Tl;dr – we were engaged by a client back in June 2017 to rebuild NotPetya from scratch. However, instead of the data destruction payload, they asked for telemetry and safeguards. Why? Because they wanted to measure what the impact of NotPetya would have been. Below, you’ll find part one of the story…
When you dodge a bullet
In June of this year, NotPetya hit. Hot on the heels of WannaCry, it was a wakeup call for a lot of organisations. Instead of a worm that encrypted data which could be recovered (if paid for), we witnessed one that would rip through infrastructure and destroy any of the hosts it was able to.
Very quickly, mature organisations began to realise that this type of event, and the resulting failure scenario, is hard to test for.
When a progressive client comes calling
At the end of June we had a client reach out with a request:
“The thing with NotPetya and our network is that we have made a number of assumptions about the defences we have put in place and how these should have stopped NotPetya from spreading. But these are assumptions [and] I don’t really want to be dependent on them.
“So, would NCC Group be interested in producing a NotPetya simulation program? i.e. a NotPetya clone that we can run inside of our network, but with the ransomware removed and safe guards to ensure it stays within our network. Also could you create some reporting so that we can understand what mechanism it used to move between each host and how long it took to move around the network?”
Queue A-Team build music
From a security engineering perspective, this sounds fascinating because – let us be honest – it absolutely is.
Much like how Red Teaming is returning penetration testing back to the art/science of real attacks, this malware simulation engagement team is one of those projects you relish. Engagements like this truly give us the opportunity to gain better real-world understanding.
We first worked with the client to define a set of requirements. These included:
- Target operating systems
- Target enumeration mechanisms
- Propagation mechanisms
- Exploits
- Enable/propagate switches
- Kill/remove switches
- Telemetry and reporting
- Clean-up and removal
- Anti-network saturation algorithm
While the first four effectively mirrored NotPetya, they were explicitly detailed for sake of clarity.
The second five were safe guards and included:
- IP address whitelists to target and ensure we only run within
- DNS held pre-shared secrets that were checked and validated for their ability to run and be killed/removed
- Regular heartbeats
- State reporting
- Success/failure reporting
Engineering was led by our Exploit Development Group with support from Cyber Defence Operations and started on 10 July.
We are at Defcon 2
On 11 September we entered the testing phase with our client, who has deployed a lab where the initial run will occur.
Once acceptance testing has passed, it will be released into production.
Discussing the risk
This is an interesting engagement for a couple of reasons.
First, we are not executing the code in the client environment. The client is.
And second, we know that, inherently, some of the exploits in NotPetya are unstable at times due to the nature of kernel exploitation. In our experience, the reliability of exploiting the EternalBlue bug can drop as low as ten per cent in some cases.
On the flip side, the value of the real-world data as to what impact something like NotPetya could have on this organisation is arguably invaluable to challenge or support the client’s assumptions.
All of this has led to some very frank discussions around risk.
What’s next?
Our client is being very supportive in terms of allowing us to publish what we learn while delivering this project. Once run in production, we plan to share detailed lessons learned from both the engineering and execution aspects of this project.
We believe that sharing the knowledge we’ve gained more widely is of huge benefit and will hopefully help to inform the thinking around risk.
Need a research-led solution?
If you need a specialist team to deliver a research-led solution, email response@nccgroup.trust.
Published date: 19 September 2017
Written by: Ollie Whitehouse
