Microsoft 365 account compromise is not simply a password-reset problem. Once an attacker gains access to a Microsoft Entra ID identity, the investigation may need to cover sign-ins, authentication methods, registered devices, OAuth applications, mailbox rules, cloud storage activity, administrative changes, tokens and other persistence mechanisms.

Microsoft recommends beginning an identity investigation with Microsoft Entra ID Protection risk information, sign-in logs and related activity. Investigators should compare suspicious activity with the user's normal application, device, location, IP address and user-agent patterns, while also checking whether the account was used to access resources or make administrative changes. Microsoft's Entra ID Protection investigation guidance[1]

The goal is therefore broader than answering "Was the password stolen?" The real questions are:

• When did the compromise begin?
• How did the attacker obtain access?
• Which authentication mechanisms were used?
• Did the attacker establish persistence?
• What Microsoft 365 resources were accessed?
• Were applications or permissions added?
• Were other accounts affected?
• Has the attacker actually been removed?

This guide presents a defensive forensic checklist for investigating and recovering a compromised Microsoft 365 or Microsoft Entra ID account.

Figure 1. A defensive investigation view for tracing a compromised Microsoft 365 or Microsoft Entra ID identity.

1. Preserve the Timeline Before You Start Cleaning Up

One of the easiest mistakes during an account-compromise investigation is to remediate too quickly and destroy useful evidence.

Before making extensive changes, record the suspected discovery time, the first suspicious activity, affected account identifiers, known IP addresses, suspicious devices, unusual applications and any user reports. Microsoft incident-response guidance treats timeline reconstruction as a core part of investigations such as password spraying and token theft. Microsoft's password-spray investigation playbook[6] and token-theft playbook[7]

Export relevant logs where possible and record the filters used. Microsoft Entra sign-in logs can be downloaded in JSON or CSV format, providing a practical way to preserve the data being examined during an investigation. Microsoft Learn: Download Microsoft Entra logs[4]

Do not assume that the earliest suspicious sign-in is the beginning of the incident. An attacker may have obtained credentials or a token earlier and remained unnoticed until a later activity generated an alert.

2. Start With Microsoft Entra Sign-In Logs

Microsoft Entra records sign-in activity for users and applications. The sign-in logs can help answer three basic forensic questions: who performed the activity, how they authenticated or connected, and what resource they accessed. The logs include interactive user sign-ins, non-interactive user sign-ins, service-principal sign-ins and managed-identity sign-ins. Microsoft Learn: Sign-in logs in Microsoft Entra ID[2]

For the affected account, examine at least:

• Timestamp
• Application
• Resource
• IP address
• Location information
• Device information
• Operating system and browser
• User agent where available
• Authentication details
• Conditional Access results
• Success and failure patterns
• Interactive versus non-interactive activity

Microsoft specifically recommends comparing suspicious sign-ins with the user's historical behavior, including the application, device, location, IP address and user-agent string. Microsoft Entra ID Protection investigation guidance[1]

Do Not Treat Geolocation as Proof

An unfamiliar country or city is an important investigation signal, but it is not definitive proof that the user was physically somewhere else. Microsoft notes that IP-based location is best effort and can be affected by VPNs, mobile providers and centralized network infrastructure. Microsoft Learn: Sign-in activity details[3]

The stronger question is whether multiple signals agree. An unfamiliar IP combined with an unfamiliar device, unusual application, new authentication method and suspicious mailbox activity is considerably more meaningful than an unfamiliar IP alone.

3. Examine Non-Interactive Sign-Ins

Investigators should not stop after reviewing interactive sign-ins.

Microsoft Entra also records non-interactive user sign-ins, which represent activity performed on behalf of a user by applications and other clients. These events can become particularly important when investigating token abuse or suspicious application activity. Microsoft Learn: Microsoft Entra log categories[4]

A compromise can therefore appear as a sequence in which an unusual interactive authentication is followed by application-driven or non-interactive access.

Do not automatically interpret every non-interactive event as malicious. The investigation should establish whether the application, device, source network and timing are consistent with the user's normal behavior.

4. Review Microsoft Entra Audit Logs for Changes

Sign-in logs tell you about authentication activity. Audit logs help answer a different question: what changed?

