Tried-and-True Tactics: How an Adversary Mixed Lateral Movement and Cryptomining

Cryptomining continues to be a hot topic as the values of cryptocurrencies fluctuate, and adversaries use mining as an easy way to make money without needing escalated privileges. In my last detection post, I wrote about mining as the objective of exploitation against Oracle WebLogic systems. In this detection, we’ll look at how one adversary supplemented operations with a little bit of mining while preparing to move laterally across an organization’s network.

Using PowerShell to Scan and Mine

At the start of the activity, we noticed numerous Windows command shells spawning from the Local Security Authority Subsystem process (lsass.exe). This type of event is highly suspicious for a couple reasons. First, lsass.exe executes in the security context of the local SYSTEM account—and as a result, child processes spawning from it will inherit this context, giving the child processes unfettered access to the local system. Next, lsass.exe handles user authentication for a system, and rarely has child processes. Anytime lsass.exe spawns a command shell, a PowerShell instance, or a script execution, it should be closely scrutinized.

In this case, the command prompt executed a set of commands to establish persistence on the affected system. First, the adversary set a Windows Registry autorun key to leverage a Windows Installer process (msiexec.exe) to download and execute a suspicious binary. The execution of a remote installer with msiexec is unusual, especially in this context.

Next, the adversary set a second autorun key to evade application whitelisting controls using regsvr32.exe in a technique commonly known as the “Squiblydoo” attack. We see this technique often as many adversaries use it to easily download and execute suspect code outside PowerShell or the command prompt in a higher-security environment.

As a final method, the adversary created a Windows Scheduled Task that scripted a File Transfer Protocol (FTP) connection to a malicious domain, downloaded a binary, and executed it. They scheduled the task to run on system boot with the highest level of privileges on the system. We’ve begun to observe this technique much more frequently in compromises, perhaps because adversaries have become aware of blue teams getting wise to monitoring the creation of autorun Registry keys.

Why Use Multiple Persistence Mechanisms?

The use of multiple persistence mechanisms may seem like a “scattershot” to see what is effective, but it works in the adversary’s favor because it achieves persistence and further execution by numerous means. Defenders will have a tough time removing all traces of the compromise, and attempts at targeted remediation without fully wiping the computer will likely miss one of the mechanisms. To make a complete remediation of the compromise, the defender either has to take the workstation or server out of service for a complete wipe and reinstallation or must catalog every method of persistence. Both methods take time away from other duties.

Digging Deeper

Our next indicator of malicious activity came from a suspicious instance of PowerShell reading base64-encoded code that spawned as a child process of the Windows Startup Application Initialization Process (wininit.exe).

This is odd because wininit.exe runs as the local SYSTEM account and usually spawns sensitive processes required for Windows startup; it should not spawn scripts or command shells. As we investigated further, we found that PowerShell called the Windows C# Compiler (csc.exe) and compiled code into a Dynamic-Link Library file that could be loaded into a process.

Analyzing Behavior

When working through security events and presented with odd behavior, analysts often ask questions, such as: Why would an adversary compile code locally on the victim’s system? The answer is that the tactic allows an adversary to potentially carry multiple payloads in a single download that can be compiled and executed as needed. Additionally, payloads transferred in a source code form and compiled later can evade network-based controls that look for telltale signs of Windows binary downloads.

As the chain of execution continued, more encoded PowerShell code spawned – this time exhibiting shared code from exploitation tools that allow PowerShell to import and execute shellcode. The network activity for this instance proved fascinating as we began to observe internal network connections to various systems in a sequential manner, all on port 445.

Developing a Hypothesis

This activity was consistent with PowerShell being used for Server Message Block (SMB) service scanning on the network. This is where lateral movement came into play, as this type of scanning also made headlines last year with the WannaCry ransomware outbreak. Our hypothesis at this point formed around the idea that this code would attempt further lateral movement using an EternalBlue exploit. After all, exploitation using EternalBlue matched some of the activity we’d already seen: lsass.exe spawning suspicious processes. While this scanning occurred, we also observed PowerShell reaching out to a cryptomining pool network address associated with the Monero cryptocurrency.

Finally, a network connection to a Tor exit node was made on port 9001, suggesting anonymized network traffic was also involved with this PowerShell instance.

We quickly reported this occurrence to our customer and they looked into the detection, responding to it in just a few minutes!

Closing the Loop with Threat Intelligence

After shipping a detection, we like to learn more about adversaries using these tactics so we can spot them in other customer environments and provide more context for remediation. Through some research, we discovered the network domains used in the persistence mechanisms were also used in previously documented campaigns to spread remote access trojans (RATs) that could mine Monero and infect their peers using EternalBlue SMB exploits. Thanks to Symantec and Juniper Networks for documenting this!

What’s the Big Deal?

We’ve said it before: cryptomining is usually a “small potatoes” issue until it is associated with a bigger threat. In this case, the adversary saw an opportunity to mine for a bit of extra money while spreading a RAT that would be accessible later for more commands. In this case, mining was a symptom of the larger issue: the system was vulnerable to exploits. As we’ve seen in other cases, mining was a low-friction method for the adversary to use the victim’s computing resources for profit. This stands in stark contrast to the previous trend of ransomware, which is highly disruptive to systems. This type of campaign is less disruptive and can continue for an infinite amount of time if defenders don’t notice.

