Petya.A / NotPetya is an AI-powered cyber weapon, TTPs lead to Sandworm APT group

[post-views]
July 02, 2017 · 7 min read
Petya.A / NotPetya is an AI-powered cyber weapon, TTPs lead to Sandworm APT group

It’s been a hot summer for security industry: in less than a week since the initially suspected ransomware Petya.A has turned out to be much more than meets the eye. Security researchers around the world have rightfully dubbed it NotPetya and EternalPetya, as the malware was never meant to ask for ransom – it was merely a disguise for a wiper component of an APT attack. With nearly 16 man/days of field work & lab investigation at the cyberwar epicenter in Ukraine we can publish the preliminary TTPs. While most of the world has successfully dealt with another WannaCry clone Ukraine has been hit by perhaps a first AI-powered cyber weapon. More traditional way would be presenting this campaign as an APT with an autonomous worm component, though there’s still much to learn. As of today with the help of our partners, clients and friendly security researchers our team has gathered TTPs that point to an infamous Sandworm APT group. The same very actor who was behind BlackEnergy attacks that previously lead to power grid outage in Ukraine. Let us quickly recall what TTPs are all about:

You can see all Hash, IP and Domain values in reverse engineering reports by Microsoft, local Ukrainian forensics firm ISSP Labs and github thread by Vulners. We will use MITRE ATT&CK open methodology to describe the TTPs (updated daily).

To fully describe the attack and do actor attribution we need to include Delivery phase which requires gathering evidence onsite. What’s up with the colors on the frames? Security industry lacks a standard when it comes to sharing attack details. There is of course STIX and its implementation by TIPs but it did not work out so good with NotPetya and WannaCry, did it? So hereby I’d like to propose an open standard for everyone to use. Idea is that there are different IOCs and Techniques we can rely on during such outbreaks and there is total chaos in security field on what samples are relevant, what are not, let alone IOCs. I suggest this can be maybe introduced as open standard for IOC tagging (not to be confused with TLP!):

Color: GREY, weight: 1 – hypothesis. Mainly this is someone making attribution and saying – hey, I know this kind of threats so this can be possible. For example Ransomware often uses Tor, so do APT actors so we should check for Tor connections. Also I saw APT using DNS tunnels as fallback channel so lets search for that as well.

Color: YELLOW, weight: 2 – IOCs from external threat intel, sandboxes, OTX pulses etc. While these can be much better than GREY they are still not 100% trusted. We can fake an OTX pulse. Researchers can make mistake in their chase to be the first to claim the threat. Adding 1+2 in SIEM would increase weight, e.g. we know Ransomware uses Tor and TI posts an IP:port tagged as C2 and Tor.

Color: BLUE, weight: 3 – IOCs from the field, e.g. Blue teams. This is evidence gathered onsite, details shared by attack victims in any form. This is what we get by looking into 3 months old data in a SIEM (the lucky ones) or via LogParser from recovered endpoints or grepping those syslogs. Thing is, the BLUE evidence would be much higher accuracy than TI. It also makes all the difference between report by AV vendor about the threat that happened in another part of the world.

Color: RED, weight 4 – IOCs from the Red team. The hardest to get, the most accurate ones and the core for SIGMA and IOC-based SIEM rules.

This leads us to color mixing rules

YELLOW + RED = ORANGE

YELLOW + BLUE = GREEN. The valuable vetted threat intel you can use for Incident Response and SOC.

BLUE + RED (if it ever happens) = PURPLE. Epic findings (just like in World of Warcraft, lol). Then if we add all the weights we get total of 10 in value (can be leveraged for SIEM correlation). And need to decide final color, brown doesn’t really sound so hot, so lets say its GOLD. In slide above there are 2 GOLD indicators – $admin & PsExec – now confirmed by RED, BLUE (onsite event logs), threat intel and of course it was a theoretical possibility.

Perhaps you noticed a GOLD BlackEnergy attribution in Reconnaissance. Seems a long shot? In order to explain it along with the GREY we will have to compare the TTPs by looking through all Techniques from BlackEnergy in ATT&CK, adding the Delivery phase from Lockheed Martin’s Cyber Kill Chain and recalling our own investigation. Before we do that, let’s review above diagram with Delivery mixed in, let’s dub it Extended Cyber Kill Chain for now.

As you can see we use our color marking method to confirm that M.E.Doc update as GREEN. Not only it was only reported by external research (though Microsoft telemetry is strong evidence, and a strong security concern too) – we also digged up network and AD logs from APT victims SIEMs, BLUE evidence that clearly indicate active M.E.Doc connections on day of the attacks. There is more, let’s draw out the APT worm intelligence pattern and see how much of an AI it really is?

Current evidence suggests that APT actor has built a cyber weaponry by using knowledge of target’s infrastructure. If we match it to the names of encrypted companies we can see that they are very often the same as victims of BlackEnergy attack in 2015/2016 (media, energy, public sector, transportation). BLUE evidence: we found connections from M.E.Doc machines to Active Directory using the Microsoft SCCM account. We performed onsite forensics in 2 companies and both of them have PsExec entries from using SCCM credentials. The biggest question is how was the decision made to work with SCCM account? There are no RED reverse engineering reports that prove that. So some either C2 was in place at certain point or we are missing a critical piece of the evidence/samples. Hence the GREY hint to Tor/DNS tunnel/HTTP C2. One can also notice that attacking party has an extensive knowledge of windows. Lets visualize all the 191 techniques we know:

Plenty to pick from, yes? Sandworm and BlackEnergy use Email attachment.

They also use extensive File and Directory discovery capabilities and the attack went after 65 critical files like password vaults, unlike hundreds of files that ransomware goes for.

Scanning capabilities are also known to Sandworm and BlackEnergy.

Bootkits are not used by that many known actors. Petya used one? Nice disguise for an APT.

Take a guess at which actor is an expert in PsExec and WMI?

wevtutil for clearing event log = Indicator removal on Host according to ATT&CK

And a scheduled task for reboot used for Execution stage

Before destroying data with a wiper component. While KillDisk deleted data and did write 0’s NotPetya destroys it with encryption without preserving Salsa20 key. In my book this is an equal data destruction.

And we all know that BlackEnergy attack was not there to delete data, but to exfiltrate it for the Phase 2.

Was this the same actor? Does the Sandworm really exist? Can this be called an AI cyber weapon? At least we now have an AI Expert system to help us answering this question…

p.s. I’d like to refer to a recent quote from a fellow security researcher who dedicated his career to fight threats like BlackEnergy “The dark side stands united”. I can’t agree more. Time has come for the security jedi to join forces once again.

Was this article helpful?

Like and share it with your peers.
Join SOC Prime's Detection as Code platform to improve visibility into threats most relevant to your business. To help you get started and drive immediate value, book a meeting now with SOC Prime experts.

Related Posts