Microsoft states that Entra audit logs capture changes to applications, groups, users and licenses. They can therefore help identify modifications that occurred during the suspected compromise window. Microsoft Learn: Logs available for streaming from Microsoft Entra ID[4]

Look for changes involving:

• User account properties
• Group membership
• Privileged role assignments
• Authentication methods
• Registered devices
• Applications and service principals
• Application permissions
• Credentials associated with applications
• Administrative configuration

Microsoft's activity-log guidance recommends using filters such as user, application, status, resource, IP address and Conditional Access information to narrow investigations. Microsoft Learn: Customize and filter activity logs[4]

5. Check Authentication Methods and Devices

A successful password reset does not necessarily mean that the account is clean.

Investigators should determine whether an attacker added or modified authentication methods, registered a new device or otherwise changed the account's authentication state. Microsoft's token-theft investigation guidance specifically calls out newly registered devices, additional MFA options and credential changes as investigation areas. Microsoft token-theft playbook[7]

For the affected user, establish a known-good baseline and compare it with the current configuration.

• Which MFA methods existed before the incident?
• Which methods exist now?
• Were any new authentication methods added?
• Are all registered devices recognized?
• Were credentials or passwordless authentication options changed?
• Were any changes made close to the first suspicious sign-in?

An unexpected authentication method or device should be treated as an important persistence indicator and investigated in the context of the complete timeline.

6. Investigate OAuth Applications and Consent Grants

OAuth consent deserves special attention because an attacker does not necessarily need to maintain access by repeatedly signing in as the victim.

Microsoft's app-consent investigation guidance describes attacks in which users are tricked into granting permissions to applications. Investigators should review applications assigned to the affected user and examine audit activity involving application consent. Microsoft Learn: App consent grant investigation[5]

Search for applications that:

• Were added near the suspected compromise window
• Are unfamiliar to the user or administrators
• Request permissions inconsistent with their stated purpose
• Have unexpected access to mail, files or other organizational data
• Received administrative consent unexpectedly

Microsoft specifically recommends examining audit events for Consent to application and determining whether administrative consent was involved. Microsoft's application-consent investigation workflow[5]

Do not delete a suspicious application before documenting the evidence unless immediate containment requires it. Record the application identity, permissions, users affected and relevant timestamps first.

7. Investigate the Mailbox

When a Microsoft 365 identity is compromised, the mailbox should be considered part of the investigation rather than merely an email system.

Microsoft's compromised-account guidance recommends reviewing suspicious or missing messages, suspicious Sent and Deleted Items activity, inbox rules, forwarding, signatures and other mailbox changes. Attackers can also use compromised Microsoft 365 accounts to access associated SharePoint and OneDrive data. Microsoft Learn: Respond to a compromised email account[9]

Pay particular attention to:

• New inbox rules
• Rules that move messages into unusual folders
• External forwarding
• Mailbox delegation changes
• Unexpected sent messages
• Deleted or missing messages
• Suspicious signatures
• Unexpected mail transport or configuration changes

Mailbox persistence is especially important because an attacker may use access to monitor password-reset messages, security notifications, internal communications or other sensitive information.

8. Expand the Investigation Beyond the Account

Do not investigate the compromised identity in isolation.

Microsoft Entra ID Protection recommends looking for similar activity across the tenant. Shared IP addresses, locations, applications or other characteristics can indicate that additional accounts were targeted or compromised. Microsoft Entra ID Protection investigation guidance[1]

Search for:

• Other users authenticating from the same suspicious infrastructure
• Other accounts targeted by password spraying
• Similar suspicious applications
• New devices registered during the same period
• Additional MFA registrations
• Related mailbox rules
• Similar data-access patterns
• Changes made by the compromised identity to other users or groups

If the affected identity had privileged access, widen the investigation immediately. A compromised administrator can potentially make changes that extend beyond the original account.

Figure 2. A practical investigation workflow for tracing identity compromise from initial detection through recovery and validation.

9. Common Attacker Techniques to Investigate

Modern cloud-account investigations should consider more than conventional password theft. Microsoft has documented several identity-focused techniques that can result in account or session compromise.

Password Spraying

