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):

FieldOperatorValue
nameISWindows: Multiple Logon Failure Followed by Logon Success

Platform: Windows (PowerShell)

Actions (3 steps, sequential):

StepActionCommandLogic
1Block attacker IPnetsh advfirewall firewall add rule name="Block-Brute-Force-$(adversary.ip)" dir=in action=block remoteip="$(adversary.ip)" enable=yesAlways run
2Disable the compromised usernet user $(target.user) /active:noRun on success
3Force logout all sessionslogoff $(target.user)Run on success

What Happens

  1. The correlation rule detects that 10+ failed logins from IP 203.0.113.45 were followed by a successful login as john.doe

  2. The alert fires: "Windows: Multiple Logon Failure Followed by Logon Success"

  3. SOAR matches the trigger and sends the commands to the Windows agent on the affected server

  4. The attacker's IP is blocked at the Windows Firewall level

  5. The john.doe account is disabled — no further logins are possible

  6. Any active sessions for john.doe are 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:

StepCommand
Block IPiptables -A INPUT -s $(adversary.ip) -j DROP
Disable userusermod -s /sbin/nologin $(target.user)
Kill sessionspkill -KILL -u $(target.user)

Enhanced version — add notification:

StepCommandLogic
4curl -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:

FieldOperatorValue
nameISRDP 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:

VariableTypeValue
firewallIpRegular10.0.0.1
fwApiTokenSecret(FortiGate API token)

Actions (2 steps):

StepActionCommandLogic
1Block IP on FortiGate firewall via APISee command belowAlways run
2Log the block actionecho "$(date): SOAR blocked $(adversary.ip) on firewall for alert $(name)" >> /var/log/soar-firewall-blocks.logAlways 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

  1. Unified Security Stack detects 15+ failed RDP login attempts from 203.0.113.99 in 5 minutes

  2. The correlation rule fires: "RDP Brute Force Attack"

  3. SOAR matches the trigger and sends the command to the Linux proxy agent

  4. The proxy calls the FortiGate REST API to create an address object and deny policy for 203.0.113.99

  5. The 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:

FieldOperatorValue
nameISPowerShell Empire Detection

Platform: Windows (PowerShell)

Actions (4 steps):

StepActionCommandLogic
1Kill the malicious processtaskkill /F /IM $(log.winlogEventDataProcessName)Always run
2Delete the malware artifactRemove-Item -LiteralPath "$(target.file)" -Force -RecurseRun on success
3Disable the compromised usernet user $(target.user) /active:noAlways run
4Force logoutlogoff $(target.user)Run on success

What Happens

  1. Unified Security Stack detects PowerShell Empire command patterns in Windows Event Logs

  2. The alert fires with the process name, target file, and compromised user populated from the log data

  3. SOAR kills the malicious PowerShell process immediately

  4. The Empire payload file is deleted from disk

  5. The compromised user account is disabled

  6. 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:

FieldOperatorValue
nameISVolume Shadow Copy Deletion

Platform: Windows (PowerShell)

Actions (4 steps):

StepActionCommandLogic
1Kill the suspicious processtaskkill /F /IM $(log.winlogEventDataProcessName)Always run
2Disable the usernet user $(target.user) /active:noAlways run
3Force logoutlogoff $(target.user)Always run
4Isolate the host`Get-NetAdapterDisable-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:

FieldOperatorValue
nameISWindows: PowerShell Keylogging Script

Platform: Windows (CMD)

Actions (2 steps):

StepActionCommandLogic
1Kill by PIDtaskkill /F /PID $(log.winlogEventDataProcessId)Always run
2Kill 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:

  1. Block the attacker IP on the local firewall (built-in action)

  2. Block the IP on the perimeter firewall (proxy agent + API call)

  3. Disable the compromised user (built-in action)

  4. Kill active sessions (built-in action)

  5. Send a Slack notification (custom action)

  6. 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."}