I am an advocate for the practice of adversary emulation to ensure detection efficacy. Candidly, I don’t consider a detection production-ready until it has been validated with appropriate adversary emulation to ensure the required triggers, alerts, and escalations are met. In many cases, basic human interaction can simulate the adversary per specific scenarios, but this doesn’t scale well. Applications and services to aid in this cause are essential. A couple of years ago I discussed APTSimulator as a means by which to test and simulate the HELK, but I haven’t given proper attention to adversary emulation on Linux. To that end, Chain Reactor “is an open source framework for composing executables that can simulate adversary behaviors and techniques on Linux endpoints. Executables can perform sequences of actions like process creation, network connections and more, through the simple configuration of a JSON file.”

Chain Reactor is a Red Canary offering, this team also provides Atomic Red Team, a set of “small and highly portable detection tests based on MITRE’s ATT&CK.” I’ll definitely focus on Atomic Red Team in the future, but it’s so well documented and vetted, I’ll target some very specific scenarios.
With Chain Reactor we see a few basic premises. Chain Reactor operates in the frame work of a reaction. Within the context of the reaction are a list of objectives defined as atoms. Within each atom, one or many actions and the subsequent arguments to use are established with quarks. According to Red Canary, “this structure helps with pre-stage setup, multi-stage objectives, and post-stage cleanup.” With any chain reaction, testers should ask the following questions:

• 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?

For the more specific nuances of how Chain Reactor seeks to achieve these goals, see the details, as well as the installation process on the project GitHub repository.

Chain Reactor includes examples specific to detection and visibility. The detection example includes a whois transfer, a visit to a pastesite, an execution in shared memory, and a hidden process creation.
The visibility examples include network examples for both connections and listeners. The listener sets up TCP and UDP listeners for localhost that should likely never be there i.e. port 12400 through 12407.
First a look at the network connection example that goes loud to a variety of DNS services as seen via visibility_network_connect_atoms.json in /chain-reactor-master/examples/visibility/network/connect. Atom content is seen in Figure 1.

Figure 1: Network visibility atoms

To create an ELF executable for the network visibility connections example, execute the following:

python3 compose_reaction examples/visibility/network/connect/visibility_network_connect_atoms.json examples/visibility/network/connect/visibility_network_connect_reaction.json networkConnect

Executing the reaction is as easy as ./networkConnect. The execution output is seen in Figure 2.

Figure 2: Reaction output

As we’ve laid claim to visibility in this scenario, no better way to see the results of the reaction via tcpdump, as seen in Figure 3.

Figure 3: tcpdump result

Chain Reactor’s detection example is a great way to test your auditd configuration. What!? Wait, you’re not running auditd? Let’s fix that (assumes Ubuntu 18.04).

sudo apt install -y auditd audispd-plugins

You’ll need to update your audit rules with a worthy audit.rules file. I am already a Florian Roth fan, he of Sigma, YARA, and Nextron fame; his audit.rules file for auditd is spot on. It already includes detection for the likes of curl as used by the detection reaction, I added an entry for whois as well: -w /usr/bin/whois -p x -k recon. Assuming a fresh install, copy this audit.rules to /etc/audit/rules.d and overwrite any existing file. You should run sudo service auditd restart to generate a new audit.rules file in /etc/audit. The service reads from rules.d to do so automatically.
Now, back to Chain Reactor. I compiled the detection example with

python3 compose_reaction examples/detection/example/detection_example_atoms.json examples/detection/example/detection_example_reaction.json detectMe

then fired it off with ./detectMe.
This reaction executing follows in Figure 4.

Figure 4: detection reaction

You can easily see the curl and whois references, the curl call is something you may want to flag similar instances of, particular to paste sites. To review auditd’s log output from /var/log/audit/audit.log one need only use ausearch.
ausearch -x whois results in Figure 5.

Figure 5: ausearch whois

Note the redcanary.com reference about two-thirds to the bottom of the Figure 5, clearly indicating auditd flagged the use of whois. If this was of concern to you, put a detection in place, fire an alert and take action. But thanks to the likes of Chain Reactor you can validate the detection in advance, emulating the behavior of concern.
Similarly, ausearch -x curl results are seen in Figure 6.

Figure 6: ausearch curl

Again, the likes of a trigger for curl requests to paste sites should likely be a worthy detection, be sure to validate with emulation courtesy of Chain Reaction via quarks, atoms, and reactions. The auditd audit.rules set is also highly configurable to your preferences and detection goals. Likewise, reactions are equally and easily configurable to your adversary emulation goals.
Kudos to the Red Canary team for this work, and Atomic Red Team. I look forward to seeing what comes next from this crew.

Cheers…until next time.

Russ McRee | @holisticinfosec