Detecting Azure and Entra ID abuse through telemetry and rules

At a glance

What this is: This is a defensive guide showing how to detect Azure and Entra ID abuse by correlating cloud and identity logs with custom Wazuh rules.

Why it matters: It matters because Azure identity and role abuse often looks like normal administration until logs from Entra ID, Azure Activity, and storage are joined into one detection path.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.

👉 Read Wazuh's Azure and Entra ID detection guide for cloud abuse techniques

Context

Cloud identity abuse in Azure is often a governance problem before it is a malware problem. Service principals, managed identities, consent grants, and role assignments can all be used legitimately, which makes detection depend on whether identity activity is monitored alongside resource and storage events. In Microsoft Azure environments, Entra ID and subscription-level telemetry are the difference between normal administration and hidden persistence.

This article focuses on detection engineering across Azure and Entra ID rather than on the attacks themselves. The value for IAM and NHI practitioners is in seeing how role assignment changes, credential additions, and storage access patterns can be translated into log-based controls that expose abuse early enough to matter.

The setup is typical for organisations that want to centralise Azure signals into a SIEM-style workflow, but the lesson is broader: if identity events, privileged operations, and storage telemetry are not joined, attackers can hide inside ordinary cloud operations.

Key questions

Q: What breaks when Azure identity changes are not monitored as security events?

A: Attackers can add secrets, federated credentials, or role assignments that create durable access while looking like routine administration. Without alerting on those transitions, defenders often miss the persistence layer and only notice the compromise when data moves or resources change. Azure identity governance fails at the point where identity object changes are not treated as high-risk events.

Q: Why do Entra ID credential additions create persistent cloud risk?

A: Because a new secret or federated credential can let an attacker authenticate as the application long after the original compromise is gone. That turns the application object into a long-lived access path. The risk is highest when credential changes are not tied to lifecycle review, ownership, and immediate detection.

Q: How do security teams know whether Azure telemetry is actually helping?

A: They should test whether detections can connect identity changes, privilege escalation, and storage access into one investigation trail. If the team can only see each event type in isolation, the programme has visibility but not detection value. Success means analysts can trace abuse from account change to impact quickly enough to contain it.

Q: Who is accountable when a service principal is used to persist access in Azure?

A: Accountability sits with the team that owns the application, the tenant, and the access governance process that approved or failed to revoke the credential. In practice, this is an IAM and cloud operations issue as much as a SOC issue. The control gap is unmanaged lifecycle ownership of the non-human identity.

Technical breakdown

Azure Activity logs and privilege escalation detection

Azure Activity logs capture subscription-level actions such as role assignments, policy changes, resource creation, and lock deletion. In practice, these logs are useful because privilege escalation in Azure often happens through administrative operations that look legitimate at the API layer. If a user elevates privileges, changes role bindings, or alters protective controls, the evidence usually sits in the activity log stream before it appears anywhere else. Detection works best when those events are normalised into rules that distinguish expected administration from high-risk change patterns.

Practical implication: monitor role assignment and lock-deletion events as control-plane abuse signals, not just as administrative change records.

Entra ID audit trails for credential and consent abuse

Entra ID Audit and Sign-in logs expose application changes, credential additions, consent grants, and authentication activity. That matters because attackers frequently create persistence by adding secrets, federated credentials, or malicious application permissions to an existing identity. The important distinction is between a one-time login event and a durable identity modification that lets an attacker return later without reusing the original foothold. In this model, the application object becomes the persistence layer, and audit telemetry is what reveals the change.

Practical implication: alert on application updates, credential additions, and unexpected consent grants as persistence indicators.

Storage diagnostics as an exfiltration and impact channel

Azure Storage diagnostic logs show blob access, SAS token use, configuration changes, and deletion activity. That makes them central to identifying data theft that happens after identity compromise, especially when an attacker generates shared access signatures or uses storage keys to bypass normal authentication. Storage abuse is often the impact stage of a broader identity compromise, not a separate problem. The detection challenge is to correlate storage events with identity and role changes so that exfiltration can be tied back to the access path that enabled it.

Practical implication: correlate SAS usage and storage key activity with identity events to spot exfiltration chains instead of isolated storage noise.

Threat narrative

Attacker objective: The attacker wants durable cloud access that can be used to escalate privileges, evade normal authentication controls, and exfiltrate data or manipulate Azure resources.

1. Entry occurs through legitimate cloud identity and admin pathways, where service principals, application credentials, or federated identity grants are abused to obtain trusted access in Azure and Entra ID.
2. Escalation follows when the attacker adds credentials, grants roles, or elevates access at the root scope, turning a normal identity object into a persistence and privilege vehicle.
3. Impact is achieved through storage access, SAS generation, resource lock removal, and exfiltration of data or continued cloud control under valid-looking identity operations.

Breaches seen in the wild

