Authors: Samir Boussarhane, Rachel Murphy, Elijah Saloma, and Jake Dickinson

Access to physical operational technology (OT) hardware remains a significant barrier to hands-on cybersecurity education. Without building automation controllers or HVAC equipment, it can be difficult to understand how industrial control protocols operate, how devices exchange data, and how adversary actions translate into physical process effects.

Heating, Ventilation, and Air Conditioning (HVAC) systems regulate temperature, airflow, and environmental conditions in commercial and industrial buildings. These systems are typically managed by Building Automation Systems (BAS) that use industrial control protocols such as BACnet to monitor sensors and adjust equipment including chillers and fans. Because HVAC systems directly affect physical processes, energy usage, and occupant safety, they are considered operational technology (OT).

Cyber incidents have demonstrated the real-world relevance of building systems. The 2013 Target breach began with compromised credentials from an HVAC contractor, allowing attackers to pivot into Target’s corporate network and ultimately exfiltrate millions of payment card records. Public reporting and cyber threat intelligence analysis describe how the attackers initially gained access through the HVAC vendor (Target Hackers Broke In Via HVAC Company).

Beyond initial access risks, disruption to HVAC systems can have direct operational consequences. In data centers and healthcare environments, improper temperature control can damage equipment or disrupt critical services. Manipulation of fan speeds or setpoints can increase energy consumption, reduce equipment lifespan, or create unsafe environmental conditions. Even simple changes to control values can demonstrate how cyber actions translate directly into physical process impact.

Recognizing the growing intersection of cyber threats and building automation systems, HVACSim was developed to provide defenders with a safe and accessible environment to understand and mitigate these risks before they affect real-world infrastructure.

HVACSim was created by University of Hawaii at Manoa students Elijah Saloma and Jake Dickinson as part of a capstone project, in collaboration with the MITRE Caldera for OT team. The simulator provides a software-only model of a server room HVAC controller and integrates directly with Caldera for OT, enabling hands-on adversary emulation without requiring physical industrial hardware.

HVACSim Overview

HVACSim is a simplified, educational simulator designed for training and experimentation. It does not attempt to replicate vendor-specific implementations or serve as a high-fidelity engineering model. Instead, it focuses on illustrating how BACnet protocol interactions affect a temperature control process.

The simulator models a server room with a temperature control loop that includes:

• Ambient and internal heat sources
• Airflow-based cooling
• A proportional-integral (PI) controlled chiller
• Sensor noise and actuator lag

Users interact with the system through BACnet ReadProperty and WriteProperty requests. Writable values — such as the temperature setpoint, fan speeds, and emergency stop — directly influence the simulated physical process.

Virtual Equipment Architecture

The simulator consists of two components: a BACnet/IP server and a matplotlib-based Human Machine Interface (HMI). The server listens for and responds to BACnet requests over UDP. The HMI reads values from BACnet objects and updates its display with temperature trends, chiller load, and fan speeds. When controls are adjusted in the HMI, the object values are updated directly in memory. A BACnet client, such as those operated through Caldera for OT, can send write requests over UDP to modify these same objects, allowing adversaries to observe how their protocol actions change process behavior through the HMI display and network traffic.

Adversary Emulation with Caldera for OT

HVACSim responds to common BACnet protocol requests. The simulator can be used with Caldera for OT abilities discovery, collection, and impact tactics. Discovery can be used to identify devices and their objects. Collection can be used to read process values such as temperature, setpoint, and chiller load. Process impact can be used to change control values and observe the results on the HMI.

Adversary Scenarios

One learning scenario is manipulating the temperature setpoint and fan speeds through BACnet WriteProperty commands. The system starts at 73.4°F with both fans running at 30%. When an attacker writes a lower setpoint to analog value address 0 — such as changing it from 73°F down to 64°F — the chiller load increases to reach the new target and the temperature drops. Figure 3 shows the system response after lowering the temperature setpoint.

When intake and exhaust fan speeds (analog value addresses 1 and 2) are set to different extremes — like setting intake to 100% but exhaust to 0% — the airflow becomes unbalanced and the temperature rises. Figure 4 shows the system behavior when intake and exhaust fan speeds are set to different extremes.

The emergency stop control can also be activated at any time to stop both the chiller and fans. Figure 5 shows the system state after the emergency stop is activated.

BACnet Simulation

HVACSim exposes a small set of BACnet objects that can be accessed using standard ReadProperty and WriteProperty requests. Figure 6 shows an example of reading the current temperature value using a BACnet ReadProperty ability in Caldera for OT. Writable objects, such as the temperature setpoint and fan speed values, can be modified using WriteProperty requests, with updated values reflected in the simulator and displayed through the HMI. This allows users to observe how BACnet reads and writes correspond to changes in exposed object values during simulation.

