SOP-06: Lateral Movement Detection & Response

Lateral movement is an attacker technique used to progressively access additional systems within a network after gaining an initial foothold. The attacker reuses stolen credentials, exploits trust relationships between hosts, or abuses legitimate remote administration tools to reach higher-value targets — file servers, domain controllers, backup systems, or databases holding sensitive data.

Common objectives: credential harvesting, data exfiltration staging, ransomware deployment prep, persistence on critical systems, and reaching a Domain Controller to perform DCSync or Golden Ticket attacks.

Log Sources

Severity Scale

Answer these before spending time investigating. A NO to all five = probable FP. Any YES = continue investigation.

• 1
  Is the account a privileged account (Domain Admin, local admin, service account with broad rights)? If YES — escalate to L2 immediately while continuing investigation.
• 2
  Did the source host have a malware or EDR alert in the last 24 hours? Pull the alert timeline in Defender: security.microsoft.com → Incidents & Alerts → filter by device
• 3
  Is the logon type 3 (Network) or 10 (Remote Interactive / RDP)? LogonType 2 = interactive console = not lateral movement. LogonType 3/10 between two workstations = suspicious.
• 4
  Is this a first-time connection between the source and destination host in the last 30 days? Baseline the pair — first-time connections are high-signal.
• 5
  Did the logon result in process execution on the destination host immediately after? (WMI child process, service install Event 7045, cmd.exe / powershell.exe spawned by WmiPrvSE)

Map every network logon out of the source host. This tells you how many systems the attacker touched and with which accounts. Replace DEVICE_NAME with the source device from the alert.

PTH generates NTLM authentication from workstations (not the DC). Normal NTLM auth routes through DCs. When you see NTLM auth where the target accepts it directly from another workstation, that's PTH.

PTT reuses a stolen Kerberos TGT. The telltale sign: a service ticket (Event 4769) being requested for a service on a host that the legitimate user never accessed, or a TGS request from an unexpected source IP.

After lateral logon, attackers execute code on the target. Look for the classic remote execution patterns on the destination host(s) you identified in I2.

Determine the full blast radius before containing. This query maps the account across the entire fleet in the last 24 hours. Run this before isolating — you need the full list.

Use this to make the call before escalating. Document your verdict and evidence in the incident ticket.

Isolate every host in your blast radius list from I6. Use Full Isolation — this blocks all network except Defender telemetry, so you keep visibility while cutting the attacker off.

• 1
  Go to security.microsoft.com → Assets → Devices
• 2
  Search for the device. Click the device name to open the device page.
• 3
  Click ... → Isolate device → Full isolation. Add incident number in the comment field.
• 4
  Repeat for every host in the blast radius list. Prioritize: source host first, then hosts with admin shares accessed, then general workstations.
• 5
  Confirm isolation status: device page shows "Isolated" badge under device name.

Block the compromised account entirely while investigation continues. Do this in this order — each step escalates the lockdown.

• 1
  Block sign-in: portal.azure.com → Entra ID → Users → [user] → Edit properties → Account enabled → NO → Save
• 2
  Revoke all active sessions: Users → [user] → Revoke sessions — kills all current tokens and refresh tokens immediately.
• 3
  Reset password: Users → [user] → Reset password → Auto-generate → copy temp password — out-of-band delivery to user's manager, not email (attacker may have inbox access).
• 4
  Clear MFA methods and force re-registration: Users → [user] → Authentication methods → Delete all methods — prevents attacker from approving MFA prompts.
• 5
  Confirm risky user in Identity Protection: Entra ID → Security → Identity Protection → Risky users → [user] → Confirm user compromised

Block the attacker's movement channels while you eradicate. These are temporary rules — remove after eradication is confirmed.

• 1
  Block SMB inbound on affected hosts (port 445, 139) via host firewall or NSG rule targeting the attacker's source IP range. In Defender: security.microsoft.com → Settings → Endpoints → Indicators → IP addresses → Add indicator → Block
• 2
  Block RDP inbound (port 3389) from all non-IT subnets to the affected hosts. If RDP is not required between workstations — block it fleet-wide at the firewall.
• 3
  Block WinRM (5985/5986) inbound if WMI exec was detected. Check with IT before applying — this may break legitimate management tools.
• 4
  Conditional Access block for compromised account: Entra ID → Security → Conditional Access → New policy → Users: [compromised account] → Grant: Block access → Enable policy

If I6 showed the compromised account reached a DC, or if DCSync activity is detected, these actions are non-negotiable. Escalate to L3 / IR Team before proceeding — these steps affect the entire domain.

• 1
  Isolate all DCs that the attacker touched via Defender XDR — same process as C1.
