If you are already using Microsoft Sysmon in your environment, then you might be wondering whether it is possible to detect WannaCry activity on your Sysmon-enabled Windows hosts. The answer is yes, and this blog will explain how!
What is Sysmon?
“System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time. By collecting the events it generates using Windows Event Collection or SIEM agents and subsequently analyzing them, you can identify malicious or anomalous activity and understand how intruders and malware operate on your network.” Source: https://technet.microsoft.com/en-gb/sysinternals/sysmon
The assumptions made for this article are that Sysmon has already been installed using the default Sysmon configuration, and that you are already collecting Sysmon log sources into LogRhythm. For reference, the command used to install a basic instance of Sysmon would simply be (depending on whether you are protecting x86 and/or x64 hosts):
If you are already using a custom Sysmon configuration, then you will need to ensure that the following event tags are added to the XML configuration:
Below are the two event IDs we can use to detect WannaCry. Note that there are additional event IDs a system administrator may use, but for the following example, we are primarily using Event IDs 1 and 2. The additional event IDs and their corresponding explanation, along with the download link to the Sysmon utility can be found here: https://technet.microsoft.com/en-gb/sysinternals/sysmon
|1||Process Creation||The change file creation time event is registered when a file creation time is explicitly modified by a process. This event helps tracking the real creation time of a file. Attackers may change the file creation time of a backdoor to make it look like it was installed with the operating system. Note that many processes legitimately change the creation time of a file; it does not necessarily indicate malicious activity.|
|2||A process changed a file creation time||The change file creation time event is registered when a file creation time is explicitly modified by a process. This event helps tracking the real creation time of a file. Attackers may change the file creation time of a backdoor to make it look like it was installed with the operating system. Note that many processes legitimately change the creation time of a file; it does not necessarily indicate malicious activity.|
Table 1. Event IDs and Their Meangings
If you are already using Sysmon, you can skip this section. However for LogRhythm configuration steps, below is an example of a default configuration of a log source configured to collect using the “MS Windows Event Logging – Sysmon” Log Message Source Type. In the example that follows, we are collecting the Sysmon output from a Microsoft Windows Server 2012 R2 x64 host, using the default Sysmon XML configuration.
Figure 1: Log Message Source Properties Basic Configuration Window
For the Flat File Settings, you will want to ensure that the File Path is specified correctly:
Figure 2: Log Message Source Properties Flat File Settings Window
Note: In case you wonder where you get the file path from, this is simply found by opening any event ID contained in the Event Viewer > Applications and Service Logs > Microsoft > Windows > Sysmon > Operational log. By clicking the Details tab and selecting the XML view, you simply need to note down the Channel name, and copy/paste this into the Flat File Settings > File Path field.
Figure 3: Event Properties XML View
WannaCry Sysmon Artifacts
First we see a group of Event ID 2s for each individual language file (prefixed with the .wncry file extension) stored in the newly created “msg” folder on the desktop. You will likely see around 28 of these events being written, for each individual language file. These are created after the WannaCry encrypter component is first run (typically obvserved with the file name “tasksche.exe”, but could be named differently), and the dropper begins to extract and write files to this new “msg” folder by the extracted wcry.exe process.
Please note that this path will be dependent on where the initial executable was run. For example, if the WannaCry executable was run from the Desktop, then the msg folder (and additional files that get extracted) will be stored on the Desktop. These first few event IDs give a wealth of forensic knowledge, such as the Log Source Host, MPE Rule Name, Object, Object Name as well as Common Event.
Figure 4: Msg Folder Language Files Being Created
Below we can see the “r.wnry” file being created on the desktop, which includes additional decryption instructions used by the decryptor tool. Again, as shown in the below screenshot, the wcry.exe process is responsible for creating this on the user’s desktop. Some more useful indicators are highlighted below.
Figure 5: r.wncry Configuration File Being Created
The “s.wnry” also is created (not shown), which contains the TOR software executable. This is used to later communicate to TOR hidden services to provide the infected user the ability to be able to pay the ransom using BitCoin.
The “taskse.exe” file, which is responsible for enumerating Remote Desktop Protocol (RDP) sessions, then is created. This is another file that is created by wcry.exe, and placed on the desktop.
The “s.wnry” and “taskse.exe” also use the same event ID as the example shown above.
Figure 6: taskse.exe File Being Created
The “taskdl.exe” is then created (not shown), which is the file deletion tool. This process is responsible for the encryption of the files, which then writes the encrypted files using the “.WNCRYT” file extension.
The “t.wnry” file next gets created (not shown), which contains part of the AES encryption and a DLL file.
The decrypter file “u.wnry” then gets created (not shown).
Again, the “taskdl.exe,” “t.wnry,” and “u.wnry” files generate the same event IDs as above.
Now the “attrib +h .” command is run, which hides the current directory. Here, we can see additional metadata fields populated, such as the Hash, Session, and more. This is a great example of using out-of-the-box Sysmon parsing rules and a standard Sysmon configuration to quickly get a rich set of indicators that can be used not only as indicators, but also to later be able to build out detection rules with AI Engine.
Figure 7: Attrib Command Executing
Now we see the “icacls . /grant Everyone:F /T /C /Q” command being run. This grants all users on the system full access to files in the current directory, and all subdirectories beneath it.
Figure 8: icacls Command Executing
Further along, we see a CScript execute a VBS script “m.vbs.” This is essentially the part of the ransomware that provides persistence, and creates a link to a batch file (not shown).
Figure 9: csript Executing the m.vbs File
Next we see many more of the same of the following, which indicates that WannaCry is now encrypting files on the infected host and replacing the file extension of legitimate files with the “.wncryt” extension.
Figure 10: File Encryption Process Begins
There are many, many more event IDs that follow (1028 in total to be precise, although this may vary between operating systems), but hopefully, the above snippets are enough to leverage log data generated by Sysmon on machines collected by a LogRhythm System Monitor agent. Using default Sysmon configuration and a simple log collection setup, a whole host of data can be parsed out using our out-of-the-box default Sysmon log processing policy.
WannaCry Detection Using LogRhythm and Sysmon
Using metadata fields such as Object, Object Name, Vendor Message ID, Process Name, Hash, and others, you can quickly look to build simple detection rules using AI Engine. Looking for any of the fields mentioned, and targeting the rule to look at Sysmon-enabled log sources, simple Log Observed rule blocks can be created to look for the presence of any of these indicators, which can further be alarmed on, and aid the SOC team to reduce the impact and spread of WannaCry.
One example is shown below. Note: If you are already collecting Sysmon log sources, then you should first check to see how your log data is represented, as it may not be identical to the above examples shown.
Figure 11: AI Engine Detection
Special thanks to these additional LogRhythm Labs team members for their continued work analyzing and reporting on WannaCry and other threats affecting LogRhythm customers: Brian Coulson, Erika Noerenberg, Kim Raburn, Matt Willems, Nathanial Quist, and Rob McGovern.
More Posts from Andrew Costis
- WannaCry Ransomware
- Understanding Insider Threats with UEBA
- Detecting the BlackNurse DDoS Attack with Network Monitor