Detecting Lateral Movement Through Identity Signals

By the time a lateral movement alert fires on a network sensor, the attacker has usually already authenticated as someone — often several someones. The credential, not the packet, is the artifact that carries an intrusion from a single compromised laptop to the domain controller, the backup vault, and the crown-jewel database. This article lays out the architecture, telemetry, and analytics required to catch that movement while it is still happening, using identity as the primary sensor grid rather than an afterthought bolted onto network detection.

The perimeter moved to the identity plane, and detection has not caught up

Ten years ago, lateral movement detection was a network problem: watch east-west traffic, flag unusual SMB or RDP flows, and alert on new host-to-host connections that did not match a baseline. That model assumed a flat, observable network and a relatively small set of trust boundaries — a firewall here, a VLAN there. It does not survive contact with modern estates: hybrid identity providers spanning Active Directory and Entra ID, SaaS applications each with their own authorization model, Kubernetes workloads that authenticate with short-lived tokens, and cloud IAM roles that can be assumed across account boundaries in milliseconds. The network path an attacker takes is now almost incidental; the meaningful path is the chain of identities and entitlements that let a single stolen credential reach further than it should.

This is why identity threat detection and response (ITDR) has become its own discipline, distinct from both traditional identity and access management (IAM) and traditional network detection and response. IAM answers "who is allowed to do what." ITDR answers "who is actually doing what, right now, and does that behavior deviate from what their role, history, and peer group would predict." Lateral movement, in almost every framework from MITRE ATT&CK to real-world incident response reports, is fundamentally an identity behavior anomaly: a credential authenticating somewhere it has never authenticated before, a service account suddenly performing interactive logons, a low-privilege user requesting a Kerberos ticket for a service it has no business relationship with.

The practical consequence for engineers and SOC analysts is that the highest-leverage telemetry for catching lateral movement is not NetFlow or packet capture — it is authentication logs, directory service events, privileged session recordings, and entitlement change history. Building a detection program around that telemetry, and wiring it into automated response, is the subject of this article. We will walk through the attacker playbook, the signal taxonomy, a reference architecture, concrete detection logic, non-human identity coverage, PAM as an enforcement layer, governance feedback loops, and the metrics that tell you whether the program is actually working.

The attacker's identity playbook: how lateral movement actually unfolds

To detect lateral movement you have to understand its mechanics in enough depth to know which log source will show the tell. Almost every real-world intrusion that progresses beyond initial access follows a recognizable sequence: establish a foothold identity, harvest additional credentials or tokens, use those credentials to reach a new host or resource, and repeat until the attacker reaches a target with the access needed for the mission objective — data exfiltration, ransomware deployment, or destructive action.

Credential harvesting techniques

Once inside, adversaries rarely need to exploit a new vulnerability to move — they need a new credential. Common techniques include:

• LSASS memory dumping (via tools like Mimikatz or built-in Windows APIs) to extract plaintext passwords, NTLM hashes, and Kerberos tickets cached on a compromised host.
• Kerberoasting, requesting service tickets for accounts with a Service Principal Name and cracking the ticket offline to recover the service account password, particularly effective against over-privileged service accounts with weak passwords.
• Pass-the-hash and pass-the-ticket, reusing captured NTLM hashes or Kerberos tickets to authenticate as another user without ever knowing the plaintext password.
• Token theft and impersonation on Windows hosts, hijacking an existing authenticated session token from a higher-privileged process.
• Cloud credential and metadata service abuse, reading instance metadata endpoints or environment variables to extract cloud IAM role credentials, API keys, or OAuth refresh tokens left in configuration files, CI/CD pipelines, or container images.
• Session cookie and token theft from browsers or SaaS sessions, increasingly common as adversary-in-the-middle phishing kits bypass MFA by stealing the post-authentication session token rather than the password.

Movement techniques

With a harvested credential in hand, the attacker moves using entirely legitimate administrative protocols — which is precisely why this is hard to detect with signature-based tools:

