This morning, reports began coming out regarding a new ransomware infection rapidly spreading across Europe. Early indications are that this began in the Ukraine, and has branched out from there. Most early reports are calling it Petya, due to the fact that it appears to behave very similar to the Petya ransomware that emerged last year. However various researchers are claiming that this is not in fact Petya, and is dissimilar enough, that it should be classified as something different. When you’re dealing with responding to an incident like this, you don’t care what it’s called, you just want the information you need to deal with the threat.
What makes the Petya ransomware a little different from traditional ransomware, is that unlike most ransomware families that target various file types for encryption but leave the operating system relatively intact and operable, Petya instead renders the entire system disk inaccessible after a reboot, meaning you can’t even get windows up and running to determine what was lost.
Instead, upon system boot, you get a text screen with a message that makes it look like it’s running the legitimate chkdsk tool, but in reality is doing its dirty work. When that phase is done, it displays a simple text message, instructing the victim to send an email with a unique identifier to an email address along with $300 in bitcoins to re-gain access to your system. (#Protip: The email address included in the scheme has since been decommissioned and is no longer active so you can no longer coordinate ransom payment if that was something you were even considering.)
The ransomware is also interesting in that it appears to spread on its own, similar to the recent WannaCry ransomware outbreak. Symantec has confirmed that it is leveraging the same ETERNALBLUE exploit, targeting systems that have not yet applied MS17-010. However, another unique aspect of this ransomware is that it also uses legitimate credentials to spread. Analysis of the sample shows that the ransomware also embeds a copy of PsExec, which it can use to spread throughout an organization. As if this weren’t enough, the credentials could also be used in conjunction with WMI, providing another mechanism in which to spread. The assumption at this point is that it uses the credentials of the currently logged-in user, which means it can infect fully patched hosts.
If you’re a Splunk customer, you know how to use the platform to get actionable information out of the reams of data your systems generate. If you’re collecting security-related data, there are various things you can look for there, specific to this attack. We’ll go over some things you can look for that should help you deal with this campaign, as well as other security incidents.
Searching for windows event log clearing
Based on various published reports, the ransomware takes the step of clearing the event logs shortly after infection. Searching for this can help you identify systems that may have been impacted by this campaign.
When windows event logs are cleared, they generate a specific event to let you know about it. If we are collecting Windows event logs, we can search for this event with the following search:
((sourcetype=wineventlog:security OR XmlWinEventlog:Security) AND (EventCode=1102 OR EventCode=1100)) OR ((sourcetype=wineventlog:system OR XmlWinEventlog:System) AND EventCode=104) | stats count by _time EventCode sourcetype host
The search above uses data from the windows event logs to look for the events that will indicate that a log has been cleared. Event 1102 in the Security log indicates that the log has been cleared, and 1100 indicates the event log service is shutting down. In the system log, event 104 will be generated when any event log is cleared.
If we are collecting data on processes, we can also look for the execution of a tool called wevtutil, that can be used to clear the event logs. The following search looks for the execution of this tool, as well as the arguments passed along that are needed to clear the logs. This data may be available in Windows logs if process auditing is enabled, or in endpoint data that could be collected via Sysmon or an endpoint tool that reports process and file system info such as Carbon Black. The search below is looking for the wevtutil being run with the command line options to delete either the System log or the Security log. The search uses the tstats command to search against data that has been accelerated in the Application_State data model. This allows for much faster searching against large sets of data.
| tstats `summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Application_State where All_Application_State.process_name = "*wevtutil.exe" AND (All_Application_State.process = "*cl System*" OR All_Application_State.process = "*cl Security*") by All_Application_State.dest All_Application_State.user All_Application_State.process | `ctime(firstTime)` | `ctime(lastTime)`
Searching for remote process execution via WMI
Multiple reports state that the ransomware attempts to spread internally via WMI. This technique requires the use of legitimate credentials, which the ransomware will attempt to harvest from the local system. The following is a search used to look for the command line that invokes wmic with the proper arguments to remotely launch a process. The search uses the tstats command to search against data that has been accelerated in the Application_State data model. This allows for much faster searching against large sets of data.
| tstats `summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Application_State where All_Application_State.process_name = "*wmic*" AND All_Application_State.process = \"*/node*\" AND All_Application_State.process = "*process call create*" by All_Application_State.dest All_Application_State.user All_Application_State.process_name All_Application_State.process | `ctime(firstTime)`| `ctime(lastTime)` | `drop_dm_object_name("All_Application_State")`
Searching for the use of fsutil
Fsutil.exe is a built-in Windows tool used to perform tasks that are related to the file allocation table (FAT) and NTFS file systems. It is executed along with wevtutil for event log clearing. Specifically, the update sequence number (USN) change journal provides a log of all changes made to the files on the disk. The ransomware uses this command to delete the log that contains all the changes that have been made. The search belong looks for fsutil being run with the command line options the delete the USN journal. This search also uses the tstats command to search against accelerated data.
| tstats `summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Application_State where All_Application_State.process_name = "*fsutil*" All_Application_State.process="*usn*" All_Application_State.process="*deletejournal*" by All_Application_State.dest All_Application_State.user All_Application_State.process All_Application_State.process_name | `ctime(firstTime)`| `ctime(lastTime)` | `drop_dm_object_name("All_Application_State")`
Regardless of the source or nature of attack, data is your friend. If you’re collecting the right data from the right places, going back and digging through it can help you identify all impacted systems and give you details about what happened right before the initial infection to help you identify root cause. It can also quickly confirm your systems are being backed up properly, they have current patches applied, and what external systems have been visited. It’s all about collecting the right data, and being able to quickly pull out the relevant information.
There are a number of ways to use Splunk to combat Petya and ransomware in general.
If you want to use something pre-packaged, the Splunk Security Essentials for Ransomware App is designed to identify various behaviors common to ransomware and alert you to them. The app includes over a dozen use cases, with search templates that you can customize to your environment.
If you are using Splunk Enterprise, there are a number of techniques outlined in the blog, “How Splunk can Help you Prevent Ransomware from Holding your Business Hostage.”
If you are using Splunk Enterprise Security, check out the blog “Enhancing Enterprise Security for Ransomware Detection."
If you are a smaller organization and new to Splunk, you may be interested in Splunk Insights for Ransomware.
In addition, if you are currently an ES customer, the security research and product teams at Splunk are developing a new application that is currently in Alpha, called ES-SOC. This application is designed to continuously deliver searches that help Splunk Enterprise Security users detect, investigate, contextualize and scope various suspicious activities, and includes many of the above behaviors as well. If you’re interested in being an ES-SOC alpha customer, contact us at firstname.lastname@example.org.