Tripwire — [red|purple|blue] team detection lab orchestration
Python version: https://medium.com/@hacksplaining/a-new-tripwire-but-in-python-96a5f5b33a3f
Tripwire is a virtual machine orchestration script, designed to supplement red|purple|blue team lab environments. It utilizes VMware Workstation’s vmrun.exe (Virtual machine automation tool) to provide the user additional methods of control, like automatically starting and stopping VMs, print network and resource usage information, and reset VMs to a “known good state” via snapshots. Beyond the automation, “Red Ranger” will monitor ELK Security Alerts and prompt you with any tripped detections… hence the name Tripwire.
How is Tripwire used?
As with many Red Team engagements, custom tooling and certain techniques may be required per the given objectives. During the testing and development phase of an engagement, I would execute an attack and run tools in a lab environment, sleuth through ELK logs, and write a few detection rules for the techniques. This works, but I found pivoting back and forth from my team server’s console, dashboards, and logs was distracting. I needed a way to easily track the residual artifacts from techniques I was designing for Red Team engagements, while attempting to evade my own detections.
Example
Sliver’s default execute-assembly configuration will spawn a sacrificial process (notepad.exe) and then inject the assembly code into the process.
The screenshot below shows three separate executions of a Sliver binary named beacon.exe. One with Windows Defender disabled, and then two with both Real-time protection and Cloud-delivered protection enabled.
Iteration 1
I launched beacon.exe and then ran the execute-assembly command. Here is the associated Sysmon “CreateRemoteThread” (event id 8) event:
CreateRemoteThread detected:
RuleName: technique_id=T1055,technique_name=Process Injection
UtcTime: 2023-02-07 18:21:47.499
SourceProcessGuid: {78b18240-9f5d-63e2-4307-000000000c00}
SourceProcessId: 5884
SourceImage: C:\Users\hannib\Downloads\beacon.exe
TargetProcessGuid: {78b18240-9fa3-63e2-4807-000000000c00}
TargetProcessId: 3956
TargetImage: C:\Windows\System32\notepad.exe
NewThreadId: 5224
StartAddress: 0x0000025903210000
StartModule: -
StartFunction: -
SourceUser: TRIPWIRE\hannib
TargetUser: TRIPWIRE\hannibUsing the Sysmon event data, I created a new Security Alert in ELK named: CreateRemoteThread to notepad.exe; default Sliver artifact, searching for event.code: 8 AND the TargetImage: notepad.exe, and then ran the same command.
This time, Red Ranger saw the alert, and the returned the detection information. It’s working as planned.
Iteration 2
Now let’s run the same technique, but this time with Windows Defender (Real-time protection and Cloud-delivered protection) enabled. Running beacon.exe bypassed Windows Defender, and wasn’t interrupted until we spawned the sacrificial “notepad” process, due to a “Behavior” detection.
The new Sysmon alert was also triggered.
Specifying a hosting process to inject into with the -p or — process flag will also get blocked by Windows Defender.
Iteration 3
Our last test we’ll want to try and bypass alerts seen by Red Ranger. This time I’ll run execute-assembly with the — in-process flag, which enables the assembly to Run in the current sliver process. Defender doesn’t seem to mind this action, and our beacon lives on. The sacrificial process doesn’t get spawned and our detection is bypassed.
Is there really a need?
Sure, you could just look at the Security Alerts page in ELK and view any dashboards that have been created, or even search the logs directly. There is nothing wrong with that approach, and I’ll do that at certain points while testing.
One benefit to using Tripwire, was how I could customize the output when an alert was triggered, and even orchestrate different groups of virtual machines to run at a given time or based on a specific configuration. Sometimes, I just want to see the alert name and the culprit file for the alert, but for others I may want only certain artifacts or a general “informational” notice of an action.
Recently, I added a line to the script to play the Metal Gear Solid ‘alert’ sound when Red Ranger prompts the first triggered alert. It doesn’t add any real benefit beyond ‘shock factor’, but the initial alert could be the tipping point during an operation.
Future capabilities
I am constantly modifying the script with new capabilities, and planning to include things like: attack-detection “scenarios”, a scoring feature, and OPSEC recommendations.
