Nobody exploited anything: who verifies it is you before resetting your MFA

On Friday 7 August, Levi Strauss & Co. filed an 8-K with the SEC to report that an unauthorised third party gained access to three company-issued computers through social engineering and walked away with corporate information. The filing names no CVE and no unpatched version: the only vector it declares is that one. There is nothing there that could have been closed the previous Tuesday by applying updates, and that is exactly the part that interests us. The work most of us use to measure security — patch, update, reboot — would have changed nothing.

We are writing this from an uncomfortable position. The joint CISA and FBI advisory on Scattered Spider, reference AA23-320A, describes a group that targets large companies and the contracted IT help desks those companies rely on. We are a contracted IT help desk: we provide managed 24x7 support to companies. When somebody calls saying they lost their phone and cannot get into their mail, the person deciding what happens next works for us. The advisory is about large companies, and it is worth saying so rather than inflating the alarm; but the procedure it describes runs the same way at a thirty-person firm, with fewer people to verify and more prior familiarity. So this article is, first of all, about our own procedure.

What the 8-K says and what it does not

It pays to be precise, because within two days this story was already being told several different ways. The text Levi Strauss filed says an unauthorised third party accessed and exfiltrated certain corporate information after gaining access to three company-issued computers through a social engineering attack. It adds that the response contained the access, that business operations were not disrupted, that the company believes no consumer data was impacted, and that it does not consider the incident likely to have a material impact. The investigation continues with outside help.

And now what it does not say, which matters just as much: it does not say how the social engineering worked. We do not know whether it was a phone call, a Teams message, an email or a mixture. There is no attribution: no group has claimed it, and the links some outlets have drawn to voice-phishing campaigns are hypotheses, not confirmed fact. We had no part in responding to that incident and hold no inside information. If somebody hands you the exact script of the call, they are making it up.

That is enough for the point at hand. Three computers. No vulnerability involved. A company with a multinational-sized security budget. And a vector that was not technical.

That 65% no longer arrives through a CVE

Unit 42's annual incident response report — Palo Alto Networks' unit — published on 17 February 2026 and covering the more than 750 major incidents they handled during 2025, puts a number on it: 65% of initial access is achieved with identity-based techniques — credential theft, MFA bypass and IAM misconfigurations. And identity weaknesses played a material role in almost 90% of the investigations they ran. That is what they found when they went in to clean up, not a projection. Nor is it the first figure of this family we have quoted this summer, and they all push in the same direction.

That figure is awkward above all for where it leaves the effort. A decent patching cycle costs money, maintenance windows, night-time reboots and arguments with whoever does not want their server touched. All of that remains necessary and we defend it every week. But it covers the smaller half of the problem. The bigger half is settled in three minutes of conversation, with no technical log, by a tired person on the other end who wants to help and close the ticket.

The failure is not the person answering the phone

Advisory AA23-320A, updated on 29 July 2025, describes the method with a dryness we appreciate: attackers pose as employees to convince IT or help desk staff to hand over sensitive information, reset the employee's password and move their MFA to a device the attacker controls. And it adds the detail that gave us most pause: they use "layered" techniques, with several prior calls and contacts whose only purpose is to work out which steps a reset requires at that particular organisation.

Read that again. The attacker does not break the procedure: they study it. They call at nine, ask something trivial, hang up. They call at eleven with another excuse and check whether they are asked for an employee number. By the third call they know the questions and bring the answers. Anti-phishing training for staff does little here: the person taking the call is one of ours, and they are doing their job exactly as instructed.

Here is the thesis of the whole article, and it indicts the procedure, not the people: in a great many organisations — including many that get audited and certified — sounding convincing counts as identity. Knowing your manager's name, the department, the last four digits of an ID number or your start date proves nothing, because all of it sits on LinkedIn, in an old breach dump or in the signature of any email. If your verification rests on things that can be known, your verification is a quiz, not proof.

The reset is the back door to any factor

There is a very common answer to this that is half right, and therefore dangerous: "we already run phishing-resistant MFA". We wrote a few weeks ago about Microsoft Entra retiring SMS as a second factor and why passkeys are better. They still are. But a cryptographic factor protects the use of a credential, not its enrolment. If the support desk can register a new factor for an account at the request of whoever is calling, the attacker does not need to break anything: they enrol themselves.

