BEC investigations in M365 benefit from a structured, research question-driven approach rather than by an ad hoc log review. By defining these questions before examining evidence, investigators avoid confirmation bias, ensure consistent coverage across engagements, and produce findings that are clearly mapped to supporting evidence. Some questions you will want to answer when you investigate an identity are:
- Has the password been reset?
- Have session tokens been revoked?
- Has a compromise occurred?
- How did the threat actor gain access?
- What did the threat actor do? (Some actions discussed here)
- What data was accessed? (Discussed in a future blog)
- Did data exfiltration occur? (Discussed in a future blog)
This post addresses the first five questions. Data access and exfiltration analysis require mailbox and compliance log investigation and will be covered in subsequent parts of this series.
As a prerequisite, you should have, at a minimum, Global Reader. This will give you access to view risk reports.
This part of the investigation will revolve around the portal at https://portal.azure.com/ and the identity management system, Entra ID.
Have Passwords Been Reset?
Why this matters: Confirming password remediation is the first step in determining whether the threat actor has been evicted from the environment. Without a reset password, the threat actor retains access through either a session token or password regardless of other remediation performed.
Data Source: Entra ID Audit Logs
Relevant Logging:
| Operation | Initiated by |
| Admin started password reset | Admin-initiated reset |
| Reset password (by admin) | Admin-initiated reset |
| Reset password (self-service) | User initiated via SSPR |
| Change password (self-service) | User initiated via SSPR |
| Self-service password reset flow activity progress | User initiated via SSPR |
| Change user password | User initiated via SSPR |
You can find a full list of audit activities available here: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-audit-activities
What these results mean:
If any of the above operations were performed after the incident was identified, then password remediation has been performed. The absence of these operations means that the password has not been reset and the threat actor may retain credential access.
Limitations:
- Entra ID Free retains audit logs for only seven (7) days; Entra ID P1/P2 retains logs for 30 days. If the compromise predates this retention period, then using the Unified Audit Log (UAL) would be the next log to investigate. I have found that Azure logs in the UAL can be spotty and miss details.
- A password reset alone does not end already authenticated sessions. To remediate this, active session tokens will need to be revoked.
Next Step: Move to research question 2 regardless of the above outcome. Without revoking active session tokens and passwords, a threat actor can still access the affected environment.
Have Session Tokens Been Reset?
Why this matters: Session tokens authenticate independently of credentials. A threat actor who gained access through AiTM phishing or token theft can maintain active sessions even after a password reset, as the token remains valid until explicitly revoked. Confirming token revocation is therefore a required step in remediation.
Data Source: Entra ID Audit Logs
Relevant Logging:
| Operation | Initiated by |
| Update StsRefreshTokenValidFrom Timestamp | Admin-initiated |
What these results mean:
Observing the above operation in the Audit Logs after the window of access indicates that any active sessions are invalid, requiring the user to log back into the environment. If you do not observe this, then session tokens are still valid and the threat actor can reuse the session token.
Limitations:
- Entra ID Free retains audit logs for only seven (7) days; Entra ID P1/P2 retains logs for 30 days. If the compromise predates this retention period, then using the Unified Audit Log (UAL) would be the next log to investigate. I have found that Azure logs in the UAL can be spotty and miss details. In the UAL, look for workloads in AzureActiveDirectory and operations ‘Update StsRefreshTokenValidFrom Timestamp’. This is triggered by clicking the ‘Revoke sessions’ button on the user’s Entra ID profile, using Revoke-MgUserSignInSession, Invoke-MgInvalidateUserRefreshToken, or revokeSignInSessions.
Next Step: With the threat actor removed from the environment, the investigation can proceed to determine whether a compromise occurred and scoping of the threat actor’s actions during the access window.
Has a Compromise Occurred?
Why this matters: Determining whether unauthorised access occurred establishes the foundation for all subsequent investigative steps. Without confirming a compromise, scope cannot be defined and the extent of the threat actor’s actions cannot be investigated.
Data Source: Entra ID Sign-in Logs
Relevant Logging:
| Field | Description |
| Date | Used to determine when an event occurred |
| Status | Was it successful, interrupted, or failed? |
| IP Address | The connected IP address of the user logging in. |
| Location | Where the user connected from. |
| UserAgent | The type of software the user connected with. |
| Username | What account was used. |
| Authentication requirement | Was it single factor or multifactor authentication? |
| Risky Sign-ins | Suspicious activity identified by Microsoft. |
What these results mean:
The date can be used to help map out when the threat actor was active. The status has three (3) different types which are success for when a user gets into an account, interrupted occurs when a user gets prompted for their MFA token and when the prompt asking if they want to stay signed in. Observing an interrupted status does not necessarily mean the login is malicious and context is required. If the status is failure, then the login attempt failed.
IP address is to be used in conjunction with the location as abnormal IP addresses and locations should be flagged for review. Using tools to determine whether or not these IP addresses are associated with VPN services is important. You will experience some threat actors using their VPN to change their location to the same city as the legitimate user. Determining who the ISP or hosting provider is will help you determine if it’s legitimate or not.
If you see a user log in from another country, you will want to establish whether or not they have travelled recently. Additionally, I’d recommend you enrich your data to determine what ISP, hosting, VPN provider is used. Using purely location can be misleading as a threat actor may use a VPN to login from Sydney, Australia when the legitimate user is also based in Sydney, Australia. Sometimes you may be in the situation where the legitimate user also uses a VPN, your data enrichment tool will be able to determine who the provider is (Mullvad, Proton, ExpressVPN, NordVPN, etc.).
When looking at user agents, find out what devices the affected user uses. If the compromised user typically uses a Windows laptop but you observe logins from a Mac device, it’s highly likely that this is not the legitimate user. A user agent commonly used by threat actors is Axios which is an open-source HTTP client and should be flagged for review. One observation I have made about this user agent is that it is typically used during the first login session after a session token is stolen.
The username contains the user’s user principal name, this is needed to make sure we are looking at the right account. The Authentication requirement can be used if only a password is required or if multifactor authentication is required to gain access.
There is additional information for Conditional Access which is used to identify if the login event triggered any of the policies and if the login was audited or if the attempt was blocked.
For organizations that have Entra ID P2 licensing, you will have access to risky sign-ins. Risky sign-ins uses machine learning to help determine whether or not activity is suspicious. Some examples of actions include: impossible travel, activity from anonymous IP address, new country, password spray, verified threat actor IP, and more. For your reference, you can find a list of actions here: https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks.
Limitations:
- Logs in Entra ID may need to be enriched as relying purely on geolocation data can mislead investigators if threat actors use a VPN geolocating to the same geographical region, it can be missed.
- Entra ID Free retains audit logs for only seven (7) days; Entra ID P1/P2 retains logs for 30 days. If the compromise predates this retention period. You can fallback to the UAL and look for UserLoggedIn events which show the user logging into the account. However, the UAL is not as verbose Azure logging.
- There are no logoff events.
- A successful login from a remote location could be triggered due to an employee travelling. So it is required to communicate with the account owner or their manager before treating the login as malicious.
Next Step: After we have identified that the account has been compromised, the next step is to determine how the threat actor was able to gain access. Some initial access indicators are visible in the sign-in logs which creates a bridge to continue the investigation.
How did the threat actor gain access?
Why this matters: Identifying the initial access vector determines the scope of the investigation beyond the compromised account. A password spray indicates multiple accounts may be targeted, while session token theft points to a phishing event requiring additional investigation into how the token was intercepted. In practice, this is investigated simultaneously with the question “has a compromise occurred?”
Data Source: Entra ID Sign-In Logs
Relevant Logging:
| Field | Description |
| Date | When the event happened. |
| Session ID | The value given by Microsoft to identify the login. |
| UserAgent | The software used to connect. |
| Username | The name of the account. |
| Authentication Requirement | Whether single or multifactor authentication was required. |
What these results mean:
The session ID is one of the most important fields that you will use throughout the investigation. This can also be important in identifying how the threat actor got in, for instance the legitimate user may login which is followed by another login from another IP address using the same session ID. This is common in Adversary in the middle (AiTM) attacks where a user logs into a fake M365 page and has their session token stolen. This can be paired with the authentication requirement if it’s multifactor as the threat actor will not have access to the mobile device. In my experience, threat actors commonly use user agents such as Axios to load the session token to the browser.
Password spraying can be observed as you will see multiple accounts being targeted with nine (9) attempts made per account (two (2) for US government employees) and reattempting at a later point in order to avoid having their IP address blocked by Azure Smart Lockout. This can be circumvented by using a tool such as FireProx which uses the AWS API Gateway which uses thousands of workers, each with different IP addresses, to make the request to Microsoft.
Limitations:
- Entra ID Free retains audit logs for only seven (7) days; Entra ID P1/P2 retains logs for 30 days. If the compromise predates this retention period. You can fallback to the UAL and look for UserLoggedIn events which show the user logging into the account. However, the UAL is not as verbose as Azure logging.
Next Step:
After establishing how the threat actor gained access and when, we can begin to determine what actions the threat actor performed.
What did the threat actor do?
Why this matters: Understanding threat actor actions within the identity layer establishes whether they attempted to maintain persistence, escalate privileges, or perform data exfiltration. All of these affect the remediation scope and business impact.
Data Source: Entra ID Audit Logs
Relevant Logging:
| Field | Description |
| Update user | Look for activity that would affect access such as StrongAuthenticationRequirements for MFA. |
| Add service principal | When a user adds an instance, usually in the form of an application. |
| Add application | An application has been added to the account |
| Consent to application | Occurs when the user gives consent for the application to access the account. |
| Add user to role | Have extra permissions been assigned? |
| Add user | Indicates a user has been created in the tenant. |
What these results mean:
When you see Update user events where the property is StrongAuthenticationRequirements, this can indicate that the threat actor has removed MFA if the value is blank, or a new device if it’s something else. This is done by threat actors in order to maintain control of the mailbox should the password and session token be revoked, they will attempt to use their registered phone to get the password changed.
You will generally find the events “Add service principal”, “Add application”, and “Consent to application” all appear in sequence. They are all tied to a user adding an application to the compromised user’s account. A user signs into their account with a particular application such as PERFECTDATA and before they are able to sign in, they will be prompted to give consent to the application. Once that is done, the “Add service principal”, “Add application”, and “Consent to application” are all recorded within Entra ID. Applications such as PERFECTDATA and eM Client are commonly used by threat actors to download a copy of the mailbox. You may also find that some other applications have been added to the user’s account such as custom Graph API applications which will use a custom application ID. One helpful resource is https://byteintocyber.com/microsoft-365-application-ids-bec-investigation-resources/ which contains a list of potentially malicious applications.
Threat actors commonly add other accounts if they have privileged access. This can be confirmed in the audit logs by checking for activity related to ‘Add user’ and ‘Add member to role’ which will help determine if the user has persistence in the environment and if they have been given elevated privileges.
Limitations:
- Entra ID Free retains audit logs for only seven (7) days; Entra ID P1/P2 retains logs for 30 days. If the compromise predates this retention period. You can filter on the AzureActiveDirectory workload as this is the legacy name that Microsoft still uses to identify the aforementioned events.
- If a threat actor uses a tool like PERFECTDATA to download a mailbox, you will not be able to see what emails or message IDs were taken without the UAL. Additionally, logs will not show you how it was used.
- Activity in the audit log will need to be correlated with other factors such as IP addresses used by the threat actor, time, and user agents.
- If a custom Graph API application is used, you will need graph logs to be enabled which are not enabled by default.
Next Step:
This concludes section 1 where we discussed identity based logging and events showing how we can confirm that an incident has occurred. In the next section, we will discuss Exchange and mailbox analysis.
