Why does threat hunting often expose identity risk as well as attacker activity?

Why This Matters for Security Teams

Threat hunting is most useful when it looks past alerts and asks how an intruder would actually operate inside an enterprise. That usually means credentials, sessions, privilege changes, token use, and authentication paths, not just endpoint events. The NIST Cybersecurity Framework 2.0 is helpful here because it reinforces the need to connect detection with response, asset context, and access control rather than treating them as separate problems.

Identity risk shows up because many attacks succeed by using legitimate access after initial compromise. A hunt that ignores directory logs, cloud audit trails, PAM activity, and service account behaviour can miss the attacker’s real tradecraft and focus only on noisy downstream effects. That is especially true in hybrid environments where one identity can cross SaaS, cloud, and on-premises systems without tripping a single control.

The practical mistake is assuming identity issues are just an IAM hygiene concern. In reality, hunt findings often expose weak offboarding, stale privileged accounts, over-broad API keys, or authentication flows that were never instrumented for detection. In practice, many security teams encounter identity abuse only after suspicious lateral movement has already occurred, rather than through intentional identity-led hunting.

How It Works in Practice

Effective threat hunting starts by mapping likely attacker objectives to the identities and privileges they would need. That includes valid accounts, delegated admin roles, service principals, machine identities, and recovery paths that bypass normal user controls. Teams typically combine endpoint, cloud, and directory telemetry with authentication metadata so they can reconstruct not just what happened, but which identity made it possible. The MITRE ATT&CK Enterprise Matrix is useful for structuring these hypotheses around initial access, persistence, privilege escalation, and lateral movement.

In practice, a hunt often follows a few recurring questions:

• Which identities authenticated from unusual geography, device posture, or time window?
• Which accounts gained privilege shortly before suspicious activity?
• Which API keys, tokens, or service accounts were used outside their normal workload patterns?
• Which offboarding events left active access, shared credentials, or orphaned secrets behind?

Identity-focused hunting also benefits from control validation. If the logging chain is incomplete, the hunt may need to inspect SaaS audit logs, cloud IAM events, PAM checkout activity, and directory synchronization records. Current guidance suggests building detections around changes in identity state as much as suspicious actions, because attackers often move from compromise to persistence through trust relationships that appear normal in endpoint telemetry. The CISA cyber threat advisories are a strong source for current tactics and operational indicators that can be translated into hunt hypotheses.

These controls tend to break down when identity data is fragmented across multiple directories, cloud tenants, and SaaS platforms because analysts cannot reliably join authentication events to privilege changes and resource access.

Common Variations and Edge Cases

Tighter identity telemetry often increases operational overhead, requiring organisations to balance richer detection against logging cost, privacy constraints, and analyst workload. Not every environment can centralize every identity signal, and best practice is evolving for how much identity context should be retained for hunt use versus compliance use.

One edge case is machine-to-machine activity. Service accounts, workload identities, and API tokens may behave “normally” at high volume, so simple anomaly rules can create false positives unless baseline expectations are tied to workload purpose. Another is agentic AI or automation platforms that use broad execution authority. If those systems are not treated as identities with scoped permissions, hunt teams may miss abuse patterns that look like legitimate automation. For that reason, emerging guidance increasingly links identity governance with AI and automation risk, but there is no universal standard for this yet.

When AI systems participate in the attack path, the hunt scope may need to include prompt abuse, tool access misuse, and agent credential exposure alongside traditional identity signals. The MITRE ATLAS adversarial AI threat matrix helps when hunting for model or agent abuse, while the Anthropic report on the first AI-orchestrated cyber espionage campaign illustrates how automation can accelerate identity misuse and operational scaling. Current guidance suggests treating those intersections as a shared identity and detection problem rather than a pure AI issue.

Related resources from NHI Mgmt Group

• How should organisations prove identity governance is reducing risk, not just activity?
• Why do developer workstations create NHI risk as well as human identity risk?
• Why do declarative identity environments create governance risk as well as speed?
• Why do acquisitions often increase identity risk?