Hello, IT? Why the Helpdesk Became the Hacker's Front Door

It is 4:52 pm on a Friday, and you run the IT helpdesk. The phone rings. The caller is a little breathless. It is Sam from Finance, and you can hear an airport in the background: a boarding call, a rolling suitcase, a child who has strong views about something. Sam has a new phone, because the old one is somewhere in a taxi. Sam's authenticator app went with it. The board papers are due in an hour, and Sam cannot sign in. Could you please, please reset the MFA so it can go on the new phone?

Sam knows their employee number and their manager's name, and mentions him fondly. Sam knows the finance system, the project it is late for, and that your team moved to the new ticketing tool in March. Sam thanks you by name. Sam is, frankly, the nicest person who has called all week.

So you help. Helping is the job. You reset Sam's MFA and send the enrolment link. The call takes four minutes, and your weekend comes a little closer.

On Monday, Sam from Finance comes into the office with the old phone in hand. It was never in a taxi. Sam was never at an airport, and has no idea why their account has been downloading the customer database since about 5:15 on Friday.

No firewall was bypassed and no encryption was cracked. A stranger asked for the key, and a kind, busy person gave it to them, because everything about the call said "colleague in trouble". The weakness was not in the software. It was in the shape of the job.

As of July 2025, this is one of the most reliable ways into a large company. On Monday 30 June, Qantas detected "unusual activity on a third party platform used by a Qantas airline contact centre". Its statement says the incident "occurred when a cyber criminal targeted a call centre and gained access to a third party customer servicing platform", and that about 6 million customers had service records on it. The Friday before, the FBI had posted a warning that a group called Scattered Spider was expanding its targeting to include the airline sector, "often impersonating employees or contractors to deceive IT help desks into granting access". It named the exact trick in the Friday call: "convincing help desk services to add unauthorized MFA devices to compromised accounts".

I want to walk you from the phone scams everyone knows, down through how an account reset turns into a break-in, and out to the controls that stop it, including why "we have MFA" is not the answer it sounds like. By the end you should be able to rewrite your helpdesk's identity checks and map where your customers' data actually lives. Put the kettle on.

Part 1: The Oldest Hack Is a Phone Call

Start with something you have almost certainly lived through. Your phone rings, and a calm voice says it is your bank's fraud team. There has been a suspicious transaction. To stop it, they just need to confirm a few details, and could you please read out the code they are about to text you?

Most of us now know to hang up, because it has cost so many people so much. In 2024, Australians reported $107.2 million lost to scams that started with a phone call, the highest loss of any way a scammer can reach you, across 2,179 people who reported it to Scamwatch. That is about $49,000 per person who reported a loss, and it only counts the people who reported.¹

The scammer does not attack your bank. They attack you, by borrowing a role. For the length of that call, they are the bank, with the tone, the urgency and the script. You are not being asked to break a rule. You are being asked to help an authority figure fix a problem, which is something good people do all day.

Pretexting: the story does the work

The security world calls this pretexting. The attacker invents a pretext, a believable reason for the request, and wraps the request inside it. "I'm from the bank and there's fraud on your account" is a pretext. So is "I'm Sam from Finance, I've lost my phone, and the board papers are due." The request itself (read me the code, reset my MFA) would sound strange on its own. Inside the story, it sounds like the obvious next step.

A good pretext has three parts, and you will see all three in every case that follows:

1. An identity that the helper has reason to serve: a customer, a colleague, a senior manager, a contractor.
2. A problem that the helper is able to fix, and that explains why the normal route will not work ("my phone is lost", "the VPN won't connect").
3. A clock: a flight, a deadline, a board meeting. The clock is there to stop you thinking about parts one and two.

Now flip it around: a scammer pretending to be an employee, calling the helpdesk. The trick is the same. The target is much better.

Why the helpdesk is the better target

When a scammer calls you at home, the prize is your bank account. When a scammer wins at a company's helpdesk, the prize is an employee's account and everything it can reach.

