No System Is Risk Free: Why Big Companies Keep Falling for the Same Phone Call

In 2025, an attacker impersonating “Qantas IT help” called one of the airline’s contact centres and talked an agent into connecting a modified version of a legitimate CRM tool. Personal data on 5.7 million customers, names, birthdates, phone numbers, frequent flyer details, walked out the door. No malware, no exploit, nothing a patch would have stopped. Three years earlier, Medibank lost health and personal records on 9.7 million people after a contractor’s personal device was infected with malware, harvesting login credentials that bypassed a misconfigured firewall because multi-factor authentication wasn’t enforced on remote access. Different mechanisms, same underlying story: a person or a process was the actual gap, not the technology sitting around it.

That’s worth sitting with, because a lot of security spending is built around the idea that enough of the right tools, endpoint protection, MFA, network segmentation, will get a business to something close to safe. No system is risk free, whatever a vendor’s pitch deck implies. Qantas shows what happens when a well-resourced organisation gets beaten by phishing and vishing from an advanced, patient attacker. Medibank shows what happens when an identity and credential gap, an unenforced MFA policy, a contractor’s unmanaged device, quietly sits there until someone finds it. Both are still the leading edge of how big businesses actually get breached. Mandiant’s M-Trends 2026 report puts voice phishing as the second most common initial access vector in 2025, and stolen or misused credentials aren’t far behind it.

How it actually works

Most people picture social engineering one way: someone calls the help desk pretending to be an employee. That’s a real and common pattern. But the same crews, tracked under overlapping names like Scattered Spider, UNC3944, and Octo Tempest, run it in reverse just as often, calling actual employees while pretending to be the help desk. A campaign tracked through mid-2026 shows this version clearly. The attacker calls someone’s personal mobile, not their work line, and says IT needs them to complete an urgent security migration. The employee gets sent to what looks like a normal company sign-in page. It isn’t. It’s sitting in the middle of the real connection, capturing the password and MFA code as they’re typed, then using both immediately before either expires. The Qantas incident ran the first version, an attacker posing as staff to a contact centre.

Medibank shows the other common failure mode, where the problem isn’t a convincing phone call but a basic identity gap. A stolen credential, a device without endpoint protection, a remote access path without MFA. No conversation happens at all. The attacker just walks through a door nobody remembered to lock.

Both failure modes rely on the same underlying weakness: a business assuming its process, or its perimeter, is more trustworthy than it actually is. An employee ID, a manager’s name, or a saved password sitting in a browser profile is often all it takes, the kind of detail that takes an attacker twenty minutes to gather or a piece of commodity malware to lift.

No vendor can promise to stop this outright

It’s worth saying plainly rather than dressing it up. Anyone selling total prevention against either of these failure modes is selling something that doesn’t exist. Qantas didn’t fail because a firewall rule was missing, it failed because a person made a call that seemed reasonable under time pressure. Medibank didn’t fail because of some exotic zero-day, it failed because one contractor’s laptop and one missing MFA policy were enough. You can make both of these processes much harder to break, and you should, but as long as a human can override an automated check for a good reason, or a credential can be lifted from an unmanaged device, some percentage of attempts will get through. Prevention lowers the odds, and that matters, but it was never going to take them to zero. That’s why detection ends up mattering more than most security budgets reflect. If an attacker only needs to succeed once, what actually holds up is noticing quickly when prevention didn’t work.

Why the target is almost always Microsoft 365 or Google Workspace

Whichever failure mode gets an attacker in, what they’re usually after is the same thing: whichever identity provider unlocks everything else the business runs on. For most Australian companies today that’s Microsoft 365 or Google Workspace, where one set of credentials can open email, files, admin consoles, and every app connected through single sign-on. A successful reset or stolen credential on one of these accounts can mean global admin access, an OAuth grant to a malicious app that survives a password change, or quiet inbox rules that redirect mail before anyone notices. It also gives the attacker a legitimate-looking internal identity to use for the next step, which is how a single successful compromise sometimes escalates from a regular account to tenant-wide access over a series of moves rather than one clean break.

This is exactly where detection matters more than any single control. Every step of this can look legitimate to a system built around known bad signatures: the credentials are real, the MFA prompt gets satisfied, the session token is valid. There’s no failure to alert on, just a login that shouldn’t have happened using an identity that technically checks out. This is roughly what SensorZero is built to catch on the identity side, by building a picture of what normal looks like for each M365 or Workspace account rather than watching for known attack patterns. That covers the same account signing in from one city and then somewhere it couldn’t plausibly have reached minutes later, a new authenticator registered shortly after a help-desk interaction, a mailbox rule appearing right after an odd sign-in, or consent granted to an app the account has never touched before. On their own, any of these can look explainable. Set against a reset or a suspicious sign-in from an hour earlier, they usually aren’t, and the platform pulls that history together into one alert written in plain language rather than leaving someone to piece it together from scattered logs at 2am.

If you’d like help pressure-testing your own help-desk process and identity controls, or want to see what this kind of detection looks like against your own M365 or Workspace tenant, get in touch.