Sharpen your Simulation Game Part 2 - Enter PurpleSharp

Published in

Open Threat Research

4 min readAug 6, 2020

In Part 2 of this series I would like to describe the architecture and workflow PurpleSharp implements to execute simulations.

The other two parts can be found in the following links:

Sharpen your Simulation Game Part 1— Introduction
Sharpen your Simulation Game Part 3 — Demos

Architecture

PurpleSharp currently consists of a single .NET assembly responsible for executing three distinct modules to deploy simulations on remote endpoints. These modules communicate with each other both locally and across the network using named pipes.

Orchestrator

The orchestrator runs on the operator’s endpoint and is responsible for orchestrating the simulation deployment by interacting with the simulation target to upload the other two modules, trigger the simulations, clean up after its etc.

Scout

The Scout runs on the simulation target and performs reconnaissance tasks to identify logged users and suitable processes. When instructed by the Orchestrator, the Scout will execute the Simulator.

Simulator

The Simulator runs on the simulation target and is responsible for running the specified techniques; the actual simulation.

Although currently bundled in one, each one of these modules will eventually become its own .NET project/assembly which comes with lot of benefits. Let me know if you are interested in helping with this modularization effort.

The following graphic describes the high level workflow of a simulation and how the three different modules interact with each other. The purple column highlights the actions executed on the operator’s endpoint and the blue column the actions executed on the simulation target.

Simulation Deployment

To deploy simulations, PurpleSharp requires administrative credentials on the remote endpoint and leverages Windows native services/features such as Server Message Block (SMB), Windows Management Instrumentation (WMI), Remote Procedure Call (RPC) and Named Pipes:

SMB is used to upload the Scout and Simulator .NET assemblies, read the content of the log files created by the modules and finally delete all generated files once the simulation is finished.
WMI and RPC are used to execute the Scout using the Win32_Process class. Because of this, the Scout runs as a child process of wmiprsve.exe and in the context of the service account used to deploy the simulation.
Named Pipes are used by the Orchestrator, Scout and Simulator to exchange information required for the simulation and avoid using command line parameters.

The following graphic provides a description of the steps PurpleSharp takes to deploy simulations on remote hosts.

Parent Process ID Spoofing

To trigger the simulation, the Scout leverages the PPID Spoofing technique. This technique provides several benefits to the simulations deployed by PurpleSharp:

Breaks the parent-child process relationship between the simulation deployment (Scout) and the actual simulation (Simulator). — wmiprsve.exe is a commonly abused process and breaking the processes relationship minimizes the chances of the simulation deployment triggering a detection.
Allows the Simulator to run as a child process of explorer.exe and in the context of the logged user mimicking this way a real compromised user on a production endpoint.

In the next picture, we can see the Sysmon Event 1 events generated when simulating technique T1059.001 — Powershell with PurpleSharp. The simulation was run using the service account hacklabz\psharp on the remote endpoint win10–1.hacklabz.com where the user hacklabz\msimpson is logged using an interactive session. Notice the Scout (C:\Windows\Temp\Scout.exe) and the Simulator (C:\Users\msimpson\AppData\Local\Temp\t1.exe) run under different users and from different parent processes.

Here is the operator’s view of the same simulation. For a full list of parameters, visit the documentation.

Simulation Playbooks

As I was writing PurpleSharp, I reached out to the community looking for feedback and feature requests. My friend Olaf had a particular one: He needed a more flexible way to execute groups of techniques without having to use the command line.

Thanks to this request, PurpleSharp supports JSON files as parameters used to describe complex adversary simulation playbooks. This functionality allows purple/blue teams to orchestrate the simulation of multiple techniques in a sequential way against several pre-defined or random targets. This feature allows blue team to execute flexible simulation playbooks like:

Create a playbook to execute techniques of interest based on a public report. For example, Red Canary 2020 Threat Detection report or CrowdStrike Global Threat.
Create a playbook to simulate the techniques employed by a particular threat actor and measure the organization’s security posture against it. For example, APT 28.
Create a playbook that will execute one technique a day against a random host for a span of several weeks. This flexibility allows security managers to train and measure the effectiveness of a security operations center in a continuous way without much effort.

Here is an example of that a JSON simulation playbook for PurpleSharp looks like:

JSON Playbook Template