Another key lesson is the “scattershot” of persistence mechanisms observed at the beginning of the detection. This tactic (Redundant Access for you ATT&CK geeks!) serves the purpose of maintaining access for an adversary while making remediation much harder for defenders. For many years in different circles, I’ve heard arguments for and against simply wiping computers to remove malware rather than performing targeted removal of the malware. Methods like this increase the time a defender needs to perform targeted remediation, and the defender runs the risk of missing a vital piece of the persistence puzzle. In cases with multiple persistence mechanisms, your organization needs to have a strategy to address the wipe vs. target dilemma.

How to Detect this Evil

Thankfully, there are a few strategies organizations can employ to detect campaigns similar to this one.

Target these 4 key behaviors:

1: Lsass.exe spawning a child process

There should be some detection of lsass.exe spawning child processes. In most configurations of Windows networks, this process should never spawn children. There are a handful of exceptions, namely specialty Active Directory or credential management tools. These are, however, so infrequent that we hardly see them across our customer base. After you’ve documented any exceptions in your organization, this strategy will help you find suspicious processes running with local SYSTEM privileges that may make administrative changes without any obstacles. This strategy is the least noisy of the ones suggested in this post, and should be the first that you implement.

2: The creation of persistence mechanisms

Next, use your technology of choice to monitor the creation of persistence mechanisms. This effort will involve more noise than the previous one, mostly because a lot of software frequently schedules automatic updates for itself or starts itself when the user logs on. You can get as in-depth as you want, creating approved software lists that you know should create Windows Registry autorun keys and startup folder entries. To start, look for quick wins by identifying unsigned processes, command shells, or scripts that write persistence mechanisms. Keep in mind that these types of processes are often carried out by legitimate software, but are often used by adversaries for evil as well.

3: Network connections to a cryptomining pool

Look for mining activity using a bit of threat intelligence. The two major strategies for identifying unauthorized cryptomining activity are to monitor resource usage and network activity. Monitoring resource usage can be difficult without an initial baseline of performance and can even be unreliable because cryptomining resource usage can be throttled as seen in the Tesla cryptojacking incident. A more reliable method involves monitoring network activity for hosts communicating with common cryptomining pool domains. Cryptominers eventually need to communicate to the external network for someone to make money, so you can watch for those beacons. If you’re not sure where to begin, start with pool addresses for Monero cryptocurrency. This currency itself is not bad, but we often see adversaries using it because it’s a largely private and untraceable cryptocurrency.

4: Network connections to Tor by unexpected processes

Consider merging the detection of anonymized network connections with threat intelligence by monitoring for the access of Tor exit nodes. Tor can be used to provide anonymous Internet browsing benefits, but can also be used to proxy attacks against your network. Determine if your organization has a legitimate need to use Tor for troubleshooting or to provide services. If not, obtain a list of Tor nodes and monitor for unexpected processes accessing Tor. Since Tor exit nodes are often public hosts used for legitimate public Internet purposes, consider narrowing this detection scope to only scripts, command shells, or privileged processes to reduce the potential for noise. This detection strategy is the noisiest one of these, and it should be used to provide additional context to already detected activity. It may lead you to users getting around acceptable use policies, but it could lead you to identify more malicious activity.

Can This Be Prevented?

Preventing this activity requires work and planning, but it’s not impossible. Here are 3 tips for prevention:

1: Use configuration management controls

Preventing persistence mechanisms can be difficult because these can be created without administrative credentials. Administrators can limit permissions to create Windows Scheduled Tasks, but Registry autorun keys and startup folder entries can be created with lower privileges. To prevent unauthorized autorun keys and startup folders, administrators can use configuration management controls such as Group Policy Objects (GPOs). When configured properly, GPOs can enable administrators to execute logon scripts or other settings that delete unauthorized autorun keys or startup entries and replace them with ones authorized for use.

2: Apply patches

You’ve heard me rant on the topic of patch management before, but only because it’s crucially important when securing systems. Applying patches in a timely manner makes life harder for adversaries because it keeps the number of exploits they can use down to a bare minimum. As I wrote about in a previous post, patch management doesn’t have to be a large-scale endeavor when you start. It can start small, with one network administrator checking for updates periodically, and expand from there.

3: Consider network segmentation

In the case of this detection, limiting SMB communication between systems would prevent lateral movement. Limiting SMB communication in this manner has additional benefits, as we’ve seen adversaries spread malware and try to collect data over SMB without using the exploit seen here. Segmentation involves a lot of cooperation with network and security personnel to produce a usable network that also prevents malicious activity from spreading across the network. To start, focus on the mission critical services for your network and work on segmenting those services so they can only be accessed in approved paths. For example, file shares that are mission critical should be hosted in a centralized location. An end user’s workstation should not need to consistently access services running on another workstation, so firewall rules can limit communication between them.

Conclusion

This detection shows a mixture of tried-and-true tactics with cryptomining as a way for adversaries to make some extra money while conducting their usual operations. With some proper planning and work, you can secure your network against these operations by detecting the behaviors of mining software as well as the behaviors of exploits that subvert Windows system processes. For prevention, move toward patch management and network segmentation practices that are sustainable for your organization. The best security practices are the ones you can maintain and iterate into the future!