How should security teams detect attacks that look like normal user activity?

Why This Matters for Security Teams

Attacks that resemble normal user activity are difficult because they often use valid credentials, approved channels, and ordinary business workflows. That makes signature-only detection weak, especially when adversaries time activity to blend into daily routines. Security teams need identity context, session visibility, and action sequencing to spot when behaviour is technically allowed but operationally unusual. Guidance in the NIST Cybersecurity Framework 2.0 supports this shift from isolated alerts to risk-based detection.

The practical challenge is that normality is not static. A user may legitimately change jobs, work locations, device patterns, or application usage, and a service account may have bursty behaviour during deployments. That means teams need a baseline that is tied to identity, role, device trust, and workload context, not just to IP reputation or login success. This is where SOC and IAM data need to be analysed together rather than in separate queues.

In practice, many security teams encounter stealthy abuse only after a trusted account has already been used to move laterally or exfiltrate data, rather than through intentional behavioural monitoring.

How It Works in Practice

Detection works best when the SOC builds layered context around each authenticated session. Start with identity signals such as user, service account, role, recent password resets, MFA changes, device posture, geolocation, and privilege level. Then compare those signals with behavioural baselines such as login cadence, resource access patterns, tool usage, command sequences, and data transfer volume. The goal is not to prove that activity is malicious in isolation, but to identify combinations that are unusual for that identity.

Teams often operationalise this with correlation rules, UEBA-style scoring, and investigation playbooks that include IAM logs, endpoint telemetry, cloud audit trails, and SIEM alerts. Mapping suspicious behaviours to attacker tradecraft helps analysts move faster. The MITRE ATT&CK Enterprise Matrix is useful for linking seemingly normal actions to known techniques such as valid accounts, remote services, or command-line abuse. For AI-enabled intrusion patterns, the MITRE ATLAS adversarial AI threat matrix is relevant when models, copilots, or agentic workflows are part of the operational path.

• Flag impossible combinations, such as privileged access from a new device followed by bulk downloads.
• Score sequences, not single events, because normal-looking steps can still form an attack chain.
• Prioritise accounts with elevated access, automation authority, or access to sensitive data.
• Confirm whether the behaviour aligns with change windows, deployments, or documented exceptions.

Threat intelligence can improve triage, but it should not replace behavioural context. Current guidance suggests using alerts from CISA cyber threat advisories to enrich detection logic, not to define it. These controls tend to break down in environments with poor log normalisation, shared accounts, or fragmented identity stores because the baseline becomes too noisy to trust.

Common Variations and Edge Cases

Tighter behavioural detection often increases analyst workload and false positives, requiring organisations to balance sensitivity against operational noise. There is no universal standard for what counts as normal behaviour across every business function, so teams need local baselines and documented exceptions rather than one global threshold.

Edge cases matter most in hybrid estates. Service accounts, break-glass accounts, contractors, and machine identities can all look “normal” while still being risky if their access patterns change unexpectedly. This is especially true in cloud and DevOps environments where automation can trigger large bursts of legitimate activity. In those cases, best practice is evolving toward identity-specific baselines, short-lived privilege, and session-level monitoring rather than broad user averages. The control philosophy in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because it supports continuous monitoring, auditability, and access control depth.

AI-driven detection also needs governance. If models are used to score behaviour, teams should validate training data quality, monitor model drift, and review false positives for bias against legitimate edge-case users. The Anthropic report on the first AI-orchestrated cyber espionage campaign report shows why adversaries increasingly rely on automation to scale human-like activity. That makes human review indispensable when anomalous activity is subtle, high impact, or tied to privileged identities.

Related resources from NHI Mgmt Group

• How should security teams detect email attacks that look legitimate at first glance?
• How should security teams handle credential abuse when breaches look like system intrusion?
• How should security teams detect AI-orchestrated attacks before exfiltration starts?
• How should security teams stop ClickFix attacks before the user reaches the endpoint?