What happened, step by step
- The change: to make things easier for users, SSPR was set up so that an email code was enough to reset a password.
- The registration: a finance employee registered her personal Gmail as her reset email. The setting allowed it.
- The campaign: the attackers picked a clear target, the finance team, and sent its people targeted phishing.
- The breach: they got into the employee’s personal Gmail, which wasn’t protected like her work account.
- The reset: from the Gmail they requested a reset of her Microsoft 365 password, received the code and set a new password.
- The dwell time: in the work account, with no strong MFA to stop them, they read the finance team’s correspondence for months.
- The theft: from those emails they knew who the suppliers were and when they got paid. They forged an update of one supplier’s bank details, and the payments went to the attackers’ account. The company found out only months later.
Why this is human error, not a sophisticated attack
Nothing here was hacked in an unusual way. There were three small decisions, each reasonable at the time:
- An admin enabled email reset to take load off the help desk.
- The policy required a single method to reset, so an email code was enough.
- The employee registered the email that was most convenient for her.
Together, they made the work account exactly as secure as a personal Gmail account the organization doesn’t manage, can’t see and can’t apply any policy to.
Worth knowing: Microsoft requires administrators to use two methods to reset a password, and that can’t be changed. Regular users get whatever policy the organization set. In finance, those "regular" accounts are exactly what attackers are after.
Why a yearly assessment wouldn’t have caught it
The setting changed between two assessments. The Gmail registration came even later, when the employee signed in. A security assessment is a snapshot of the tenant on one day. The risk here built up gradually, from a setting combined with what users did with it, and stayed open for months.
What to check in your tenant now
- Is an email code allowed for password reset? In the Entra admin center, under Authentication methods, check Email OTP. For members of your organization, turn it off for password reset and prefer Microsoft Authenticator or passkeys.
- How many methods does a reset require? If the answer is one, consider requiring two, at least for sensitive groups such as finance and payroll.
- Which addresses are registered for reset? Review your users’ authentication details and look for addresses on personal domains such as gmail.com.
- Who can register authentication methods, and from where? A Conditional Access policy on the Register security information user action can require registration from a managed device or a known location only.
- Are finance accounts protected with phishing-resistant MFA? Finance is a named target. It needs the strongest protection you have.
- Is there a verification process for bank-detail changes? Every change to a supplier’s bank details is verified by phone, on a number you already have, not one from the email. That step would have stopped the theft even after the account was compromised.
How Griffin31 helps
Griffin31 checks the security settings in your Microsoft 365 tenant continuously, including the password reset policy and authentication methods, and shows you what to fix first, with the evidence behind the results. When a checked setting changes, Griffin31 flags it after its next scan, instead of you finding out months later.
Want to know how password reset is set up in your tenant? Griffin31 checks your Microsoft 365 security settings continuously and shows you what to fix first.