Password spraying attempts to validate commonly used or reused passwords against multiple accounts rather than repeatedly attacking one account. Microsoft recommends investigating the timeline, attacker IP addresses, successful sign-ins, MFA failures and potentially affected accounts when password spraying is suspected. Microsoft password-spray investigation guidance[6]

A successful password validation followed by a failed MFA event can be particularly useful when reconstructing an attack, although the meaning of individual events must be evaluated in context.

Adversary-in-the-Middle Phishing

Microsoft has documented phishing campaigns in which an adversary-in-the-middle flow proxies authentication and captures authentication tokens. Microsoft notes that such attacks can bypass non-phishing-resistant MFA because the attacker is abusing an authenticated session rather than simply stealing a password. Microsoft Security Research: AiTM token compromise[12]

For investigations, this means a valid MFA event does not automatically prove that the legitimate user controlled the resulting session.

Device-Code Phishing

Microsoft Security Research has also documented large-scale phishing activity abusing device-code authentication. In the observed campaign, victims were persuaded to complete a legitimate Microsoft device-login process while the attacker obtained access to the resulting authentication session. Microsoft Security Research: AI-enabled device code phishing campaign[11]

During an investigation, therefore, suspicious device-code activity should be correlated with user reports, authentication events, token activity and subsequent cloud access.

Token Theft and Session Replay

Microsoft defines token theft as a scenario in which an attacker compromises and replays tokens issued to a user. Because the token can represent an already authenticated session, the attacker may gain access even when the legitimate user previously satisfied MFA. Microsoft token-theft playbook[7]

This is one reason why changing a password alone should not be treated as the complete response to a suspected identity compromise.

OAuth Consent Abuse

Attackers may attempt to persuade users to grant malicious or inappropriate applications access to organizational resources. Microsoft maintains a dedicated incident-response workflow for investigating illicit application consent, including review of consent events, application permissions and affected users. Microsoft app-consent investigation guidance[5]

Authentication Persistence

Microsoft's current token-theft guidance specifically highlights additional credentials, devices, MFA methods and mailbox rules as areas that investigators should examine when looking for persistence. Microsoft token-theft investigation checklist[7]

Cloud Data Collection

Current Microsoft research has observed identity compromises followed by Microsoft Graph reconnaissance, SharePoint and OneDrive downloads and email collection. In a September 2026 investigation, Microsoft described activity spanning multiple accounts in which identity compromise was followed by authentication persistence, cloud reconnaissance and data collection. Microsoft Security Research: Passkey-themed social engineering[10]

Figure 3. Common identity attack techniques and the investigation checkpoints they can create.

10. Contain the Account

Once the evidence supports a compromise, containment should stop the attacker from continuing to use the identity while preserving enough information to understand what happened.

Microsoft's Entra ID Protection guidance says that when an attacker may be able to impersonate a user, responders should require a password reset and MFA or block the user and revoke access and refresh tokens. Microsoft Entra ID Protection remediation guidance[1]

Microsoft's emergency-access documentation also explains that revocation can involve a period before access is effectively removed because applications may continue to accept existing access or session tokens until their applicable expiration or synchronization behavior takes effect. Microsoft Learn: Revoke user access in an emergency[8]

A practical containment sequence can include:

1. Block or disable the affected account when required.
2. Reset the password.
3. Revoke the user's sessions and refresh tokens.
4. Remove unauthorized authentication methods.
5. Disable or remove unauthorized devices.
6. Remove malicious application consent.
7. Remove malicious mailbox rules and forwarding.
8. Review privileged memberships and changes.
9. Investigate related accounts and infrastructure.

The exact order depends on the incident. During an active attack, containment may need to happen while the investigation continues.

11. Recover the Microsoft 365 Account

Recovery should not end when the user can successfully sign in again.

Microsoft's compromised-email guidance recommends reviewing MFA devices and removing suspicious methods, revoking active sessions, and reviewing applications that have received user consent. Microsoft Learn: Compromised Microsoft 365 email account response[9]

Before restoring normal access, verify:

