Detecting Azure and Entra ID abuse through telemetry and rules

At a glance

What this is: This is a detection-focused walkthrough showing how Azure Activity, Entra ID, and Storage logs can be correlated to surface abuse patterns across cloud identity and resource layers.

Why it matters: It matters because IAM and cloud security teams need detections that tie identity events to privilege changes and storage activity, not isolated alerts that miss the attack chain.

Context

Microsoft Azure and Microsoft Entra ID sit at the centre of cloud identity control, so abuse in that layer can quickly turn into privilege escalation, persistence, or data exposure. The governance gap is not whether telemetry exists, but whether identity, role, and storage events are connected well enough to expose malicious behaviour before it blends into normal administration.

In this article, Wazuh focuses on telemetry collection and detection rules rather than abstract cloud security advice. That distinction matters for IAM and cloud security teams because the real question is whether the control plane produces enough identity and access evidence to support actionable detections.

The underlying pattern is familiar in cloud breaches and red-team exercises: legitimate services, application credentials, federated trust, and storage access are abused as if they were routine operations. That makes detection engineering, not just configuration review, the practical boundary between visibility and compromise.

Key questions

Q: What breaks when Azure and Entra ID telemetry is not correlated for detection?

A: Isolated logs miss the sequence that turns a routine identity change into abuse. A role assignment, new application credential, or SAS token event may look normal on its own, but together they reveal escalation, persistence, or exfiltration. Without correlation, security teams get fragments instead of a defensible attack narrative.

Q: Why do service principal and federated credential changes create persistence risk?

A: Because those changes can give an attacker a trusted way to authenticate without reusing the original intrusion path. Once a new credential or federation link exists, the identity can keep working like legitimate automation. That makes application and managed identity changes high-value signals for cloud monitoring.

Q: What are the signs that Azure storage activity is being abused for exfiltration?

A: Look for SAS URL generation, unusual blob access, storage key usage, and storage events that follow identity or role changes. Exfiltration often uses permitted mechanisms rather than obvious malware. The warning sign is not simply volume, but access method combined with recent privilege expansion.

Q: How should cloud teams respond to privilege escalation and consent abuse in Entra ID?

A: They should treat those events as identity compromise indicators, not only administrative changes. The response should focus on the affected application, the roles it gained, the authentication paths it can still use, and any storage or resource access those permissions enable. The goal is to contain the trust path, not just the alert.

Technical breakdown

Azure and Entra ID telemetry as a detection plane

Azure Activity logs, Entra ID Audit logs, Sign-in logs, and Storage diagnostic logs create a detection plane across administrative actions, identity changes, authentication events, and storage access. The technical value is not any single log source, but the correlation between them. A role assignment by itself may be routine, while the same event paired with a new credential, abnormal sign-in, or suspicious storage access becomes a higher-confidence abuse signal. That is why cloud identity detection depends on joining control-plane and identity-plane telemetry rather than reviewing each stream in isolation.

Practical implication: build detections that correlate role, identity, and storage events in the same investigation path.

Service principals, federated credentials, and persistence

In Entra ID, service principals and federated identity credentials can become persistence mechanisms when attackers add new authentication material to an existing application. That changes the detection problem from a one-time intrusion to long-lived access that looks like trusted automation. The critical issue is that application changes, credential creation, and consent events often appear administrative unless rules explicitly treat them as identity-bound access expansion. In cloud terms, persistence is not always a hidden implant. It can be a legitimate identity object modified to keep authenticating after the initial foothold.

Practical implication: alert on application credential changes and federated trust additions as potential persistence events.

Storage telemetry and exfiltration paths

Azure Storage logs matter because exfiltration often uses authorized mechanisms such as SAS URLs, blob access, or storage key abuse instead of noisy download tools. These access paths are especially risky because they can look like normal application activity while bypassing interactive authentication. Detection therefore depends on monitoring access method, not just data volume. When storage events line up with prior privilege changes or unusual identity activity, they can reveal the transition from account compromise to data theft. The mechanism is operationally simple, but the governance impact is large because storage permissions often outlive the identity changes that made them dangerous.

Practical implication: monitor SAS usage, storage key events, and blob access as potential exfiltration indicators.

Threat narrative

Attacker objective: The objective is durable cloud control that enables privilege expansion, stealthy persistence, and access to sensitive Azure data or resources.