Put another way: the strength of your authentication is the strength of the weakest path to obtaining it, and that path is almost never the cryptographic one. It is the "I lost my phone" form. This deserves the same scrutiny we give the provider's privileged access: a few days ago we wrote that your IT provider's remote management agent is attack surface, and this is the same problem seen from the other end of the cable. One grants access to the machine; the other, to the identity. In practice they end up in the same place.

Eight things we ask for before a reset

This is our own criterion, not a standard you can cite in an audit. It is what we consider the minimum for a password reset or an MFA re-enrolment not to hinge on how convincing a voice sounds. Eight points, and not one of them requires buying software:

• Call back on the number in the directory. Not the number on the screen, and not the one the caller dictates. If the directory number is out of date, the directory is the problem and needs fixing — not skipping the step.
• Out-of-band approval from a named manager. A second human, on a different channel, confirming the person is who they claim. And named: "somebody in HR approved it" does not count.
• Ban "knowable" data as proof. ID number, start date, manager's name, employee number: useful to find the record, never to authorise the change.
• Video verification with an ID document for the accounts that warrant it. It is awkward and slow. It is also the only thing that cannot be solved by reading a public profile.
• A short list of accounts support never resets by phone. Global admin, the board, finance, whoever signs payments. For those: in person, or with a second approver from the company itself.
• Automatic notice to the legitimate user on a different channel. If somebody's MFA is reset and it was not them, they should know within the minute and know who to call.
• A quarantine window after re-enrolling a factor. A few hours during which that identity cannot reach the most sensitive systems. A real employee who lost their phone can wait until tomorrow to get into corporate banking; an attacker in a hurry cannot.
• Explicit permission to say no. In writing, signed by the client's management: nobody on support will be reprimanded for making a director wait when they could not be verified. Without this, the previous seven points are decoration.

The eighth is what actually decides whether any of this works, and it is the only one that does not depend on us. Hierarchical pressure is the attack's main tool: the caller exaggerates the urgency and their job title precisely because they know that at seven in the evening nobody wants to be the one saying no to the CFO.

The price, in minutes and in annoyance

A reset that today takes three minutes starts taking twenty or thirty, and some do not get resolved until the next day. Somebody will get angry, and fairly so, because they are late to a meeting thanks to a procedure of ours. That is the real price and we are not going to dress it up: identity security is paid for in friction, not in licences.

That is why this is not an IT department decision. A provider cannot impose friction on its client's users unless the client's management has accepted it in writing beforehand, because by the third complaint the friction evaporates and back comes "well, I know this one". The hard conversation, when this gets defined properly, is agreeing who can be made to wait.

Four shortcuts we will not take

• Buy more anti-phishing training and call it done. It helps with email. The problem is elsewhere: the decision here sits with your support staff, and what they lack is a procedure that lets them refuse.
• Trust caller ID. Spoofing the originating number is harder than it was two years ago: since June 2025, under Spain's Order TDF/149/2025, carriers have had to block inbound international calls presenting Spanish numbering. But that block does not cover calls originating inside Spain, and it does not turn caller ID into proof. The company's internal number showing on the screen authorises nothing.
• Apply the hard procedure to everyone. If video verification costs the intern the same as the CFO, the intern stops calling and works around it, which is worse. Grade it by what the account can actually do.
• Assume an incident like this shows up in the ticket. An approved reset raises no alert: it is a legitimate operation performed by legitimate people. It only becomes visible afterwards, in what the account does next.

And after the call

The last item on that list is what connects to the other half of the job. If access is obtained through the front door with the right keys, no entry barrier will stop it; what remains is noticing what happens next. A mailbox that suddenly creates a forwarding rule, an account signing in from a new location twenty minutes after a reset, a laptop that starts reading shared folders it never opened before. That is managed detection and response, and it is the second control for when the first has been walked straight past.

With one caveat we have been repeating since we wrote about alert fatigue: an MFA re-enrolment alert landing in a mailbox nobody reads is exactly as useful as not having it. If you are going to raise a notice on every factor change, decide first who reads them on a Sunday afternoon and what they do about them. If the answer is "we will look on Monday", better not to switch them on and not to kid yourself.

None of this is new, and that is the problem. CISA's advisory has been explaining the method since 2023, was updated over a year ago, and still describes precisely what happened on Friday at a company far larger than most of the ones we look after. If you have never written down what gets asked before an MFA reset, today is a good day. And if you want us to go through it with you, let's talk and we will work through whatever you already have written down.