Helpdesks are also built to say yes. Staff are measured on how fast they close tickets and how happy callers are. Most callers really are locked out and really are stressed. Many helpdesks are outsourced, so the person on the phone may work for a different company, reading from a process written by someone else. None of that is a failing of the people. Pretexting is simply designed to fit the job.

The attackers know this. Mandiant, Google's incident response team, wrote in May that the group it tracks as UNC3944 (the one most people call Scattered Spider) targets "organizations with large help desk and outsourced IT functions" because they are "susceptible to their social engineering tactics". CrowdStrike, quoted by Information Age, went further: it said the group used help desk voice phishing "in almost all observed 2025 incidents".

This is not only an American problem. In the second half of 2024, the Office of the Australian Information Commissioner received 404 data breach notifications caused by malicious or criminal attacks. Of those, 115 were social engineering or impersonation, which the OAIC defines as "an attack that relies heavily on human interaction to manipulate people into breaking normal security procedures". That is a little over a quarter of all the criminal breaches reported in Australia, and the OAIC called out a "significant increase" in that category.

Part 2: What We Know About Qantas, and What We Don't

Before the mechanics, let me be careful about the Qantas breach, because the coverage has filled a lot of gaps with guesses. As of the end of July 2025, here is what Qantas itself has said.

In its 2 July statement, Qantas said it detected unusual activity on the Monday, contained the system and that "all Qantas systems remain secure". The data included "some customers' names, email addresses, phone numbers, birth dates and frequent flyer numbers". Credit card details, financial information and passport details were not held there, and no frequent flyer accounts, passwords or PINs were compromised. Qantas told the Australian Cyber Security Centre, the OAIC and the Australian Federal Police.

A week later, Qantas gave the detail: about 4 million records held only names, email addresses and frequent flyer details, and the rest held some mix of addresses, birth dates, phone numbers, gender and, for about 10,000 people, meal preferences.² Group CEO Vanessa Hudson told the ABC that Qantas had received contact from "somebody purporting to be the criminal actor", and that the AFP was leading the investigation.

Al Jazeera's report noted the FBI's warning from the previous week, and most coverage made the same link. But Qantas has not named the platform or the attacker, and, according to Information Age, it has declined to explain how the breach occurred.

So the Scattered Spider link is an informed guess, not a finding. CyberCX, which was helping Qantas respond, told the ABC the attack showed "all the hallmarks" of the group. Darktrace's Toby Lewis said much the same to Computer Weekly. But Charles Carmakal, the chief technology officer of Mandiant Consulting, said it was "too early to tell" whether the group had expanded to Australian airlines, and pointed out that "various threat actors use telephone-based social engineering". Even the North American airline incidents that came before the FBI warning, at WestJet on 13 June and Hawaiian Airlines on 26 June, had not been publicly linked to the group at the time of the warning.

So this is not a reconstruction of the Qantas breach. It is about the pattern Qantas fits so neatly, because that pattern is well documented, and it is the part you can do something about.

The pattern, in other companies' words

Marks & Spencer, April 2025. In July, the M&S chairman, Archie Norman, told a UK parliamentary committee that the initial entry came through "what people now call social engineering", which, as far as he could tell, was a euphemism for impersonation. He added: "They just didn't walk up and say will you change my password. They appeared as somebody with their details. And part of the point of entry also involved a third-party." That is the Friday call, more or less.

Co-op, also in 2025. Co-op gave evidence at the same hearing. Its attack, Bloomberg reported, involved hackers impersonating an employee by answering security questions to trigger an account reset. Hold on to the phrase "security questions". We will come back to it.

Clorox, August 2023. This one has the most detail, because it is now in court. In July 2025, Clorox sued Cognizant, which ran its helpdesk, saying the attack cost it US$380 million in damages. The complaint, as reported by The Record, alleges that on 11 August 2023 an attacker posing as an employee called the service desk several times. Clorox says agents reset the employee's Okta and VPN passwords, reset their Microsoft MFA twice and changed the phone number for SMS codes, all without checking who was calling. The attacker then did the same to an IT security employee's account. Clorox's procedure, it says, required a verification tool called MyID or, as a fallback, the caller's manager's name and username, plus an email to the employee and manager after any reset. Cognizant says Clorox hired it "for a narrow scope of help desk services which Cognizant reasonably performed" and that it "did not manage cybersecurity for Clorox". A court will sort out who was at fault.³

