Friday, May 19, 2017

On the Misuse of Artifacts of Whitehat Research

The Metasploit module for EternalBlue was developed by myself and JennaMagius, previous community contributors of the project, and security researchers at RiskSense, a provider of pro-active cyber risk management solutions. The module was developed to enable security professionals to test their organization's vulnerability and susceptibility to attack via EternalBlue.

As part of our research, a recording of the network traffic that occurs when the FuzzBunch EternalBlue exploit is run was packet captured. The purpose of this recording was to help educate other security professionals, and get feedback as they worked through the process. This kind of approach is fairly common in both the security researcher and open source contributor communities, where transparent collaboration enables individuals to pool their expertise and achieve greater results.

It's possible that network data from this analysis was copied and rewritten by individuals with malicious intent; we cannot confirm if this is the case or not. Unfortunately, this is a risk that is taken whenever technical information and techniques are shared publicly. Nonetheless, we believe the educational and collaborative benefits generally outweigh the risk. We currently believe any overlap is an attempt to shift blame and obfuscate investigations by misdirecting authorities.

To our knowledge, no code from the Metasploit module was ever used in the WannaCry attacks, and once Dr.Krypt3ia's blog pointed out the possibility that some of the information may have been used by the attackers, we removed the recording from the GitHub repository to ensure no other bad actors would be able to do likewise to create variants of the malware.

Do note: there is nothing special about our research or recording, and an attacker can still create his or her own recording of FuzzBunch. It is important that non-technical people realize the recording used is simple to recreate, and was from the original NSA exploits. There are hundreds of FuzzBunch recordings that have been made available by other researchers.

Here's a summary of context and the technical details:

  1. On April 27th, JennaMagius created a recording of the network traffic that occurs when the FuzzBunch EternalBlue exploit is run. That recording was subsequently posted on a Metasploit GitHub issue. The recording included an IP that was used as a lab target of the original exploits.
  2. Recording the replay and playing it back works against freshly booted boxes because the Tree Connect AndX response will assign TreeID 2048 on the first few connections, after which it will move on to other tree IDs. This is the same for the user login request. The replay would then fail because the rest of the replay is using "2048" for the tree and user IDs, and the server has no idea what the client is talking about.
  3. On April 30th, JennaMagius published a slightly enhanced replay by substituting in the server provided TreeIDs and UserIDs. This was subsequently posted on GitHub (now removed).
  4. Research supplemented these findings by outlining that __USERID__PLACEHOLDER__ and __TREEID__PLACEHOLDER__ strings were also present in the malware.

Replaying ANY recording of EternalBlue will produce the same result, so the attackers may have chosen to use that particular recording to throw investigators off track. We have studied samples of other MS17-010 worms, where the authors created their own recordings. It is important to note that to our knowledge no code from the Metasploit module was ever used in the WannaCry attacks.

To be successful, the attackers independently implemented sending the network traffic in C; constructed additional code to interact with DoublePulsar (which is a significantly harder undertaking than just replaying the recorded traffic), implemented the rest of their malware (maybe before or after), and then released it on the world. The technical prowess displayed is enough to assume that the malware authors could and would have completed their worm without misusing elements of whitehat research.

A technical whitepaper will be made available at a later time. Rapid7 has also released a statement.