How should SOC teams handle attacker behaviour that looks like normal user activity?

Why normal-looking activity needs context, not just signatures

When attacker behaviour blends into ordinary work, the SOC has to judge the action in context, not just whether it matches a known indicator. The practical shift is from “is this malicious code?” to “does this sequence make sense for this identity, device, session, and process at this moment?” That is what separates behavioural realism from routine user activity.

Signals that matter are often weak in isolation. A login, API call, file access, or admin action may look legitimate until you combine it with unusual timing, impossible travel, atypical process ancestry, a new device posture, or a session that behaves differently from the user’s normal pattern. That is why context is not enrichment, it is part of the detection logic.

For identity and session context, the strongest baseline is usually the user or workload’s normal access pattern, including what they typically touch, from where, and through which path. Insider Threat and Identity Guide is useful here because behavioural analytics only works when the SOC understands how access and privilege should look before it decides something is suspicious.

How SOC detections should combine identity, device, and process context

Effective detections should join identity context with endpoint and runtime context so the alert is about a sequence, not a single event. A valid login followed by privilege escalation, mailbox access, script execution, or token use can be far more meaningful than any one action on its own. The same action may be routine for a service account and highly unusual for a human user, so the identity of the actor changes the interpretation.

Device context helps distinguish trusted from untrusted execution paths. Managed endpoints, compliant devices, known browser profiles, and expected geographies tend to reduce uncertainty, while new hosts, abnormal user agents, or suspicious parent-child process chains increase it. The SOC should treat those differences as evidence about intent, not just hygiene.

Process context is equally important because attackers frequently hide inside living-off-the-land activity. A shell, script host, remote admin tool, or browser process can be benign in one workflow and highly suspicious in another. SANS Security Resources is relevant because detection engineering depends on understanding how benign operational patterns differ from adversary tradecraft.

That is also why detection teams should keep their rule logic open to sequence-based conditions such as “new device plus sensitive action,” “new privilege plus lateral movement,” or “rare process plus exfiltration-ready destination.” Those combinations are more resilient than simple indicators because they model the way real attackers try to look normal.

What good behavioural detection looks like in practice

Good detection does not mean alerting on everything unusual. It means knowing which deviations are meaningful for a given identity, workload, and business process. The SOC should be able to explain why an action is suspicious in plain terms, such as “this account never uses this host,” “this service normally calls one API but is now enumerating many,” or “the process chain does not match the approved admin workflow.”

That explanation matters because analyst triage improves when the alert carries the story of the activity, not just the anomaly score. Context-aware detection should also feed response decisions: isolate the endpoint, step up verification, suspend the session, or review the privilege path when the sequence suggests real compromise. MITRE D3FEND is a useful companion because it helps translate suspicious behaviour into defensive countermeasures that match the observed technique.

At scale, the hardest problem is reducing false confidence. A model can label many actions as “normal” simply because they resemble a user’s historical behaviour, even when that history has already been compromised. The SOC therefore needs to watch for behaviour that is normal-looking but wrong in sequence, timing, or access scope.

Practitioner Guidance

What to prioritise: Prioritise detections that join identity, session, device, and process context for the same actor. A single alert on a login or command is rarely enough; the deciding factor is whether the sequence fits the actor’s established operating pattern.

What to verify: Verify that the baseline is current and role-aware. If a user changed role, location, device, or access path, stale behavioural models can turn real abuse into noise or normal work into false positives.

Common mistake: Do not tune solely for known malware patterns. Behavioural realism is often the attacker’s advantage, so the control must look for intent, sequence, and abnormal privilege use, not just bad hashes or obvious tool names.

Practitioner takeaway: The most reliable SOC judgement is not “does this look malicious?” but “does this activity make sense for this actor, on this device, in this session, and in this order?”

Related resources from NHI Mgmt Group

• How should teams handle agentic traffic that looks like normal customer behaviour?
• How should security teams handle AI-generated phishing that looks like normal business mail?
• How should security teams detect attacks that look like normal user activity?
• Why do bot controls fail when automation looks like normal user activity?