Be somebody, ask for a reset, walk in. There is no exploit to patch. The attackers win on a phone line the company opened on purpose.

Part 3: The Reset Is a Second Front Door

max_tokensPOST./v1/messages

Think about your house. You have a good lock on the front door. You also, I suspect, have a spare key under a pot plant that everyone in the street knows about. The spare key exists for a good reason: people lose keys. But your house is only as secure as the easiest way to get a key, and for most houses that is not the lock. It is the pot plant.

In identity systems, the spare key has a name: account recovery. Every system that lets you sign in also has to let you back in when you cannot: the forgotten password, the lost phone, the security key that went through the wash.⁴ Recovery is a second way to authenticate, and it runs alongside the login all the time. The attacker takes whichever path is weaker.

What "MFA" actually proves

Remember what multi-factor authentication is meant to do. I wrote about two-factor authentication a few years ago, and the short version still holds: you prove who you are with two or more different kinds of evidence. The Australian Signals Directorate lists them as something you know (a password), something you have (a security key, a phone) and something you are (a fingerprint). An attacker who steals one kind should still be stuck without the other.

An MFA reset takes away the "something you have", because the caller says they no longer have it, and lets them enrol a new one. At that moment, the only thing between the attacker and a brand-new second factor is whatever the helpdesk uses to check who is calling. If that check is an employee number, a manager's name and a date of birth, then your multi-factor system has quietly become a single-factor system, and the single factor is "knows some facts about Sam".

That is the step the FBI named. The US Cybersecurity and Infrastructure Security Agency (CISA) updated its joint advisory on the group on 29 July, and it describes the preparation too. The attackers make several calls, some of them designed "to first learn what steps are needed to conduct password resets from helpdesks", and then call again to "convince IT help desk personnel to reset passwords and/or transfer MFA tokens". The first call is research. The second is the attack.

The questions everyone can answer

Facts about Sam work because they are not secret. A manager's name is on LinkedIn. A date of birth is in a dozen old breaches. The ticketing tool your team moved to in March was in a job advert. Mandiant's advice is blunt: avoid "publicly available personal data for verification (e.g., DOB, last 4 SSN)", because the group "often possesses this information".

This is also why Co-op's phrase matters. A security question like "What was your first school?" is still something you know, so it adds nothing to the password, and other people can find the answer.

Australia has already tested this idea in law, for telcos. Under the ACMA's customer identity rules, which started in 2022, telcos must properly authenticate customers for high-risk interactions such as requests for a new SIM. In July 2024, Telstra paid a $1.5 million penalty after the ACMA found it had not done so for 168,000 of those interactions. One detail is worth pinning up by every helpdesk phone. At Telstra's Belong brand, customers who could not complete the proper checks were asked "additional security questions" instead, which, as ARN summarised the ACMA's findings, "is not considered a valid process". The regulator has, in effect, already ruled on the pot plant.

Four ways around "we have MFA"

The MFA reset is the headline trick. Here are the four that come up again and again.

1. Take over the phone number (SIM swap). If your second factor is an SMS code, it is really your phone number, and telcos have helpdesks too. In a SIM swap, the attacker convinces the carrier to transfer control of the victim's number to a SIM card the attacker holds. Before the Australian rules changed, a name, address, phone number and date of birth were enough to get a replacement SIM. The ACMA's fix is worth noticing, because we will reuse it: call centres must now call back the number on the account, and store staff must check that the number rings on the phone of the person in front of them. They prove possession, not knowledge.⁵

2. Wear the victim down (push fatigue). Some MFA apps just ask "Is this you?" An attacker with the password can trigger that prompt again and again, late at night, until the victim taps "Approve" to make it stop. CISA calls this push bombing, where attackers "bombard a user with push notifications until they press the 'Accept' button". Pair it with a call from "IT" saying "just approve the next one, we're fixing a glitch" and it gets much easier.

