Automating the Adversary: Using SOAR to Simulate Real-World Attacks

By Kelsea Boyd, Automation Engineer

Why Automate Adversary Simulation?

Traditional penetration tests provide valuable insight, but they are episodic, expensive, and quickly outdated. Real attackers operate continuously, automate aggressively, and adapt faster than annual assessments can keep up.

This gap between periodic testing and continuous threat activity is where adversary simulation becomes critical – not as a replacement for red team engagements, but to continuously validate that detections, telemetry, and response workflows play out as intended. When paired with orchestration, adversary simulation stops being a point-in-time exercise and becomes an operational purple team capability.

By safely simulating attacker techniques on a recurring basis, security teams can:

Validate detection logic against known TTPs

Measure SOC visibility and alert fidelity

Continuously test logging pipelines and telemetry coverage

Reduce the operational burden of manual testing

Splunk SOAR is a well-suited automation tool for this role. Its ability to orchestrate API calls, authentication flows, command execution, and logging validation allows defenders to simulate attacker behavior while staying firmly in control.

This post walks through common attack phases and outlines how to safely automate them using Splunk SOAR.

Architecture Overview: SOAR as an Adversary Orchestrator

At a high level, an automated simulation using Splunk SOAR looks like this:

A scheduled or manually triggered SOAR playbook initiates a simulation

The playbook executes controlled attacker-like actions (API queries, logins, commands)

Each action is fully logged by the target systems

Splunk Enterprise / SIEM ingests the telemetry

Detection rules, correlation searches, and alerts are evaluated

SOAR optionally validates that expected alerts fired

This creates a closed feedback loop between attack simulations, detection, and response without introducing real risk.

Lateral Movement Simulation: Logged Connection Attempts

Attacker Context

After initial access, attackers attempt lateral movement using protocols such as:

WinRM

LDAP authentication probes

Even failed attempts are valuable for attackers, and equally valuable for defenders when properly logged.

Objective

Simulate lateral movement attempts that:

Use valid but limited credentials

Use intentionally invalid passwords for failure-only tests

Attempt access across multiple hosts

Generate authentication and network logs

Example: Simulated SMB Authentication Attempts

A common lateral movement pattern is SMB authentication to multiple hosts using the same credential.

SMB Command Example

smbclient -L \\10.0.5.12 -U sim_user%FakePassword123

This command attempts authentication and access to shares (fails safely) without executing arbitrary code or writing data.

Automating via Splunk SOAR

Splunk SOAR can orchestrate these attempts using a secure test host or VM:

phantom.act( 

    action="run command", 

    parameters=[{ 

        "command": "smbclient -L \\\\10.0.5.12 -U sim_user%FakePassword123" 

    }], 

    assets=["windows_test_host"], 

    name="Simulated SMB Lateral Movement" 

)

Detection Opportunities

Defenders should look for:

Repeated authentication attempts across hosts

Same username targeting multiple systems

Lateral movement without prior endpoint activity

Failed authentication spikes followed by success

These patterns are ideal for correlation searches and behavioral detections.

Safety Considerations

Use non-privileged accounts

Limit target scope to lab or tagged hosts

Disable administrative shares and write access

Post-Exploitation Enumeration Simulation: Benign Command Execution

Attacker Context

Command execution is where simulations often become risky. However, many attacker commands are informational rather than destructive. Commands like whoami, ipconfig, or uname can reveal important context without changing system state.

Objective

Safely emulate attacker enumeration command execution to generate process creation logs and trigger EDR and SIEM detections while avoiding system modification.

Example: Benign Discovery Commands

Windows:

whoami 

ipconfig /all 

net user

Linux:

id 

uname -aWindows Remote Management integratio 

hostname

Commands of this nature mimic attacker enumeration and are widely used post-exploitation.

Automating via Splunk SOAR

Using the Windows Remote Management integration we can remotely execute commands through secure management channels:

phantom.act( 

    action="run command", 

    parameters=[{ 

        "command": "whoami && ipconfig /all" 

    }], 

    assets=["windows_test_host"], 

    name="Simulated Post-Exploitation Command Execution"

Detection Opportunities

Defenders should look for:

Command execution by service accounts

Execution without interactive logon

LOLBins (cmd.exe, powershell.exe) launched remotely

Command patterns associated with known TTPs

Detection engineering teams can validate that expected alerts fire when these commands run.

Safety Considerations

Block shell redirection and file writes

Disable PowerShell remoting unless explicitly needed

Use constrained language mode where possible

Never execute persistence or privilege-escalation commands

Validating Detections with SOAR

One of Splunk SOAR’s biggest advantages is closed-loop validation. After running a simulation, SOAR can query Splunk to confirm detections fired:

index=security EventCode=4688 CommandLine="*whoami*"

If no results are found, SOAR can open a detection gap ticket, notify detection engineers, and log a regression in detection coverage. This transforms simulations into measurable security outcomes.

Conclusion

Automated penetration test simulations sit at the intersection of offensive security and defensive. By using Splunk SOAR to orchestrate controlled, logged, and safe attacker behaviors, organizations can continuously validate their visibility, detections, and response workflows.

Rather than replacing traditional penetration tests, SOAR-driven simulations amplify their value, turning isolated findings into continuous assurance. For SOCs and security engineers alike, this purple team approach brings adversary techniques out of the abstract and into measurable, repeatable actions.

Ready to automate your security operations and make SOAR work for you? Explore how Splunk SOAR playbooks can transform your SOC.

About the Author

Kelsea Boyd is an experienced Automation Engineer and Splunk SOAR practitioner with a strong background in security engineering, red team operations, and software development. She has worked extensively with Splunk SOAR and other automation platforms to streamline incident response processes, reduce manual workloads, and enhance threat detection capabilities. Kelsea holds the Offensive Security Certified Professional (OSCP) certification and has hands-on experience with a wide range of penetration testing tools and programming languages.

She brings a versatile technical foundation to her work, having served in roles such as Purple Team Engineer, Security Engineer, and DevOps/SRE Engineer. Her contributions include developing and maintaining playbooks, integrating threat intelligence feeds, and building custom API connections. She has also supported PCI compliance efforts through vulnerability validation and remediation and participated in internal red team engagements to identify and mitigate security risks.

Kelsea’s development experience spans backend Java services, .NET applications, Kubernetes infrastructure, and IAM systems using SailPoint. Her early career included IT support and web application development, showcasing her adaptability and commitment to continuous learning.

Her technical toolkit includes Python, Java, C++, Go, Rust, and Bash, along with tools like Docker, Kubernetes, Git, and Splunk. She is passionate about building scalable, secure automation solutions that empower security teams and improve operational efficiency.