Crude OilRig: Drilling into MITRE’s Managed Service Evaluations

Background on the test

We’re going to spend most of this blog explaining how our intel analysts, detection engineers, threat researchers, and incident handlers reacted to the emulation, and showing you what this looked like from the perspective of the customer, in this case MITRE. However, before we get to the fun stuff, we need to take some time to set the stage.

What did MITRE do?

Generally speaking, the Managed Services ATT&CK eval was a closed book test for which we instrumented a specially configured environment (more on this in a moment) for the MITRE Engenuity team. The MITRE folks then ran a 10-step adversary emulation, testing our ability to observe, detect, and respond to the threats they were emulating. This test was fundamentally different from MITRE’s previous Enterprise and ICS Evaluations because MITRE did not announce the adversary they would emulate nor the techniques they would leverage in advance.

MITRE Engenuity was basically a Red Canary customer for one week. They ran a red team engagement against Red Canary in an environment that was intentionally configured to allow the emulation to run unencumbered. The point, after all, was to test detection, not prevention.

In this case, the MITRE Engenuity Team chose to emulate a threat actor commonly known as OilRig. OilRig is a so-called advanced persistent threat (APT), thought to be working in the interest (or at the behest) of the Iranian government. The group is well known for a series of attacks targeting public, private, and civil society organizations in Saudi Arabia, but OilRig remains active and has been accused of targeting a wide array of organizations in Gulf States and more broadly around the Middle East.

In other words, our friends at MITRE pretended to be our foes at OilRig.

Due to the test’s requirements, all prevention technology and features provided by our EDR partners were turned off. Red Canary’s Automate feature was enabled and set to report the remediation actions it would have taken based on threats published during the evaluation.

So… how’d we do?!

This blog post makes no effort to qualitatively assess Red Canary or anyone else’s performance in MITRE’s Managed Services Evaluation. Instead, we want to show you everything we observed and detected, independent from MITRE’s assessment of our performance. Our goal is to tell the whole story of MITRE’s emulation like we would for any other adversary, as if we’re writing a post-incident report. In order to do that, though, we need to provide some quantitative information about our performance in the test.

The evaluation consisted of 10 steps, each of which included multiple substeps. In all, we detected 82.9 percent of the substeps. We could nitpick endlessly about what counted as a detection, why certain substeps might not warrant detecting at all, and whether all of the substeps should’ve been weighted equally, but that’s really beside the point. In the spirit of transparency, we’re going to highlight the things we missed right alongside the things we detected. While most of the misses were discovery techniques that might not warrant a detection under normal circumstances, we admittedly and undeniably missed one important substep.

If you’re interested in learning how to interpret the results of the test, you’ll want to read our executive briefing.

Dissecting MITRE’s Managed Service Evaluations

We’ll start with a high-level overview of everything that happened—mapped to MITRE’s official 10-step evaluation—before examining everything we observed and detected in depth.

TL:DR

Click on each step to navigate to a more detailed description of what we saw for each event.

Step 1: A user downloaded a malicious document on a workstation called theblock (10.1.0.5), establishing command and control (C2) and persistence.

Step 2: The adversary performed various discovery commands for situational awareness and to enable follow-on targeting on theblock.

Step 3: The adversary conducted credential theft on theblock and exfiltrated those credentials to an adversary-controlled C2.

Step 4: The adversary downloaded a web shell to theblock and copied the webshell to an Exchange server, waterfalls (10.1.0.6), leveraging stolen credentials from step 3.

Step 5: The adversary leveraged the webshell on waterfalls to execute various discovery commands for situational awareness.

Step 6: The adversary accessed the web shell implanted on waterfalls to drop and execute credential theft tooling and exfiltrate stolen credentials back to adversary-controlled C2.

Step 7: The adversary moved laterally via port forwarding on theblock to access waterfalls via RDP.

Step 8: The adversary performed a pass-the-hash attack to gain a shell in the context of another user, a SQL administrator, on the waterfalls Exchange server, then used this access to move laterally to a SQL server, endofroad1.

Step 9: The adversary discovered and collected SQL server database backups and exfiltrated them directly over the Exchange Web Services API.

Step 10: The adversary removed any file indicators on endofroad1.

Test concludes! 

Step 2

Discovery

Too many techniques to list

SystemFailureReporter.exe initiated a sequence of discovery actions beginning at 16:05 UTC and ending at 16:10 UTC. The activity included the following commands:

The last command, nslookup WATERFALLS, is a harbinger of what’s to come, but before we get into the next phase of this attack, we need a brief sidebar.

Side note: Detecting discovery actions

We observed the execution of SystemFailureReporter.exe less than two hours (14:05 UTC) after Gosta opened the malicious document that initiated this incident. Another two hours passed before we started to observe the aggressive discovery actions detailed above (16:05 UTC).