• WMI and PowerShell Remoting (WinRM) to execute commands on remote hosts using domain credentials.
• RDP with harvested credentials, often chained through jump hosts that were never intended to be internet-reachable but are reachable from the compromised segment.
• SMB and admin shares (C$, ADMIN$) for file staging and remote service creation.
• Cloud role assumption chains, where an attacker assumes role A, which trusts role B, which trusts role C, walking a trust graph that was never reviewed as a whole because each individual trust relationship looked reasonable in isolation.
• SaaS-to-SaaS OAuth pivoting, using a compromised identity's delegated OAuth grants to reach connected applications without triggering a new authentication event at all.

Every one of these techniques leaves a trace in identity telemetry, even though none of them trip a traditional IDS signature. That is the central opportunity: the raw signal exists, almost everywhere, in authentication and directory logs that most organizations already collect but do not correlate at the level of granularity required to see the pattern.

The signal taxonomy: what identity telemetry actually tells you

Not all identity telemetry is equally useful for lateral movement detection, and treating it as an undifferentiated log stream is a common early-stage mistake. It helps to organize signals into four categories, each with different collection mechanics, latency characteristics, and false-positive profiles.

Authentication telemetry

This is the highest-volume, lowest-latency category: Windows Security Event Log 4624/4625/4648/4672/4768/4769/4776, Entra ID and Okta sign-in logs, SSH auth logs, VPN concentrator logs, and SaaS application login events. The critical fields for lateral movement detection are logon type (interactive versus network versus service), authentication package (NTLM versus Kerberos), source workstation, and whether the logon used a cached credential versus a fresh one. A Kerberos ticket-granting-service request (4769) for a service account followed shortly by an interactive logon (4624 type 2 or 10) using that same account is a textbook Kerberoasting-to-lateral-movement chain.

Directory and entitlement change telemetry

Group membership changes, new SPN registrations, delegation flag modifications (particularly unconstrained or resource-based constrained delegation grants), password reset events, and privileged group additions. These events are lower volume but disproportionately high signal — an attacker adding a compromised account to Domain Admins, or granting a service account unconstrained delegation, is one of the highest-confidence indicators available anywhere in the stack.

Privileged session and PAM telemetry

When privileged access is brokered through a PAM platform rather than direct credential use, you gain session-level telemetry: which vaulted credential was checked out, by whom, for how long, what commands were typed or what screens were recorded, and whether the session was terminated by policy. This is qualitatively richer than raw authentication logs because it captures intent and sequence, not just the fact of authentication.

Behavioral and contextual telemetry

User and entity behavior analytics (UEBA) baselines built from the above three categories: typical logon hours, typical source hosts, typical resource access patterns, typical peer-group behavior for a role. Deviations — a service account logging in interactively for the first time in its operational history, a user authenticating from a host they have never used, a machine identity suddenly calling an API it has never called — are the highest-value derived signals because they require an attacker to either replicate months of legitimate behavior or accept detection risk.

The reference architecture described in the next section exists to ingest these four categories from dozens of disparate sources, normalize them into a common identity event schema, and correlate across them in near real time — because any single category, viewed alone, produces either too many false positives or arrives too late to stop the movement.

Reference architecture: building the ITDR pipeline

A production-grade identity threat detection pipeline has five layers, and skipping any one of them is the most common reason ITDR programs stall at the pilot stage.

Collection layer

Collect directly from the identity fabric rather than relying solely on downstream SIEM forwarding, which frequently drops or truncates the fields needed for lateral movement detection (source workstation name, ticket encryption type, delegation flags). For Active Directory, this means enabling and forwarding the full Advanced Audit Policy category for Account Logon and Logon/Logoff events, not just the default audit policy. For cloud identity providers, subscribe to the native audit and sign-in log streams (Entra ID sign-in and audit logs via Microsoft Graph, Okta System Log via the API, AWS CloudTrail with data events enabled for IAM and STS, GCP Admin Activity and Data Access logs). For PAM platforms, ensure session metadata and command-level logs are exported, not just checkout/checkin timestamps.

