Tinker Turla Soldier Spy

Automating TURLA with MITRE CALDERA

Following the latest round of MITRE Engenuity’s ATT&CK® Evaluations for Enterprise, the Center for Threat-Informed Defense (CTID) added two full emulation plans for the Russian state-sponsored threat actor Turla to the Adversary Emulation Library. MITRE Caldera™ can now run these emulation plans, which are focused on Turla’s usage of Carbon and Snake, to execute automated attacks modeled after the adversary’s known behaviors. This collaboration between two MITRE Engenuity cyber offerings enables a Caldera user to test defenses against real-world threats or to familiarize oneself with Turla’s commonly used Tactics, Techniques, and Procedures (TTPs).

What did we modify to enable Caldera to execute the Turla emulation plans?

The ATT&CK Evaluations Control Server was modified to forward any implant beacons to Caldera. Additionally, Caldera was modified to be able to receive these forwarded implant beacons and display the implants in Caldera’s Agents tab.

Do we use a Caldera agent, custom implants, or both?

In previous ports, the Caldera Sandcat agent replaced implants that were used in the original red team scenario. In contrast, the Sandcat agent in this port is used to replace the red team operator, and Caldera and the ATT&CK Evaluations Control Server REST APIs were adapted to use the original implants developed for Round 5 of ATT&CK Evaluations for Enterprise. The Sandcat agent runs on the adversary box and executes the actions that the red team operator would run, thereby enabling automated red team operations. These red team actions include both “user activity” (such as logging in and out of victim machines or downloading and running malicious executables) and commands to task the implants through the ATT&CK Evaluations Control Server.

This new approach of using the Sandcat agent represents a dramatic improvement compared to earlier ports, because the adversary activity executed by the adversary profile run in Caldera is now almost identical to the original red team scenario executed for Round 5 of ATT&CK Evaluations for Enterprise. Therefore, defense evasion, among other behavioral implementations that are largely tied to the adversary’s implants, is maintained in this new approach.

How can Caldera task an implant?

Follow along in Figure 1 to understand what happens when this command is sent from Caldera to task an implant:

./evalsC2client.py –set-and-complete-task 9b5ef515 ‘{“id”: 0, “cmd”: “whoami”}’ –task-wait-timeout 60

1. Caldera Server sends the above command to the Sandcat agent.
2. Sandcat agent executes the command by tasking evalsc2client.
3. Evalsc2client sends the command to the ATT&CK Evaluations Control Server.
4. The Control Server tasks the implant to execute the whoami
5. The implant sends output from whoami back to the Control Server.
6. The Control Server forwards the whoami output back to the Caldera Server.
7. The result from the whoami command is shown in the Caldera Server GUI.

How can we prevent Caldera from tasking an inactive implant?

Throughout developing the scenario port to Caldera, the question remained: How could we prevent Caldera from executing an ability if, for some reason, the implant tasked in that ability was not actively beaconing in?

Generally, it’s only possible to task a Caldera agent which is alive and actively checking in with Caldera. However, due to the integration between the evalsc2client.py and the Caldera Emu plugin in this port, the user is effectively tasking the Sandcat agent to task evalsc2client.py to task an implant through the Control Server, which makes it possible to task an implant that is not active.

To solve this problem, we implemented a new Caldera Requirement. A fact was created for each implant ID, and these facts were used as requirements in the relevant abilities.

For example, in Figure 2, first.epic.id is defined as 218780a0-870e-480e-b2c5dc.

In Figure 3, the first.epic.id fact is used as a requirement in an ability tasking the first Epic implant, with ID 218780a0-870e-480e-b2c5dc. This means that the ability will only run if the fact requirement is fulfilled, meaning that the agent with ID 218780a0-870e-480e-b2c5dc must be actively beaconing in to Caldera for the ability to execute.

Figure 4 shows the check_registered.py requirements file. This file shows the inner workings of the fact requirement that allows an ability to run only if the given implant ID is shown in the list of active Caldera agents. This ensures that an ability will only run if the agent tasked in that ability is actively beaconing in.

Additionally, a separate Caldera requirement was implemented for the LightNeuron implant since LightNeuron will not heartbeat to the ATT&CK Evaluations Control Server and will only return communications and output when it receives a task. The LightNeuron session is only registered on initial startup of the Control Server, which is then forwarded to Caldera. Because no further heartbeats are received, Caldera then considers LightNeuron to be a dead agent. This new requirement will allow an ability to execute and task LightNeuron as long as the LightNeuron implant ID is listed in the Caldera’s Agents tab, even if it listed as a dead and untrusted agent.

Go ahead and try out the new Turla Carbon and Snake adversaries! If you have any questions or comments, join the discussion on the Caldera Slack channel.

© 2023 MITRE Engenuity, LLC. Approved for Public Release. Document number AT0056.