A random call today turned into a full account takeover — and it started with something that looked completely normal.
A Perth small business rang us after losing access to their work email. Password resets weren’t working. Email stopped syncing. Even MFA “wasn’t working”. Their first thought was the same thing most teams think: “How can someone get in if MFA is enabled?”
Here’s what happened.
They’d had an issue with Xero earlier in the day, then received a phone call from “support” that sounded legitimate. The caller knew the right language, guided them through a few steps, and asked to remote into the PC to “fix the problem”. Everything looked fine… until about an hour later.
Then the signs hit:
Outlook stopped syncing.
They were suddenly logged out of their email.
Password reset attempts failed.
MFA prompts weren’t coming through (or didn’t help).
“But we had MFA…”
MFA helps a lot — but it’s not a magic shield.
In attacks like this, the goal often isn’t to “guess your password”. It’s to steal a browser session (the authenticated token/cookie that proves you already logged in). Once the attacker has that session, they can effectively bypass MFA because the session is already trusted.
After that, the playbook is simple:
Get in using the stolen session
Change the password and recovery details
Lock the real user out
Expand access (especially if that user has admin rights)
And that last point is where small businesses get hit hardest: one person often has admin privileges “because it’s easier”.
The real root cause (in SMBs)
Not just the scam call — it’s the combination of:
One user with global admin privileges
No conditional access rules
No phishing-resistant sign-in controls
No monitoring/alerting that flags impossible travel, token use, suspicious sign-ins, or admin changes
Resolution (the right way)
If this sounds even remotely like your environment, these are the hardening steps that stop repeats:
Remove standing admin access: use least privilege (separate admin accounts, just-in-time elevation).
Enforce Conditional Access: location/device compliance, risky sign-in policies, block legacy auth.
Add phishing-resistant sign-in protections: session/token theft resistance settings and stronger authentication methods.
Lock down remote access: staff should have a clear rule—no remote access granted to “support” unless it’s a known, verified provider.
Have an IT partner you trust: someone who can respond fast and put the guardrails in place before the next call comes in.
Question for Perth SMB owners and office managers:
Have you ever had a “support” call that felt legit—but something didn’t sit right afterwards? What happened?
