Entra ID Monitoring

Stolen credentials are cheap. Credential-dumping sites and breach databases provide attackers with ready-made lists of real usernames and passwords. Many of these credentials are tied to active corporate accounts where users have reused passwords from personal services.

Entra ID is an especially attractive target because its authentication endpoints are internet-exposed by design. Any attacker with a username list can start attempting logins without ever touching the target's network perimeter. And when a login succeeds, it can look identical to a legitimate one, with no exploit, no malware, and no network anomalies. The only way to catch it is through log analysis.

Password Spraying

The attacker tries a small set of common passwords against many accounts. The goal is to stay under the lockout thresholds.

Lockout thresholds are protection policies that lock accounts after reaching a pre-defined number of failed attempts. When a user is locked, they can't access their account until an admin or a defined timeout unlocks the account.
For example, if the policy is set to lock the account after 10 failed attempts, the attacker never exceeds 5 per account to stay stealthy. The volume is spread across accounts rather than concentrated in a single account.

How it looks in logs:

• Many failed sign-ins from the same IP address.
• Failures spread across multiple different usernames.
• All attempts occur within a short time window.

Brute Force

On the other hand, in brute-force attacks, the attacker tries many passwords against a single account. This technique is less common against Entra ID due to the lockout policies. However, attackers can bypass this by throttling their attempts and spreading them over a long period, so they never exceed the lockout threshold.

For example, an attacker might try just one password per hour against the same account. This keeps the noise low enough to avoid triggering a lockout, making it slow and harder to detect because the attempts may span a longer time window.

How it looks in logs:

• Many failed sign-ins against a single username.
• High volume of attempts from a single IP or a small number of IPs.

Detecting With Logs

To filter failure attempts in Sign-in logs, you can use the query below. Note that you are also filtering out conditionalAccessStatus that are not equal to success. This is necessary because a successful authentication can have error codes in some steps of the login process.

index="task-2" sourcetype="azure:aad:signin" "status.errorCode"!=0 conditionalAccessStatus!=success
| table _time, userPrincipalName, appDisplayName, ipAddress, location.countryOrRegion, status.errorCode, status.failureReason
| sort - _time

This query lists only failure attempts against Entra ID identities; however, you can leverage Splunk's (or any other SIEM's) query features to identify brute-force or password-spraying patterns better.

For example, the query below can reveal which IP address has the most failure attempts and how many accounts were targeted:

index="task-2" sourcetype="azure:aad:signin" "status.errorCode"!=0 conditionalAccessStatus!=success
| stats dc(userPrincipalName) as targeted_accounts, count as failures by ipAddress
| sort - failures

After identifying an IP address executing these techniques or a relevant account being targeted, you can specifically filter for these artifacts to investigate the suspicious behavior.

A good starting point is to check whether any authentication has been successful using the Splunk queries below by just replacing the placeholders <TARGET-USER> and <SUSPICIOUS_IP> with the user and IP address you want to investigate:

index="task-2" sourcetype="azure:aad:signin" "status.errorCode"=0
| where userPrincipalName="<TARGET_USER>"
| stats count by userPrincipalName, status.errorCode, ipAddress
| sort status.errorCode

index="task-2" sourcetype="azure:aad:signin" "status.errorCode"=0
| where ipAddress="<SUSPICIOUS_IP>"
| stats count by userPrincipalName, status.errorCode
| sort status.errorCode

Practice

For this task, you will answer a couple of questions about brute-force and password-spraying attacks using Sign-in logs in Splunk logs.
With the filter index="task-2" sourcetype="azure:aad:signin", you will be able to see all Sign-in logs, but feel free to use any other queries you learned in this task.
Remember to search for All Time to find all log activity.

A successful password spray can give an attacker valid credentials. What stops them from walking straight in?
In most Entra ID tenants, the answer is a combination of two controls: Conditional Access Policies and Identity Protection. Understanding both and their blind spots is essential for a SOC analyst because attackers actively look for gaps in these controls, and your logs will tell you when they find one.

Conditional Access Policies

Think of Conditional Access Policies (CAP) as Entra ID's if/then engine. Every sign-in is evaluated against a set of policies, and based on the policy's findings, it either grants access, requires an additional control (such as MFA), or blocks the request entirely.

For example, if a company has users only in London and São Paulo, and a user authenticates from New York, the user must complete an MFA validation before successfully accessing their account.

Common Policy Examples

It's important to mention that a policy is only as effective as its scope. If it doesn't cover the right accounts and conditions, it leaves gaps that attackers actively look for.