Analog Outputs:

Instance 0: Temperature set point (target temperature in °C)

Instance 1: Intake fan speed percentage (0–100%)

Instance 2: Exhaust fan speed percentage (0–100%)

Binary Outputs:

Instance 0: Emergency Stop (0 = off, 1 = on)

Analog Inputs:

Instance 0: Current Temperature

Instance 1: Chiller Speed Percentage

Getting Started

HVACSim is designed to be lightweight and accessible while still modeling realistic cyber–physical interactions. The simulator runs entirely in software and requires no specialized hardware. It supports Python 3.10+ and runs on Linux, macOS, or Windows. Core dependencies include matplotlib for the HMI and bacpypes for BACnet/IP communications.

When launched, HVACSim starts a BACnet/IP device over UDP and opens an interactive HMI for observing temperature trends, chiller behavior, and airflow changes in real time. Users can configure device identifiers and network parameters through the provided BACpypes.ini file. Linux systems may require additional GUI packages (such as python3-tk) to support the matplotlib interface.

For adversary emulation workflows, HVACSim can be paired with MITRE Caldera and its BACnet plugin. Once running, Caldera agents can perform BACnet ReadProperty and WriteProperty actions against the simulator to exercise discovery, collection, and impact techniques in a controlled environment.

By lowering the barrier to entry for building automation security research, HVACSim enables defenders, educators, and students to safely explore how protocol-level actions translate into physical process behavior — without requiring access to live industrial infrastructure. Contributions and feedback are welcome as the community continues expanding practical OT cybersecurity training resources.

Resources and Code:

• Caldera for OT plugin repository
• HVACSim
• Caldera GitHub
• Caldera Homepage

Community and Support:

• Discord
• LinkedIn
• Caldera Documentation
• Caldera YouTube

©2026 The MITRE Corporation. All rights reserved.

Approved for public release. Distribution unlimited PR_26–0182.

Author: Samir Boussarhane

Access to testable physical hardware is a barrier to entry for operational technology (OT) security education. Without access to programmable logic controllers (PLCs) or OT lab equipment, it can be harder to learn OT protocols, explore how control systems exchange data, and understand how an adversary can impact a critical process. The release of the Wildcat Dam simulator helped lower that barrier by introducing an open-source software-based Modbus simulation that can be used as a virtual OT protocol sandbox. Aloha Water Treatment Plant builds upon that work by adding a simple water treatment process, supporting both Modbus and BACnet control protocols, and includes a web-based human-machine interface (HMI).

Aloha!

Aloha Water Treatment Plant is a software-based OT simulator designed as a low-cost resource for education. The simulator is not intended to be a full-fidelity realistic environment mimicking vendor-specific behavior. It models a basic water storage tank, including flows, modes, and alarms, to illustrate how protocol interactions interact with and impact a controlled process.

Virtual OT Equipment

The simulator has two parts: a PLC-style protocol server and a web-based HMI. The PLC server responds to Modbus or BACnet requests over TCP/IP. The HMI continuously reads values from the PLC and updates its display. When the user clicks “Controls” on the HMI, it performs protocol writes back to the PLC. This traffic can be observed on the network with packet capture tools, which helps connect protocol activity to process behavior. The diagram in Figure 2 illustrates how these components interact.

Adversary Emulation with Caldera for OT

Aloha Water Treatment Plant responds to common OT protocol requests, making it compatible with Caldera for OT. The simulator supports Caldera for OT BACnet and Modbus plugins’ abilities across discovery, collection, impair process control, and impact tactics. Discovery techniques can be used to identify devices for interaction. Collection techniques can be used to read process values such as tank level and flow. Process impact techniques can be used to change control values and observe the results.

Adversary Scenarios

One learning scenario is switching the system into manual mode and adjusting inflow and outflow rates through Modbus or BACnet writes. In AUTO mode, the control process adjusts inflow and outflow automatically to stay around 65% full. When inflow is set higher than outflow, the tank level increases and can reach an overflow condition. When outflow is set higher than inflow, the tank level drops and can reach a low-level condition. When thresholds are crossed, alarms become visible in the HMI.

Another scenario involves the emergency stop. Setting the emergency stop through the protocol halts the process and changes the system state shown in the HMI. In both cases, the impacts of protocol actions are visible in the interface, and observable within network protocol flows.

Modbus Simulation

The Modbus version of Aloha Water Treatment exposes a small set of coils and holding registers that represent values in the simulated process. Figure 5 shows an example of reading the tank level using a Modbus Read Holding Registers ability in Caldera for OT. Holding registers are used for values such as tank level and flow rates, and coils are used for discrete states including emergency stop, pump switch, and operating mode. Modbus read and write operations can be used to observe and modify these values and view the resulting changes in the HMI.