Normalization and enrichment layer

Every source has its own schema. A durable pipeline maps all events into a common identity event model with a small set of required fields: actor identity (with a resolved canonical identifier across AD SID, cloud principal ARN, and SaaS user ID), target resource, action, source location (host, IP, or cloud region), authentication method, and outcome. Enrichment adds context that raw logs lack: is this identity privileged, is this host a Tier 0 asset, is this the identity's usual working hours, does this identity normally interact with this resource. This enrichment step is where an asset inventory, an entitlement store, and an HR feed (for joiner/mover/leaver status) all need to be joined against the event stream — and it is the step most home-grown SIEM correlation rules skip, which is why they generate so much noise.

Detection and response layer

This layer runs three complementary detection strategies simultaneously: deterministic correlation rules for known attack patterns, graph-based analytics for entitlement and session-path abuse, and behavioral baselining for novel or living-off-the-land techniques. None of the three is sufficient alone. Rules catch known techniques fast but miss variants; graph analytics catch structural risk (a path from a compromised low-privilege account to a Tier 0 asset) but do not by themselves indicate an attack is in progress; behavioral models catch novel deviations but need weeks of baseline data and tend to have a higher false-positive rate during onboarding.

Platforms such as Algomox CyberMox integrate these three strategies into a single detection surface, correlating identity signals with endpoint and network telemetry inside an AI-driven XDR alert triage workflow, so an analyst sees a single prioritized case — "compromised service account, unconstrained delegation, lateral movement to Tier 0 host" — instead of six unrelated alerts from six tools that each saw a fragment of the same kill chain.

Detection mechanics: rules, graphs, and behavioral baselines with worked examples

Concrete detection logic separates a working ITDR program from a slide deck. Below are patterns that map directly onto the attacker techniques described earlier, expressed as correlation logic an engineer can implement against a normalized identity event stream.

Kerberoasting-to-movement chain

Detection logic: flag any account where a TGS request (event 4769) uses RC4 encryption (etype 0x17) for a service account that historically only receives AES-encrypted requests, followed within a configurable window (commonly 30–120 minutes) by an interactive or network logon (4624 type 2, 3, or 10) using that same account from a host that is not the account's designated service host. The RC4 downgrade is itself suspicious in an AES-capable domain because it is the artifact left by offline ticket-cracking tools; the subsequent logon confirms the cracked credential was used.

Pass-the-hash detection

Pass-the-hash logons characteristically show NTLM authentication (event 4624 with authentication package NTLM) for an account whose normal authentication package is Kerberos, combined with a logon type 3 (network) that does not present a corresponding interactive logon on the source host in the endpoint telemetry. The absence of a matching interactive session on the claimed source machine is the tell: a legitimate user who is actually sitting at that workstation would show up in the EDR process tree; an attacker replaying a hash from a different, already-compromised host will not.

Unconstrained delegation abuse

Any change event granting the TRUSTED_FOR_DELEGATION flag, or adding a Resource-Based Constrained Delegation entry (msDS-AllowedToActOnBehalfOfOtherIdentity), on an account that is not already on an approved delegation allow-list should generate a high-severity alert immediately — this is a directory change signal, not a behavioral one, and needs no baseline period to be actionable.

Impossible travel and session anomalies for cloud/SaaS identities

Two successful authentications for the same identity from geographically distant locations within a time window that makes physical travel impossible is a classic detection, but its value has degraded as attackers route through residential proxies near the victim's actual location. A stronger companion signal is device and session fingerprint discontinuity: a new device ID, a new TLS/JA3 fingerprint, or a session that begins with a token replay (no corresponding MFA challenge) rather than a fresh interactive login.

Graph-based lateral movement path analysis