3. Ask for the code (real-time phishing). A code from an app beats SMS, but a human can still read it out or type it into the wrong page. The software company Retool published a frank account of this in 2023. An employee clicked a text from "IT", used a fake login page, and then took a call from someone who, Retool says, had deepfaked the employee's actual voice. The employee grew suspicious, but still gave the caller one more MFA code, and that was enough to add the attacker's device to their Okta account. Because the employee's authenticator app synced its codes to their Google account, Retool concluded that "what was previously multi-factor-authentication had silently (to administrators) become single-factor-authentication".

4. Get the victim to connect the attacker's app (consent phishing). This one matters most for customer data platforms. Most cloud platforms let you connect other apps to your account using a standard called OAuth. You approve the app once, and it gets a token to act for you, without your password or MFA again. In June 2025, Google's Threat Intelligence Group described a group it calls UNC6040 that impersonates IT support on the phone and guides the employee to their Salesforce "connected app setup page", where the employee enters a "connection code". That code links a modified copy of Salesforce's own Data Loader tool, controlled by the attacker, to the company's data. Sometimes the app was renamed "My Ticket Portal", to match the helpdesk story. Google is clear that "attackers relied on manipulating end users, not exploiting any vulnerability inherent to Salesforce", and Salesforce itself warned its customers about the same pattern in March.

If you have ever signed into a streaming app on a TV by typing a short code into your phone, you have used the same kind of code-pairing. The code links whatever device showed it to your account. That is the convenience, and it is also the danger: the general standard for device code sign-in, RFC 8628, has a section called "Remote Phishing" that warns the flow can be "initiated on a device in an attacker's possession". The victim thinks they are helping IT fix a ticket. They are plugging the attacker's laptop into the customer database, and passing MFA for them.

To be clear: Qantas has not named its platform or said how the attacker got in. Adam Marré, the chief information security officer at Arctic Wolf, pointed out to Information Age that UNC6040 had recently targeted Salesforce, and the same article notes that Qantas is a Salesforce customer. Google says some of the infrastructure it saw in these intrusions shares characteristics with groups suspected of ties to a loose online collective known as "The Com", though it may not mean a direct link. That is a pattern worth defending against, not a finding about Qantas.

stop_reasoneval:.pass

Where the session comes in

One more layer sits under all four tricks. After you pass MFA, the system gives your browser a session token, a small secret that says "this person already proved who they are", so it does not ask again on every click. I wrote about how those tokens get stolen in the piece on session hijacking, and the OAuth token from consent phishing is the same idea with a longer life. MFA is a check at the door, not a guard who follows you around. Once the attacker is through, every system downstream sees a fully verified user. Nothing looks wrong, because on paper nothing is wrong.

Part 4: Phishing-Resistant MFA, and What It Cannot Do

For three of those four tricks, there is a real technical fix, and it is already built into the phone in your pocket.

Why a code can be phished and a passkey cannot

The Retool attack worked because the second factor was a code: six digits that a human can read out to anyone. The code has no idea where it is being used, so a fake login page can pass it straight on to the real one within the same thirty seconds.

Phishing-resistant MFA takes the human out of that loop. The main form of it is FIDO2, which includes the security keys you plug into a laptop and the passkeys now built into phones and password managers. I wrote about passkeys and their public-key cryptography when they arrived. What matters here is one detail in the Web Authentication standard (WebAuthn) they use.

When you create a passkey for a website, your device makes a pair of keys and ties them to that website's name, which the standard calls the Relying Party ID. From then on, the W3C specification says, the credential "can only be accessed by origins belonging to that Relying Party", and the authenticator makes sure operations "cannot be replayed against a different origin". The browser, not the person, checks the address. So if an attacker sends you to qantas-helpdesk-support.example, your passkey for the real site does not recognise it, and simply does not respond. There is no code to read out, and no approve button to tap in a panic. As Retool put it, with hardware keys "there isn't a code to share in the first place!"