Holding registers

• Address 0: Tank level (updated by controller logic)
• Address 6: Inflow rate (effective in manual mode)
• Address 7: Outflow rate (effective in manual mode)

Coils

• Address 0: Emergency stop (0 = off, 1 = on)
• Address 1: Pump switch (0 = off, 1 = on)
• Address 5: Inflow mode (0 = automatic, 1 = manual)

BACnet simulation

The BACnet version of Aloha Water Treatment exposes a set of BACnet objects that represent values in the simulated process. Figure 6 shows an example of reading the tank level using a BACnet ReadProperty ability in Caldera for OT. Analog value objects are used for values such as tank level and flow rates, and binary value objects are used for discrete states including emergency stop, pump switch, and operating mode. BACnet ReadProperty and WriteProperty requests can be used to observe and modify these values and view the resulting changes in the HMI.

Analog values

• Instance 1: Tank level (updated by controller logic)
• Instance 2: Inflow rate (effective in manual mode)
• Instance 3: Outflow rate (effective in manual mode)

Binary values

• Instance 1: Emergency stop
• Instance 2: Pump switch
• Instance 3: Inflow mode (False = automatic, True = manual)

Getting Started

To start exploring operational technology (OT), download the Aloha Water Treatment Plant simulator today and explore the Modbus and BACnet protocols. The project is open source and built for education. Feedback, issues, and pull requests are welcome so the community can keep improving these virtual OT sandboxes and continue advancing open-source OT cybersecurity together!

Resources and Code:

• Caldera for OT plugin repository
• Aloha Water Treatment Plant
• Caldera GitHub
• Caldera Homepage

Community and Support:

• Discord
• LinkedIn
• Caldera Documentation
• Caldera YouTube

©2026 The MITRE Corporation. All rights reserved.

Approved for public release. Distribution unlimited PRS 23–4177.

Overview

The MITRE Caldera project has introduced Caldera MCP (Model Context Protocol), a new plugin that enables large language models to interact with and control Caldera. This overview focuses on MCP’s capabilities, setup, and practical use cases for an LLM-powered Caldera. It demonstrates how MCP can streamline purple teaming workflows, automate adversary emulation, and augment analysis.

Caldera MCP

While large language models (LLMs) are excellent at generating code and drafting emails, the Caldera team wanted to explore uncharted territory with LLMs. Specifically, we set out to apply LLMs to various cybersecurity domains within Caldera, aiming to make the platform more accessible and powerful for operators of all skill levels. Fortunately, recent advances in the AI open-source community have led to the standardization of the Model [EM1] Context Protocol (MCP), which allows standalone tools to be masked and presented as context to large language models [1]. Building on this, the MCP plugin was developed as a wrapper for the existing Caldera API, enabling seamless integration between Caldera and LLMs. The MCP plugin acts as a bridge, translating requests and responses between Caldera’s REST API and large language models. This allows LLMs to understand Caldera’s capabilities and issue commands as if they were native operators, enabling automation and advanced reasoning.

We explored three different research directions utilizing the MCP plugin, as well as a custom large language model approach that didn’t rely on the MCP plugin. Our work included developing a large language model planner, creating a large language model-powered ability factory, and deploying a forward agent enhanced with Retrieval Augmented Generation (RAG) for CTI-driven improvements.

Large Language Models as an Ad-hoc Planner

Our first research effort builds on prior work on autonomous Caldera agents [2], adapting those ideas to an LLM-based ad-hoc planner.

In Caldera, planners are algorithms that determine the order and selection of abilities for an adversary. Traditionally, Caldera planners have focused on optimizing for a specific goal by balancing exploration and exploitation within an environment. The LLM planner, while still grounded in the straightforward atomic planner, takes a different approach: it dynamically constructs new adversaries on the fly based on user requirements provided through natural language prompts. This flexibility allows the ad-hoc planner to adapt to changing environments while still maintaining a balance between exploration and exploitation.

For example, one of our most frequently tested prompts was: “Can you make a new caldera adversary that replicates a stealer malware sample?” With access to a suite of Caldera API tools exposed via the MCP server, the LLM can analyze and select the most suitable abilities to mimic stealer malware behavior. Typically, the adversaries generated by the LLM included tactics such as collection, exfiltration, and discovery.

Large Language Models as an Ability Factory

A common challenge for red team operators using Caldera is the lack of high-quality abilities tailored to their specific use cases. Caldera’s ability repository includes thousands of options, with atomic, emu, and stockpile plugins available, but sometimes the unique configuration of an environment requires something more nuanced. Our second research effort addresses this issue by leveraging an LLM to generate new Caldera abilities based on user requirements. By having the LLM handle the creation of custom abilities, operators can spend less time developing red team capabilities from scratch, which in turn allows them to focus on operational details and collaborate more effectively with the blue team for a successful engagement.

