EternalGlue: Using NotPetya as a Testing Tool

Written by

When it hit in July 2017, the attack we now know as NotPetya seemed to have been eclipsed by the WannaCry ransomware, which hit some six weeks earlier. In fact, NotPetya proved to be significantly more aggressive and had functions enabling wiping as well as encrypting data, resulting in more than $10bn in total damages.

With so much knowledge in hindsight of what this attack was able to achieve, surely more than two years on, and with those affected now delivering keynote talks, we should be able to take more of an analytical view of NotPetya’s capabilities? Two researchers who did just that are Aaron Adams and Cedric Halbronn from NCC Group. In a recent presentation at UK security conference 44CON, the two researchers saw the opportunity to create the ultimate malware testing tool with a sample of the malware.

“This was a safe version,” said Halbronn, who said that after three days of reverse engineering, they uncovered the 150 functions of NotPetya, which included 5000 lines of code, and the ability to use NSA exploits EternalBlue and EternalRomance, which were leaked by the Shadow Brokers group in early 2017.

“It also used the DoublePulsar exploit, and had its own customized backdoor” said Halbronn. Once reverse engineered, and with what they called a “safe worm,” they saw the opportunity to run the de-weaponized malware on a network. “So we built a telemetry server to see what was happening, and be sure we were not running malware into a safe environment.” He also said that this allowed the malware's execution to be terminated.

In terms of the capabilities, some of the original capabilities were used and “glued” together, giving it the name of “EternalGlue.” Halbronn said: “We included a kill switch and all agents, which talked to the telemetry server, and we could see if it didn’t work as it would stop and upload the log back to server. If cannot talk to the server, it will stop.”

The preparations also included whitelisting the malware to the local IP provider, in order to prevent it propagating.

The trial was built for a client, who appeared with the Halbronn and Adams, but did not speak on the record. The researchers said that the lateral movement “only kicks in when it is exploited through EternalBlue,” and in a patched environment “it will not get through anything.” It was also considered that running this sample was a big concern to the client's operations team, who “are scared of this and were also aware that they could spend hours rebuilding the network.” The client said that getting the company on board with this test was “harder than you think” and unless the company could be convinced of the kill switches and how it was run, “we would never get sign off for running it in the network.”

On the first test, the malware was completely detected by the client’s anti-virus, while Adams admitted that they didn’t want to run EternalGlue on Virus Total in order to avoid creating signatures to detect this, and also they didn’t want to rewrite the exploits. However as the anti-virus didn’t scan Python language, it was run as Python which worked. The researchers also rebuilt the Mimikatz post-exploitation tool, and integrated it into the obfuscated source code.

The first test was in early 2018, and on a second run anti-virus was still detecting it, “and it turned out that the client’s anti-virus vendor had a false positive” and was flagging a frozen Python module as malware. Adams said that was stopping it from propagating.

Further tests were run, including as low privilege, and as a system administrator, and on a third test run an unpatched system was found. When a successful test was finally achieved, the client said that it “moved fast and aggressively in 30 minutes” because of a mistake in Active Directory, which is why privilege settings were so important to be reviewed.

They said that they reviewed the logs, and found selected “account is sensitive and cannot be delegated” messages, and without that protection, they said that the worm would have propagated.

“The surprise is that we have not seen another worm since 2017 as the scope is there for improvement, the game is far from over,” they said.

Halbronn said that the development of EternalGlue took four months of development for two people, and included more than 20,000 lines of C code. As for what is next, Halbronn said that this showed that “trusted mitigation can be bypassed” while he and Adams dismissed the possibility of releasing the tool as open source “as that would remove the safety nets, it’s not a good idea.”

The client said that it is always good to validate the testing process, and also use this to prepare defenders “as no one knew how long it would take, and this helped us understand” the time factor, and also adjust defenses as appropriate and replay it and see if the changes worked.

In terms of propagation, the research found that the malware would not propagate to standard users with no local admin rights, but would “100% propagate” to a user with “God rights”, which they called the “nightmare scenario.”

Speaking to Infosecurity after the event, NCC Group global CTO Ollie Whitehouse said that the organization wanted to test the resilience they had in place to be able to quantify the impact that NotPetya specifically would have had on them.
“This project was therefore a valuable opportunity to gain real-world understanding of the impact that this type of ransomware could have on an organization in the future.”

So what were the reasons for the multiple test failings, and what enabled it to finally work after a few efforts? Whitehouse said that due to various safety measures, it took a while for the assessment using EternalGlue to get going, and the process involved starting the software from various points around the network under a number of different user scenarios to help generate the most accurate and insightful outcomes.

Could this be something that NCC Group could repeat for others? Whitehouse said that to ensure that the software was highly reliable and safe to release into a live enterprise environment, it carried out extensive testing with the client over the period of a year, in a variety of scenarios, while “extensive safeguards that prevent it from causing adverse effects” were included. These involved: removing the ransomware payload; implementing IP address whitelists so that business-critical systems weren’t affected; and ensuring that the software had a low enough threat priority to avoid causing disruption to end-users.
“Following very successful initial tests, we have subsequently gone on to take a number of other customers on the same journey,” he said.

While this effort didn’t come without its share of headaches, the effort to turn something so destructive into the ultimate testing tool has to be applauded.

What’s hot on Infosecurity Magazine?