Microsoft 365 Account Hacked for a Month: What We Found

TL;DR: An attacker controlled a staff member’s Microsoft 365 account at a UK business for at least a month. Then they used it to send thousands of phishing emails to the company’s contacts in a single day. Before that, they quietly added their own MFA methods, registered devices, connected a third-party email app and set up an inbox rule to hide replies. Nothing raised an alarm until the mass mailout. If nobody is watching sign-in and identity activity in your Microsoft 365 tenant, these warning signs go unseen.

What happened

We were recently called in to help a business whose Microsoft 365 account had been taken over. The first sign of trouble was obvious: the mailbox had sent a huge volume of email to everyone it could reach, all marked High Importance.
By then the attacker had been inside for a while. The audit logs showed unauthorised activity going back at least a month. The real start date could be earlier, because the logs only reached back that far.

How the attacker stayed in

The attacker didn’t just log in and send the emails. They spent weeks making sure they could keep access even if the password changed.

• Extra MFA methods: they registered their own authentication methods on the account, so they could approve their own sign-ins.
• Extra devices: they registered devices against the account that the user didn’t recognise.
• A third-party email app: they granted permissions to a legitimate desktop email client. This let them read and send mail through the app without going through the usual web sign-in.
• An inbox rule: they created a rule that deleted every incoming message, marked it as read and stopped any other rules from running. Its name was made to look almost blank so it wouldn’t stand out in the rules list.

The inbox rule is the clever part. When thousands of phishing emails go out, the replies come back: “Did you mean to send this?”, bounce messages, colleagues asking questions. The rule deleted all of them before the user saw anything.

The phishing email itself

The email looked like a routine business request with an attachment. Opening it took the reader to a fake SharePoint document page, which then showed a Microsoft “device code” prompt.
Device-code phishing gets the victim to approve a sign-in on the attacker’s behalf. The prompt is a real Microsoft page, so it looks trustworthy, and MFA doesn’t stop it because the victim completes the MFA step themselves. Microsoft’s threat intelligence team has written about this technique, and the FBI has warned about a phishing-as-a-service kit called Kali365 that works the same way.

This is the really clever part. The link also behaved differently depending on who opened it. Security scanning tools were sent to a harmless, well-known website. A real person clicking through got the fake login page. This trick is designed to get past automated email filtering.

Every contact who approved that prompt may now have their own account compromised, and the cycle can start again in another business.

Why we couldn’t find the start date

Microsoft 365 only keeps sign-in and audit history for a limited time, and how long depends on your licences. Microsoft’s documentation gives seven days of Entra sign-in logs on the free tier and 30 days with Entra ID P1 or P2. Many small businesses don’t export these logs anywhere else.
So by the time anyone looks, the evidence of how the attacker first got in may already be gone. In this case we could confirm a month of access but not the first day.

What we did

The work focused on containment:

• Reset the password and gave it to the user by phone, not by email.
• Revoked every active session.
• Removed all MFA methods so the user could register trusted ones again.
• Removed the unrecognised devices and the third-party app access.
• Deleted the malicious inbox rule and moved hidden messages back to the inbox where possible.
• Reviewed sign-ins, permissions, devices and mailbox settings across all the history that was available.

The account is back under the user’s control. What a containment job can’t tell you is whether data was copied out during that month. Answering that needs a deeper forensic investigation, and the cost and effort are much higher once the attacker has had weeks inside.

Five things to check in your own tenant this week

1. Inbox rules: look for rules that delete, move or forward mail, especially ones with blank or strange names.
2. Authentication methods: check each user’s registered MFA methods and remove any nobody can explain.
3. Enterprise applications: review which apps users have consented to and what permissions those apps hold.
4. Registered devices: compare devices in Entra ID against the hardware you actually own.
5. Log retention: find out how far back your sign-in and audit logs go, and decide whether that’s enough.

Also make sure staff know that a genuine colleague or supplier will never need them to type a code into a Microsoft “device login” page to open a document.

Where monitoring makes the difference

Every step this attacker took left a trace: a new MFA method, a new device, an app consent, a new inbox rule and an unusual burst of outbound email. On their own, each one looks like routine admin. Together, inside a few weeks on one account, they form a clear pattern.

Identity Threat Detection and Response (ITDR) and Managed Detection and Response (MDR) services watch for exactly that kind of pattern and act on it while it’s happening. Without them, the first alert is often the moment your customers start getting phishing emails from you.