Docs

Appearance

Kill Chain — Lateral Movement Agent Response ​

When this fires: lateral_movement_agent detected same account on 3+ machines within 30 minutes (EventID 4624 Type 3), explicit credential use workstation-to-server (EventID 4648 Type 9 or NewCredentials), or admin share access (EventID 5140 to C$ or ADMIN$).

Severity: CRITICAL — immediate notification, no analyst queue.

MITRE: T1021.002 (Remote Services: SMB/Windows Admin Shares), T1550.002 (Use Alternate Authentication Material: Pass the Hash)

Immediate Triage — Within 5 Minutes ​

  1. Open SecOps finding. Note: account, machines involved, detection subtype, timestamp
  2. Determine subtype:
    • multi_machine_logon — same account on 3+ machines in 30 min
    • explicit_cred_lateral — EventID 4648, explicit creds used workstation-to-server
    • admin_share_access — C$ or ADMIN$ share accessed from unexpected source
  3. Is this account a known IT admin performing routine work? Check CM tickets for the host(s) involved
  4. Check if this account also appears in credential dumping findings in the same window — if yes, this is likely pass-the-hash or pass-the-ticket

Investigation KQL ​

kql
// All machines this account authenticated to in the last hour
SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID in (4624, 4648)
| where TargetUserName == "<account>"
| where TargetUserName !endswith "$"
| extend Host = toupper(tostring(split(Computer, ".")[0]))
| project TimeGenerated, EventID, Host, LogonType, IpAddress, WorkstationName, TargetUserName
| order by TimeGenerated
kql
// Admin share access — what was accessed and from where?
SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 5140
| where ShareName in ("\\\\*\\C$", "\\\\*\\ADMIN$", "\\\\*\\IPC$")
| where Account == "<account>" or IpAddress == "<source_ip>"
| extend Host = toupper(tostring(split(Computer, ".")[0]))
| project TimeGenerated, Host, IpAddress, Account, ShareName, AccessMask
kql
// Did any of the accessed machines then make outbound connections?
CommonSecurityLog
| where TimeGenerated > ago(1h)
| where DeviceVendor == "Palo Alto Networks"
| where SourceIP in ("<ip1>", "<ip2>", "<ip3>")
| project TimeGenerated, SourceIP, DestinationIP, SentBytes, ApplicationProtocol
| order by SentBytes desc

Scope Assessment ​

List all machines that this account touched. The scope assessment determines how broad the isolation must be.

Number of Machines CompromisedResponse Level
1–2 machinesDisable account, isolate machines, investigate
3–5 machinesCRITICAL — active spreading in progress, engage Arctic Wolf
6+ machines or includes a DC/serverFull incident response — isolate segment, initiate incident-response.md

Domain controllers appearing in the lateral movement path are the highest-risk target. If a DC is in the list of accessed machines, escalate immediately — a compromised DC means all credentials on the domain are potentially compromised.

Containment Steps ​

Step 1 — Disable the account:

Disable immediately — do not just reset the password. An attacker with a stolen hash or Kerberos ticket can still authenticate even after a password reset if the account is not disabled and sessions are not revoked.

powershell
# Disable in Active Directory
Disable-ADAccount -Identity "<sAMAccountName>"

# Revoke Entra sessions (cloud accounts)
# Entra → Users → [user] → Revoke sessions

Step 2 — Isolate the source host (where lateral movement originated):

  • Cortex XDR → Endpoints → [source host] → Actions → Isolate
  • This is the machine the attacker is using as a pivot

Step 3 — Isolate machines selectively:

Do NOT shut down all machines at once — you lose visibility and may destroy evidence. Isolate machines one at a time, starting with the source of the movement.

For domain controllers: do not isolate DCs unless you confirm they are the origin of the movement (not just a target). DC isolation breaks domain authentication for all machines.

Step 4 — Block the source IP at the firewall:

If the movement originates from a specific IP (e.g., an initially compromised workstation):

  • Panorama → Policies → Security → add inbound deny rule for that IP from reaching internal servers

Break-Glass Account Warning ​

If any break-glass account appears in 4648 or 5140 events:

  • This is unconditionally CRITICAL regardless of any other context
  • No allowlist check, no CM ticket exemption
  • Treat as confirmed active breach — initiate runbooks/incident-response.md immediately
  • Notify Rory via phone (not just Telegram) if break-glass accounts are involved

HIPAA Breach Assessment ​

If lateral movement reached:

  • psql-secops-prod
  • Any DDE environment host (Medicare app)
  • A file server or share with ePHI

Initiate the breach risk assessment immediately per compliance/hipaa-breach-notification-procedure.md.

Escalation ​

  • Rory immediately (automatic CRITICAL Telegram notification)
  • Arctic Wolf — especially if DCs are involved or movement has reached 3+ machines
  • Consider activating the full IR plan (runbooks/incident-response.md) if 5+ machines involved

Post-Incident Checklist ​

  • [ ] Compromised account disabled, sessions revoked, Kerberos tickets expired (krbtgt reset if DC involved)
  • [ ] All compromised hosts isolated or confirmed clean
  • [ ] Source of initial access identified (previous execution or credential dumping finding?)
  • [ ] Domain controller access checked — if a DC was touched, force-reset krbtgt password twice
  • [ ] Service accounts with privileged access — passwords rotated
  • [ ] HIPAA breach assessment completed
  • [ ] Full scope of compromised hosts documented in SecOps incident
  • runbooks/kill-chain-credential-dumping-response.md — lateral movement is usually preceded by credential dumping
  • runbooks/kill-chain-execution-response.md — execution often preceded this
  • runbooks/incident-response.md — full IR plan for widespread compromise
  • runbooks/active-directory-operations.md — krbtgt reset and AD recovery
  • compliance/hipaa-breach-notification-procedure.md

Internal use only — Cirius Group