A Compromised Microsoft 365 Account

A Compromised Microsoft 365 Account

A Compromised Microsoft 365 Account

No malware, no payload, no endpoint alert. Account takeover is the attack that endpoint tools structurally miss, because nothing malicious ever runs on a device. Someone signs in with a real password from the wrong side of the world and starts working quietly inside a mailbox. This is how it gets caught. 


enhanced.io is a channel-only Open XDR SOCaaS built exclusively for MSPs, with 400+ integrations across endpoint, network, cloud, identity and IoT/OT. 

The situation


A finance user's credentials surface in a breach dump from an unrelated service, reused on their work account. Weeks later, someone signs in from an unfamiliar country at 4am local time. The session looks legitimate to the mail platform: right password, valid session, no malware anywhere. 


The attacker's first moves are quiet ones. A mailbox rule to forward invoices externally. A second rule moving replies from a specific supplier straight to a hidden folder. The groundwork for payment fraud, laid without touching a single endpoint. 

What we detect


Identity telemetry flags the login: a country the account has never signed in from, at an hour outside the user's pattern, minutes after a legitimate session elsewhere. Geography rules set at onboarding score it immediately, because sign-ins from that region were flagged or blocked in the baseline. The cloud connector then reports the new mailbox rules, and rule creation plus anomalous login correlates into one High case on the account. 

What gets automated


Per the response posture agreed at onboarding, the session is revoked and the account is disabled pending a credential reset. The forwarding rules are flagged in the case for removal. The account stops being useful to the attacker within minutes of the rule creation, which is usually before a single message forwards. 

Where humans step in


An analyst reviews the mailbox for what the attacker touched: rules created, messages read, anything sent. The check widens to other accounts for the same login pattern, because credential dumps rarely contain one employee. Escalation to the MSP includes the reset requirement, the rule cleanup, and a recommendation: this user's credential hygiene, and possibly the client's password policy, needs a conversation. 

The outcome


The account is back with the user by morning under a new credential. No invoices redirected, no fraud initiated, and the client hears about it from their MSP as a contained event with a clear remediation list. The alternative version of this story ends weeks later with a supplier asking why an invoice was paid to the wrong account. 

Check your own stack


  • Would an impossible-travel login on a client tenant reach a human today? 

  • Does anything alert on new mailbox forwarding rules? 

  • Who has authority to revoke a session at 4am? 

  • Are geographic sign-in rules set per client, or not at all? 

Want to know what your current setup does in this scenario?

Want to know what your current setup does in this scenario?

Want to know what your current setup does in this scenario?

Book a 30-minute call with Hannah Lloyd, our co-founder