Another prompt we tested frequently was: “Can you create Windows WMI persistence abilities (more than one)?” In our experiments, the LLM typically succeeded in registering two persistence abilities using WMI in Caldera. However, the payloads chosen by the model were sometimes basic, or the abilities resembled proof-of-concept demonstrations rather than fully developed Caldera abilities. Still, the underlying mechanism for establishing a persistence hook was generally solid, and red team operators could easily refine the ability by tweaking the payload to better suit their needs.

We also found that using more specific prompts, narrowing the LLM’s scope and specifying a desired payload, dramatically improved the quality of the generated abilities. This observation aligns with broader trends in LLM research. Providing clear context and requirements allows the model to deliver more targeted and effective results.

Utilizing CTI Data via RAG

While a large language model planner and a large language model ability factory may offer many use cases, we wanted to take things a step further. We asked ourselves: “What if our existing large language model applications could incorporate cyber threat intelligence (CTI) data?” The immediate benefit of using CTI data is the ability to distill an organization’s STIX data into a repeatable, testable adversary. To accomplish this, we added a RAG pipeline capable of indexing and searching through embeddings for our STIX data in JSON format.

For testing, we downloaded publicly available STIX data. Although this data wasn’t particularly robust or relevant to an adversary worth replicating, it was still functional for our RAG pipeline and allowed the LLM to gain context about abilities and execution flows. Our most frequently used prompt was: “I want to emulate APT 28’s persistence strategies in a new adversary.” The impact of integrating CTI data into both the planner and the ability factory was immediately noticeable, and we could verify that our CTI data was being pulled into context.

APT 28 “Lamehug” Adversary Emulation with Caldera

1. In July of this year, shortly before DEFCON 33, CERT-UA [3] [EM2] [RCM3] [EM4] [RCM5] reported a unique malware strain called LameHug attributed to APT 28. The malware’s distribution and behaviors followed familiar patterns such as evasion, collection, and exfiltration, but its techniques were highly innovative. Instead of relying on a command-and-control server or pre-designed payloads, the malware relied on a public large language model endpoint. The Python sample contained configuration settings for a QWEN 2.5-Coder-32B-Instruct model, prompts for PowerShell scripts, and a hardcoded output file called “info.txt” to store the results of PowerShell commands. The sample actively communicated with the Huggingface API[RCM6] , using prompts to translate textual descriptions of PowerShell scripts into targeted PowerShell commands that leveraged Windows utilities.

We can infer from this isolated malware sample and many threat reports from frontier AI labs like OpenAI and Anthropic that APT groups are starting to utilize LLMs for more than writing social engineering emails.

Before, the CERT-UA report surfaced, the Caldera team was pursuing a similar LLM research effort. Our approach involved modifying a Caldera agent to translate natural language commands into PowerShell scripts and execute them inline for Caldera C2. But after learning about APT 28’s activities, we decided it would be interesting to emulate the “LameHug” malware by adopting its style of execution, prompting, and reporting.

We developed a new Caldera agent called Magician, implemented in Go. It uses a prompt format inspired by APT28 and follows a similar flow: translate prompts into commands and execute them. The key addition is a feedback loop that reports errors to the LLM when a generated script fails, allowing it to correct and retry. When commands succeed, Magician writes the output to “C:\Users\Public\info.txt” for later collection by the standard Sandcat agent.

After confirming that Magician could execute commands reliably, we ran three experiments with increasing complexity. In the first experiment, we structured the prompts to closely emulate APT 28 by gathering files, performing reconnaissance, and, for some flare, even conducting a security assessment. In the second experiment, we tasked the agent to degrade system security by turning off the Windows firewall, disabling real-time protection, disabling user account control, and creating a new user with provided credentials. In the last experiment, we tasked the agent with performing system wide file encryption by finding files most likely to contain sensitive information, generating an AES key, and encrypting the files it found earlier with the AES key it generated. Surprisingly, after a few trials, Magician was able to perform system-wide encryption autonomously. The agent also completed the first two experiments with relative ease, with the reconnaissance experiment being the most consistently successful.

Takeaways

Having explored three distinct approaches for integrating large language models with Caldera, we evaluated each method using a scoring rubric to assess their overall effectiveness. Table 1 summarizes the scoring results across four key criteria. As shown, both the Planner and Factory approaches performed strongly, tying for first place, while the Forward Deployed Agent approach also showed promise but scored slightly lower overall.

In this rubric, each approach was evaluated for Impact, Autonomy, Cost, and Extensibility, with a maximum score of 5 per criterion. Higher scores reflect better performance in that category.

