Email Diagnostics

Is Your Email Compromised? An M365 Guide to Detection and Recovery

Eight signs anyone can see, six that only an admin can see, the false positives that look like a hack but aren't, and the 5-minute self-check that tells you whether to panic.

By , CTO · Published · Last updated

TL;DR

  • You suspect your Microsoft 365 mailbox has been compromised. The first job is to figure out whether you're right before you start changing things and destroying evidence.
  • Eight signs are visible to any user without admin access. Six more are only visible to whoever runs your tenant. We list both, plus the look-alikes that fool people every week.
  • The 5-minute self-check covers the four highest-signal places to look: Sent items, inbox rules, recent sign-ins, and connected apps. Any one of them can give you a yes-or-no answer fast.
  • If the self-check raises a flag, the 30-minute admin check uses two PowerShell queries to confirm or rule it out, and one rule about evidence: do not delete anything until you've copied it.
  • Most M365 mailbox compromises trace back to four attack paths. Knowing which one hit you decides what you fix next.

Why early detection is most of the battle

The dwell time stat for business email compromise has gotten worse, not better. Industry incident-response data from 2024 puts the median attacker dwell time inside a compromised M365 mailbox at 18 to 24 days before any defender notices. The first wire fraud, forwarding rule, or downstream phishing campaign typically lands in week two. By the time customers start calling because they got weird emails from your address, the attacker has been reading your mail for the better part of a month.

The good news is that early detection is cheap. Most of the signals on this page take a few minutes to check, and any one of them showing up clean cuts your risk window down significantly. Most of the signals showing up dirty also gives you the answer fast, so you can stop guessing and start the recovery clock.

This guide is written for two readers at once: the owner who suspects something is off and isn't sure who to call, and the IT generalist who got pinged by that owner and needs a structured path through the diagnosis. The user-visible signs are first. The admin checks come after.

The 8 signs anyone can see (no admin access required)

You can run all eight of these checks from your own mailbox in a normal Outlook or Outlook on the web session. None of them require an admin role.

1. Emails in your Sent folder you didn't write

Open Sent Items. Sort by date. Look at the last 30 days. If you find a message you don't remember writing, especially one going to a contact you don't know, that's the highest-signal sign on this page. Attackers who aren't careful leave their work behind here. Attackers who are careful delete from Sent immediately, so an empty Sent folder for a day you know you sent mail is also a finding.

2. Customers, vendors, or coworkers asking about emails you didn't send

"Hey, did you mean to send me this invoice?" "Why did you ask me to buy gift cards?" "Is this attachment really from you?" When two or more contacts independently ask about messages you don't recognize, treat it as a confirmed finding until you prove otherwise. Outsiders are often the first to notice a compromise because the attacker is using your account to phish them.

3. MFA prompts you didn't trigger

Your phone buzzes with an Authenticator approval request, but you weren't logging in anywhere. That means someone else just typed your password into a Microsoft sign-in page and is waiting for you to approve them. Deny it, then change your password immediately. If you've been getting these every few hours, MFA fatigue is the active attack pattern, and the attacker is hoping you tap Approve once by accident.

4. Password reset emails you didn't request

An email arrives titled "Reset your Microsoft password" or "Verify your account," and you didn't ask for it. Two possibilities: legitimate phishing, where someone is testing whether you'll click the link, or an active takeover attempt where someone is using the self-service reset flow against your account. Don't click the link in either case. Sign in directly through outlook.office.com and check your account security settings.

5. Microsoft sign-in alerts from unfamiliar locations

Microsoft sends an automatic email when your account signs in from a new country or a new device. The subject line is usually "Unusual sign-in activity" or "We noticed a new sign-in." If the alert mentions a city you've never been to, or a sign-in at 3 AM your time, that's a real finding. Pay attention to the IP address shown. A residential IP in Lagos or Hanoi is not where your business is logging in from.

6. Inbox rules you didn't create

This one catches the most attackers, because almost every M365 compromise installs at least one rule. In Outlook on the web, click the gear icon, then Mail → Rules. Look at every rule listed. Anything you don't recognize is a finding. Rules with names like a single period (.), a single space, or "..." are classic attacker signatures, designed to be invisible in a quick scan. Rules that move messages containing "invoice," "wire," "payment," "bank," or "urgent" to Deleted Items, RSS Feeds, or Archive are even more telling.