Beyond individual events, build an attack path graph from directory and entitlement data: nodes are identities and assets, edges are "can log on to," "can reset password of," "is a member of," "has delegation over." Running shortest-path and reachability analysis from every standard-tier user identity to every Tier 0 asset surfaces the same class of finding that tools like BloodHound made famous for red teams — except run continuously and defensively, it becomes a leading indicator: if a path shortens or a new edge appears (a new group membership, a new delegation grant), that is itself a detection-worthy event, independent of whether an active attack is underway. This graph should be recomputed on every entitlement change event, not on a weekly batch schedule, because the window between a privilege escalation and its abuse is frequently measured in minutes.

Non-human and workload identity baselining

Service accounts, API keys, and workload identities have far more regular behavior than humans, which makes them easier to baseline and any deviation more significant. A service account that has called the same three internal APIs at the same time window every day for six months and then, one afternoon, authenticates interactively to a workstation, or calls an API it has never called, or is used from a source IP outside its known infrastructure range, is an extremely high-confidence signal precisely because machine behavior has near-zero legitimate variance.

Non-human identities: the fastest-growing and least-governed attack surface

In most enterprise and cloud environments, non-human identities — service accounts, API keys, OAuth applications, workload identities, CI/CD pipeline credentials, and machine-to-machine certificates — now outnumber human identities by a wide margin, commonly cited at ratios between 10:1 and 50:1 depending on how aggressively an organization has adopted microservices and cloud automation. These identities are disproportionately represented in lateral movement incidents for three structural reasons: they are frequently over-privileged because it is easier to grant broad access once than to scope it precisely, they rarely rotate credentials because rotation risks breaking automation, and they are poorly owned because no single human is accountable for noticing anomalous behavior.

A workable non-human identity security program needs four controls working together. First, a complete inventory: you cannot detect anomalous behavior in an identity you do not know exists, and most organizations discover 20–40% more service accounts and API keys during a first inventory sweep than their IAM system of record shows. Second, ownership assignment: every non-human identity should map to an accountable human or team, both for incident response routing and for periodic access review. Third, scoped, short-lived credentials wherever the platform supports it — workload identity federation instead of long-lived cloud keys, certificate-based mutual TLS instead of static API keys, and Kerberos delegation scoped to specific services rather than unconstrained. Fourth, and most relevant to this article, behavioral monitoring specifically tuned for machine identities, since as noted above their tight behavioral envelope makes them some of the easiest identities to protect with UEBA once properly inventoried and baselined.

Workload identities in Kubernetes and service mesh environments add another layer: short-lived, automatically rotated tokens (via SPIFFE/SPIRE or cloud-native service account token projection) reduce the value of credential theft because a stolen token expires quickly, but they also mean detection must operate on token issuance and use patterns rather than static credential presence — an unusual pattern of token requests from a workload that has never needed cross-namespace access is the equivalent signal to an unusual interactive logon for a human account.

PAM as an enforcement control plane, not just a password vault

Privileged access management is frequently deployed as a password vault: check out a credential, use it, check it back in. That is necessary but not sufficient for lateral movement defense. The more valuable architecture treats PAM as a mediated control plane that brokers every privileged session, which turns PAM from a storage mechanism into a real-time detection and containment point.

Just-in-time privilege elevation

Standing privileged access is the single largest amplifier of lateral movement blast radius: an attacker who compromises an account with permanent Domain Admin rights has already won, regardless of how good detection is downstream. Just-in-time (JIT) elevation — granting privileged rights only for the duration of an approved task, then automatically revoking them — shrinks the window of opportunity from "always" to "minutes," and every elevation request becomes a discrete, loggable, and approvable event rather than an ambient state. Well-implemented JIT ties elevation requests to a ticketing system or change record, so an elevation with no corresponding change ticket is itself a detection signal.

Session brokering and isolation

