Table of Contents
- Introduction
- How is Ransomware Deployed?
- Credential Harvesting
- ProcDump
- comsvcs.dll
- Custom Applications
- Lateral Movement
- RDP
- WMI
- SMB
- Backdoors
- Account Creation
- Ransomware Deployment
- Conclusion
Introduction
Ransomware is something that’s haunted businesses for well over a decade, and now more than ever, detection for these attacks is something that should be prioritized by organizations. While reports have noted a slight decline in the number of ransomware attacks (Sophos 2020), they have now become highly targeted, more sophisticated, and deadly due to the value of the assets being encrypted.
How is Ransomware Deployed?
For ransomware to be as effective as possible, it must infect as many endpoints as possible, this means that ransomware is commonly deployed using techniques that allow for quick and easy distribution. Deployment methods could involve the following:
- Microsoft SysInternals PsExec Utility
- Group Policy Objects (GPOs)
- System Center Configuration Manager (SCCM)
If the attacker has reached the stage where they are ready to distribute the ransomware, your detection of it will most likely occur once it starts encrypting your files, which is far too late. Prior to the deployment of the ransomware, the attacker must infiltrate the network, setup backdoors, harvest credentials, laterally move, and exfiltrate data – the attacker has to make a lot of noise to reach their end goal, and it is at these key points where defenders need to be detecting this attack. The dwell time from first signs of malicious activity to the deployment of ransomware can be as little as a few hours, so quick detection to prevent a successful attack is a must. The following figure shows an example flow of how a ransomware attack may play out:
Let's run through this and see how we can detect this with NetWitness.
Credential Harvesting
For an attacker to laterally move, they are going to need some credentials, these are typically obtained by dumping the memory of LSASS and using Mimikatz to extract the cleartext credentials from the dump. There are several methods an attacker can use to dump the memory of LSASS:
- Microsoft Sysinternals ProcDump
- Using the MiniDump function from comsvcs.dll
- Custom applications (such as Dumpert)
Understanding these methods and how they manifest themselves in NetWitness is important for defenders, so they can quickly identify if these actions are occurring on their network.
ProcDump
ProcDump is a command line utility, and as such, will typically be executed via cmd.exe. The corresponding events for this would look similar to below, where cmd.exe launches the ProcDump binary with the command line arguments to dump LSASS memory and save it as a minidump:
We then see the ProcDump binary open lsass.exe in order to dump the memory:
This minidump would typically be exfiltrated from the network so the attacker can run Mimikatz against it to extract credentials. They do this activity offline as introducing Mimikatz into the network would most likely trigger antivirus and other detections. You should definitely monitor your AV logs for alerts of this type.
The activity above could be detected by adding the following application rule to your Endpoint Decoder(s):
| Name | Logic |
|---|---|
| procdump lsass dump | param.src contains '-ma lsass' || param.dst contains '-ma lsass' |
| sysinternals tool usage | param.src contains '-accepteula' || param.dst contains '-accepteula' |
Microsoft Sysinternal tools could also be detected by utilising the following query, file.vendor = 'sysinternals - www.sysinternals.com':
As a defender, it would then be possible to identify malicious intent by analyzing the location and names of the binaries. For example, the screenshot below shows that the Sysinternal tool named, pd.exe, exists in the C:\PerfLogs\ directory, this should stand out as anomalous and be triaged:
comsvcs.dll
This method has been around for quite some time but is seldom observed being utilized by attackers, however, it is a method to dump LSASS memory that should be monitored all the same. An example of how this may look is shown below, where we see a PowerShell command using rundll32.exe to utilize the MiniDump function to create minidump of LSASS:
We then see rundll32.exe open lsass.exe in order to dump the memory:
The activity above could be detected by adding the following application rule to your Endpoint Decoder(s):
| Name | Logic |
|---|---|
| comsvcs.dll lsass dump | param.src contains 'comsvcs.dll MiniDump' || param.dst contains 'comsvcs.dll MiniDump' |
Custom Applications
Custom applications can be made to dump the memory of LSASS using direct system calls and API unhooking. An example of a tool that does just that is, Dumpert. Tools such as this would commonly be executed by cmd.exe. From the below we can see that cmd.exe was used to run Outflank-Dumpert.exe, and subsequently Outflank-Dumpert.exe opens lsass.exe to dump the memory:
Activity from unsigned executables opening LSASS would be flagged by the meta value shown in the following figure. As a defender, all binaries flagged by this meta value should be investigated to confirm if they are legitimate or malicious:
If the LSASS minidump is transferred across the network via a cleartext protocol, and you have pushed the fingerprint_minidump Lua parser to your Packet Decoder(s), the following meta value would be created; which would be another great starting point for an investigation:
Lateral Movement
Once the attacker has credentials they can then begin to laterally move to endpoints in the network. There are a number of options an attacker has to move laterally, typically they are seen to use:
- Remote Desktop Protocol (RDP)
- Windows Management Instrumentation (WMI)
- Server Message Block (SMB)
While all the above are used legitimately within an environment, it is important for defenders to understand how and where they are utilized to idenitfy anomalous usage.
RDP
RDP is a great way for attackers to laterally move, it provides an interactive graphical view of the endpoint they connect to and can easily blend in with normal day-to-day operations allowing it to go unnoticed by defenders. Typically, RDP logs are utilised when evidence of compromise is found. The attacker will be utilising one or more users and this information could then be utilised as a pivot point to identify lateral activity:
In order for the RDP event logs to be parsed as shown above, I added two dynamic log parser rules: Log Parser Customize: Log Parser Rules Tab
The best log to monitor RDP activity is the Microsoft-Windows-TerminalServices-LocalSessionManager/Operational event log; an event ID of 21 will be a successful RDP connection. A great read to get a better handle on the event ID's related to RDP can be found here: Windows RDP-Related Event Logs: Identification, Tracking, and Investigation | Ponder The Bits.
WMI
Moving laterally to endpoints using WMI is a common technique adopted by attackers. Typically, usage of a tool named, WMIExec, is favoured. The following screenshot shows an example of how this tools usage looks in NetWitness Endpoint. From the below we can see the WMI provider service, WmiPrvSE.exe, executes cmd.exe and passes the parameters along with it:
Adding the following application rules to your Endpoint Decoder(s) would assist with detecting potentially malicious WMI usage:
| Name | Logic |
|---|---|
| wmiexec | param.dst contains '127.0.0.1\\admin$\\__1' |
The NetWitness Endpoint Decoder also comes with out of the box content to detect potentially malicious WMI usage:
Pivoting on these meta values would be a great way to detect possible attacker lateral movement, as a defender you would want to identify any atypical commands associated with the WMIC activity, an example of this is shown below, whereby the the attacker could use WMI to remotely execute commands on an endpoint using "process call create":
Remote WMI activity is also flagged in NetWitness Packets with the meta value, remote wmi activity. When process call create is utilised (CAR-2016-03-002: Create Remote Process via WMIC | MITRE Cyber Analytics Repository), the execmethod meta value will be populated under the action meta key. Identifying endpoints where this is taking place and typically does not, is another great starting point to identify potentially malicious WMI usage:
SMB
Lateral movement via SMB is typically performed with the net use command. It allows attackers to access a shared resource on a remote computer. Their favoured resources are typically the administrative shares, which commonly are C$, ADMIN$, D$. In order to identify if this type of activity is occurring in your environment keep an eye out for the following meta values:
A sample of the net use command to mount an administrative share is shown below:
As a defender you would want to pivot on these events and see what endpoints this activity is occurring on, from there you can perform timeline analysis on the endpoint to see what other activity took place around that time.
Backdoors
Once an attacker has breached a network they will need to maintain persistence. There are two primary ways that an attacker will do this:
- Deploy a web shell to a public facing server
- Deploy a Trojan to beacon back to a C2 server
A common method to detect C2's is via proactive hunting, which is something we have discussed in-depth on many occasions as part of the Profiling Attacker Series. We highly recommend reading through these posts to grasp C2 and web shell detection as they have been covered in-depth on a number of posts.
Another great resoure for identifying endpoints that are potentially infected with web shells or Trojans is the Microsoft-Windows-Windows Defender/Operational event log. Antivirus events are often overlooked but can be a great indicator to potential compromise as shown below, where Defender identified two web shells in the C:\PerfLogs\ directory:
Account Creation
Attackers may choose to create an account in order to push their ransomware or to laterally move. A common way for an attacker to create an account is with the net command. If the following meta value appears, it should be investigated to confirm if the user account creation was legitimate or not:
Pivoting on this meta value would give us some context as to what user was created and how. From the below we can see that lsass.exe executed net.exe to create an account named, helpdesk - this is indicative behaviour of the EternalBlue exploit:
If a user was adding via the command line it would look like the following. This is not to say that this is legitimate behaviour, but demonstrates the differences as to how a normal execution of net.exe would look:
For both of these events, the defender should perform anlaysis on the endpoint(s) in question and perform timeline analysis to look for further anomalous behaviour.
Some additonal useful application rules that could be deployed to detect anomalous behaviour by LSASS:
| Name | Logic |
|---|---|
| lsass writes exe | filename.src = 'lsass.exe' && action = 'writetoexecutable' |
| lsass creates process | filename.src = 'lsass.exe' && action = 'createprocess' |
From the account creation perspective, the Security event log would record a 4720 event ID along with information about the user that was created:
As a defender, you could pivot on reference.id = '4720' to analyse what user accounts were being created and where.
Ransomware Deployment
Ransomware can be deployed via a number of methods. The one we will cover here is deployment via PsExec. This is a common choice for attackers as it is a legitimate Microsoft tool that can be easily scripted to copy and execute files. Based on the way PsExec works, we can easily spot its activity based off of the following meta value:
Drilling into these events, we can see that PsExec.exe was used to connect to a remote endpoint. transfer a binary and execute it:
A useful application rule to further detect PsExec usage could be:
| Name | Logic |
|---|---|
| psexec usage | filename.dst = 'psexesvc.exe' |
There are many clones os PsExec that work in a very similar to fashion, the following application rules should be added to help identify their usage within your envrionment:
| Name | Logic |
|---|---|
| remcom usage | filename.dst = 'remcomsvc.exe' |
| csexec usage | filename.dst = 'csexecsvc.exe' |
| paexec usage | filename.dst begins 'paexec' |
From a Packet perspective, PsExec execution would be flagged under the Indicators of Compromise meta key. As a defender you would then need to determine if the PsExec activity is legitimateor not:
For a log perspective, the System event log records an event ID of 7045 (service creation) when PsExec is being used, as is shown below:
This is because PsExec and similar to tools utilise the service control manager (SCM) in order to function. For a better understanding of PsExec and how it works, please refer to the following URL: https://www.contextis.com/de/blog/lateral-movement-a-deep-look-into-psexec.
Conclusion
What has been outlined above is merely an example of how a ransomware attack may unfold. Of course there are a myriad of tactics, techniques, and procedures (TTPs) an attacker will have in their arsenal that have not been outlined within this blog post, but this hopefully gives you a good starting point of how to use NetWitness to identify anomalous behaviours and prevent successful attacks. The further down you are in this process the higher the probabiity the attacker will succeed, if you are at the PsExec stage, it is already a bit too late. It should also be noted that the application rules listed in this blog may generate false positives, each envrionment is unique and the filtering as such should be performed on an individual basis.
