Cloud threat hunting depends on identity visibility, not just logs

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Crogl's blog post: Cloud threat hunting depends on identity chains, API telemetry and control plane logs, and missing logging coverage can turn null results into false confidence.

Why it matters: This matters because cloud compromise paths often pivot through service principals, roles and temporary credentials, so hunters need identity-aware hypotheses and a documented view of what the environment actually records.

Context

Cloud threat hunting is a hypothesis-driven search for adversary activity across cloud control planes, identity systems and workloads. In hybrid environments, the evidence often sits in different log sources with different retention rules, so a hunt can look complete while still missing the data needed to prove or disprove the theory.

The operational problem is not simply log volume. It is uneven coverage across identity, API and control plane telemetry, which makes a null result ambiguous unless the team has already mapped what is recorded, where it is stored and how long it is retained. service accounts and workload identities are often the pivot point when attackers move from access to persistence.

Hybrid cloud environments make this challenge worse because on-prem habits do not transfer cleanly to cloud hunting. The starting assumption for a cloud hunt should be that visibility is fragmented until proven otherwise.

Key questions

Q: How do cloud threat hunts use identity telemetry?

A: Cloud threat hunts use identity telemetry to trace who or what performed actions across cloud control planes, federation chains and workload credentials. That includes service principals, role assumption, OAuth grants and temporary tokens. The goal is to connect authenticated actions to adversary behaviour instead of relying only on endpoint events or network indicators.

Q: Why do cloud logging gaps create false negatives in hunts?

A: Cloud logging gaps create false negatives because hunts can only see the events that were actually collected. If identity logs, control plane audit trails, network flow records, or endpoint telemetry are missing, suspicious actions can blend into the unseen period. A coverage map shows which sources exist, their retention, and blind spots, so analysts can separate true absence from missing evidence.

Technical breakdown

Identity chains in cloud compromise

Cloud compromise often follows the identity chain rather than the host chain. Attackers do not need to smash through network segments when they can abuse service principals, role assumption, OAuth grants or temporary instance credentials to move between cloud resources. In practice, the relevant evidence lives in audit logs, sign-in logs and control plane events, not just endpoint telemetry. Hunters therefore need to think in terms of authenticated actions, not only suspicious binaries or sockets. The same identity object can be legitimate in one context and malicious in another, which is why hypotheses have to name the identity type and the cloud service together. See the Cloud Workload Identity Guide.

Practical implication: Start hunts by enumerating the identity objects and log sources most likely to show privilege abuse, not by querying generic cloud noise.

Why cloud logging defaults create blind spots

Cloud platforms often log control plane actions more consistently than data plane activity. That means a team may see account changes, role creation or configuration edits while missing the object-level API calls that reveal data access or exfiltration. Retention also varies by source and often differs between the cloud provider, the SIEM and any downstream archive. A hunt that assumes all relevant events are present will produce misleading null results. The technical issue is not just collection gaps, but the mismatch between the question being asked and the telemetry that was actually enabled when the activity occurred. See the Cloud Incident Response Guide.

Practical implication: Document which data plane events are enabled, retained and searchable before a hunt begins.

Translating hunts across cloud and on-prem systems

Hybrid hunts fail when analysts treat cloud and on-prem logs as interchangeable. Cloud queries usually speak in provider-specific APIs and identity objects, while on-prem investigations rely on host telemetry, Windows events and SIEM syntax. Correlating an Entra ID object ID with an on-prem SID, or an Azure activity with an endpoint process tree, introduces a translation step at every pivot. That translation tax slows analysis and can break chain-of-evidence if the team does not preserve the intermediate results. The mechanism is architectural, not procedural: different telemetry stacks encode the same actor in different ways.

Practical implication: Preserve the original query logic and identity mappings so evidence survives pivots between cloud and endpoint sources.

Threat narrative

Attacker objective: The attacker aims to turn valid cloud identity access into durable reach across cloud services and associated data.

1. Entry occurs through compromised cloud identity material such as service principal credentials, OAuth application access or temporary instance metadata credentials.
2. Escalation follows when the attacker uses valid cloud permissions to assume roles, register or modify principals, or access resources that ordinary endpoint telemetry would not reveal.
3. Impact comes from persistent access to mailboxes, storage, control plane actions or other cloud assets that can be reached without triggering traditional perimeter alerts.

Breaches seen in the wild

