December 4, 2019 Detection and response
Tony Lambert Brian Donohue

Detection déjà vu: a tale of two incident response engagements

After a seemingly routine incident response engagement, Red Canary’s Cyber Incident Response Team (CIRT) was surprised to see similar indicators and activity reemerge in the same environment months later. Here’s what we learned about how adversaries respond to responders and get back in the door.

At the risk of oversimplifying, our customer environments can be organized into two general groups: those in which we know that a breach has occurred and those in which we have no reason to believe that a breach has occurred. The former group typically consists of incident response engagements with one of our partners—like Kroll for example.

Over the course of two incident response engagements in one environment this year, we were able to track what appears to be a single threat actor and gain interesting insights into the ways that determined adversaries conduct reconnaissance, gain access, and persist.

Engagement One

When Kroll called us in to work an incident response in the first half of this year, we found a lot of fairly ordinary activity. The adversary was leveraging obfuscated PowerShell commands that, upon inspection, appeared to represent instances of an adversary using PowerShell Empire for fileless execution. Numerous artifacts supported this theory, including command-line references to news.php, system.net credential cache, and defined user-agents.

The adversary also stored PowerShell scripts in Windows Registry Keys, which would execute in order to persist in the environment, a technique that made detection pretty straightforward. Another persistence mechanism involved Windows Management Instrumentation (WMI).

However, while some of the activity was routine and some of it was detectable, there was ample evidence of seriously malicious intent. We found an open source alternative of PsExec called “RemCom” on the system, a tool that’s simultaneously associated with sophisticated attack groups and administrators alike. It was installed on an Active Directory domain controller, which is much less likely to be legitimate. The domain controller access and persistence mechanisms suggest that the adversary had some level of administrative access to the network. Furthermore, the investigation revealed that the adversary had conducted some pretty aggressive reconnaissance activity emanating from a compromised web server in an attempt to identify administrators on the domain.

Oddly, the adversary in question downloaded software from what appears to be a legitimate site belonging to a business located in Tbilisi, Georgia. On at least one occasion, we observed the presumably compromised server trying to use PowerShell to execute a payload in the environment. The payload seemed to be associated with a variety of remote access trojans (RAT). The external server also made attempts to map the victim’s network using legitimate credentials and scanning various ports on the local subnet.

 

After we identified all of this activity, our incident response partner worked with the customer to remove persistence mechanisms and clean up the environment. However, months later, we found ourselves working another incident response engagement in the same environment.

Engagement Two

We immediately recognized activity and indicators that were very similar to what we had found in the previous engagement. However, the adversary’s tactics seemed to be escalating; our partner had already removed a compiled PowerShell Empire backdoor. One indicator provided us with a telling lead: an IP address hosting Empire potentially tying this campaign to one documented by Zscaler.

During the course of our investigation and detection work, we observed regsrv32.exe executing a dynamic link library (DLL) signed by a non-Microsoft entity and making a network connection. The IP addresses associated with these DLLs suggest that the infrastructure being used in the attack is fairly new (set up in the last couple months). We also discovered that this infrastructure had been recently used to host PowerShell Empire. All of the compiled payloads that featured prominently in the environment didn’t seem to have any track record on VirusTotal or other public malware repositories.

The fresh infrastructure and payloads suggested that the adversary was very intentionally choosing their targets and trying to go unnoticed. During the course of research we leveraged VirusTotal Intelligence to perform additional searches. When we decided to pivot and query for the DLL’s suspicious code signer and its import hash, we found only one sample that had been uploaded to VirusTotal, from a Russian address. While this was far from definitive, it matched our expectations, as the documentation we saw from Zscaler describes a malicious document that contains Russian words in metadata. To muddy the water further, all of the infrastructure used to run the attacks was widely dispersed in terms of geography.

Other interesting activity involved extensible stylesheet language (XSL) document execution using wmic.exe. Yet again, we saw another instance of RemCom on another domain controller, suggesting that the adversary had access to two-or-more domain controllers and was using RemCom to access other systems.

Outside of some strange scheduled tasks and AutoIT activity, we observed a fairly novel use of the Windows defragment service making a network connection. It appears as if the adversary figured out how to inject a malicious PowerShell Empire DLL into the Windows Optimize Drives service.

From there, unmanaged PowerShell code (i.e., PowerShell scripts that execute without launching powershell.exe) executed commands to communicate with command-and-control (C2) systems. Network indicators associated with this activity pointed to one of the IP addresses that had hosted PowerShell Empire previously. The adversary may have stopped using easily detected forms of PowerShell (i.e., scripts and code in command lines) and started using less obvious ones (i.e., unmanaged PowerShell compiled in DLL form).

For Red Canary’s CIRT, this is a case study in how an adversary escalates their ability to attack and persist within systems once an incident response begins to remove their foothold.

Hunting for this Threat

To look for this threat or similar ones in your environment, these analytics should give you a head start:

Executing PowerShell from Decoded Base64 (medium confidence)
Process is ‘powershell.exe’ AND
Command line includes ‘base64’ AND
Command line includes ‘iex’

PHP Executing OS Commands (medium confidence)
Parent process is ‘php.exe’ OR ‘php-cgi.exe’ AND
Process is ‘cmd.exe’
Tune out commands required for normal web application use; this is different per organization and application.

Windows IIS Worker Executing OS Commands (medium confidence)
Parent process is ‘w3wp.exe’ AND
Process is ‘cmd.exe’
Tune out commands required for normal web application use; this is different per organization and application.

Domain Administrator Enumeration via Net.exe (high confidence)
Process is ‘net.exe’ OR ‘net1.exe` AND
Command line includes ‘Domain Admin’

PowerShell Downloading Code for Execution (medium confidence)
Process is ‘powershell.exe’ AND
Command line includes ‘downloadstring’ AND
Command line includes ‘iex’

Wmic Remote Stylesheet Execution (high confidence)
Process is ‘wmic.exe’ AND
Command line includes ‘/format:’ AND
Has network connection

Use of Windows Optimize Drives Service for C2 (high confidence)
Process is ‘svchost.exe’ AND
Command line includes ‘defragsvc’ AND
Has network connection

 

Detecting attacks leveraging the .NET Framework

 

Privilege escalation revisited: webinar highlights

 

Context matters: harnessing creativity to triage security alerts

 

Detecting SharePoint attacks via worker process activity

Subscribe to our blog