Emulating OilRig with Caldera™’s Emu Plugin
Authors: Kayla Kraines & Melanie Chan
In case you missed it, check out our previous blog post about the Caldera™ team’s collaboration with MITRE ATT&CK Evaluations™ to allow users to run automated attacks modeled after the OilRig adversary. These automated attacks were built using the Caldera Emu plugin. The Emu plugin converts adversary emulation plans from the Center for Threat Informed Defense (CTID) library into adversary profiles, which are represented by yaml files that are loaded into Caldera. Read on to learn more about the process!
Our Development Process
- Creating the file header for the yaml file
The oilrig.yaml file must start with the emulation plan details in the following format:
2. Breaking the emulation plan into individual abilities
Our next step was to review the ATT&CK Evaluations Managed Services Round 1: OilRig Emulation Plan and determine how to break it down into individual abilities. These abilities would need to be written in yaml format, similar to a regular Caldera ability. (Read more about Caldera’s ability format here.)
Each ability will be structured based on the fields shown in Table 1.
This structure was used to create each ability (of which there are over 40!) in the oilrig.yaml file.
Figure 2 shows an example of one of the abilities in the OilRig Caldera yaml file. The format follows the above template, but it has been customized to run cscript /nologo computername.vbs on the Windows target using the command prompt. This ability also uses a payload called computername.vbs.
Some of the abilities are meant to run on the Windows agent, while some are meant to run on the Kali Linux agent. So, how can we specify which agent should run each ability? On to the next step… creating the custom planner!
3. Create the custom planner
In order to set up the adversary to run each ability on a pre-determined agent, a custom planner was created under the planners folder and called oilrig_planner.yml. This planner was based on the group_filtered_planner.py module, which had been previously written in the emu plugin for the Wizard Spider and Sandworm Caldera ports.
The oilrig_planner.yml contains several key pieces of information:
- Unique ID representing the OilRig Planner (in UUID format)
- Name of the planner (in this case, “OilRig Planner”)
- Brief description explaining the purpose of this planner
- Path to the planner module (in this case, “plugins.emu.app.group_filtered_planner”)
- A list of UUIDs for each ability in the OilRig adversary. Following each ability’s UUID is the agent group representing either the Windows agent or Kali Linux agent. These UUIDs were copied & pasted directly from the oilrig.yaml file — it’s important that the UUIDs between the two files match exactly.
A snippet of the OilRig planner is shown in Figure 3.
Deviations from the Original Scenario
When writing the abilities for the oilrig.yaml file, we encountered technical limitations that prevented us from creating a port that mimicked the emulation plan down to the last detail. Therefore, we chose to make some modifications to the scenario. These modifications have been documented in the README file that accompanies the port.
Here are some of the more significant modifications that we needed to make:
- Attack Vector: The original scenario used a Microsoft Word document delivered via email as the attack vector. When the Word document was opened, a malicious VBA macro ran automatically and deployed the SideTwist implant. However, the Caldera server is not capable of communicating directly with the SideTwist implant. Additionally, due to the complexity of automatically executing these manual interactions with Microsoft Outlook and Word, we decided to skip the Word document and substitute a manually deployed Caldera Sandcat agent for the SideTwist implant.
- Payloads: In the Caldera port, required files are transferred as payloads to the target via the Caldera C2 channel. Caldera payloads are downloaded to the agent’s working directory. Payloads are deleted by default when they are finished being used, which reduces the amount of cleanup needed.
- Combined Steps: In the interest of readability, some steps were combined into one ability in the port.
- Curl Commands: Curl commands needed to have the -s flag added to them to activate “silent” mode. This restricts the progress meter from displaying to allow the Caldera server to properly capture terminal output. The -s flag will also restrict error messages from appearing.
- Special Characters in Passwords: Because Caldera escapes special characters in commands, a bug was identified when attempting to use the original passwords for the users Saka and Gosta, both of which contained the $ symbol. The password for Saka was changed from $ceKa#zU$Uc4^9yZ to ceKa#zUUc4^9yZ, and the password for Gosta was changed from d0ntGoCH4$ingW8trfalls to d0ntGoCH4ingW8trfalls. Fixing this bug is on the Caldera team’s to do list in the future.
- Background Processes: Several commands (of type proc) used exec-background to run as background processes. Click here for more information about proc.
- RDP Session: In the original scenario, there is a manually created RDP session from the Kali Linux virtual machine to 10.1.0.6, which is then used to execute commands on the host. To maintain 100% automation for the port, we chose to use xdotool to automate the RDP session to 10.1.0.6 and automate execution of the manual commands. Xdotool can simulate mouse clicks, mouse movements, and key presses to control the entire RDP session as if it was being done in real time by a user.
Let us know if you try out the new OilRig adversary! And if you see any room for improvements to the OilRig adversary or to the Emu plugin, please create a PR! We’d love to see your work!
Resources
©2023 The MITRE Corporation. All rights reserved.
Approved for public release. Distribution unlimited 22–02104–14.