1. Entry begins with abuse of legitimate Azure and Entra ID access paths, including application credentials, consent grants, and privileged role assignments.
2. Credential access and persistence follow when the attacker creates or modifies service principal credentials, federated identity credentials, or managed identity trust.
3. Escalation occurs when the attacker uses elevated roles such as root-scope access or abuses cloud permissions to expand control across resources.
4. Impact is achieved through storage exfiltration, resource lock removal, or other actions that preserve access and enable unauthorized data access or destructive change.

Breaches seen in the wild

• Storm-1283 OAuth apps abuse 2023: Storm-1283 added secrets to new and existing OAuth apps in Entra ID and used them to run Azure cryptomining VMs, costing victims up to $1.5 million.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

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 identity abuse is now a telemetry correlation problem, not a log collection problem. Azure, Entra ID, and storage events already contain the evidence of role abuse, credential manipulation, and exfiltration paths. The failure mode is treating each stream as a separate alert source instead of a chained identity narrative. Practitioners need detections that reconstruct the access story across control plane and identity plane.

Application credentials are a persistence primitive in cloud environments. A service principal, federated credential, or managed identity can outlive the administrator who created it and still authenticate as trusted infrastructure. That creates a governance gap around lifecycle ownership, not just secret hygiene. The practical conclusion is that identity objects with delegated trust must be monitored as durable access assets.

Storage access is often the last visible step in an identity compromise chain. By the time SAS usage or blob access becomes obvious, the access decision has already happened upstream in identity and role configuration. That is why cloud security teams should treat storage logs as confirmation evidence, not the first place to look. Detection quality depends on seeing the entitlement change before the data movement.

Wazuh's value in this pattern is analytical, not architectural. The article shows how detection logic can connect Azure Activity, Entra ID, and Storage telemetry into usable alerts. That matters because many teams already have the logs but still lack rules that distinguish normal administration from abuse. The control problem is not absence of data, but absence of meaningful correlation.

Identity blast radius: cloud compromise expands when one credential or role can alter multiple identity and storage planes. The article repeatedly shows that a single identity change can create persistence, privilege escalation, and exfiltration paths across Azure. That means the governance unit is no longer the individual log event. Practitioners should manage the blast radius of each identity object and its downstream permissions.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.

What this signals

Azure and Entra ID abuse is best understood as an identity lifecycle problem expressed through cloud telemetry. Once application credentials, federated trust, or elevated roles are created, the useful detection question is whether the event can be tied to a legitimate change request or an abuse chain. That is where identity governance and detection engineering meet.

Identity blast radius: the practical unit of control is not the account alone but every resource it can still reach after a role or credential change. Teams that only monitor sign-ins will miss the downstream use of storage and administrative permissions. Correlation across identity, privilege, and storage events is the programme-level control that changes outcomes.

For practitioners

• Build cross-plane correlation rules Join Azure Activity, Entra ID Audit and Sign-in logs, and Storage telemetry so role assignments, credential changes, and data access can be evaluated together.
• Alert on application credential changes Treat new client secrets, federated identity credentials, and managed identity trust additions as high-risk identity events rather than routine admin changes.
• Monitor storage access methods Track SAS URL usage, blob access, and storage key-related activity for exfiltration patterns that bypass interactive authentication.
• Review privilege escalation paths Map subscription-level role assignments and root-scope access changes to the identities that can create them, then flag abnormal elevation patterns.
• Validate diagnostic coverage Confirm that Entra ID, Azure Activity, and Storage diagnostic settings are exporting the categories needed for identity abuse detection.

Key takeaways

• Azure and Entra ID abuse often hides inside legitimate cloud administration, which is why separate event review is not enough.
• Credential creation, federated trust changes, and privileged role assignments are the control points that determine whether persistence can stick.
• Teams that correlate identity, role, and storage telemetry can detect abuse earlier and narrow the blast radius before data leaves the environment.

Key terms

• Cloud Identity Correlation: Cloud identity correlation is the process of linking identity signals across cloud services, accounts, and workloads to determine whether they belong to the same person, machine, or session. It combines attributes such as usernames, tokens, device data, IPs, and activity patterns to improve detection, governance, and access decisions.
• Federated Credential: A federated credential lets a workload authenticate through trusted external identity assertions instead of storing a long-lived secret. It reduces secret sprawl, but it still depends on correct trust configuration, scope control, and lifecycle management to avoid turning trust exchange into silent overreach.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• SAS-Based Exfiltration: Data theft that uses a Shared Access Signature token or similar storage access method instead of obvious malware. It matters because the access can look legitimate while still enabling unauthorized reads, downloads, or exports from blob and storage services.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.