Routing privileged RDP, SSH, and database sessions through a PAM jump/proxy layer means the end user or admin never actually holds the raw credential — the PAM broker injects it at the session layer. This has two detection benefits: it makes credential theft from the client endpoint far less useful (there is no plaintext credential to steal from that machine), and it produces a complete, replayable session record (keystrokes, screen recording, or at minimum command history) that is invaluable both for real-time anomaly detection and post-incident forensics.

Real-time session analytics

A modern PAM deployment should feed session telemetry into the same detection pipeline as authentication and directory logs, watching for command sequences associated with credential harvesting (execution of known dumping tool names or their renamed variants, unusual LDAP queries against the directory, disabling of security tooling) and terminating or flagging the session automatically when those patterns appear. This is the point at which PAM stops being a preventive control and becomes a live detection sensor with the authority to kill a session mid-attack.

Vaulting and rotation discipline

Automatic, frequent rotation of vaulted credentials (ideally after every checkout, at minimum on a fixed schedule measured in hours or days rather than months) limits the value of any credential an attacker manages to exfiltrate from the vault or intercept in transit. Rotation cadence should be risk-tiered: Tier 0 domain and cloud root credentials rotated after every single use, lower-tier service account passwords on a daily or weekly cycle.

Algomox's approach to this layer, delivered through identity and privileged access management capabilities, is to treat PAM telemetry as a first-class input to the same detection engine that consumes directory and endpoint signals, so a privileged session anomaly and a directory change anomaly on the same account within the same time window are automatically correlated into one incident rather than triaged separately by two different teams.

Identity governance as a detection multiplier: closing the entitlement loop

Identity governance and administration (IGA) is usually framed as a compliance function — access certifications, joiner/mover/leaver workflows, segregation-of-duties reporting. Its detection value is under-appreciated: governance data tells you what access should exist, which is exactly the baseline against which anomalous access can be measured, and governance events are themselves leading indicators of increased blast radius.

Entitlement drift as a precursor signal

Entitlement drift — access that accumulates over time as employees change roles without corresponding removal of prior access — is not itself an attack, but it is the single largest reason lateral movement, once achieved, succeeds in reaching a high-value target. A compromised account belonging to someone who changed roles three times and kept every prior group membership has a dramatically larger reachable footprint than a tightly scoped one. Feeding current entitlement state into the attack path graph described earlier means governance data directly narrows or widens the computed blast radius for every identity in real time.

Toxic combinations and segregation of duties

Certain entitlement combinations are dangerous together even when each is individually reasonable: the ability to create a new user account combined with the ability to add that account to a privileged group, or the ability to approve one's own access request. These toxic combinations are exactly the conditions attackers exploit once they compromise any single account holding both halves of the combination, and they should be modeled explicitly in the governance layer and surfaced to the detection graph as elevated-risk nodes.

Access certification as a detection tuning input

Periodic access reviews, when done well, generate a valuable signal: entitlements that reviewers repeatedly reject or flag as unnecessary should raise the baseline risk score of the identities and resources involved, even before removal is completed, so that detection thresholds tighten automatically for the riskiest parts of the entitlement graph rather than waiting for the certification campaign to close out administratively.

A continuous exposure management view that spans identity governance, misconfiguration, and vulnerability data is the natural home for this correlation, since entitlement drift is, functionally, a form of exposure. Programs built around a continuous threat exposure management discipline treat over-provisioned identity as an exposure class alongside unpatched software and open ports, prioritizing remediation by actual reachability to critical assets rather than by raw count of findings.

Metrics and decision frameworks: proving the program works

ITDR programs need metrics that are specific to identity behavior, not repurposed network security KPIs. The following set has proven useful across mature deployments.