If GGMS Overview.doc had slipped past the initial preventive controls and managed to execute its hidden VBA macro, Red Canary would have detected the above discovery actions and initiated response controls to isolate the affected endpoint right then—less than four hours after Gosta logged in and well before any credential theft, lateral movement, and exfiltration activity.

Step 3

Command and Control

Ingress Tool Transfer

At 18:03 UTC, SystemFailureReporter.exe ran via a scheduled task and wrote another binary to disk, b.exe.

Credential Access

Windows Credential Manager

Upon analysis, our intelligence and research teams determined that the b.exe binary was emulating a known malware strain called VALUEVAULT, all but confirming our suspicion that MITRE was in fact emulating OilRig.

Side note: Identifying OilRig!

FireEye first reported on VALUEVAULT while investigating social media phishing campaigns in 2019, and the malware is now widely associated with OilRig. VALUEVAULT is known to extract credentials from the Windows Vault and create a SQLITE database file in the AppData\Roaming directory named fsociety.dat to store the stolen credentials.

This is precisely what happened in the evaluation: b.exe dumped the windows credentials stored on theblock.boom.box into a SQLite3 database called fsociety.dat.

At this point, our Intelligence Team was almost certain that MITRE was emulating OilRig. In a real-world scenario, there would remain some doubt about this attribution because any number of adversaries could have leveraged VALUEVAULT, written credentials to “fsociety.dat, and mimicked other indicators. However, our assessment was made easier by knowing that MITRE would be emulating a well known adversary.

Exfiltration

Exfiltration Over C2 Channel

At this point, the adversary exfiltrated fsociety.dat from theblock.boom.box to their C2 server (192.168.0.4) via an HTTP post request.

Side note: We missed this!

This is probably our most glaring omission. We simply did not observe the adversary passing the fsociety.dat file back to their C2 infrastructure, which was an important part of the intrusion. Many C2 frameworks offer adversaries the ability manipulate packet structure and effectively hide the contents of their communications during exfiltration. We were able to identify requests that likely contained the exfiltration, but complete visibility into network telemetry is a known short-coming of most EDR products. As we do with any misses during testing, we’re considering how we could improve our detection coverage to catch similar behavior in the future. Further, we support the ingestion of Network Security telemetry and alerts from products like firewalls, network detection and response, and DNS records, which would have proven helpful in fully observing this substep.

Step 4

Command and Control, Lateral Movement

Ingress Tool Transfer, Lateral Tool Transfer

At 19:33 UTC, SystemFailureReporter.exe wrote contact.aspx to disk. Shortly thereafter (19:43 UTC), it copied that contact.aspx to another endpoint (technically an Exchange server) waterfalls.boom.box, which is the same endpoint upon which the adversary performed a DNS lookup earlier as part of their discovery.

Persistence

Web Shell

This web shell provided the adversary the ability to write, download, and delete files from disk, as well as execute binaries that are present on the infected endpoint. The previous image illustrated telemetry from theblock.boom.box copying an Active Server Page Extended (.aspx) file to waterfalls.boom.box. The following image shows the telemetry associated with that action from the perspective of waterfalls.boom.box:

Defense Evasion

Hidden Files and Directories, File Deletion

Meanwhile, back on theblock.boom.box at 19:48 UTC, the adversary deleted contact.aspx from the endpoint and leveraged the attrib +h command to hide the .aspx file from the typical folder view and from ordinary directory listings on waterfalls.boom.box.

Step 5

Persistence

Web Shell

On July 14 at 17:30 UTC, the adversary then leveraged the web shell to launch the Command Processor (cmd.exe), which ran as SYSTEM (this has important implications when we get to the Mimikatz activity later). It proceeded to run multiple commands consistent with post-exploitation, which we will highlight in the coming sections. The following graphic shows w3wp.exe spawning the command shell:

Discovery

Multiple Discovery techniques

In the space of a few minutes, the adversary used the newly spawned command shell to gather information about system network configuration, enumerate a list of active network connections, and see who had system access on the host via the ipconfig, netstat, and whoami commands. The following image shows telemetry associated with the ipconfig and netstat commands:

Step 6

Command and Control, Credential Access

Ingress Tool Transfer

Leveraging the web shell, the adversary then wrote a binary named m64.exe to disk at 18:33 UTC on waterfalls.boom.box. This binary was in fact a renamed version of the credential-stealing tool Mimikatz. As we noted earlier, the command shell that spawned Mimikatz ran with system-level privileges, which granted Mimikatz the privilege level required to perform the actions described in the next section.

LSASS Memory

Immediately thereafter, the adversary leveraged Mimikatz to open a handle into the Local Security Authority Subsystem Service (lsass.exe) and used the sekurlsa::logonPasswords command to extract credentials from it, writing them to a file called 01.txt, which potentially contained hashes for the following users:

• gosta
• tous
• Mariam
• vendor_domain_admin
• evals_domain_admin