The agencies all point the same way. CISA's fact sheet lists MFA methods from strongest to weakest, and puts phishing-resistant methods such as FIDO/WebAuthn at the top, calling phishing-resistant MFA "the gold standard". They are marked as resistant to phishing, with push bombing and SIM swaps "not applicable". SMS and voice are at the bottom. Its advisory on Scattered Spider, updated in July, recommends FIDO/WebAuthn or PKI-based MFA because they are "not susceptible to push bombing or SIM swap attacks". And the ASD says phishing-resistant MFA "should be implemented for all online services (including online customer services)", and names security keys and passkeys among the most effective methods, because they use public-key cryptography.⁶

The part it does not fix

Now the catch, and the reason this article exists. A passkey protects the login. It does nothing for the phone call.

If "Sam" rings to say the phone with the passkey on it is lost, and the helpdesk says yes on the strength of a manager's name, a new passkey gets registered, and it belongs to the attacker. The strongest login method in the world then works perfectly, on the attacker's behalf. You have fitted a bank-vault door to the front of the house and left the spare key under the same pot plant.

The same goes for consent phishing. A passkey stops the attacker from reusing your login on a fake page. It does not stop you from signing in to the real page, and then approving the attacker's app because a nice person on the phone asked you to.

So phishing-resistant MFA is necessary, and it is not enough. The rule is simple to say: the recovery path has to be as strong as the login path. Mandiant's version: employees should be "required to authenticate using strong authentication PRIOR to changing authentication methods (e.g., adding a new MFA device)". When they cannot, because the device really is lost, the helpdesk has to do the proving instead. That is where the helpdesk's process becomes the security control.

Part 5: Marisol Takes a Call

page_viewtool_use

Marisol is not real, and neither is her company; she is a worked example. She works on the service desk of a mid-sized Australian retailer whose contact centre is run by an outside provider. Every administrator uses a security key, and staff use passkeys or an authenticator app with number matching. On paper, the logins are in good shape.

On Thursday afternoon, Marisol takes a call.

3:41 pm. The caller says he is Daniel Okafor, a regional operations manager. He is at a supplier's warehouse, his laptop has died, and he has borrowed a colleague's. He needs to get into the customer service platform to approve a refund batch before 4 pm, and his phone "just did an update and wiped the authenticator". Identity, problem, clock: all three parts of the pretext are there.

3:42 pm. Under the old process, Marisol would now ask for his employee number, his manager's name and his date of birth. He would know all three; they are in his LinkedIn profile, an old staff newsletter and a breach from 2019. She would reset his MFA, and the call would end at 3:45 with a thank-you. It is the kind of fact-based check that Co-op's attackers answered.

3:42 pm, the new process. Instead, Marisol's script tells her that an MFA reset for anyone with access to customer data is a high-risk change, and it cannot be done on an inbound call. She says so, kindly: "No problem, I'll call you back on the mobile number we have on file for you. It'll be about two minutes." This is the telco call-back rule, borrowed straight from the ACMA and from Mandiant's advice to use "a call-back to a registered number or confirmation via a known corporate email". The caller controls the inbound call. He does not control the directory.

3:43 pm. "Daniel" objects. He is on the colleague's phone, the batch is urgent, and his general manager will be furious. Marisol's script covers this too. She does not argue or make an exception. She offers the other routes. "Understood. If you can't take a call on your registered number, I can do a video check with your ID, or your manager can approve it through the ticket." The script takes the decision away from her, so there is nothing to push on.

3:44 pm. He says he will call back. He does not. Marisol flags the call in the ticket as a suspected impersonation, with the number it came from and the name used, and her team lead forwards it to security. That note matters more than it looks: a log of failed attempts is how you notice that three "managers" rang from the same number in one afternoon.

3:52 pm. Security calls the real Daniel Okafor on his registered mobile. He is at his desk in Melbourne and has never heard of the refund batch.

The next morning. Security checks for the other half of the pattern: new connected apps, sign-ins from odd networks, bulk exports. The UK's National Cyber Security Centre gave retailers this same pairing of advice in May: review "helpdesk password reset processes", paying special attention to staff with elevated privileges, and watch for sign-ins from "atypical sources such as VPNs services in residential ranges".