• The password was changed using a trusted administrative or recovery process.
• Unknown MFA methods have been removed.
• Unknown devices have been disabled or removed.
• Suspicious sessions have been revoked.
• Malicious OAuth applications or permissions have been removed.
• Mailbox forwarding and suspicious rules have been removed.
• Unexpected delegation has been investigated.
• Privileged role or group changes have been reviewed.
• Related accounts have been checked.
• There is no continuing suspicious sign-in activity.

12. Validate That the Attacker Is Actually Gone

This is the step that separates account recovery from incident containment.

After remediation, continue monitoring the identity. Look for renewed suspicious sign-ins, unexpected non-interactive activity, newly added authentication methods, application access, mailbox rules and cloud-data access.

Microsoft's token-theft guidance recommends iterating the investigation until affected accounts and devices are identified and the attack has been stopped. Microsoft token-theft recovery guidance[7]

If suspicious activity returns immediately after remediation, do not assume that the new event is unrelated. Re-open the timeline and determine whether an overlooked token, device, application, credential or persistence mechanism remains active.

13. Microsoft 365 / Entra ID Forensic Audit Checklist

Use the following checklist during an investigation:

Identity

• ☐ Confirm affected user and account identifiers.
• ☐ Establish the suspected incident window.
• ☐ Determine whether the account is privileged.
• ☐ Identify related users or accounts.

Authentication

• ☐ Review interactive sign-ins.
• ☐ Review non-interactive sign-ins.
• ☐ Compare IP addresses and locations.
• ☐ Compare devices and user agents.
• ☐ Review MFA results.
• ☐ Check for password-spray indicators.
• ☐ Check for AiTM or device-code phishing indicators.
• ☐ Check for token-theft indicators.

Persistence

• ☐ Review authentication methods.
• ☐ Review registered devices.
• ☐ Review application consent.
• ☐ Review service principals and application permissions where relevant.
• ☐ Review mailbox forwarding and inbox rules.
• ☐ Review delegation changes.

Impact

• ☐ Review mailbox activity.
• ☐ Review SharePoint activity.
• ☐ Review OneDrive activity.
• ☐ Review Microsoft Graph-related activity where telemetry is available.
• ☐ Check for administrative changes.
• ☐ Check for other compromised accounts.

Recovery

• ☐ Reset the password.
• ☐ Revoke sessions and refresh tokens.
• ☐ Remove unauthorized MFA methods.
• ☐ Remove unauthorized devices.
• ☐ Remove malicious applications and consent.
• ☐ Remove malicious mailbox rules and forwarding.
• ☐ Review privileged changes.
• ☐ Continue monitoring after recovery.

14. The Most Important Lesson: Recovery Is Not Containment

A compromised Microsoft 365 or Entra ID account should be treated as an identity incident, not merely a password incident.

The strongest investigations correlate identity telemetry with mailbox activity, application permissions, authentication changes, device information and cloud-resource access. Microsoft provides dedicated incident-response playbooks for scenarios including password spraying, token theft, application consent and compromised applications, reflecting the fact that identity incidents can involve several different persistence and access mechanisms. Microsoft incident-response playbooks[13]

The central operational principle is simple:

Regaining control of the account is not the same as proving that the compromise is contained.

Containment requires evidence that unauthorized access has stopped, persistence has been removed, affected resources have been assessed and related identities or applications have not been left behind.

Conclusion

Investigating a compromised Microsoft 365 or Microsoft Entra ID account requires defenders to follow the evidence across the identity rather than focusing on a single suspicious login.

Start with the timeline. Examine Entra sign-in and audit logs. Compare suspicious activity with the user's normal behavior. Review authentication methods and devices. Investigate OAuth consent, mailbox rules and cloud-resource access. Then contain the account, revoke sessions, remove unauthorized persistence and continue monitoring until the evidence supports closure.

Modern identity attacks increasingly abuse legitimate authentication and cloud functionality, which makes forensic correlation more important than simply looking for malware or obvious exploitation. Recent Microsoft research has documented identity compromises involving social engineering, AiTM, device-code authentication, authentication persistence, Microsoft Graph reconnaissance and cloud-data collection. Microsoft Security Research[10]

For incident responders, the practical objective is therefore not just to reset the user's password. It is to reconstruct what happened, identify every persistence mechanism, determine what the attacker could access, remove unauthorized access and establish evidence that the identity and its surrounding cloud resources are clean.