A hijacked company mailbox and a fraudulent invoice

The company uses email in Microsoft 365. Sign-in is protected by a username and password only, with no second factor. Supplier invoices arrive by email and the accountant pays them by bank transfer.

Microsoft 365 records sign-ins and setting changes in the unified audit log. It is on by default, but with no alerts configured nobody notices a change until something goes wrong.

A supplier phoned to ask why the company had not paid an invoice. The accountant, though, had received an email the day before, in the same thread, asking for payment to a new bank account. It looked like a continuation of the conversation with the supplier.

It turned out an attacker controlled one employee's mailbox. Earlier they had sent that employee a phishing email with a link to a fake Microsoft 365 sign-in, where the employee entered their password. With no second factor, the password alone gave full mailbox access.

The attacker read the thread with the supplier, joined it, and wrote to the accountant with a change of bank account. They also created a hidden rule in the mailbox that moved replies from the supplier and the accountant out of sight, so the exchange would not give them away. This is a classic mailbox takeover (business email compromise).

Prerequisite: the attacker needs only the victim's password, obtained by phishing, and a mailbox with no second factor. Nothing else.

The first cause is password-only sign-in. Without a second factor, one password captured by phishing becomes full mailbox access.

The second cause is that the mailbox allowed a rule that silently moves and deletes mail. That let the attacker hide their activity from the mailbox owner.

The third cause is in the payment process: the change of bank account went through on an email alone, with no verification through another channel. That is what turns a hijacked mailbox into money.

The Microsoft 365 unified audit log was searched for sign-ins to the mailbox: source IP and country, time and impossible travel, meaning two sign-ins from places a person could not move between in that time. One sign-in from abroad did not fit the employee.

Connect-ExchangeOnline

# the hidden rule an attacker leaves to bury the supplier's replies
Get-InboxRule -Mailbox user@firma.sk |
  Select-Object Name, Enabled, MoveToFolder, DeleteMessage, ForwardTo

# sign-ins and rule changes, from the unified audit log (auditing must be on)
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
  -Operations New-InboxRule,Set-InboxRule,UserLoggedIn `
  -UserIds user@firma.sk |
  Select-Object CreationDate, Operations, AuditData

The audit also showed a mailbox rule created at the time of the foreign sign-in. The rule moved messages from the supplier and the accountant to a little-watched folder.

Sent items were reviewed for whether the attacker had written to others, and other mailboxes for whether more than one account was involved. Whether any payment had actually gone out was checked.

For the period the audit does not cover, it cannot be shown what the attacker read. The incident record says so.

Immediately: reset the compromised account's password and revoke all active sessions and tokens, so a signed-in attacker is dropped. A password change alone does not evict them from an already open session.

The hidden mailbox rule was removed, and the mailbox was reviewed for any other rules or forwarding the attacker had left.

A second factor was turned on for everyone, along with conditional access. Legacy authentication, which bypasses the second factor, was blocked.

The payment process gained a rule: any change of bank account is verified by the accountant with a call back to the supplier's known number, never a number from the email.

Alerts were enabled for the creation of a new mailbox rule and for mail forwarding out of the company.

The supplier was informed, and the correct bank account was confirmed with their accounting.

A second factor turns a stolen password from full access into an incomplete attempt: the password alone does not finish a sign-in.

Blocking legacy authentication closes the protocols that ignore the second factor; otherwise it would be bypassed.

Revoking sessions evicts an attacker who is currently signed in, which a password change alone does not do.

Removing the rule gives the mailbox owner back the view of their own mail.

Verifying an account change by calling back stops the fraud even when the email is in the attacker's hands, because the money no longer depends on the email alone.

What it does not address: MFA does not stop an attacker who phishes the password and the second factor in real time or steals an already open session. That is why the rule alerts and payment verification matter.