Adversary Simulation with Sim
One of the best ways to test your detection portfolio is to emulate user actions on monitored systems.
I spotted Sim via Twitter and was immediately intrigued as I advocate strongly for any tools and features that enable configurable adversary emulation. Adversary emulation enables blue teams to validate and optimize their detection portfolio and thus determine the true efficacy of their detective capabilities. I do not consider any detection that has not been tested via direct purple or red team engagement, or via automated adversary emulation, as production ready. Per her GitHub repo, Hope Walker’s Sim is a C# application, configured via an XML file, that performs tasks based on the configuration to resemble user actions on a system in order to facilitate training and education. As a long time SOC and DFIR manager, training for me includes “training” detection and models to ensure optimal performance. IceMoonHSV’s projects appear to be fairly recent contributions to our community, I applaud Hope’s work here and offer a hearty welcome.
Again, referring to her repo content, user actions can be scripted using the task block in an XML configuration file where tasks are comprised of two components:
- Task configuration: three configuration tags determine the name of the task (for error tracing and configuration), the number of times the task will
<loop>, and how long to<pause>between each action. - Task actions: Many actions can be configured but it is recommended to maintain task granularity for more narrow, specified testing. Create multiple, scenario based config files, and run individual tests instead. Sim execute
<actions>as part of user simulation. Sim performs each action as if scripted, executing one action after the other in sequential order. Sim does not wait for one action to complete before starting another, thus the importance of the<pause>and<sleep>tags.
Read the rest of Hope’s documentation for yourselves, there are plenty of details as to action configurations including <setclipboard>, <getclipboard>, and <plain> for plain text typed as if a user typing sequentially. There are numerous special key options as well as the ability to call executables via <process> and run PowerShell commands with <powershell>.
I built Sim in Visual Studio; it’s posted to GitHub as a source-only project but with a solution file so compiling your own sim.exe is quick and easy. I also created a copy of the admindemo.xml file found in XMLExamples, saved it as sim_toolsmith_demo.xml and made some tweaks to create a more adversarial user.
I’ve shared my modifications for your use and consideration as a Gist.
Calling my demo file with sim.exe is as easy as Sim.exe sim_toolsmith_demo.xml (unique to your file structure) at an admin command prompt.
Figure 1: Sim with actions config file
Rather than talk about it, I captured a video to exhibit Sim’s run through my adversarial user configuration file. Imagine this adversary as a script kiddie who has popped a system and is now searching for hacker tools to expand terrain. You’ll note PowerShell calls as well as command prompt actions. Actions also include Google searches, including multiple browser tabs, as well as keyboard tabs to land on desired search content. This config also saves the Windows Security event log, noteworthy because it could just as easily have cleared it, which should always trigger an alert.
As you can see, Sim does a great job of emulating user behaviors, and can easily be configured to conduct far more adversarial behaviors as desired. This particular demonstration would likely trigger alerts for web filtering rules intended to block access to hacker tools. Detections that make use of PowerShell logging could certainly be easily tested here as well. And again, if the Security event log had been cleared instead of simply written off to a file, any detection rules or signatures monitoring the 1100 series of Windows Event Logs would have triggered, particularly Event ID 1102 - The audit log was cleared.
I assert that Sim could be batched and automated. You could deploy an entire range of adversary emulations to a central share then call a master file during a desired and scheduled test or emulation window. Group Policy is even an option. Obviously, it is not recommended to fire off Sim jobs designed to emulate adversarial behavior without working with your leadership and any teams who may be monitoring user behaviors. Much like penetration testing, definitely ask for written permission rather than forgiveness after the fact.
I hope Hope will keep developing against this project, the possibilities are endless for adversary emulation scenarios, end Sim is really light and highly flexible. It’s great work, please safely give it a go for yourselves!
Cheers…until next time.
Comments