· Impact measures real-world effectiveness for adversary emulation tasks.

· Autonomy indicates how independently the system operates.

· Cost reflects resource efficiency.

· Extensibility gauges adaptability to future use cases.

Overall, the MCP plugin opens up exciting possibilities for future research and operational use in cybersecurity. We will continue exploring and iterating on these approaches, and we invite the community to experiment with the MCP plugin, which is open sourced at: link. Share feedback, file issues, and contribute enhancements to help shape the roadmap.

References:

[1] Model Context Protocol (MCP) — Spec and reference implementations. URL: https://modelcontextprotocol.io/docs/getting-started/intro

[2] Mirage: cyber deception against autonomous cyber attacks in emulation and simulation. URL: https://link.springer.com/article/10.1007/s12243-024-01018-4

[3] CERT-UA — “LameHug” malware report (APT28). URL: https://cert.gov.ua/article/6284730

Resources and Code:

• Caldera GitHub: https://github.com/mitre/caldera
• Caldera documentation: https://caldera.readthedocs.io/en/latest/
• MCP plugin repository: https://github.com/mitre/MCP

Community and Support:

· Discord: https://discord.gg/8ApVgPXQnY

· LinkedIn: https://www.linkedin.com/company/mitre-caldera/

· Website: https://caldera.mitre.org/

· YouTube: https://www.youtube.com/@MITRECalderaOfficial

Author: Devon Colmer

Since our open-source release in September 2023, the MITRE Caldera for OT team has been adding capabilities to emulate adversary behavior in operational technology (OT) networks. But what if you don’t have access to physical hardware for testing? How can you join our community and start experimenting? Today we’re excited to announce another milestone in our development with the release of Wildcat Dam — the first in a planned series of virtual OT protocol training devices. With this simple software device and Caldera for OT, you have everything you need to set up an OT network protocol testing sandbox entirely in software — on a single computer, if desired.

First, we congratulate the talented University of Arizona students who brought this idea to life. Through the INSuRE program, MITRE had the privilege of mentoring four students in designing and developing Wildcat Dam. We commend their hard work and are proud to amplify their success.

A MODBUS-Based Dam Control Simulation

Wildcat Dam is a simulation of a basic dam control system that communicates using the MODBUS protocol. The controller manages three sluice gates (or doors) to regulate the reservoir’s water level, ensuring it stays within threshold setpoints. It receives sensor readings of the water level and the surge (inflow) rate of water. While not intended to be a realistic replica of a dam controller, it was designed to include all four datatypes of the MODBUS protocol and enable a range of interactions with the system. This makes it ideal for experimenting with a range of MODBUS messages, generating sample traffic, and learning how OT represents the physical world.

Getting Started with Wildcat Dam

The Wildcat Dam repository includes a README with step-by-step installation and usage instructions.

Wildcat Dam is a simple Python script. To get started, install the required dependencies, set up a virtual environment, and run the script, launching the virtual MODBUS server. Next, swap over to Caldera, ensuring the MODBUS Caldera for OT plugin is loaded, and begin sending MODBUS messages to the dam controller.

If you are running the Caldera agent and Wildcat Dam on the same computer, you can target the dam by using the loopback IP address (127.0.0.1) and port 5020. (Note: While the default MODBUS port is 502, Wildcat Dam is configured for port 5020.)

Exploring Caldera MODBUS Capabilities

Which Caldera MODBUS abilities should you use? The choice is yours — experiment and discover what works. This setup lets you freely test and explore without the limitations of real hardware or the risk of impacting a physical process. Hands-on exploration fosters deeper learning and a stronger understanding than simply following step-by-step instructions.

If that feels too broad, here is a breakdown of the variables available in the control system:

Coils (binary values that can be read or written)

• Address 0: Door 1 position
• Address 1: Door 2 position
• Address 2: Door 3 position
• Address 3: Door 1 manual override (0/OFF = auto, 1/ON = manual)
• Address 4: Door 2 manual override (0/OFF = auto, 1/ON = manual)
• Address 5: Door 3 manual override (0/OFF = auto, 1/ON = manual)

Discrete inputs (read-only binary values)

• Address 0: water outflow status

Holding registers (read/write analog values)

• Address 0: close level for door 1 (0–100)
• Address 1: reduction rate of door 1 (0–10)
• Address 2: reduction rate of door 2 (0–10)
• Address 3: reduction rate of door 3 (0–10)
• Address 4: threshold 1 value (0–100)
• Address 5: threshold 2 value (0–100)
• Address 6: threshold 3 value (0–100)

Input registers (read-only analog values)

• Address 0: water level
• Address 1: surge rate (inflow rate, scaled 1–5)