7. OAuth consent prompts you didn't approve

Sometime in the last 30 days, you may remember clicking through a Microsoft-looking consent screen that asked permission for an app you don't recall installing. To check what's connected: sign in at myapps.microsoft.com, or go to myaccount.microsoft.com and review the "Apps and services" section. Any third-party app with mail, calendar, or contact permissions you don't remember granting is a finding. The post on how attackers use email forwarding rules in Microsoft 365 covers what malicious OAuth apps typically do once they're in.

8. Contacts saying you sent them something strange

Slightly different from sign #2 above: this is when someone says they got information from you, by email, that you never sent. A vendor confirms a wire transfer to a routing number you don't recognize. A coworker mentions you "approved" a request you have no memory of. The attacker is impersonating you in real conversations, often inside threads that look genuine because the attacker has been reading your mail for weeks. Trust the contact who's confused. Investigate.

The 6 signs only an admin can see

If you have Global Admin or Security Admin access in your tenant (or if you're working with whoever does), six more signals live behind the admin portals. These are higher-fidelity than the user signs above, and they're where confirmation usually happens.

1. Sign-in log entries from foreign IPs or impossible-travel patterns

In Microsoft Entra admin center → Monitoring & health → Sign-in logs, filter by the user in question and the last 30 days. Look for sign-ins from IPs in countries the user has never visited, sign-ins from anonymizer or VPN IPs, and impossible travel (a London sign-in followed 20 minutes later by a Manila sign-in for the same user). Entra automatically flags impossible travel as a "high" risk sign-in.

2. New mailbox forwarding rules

Inbox rules are visible to the user, but mailbox-level forwarding (set via ForwardingSmtpAddress) is admin-only and survives password resets. An attacker who plants a forwarding rule at this layer keeps reading your mail even after you've reset credentials and revoked sessions.

3. New OAuth app consents on the user's behalf

In Entra → Identity → Applications → Enterprise applications → User consent (or via Graph), look at every app the user has consented to in the last 90 days. Filter by apps requesting mail, calendar, or full directory scopes. Apps from unverified publishers, apps with names like "PDF Viewer" or "Mail Helper," and apps registered in the last 30 days are high suspicion.

4. New mailbox permissions or delegate access

Check whether anyone else has been granted "Send As," "Send on Behalf," or "Full Access" to the mailbox recently. The attacker grants themselves access from a second compromised account so they can keep reading even if the original mailbox locks down. Run Get-MailboxPermission against the suspected account and look for non-default entries.

5. New admin role assignments

If the compromised user had any admin rights, the first move is often to grant a new role to a second account the attacker controls. Check Entra → Roles and admins and review the audit history. Any role assignment in the past 90 days that you didn't authorize is a serious finding and almost always means the attacker is preparing for a longer campaign.

6. MailItemsAccessed events from foreign IPs

This is the strongest single signal in the unified audit log. When an attacker reads mail in your tenant, Microsoft logs a MailItemsAccessed event with the source IP. Filter by user, the last 30 days, and operation = MailItemsAccessed. Sort by IP. Anything from a country or ASN the user has no business in is the smoking gun. (This event requires E5/G5 licensing or Microsoft Purview Audit Premium. On lower SKUs, you'll see UserLoggedIn instead, which is weaker but still useful.)

The look-alikes: things that scare people but aren't compromises

About a third of the "I think I've been hacked" calls our peers in IR consulting take turn out to be one of these four patterns. Rule them out before you pull the fire alarm.

None of these four are compromises. All of them generate alerts that look like compromises. Ten minutes of context-checking saves you a wasted IR engagement.

The 5-minute self-check (no admin access needed)

If you're the user and you don't have admin access, run these four checks in order. Any one of them tripping is enough reason to escalate.

  1. Sent items, last 14 days. Open Sent. Skim every subject line. One unfamiliar message is a finding.
  2. Inbox rules. Outlook on the web → gear icon → Mail → Rules. Look at every rule. Names that are punctuation, names that include external email addresses in the action, rules that move "invoice"/"wire"/"payment" anywhere weird: findings.
  3. Sign-in history. Visit mysignins.microsoft.com. This is the user-visible version of the admin sign-in log. Look at the last 30 days. Strange country, strange browser, strange "Successful sign-in" you don't remember: finding.
  4. Connected apps. myaccount.microsoft.com → Apps and services (or Permissions). Anything with mail or calendar permissions you don't remember granting: finding.

If all four come back clean, your mailbox is probably fine. If any one of them surfaces something, escalate to whoever runs your tenant before you start changing things. Touching the wrong thing destroys the evidence trail an investigator needs.

Three immediate steps you can take regardless of what you find: change your password to something long and unique, sign out of all sessions on mysignins.microsoft.com, and turn on MFA if it isn't already on. None of those destroy evidence. All of them limit the attacker's ongoing access.

The 30-minute admin investigation

If you're the admin (or working with one), the next step is a structured pass through PowerShell. Two queries cover the highest-value ground. They take about 30 minutes total when you include reviewing the output.

Connect to Exchange Online first:

Connect-ExchangeOnline -UserPrincipalName [email protected]

Query 1: list every inbox rule on the suspected mailbox, including hidden ones.

$user = "[email protected]"

Get-InboxRule -Mailbox $user -IncludeHidden |
  Select-Object Name, Enabled, Priority, ForwardTo, ForwardAsAttachmentTo,
                RedirectTo, MoveToFolder, DeleteMessage, MarkAsRead,
                FromAddressContainsWords, SubjectContainsWords, BodyContainsWords |
  Format-List

# Also pull mailbox-level forwarding (different from inbox rules)
Get-Mailbox -Identity $user |
  Select-Object UserPrincipalName, ForwardingSmtpAddress, ForwardingAddress,
                DeliverToMailboxAndForward

What you're looking for: any rule with an external ForwardTo/RedirectTo address, any rule moving financial-keyword messages to RSS Feeds or Deleted Items, any hidden rule (the -IncludeHidden flag is the only way to see them), and any non-empty ForwardingSmtpAddress at the mailbox level.

Query 2: find recent sign-ins from unusual locations for the user. Switch to Microsoft Graph for this one:

Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

$user = "[email protected]"
$since = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")

Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$user' and createdDateTime ge $since" -All |
  Select-Object CreatedDateTime, IpAddress,
                @{n='City';e={$_.Location.City}},
                @{n='Country';e={$_.Location.CountryOrRegion}},
                ClientAppUsed, AppDisplayName,
                @{n='Status';e={$_.Status.ErrorCode}},
                @{n='RiskLevel';e={$_.RiskLevelDuringSignIn}} |
  Sort-Object CreatedDateTime |
  Export-Csv "$user-signins.csv" -NoTypeInformation

Open the CSV in Excel. Sort by Country, then by IpAddress. Anything outside the user's normal pattern is a finding. Pay particular attention to rows with RiskLevel = "high" or "medium," and to rows where ClientAppUsed is one of the legacy-auth values (IMAP4, POP3, "Other clients," Authenticated SMTP). Legacy-auth sign-ins on a tenant that hasn't blocked them are how most credential-stuffing attacks land. The deeper rationale lives in the broader signs your M365 tenant is hacked.

Run both queries. If they come back clean, the mailbox is probably fine and the user-visible alarm was a false positive. If either surfaces something, you're now in incident response, and the rules change.

If you confirm a compromise: do not delete evidence

The single biggest mistake in the first hour of an M365 mailbox incident is the helpful admin who sees a malicious inbox rule, deletes it immediately, then can't reconstruct what the attacker was doing. Microsoft's audit retention is only 90 days on default licensing, and a deleted rule is gone the moment you click. Capture before you cut.

The minimum evidence-preservation pass before you start cleaning up:

Once evidence is captured, the recovery sequence (password reset, session revocation, rule removal, OAuth revocation, MFA reset, secondary-account audit) is documented step by step in the M365 breach FAQ on BreachShield365. Run the steps in order. Skipping ahead is how attackers regain access during the same incident.

Two operational rules from incident response work that save real money: any wire transfer that left the bank in the last 72 hours gets a recall request to the bank's wire-recall desk immediately, and any cyber insurance carrier on the policy gets a notification call within 24 hours of confirmation, even before you know the full scope. The bank window closes fast. Insurance carriers can deny claims for late notice.

M365Shield handles your Microsoft 365 security. For full compliance readiness — incident response plans, governance frameworks, and executive security leadership — Iron Path Advisory provides fractional CIO and CISO services.

The 4 attack paths that account for almost every M365 mailbox compromise

Identifying which one of these hit you decides what to fix next. Reset your password against the wrong attack vector and the attacker is back in within hours.

1. Legacy auth credential stuffing

The attacker buys a list of breached passwords from another data breach, scripts a tool to try them against your tenant over IMAP, POP3, or SMTP AUTH, and one of them works because the user reused a password. MFA never triggers because legacy protocols don't support it. The fix is blocking legacy auth at the tenant level.

2. OAuth consent phishing

The user clicks a Microsoft-styled link asking permission for an app they don't recognize. They click Accept. The attacker now has a long-lived OAuth token with mail-read and mail-send scopes, and that token survives password resets and MFA changes because it isn't a password. The fix is restricting user consent in Entra and reviewing what's already been consented to.

3. Adversary-in-the-middle (AiTM) session theft

The user clicks a phishing link that proxies the real Microsoft sign-in page. They enter their password, approve MFA, and the attacker captures the post-MFA session cookie in real time. Tools like Evilginx and EvilNoVNC automate this. The fix is phishing-resistant MFA (FIDO2 keys, Windows Hello, certificate-based auth) plus sign-in risk policies that require re-authentication on anomalies.

4. Password reuse from a third-party breach

The user used the same password on a hobbyist forum that got breached in 2023, the password ended up in a credential dump, and the attacker tried it against M365 with the user's work email. If MFA was off, or if legacy auth was open, it worked. The fix is enforcing unique-password policies, blocking legacy auth, and requiring MFA on every account without exception.

Each of these has a sibling deep-dive in the EmailShield365 cluster. The case-study walkthrough of how a 60-person engineering firm got hit and what they changed afterward is in our BEC prevention case study. The prevention stack that closes all four paths simultaneously sits in the broader business email compromise prevention guide.

Common questions

My password works fine. Doesn't that mean my account is safe?

No. Most modern attacks don't change your password, because changing it would tip you off. The attacker keeps your password working, sets up a forwarding rule or a hidden inbox rule, and reads your mail in the background. A working password is the default state of a compromised mailbox, not evidence of safety. The signs above are how you actually tell.

I have MFA on. Doesn't that prevent compromise entirely?

MFA stops the password-stuffing version of the attack, which is real progress. It does not stop OAuth consent phishing, where the user grants the attacker a token directly, and it does not stop AiTM phishing, where the attacker captures the post-MFA session cookie. Both of those attack patterns are growing year-over-year. MFA is necessary, not sufficient. The full picture of what MFA covers and what it doesn't is in the MFA cyber-insurance-requirement breakdown.

Should I delete a suspicious inbox rule the moment I find it?

Not before you've captured it. Screenshot the rule, export it via PowerShell, and note the timestamp. Then delete it. The five minutes you spend preserving the evidence is what lets your insurance carrier process the claim and lets a forensic investigator (if you bring one in) reconstruct the attacker's timeline. Skipping that step is a common, expensive mistake.

How long does an attacker typically sit inside a compromised mailbox before doing damage?

Median dwell time is 18 to 24 days from initial compromise to the first observable damage event. The attacker spends the first two to three weeks reading mail, mapping vendor and customer relationships, and identifying high-value invoice or wire targets. Active damage (forwarding rules, fraudulent invoices, downstream phishing) typically lands in week three. That window is your detection budget. Most of the signs in this guide can be checked weekly in under 10 minutes.

My MSP says everything is fine. Should I trust them?

Ask them which of the eight user-visible signs and six admin-visible signs they checked, and request the output. A "we ran a scan and you're good" answer is not a check. A "here's the inbox rule audit, here's the sign-in log review for the last 30 days, here's the OAuth consent inventory" answer is. Most MSPs are trustworthy. The few that aren't tend to skip exactly these checks, because the checks are tedious and the customer rarely asks for evidence.

Get the free Email Compromise Self-Check

No spam. Unsubscribe anytime.

Not sure if your tenant is exposed?

Run the free M365 risk check. We'll look at the controls that decide whether a stolen password becomes a compromised mailbox.

Check My Risk

Related Articles

Business Email Compromise Prevention

The full prevention stack that closes all four M365 attack paths.

Email Forwarding Attack Detection

Find the hidden rules attackers use to keep reading your mail.

BEC Prevention Case Study

A $312,000 invoice-fraud incident, and what the firm changed afterward.