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.
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.
Figure 1: Network visibility atoms
To create an ELF executable for the network visibility connections example, execute the following:
Executing the reaction is as easy as
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).
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:
then fired it off with
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.
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.
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.
Cheers…until next time.
Mar 7th 2020
|Thread locked Subscribe||
Mar 7th 2020
1 year ago
Thank you Russ McRee
Mar 7th 2020
1 year ago