Introducing Chain Reactor: an open source tool for adversary simulations on Linux

While adversaries, tools, and techniques have continued to evolve for the traditional IT and end user device market (Windows and macOS), the threat landscape for Linux is not as well understood. The Internet is generally devoid of publicly documented attacks, campaigns, or up-to-date literature on working attack techniques and tools for Linux. Most existing public documentation covers the evolution and proliferation of cryptocurrency miners.

Chain Reactor is the first of many future community contributions by Red Canary to help researchers, pentesters, red teamers, and defenders better understand what is possible on Linux endpoints. Chain Reactor assumes no prior engineering experience and can easily leverage tests or techniques from Atomic Red Team and MITRE ATT&CK.

What is Chain Reactor?

Chain Reactor allows you to compose Executable and Linkable Format (ELF) binaries that perform sequences of actions like process creation, network connections, and more, through the simple configuration of a JSON file. Chain Reactor’s rich configuration settings let you specify the specific system calls used to perform these actions, giving you greater granularity when testing security controls.

By supporting sequences of actions, Chain Reactor enables security teams to compose ELF executables that mimic the multiple stages seen in real world adversary behavior. Teams can compose executables that move through the different stages documented in MITRE’s ATT&CK framework, from running malicious code to establishing persistence to escalating privileges and more.

How does Chain Reactor work?

Chain Reactor is responsible for running a “reaction,” which is composed of a list of objectives, called “atoms.” Each atom can contain one or many actions, called “quarks.” Quarks specify the action to take and the subsequent arguments that will be used.

While this might sound complex at first, this structure helps with pre-stage setup, multi-stage objectives, and post-stage cleanup.

An illustrative example

Let’s start with a basic chain reaction:

reaction.json

{
      "name": "simple_reaction",
      "atoms": [
            "HIDDEN-PROCESS-EXEC"
      ]

}

atoms.json

{
      "name" : "HIDDEN-PROCESS-EXEC",
      "execve" : [ "mkdir", "-p", "/tmp/.hidden" ],
      "copy" : [ "/proc/self/exe", "/tmp/.hidden/.chain_reactor_hidden" ],
      "execveat" : [ "/tmp/.hidden/.chain_reactor_hidden", "exit" ],
      "remove" : [ "/tmp/.hidden" ]
}

To build the ELF executable, we run the following:

python compose_reaction atoms.json reaction.json <output_name_for_executable>

Then simply run the executable:

How it works

1. 1. The chain reaction ‘simple_reaction’ is composed of one objective (atom) called HIDDEN-PROCESS-EXEC.
   2. This atom is composed of four actions (quarks).
   3. The first quark utilizes the execve system call to create a hidden directory.
   4. The second quark copies the current running chain reactor process (/proc/self/exe) to the newly created hidden directory as a hidden file.
   5. The third quark uses a different system call, execveat, to execute the hidden chain reactor binary. The “exit” argument instructs the newly created chain reactor process to exit without performing additional operations.
   6. The fourth quark deletes the hidden directory and hidden file.

Here are some questions this chain reaction can help you answer:

• Visibility: Does my endpoint security product collect telemetry for all four quarks? Does it handle one, many, or all system calls that can be used to execute a binary?
• Detection: Does my endpoint security product alert me to the execution of a hidden binary in a hidden directory?

Leveling up

Let’s now demonstrate some of the advanced capabilities of Chain Reactor by composing a multi-stage simulation that utilizes network connections as well as other features.

reaction.json

{
      "name": "beastquake_reaction",
      "atoms": [
            "DISCOVERY-PROCESS-MEMORY-PERMS",
            "PRIVESC-FIND-SETUID-SETGID",
            "FORK-WITH-NETCONNS"
      ]
}

atoms.json

{
      "name" : "DISCOVERY-PROCESS-MEMORY-PERMS",
      "execve" : [ "cat", "/proc/sys/kernel/yama/ptrace_scope" ]
}
{
      "name" : "PRIVESC-FIND-SETUID-SETGID",
      "execve" : [ "find", "/", "-xdev", "-type", "f", "-perm", "+6000", "-perm" "-1", "2> /dev/null" ]
}
{
      "name" : "FORK-WITH-NETCONNS",
      "fork-and-rename" : [ "spoon" ],
      "connect" : { "method": "socketcall", "protocol": "tcp4", "address": "g.co", "port": 80 },
      "connect" : { "method": "connect", "protocol": "udp6", "address": "google.com", "port": 53 }
}

To build the ELF executable, we run the following:

python compose_reaction reaction.json <output_name_for_executable>

High-level details for this chain reaction:

• This chain reaction is composed of three atoms, which map to different MITRE ATT&CK tactics and techniques.
• The last atom, FORK-WITH-NETCONNS, utilizes a quark, fork-and-rename, that forks the existing process into a new process specified as spoon. The two remaining quarks for that atom initiate network connections, a tcp ipv4 connection to g.co on port 80, and a udp ipv6 connection to google.com on port 53. These benign domains/addresses could be exchanged with malicious ones.

Example questions this chain reaction can help you answer:

• Visibility: Did my existing security solutions fail to collect telemetry for the fork()?
• Visibility: Did my existing security solutions fail to collect telemetry for particular control protocols (tcp vs. udp) or internet protocols (ipv4 vs. ipv6)?
• Visibility: Is DNS telemetry captured and is it correlated to the process activity occurring on my endpoints?

What Chain Reactor can do for you

• Chain reactions are defined in JSON, and the resulting ELF executable is composed for you. No prior engineering experience is required.
• The creation and use of an executable allows for finer control over process lineage through forking and execing.
• The creation and use of an executable allows for network connections to be utilized without the use of external binaries like curl or wget.
• Chain Reactor does not require the use of an on system shell or interpreter in order to run.
• Tests and techniques can be used from Atomic Red Team, MITRE ATT&CK, and elsewhere.
• Support for defining objectives (atoms) and actions (quarks) allows for pre-stage setup, post-stage cleanup and multi-stage operations.
• Chain reactions can be shared, either as ready-to-run ELF executables or as JSON files.
• Specific system calls can be utilized for program execution and network connections, helping you to test the efficacy of security controls.

Features to look forward to

Quarks
We plan on developing additional quarks, similar to fork-and-rename, to facilitate common operations.

Chain Reactions
We plan on open-sourcing many chain reactions (both the JSON and ELF executables) so everyone can easily download and try them out, without having to go through the ideation and implementation process. These will simulate APT groups, common sequences and more!

Getting Started

Getting started is easy! Visit https://github.com/redcanaryco/chain-reactor.