Exfiltration Over C2 Channel

The web shell then ran its HandlePOSTFileDownloadServer() function to download files off disk, very likely in an effort to exfiltrate credentials from 01.txt.

Defense Evasion

File Deletion

At 18:37, the adversary ran commands intended to delete m64.exe and 01.txt from waterfalls.boom.box.

Side note: Detecting Mimikatz

We’ve developed detection analytics for different aspects of Mimikatz, at least three of which are on display in the above image. One option involves looking for processes that obtain a handle into lsass.exe. Alternatively, you can look for module loads of dynamic link libraries like samlib.dll or vaultcli.dll, which you can see in the following image:

A third option is to detect specific command-line parameters that are associated with Mimikatz. In this case, those commands were: privilege::debug and sekurlsa::logonpasswords.

Step 7

Command and Control

Ingress Tool Transfer

Back on theblock.boom.box on July 15 at 12:06 UTC, SystemFailureReporter.exe wrote a copy of plink.exe, the PuTTY command-line interface used for SSH tunneling.

Protocol Tunneling

At 12:11 UTC, the adversary leveraged plink.exe to create an SSH tunnel and make RDP connections to their adversary-controlled machine, attempting to gain direct RDP access on waterfalls.boom.box.

Lateral Movement, Defense Evasion

Remote Desktop Protocol, Domain Accounts

At 12:13 UTC, the adversary leveraged the stolen Gosta credentials to open an RDP session on waterfalls.boom.box using the established SSH tunnel via plink.exe.

Step 8

Persistence, Command and Control

Web Shell, Ingress Tool Transfer

Starting at 12:15 UTC, the adversary leveraged the web shell to write several files to disk on waterfalls.boom.box:

• ps.exe, a renamed version of the Sysinternals tool
• mom64.exe, another renamed version of Mimikatz
• nt.dat, an email-based C2 tool

The following images show the adversary writing each of these tools to disk.

PsExec

Nt.dat

Mimikatz

Side note: Detecting renamed instances of PsExec

As we’ve written about extensively, you can often detect renamed tools by looking for the execution of binaries where the binary’s presented filename is different from the internal filename listed in its binary metadata. In this case, the file was called ps.exe, but the file’s internal binary name was “PsExec.”

Defense Evasion, Execution, Lateral Movement

Pass the Hash

The adversary then abused Mimikatzʼs pass-the-hash functionality and a previously extracted NTLM hash to switch the user’s context to the user “tous” at 12:18 UTC. Importantly, “Tous” is a member of the SQL Admins group, which the adversary discovered in a previous step.

Windows Command Shell

Seconds later, mom64.exe (aka Mimikatz) opened an interactive command shell, as shown in the following image:

Lateral Tool Transfer, SMB/Windows Admin Shares, Service Execution

At 12:20 UTC, the adversary—now operating in the context of the user “tous”—leveraged PsExec to execute commands on a new host, a SQL server called endofroad1.boom.box, before moving nt.dat to the new host.

Step 9

Discovery

File and Directory Discovery

Next, the adversary performed discovery of backup files on the SQL server endofroad1.boom.box.

Side note: We missed this!

We failed to include these actions in our timeline or report them to the team at MITRE. As with all misses, we’re considering how we could better detect similar behaviors in the future.

Step 10

Collection, Defense Evasion

Local Data Staging, Match Legitimate Name or Location

At 12:23 UTC, the adversary used PsExec to spawn a command shell and create a folder named “Vmware” and a file named vmware.exe on endofroad1.boom.box.

An analysis of vmware.exe revealed that the binary was actually a renamed instance of the email C2 tool from earlier, nt.dat. The adversary moved that nt.dat file into the Vmware folder and renamed it.

Collection, Exfiltration, Defense Evasion

Data From Local System, Data Transfer Size Limits, Exfiltration Over Unencrypted Non-C2 Protocol, Obfuscated Files or Information

At 12:26 UTC, the adversary leveraged nt.dat (masquerading as vmware.exe) to exfiltrate a steganographic .bmp file containing the contents of a SQL database backup. Using credentials for the user Gosta, the adversary sent an email via Microsoft Exchangeʼs API and then removed their custom tooling from disk. In the process, the adversary resized some of the data to evade detection.

Defense Evasion

Indicator Removal

Last but certainly not least, the adversary cleaned up their tracks by removing vmware.exe and the Vmware folder from endofroad1.boom.box at 12:26 UTC. At 12:31 the adversary removed the following files from waterfalls.boom.box:

• mom64.exe
• nt.dat
• ps.exe
• b.exe
• fsociety.dat
• plink.exe
• update.xml

Side note: We missed a pair of removals

We got partial credit on this step for reporting half of the removed files to MITRE. We failed to explicitly report the deletion of the VMware directory and the deletion of mom64.exe, nt.dat, and ps.exe.