• 2
  Disable all attacker-touched admin accounts at the DC level via ADUC or PowerShell: Disable-ADAccount -Identity "username"
• 3
  Check for DCSync: In Defender Advanced Hunting, look for replication requests from non-DC sources:
  IdentityQueryEvents | where QueryType == "Dcerpc" | where ActionType == "LdapSearch" | where Protocol == "MS-DRSR"
• 4
  Initiate first krbtgt password reset (two resets required, 10h apart). Coordinate with L3 / Domain Admin — this will force all existing Kerberos tickets to be re-issued. Do NOT do this without L3 sign-off.

Lateral movement often drops persistence before moving on. Check all affected hosts for these artifacts via Live Response in Defender XDR.

Access Live Response

• 1
  security.microsoft.com → Assets → Devices → [device] → Initiate Live Response session

Attackers frequently create backdoor admin accounts or add themselves to privileged groups. Audit this during the attacker's activity window.

• 1
  For every attacker-created account found: Entra ID → Users → [account] → Delete
• 2
  For every unauthorized group membership: Entra ID → Groups → [group] → Members → Remove [account]
• 3
  For local accounts on endpoint: Live Response → run cmd /c "net user ATTACKER_ACCOUNT /delete"

If PTH was confirmed, the attacker has the NTLM hash. A session revoke is NOT enough — the hash remains valid until the password is changed. Reset all accounts that were logged on to any of the compromised hosts during the attack window.

• 1
  Pull all accounts that had active sessions on compromised hosts during the attack window from DeviceLogonEvents.
• 2
  Force password reset for each: Entra ID → Users → [user] → Reset password → Require change at next sign-in
• 3
  For on-prem AD accounts: Set-ADAccountPassword -Identity "username" -Reset -NewPassword (ConvertTo-SecureString "TempPass123!" -AsPlainText -Force) then Set-ADUser -Identity "username" -ChangePasswordAtLogon $true
• 4
  If PTT confirmed: initiate second krbtgt reset 10h after the first reset from C4.

After all cleanup steps are complete, re-run the identification queries from Section 2 on a 1-hour window from current time. Expected result: zero new lateral movement events from the attacker's accounts and hosts. If you still see activity — the attacker has another foothold. Loop back to I2.

Document the full attack timeline and close the vector that enabled lateral movement. Without closing the entry point, the same attacker or another actor will repeat the same path.

• 1
  Identify patient zero: The host where the NTLM hash or Kerberos ticket was stolen from. Use the earliest timestamp from I2 and trace backward — what happened on that host before the lateral movement started? (Cross-reference with SOP-03 for malware triage on patient zero.)
• 2
  Close the vector: PTH? → Enable LAPS, enforce Credential Guard, disable NTLM where possible. PTT? → Enforce AES256 Kerberos, disable RC4. PsExec? → Block Admin share access via GPO. RDP? → Restrict via Conditional Access + IP allowlist.
• 3
  Document the timeline in the incident ticket: T0 (initial compromise), T1 (first lateral move), T2 (containment), T3 (eradication complete). Include all affected hosts and accounts.

Escalate from L1 to L2 when any of the following are true. Do not wait 30 minutes — if the trigger is met, escalate immediately and continue working in parallel.

• 1
  L1 cannot determine TP vs FP within 30 minutes of initial triage
• 2
  The compromised account is a privileged account (Domain Admin, local admin on servers, service account with elevated rights)
• 3
  Lateral movement confirmed across 3 or more hosts
• 4
  Any server (file server, database, backup server, domain controller) is in the affected host list
• 5
  PTH or PTT is confirmed — NTLM hash or Kerberos ticket stolen

• 1
  Lateral movement reached a domain controller — any DC in affected host list
• 2
  DCSync detected — replication requests from non-DC source (check IdentityQueryEvents)
• 3
  Ransomware indicators on any affected host (file renames, shadow copy deletion) — cross-reference SOP-05
• 4
  Data exfiltration suspected — large outbound transfers, cloud upload tools, compress-and-send patterns detected in DeviceNetworkEvents
• 5
  Attacker has maintained access for more than 4 hours undetected before this alert — dwell time investigation required

• 1
  Domain Admin credentials compromised — entire domain potentially under attacker control
• 2
  krbtgt hash exposure suspected — Golden Ticket attack possible; requires domain-wide remediation
• 3
  Customer data, PII, or regulated data at risk (GDPR, PCI-DSS, HIPAA) — legal and compliance notification timelines start now
• 4
  Attacker has reached critical infrastructure systems (production databases, ERP, financial systems, OT/SCADA)
• 5
  Active ransomware deployment in progress across multiple hosts