Most malware that traverses a network do so with specific indicators, some of which look like legitimate network traffic and others that are completely unique to the malware. A single IDPS signature can have high confidence of detecting an infection but as the malware creator uses obfuscation, encryption, or even typically legitimate means in order to spread and infect a host, it can take multiple IDPS signatures for proper detection. Petya is no exception, and tries hard to make its activities look like normal traffic.
ARP:
Petya begins by attacking hosts that are already known to the currently infected system. To find other hosts on the network it performs ARP scan across the entire subnet it's associated with (excluding the IP addresses it already knows about). As it finds new hosts on the network it will attempt to infect those.
Detection:
Each infected system will perform a new ARP scan, so with many infected systems, there can be quite a bit of ARP traffic on the wire. You can often detect this type of excessive ARP traffic by monitoring your router and switch logs via network flow information or through an IDPS by monitoring for "ARP Scan" or "ARP Storm" type signatures.
SMB:
While the ARP scan is going, Petya attempts to connect to port 445 on the systems that it either already knows about or finds during the scan. While the ARP scan will constrain Petya to the internal network, if the infected host connects to any external IP address Petya will then try to infect that address as well. This gives it the ability to spread quickly.
Once it finds an open port on 445 it then tries to use credentials it procured previously from the host it infected. If it isn't able to authenticate, it will try multiple times with other credentials before moving on.
Detection:
Monitoring your system logs for multiple failed authentication attempts can be used to indicate that something is wrong. This is especially true if there are events of multiple authentication failures on multiple systems.
Signature:
Though a signature can be created to alert when a failed SMB authentication takes place, it may not be a great idea. These signatures can get quite noisy and can DDoS the analyst monitoring these events.
SMB_AUTH:
If Petya does successfully authenticate using the credentials it retrieved from the infected host, it will connect to the ADMIN$ share (located at C:\Windows) and place a copy of the malware there. PSEXEC can then be used to execute that file remotely. The newly infected system will now begin its own ARP scan and try to infect other hosts.
Detection:
Multiple signatures can be used to indicate this part of the compromise with high confidence since the file is transferred in clear text.
While any one of these on its own may not mean much (besides the bitcoin address), they can be used together to create a very strong indicator of compromise.
Signatures:
alert tcp any any -> $HOME_NET 445 (msg:"SLR Alert - SMB Write Request - MZ File Transfer (Bitcoin Address Petya IoC)"; flow:established,to_server; content:"SMB"; offset:5; depth:3; content:"|09 00|"; offset:16; depth:2; content:"MZ"; distance:0; content:"PE"; distance:0; content:"1|00|M|00|z|00|7|00|1|00|5|00|3|00|H|00|M|00|u|00|x|00|X|00|T|00|u|00|R|00|2|00|R|00|1|00|t|00|7|00|8|00|m|00|G|00|S|00|d|00|z|00|a|00|A|00|t|00|N|00|b|00|B|00|W|00|X"; distance:0; classtype:slr-tw; sid:400001; rev:1;)
alert tcp any any -> $HOME_NET 445 (msg:"SLR Alert - SMB Write Request - MZ File Transfer (Petya IoC)"; flow:established,to_server; content:"SMB"; offset:5; depth:3; content:"|09 00|"; offset:16; depth:2; content:"MZ"; distance:0; content:"run in DOS mode"; distance:0; flowbits:set,SMB.MZ; flowbits:noalert; classtype:slr-tw; sid:400002; rev:1;)
alert tcp any any -> $HOME_NET 445 (msg:"SLR Alert - SMB PSEXECSVC Command Exectution After MZ File Transfer (Petya IoC)"; flow:established,to_server; content:"SMB"; offset:5; depth:3; content:"|09 00|"; offset:16; depth:2; content:"|09 00 00 00 00 00 00 00 09 00 00 00 ff ff ff ff|"; distance:0; content:"|00|\\|00|S|00|y|00|s|00|t|00|e|00|m|00|3|00|2|00|\\|00|r|00|u|00|n|00|d|00|l|00|l|00|3|00|2|00|.|00|e|00|x|00|e|00|"; distance:0; content:"\"|00|,|00|#|00|1"; distance:0; flowbits:isset,SMB.MZ; flowbits:unset,SMB.MZ; classtype:slr-tw; sid:400003; rev:1;)
HTTP:
If it attempts to connect via SMB and fails, it will attempt to connect via WebDav to port 80. If the port is open it will send an HTTP OPTIONS Method to "/" and "/ADMIN$". Afterward it will try multiple attempts using "PROPFIND /ADMIN$".
Detection:
IDPS signature can easily detect both the OPTIONS and PROPFIND methods reaching out to the /ADMIN$ share. While this signature alone won't necessarily indicate a compromise it will if it's combined with others.
Signature:
alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"SLR Alert - Malware HTTP PROPFIND Scan (Petya IoC)"; flow:established,to_server; content:"PROPFIND"; http_method; content:"/admin$"; nocase; http_uri; content:"User-Agent: Microsoft-WebDAV"; http_header; nocase; pcre:"/Host:\s\d{1,3}\.\d{1,3}\.\d{1,3}.\d{1,3}/"; detection_filter:track by_src,count 5, seconds 30; classtype:slr-tw; sid:400004; rev:1;)
ETERNALBLUE:
When Petya isn't able get into the system via SMB or HTTP it will then start trying the ETERNALBLUE exploit to compromise systems that haven't been patched.
Detection:
There are multiple signatures to detect the presence of ETERNALBLUE. The interesting thing about this attempt at ETERNALBLUE is that the IP address used in "path" for the connection is 123.12.31.2. Not only are we able to use the many available IDPS signatures for ETERNALBLUE, but we also now have one that is unique to Petya!
Signature:
alert tcp any any -> $HOME_NET 445 (msg:"SLR Alert - Petya Ransomware/Wiper ETERNALBLUE Connect AndX Request IP \\123.12.31.2\"; flow:established,to_server; content:"|ff 53 4d 42 75|"; offset:4; depth:5; content:"|5c 00 5c 00 31 00 32 00 33 00 2e 00 31 00 32 00 2e 00 33 00 31 00 2e 00 32 00 5c|"; classtype:slr-tw; sid:400005; rev:1;)
Conclusion:
While Petya may not always show every indicator discussed in this post, it will certainly show at least a few of them. In any decently sized network you'll likely see most of them. Paying attention to your logs and alerts can greatly increase your chances of detecting and stopping the infection.
Researchers can download the packet captures used in this analysis here: https://github.com/SpiderLabs/IOCs-IDPS/tree/master/Petya
IOC Recap:
For information on the host based activity of Petya including IoCs, please see our previous post:
https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/petya-ransomware-a-glimpse-of-the-past-the-present-and-the-future/
Trustwave customers will find active protection against this campaign in many of our security offerings including:
Finally, if you find yourself or your organization infected, our Trustwave Incident Response team is happy to help you. You can visit https://www.trustwave.com/en-us/company/about-us/spiderlabs/ for more information or call our 24 hour Incident Response Hotline: +1 (866) 659-9097 and select "Option 5".