Marisol was not smarter than the agents in the Clorox calls, or more suspicious by nature. She had a process that did not depend on her being suspicious. It moved the proof from "what do you know about Daniel?" to "can you answer Daniel's phone, show Daniel's face, or get Daniel's manager to click approve?". Those are things an attacker with a copy of LinkedIn cannot do from a warehouse that does not exist.

Part 6: What to Do This Week

The Qantas pattern has two halves: where your customer data sits, and who can talk their way into it. So does the fix.

First, map where your customer data lives

Qantas says its own systems "remain secure". The data was on a third-party platform used by a contact centre. That is a normal arrangement, and it is probably true for you too: customer records now live in a CRM, a helpdesk tool, a marketing platform, a contact centre provider's systems, and whatever those connect to. The FBI's warning said the group targets "large corporations and their third-party IT providers", and that "anyone in the airline ecosystem, including trusted vendors and contractors, could be at risk". Swap "airline" for your own industry.

Draw the map. A spreadsheet will do. For each system:

1. What customer data is in it? Names, emails, phone numbers, dates of birth, addresses, loyalty numbers, notes. Be specific: an email list and a record that can answer someone's security questions are very different risks.
2. Who can reach it? Your staff, the vendor's staff, an outsourced contact centre, integrations. Count the people, roughly. M&S' attackers, BleepingComputer reported, posed as one of the roughly 50,000 people working with the retailer. Every one of them is a possible identity to borrow.
3. Whose helpdesk can reset access to it? Most maps miss this. If your contact centre agents' accounts are managed by the provider, the provider's helpdesk is part of your security.
4. What apps are connected to it? List every OAuth app and who approved it. Google's advice for Salesforce customers is to restrict "Customize Application" and "Manage Connected Apps" to a small set of trusted administrators, and to consider allowlisting known safe apps.
5. Where can it be reached from? Salesforce recommends restricting login IP ranges to your enterprise and VPN network at the profile level.
6. Would you notice a bulk export? Google describes attackers making small test queries and then "rapidly" increasing the volume to extract entire tables. Find out whether your platform can alert on large downloads, and whether anyone reads the alert.
7. Who is the security contact? Salesforce asks customers on its Signature and Premier support plans to add a Security Contact. Do it for every platform, with a monitored inbox, not the person who set up the account in 2019.

While you have the map open, ask whether each system needs everything it holds. A date of birth that is not in a contact centre platform cannot leak from it. Data you do not keep is data you do not have to protect.⁷

Second, rewrite the helpdesk's identity checks

This is the part that would have changed the Friday call. The list draws heavily on Mandiant's May guidance, the most detailed public playbook I have found. Start with privileged accounts and anyone who can reach customer data.

• Name the high-risk changes. Password and MFA resets, new MFA devices, changes to an account's phone number or email, and new access. Treat them differently from "my printer is jammed".
• Stop using facts as proof. Remove employee number, date of birth, manager's name and security questions as the only check for any high-risk change. They can be one input. They cannot be the gate. The Telstra penalty is your local precedent if anyone argues.
• Prove possession or presence instead. Mandiant lists on-camera or in-person verification, ID checks and challenge-response for privileged accounts, and out-of-band confirmation for high-risk changes. In practice: call back on the registered number from the directory, never the one the caller gives; or confirm through a known corporate email; or have the manager approve in the ticketing system, while signed in with their own phishing-resistant MFA.
• Require strong authentication before changing authentication. If the user can still sign in with a passkey or security key, make them do that before they add or remove a factor. The helpdesk path is only for the truly locked out.
• Tell people when their security changes. Notify the old email and phone whenever a password or MFA method changes. Clorox's complaint says its post-reset email was never sent. It is the cheapest alarm you will ever install.
• Give agents a script that says no for them. A written rule that high-risk changes are never done on an inbound call, with no exceptions for seniority, takes the clock off the agent, including when the caller really is the CEO.
• Tighten up when the threat is high. Mandiant suggests temporarily disabling self-service MFA resets during elevated threat periods. A public FBI warning about your industry counts.
• Log the failures, not only the successes. Record every refused or abandoned high-risk request, with the number and the name used. That is how you spot the research calls that come before the real one.
• Watch for fake helpdesks, too. Attackers register lookalike domains such as targetsname-helpdesk.com, which CISA lists as a real pattern. Mandiant also warns about attackers posing as IT support on Microsoft Teams. Tell staff, in plain words, that IT will never ask them to read out a code, approve a prompt they did not start, or enter a "connection code" on a setup page.
• Put the same rules in your contracts. If a provider runs your helpdesk or contact centre, its reset process is yours. Write your rules into the contract, and test them.
• Test it. Have someone you trust call your helpdesk with a good pretext and ask for an MFA reset. If it works, you learned something cheaply.