With this understanding, use Caldera to enable manual control of the sluice gates and then open and close them. Next, switch back to automatic control, reset the threshold values and watch the system adjust.

After that, run an experiment to learn more about the MODBUS data model. First, try reading the water level in the reservoir. Now attempt to set the water level. Spoiler alert: you can’t! MODBUS input registers such as the water level in Wildcat Dam are read-only. There is no “write input register” MODBUS message and consequently, no Caldera “ability” to write to an input register. This isn’t a limitation of MODBUS, it is a way for the protocol to model the physical process in data. The controller can’t change the water level in the reservoir directly, so that water level value is stored as a read-only “input register.”

Get Involved

Download Wildcat Dam today and start exploring the world of OT network testing in a safe, virtual environment. Whether you’re experimenting with MODBUS protocols, testing Caldera abilities, or just learning the basics of OT security, this tool is designed to empower your journey.

Wildcat Dam is open-source, and we welcome your contribution of new features, improvements, or bug fixes. Jump into the codebase, submit pull requests, or share your feedback with us. Get started by checking our issues list.

Together, we can continue to innovate and build tools that advance OT security for everyone.

Let’s get started!

Author: Dawid Kulikowski, edited by Michael Kouremetis for Medium.

Disclaimer: This post comes from a contributor from the MITRE Caldera™ open-source community. The views, thoughts, and opinions expressed are those of the author and do not reflect the official view, policy or position of the MITRE Caldera™ team or the MITRE Corporation. The MITRE Caldera team has also reviewed the author’s content and code, and have found it to be of high quality and safe for open sourcing. The team expresses their appreciation to the author for their contribution of this high quality content.

Overview

All versions of MITRE Caldera (before commit 35bc06e and going back as far as the very first versions of Caldera) are vulnerable to a remote code execution (RCE) vulnerability that can be triggered in most default configurations. The only preconditions for this vulnerability to be exploitable are the presence of Go, python and gcc on the system that the Caldera server is running on. Notably, all of these dependencies are required for Caldera to be fully-functional in the first place and on many distributions, gcc is a dependency of Go, meaning this vulnerability is extremely likely to be available to an attacker.

CVE Record

Sandcat, Manx and Dynamic Compilation

The vulnerability originates in the dynamic compilation functionality of the Caldera Manx and Sandcat agents (implants). For those unfamiliar, they’re small reverse shells that call back to Caldera and execute commands as tasked during a Caldera operation. Looking at Caldera’s source code, the author initially took note of this compilation endpoint as it is not authenticated, meaning any vulnerability found would likely not require any knowledge of credentials.

The Caldera server has an HTTP(S) endpoint which serves web requests for for agents to be downloaded and executed on target systems. When downloading them, various options can be specified such as the communication method, encryption keys, the C2 address, etc. using HTTP headers. The agents are then compiled on-the-fly and these parameters are passed to them so it can be included in the resulting binary and control how the agent runs.

As such, you may be wondering how this attacker-controlled data is passed to the agent being compiled. Something like the use of gcc’s “-D” flag and insecure use of “system()” may be enough to result in exploitable command injection.

Simple Command Injection

First thing to do is trace the execution flow. After following the function calls from the initial request handler, we arrive here:

This looks promising! We have user-controlled data in the linker flags “ldflags” which is passed to “compile_go()” as a string. Let’s see what compile_go() does with this.

Darn, subprocess.check_output() is being used without shell=True. As mentioned in the subprocess documentation:

Unlike some other popen functions, this library will not implicitly choose to call a system shell. This means that all characters, including shell metacharacters, can safely be passed to child processes. If the shell is invoked explicitly, via shell=True, it is the application’s responsibility to ensure that all white-space and meta characters are quoted appropriately to avoid shell injection vulnerabilities. On some platforms, it is possible to use shlex.quote() for this escaping.

The important parts are highlighted. In effect, we won’t be able to simply pass “; reboot ;” and restart the system. We will have to look elsewhere for bugs. Or will we?

Abusing Linker Flags

While there is no low-hanging command injection, we still are able to control the linker flags. But what does that let us do?

For starters, the only flags that Caldera uses are “-X” and sometimes “-s”, “-w”. According to the documentation, “-s” and “-w” strip symbols and remove debugging information, while “-X” functions like “-D” when invoking “gcc”— it basically assigns some value to a variable. But are there any other options?

Yes there are (and many of them). Running go tool link returns:

Of these flags, those that may be utility here are “-extar”, “-extld” and “-extldflags”.“-extar” allows one to specify what tool to use for archiving when using the “buildmode=c-archive” option. While “-extld” and “-extldflags” define what linker to use and what flags to append when invoking it.