A real-world example of this is when an organization has a policy requiring MFA for all users, but excludes a handful of service accounts to avoid breaking automated workflows. If one of those accounts is later targeted in a password spray attack, there's nothing standing between the attacker and a successful login.

CAP in Sign-in Logs

Every Sign-in log event includes an appliedConditionalAccessPolicies field that tells you exactly which policies were evaluated, and what the outcome was for each:

   appDisplayName: "One Outlook Web"
   appId: "9199bf20-a13f-4107-85dc-02114787ef48"
   appliedConditionalAccessPolicies: [
     {
       displayName: "Require MFA" // Applied Policy
       enforcedGrantControls: [
         "Block"
       ]
       enforcedSessionControls: [
       ]
       id: "c63499f4-64b6-4943-bfc3-52fbb641ef10"
       result: "notApplied" // Resulted action
     }
   ]

The possible results are:

You can use the following query to start your hunt for suspicious CAP results:

index="task-3" sourcetype="azure:aad:signin" conditionalAccessStatus=failure
| spath output=policies path=appliedConditionalAccessPolicies{}
| mvexpand policies
| spath input=policies output=policy_result path=result
| spath input=policies output=policy_name path=displayName
| where policy_result="failure"
| stats values(policy_name) as FailedPolicies by _time, appDisplayName, userDisplayName, ipAddress, conditionalAccessStatus
| eval FailedPolicies=mvjoin(FailedPolicies, ", ")
| table _time, appDisplayName, userDisplayName, ipAddress, conditionalAccessStatus, FailedPolicies
| sort - _time

Identity Protection

Conditional Access enforces your rules, while Identity Protection is what tells Conditional Access when something looks suspicious in the first place.

Identity Protection is Entra ID's built-in ML-based risk detection engine. It continuously analyses sign-in behaviour and user account signals, assigns risk scores, and feeds those scores into Conditional Access so risk-based policies can act on them.

There are two types of risk: Sign-in Risk and User Risk.
Both types of risk use a three-tier scale: Low, Medium, High.

Sign-in Risk

It evaluates the suspiciousness of a specific sign-in attempt.
This is evaluated in real time, per authentication event. Below are examples of what raises sign-in risk:

• Suspicious Source IP: Sign-in from a known risky or anonymous IP. (e.g., Tor, known proxy services, or VPN providers)
• Impossible Travel: Two sign-ins from geographically distant locations within an impossible timeframe. (e.g., First login from London and after 5 minutes, a login from New York)
• Unfamiliar Sign-in Properties: New device, new location, or new ASN that doesn't match the user's historical pattern.

This Microsoft page documents all risk types.

User Risk

It evaluates the likelihood that a specific account will be compromised.
This accumulates over time, based on the account's history. Examples:

• Leaked credentials: Validates if the account's password appeared in a known breach dump.
• Multiple high-risk sign-ins: Check related risky sign-ins that weren't remediated.
• Suspicious M365 activity: Check potential post-compromise M365 activity. (e.g., Suspicious inbox-rules)

Identity Protection in Sign-in Logs

You can look for Identity Protection log details in three different sourcetype values:

Sign-in logs (azure:aad:signin)

To assess the risk level of a specific sign-in attempt, you can use the riskLevelDuringSignIn field. For the cumulative risk associated with the user account as a whole, refer to riskLevelAggregated.

Below is a Splunk query that uses these fields to analyse risky sign-ins:

index="task-3" sourcetype="azure:aad:signin"
| where riskLevelDuringSignIn="high"
| table _time, userPrincipalName, appDisplayName, ipAddress, location.countryOrRegion, riskLevelDuringSignIn, riskLevelAggregated
| sort - _time

Risk Detection Logs (azure:aad:riskdetection)

This log type is a detailed log generated when risks are detected. The difference between the regular sign-in log fields is the additional details related to the detection, for example:

• riskEventType: The type of the risk identified (e.g., anonymizedIPAddress, impossibleTravel).
• riskLevel: Shows how risky the detection is.

These logs also generate detections in other usage steps of M365 and Entra ID, for example, a suspicious configuration change performed by an admin. You can check the type of activity that is being alerted by looking at the activity field.

Below are two Splunk queries to analyse risk detection logs:

index="task-3" sourcetype="azure:aad:identity_protection:riskdetection"

index="task-3" sourcetype="azure:aad:identity_protection:riskdetection"
| where riskEventType="anonymizedIPAddress"
| table _time, userPrincipalName, activity, ipAddress, location.countryOrRegion, riskLevel, riskEventType
| sort - _time

Risky User Logs (azure:aad:identity_protection:risky_user)

Every user has a risk level in Entra ID. This is calculated based on risk detections, and it's a way for Microsoft to alert admins to users who are likely compromised (or almost compromised) and require their attention.