• ConnectWise Cloud Backup breach 2026: A stolen ConnectWise Cloud Backup app secret gave attackers sign-ins to 160+ Microsoft 365 tenants, then admin roles via sibling service principals.
• Malwarebytes breach 2021: SolarWinds attackers added a certificate to a dormant email security app's service principal at Malwarebytes and read internal email via Microsoft Graph.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud threat hunting is an identity problem first: the dominant pivot in many cloud intrusions is not a device or subnet, but a service principal, role or temporary credential. That makes cloud hunting different from conventional infrastructure hunting because the adversary can operate entirely through valid cloud identities. Hunters who do not model identity chains will miss the path from initial access to persistence.

Log coverage is part of the control surface: a hunt cannot be interpreted safely until the team knows which control plane and data plane events are enabled, retained and searchable. Missing diagnostics do not just reduce fidelity, they can manufacture false negatives that look like clean results. This is why coverage mapping belongs in the hunt design, not as an afterthought.

Null results are evidence only when they are auditable: a hunt that returns nothing is meaningful only if the organisation can show what was searched, which logs were available and where coverage stopped. That makes documentation a governance control, not a paperwork exercise. The practitioner conclusion is simple: a cloud hunt without a defensible evidence trail is not a completed hunt.

Identity chains create a distinct governance gap: cloud programmes often treat identities as configuration objects, but attackers treat them as the shortest path between trust boundaries. That creates what can be called an identity visibility gap, where service principals, federated roles and temporary credentials are present but not equally observable. The governance response is to treat visibility into those chains as a prerequisite for credible cloud detection and response.

Cloud hunting maturity depends on coverage discipline: teams that can explain where the logs stop are better positioned to separate attacker absence from telemetry absence. That discipline is what turns hybrid hunting from an ad hoc search into a repeatable security capability. The practitioner conclusion is that visibility baselines must be managed as deliberately as detections.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — What are Non-Human Identities

What this signals

Identity visibility will become the deciding factor in cloud hunt quality: teams that cannot see service accounts, role chains and temporary credentials well enough will keep mistaking telemetry gaps for clean environments. The practical shift is toward hunt programmes that treat observability into cloud workload identities as a baseline requirement, not an advanced enhancement.

Coverage discipline will matter as much as detection logic. If hunters cannot explain which log sources were on, retained and queryable at the time of the hunt, the result is difficult to defend to auditors or incident responders.

Hybrid operations will keep raising the cost of manual pivots between cloud logs, SIEM queries and endpoint telemetry. That makes federated search and preserved evidence trails more valuable because they reduce translation loss without diluting the original records.

For practitioners

• Map cloud hunt coverage before writing hypotheses Inventory which cloud control plane and data plane logs exist, where they are retained and how long they are searchable before you start a hunt.
• Build identity-focused hunt hypotheses Name the service principal, role chain or credential type, the cloud service involved and the expected adversary behaviour in each hypothesis.
• Document null results as evidence Record the hypothesis, exact query logic, sources searched and any coverage gaps so a null result can stand up to audit review.
• Correlate cloud and endpoint telemetry carefully Preserve object IDs, SIDs and time normalization steps when a hunt pivots between cloud logs, SIEM searches and EDR data.

Key takeaways

• Cloud threat hunting fails when identity chains are ignored, because attackers often move through cloud services using valid principals and temporary credentials.
• Provider logging defaults can make a search look complete while still hiding the data plane evidence needed to confirm or dismiss a hypothesis.
• A defensible hunt depends on mapped log coverage, identity-aware hypotheses and documentation that preserves null results as well as findings.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs: What are Non-Human Identities · Cloud Workload Identity Guide · Cloud Incident Response Guide · Threat Hunt Hypothesis and Report Template

Key terms

• Cloud Threat Hunting: Cloud threat hunting is the proactive search for hidden threats, suspicious behavior, and misconfigurations across cloud environments before alerts confirm an incident. It combines log analysis, identity telemetry, network signals, workload activity, and configuration data to uncover stealthy compromise, privilege abuse, and lateral movement in IaaS, PaaS, and SaaS.
• Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.
• Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
• Data Plane: The data plane is where operational access to content occurs, including prompts, outputs, logs, training data, and secrets. In AI governance, this is the layer where over-privileged identities often expose sensitive information even when the control plane appears tightly managed.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It helps practitioners connect identity controls to the wider security programmes they operate.