Our goal is to be able to execute something with user-controlled parameters. While there likely are many ways to do this, it takes some trial-and-error to find the right combination of binary and parameters. Even if we get to execute a binary of our choice and manage to give it some attacker-controlled arguments, it will often still fail due to extraneous (and in its eyes invalid) arguments being appended by the Go linker to the invocation.

I quickly gave up on trying to abuse “-extar”. While it was executing the binary specified, one couldn’t find a way to pass any arguments to it. The next candidate was “-extld”. This is a lot more interesting due to “-extldflags”, which allows us to pass some arguments to an executable of choice. First, it was determined that the external linker is not always called. The build mode had to be changed to get Go to use the specified linker. However, after getting the specified binary to execute, further obstacles occurred as binaries like python or bash did not like random parameters being passed to it by the linker in addition to the ones specified by “-extldflags”. In the end, the author decided to see if the linker could be set to “gcc” or “clang” and then ultimately if any functionality in the external linker could be abused.

This approach was validated after the author quickly skimmed through the documentation of gcc:

-wrapper

Invoke all subcommands under a wrapper program. The name of the wrapper program and its parameters are passed as a comma separated list.

gcc -c t.c -wrapper gdb, — args

This will invoke all subprograms of gcc under `gdb — args’, thus the invocation of cc1 will be `gdb — args cc1 …’.

Great! This seems like it could do what we want. Let’s put it all together and try.

Proof-of-Concept

Running this curl command:

Should result in:

Pwned!

Conclusion

As of writing, this vulnerability has been reported to the MITRE Caldera team and patched in the code base. The MITRE Caldera team recommends users to immediately pull down the the latest version (either Master branch or v5.1.0+) of Caldera. The vulnerability has been documented in CVE-2025–27364. This post will be updated as public CVE records are created. The MITRE Caldera Team also sincerely thanks Dawid Kulikowski for his initial reporting of the vulnerability and subsequent support in patching the affected Caldera code. Thank you Dawid.

A small change is applied to break the proof-of-concept seen here, to prevent script kiddies from being able to easily abuse it. One must investigate the Caldera source code to identify the required modifications, as copy-pasting the proof-of-concept shown here will not fully work.

The reporting author intends to release a fully-featured Metasploit module in the coming week(s), so patch your instances! Or even better — don’t expose them to the internet!

Resources

Caldera Homepage

Caldera GitHub

Caldera Documentation

Caldera Users Slack

Authors: Michael Kouremetis

The MITRE Caldera project would like to announce a continuing benefactor — NVISO! The Caldera project extends its deepest appreciation to NVISO for its second donation and for directly supporting the MITRE Caldera platform. NVISO’s donation will go to keeping Caldera open source and supporting our upcoming FY25 community initiatives.

Thank you, NVISO.

Interested in becoming a MITRE Caldera™ Benefactor?

Become a MITRE Caldera Benefactor! Through your charitable giving you can directly help in sustaining and advancing the Caldera Adversary Emulation platform. Donations are directly applied to platform development and maintenance, academic and community engagement, and cutting-edge R&D. To show our thanks, Caldera Benefactors are also the recipient of many benefits, to include being recognized as a benefactor of MITRE Caldera and announcement as well as collaboration and briefings with the Caldera leadership team. For more details see the benefactor program link below.

Caldera Benefactor Program Form: https://hubs.ly/Q01Wgc3V0

Want to learn a little more about the Caldera Benefactor program first? Feel free to reach out to us at caldera@mitre.org for a conversation.

Resources

Caldera Homepage

Caldera GitHub

Caldera Documentation

Caldera Users Slack

©2025 The MITRE Corporation. All rights reserved.

Authors: Louis Hacklander-Jansen

Hey Caldera Community! We just wanted to cross-post Louis Hacklander-Jansen’s recent post on working with MITRE Caldera parsers. Thank you Louis!

Checkout out Louis’s great post here!

Resources

Caldera Homepage

Caldera GitHub

Caldera Documentation

Caldera Users Slack

Authors: Michael Kouremetis

The MITRE Caldera project would like to announce our new benefactor — SANS Institute! The Caldera project extends its deepest appreciation to the SANS team for its donation and for directly supporting the MITRE Caldera platform. The Caldera project team, as longtime fans and supporters of the SANS Institute, is very excited to establish this benefactor relationship and strengthen collaboration between our teams. The SANS donation will go to keeping Caldera open source and supporting our upcoming FY25 project initiatives.

Thank you, SANS.

Interested in becoming a MITRE Caldera™ Benefactor?

Become a MITRE CalderaTM Benefactor! Through your charitable giving you can directly help in sustaining and advancing the Caldera Adversary Emulation platform. Donations are directly applied to platform development and maintenance, academic and community engagement, and cutting-edge R&D. To show our thanks, Caldera Benefactors are also the recipient of many benefits, to include being recognized as a benefactor of MITRE Caldera and announcement as well as collaboration and briefings with the Caldera leadership team. For more details see benefactor program link below.