• Mean time to detect (MTTD) for lateral movement specifically, measured from the first anomalous authentication event in an attack chain to the first analyst-actionable alert, tracked separately from overall SOC MTTD because identity chains often span hours before culminating in an obvious action.
• Standing privileged access ratio: the percentage of privileged entitlements that are permanent versus just-in-time, trending toward a lower ratio as JIT adoption matures.
• Credential dwell time: average time a vaulted credential remains unrotated after checkout, and average time an unused entitlement remains on an identity before removal.
• Detection coverage against ATT&CK lateral movement techniques (TA0008): a mapped scorecard of which sub-techniques have validated detection logic, tested against a red-team or purge-team exercise at least quarterly.
• False-positive rate per detection rule, tracked individually rather than in aggregate, because a single noisy rule can consume a disproportionate share of analyst time and mask genuine signal from cleaner rules.
• Non-human identity inventory completeness: percentage of discovered service accounts, API keys, and workload identities with an assigned human owner and an active rotation policy.
• Blast radius reduction: median graph distance from a standard user identity to the nearest Tier 0 asset, tracked over time as a direct measure of whether governance and PAM controls are shrinking attacker reachability.
• Alert-to-containment time: elapsed time from a confirmed lateral movement alert to automated or manual containment action (session termination, credential revocation, account disablement), which is the metric most directly tied to actual breach cost reduction.

A useful decision framework for tuning detection thresholds is to separate rules by required confidence tier. Directory change events like unconstrained delegation grants warrant automated high-severity alerting with no tolerance for delay, because the false-positive cost of an urgent page is low relative to the risk of a missed privilege escalation. Behavioral deviations for human identities warrant a lower automatic severity and a short observation window, because human behavior has legitimate variance (a new laptop, a business trip) that machine behavior does not. Non-human identity deviations warrant near-zero tolerance thresholds precisely because their legitimate variance is so low.

Worked example: tracing a real intrusion chain through identity signals

Consider a representative incident pattern, assembled from common elements seen across public incident response reporting, to make the abstract detection logic concrete. An attacker gains initial access via a phishing email that harvests a standard user's credentials and MFA session token through an adversary-in-the-middle proxy. The first identity signal is a sign-in event from a new device fingerprint that nonetheless presents a valid, already-satisfied MFA claim — a token replay pattern rather than a fresh challenge, visible in the identity provider's sign-in log if session provenance is logged, and easy to miss if only "MFA satisfied: yes/no" is monitored rather than the full authentication method chain.

From that foothold, the attacker enumerates the directory using LDAP queries characteristic of BloodHound-style collection — a burst of directory reads against group membership and ACL attributes from a single workstation, itself a detectable volumetric anomaly against the account's historical query pattern. The attacker identifies a service account with a Service Principal Name and requests a Kerberos service ticket, downgrading to RC4 encryption to enable offline cracking — the Kerberoasting signal described earlier. After cracking the password offline, the attacker authenticates interactively as the service account from the original compromised workstation, producing an interactive logon type that the service account has never previously exhibited in six months of baseline behavior — a clean UEBA deviation on a non-human identity.

The service account, it turns out, has local administrator rights on a file server used by IT operations, discoverable because someone once needed it for a migration project and the right was never removed — an entitlement drift finding that, had it been flagged in the last access certification cycle, would have shrunk this exact blast radius. From the file server, the attacker uses cached credentials from a domain admin who had recently logged on for maintenance, and pivots to the domain controller using pass-the-hash, visible as an NTLM authentication for an account whose normal authentication package is exclusively Kerberos.

Reconstructed after the fact, this chain touches four distinct identity signal categories — authentication method anomaly, directory enumeration volume, entitlement/behavioral deviation on a non-human identity, and authentication package mismatch on a human identity — each individually plausible as noise, but forming an unambiguous chain when correlated by actor and time window. This is precisely the correlation a mature ITDR pipeline, with graph-aware detection and PAM session telemetry, is built to surface within minutes rather than reconstruct in a post-incident timeline weeks later. It is also exactly the kind of cross-domain case that benefits from being triaged inside an agentic SOC workflow, where an AI analyst assembles the four fragments into one case, proposes containment (disable the service account, force domain admin credential rotation, terminate the active session), and hands a fully-scoped incident to a human for approval rather than four separate low-context tickets.