Once a user changes its risk state, a risky user log is generated. This makes this log type a good trigger to perform proactive threat hunting to identify users who are likely compromised.

Below is a Splunk query to filter all risky user logs:

index="task-3" sourcetype="azure:aad:identity_protection:risky_user"
| table _time, userPrincipalName, riskLevel, riskState, riskDetail 
| sort - _time

Practice

For this task, you will answer a couple of questions to assess the risk of some sign-ins and user accounts using Splunk logs.
With the filter index="task-3" sourcetype="azure:aad:signin", you will be able to see all Sign-in logs, but feel free to use any other queries you learned in this task.
Remember to search for All Time to find all log activity.

MFA is the single most impactful control against password-based attacks. Once an attacker has valid credentials, MFA is the wall between them and a full account takeover. As we mentioned before, Microsoft reports that MFA blocks over 99% of automated credential-based attacks.

How MFA Works in Entra ID

When a user signs in, Entra ID breaks authentication into two sequential challenges:

Something you know: the user enters their username and password. Entra ID validates these credentials against the directory.
Something you have: if the password is correct (and a Conditional Access policy that enforces MFA is active), Entra ID sends a second challenge to a pre-registered method.

Only after both factors are satisfied does Entra ID generate a session token and grant access to the requested resource. Unfortunately, MFA is not a silver bullet. Attackers have developed techniques to bypass it without ever breaking the cryptography. This task covers the most relevant techniques for a SOC analyst to recognise.

MFA Fatigue (Prompt Bombing)

The attacker already has valid credentials. They initiate repeated authentication attempts in rapid succession, each one generating an Authenticator push notification on the victim's phone. The goal is to overwhelm the user until they approve one, out of frustration, confusion, or the mistaken belief that it's a legitimate prompt.

This is a social engineering attack, not a technical one. It works because push notifications give the user a single button to approve without any additional context about where the sign-in is coming from.

How it looks in logs:

• A high volume of MFA prompts against a single account in a short window.
• MFA-related error codes, such as 50074, 50076,500121, repeated.
• If the user approves, followed eventually by error code 0.

Microsoft has partially mitigated this with number matching (the user must enter a number shown on the login screen into their Authenticator app) and additional context (the app shows location and app name). These controls make fatigue attacks significantly harder.

index="task-4" sourcetype="azure:aad:signin" (status.errorCode=50074 OR status.errorCode=50076 OR status.errorCode=500121)
| stats count as mfa_failures values(status.errorCode) as errorCodes values(status.failureReason) as failureReasons by userPrincipalName, ipAddress
| sort - mfa_failures

SIM Swapping

When SMS is used as the MFA method, an attacker can convince a mobile carrier to port the victim's phone number to a SIM they control, allowing them to receive all SMS codes. This primarily poses a threat to consumer accounts and organizations that still rely on SMS-based MFA. The mitigation is straightforward: move away from SMS as a factor.

In logs, this technique is characterized by:

• A successful logon using an unusual device or browser for a user.
• A successful logon from an unusual location for a user.

Adversary-in-the-Middle (AiTM) Phishing

AiTM is a more sophisticated technique. The attacker sets up a reverse proxy between the victim and the legitimate Microsoft login page. The victim authenticates normally, including completing MFA, but the proxy captures the session token issued after authentication. The attacker then replays that token on their own machine, bypassing MFA entirely because authentication has already occurred.

From the token's perspective, the session is legitimate. The attack doesn't break MFA; it steals the MFA result. The pattern can be described as:

• The sign-in succeeds without a new MFA prompt because the token already carries proof that MFA was completed during the original (victim's) authentication.
• The source IP and location differ from those where MFA was originally completed.
• Conditional Access shows the session as compliant. The policy was satisfied, just not by the person who's now using the token.

This is why token theft is so dangerous: from Entra ID's perspective, everything looks fine. The only anomalies are geography and IP, which require an analyst to connect the dots between two separate sign-in events.

Impossible Travel

You may have noticed that an attacker who has bypassed authentication, whether through SIM Swapping or by stealing a session token (AiTM), often ends up authenticating from a location that makes no physical sense relative to the user's last known sign-in location. This is the basis for one of the most reliable detection signals in Entra ID: impossible travel.

For example: a user signs in from São Paulo at 09:00, and then the same account signs in from Moscow at 09:45. That's physically impossible. One of those sign-ins is unlikely to be performed by the legitimate user.

Identity Protection tries to detect this automatically and flags it as an impossibleTravel risk event. But as we mentioned before, you can't blindly trust these alerts, since sometimes they aren't accurate. You can hunt for this pattern proactively, directly in Sign-in logs, by using the Splunk query below and trying to spot logins from different countries in a timestamp that is physically impossible:

index="task-4" sourcetype="azure:aad:signin" status.errorCode=0
| table _time, userPrincipalName, ipAddress, location.countryOrRegion, conditionalAccessStatus
| sort - _time

index="task-4" sourcetype="azure:aad:identity_protection:riskdetection"
| where riskEventType="impossibleTravel"
| table _time, userPrincipalName, activity, ipAddress, location.countryOrRegion, riskLevel, riskEventType
| sort - _time

Legitimate False Positives

Not every impossible travel event is malicious. Before confirming an incident, you may consider:

• Corporate VPNs — A user connecting through a VPN exit node in another country will appear to sign in from that country, even while sitting in their office.
• Split tunnelling — Some traffic goes through the VPN, some doesn't, producing sign-ins from multiple apparent locations simultaneously.
• Cloud service IPs — Automated sign-ins from Microsoft services or third-party integrations can produce location anomalies.

Practice

For this task, you will answer a couple of questions to identify an MFA bypass attempt using Splunk logs.
With the filter index="task-4" sourcetype="azure:aad:signin", you will be able to see all Sign-in logs, but feel free to use any other queries you learned in this task.
Remember to search for All Time to find all log activity.

Getting into an account is only the first step. Once an attacker has a foothold, their next priority is two things: expand their access and make sure they can keep it even if the compromised account is locked out or its password is reset.

This task introduces the most common post-compromise actions that an attacker takes in Entra ID. The focus here is on recognition, knowing what to look for in Audit logs.

Common Post-Compromise Techniques

You may have noticed that everything up to this point has lived in Sign-in logs. Once the attacker is authenticated and begins taking action within the tenant, the relevant evidence is moved to Audit Logs.

Audit logs capture administrative actions and any changes to the tenant's state. Role assignments, user creation, policy modifications. All changes land there.
Once you suspect a user is compromised, the key filtering field is activityDisplayName, which indicates the action the user performed.

To filter all audit logs performed in a tenant, you can use the following Splunk query:

index="task-5" sourcetype="azure:aad:audit"

In the previous room, M365 Monitoring Basics, you learned details about the most important fields in audit logs. But in short, the main fields you should pay attention to in an investigation of post-compromise activity are:

• activityDisplayName: The detailed activity or action that was performed by a user or app.
• initiatedBy: The account or app that performed the action.
• targetResources: The account or objects that have been changed or affected by an action.

These fields answer the most important question for analyzing post-compromise activity: what was changed (activityDisplayName), who made that change (initiatedBy), and the details of the changes (targetResources).
Keep that in mind to answer the task practice questions.

Role Assignment

This is the most direct path to elevated access: assign a privileged Entra ID role to the compromised account (or to a new account the attacker creates). Below are common target roles:

• Global Administrator: Full control over the tenant.
• Exchange Administrator: Access to all mailboxes.
• User Administrator: Can reset passwords and modify accounts.
• Application Administrator: Can manage app registrations and consent grants.

A legitimate role assignment isn't inherently suspicious. What's suspicious is a role assignment that happens outside normal provisioning workflows. For example, at an unusual time, initiated by an account that doesn't normally perform these actions, targeting an account that was recently involved in suspicious sign-in activity

Use the query below to list all assigned role activities in a tenant. Remember to explore the targetResources field to see what role was added to a user:

index="task-5" sourcetype="azure:aad:audit" activityDisplayName="Add member to role" 
| table _time, activityDisplayName, initiatedBy.user.userPrincipalName, targetResources{}.userPrincipalName, targetResources{}.modifiedProperties{}.newValue | sort - _time

Creating Backdoor Accounts

A new admin account created outside normal HR/IT provisioning flows is a classic example of a persistence mechanism. The attacker creates it, assigns it a privileged role, and uses it as a fallback if the original compromised account is remediated.

Use the Splunk query below to list all accounts created within a tenant:

index="task-5" sourcetype="azure:aad:audit" activityDisplayName="Add user"
| eval initiator=coalesce('initiatedBy.user.userPrincipalName','initiatedBy.app.displayName')
| eval userCreated='targetResources{}.userPrincipalName'
| table _time, activityDisplayName,initiator, userCreated

Adding Alternate MFA Methods

If an attacker registers their own authenticator app or phone number on the compromised account, they maintain access even after the victim changes their password, since they control the MFA factor. This shows up in Audit logs as an MFA registration event on a user object, initiated by the user themselves.

When onboarding an MFA device, it can generate multiple types of logs for each step. To validate if a user attempted to add an MFA device to their account, you can use the Splunk query below:

index="task-5" sourcetype="azure:aad:audit" activityDisplayName="User started security info registration" loggedByService="Authentication Methods"  operationType="Add"
| eval initiator=coalesce('initiatedBy.user.userPrincipalName','initiatedBy.app.displayName')
| table _time, activityDisplayName, initiator, initiatedBy.user.ipAddress, additionalDetails{}.value

You can explore the additionalDetails field to check what type of device the user added.

Practice

For this task, you will continue the investigation from the MFA bypass task and answer a couple of questions to identify post-compromise activity in the compromised account you have identified using Splunk logs.
With the filter index="task-5", you will be able to see all logs related to this task, but feel free to use any other queries you learned in this room!
Remember to search for All Time to find all log activity.

Password reset, MFA resets, and account lockouts. A thorough remediation effort can undo most of what an attacker achieved through credential theft. However, there is one persistent mechanism that survives it all: a consented OAuth application.

This task dives deeper into OAuth abuse as a standalone technique. It is one of the stealthiest persistence methods available to an attacker because the access isn't tied to the user's credentials at all. It lives in the application layer, and most organizations are not actively monitoring it.

How OAuth Consent Works

OAuth (Open Authorization) is the protocol that powers the "Sign in with Google" or "Connect your Microsoft account" buttons you see everywhere. It allows a third-party application to request access to a user's resources on a platform, such as M365, without ever handling the user's password. Instead, the user (or an administrator) reviews a consent screen listing what the application wants to do, approves it, and the platform issues an access token granting that application those permissions.

From an attacker's perspective, this is ideal. Once a user or admin clicks "Accept", the application holds a persistent grant to the user's data via API. That access:

• Survives password changes, because it's not credential-based.
• Survives MFA resets, because authentication already happened at consent time.
• Requires active revocation, not just credential remediation, to remove.

Delegated vs Application Permissions

Not all consent grants are equal. Microsoft's permission model has two distinct types, and understanding the difference is critical for assessing how dangerous a consent grant is.

Delegated permissions are the more common and less alarming of the two. The app borrows the user's identity and can only do what that user could do themselves. If that user leaves the organization, the grant becomes useless.

Application permissions are a different story. They grant the application a standing right to act across the entire tenant, independently of any user session. An app with Mail.Read.All can silently read every mailbox in the organization indefinitely. An app with RoleManagement.ReadWrite.Directory can assign Entra ID roles. These permissions require admin consent precisely because of how powerful they are, which is also why tricking a Global Administrator into granting consent is one of the highest-value moves an attacker can make.

High-Risk Permission Scopes to Know

The following permissions are commonly abused and should be treated as high-priority findings during a hunt:

• Mail.Read.All / Mail.ReadWrite.All: Read or modify all mailboxes in the tenant.
• Files.ReadWrite.All: Read and write all files across SharePoint and OneDrive.
• RoleManagement.ReadWrite.Directory: Assign and remove Entra ID roles, including Global Administrator.
• Directory.ReadWrite.All: Read and write all directory data, including users and groups.
• offline_access: Maintain access indefinitely via refresh tokens, even when the user is not actively signed in.

Any consent grant that includes one or more of these scopes warrants immediate investigation.

Detecting OAuth Abuse in Audit Logs

Consent grant events are captured in Audit logs under the activityDisplayName value "Consent to application". The targetResources field is particularly important here since it contains both the application that was granted consent and the specific permissions that were approved.

When granting permissions to an application generates multiple log entries, the query below filters to the consent event itself and surfaces the fields most relevant to triage:

index="main" sourcetype="azure:aad:audit"
activityDisplayName="Consent to application"
| eval initiator=coalesce('initiatedBy.user.userPrincipalName','initiatedBy.app.displayName')
| eval appName='targetResources{}.displayName'
| eval permissionsGranted='targetResources{}.modifiedProperties{}.newValue'
| table _time, initiator, appName, permissionsGranted
| sort - _time

Congratulations! You've completed the Entra ID Monitoring room. You now have a solid understanding of what the main threats are and how to identify them using Sign-in and Audit logs.

What You've Learned

• Learned the main attacks that target Entra ID.
• Learned how Conditional Access policies and Identity Protection work together to help admins quickly identify potentially compromised accounts.
• Understand how to use Entra ID Sign-in and Audit logs to detect these threats before compromising an account and how to identify post-compromise activities.

In the next room, Exchange Online Monitoring (coming soon), you'll learn about multiple common techniques attackers use when targeting one of the most important M365 applications, the Exchange Online, also known as Outlook Web.