Caldera Benefactor Program Form: https://hubs.ly/Q01Wgc3V0

Want to learn a little more about the Caldera Benefactor program first? Feel free to reach out to us at caldera@mitre.org for a conversation.

Resources

Caldera Homepage

Caldera GitHub

Caldera Documentation

Caldera Users Slack

©2024 The MITRE Corporation. All rights reserved.

Approved for public release. Distribution unlimited PR_24–02464–2.

Authors: Misha Belisle & Blaine Jeffries

The MITRE Caldera™ for OT team is proud to announce updates to the BACnet plugin. As with the initial release of this OT plugin, these abilities are open source and completely free to use. The BACnet plugin is available to download from our GitHub repository. Or, if you have an existing version downloaded, you can pull the latest commit for the new content.

With this update, the BACnet plugins introduces 8 new OT abilities (available for both Windows and Linux OS environments), for a total of 60 distinct OT abilities. Practitioners are now enabled to execute additional BACnet protocol functionality, such as GetEventInformation and ReinitializeDevice. Supplementary abilities “BACnet Device Collection” and “BACnet Object Collection” provide users with select preconfigured options to gather device information.

As before, we extend our thanks and recognize the developers of the libraries Caldera for OT is dependent on. These BACnet updates continue to leverage bacnet-stack .

To share some BACnet background and highlight some of the new abilities:

• BACnet, short for “Building Automation and Control Network” is a data communication protocol that leverages an object-oriented model for describing process controls and devices. Data exists as standardized objects, which are defined by various properties. Implemented as OT abilities, services enable users to interact with these objects and their properties.
• OT Abilities fall into the following categories of BACnet services: Alarm and Event, File Access, Object Access, Remote Device Management. For example, “BACnet Who-Is”, part of the initial release, is classified as Remote Device Management can be used to obtain information on other BACnet devices that share the same internetwork as the sender. By discovering key information, such as the Device object identifier, it is then possible to collect additional information on objects’ properties using abilities such as “BACnet Read Property” or the newly added “BACnet Read Property Multiple”, both of which are Object Access services.

As with the initial release, the BACnet plugin’s documentation has been updated to reflect guidance on these new abilities, description accessible in-app with the Caldera fieldmanual plugin. This same documentation can also be accessed directly via bacnet/docs/bacnet.md.

If you are brand new to Caldera or just need a quick refresher, check out the core documentation. There you will find everything you need to get Caldera up and running on your own infrastructure. The Caldera server is intentionally lightweight and portable so that it can be deployed on a standard laptop.

We are thrilled to bring you these additions to the original BACnet capability, and as always, are eager to hear your feedback. If you have technical comments, please utilize GitHub to report issues and/or contribute!

We can also be reached at the following:

• OT@mitre.org — ask to join our Distribution List
• Caldera Slack — find us Caldera slack

As always, we a handful of resources available, from blog posts to podcasts:

Caldera for OT Resources

Caldera for OT GitHub

SANS ICS Slides

SecurityWeek ICS Recording

Federal Drive Podcast

Nexus Podcast

The PrOTect OT Cybersecurity Podcast

Caldera Resources

Caldera Homepage

Caldera GitHub

Caldera Documentation

Caldera Users Slack

©2024 The MITRE Corporation. All rights reserved.

Approved for public release. Distribution unlimited.

Case #PR_24–02464–1.

Author: Michael Kouremetis

The MITRE Caldera™ team just wanted to highlight what is, at least in our view, a well done survey of adversary emulation tools recently conducted by cyber security researchers out of the Center for Digital Safety & Security, of the Austrian Institute of Technology. We found the survey to be of high quality, arguably the best methodical evaluation of adversary emulation tools (that we have seen), and most importantly useful. We can now just send back this survey when asked about a comparison of open source adversary emulation tooling , which happens a lot around here :). So a big thank you to the authors from the Caldera team.

Kudos to the authors Max Landauer, Klaus Mayer, Florian Skopik, Markus Wurzenberger, and Manuel Kern.

Paper link: https://arxiv.org/abs/2408.15645

*Note on survey evaluation results:

Yes, MITRE Caldera was ranked highly by the authors in their independent survey but that’s not why we are sharing the survey. We are sharing the survey because it is a very good survey, period. Additionally, the Caldera team believes in having many tool suites, and always using the best tool for the job. Not to mention that our team uses at least half of the other tools surveyed, and that Caldera makes significant use of one of the other evaluated tools (i.e. Atomic Red Team).

Resources

Caldera Homepage

Caldera GitHub

Caldera Documentation

Caldera Users Slack