Use Cases
This page reviews practical SOAR use cases, each with full workflow setups that you can tailor to your own environment. Every use case covers the threat scenario, trigger setup, action sequence, and the automated response it produces.
Use Case 1: Block a Compromised User Account
Scenario
An attacker obtains a user's credentials via phishing or credential stuffing. Unified Security Stack sees several suspicious actions tied to the same user account — attempts to escalate privileges, access to sensitive resources, or lateral movement. The SOAR workflow promptly disables the account and ends every active session before the attacker can do more harm.
Threat Indicators
Multiple failed logins followed by a successful login from an unusual IP
User account added to an administrative group unexpectedly
Anomalous process execution under the user's context
Workflow Configuration
Trigger (matches the correlation rule alert):
| Field | Operator | Value |
|---|---|---|
name | IS | Windows: Multiple Logon Failure Followed by Logon Success |
Platform: Windows (PowerShell)
Actions (3 steps, sequential):
| Step | Action | Command | Logic |
|---|---|---|---|
| 1 | Block attacker IP | netsh advfirewall firewall add rule name="Block-Brute-Force-$(adversary.ip)" dir=in action=block remoteip="$(adversary.ip)" enable=yes | Always run |
| 2 | Disable the compromised user | net user $(target.user) /active:no | Run on success |
| 3 | Force logout all sessions | logoff $(target.user) | Run on success |
What Happens
The correlation rule detects that 10+ failed logins from IP
203.0.113.45were followed by a successful login asjohn.doeThe alert fires: "Windows: Multiple Logon Failure Followed by Logon Success"
SOAR matches the trigger and sends the commands to the Windows agent on the affected server
The attacker's IP is blocked at the Windows Firewall level
The
john.doeaccount is disabled — no further logins are possibleAny active sessions for
john.doeare terminated
Total time from detection to containment: Seconds, compared with minutes or hours when a response is manual.
Variations
Linux variant — same trigger concept, different commands:
| Step | Command |
|---|---|
| Block IP | iptables -A INPUT -s $(adversary.ip) -j DROP |
| Disable user | usermod -s /sbin/nologin $(target.user) |
| Kill sessions | pkill -KILL -u $(target.user) |
Enhanced version — add notification:
| Step | Command | Logic |
|---|---|---|
| 4 | curl -sk -X POST "https://hooks.slack.com/services/$[variables.slackWebhook]" -H "Content-Type: application/json" -d '{"text": "SOAR: Blocked user $(target.user) and IP $(adversary.ip) on $(dataSource). Alert: $(name)"}' | Always run |
Use Case 2: Block an IP on a Firewall
Scenario
Unified Security Stack identifies an RDP brute force attack targeting a Windows server. The attacker is originating from an external IP. Instead of only blocking the IP on the target server's local firewall, you want to block it at the perimeter firewall — preventing the attacker from reaching any system in your network.
This requires a proxy agent because the firewall does not run a Unified Security Stack agent.
Threat Indicators
Repeated failed RDP login attempts (Windows Event ID 4625) from the same external IP
High-severity alert: "RDP Brute Force Attack"
Workflow Configuration
Trigger:
| Field | Operator | Value |
|---|---|---|
name | IS | RDP Brute Force Attack |
Platform: Linux (Bash) — the proxy agent is a Linux server
Agent: Run on specific agent — select the Linux proxy that has SSH/API access to the firewall
Automation Variables needed:
| Variable | Type | Value |
|---|---|---|
firewallIp | Regular | 10.0.0.1 |
fwApiToken | Secret | (FortiGate API token) |
Actions (2 steps):
| Step | Action | Command | Logic |
|---|---|---|---|
| 1 | Block IP on FortiGate firewall via API | See command below | Always run |
| 2 | Log the block action | echo "$(date): SOAR blocked $(adversary.ip) on firewall for alert $(name)" >> /var/log/soar-firewall-blocks.log | Always run |
Step 1 command (FortiGate REST API):
curl -sk -X POST "https://$[variables.firewallIp]/api/v2/cmdb/firewall/address"
-H "Authorization: Bearer $[variables.fwApiToken]"
-d '{"name": "soar-block-$(adversary.ip)", "subnet": "$(adversary.ip)/32"}'
&& curl -sk -X POST "https://$[variables.firewallIp]/api/v2/cmdb/firewall/policy"
-H "Authorization: Bearer $[variables.fwApiToken]"
-d '{"name": "soar-deny-$(adversary.ip)", "srcaddr": [{"name": "soar-block-$(adversary.ip)"}], "dstaddr": [{"name": "all"}], "action": "deny", "schedule": "always", "service": [{"name": "ALL"}]}'What Happens
Unified Security Stack detects 15+ failed RDP login attempts from
203.0.113.99in 5 minutesThe correlation rule fires: "RDP Brute Force Attack"
SOAR matches the trigger and sends the command to the Linux proxy agent
The proxy calls the FortiGate REST API to create an address object and deny policy for
203.0.113.99The attacker is now blocked at the perimeter — cannot reach any internal system
Alternative: SSH-based firewall block
If the firewall doesn't have a REST API, use SSH:
ssh -o StrictHostKeyChecking=no -i $[variables.fwSshKey] admin@$[variables.firewallIp]
"config firewall address
edit soar-block-$(adversary.ip)
set subnet $(adversary.ip)/32
end"Alternative: pfSense, Palo Alto, Cisco ASA
This same approach works for any firewall — simply replace the API call or SSH command for the platform you are targeting. See the Proxy Agents page for more examples.
Use Case 3: Stop a Malicious Process or Ransomware
Scenario
Unified Security Stack spots indicators of ransomware or malicious process execution — PowerShell Empire activity, suspicious keylogging scripts, or unauthorized file encryption. The SOAR workflow right away terminates the malicious process, removes the payload, disables the compromised user, and optionally isolates the host to block lateral movement.
Threat Indicators
PowerShell Empire detection (characteristic command patterns, encoded payloads)
Volume Shadow Copy deletion (common ransomware precursor)
Keylogging scripts detected via Windows API function calls
Anomalous process execution patterns
Workflow Configuration: PowerShell Empire Response
Trigger:
| Field | Operator | Value |
|---|---|---|
name | IS | PowerShell Empire Detection |
Platform: Windows (PowerShell)
Actions (4 steps):
| Step | Action | Command | Logic |
|---|---|---|---|
| 1 | Kill the malicious process | taskkill /F /IM $(log.winlogEventDataProcessName) | Always run |
| 2 | Delete the malware artifact | Remove-Item -LiteralPath "$(target.file)" -Force -Recurse | Run on success |
| 3 | Disable the compromised user | net user $(target.user) /active:no | Always run |
| 4 | Force logout | logoff $(target.user) | Run on success |
What Happens
Unified Security Stack detects PowerShell Empire command patterns in Windows Event Logs
The alert fires with the process name, target file, and compromised user populated from the log data
SOAR kills the malicious PowerShell process immediately
The Empire payload file is deleted from disk
The compromised user account is disabled
All sessions for that user are terminated
Workflow Configuration: Ransomware Response (Maximum Containment)
For confirmed ransomware, you may want to escalate to full host isolation:
Trigger:
| Field | Operator | Value |
|---|---|---|
name | IS | Volume Shadow Copy Deletion |
Platform: Windows (PowerShell)
Actions (4 steps):
| Step | Action | Command | Logic |
|---|---|---|---|
| 1 | Kill the suspicious process | taskkill /F /IM $(log.winlogEventDataProcessName) | Always run |
| 2 | Disable the user | net user $(target.user) /active:no | Always run |
| 3 | Force logout | logoff $(target.user) | Always run |
| 4 | Isolate the host | `Get-NetAdapter | Disable-NetAdapter -Confirm:$false` |
Step 4 (host isolation) turns off all network adapters. The agent will lose its connection to Unified Security Stack. Physical or out-of-band access (iLO, iDRAC, console) will be needed to recover the machine. Use this only for confirmed critical threats where halting the attack is worth more than losing remote access.
Workflow Configuration: Keylogger Response
Trigger:
| Field | Operator | Value |
|---|---|---|
name | IS | Windows: PowerShell Keylogging Script |
Platform: Windows (CMD)
Actions (2 steps):
| Step | Action | Command | Logic |
|---|---|---|---|
| 1 | Kill by PID | taskkill /F /PID $(log.winlogEventDataProcessId) | Always run |
| 2 | Kill by name (fallback) | taskkill /F /IM $(log.winlogEventDataProcessName) | Run on failure |
This uses the Run on failure logic: if termination by PID fails (the process has already restarted with a new PID), use termination by process name as a fallback.
Combining Use Cases
You can combine these use cases into broad response workflows. For instance, a complete brute force response could:
Block the attacker IP on the local firewall (built-in action)
Block the IP on the perimeter firewall (proxy agent + API call)
Disable the compromised user (built-in action)
Kill active sessions (built-in action)
Send a Slack notification (custom action)
Create a Jira ticket (custom action)
By chaining built-in actions, proxy-based commands, and custom API calls, you can build end-to-end automated response workflows that span your entire infrastructure — from endpoints to firewalls to cloud services to ticketing systems."}