• Microsoft Entra ID Flaw — Critical Microsoft Entra ID flaw allows attackers to hijack any company tenant via identity provider vulnerability.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Azure identity abuse is first a governance problem, then a detection problem. The article shows that role assignments, consent grants, and service principal changes are the real control points in Azure abuse chains. If those changes are not monitored as identity events, defenders only see the impact stage after persistence has already been established. Practitioners should treat control-plane telemetry as the primary source of truth for cloud identity risk.

Persistent access in Azure often lives inside the application object. Adding a client secret or federated credential to an Entra ID application turns that object into a durable access mechanism that can outlive the original session. This is a classic non-human identity failure mode because the identity itself becomes the persistence layer. The implication is that application lifecycle governance has to be tied to credential and consent change detection, not just periodic review.

Azure storage becomes the blast-radius amplifier once identity is compromised. SAS tokens, storage keys, and disk export paths can all convert identity abuse into data exfiltration or resource tampering. That means storage telemetry is not a separate silo. It is part of the same identity attack surface, and practitioners should design correlation rules around the path from identity change to storage access.

Runtime detection needs to focus on the exact transition points attackers use. The useful boundary is not whether Azure is being used normally, but when a legitimate identity starts making changes that create longer-lived access or broader privilege. That is where the control gap sits, and that is where SIEM rules have the highest value. Security teams should prioritise the transitions that create persistence rather than every anomalous login.

Access governance and cloud detection are converging into one operating model. Azure, Entra ID, and storage events are now too tightly coupled to manage as separate programmes. The practical conclusion for IAM and cloud security teams is that identity governance must extend into operational detection, because modern cloud abuse is written in legitimate platform actions.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.
• That governance gap is already visible in our Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, which frames rotation and offboarding as core controls, not optional hygiene.

What this signals

Identity telemetry has become the minimum viable control plane for Azure security. When Entra ID, role assignment, and storage events are not correlated, attackers can move from ordinary administration to durable persistence without triggering a clear boundary. Teams that still treat identity, cloud posture, and storage monitoring as separate workstreams will keep missing the transition points that matter.

Credential and consent changes now define the practical blast radius. The problem is not simply that Azure identities can be abused. It is that one added secret or federated credential can create a control path that survives session closure and hides in normal platform operations. That should push IAM teams to tie lifecycle governance directly to detection engineering and response workflows.

Service principal persistence debt: when an application object is allowed to accumulate credentials without immediate review, the environment inherits access that no one is actively watching. That is exactly the kind of risk that the Ultimate Guide to NHIs , Why NHI Security Matters Now was built to explain, and it is increasingly relevant to Azure estates that rely on long-lived identities.

For practitioners

• Alert on application credential creation and federated credential changes Create high-fidelity detections for new client secrets, federated identity credentials, and unexpected application updates in Entra ID. Treat these as persistence events, not routine configuration noise.
• Correlate role assignment changes with identity and storage events Join Azure Activity logs, Entra ID Audit logs, Sign-in logs, and Storage diagnostics so privilege escalation can be traced into exfiltration or resource tampering.
• Watch for root-scope elevation and resource lock removal Prioritise detections for elevated access, lock deletion, and administrative policy changes because these often precede lateral privilege use or destructive impact.
• Treat SAS generation as a data-exfiltration indicator Flag managed disk exports, Storage SAS creation, and blob access patterns that occur after identity changes, especially when they come from unusual principals or administrative sessions.
• Centralise Entra ID and Azure telemetry into one investigation path Keep the Log Analytics workspace and detection rules aligned so analysts can follow the full path from identity modification to impact without hopping between consoles.

Key takeaways

• Azure abuse is easiest to hide when identity modifications are not treated as first-class security events.
• The evidence path runs through Entra ID, Azure Activity, and storage telemetry, not through any single log source.
• Teams that correlate credential changes, role escalation, and SAS usage will detect persistence and exfiltration far earlier than teams that monitor only sign-ins.

Key terms

• 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.
• 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.
• Log Analytics Workspace: A Log Analytics workspace is the Azure repository used to centralise telemetry for querying and detection. It becomes an identity security control when Azure Activity, Entra ID, and storage logs are aggregated there, allowing defenders to correlate privilege changes with follow-on abuse.
• SAS Token: A Shared Access Signature token is a scoped credential that limits access to specific storage actions, resources, and time windows. It can reduce blast radius compared with an account key, but only if its permissions, expiry, and issuance are controlled as lifecycle events rather than convenience artifacts.

What's in the full article

Wazuh's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Azure and Entra ID log integration using a Log Analytics workspace and the azure-logs module
• Custom Wazuh rule logic for service principal credential creation, federated identity changes, and disk export events
• Exact diagnostic settings and log categories used for Azure Activity, AuditLogs, SignInLogs, and StorageBlobLogs
• Stratus Red Team command examples for reproducing privilege escalation, persistence, and exfiltration techniques

👉 Wazuh's full post includes the telemetry setup, detection rules, and attack emulation commands used in the walkthrough.

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.