Deployment considerations across cloud, on-prem, and air-gapped environments

Identity signal collection and correlation architecture differs meaningfully by deployment model, and a program designed only for cloud-native SaaS identity will fail in a hybrid or sovereign environment.

Cloud and SaaS-first environments

Here the primary identity fabric is the cloud IdP (Entra ID, Okta, or similar) plus cloud provider IAM. Signal collection is largely API-based and near-real-time, but graph analysis must span multiple trust domains — cross-account role assumption in AWS, cross-tenant guest access in Entra ID, and OAuth app-to-app grants in SaaS — because lateral movement in this model is as likely to cross a SaaS boundary as a network segment.

Hybrid enterprise environments

Most large enterprises still run Active Directory as the authoritative identity source for on-prem infrastructure, federated or synchronized to a cloud IdP. The detection architecture must correlate AD Kerberos and NTLM events with cloud sign-in events for the same human identity, which requires a reliable identity resolution layer mapping AD SIDs to cloud principal IDs — a surprisingly common integration gap that leaves a blind spot exactly at the hybrid seam, which is also where attackers increasingly pivot (compromising an on-prem account to reach cloud resources via synced credentials, or the reverse).

Air-gapped and sovereign environments

Air-gapped deployments cannot rely on cloud-hosted SIEM or analytics back ends, and often cannot call out to cloud threat intelligence feeds for enrichment. The detection pipeline — collection, normalization, graph analytics, and behavioral baselining — must run entirely within the isolated boundary, with locally maintained entitlement graphs and locally trained behavioral baselines rather than shared cloud models. This is a first-class deployment target for platforms built with an AI-native architecture designed to run detection and analytics models on-premises or fully disconnected, since many identity threat detection vendors assume constant cloud connectivity for their analytics layer and simply cannot operate in these environments without significant re-architecture. Sovereign deployments additionally require that any behavioral model training data and entitlement graphs remain within jurisdictional boundaries, which rules out shared multi-tenant analytics models entirely and requires per-environment model instances.

Operationalizing detection: SOC workflow, playbooks, and tuning discipline

A detection architecture without a disciplined operational workflow around it produces alert fatigue rather than security outcomes. Three practices separate programs that sustain value from those that decay into ignored dashboards.

Tiered playbooks by confidence and blast radius

Not every identity anomaly warrants the same response. A useful playbook structure ties response action to a combination of detection confidence and the blast radius of the affected identity: high-confidence, high-blast-radius findings (confirmed unconstrained delegation grant on an account with domain admin membership) trigger automated containment — session kill, credential rotation, account disable — without waiting for analyst approval. Medium-confidence findings on high-blast-radius identities trigger immediate analyst paging with a pre-assembled investigation package (recent authentication history, entitlement changes, peer comparison). Lower-blast-radius anomalies queue for batch review rather than real-time paging, preserving analyst attention for the findings that matter.

Continuous detection validation

Detection rules and behavioral models decay as environments change — new applications introduce new legitimate authentication patterns, organizational restructuring changes normal peer-group behavior, and attackers adapt techniques to evade known detections. Quarterly purple-team exercises that specifically emulate the lateral movement techniques in the table above, run against the live detection pipeline rather than a lab environment, are the only reliable way to confirm coverage has not silently eroded. Track detection validation results against the ATT&CK coverage scorecard mentioned in the metrics section so gaps are visible and prioritized rather than assumed away.

Feedback loop from response back to governance

Every confirmed lateral movement incident should generate a governance action, not just a containment action: if the incident succeeded because of entitlement drift, that drift should trigger a targeted access review; if it succeeded because a service account lacked an owner, ownership assignment should be enforced before the account is re-enabled; if it succeeded because a PAM policy allowed standing access to a Tier 0 asset, that policy should be tightened to just-in-time. Without this loop, the same structural weakness produces the same class of incident repeatedly, and the SOC ends up detecting the same failure mode faster each time rather than eliminating it.

Frequently asked questions