Third, finish the MFA job

With the reset path closed, login upgrades pay off. Move administrators and anyone with bulk access to customer data onto security keys or passkeys first; Mandiant's advice is to use FIDO2 security keys for privileged roles and to "remove SMS, phone call, and/or email as authentication controls". Where you cannot yet, turn on number matching for push approvals, which CISA rates as resistant to push bombing, and stop allowing users to fall back to SMS.

And if you are one of the customers

If your details were in the Qantas platform, the stolen fields are raw material for the next phone call, aimed at you. Qantas' advice is sound: always "independently verify the identity of the caller by contacting them on a number available through official channels", and never give a password or login details to anyone who calls. It is the call-back rule again. Then move your important accounts off SMS codes, starting with email. Your email is the recovery path for everything else, which makes it your pot plant (and email has its own security layers worth knowing).

Final Thoughts

Go back to 4:52 pm on that Friday, and to the kind person on the helpdesk who reset Sam's MFA. They were not careless. The process asked them to judge a stranger's identity by ear, under time pressure, using facts half the internet knows. Most of us would have made the same call, and the attackers count on that.

If you keep one idea, keep this one: every way back into an account is a way into the account. Your security is set by the easiest of those ways. For most organisations in July 2025, that is not the login page with its shiny MFA. It is the phone line where a helpful person can reset it, at your company or at your vendors'.

So this week, do two things. Draw the map of where your customer data lives and who can reset access to each piece of it. Then take your helpdesk's reset script, find every step that relies on a fact a stranger could know, and replace it with a call-back, a video check or an approval from someone signed in with a passkey. Neither job needs new software. Both need someone to decide that "please, I'm about to board a plane" is not proof of anything.

As for me, I am down here in Tasmania, a long way from most call centres, with about 1,820 cups of tea a year to get through. If anyone rings claiming to be me and asks for an MFA reset because I have lost my phone, please call me back on the number you have. I will be the one who answers, holding a perfectly good phone in one hand and a cup of tea in the other.

Notes

1. The $49,000 figure is my division of $107.2 million by the 2,179 people who reported a loss. Scamwatch only sees the people who choose to report, so the real total is higher and the real average could be lower or higher. ↩

2. Qantas' first statement said 6 million customers had records on the platform. After it removed duplicate records, its 9 July update gave 5.7 million unique customers, noting that a person with several email addresses may have several records. ↩

3. Clorox's complaint says its verification rules were updated in January 2023, several months before the calls. The dispute is whether the helpdesk followed them, not whether they existed, which is a useful reminder that a process on paper is not a control until someone checks it is used. ↩

4. Security keys are surprisingly tough. The more common failure is that the key survives the wash, and the person cannot find the jeans. ↩

5. There is a second, more technical way to steal SMS codes: attacks on SS7, the decades-old signalling system that phone networks use to route calls and texts between carriers. CISA lists it alongside SIM swaps as a reason to move away from SMS codes. ↩

6. The ASD makes one more point that surprises people. The "remember this computer" box on a login page turns multi-factor authentication back into single-factor authentication for as long as the token on that device is valid, because from then on only the password is checked. ↩

7. Under Australian Privacy Principle 11, organisations must protect the personal information they hold, and in certain circumstances must destroy or de-identify it. Deleting data is a security control the law already asks for. ↩