The Second Factor That Is Not

18.0 What this chapter gives you#

1. You will be able to explain why most of the second factors a person is offered stop one attacker and not another, and name which attacker each one stops.
2. You will be able to describe an adversary-in-the-middle attack in exact terms: what the reverse proxy rewrites, which headers it changes, and why the stolen session cookie matters more than the stolen password.
3. You will be able to name the public toolkits that made this attack routine, give the years they appeared, and explain what a phishing-as-a-service subscription buys a criminal who cannot write code.
4. You will be able to describe push notification fatigue precisely, name three real 2022 intrusions that used it, and say what each victim organization published about how it happened.
5. You will be able to say exactly what number matching fixes, what it does not fix, and why a mitigation that defeats a silent attacker can fail against a talkative one.
6. You will be able to walk through a SIM swap from target selection to money out, put real figures on what it costs and what it has earned, and name the American and British rules that now govern it, with dates.
7. You will be able to explain how a text message is diverted on the signalling networks between telephone operators, name the specific messages involved on both the older and the newer network, and say which subscribers are exposed.
8. You will be able to state the property that separates a phishable authenticator from an unphishable one, apply it to a method you have never seen, read a WebAuthn client data structure, and rank second factors against each named attack from evidence rather than from marketing.

Almost every piece of advice about accounts ends in the same place: turn on two-factor authentication. It is good advice. It is also, in the form most people are given it, advice that solves a problem they may not have while leaving untouched the problem they do have.

The problem it solves is the attacker who has your password and nothing else. He bought a list of leaked passwords, or he guessed, or he found your password in a file traded four years ago, and he is trying it from a machine far away with no other resources at all. Against him a second factor works beautifully. He types the password, the site asks for something he does not have, and he moves on to the next of the ten thousand accounts on his list.

The problem it does not solve is the attacker who is present. Not present in your house, but present in the transaction: sitting between you and the website in real time, or holding your telephone number, or ringing your phone at two in the morning until you press the button. Against him most second factors do not merely weaken. They are forwarded, along with everything else, and the site sees a perfect login. Nothing breaks. No specification is violated. The code was valid, used once, within its window, exactly as designed.

This chapter is about the gap between those two attackers and about the one property that closes it. The property is not “hardware”, and it is not “biometric”, and it is not “out of band”. It is that the thing you produce must be worthless to anyone except the specific website you meant to talk to. The chapter before this one, “The One-Time Code”, built the codes we are about to watch being forwarded, and the chapter after this one, “Biometrics”, deals with fingerprints and faces, which are a separate argument. Here we ask one question about each method: can it be relayed.

The plain version#

Two locks, and the thief who has one key#

Start with what a second factor is trying to do, in the plainest possible terms.

A password is a thing you know. If somebody else comes to know it, they can be you. That is the whole weakness, and it is a big one, because knowledge copies perfectly and silently. You cannot tell by looking at your password whether somebody else also has it.

So we add a second thing, of a different kind. Not another thing you know, because a second password has the same weakness as the first. Instead, something you have: a phone in your pocket, a small plastic key on your keyring, a card in your wallet. The idea is that a thief far away might steal your knowledge, but he cannot reach into your pocket from another country. Two locks on one door, and he holds the key to one of them.

For an enormous number of attacks this works exactly as promised. The man with the stolen password list is stopped dead, because the second lock needs a thing he cannot obtain in bulk.

But notice the assumption hiding inside the idea. It assumes the thief is far away and working alone with old information. The moment he is present at the door at the same time as you, the picture changes completely, and the rest of this section is four different ways in which he can be present.

The man with the clipboard outside the bank#

Picture a bank on a busy street. Inside, at the counter, the teller has good procedures. She asks for your account number. She asks for your password. Then she says: “We have just sent a number to your telephone. Read it to me.” You read it. She pays out your money. Three checks, all sound.

Now picture a man who sets up a small folding table on the pavement outside, with a printed sign that says “Queue here for counter service”. He has a clipboard and a lanyard and a helpful manner. You join his queue because the sign looks official and you are in a hurry.

He asks for your account number. You give it. He asks for your password. You give it. He excuses himself, walks inside, and says both to the real teller. The real teller sends a number to your telephone. The man walks back out and says, pleasantly, “The system has sent you a code, could you read it to me”. Your phone has just buzzed, so this makes sense. You read out the six digits. He walks back inside, reads them to the teller, and collects your money.

Every check the bank made was answered correctly. The account number was right. The password was right. The code was the real code, sent by the real bank, to the real telephone, used once, inside its lifetime. The bank’s procedures were not broken. They were satisfied by the wrong person, because nothing in the procedure could tell the difference between you standing at the counter and you standing on the pavement talking to a man with a clipboard. On the internet the folding table is a website that looks like the real one, and the man who walks in and out is a piece of software that passes everything through in both directions in a fraction of a second. He is not breaking the code. He is carrying it.

There is one more part, and it is the part people miss. When the man collects your money, he does not have to come back tomorrow and do it all again. The teller, satisfied, has stamped his hand and told him he may come and go all day. On the internet that stamp is a small file the website gives your browser so it does not have to ask again on the next page. The man takes the stamp for himself. Your password can be changed tonight and your code app can be reset, and the stamp on his hand still works until it wears off.

The doorbell pressed at two in the morning#

The second way of being present needs no fake table at all.

Some systems, instead of showing you a number to type, send a message to your phone that says “Someone is signing in. Is this you? Yes or No.” It is popular because it is easy. One tap and you are in.

Now suppose the thief has your password and nothing else. He types it into the real website. The website, satisfied with the password, sends the question to your phone. You are asleep. You wake, see it, and press No.

He types it again. Your phone asks again. You press No again.

He has a computer, he is patient, and it costs him nothing. At half past two in the morning, on the thirtieth buzz, you press the green button. Perhaps because you are half asleep and it is the bigger button. Perhaps because you assume something in your office is misbehaving and you want it to stop. Perhaps because somebody telephones you at that moment, sounding tired and official, says he is from your company’s technical support, that the system is stuck in a loop, and that if you approve the next one it will settle down.

You have now let him in, with your own thumb, and no lock was picked. This is exactly what happened at several very large companies during 2022, which we will look at with names and dates in the technical half.

The defence bolted on afterwards is only a partial defence. Instead of Yes and No, the website shows a short number on the screen where the login is happening, and your phone asks you to type that number in. If you are asleep in bed and the login is in another country, you have no number to type, and the buzzing becomes useless. It becomes useless against a silent attacker. It does not become useless against the man on the telephone, because he is looking at the screen where the number is displayed and can simply read it to you. The improvement is real and it is narrower than it sounds.

Redirecting the post#

The third way of being present is to take over the channel itself.

If your bank sends codes by text message, then whoever receives your text messages is, for that purpose, you. Your telephone number is not a physical object. It is an entry in your telephone company’s records that says which little card, in which handset, should receive traffic for that number. Change the entry and the traffic follows.

So the attacker does not attack you or the bank. He attacks the shop. He walks into a telephone shop with a story and a piece of identification, or he telephones the support line with enough of your personal details to sound convincing, and he says he has lost his handset and needs the number moved to a new card. Sometimes he does not even do that; sometimes he pays somebody who already works there.

If it works, your handset goes quiet, which you may not notice for hours, and every code your bank sends arrives on his. Not copied. Delivered, exclusively, to him, by the telephone company, correctly, according to its own records.

This has a name, and it has a criminal price list, and we will follow a real case through it later: a man was paid about fifty thousand United States dollars to do exactly this to one telephone number in January 2024, and the number belonged to an agency of the United States government.

The sorting office that trusts every label#

The fourth way is quieter and older, and most people have never heard of it.

Telephone companies have to cooperate. When you fly to another country and your phone finds a local network, that local network has to ask your home network questions: does this subscriber exist, is she allowed to make calls, and where should her messages go now. There is a worldwide system for asking those questions. It is a sort of postal sorting network shared between operators, and it was designed in an era when the only organizations that could reach it were a few dozen state telephone monopolies who knew each other.

It therefore trusts the label on the envelope. If a message arrives on that network claiming to come from a legitimate operator, and it says “subscriber 91xxxxxxxxxx has arrived on my network, send her messages here”, the home network by default believes it and starts sending them there.

An attacker who can get a desk in that sorting office, which today can be rented, does not need your phone, your shop, or your password. He asks the network where you are, and then he tells the network you have moved. Your text messages are delivered to him, correctly, by the world’s telephone infrastructure. In one documented case in Germany in 2017, criminals used exactly this to collect the one-time numbers that German banks were sending by text, and emptied accounts overnight while their owners slept.

A key that reads the sign above the door#

Now the fix, in plain terms, because the whole point of the chapter is that there is one.

Every attack above works because the thing you hand over is useful to whoever holds it. A six-digit code is a six-digit code. It does not know where it is being typed. A Yes button is a Yes button. It does not know what it is agreeing to. A text message is a delivery, and it goes wherever the network says.

So build a key that looks at the door before it turns.

Imagine a key that, before it will move in any lock, reads the sign above the door and checks it against the name engraved on the key. Take it to the real bank and it turns. Take it to a folding table on the pavement, or to a beautifully built replica of the bank across the road, and it will not move. It does not matter how convincing the replica is, how tired you are, or how official the man with the clipboard sounds, because the key is not persuaded by any of those things. It is checking a name against a name.

That is what a modern security key or passkey does. When you sign in, your device is told which website is asking. It holds a separate secret for each website and will only use the secret filed under that exact name. If the page is on a lookalike address, the device either has no secret for that name at all, or it produces something stamped with the lookalike’s name, and the real website refuses anything stamped with somebody else’s name.

The man with the clipboard can still take your password, and anything else you can read out loud or type. What he cannot do is make your key turn in his lock, and he cannot walk your key inside for you, because the key is not producing a number that travels. It is producing a signature over the name of the door it is standing in front of.

The whole thing on one page, with real values#

Let us follow one person all the way through, twice: once with codes, and once with a key. We will use the same attacker, the same morning and the same fake website both times.

Nikhil Bhatt manages accounts at a freight company. The company’s staff portal is at the address portal.northgate.example. To sign in he types a password and then six digits from an app on his phone.

On a Tuesday morning at 09:41 a message arrives on his phone. It says his portal access expires today and gives an address, ngate-portal.example. It is not the company’s address, but it is close, and he is between two meetings. He taps it.

What loads looks exactly like the portal, because it is the portal. The attacker’s machine is fetching the real pages from the real portal and passing them on, changing only the name in the address bar and a few internal references. Nikhil types his password. The attacker’s machine passes it straight to the real portal, which accepts it and asks for the six digits. That question is passed back to Nikhil, who reads 402913 off his phone and types it. It is a genuine code from a genuine app, valid at that second and for that account.

The attacker’s machine forwards 402913 to the real portal within the same second. The real portal is satisfied. It issues the small file that says “this browser is signed in”, and it sends it back. The attacker’s machine keeps a copy and passes a rewritten version on to Nikhil, who lands on his dashboard and notices nothing wrong, because he is looking at his real dashboard.

Twelve seconds later the attacker pastes the copied file into his own browser and is inside Nikhil’s account. Nikhil’s password was correct, his code was correct, and his second factor did not fail. It was carried.

Now run the same morning again, after the company has issued keys. Everything is identical up to the point where the portal asks for the second factor. This time the portal does not ask for six digits. It sends a challenge and asks Nikhil’s device to sign it for the name portal.northgate.example.

The attacker’s machine relays the challenge, but the page it is displayed on lives at ngate-portal.example. Nikhil’s browser will not ask his key to sign for a name that does not match the page it is on, so it refuses before the key is even touched. If the attacker instead asks for a signature under his own name, ngate-portal.example, Nikhil’s key looks for a secret filed under that name and finds none, because none was ever created. And if the attacker somehow obtains a signature anyway, it carries the name of the fake address inside it, and the real portal compares that name with its own and throws the signature away.

The names are not vague. Each is turned into a fixed 32-byte fingerprint that anybody can compute. For portal.northgate.example that fingerprint begins 427d4c9e, and for ngate-portal.example it begins f25480. They are different, they are different in every byte, and no amount of visual similarity in the address bar changes that. The attacker’s whole trade is making two things look alike to a human. The key is not looking with human eyes.

Nikhil still lost his password in the second run. That is worth saying plainly, because it is the honest shape of the result: the key did not stop him being fooled, it stopped his being fooled from mattering.

Where the plain version stops being true#

The man with the clipboard is a program, and he is not slow#

The picture of a helpful man walking in and out of a bank is useful for understanding what is happening and badly misleading about how it feels.

There is no walking. The attacker’s machine is a web server configured to fetch every page from the real site on demand and hand it back with a few substitutions. The delay it adds is the delay of one extra network hop, which for a machine sitting in a data centre is typically a small fraction of a second. Nothing is slow, nothing hesitates, and there is no pause in which a suspicious user might think again.

More importantly, the attacker is not standing there. The relay is automatic. He can be asleep. The machine collects passwords, codes and session files from hundreds of people at once and drops them into a chat channel or a database for him to read when he wakes up. In the 2022 campaign that Group-IB named 0ktapus, the harvested material was posted into a Telegram channel automatically as it arrived.

The honest version: the reason a live relay attack was rare before about 2017 and is ordinary now is not that anybody discovered a new weakness in one-time codes. The weakness was always there and was written about for years. What changed is that somebody packaged the plumbing, and then somebody else rented it out by the week.

“Phishing-resistant” describes a ceremony, not a device#

The plain version implies that a key is safe and a code is not, as if safety were a property of the object in your hand.

It is not. A hardware token that displays six digits for you to type is a physical object, costs money, cannot be copied, has a tamper-resistant chip inside, and is exactly as relayable as an app on a phone, because what leaves it is a number a human reads and retypes. A soft passkey stored in an ordinary phone’s operating system is not a special object at all, and it is unphishable, because what leaves it is a signature over the website’s name that nobody can retype.

The honest version: phishing resistance is a property of the exchange, not of the hardware. The test is a single question. Is there any value that a person can be talked into producing and transferring, which the attacker can then present to the real site? If yes, the method is phishable, no matter what it is made of. If the only thing produced is bound to the identity of the site that asked, and produced by a machine that checks that identity, the method is not phishable, no matter how cheap it is.

Number matching does not make push safe#

The plain version presents number matching as the repair for the doorbell attack. It is a real repair for one shape of that attack, and the shape it does not repair is the one used in the most serious intrusions.

Number matching defeats the attacker who is silent. He triggers the prompt, you look at your phone, and there is a number to type that you cannot see because you are not the one signing in. There is nothing to guess, so the sheer volume of prompts stops being a weapon.

It does not defeat the attacker who talks to you. He is the one signing in. He is looking at the number. If he can get you on the telephone, or into a chat, or onto a fake support page, he reads you the number and asks you to type it. This is precisely how the 2022 intrusion at Cisco began: not a purely automated flood, but a flood accompanied by voice calls from people claiming to be trusted support staff.

The honest version: number matching upgrades push approval from “defeated by patience” to “defeated by a telephone call”. That is a genuine and worthwhile upgrade and it is not the same as phishing resistance. CISA’s own October 2022 guidance places number matching in the second tier of its hierarchy, explicitly as what to do if you cannot yet do the first tier.

A SIM swap is not always a bribe, and it is not always expensive#

The plain version pictures a criminal sweet-talking a shop assistant. That happens. It is also the most expensive and riskiest version, and there are cheaper ones.

A number can be moved without a shop at all, by requesting a port to a different operator, which is a process regulators require to be quick and easy because slow porting is anti-competitive. It can be moved by an insider who has been recruited or extorted, which removes the acting entirely. On some accounts it does not need to be moved at all, because a voicemail box will read out a spoken code, and voicemail systems have historically been reachable from outside with a four-digit personal identification number or, on some networks, with no authentication when the caller identifier appears to be the subscriber’s own.

The honest version: the interesting question is not whether a SIM swap is hard, but what it costs relative to what it opens. Measured that way it is one of the best value attacks in existence, and the numbers later in this chapter show why.

The old signalling network has not gone away#

It is tempting to file signalling interception under history: an old protocol, superseded by newer generations of mobile network.

The newer generations do use newer protocols. Fourth-generation networks use Diameter rather than the older SS7, and fifth-generation core networks use ordinary web protocols with a dedicated security proxy between operators. None of that retires the old network, for three reasons. Roaming agreements have to reach every operator a subscriber might visit, including those that have not upgraded. Second and third-generation networks are still in service in much of the world and are the fallback when newer coverage is absent. And an attack does not need your network to be old, it needs some network with a path to your network to be permissive.

The honest version: Diameter inherited the architectural problem rather than fixing it. It has cryptographic transport available between operators, but the trust model between operators is still largely “you are in the club, so your messages are true”, and the same categories of message that leak location and divert delivery exist there under different names. The defence in both cases is a filtering firewall at the network edge, deployed unevenly, whose configuration is not public.

The second factor is not the last checkpoint#

The plain version stops when you get in. Everything that matters afterwards is missing from it.

Sites do not re-authenticate you on every page. Once you are in, the site issues a bearer token, most often a cookie, which is a value that works for whoever presents it. It is the stamp on the hand. In an adversary-in-the-middle attack the token is the actual prize, because it survives the password change, it survives the code app being reset, and on some services it survives the account owner clicking “sign out of all devices” less reliably than they expect.

The honest version: origin binding protects the act of signing in. It does not, by itself, protect the session that results. A site can have perfect phishing-resistant login and still hand out a long-lived cookie that an attacker who obtains it by any means can replay from another continent. Binding the session to the device, so that the token is useless without the key that obtained it, is a separate piece of engineering that most services have not done, and we will price it exactly in the technical half.

Some of these attacks do not touch your second factor at all#

Finally, the plain version assumes the attacker attacks the front door.

He often does not. If a site offers to send you a recovery link when you cannot sign in, then the recovery path is a second front door, and it is frequently protected by things weaker than the login itself. If a support desk can restore access to a caller who sounds convincing, the support desk is a third. If your account can be recovered using a telephone number, then a SIM swap defeats your account regardless of how good your key is, because it does not have to beat the key, it only has to reach the path that bypasses the key.

The honest version: this is the single most common way that strong authentication is defeated in practice, and it is not really an authentication failure at all. The chapter “Recovery” deals with it properly. It is mentioned here so that no reader finishes this chapter believing that a security key alone is a complete answer.

The technical version#

Naming the attacker you actually have#

Security arguments go wrong when the threat model is left implicit. Before ranking anything, we need a list of attackers, because “two-factor authentication is good” is only true relative to one of them.

Six are worth separating. The credential stuffer replays username and password pairs from breach corpora at scale, with no interaction with the victim. The bulk phisher harvests credentials to a static page and uses them later. The real-time relay, the subject of most of this chapter, proxies the victim’s session live and forwards every challenge. The channel attacker takes control of the delivery path, by moving the telephone number or by injecting messages into the operator signalling network. The prompt abuser never touches the victim’s traffic and simply triggers approvals until one is granted. The endpoint attacker owns the victim’s device, at which point authenticating the human is a secondary question.

The distinction matters because a single method scores very differently against each.

Google’s published measurements of May 2019, quoted in the chapter “The One-Time Code”, map onto this table almost exactly: text-message codes blocked nearly all automated and bulk attacks and a much smaller share of targeted ones. The high figures are the credential stuffer and the bulk phisher. The gap is everybody else in the list, and the rest of this chapter is about them.

The reverse proxy, in exact terms#

An adversary-in-the-middle phishing site is not a copy of the target site. Making convincing copies is laborious and they break whenever the target changes. It is a reverse proxy: a web server that terminates the victim’s connection, opens its own connection to the genuine site, and relays traffic in both directions while rewriting the small number of fields that would otherwise give it away.

The machinery is ordinary. The attacker registers a lookalike domain, obtains a publicly trusted certificate for it, which since Let’s Encrypt began issuing free automated certificates in 2015 costs nothing and takes under a minute, and points the proxy at the target.

What the proxy must rewrite falls into four groups.

 Victim browser                Proxy                 Real site
 --------------                -----                 ---------
 GET / HTTP/2
 Host: ngate-portal.example
        |
        |  rewrite Host, Origin, Referer
        v
                        GET / HTTP/2
                        Host: portal.northgate.example
                        Origin: https://portal.northgate.example
                                        |
                                        v
                        HTTP/2 200
                        Set-Cookie: ngsess=...;
                          Domain=portal.northgate.example
                                        |
        rewrite Set-Cookie Domain, links, form actions
        keep a copy of every credential and cookie
        |
        v
 HTTP/2 200
 Set-Cookie: ngsess=...;
   Domain=ngate-portal.example

The four groups are these. First, request headers that name the site: Host, Origin and Referer must be changed from the phishing name to the real name, or the real site will reject the request under its cross-origin rules. Second, response headers that scope state: Set-Cookie carries a Domain attribute, and a cookie scoped to the real domain will not be stored by a browser that thinks it is on the phishing domain, so the attribute is rewritten. Third, the body: absolute links, form action attributes and any JavaScript that hard-codes the site’s own name are substituted so the victim’s browser keeps talking to the proxy. Fourth, security headers that would break the illusion, such as Content-Security-Policy directives restricting where scripts and forms may point, are stripped or relaxed.

None of that is a cryptographic attack. The transport is properly encrypted on both legs, and the certificate on the victim’s leg is genuine and valid for the phishing domain. The padlock in the address bar is telling the truth: the connection is secure, to the attacker.

What the proxy collects, in order of value, is the reverse of what most users assume. The password is least valuable, because the victim can change it. The one-time code is more valuable but perishable. The session cookie is the prize, because it is a bearer credential representing an already-completed authentication, and it typically remains valid until it expires or the site invalidates it explicitly.

MITRE’s ATT&CK catalogue tracks the technique as T1557, Adversary-in-the-Middle, with the cookie theft as T1539, Steal Web Session Cookie, and the push-prompt variant separately as T1621, Multi-Factor Authentication Request Generation.

The toolkits, and the year the attack became a product#

The technique is old. What changed is packaging, and it is possible to date the change precisely.

Evilginx was written by Kuba Gretzky. The first version, released in 2017, was a script for a customized build of the nginx web server. Version 2, released on 26 July 2018, replaced that with a standalone server written in Go and introduced the phishlet: a small configuration file that tells the proxy which hostnames to proxy, which substitutions to make in the page body, and, critically, which cookies constitute a captured session so the tool knows when it has won and can stop. Version 3.0, released on 10 May 2023, added automatic certificate renewal, capture of authentication tokens from response bodies and headers as well as cookies, and support for displaying the phishing page inside an iframe. MITRE lists the tool as software S9003. Modlishka, released publicly in 2019 by Piotr Duszynski, made a different contribution: it proxied multiple destination domains through a single attacker domain, removing much of the per-target configuration work.

The economically important step came later. By 2023 the capability was being sold as a subscription. Sekoia’s researchers first observed the kit they named Tycoon 2FA in August 2023 and reported identifying over 1,200 domain names associated with it between late October 2023 and late February 2024. The kit was sold as ready-to-use Microsoft 365 and Gmail phishing pages starting at 120 United States dollars for ten days. On 4 March 2026 a coordinated operation involving Europol, Microsoft, Trend Micro, Cloudflare, Proofpoint and others seized over 300 domains tied to Tycoon 2FA. In reporting the takedown Trend Micro stated the platform had used over 24,000 domains since it appeared in 2023 and had approximately 2,000 subscribers at the time of the seizure.

That last figure deserves a moment. Two thousand people were paying a subscription for a service whose only function is to defeat two-factor authentication in real time. This is not a research demonstration. It is a market with customers.

The 2022 evidence, with names and numbers#

Three publicly documented episodes from 2022 are worth setting out precisely, because between them they establish that the relay attack and the prompt attack both work against organizations with competent security teams.

On 12 July 2022 Microsoft published an analysis of a large adversary-in-the-middle campaign, reporting that it had “attempted to target more than 10,000 organizations since September 2021” and describing victims landing on Evilginx2 phishing sites. Microsoft’s framing is the clearest statement of the point this chapter is making: “Note that this is not a vulnerability in MFA; since AiTM phishing steals the session cookie, the attacker gets authenticated to a session on the user’s behalf, regardless of the sign-in method the latter uses.”

On 20 July 2022 Cloudflare was targeted. Its published account states that over the course of less than one minute at least 76 employees received text messages on personal and work phones. The phishing site relayed credentials to the attacker through Telegram; the attacker typed them into the genuine login page in real time to trigger a one-time code, which the victim was then prompted to enter on the phishing page and which the attacker relayed onward. Three employees entered credentials. No account was compromised, because Cloudflare required hardware security keys and the attackers could not produce anything the real login would accept. Cloudflare’s explanation names the mechanism: the keys are tied to users and implement origin binding.

Twilio was targeted in the same campaign without that protection. It disclosed the incident beginning on 4 August 2022 and concluded its investigation on 27 October 2022, reporting that the accounts of 209 customers, out of a customer base of over 270,000, and 93 Authy end users had been affected. Among the remedial measures it listed was distributing FIDO2 tokens to all employees.

Group-IB tied these together on 25 August 2022 under the name 0ktapus, publishing figures worth stating exactly because they show the scale a single automated relay reaches. The researchers detected 169 unique phishing domains, and reported that the threat actor stole 9,931 user credentials, including 3,129 records with e-mail addresses and 5,441 records containing multi-factor authentication codes. Of the victim organizations Group-IB could identify, 136 were named, of which 114 were in the United States.

The two contrasting outcomes in the same campaign, on the same days, against companies of comparable sophistication, are as close to a controlled experiment as this field produces. The variable was whether the second factor could be relayed.

Push fatigue: the attack that needs no fake site at all#

Push approval works like this. The user registers an application on a phone. When a sign-in occurs, the identity provider sends a notification to that application. The user taps approve or deny, the application signs the response with a key held on the device, and the sign-in completes. As an engineering design it is sound, and the signature itself cannot be read out over a telephone.

The weakness is not in the cryptography. It is that the human is asked a question with a default-shaped answer, out of context, at a moment chosen by the attacker.

The attacker needs the password and nothing else. He submits it, which causes a prompt on the victim’s phone. He submits it again. And again. Microsoft described the technique on 22 March 2022 in its analysis of the group it then tracked as DEV-0537, publicly known as LAPSUS$ and since renamed Strawberry Tempest. The description is worth quoting for how mundane it is: the group used “stolen passwords to trigger simple-approval MFA prompts hoping that the legitimate user of the compromised account eventually consents to the prompts and grants the necessary approval.” The same analysis records that the group also “performed a SIM-swapping attack to access a user’s phone number before signing into the corporate network”, and that a second technique against MFA was session token replay, which is the same session cookie theft arriving by a different route.

CISA’s fact sheet of October 2022 gives the plain definition: “MFA fatigue, also known as ‘push bombing,’ occurs when a cyber threat actor bombards a user with mobile application push notifications until the user either approves the request by accident or out of annoyance with the nonstop notifications.”

Cisco was compromised on 24 May 2022 and published its analysis on 10 August 2022. The initial credential came from a personal account whose browser was synchronizing saved passwords. The MFA step was defeated by combining volume with voice. Cisco’s write-up describes “MFA fatigue, the process of sending a high volume of push requests to the target’s mobile device until the user accepts, either accidentally or simply to attempt to silence the repeated push notifications they are receiving”, alongside “a series of sophisticated voice phishing attacks under the guise of various trusted organizations attempting to convince the victim to accept multi-factor authentication (MFA) push notifications initiated by the attacker.” The attacker eventually obtained an approval and reached the corporate VPN as that user.

Uber published a security update on 19 September 2022 describing an intrusion of the preceding days. Its account is that an external contractor’s corporate password was obtained from a dark web listing after the contractor’s personal device was infected with malware, and that “the contractor received a two-factor login approval request, which initially blocked access. Eventually, however, the contractor accepted one.” Uber attributed the activity to Lapsus$.

CISA, the FBI and partners published an advisory on the group tracked as Scattered Spider on 16 November 2023, revised on 21 November 2023. It records the same techniques operating together: actors “posed as company IT and/or helpdesk staff using phone calls or SMS messages to obtain credentials”, and sent “repeated MFA notification prompts leading to employees pressing the ‘Accept’ button (also known as MFA fatigue)”, mapped to ATT&CK technique T1621. It also records that the group “convinced cellular carriers to transfer control of a targeted user’s phone number to a SIM card they controlled, gaining control over the phone and access to MFA prompts.”

The common shape is that the second factor was not broken. It was answered, by the correct person, on the correct device, at a moment the attacker chose.

Number matching and context, and the exact limit of both#

The mitigations that followed are worth describing precisely, because their limits are precise.

Number matching changes the question from a binary to a transcription. The identity provider displays a short numeric code on the screen where the sign-in is taking place, and the authenticator application asks the user to type that code rather than tapping approve. Microsoft’s documentation states the mechanic plainly: “When users respond to an MFA push notification by using Authenticator, they see a number. They need to enter that number into the app to complete the approval.” Microsoft removed the administrative controls and enforced the behaviour for all users of Authenticator push notifications from 8 May 2023, which is a useful date because it marks the point at which the largest deployment of simple push in the world stopped being simple push.

Context display adds the requesting application’s name, the geographic location derived from the requesting network address, and sometimes the browser and operating system, to the approval screen. It is a weaker control than number matching because it asks the user to notice an anomaly rather than to possess a value, and geographic location derived from network address is wrong often enough that users learn to disregard it.

Both were promoted by CISA on 31 October 2022, when it released two fact sheets, “Implementing Phishing-Resistant MFA” and “Implementing Number Matching in MFA Applications”. The framing of the second is explicit: number matching is what to do if you cannot yet implement the first. The hierarchy given in the phishing-resistant fact sheet, from strongest to weakest, is worth reproducing because it is one of the few official rankings that exists.

Now the limits, stated exactly.

Number matching defeats an attacker who cannot communicate with the victim during the attack. That is the entire population of automated prompt abusers, and it is a large population. It does not defeat an attacker who can. The attacker triggering the sign-in sees the number on his own screen; the only thing he needs is a channel to the victim over which to say it. The Cisco intrusion already used that channel before number matching existed, and there is no reason the same voice call cannot end with “the system will show you a two-digit number, please enter 47”.

Context display has the same limit and a second one: it fails silently. A user who approves without reading has not violated any control, and the system cannot tell the difference between reading and not reading.

There is a further mitigation which is genuinely underused: limiting the rate and total number of prompts, and treating a burst of denied prompts as a security event in its own right. CISA’s number matching fact sheet makes exactly this recommendation, advising that denied push notifications be investigated as they may indicate compromised credentials. A denied prompt that the user did not initiate is proof that somebody else holds the password. Very few deployments treat it that way.

The honest summary is that number matching and context display move push approval up one rung of the CISA ladder and no further. They convert an attack that any script can run into an attack that requires a person to talk to the victim. That is worth doing on the morning you cannot deploy keys. It is not a destination.

SIM swap: the procedure, the price, and the paperwork#

A SIM swap is the fraudulent reassignment of a telephone number from the subscriber’s subscriber identity module to one controlled by an attacker. The FBI’s definition, from its public service announcement of 8 February 2022, is that it “fraudulently induces a mobile carrier to reassign a mobile phone number from a victim’s SIM card to a SIM card and telephone controlled by a criminal actor”.

The procedure has five steps, and only one of them involves the telephone company.

1. Target selection. The attacker identifies an account worth taking and the telephone number attached to it. For cryptocurrency thefts this is often done from public boasting; for corporate intrusions it is done from staff directories and professional networking sites.
2. Personal data assembly. Enough of the subscriber’s identifying detail to pass the carrier’s checks: name, address, date of birth, the last four digits of a payment card, the account personal identification number if one exists. Almost all of this is available from breach corpora or data brokers.
3. Carrier account takeover. Executed in one of four ways: an in-store visit with a forged or altered identity document; a call to the support line; an online port-out request to a different operator; or the recruitment or bribery of an employee who can perform the change directly.
4. Confirmation. The victim’s handset loses service. The attacker’s handset receives it. There is typically a window of hours before anyone notices, and the window is longer at night.
5. Exploitation. Password resets, one-time codes and account recovery flows are driven from the number.

The most instructive documented case is recent and fully adjudicated, which makes every figure in it checkable rather than estimated.

On 9 January 2024 the official social media account of the United States Securities and Exchange Commission published a false statement that a category of bitcoin investment product had been approved, and the price of bitcoin moved sharply before the post was retracted. According to Department of Justice filings, Eric Council Jr., of Athens, Alabama, and others executed a SIM swap of the mobile telephone account associated with that account on or about that date, with Council providing false information to a store employee to explain why he needed a replacement SIM card. He admitted to receiving about 50,000 United States dollars for performing SIM swaps. He was arrested on 17 October 2024, pleaded guilty on 10 February 2025 to conspiracy to commit aggravated identity theft, and was sentenced on 16 May 2025 to 14 months in prison.

There is an honest qualification to that case which cuts against a lazy reading. The Securities and Exchange Commission’s own statement records that multi-factor authentication had previously been enabled on the account but “was disabled by X Support, at the staff’s request, in July 2023 due to issues accessing the account”, and that “once access was reestablished, MFA remained disabled until staff reenabled it after the account was compromised on January 9.” The second factor did not fail; there was not one at the moment it mattered. What the SIM swap defeated was the recovery path, which the chapter “Recovery” treats fully. This case belongs here because the operational detail and the price paid to the operative are both on the public record, and such numbers are otherwise very hard to obtain.

The scale figures come from the FBI’s Internet Crime Complaint Center. Its announcement of 8 February 2022 reports that from January 2018 to December 2020 the centre received 320 complaints related to SIM swapping with adjusted losses of approximately 12 million United States dollars, and that “in 2021, IC3 received 1,611 SIM swapping complaints with adjusted losses of more than $68 million.”

That is a fivefold rise in complaints and a roughly seventeenfold rise in losses across a comparable interval, and the per-complaint average moves from about 37,500 to about 42,000 United States dollars. These are complaints to one American body, so they are a floor rather than a measurement.

The difficulty of the carrier step has been measured. Lee, Kaiser, Mayer and Narayanan of Princeton University published “An Empirical Study of Wireless Carrier Authentication for SIM Swaps” at the Sixteenth Symposium on Usable Privacy and Security in August 2020. They attempted SIM swaps against five prepaid carriers in the United States, ten attempts each, and 39 of the 50 attempts succeeded, which they summarize as four out of five succeeding. They also examined over 140 websites and identified 17 on which an account could be compromised on the basis of a SIM swap alone.

Regulation has followed slowly. In the United States the Federal Communications Commission adopted Report and Order FCC 23-95 on 15 November 2023 in WC Docket No. 21-341, “Protecting Consumers from SIM Swap and Port-Out Fraud”, amending the customer proprietary network information rules at 47 CFR 64.2010 and the local number portability rules at 47 CFR 52.37. It requires wireless providers to use secure customer authentication before effecting a SIM change, to notify customers immediately of SIM change and port-out requests, and to retain records. It was published in the Federal Register on 8 December 2023 and took effect on 8 January 2024, except for provisions containing information collection requirements. For those, the Commission announced a compliance date of 8 July 2024 “or after the Commission receives approval from the Office of Management and Budget under the Paperwork Reduction Act process, whichever is later”, and that approval was issued on 15 January 2025. [UNVERIFIED: the date of the Federal Register notice of OMB approval that fixes the final compliance date for the delayed provisions of FCC 23-95]

The economics are the part worth internalizing. A SIM swap costs a forged document, a shop visit or a bribe, and some hours of preparation, and it yields, for as long as it lasts, every code sent to that number and every recovery link. That case puts a market rate on the labour: about 50,000 United States dollars for a job whose target was chosen for its publicity value, and far less for an ordinary bank account. This is why a text message is the weakest second factor in every published ranking, and why NIST classifies out-of-band authentication over the public telephone network as restricted, in section 3.1.3.3 of SP 800-63B revision 4 of 31 July 2025, meaning permitted only where the risk is documented and accepted rather than recommended.

SS7 and Diameter: diverting a message without touching the phone#

The second attack on the delivery channel does not involve the subscriber, the shop or any document. It involves the network that operators use to talk to one another.

Signalling System No. 7 is the family of protocols that carries the control messages of the fixed and mobile telephone networks, as distinct from the calls and messages themselves. The application layer used for mobility is the Mobile Application Part. It dates from an era in which the set of organizations able to send messages on that network was small, known and state-controlled, and it accordingly contains no authentication of the sender and no integrity protection of the contents. The GSMA’s own published description of the problem is direct: the protocol “contains no protection of the integrity of the data, so it can be modified by any party and there is no way of validating whether messages are authentic.”

Three Mobile Application Part operations do most of the damage, and it is worth naming them because vague talk of “SS7 flaws” hides how specific the attack is.

Attack path for intercepting one text message
---------------------------------------------

1. SendRoutingInfoForSM  ->  victim's HLR
   asks: where do I deliver an SMS for +91...?
   returns: IMSI, and address of serving MSC/VLR

2. UpdateLocation        ->  victim's HLR
   claims: subscriber is now on MY network
   effect: HLR re-points delivery to attacker

3. MT-ForwardSM          ->  attacker's fake VLR
   the bank's one-time code is delivered here

4. UpdateLocation        ->  victim's HLR
   optional: restore, so the victim's phone
   regains service and nobody investigates

Step one, SendRoutingInfoForSM, is the message a short message service centre legitimately sends to a home location register to ask where a subscriber currently is so a text can be delivered. Answered from an untrusted source, it discloses the international mobile subscriber identity and the address of the switch currently serving the subscriber, which are the two facts an attacker needs before doing anything else. Step two, UpdateLocation, is the message a visited network legitimately sends when a roaming subscriber arrives on it. Accepted from an untrusted source, it makes the home network believe the subscriber has arrived on the attacker’s node, so subsequent deliveries go there. Two further operations, AnyTimeInterrogation and ProvideSubscriberInfo, return the subscriber’s location and underlie the commercial tracking services that have periodically been exposed, and SendAuthenticationInfo retrieves authentication vectors from the home network.

Fourth-generation networks replaced this with Diameter, and the equivalents map almost one to one. On the S6a interface between a mobility management entity and a home subscriber server, defined in 3GPP TS 29.272, Update-Location-Request performs the role of UpdateLocation, Authentication-Information-Request retrieves authentication vectors, Insert-Subscriber-Data pushes subscriber profile data, and Cancel-Location-Request detaches a subscriber. Diameter can run over transport security between operators, but the trust model at the interconnect is the same: a message from a peer inside the roaming ecosystem is by default believed. Fifth-generation standalone cores move to a service-based architecture over HTTP/2 with a Security Edge Protection Proxy between operators, specified in 3GPP TS 33.501, which is a genuine improvement; it does not remove the older networks, which remain in service for roaming and fallback.

The GSMA’s countermeasure documents are the reference. FS.11, “SS7 Interconnect Security Monitoring and Firewall Guidelines”, groups SS7 and Mobile Application Part messages into categories according to where they may legitimately originate: broadly, messages that should never arrive over an interconnect from outside the operator’s own network absent a bilateral agreement; messages about a visiting subscriber that should only come from that subscriber’s home network; and messages about a visiting subscriber that should only come from the network the subscriber is genuinely visiting, which requires the firewall to hold a view of where each subscriber plausibly is. FS.19, “Diameter Interconnect Security”, does the same for Diameter, and FS.21, “Interconnect Signalling Security Recommendations”, sits above both. All three are available to GSMA members only, which is a real limitation for anybody assessing their own exposure. [UNVERIFIED: the exact per-message category assignments in GSMA FS.11, which is a members-only document]

A subscriber’s exposure is not determined by their own operator alone. It is determined by the weakest path into their home network, which makes the question of who can send messages into the interconnect decisive, and the answer is more commercial than technical: Global Title leasing. A Global Title is an address on the signalling network, which the GSMA describes as looking “like a phone number and is used to identify and communicate with certain nodes within a telecommunications network, much like the use of IP addresses within an IT network”. Some operators monetized their signalling connectivity by leasing Global Titles to third parties, which is how an organization that is not a telephone company acquires the ability to send messages that the world’s home location registers will process. The GSMA developed a Global Title Leasing Code of Conduct with a compliance deadline of 31 December 2023, which strongly advises against the practice.

Industry self-regulation was judged insufficient. On 22 April 2025 the United Kingdom regulator Ofcom banned the leasing of Global Titles associated with United Kingdom networks. The ban on entering new leasing arrangements took effect immediately; for leasing already in place it came into force on 22 April 2026, which as of August 2026 has now passed. Ofcom described the action as closing a technical loophole posing a risk to mobile users’ privacy and security.

In the United States the Federal Communications Commission issued a public notice, DA 24-308, in March 2024 seeking comment on SS7 and Diameter security, observing that “over the last several years, numerous reports have called attention to security vulnerabilities present within SS7 networks and suggest that attackers target SS7 to obtain subscribers’ location information”, and describing Diameter as similarly vital and vulnerable.

The historical record establishes that this is exploitation and not theory.

The German case is the one to remember, because it is the exact attack this chapter is about, carried out for money. Attacks were carried out in January 2017 from the network of a foreign mobile operator, and reported by Sueddeutsche Zeitung on 3 May 2017 and confirmed by O2-Telefonica. The criminals first infected victims’ computers with malware to collect account balances, login details and mobile numbers, then obtained access through a rogue telecommunications provider and redirected the victims’ numbers. They logged into the accounts in the middle of the night, and when the banks sent mobile transaction authentication numbers by text, those numbers were delivered to the criminals, who completed the transfers. Every control worked. The code was correct, single-use and fresh. It was simply delivered to the wrong handset by the world’s telephone system.

The United Kingdom case followed. Motherboard reported in early 2019, with coverage on 4 February 2019, that Metro Bank had been targeted by SS7 attacks intercepting text messages used as second factors, making it the first British bank publicly named in such an attack; the National Cyber Security Centre confirmed awareness of criminals intercepting such messages.

Phishable and unphishable: the property, stated exactly#

Everything above can now be collapsed into one test.

An authenticator is phishable if there exists any value which the legitimate user can be induced to produce, and which an attacker who obtains that value can present to the genuine verifier to complete authentication. An authenticator is phishing-resistant if no such value exists, because everything the authenticator produces is cryptographically bound to the identity of the party that requested it, and that binding is checked by a machine rather than by a person.

Apply the test and the field sorts itself without argument. A password is a value the user can produce and hand over. A one-time code from a text message, an e-mail, a voice call, an application or a hardware display is a value. A recovery code is a value. A knowledge-based answer is a value. All of them fail. A push approval fails a slightly different way: the user does not produce a transferable value, but produces a decision about a request they cannot inspect, which is the same defect with a different surface.

A FIDO2 or WebAuthn assertion passes. So does a client certificate presented in a TLS handshake, which is what personal identity verification smart cards do, because the handshake is with a specific server and the resulting proof does not transfer. That is exactly the pair CISA names as phishing-resistant in its October 2022 fact sheet: FIDO/WebAuthn authentication, and public key infrastructure based authentication.

NIST states the same property normatively. SP 800-63B revision 4, of 31 July 2025, defines it in section 3.2.5: “Phishing-resistant authentication prevents the submission of authentication secrets or activation factors to an impostor RP”, where RP is the relying party, meaning the site you are signing in to. The requirement is graduated: verifiers “SHALL offer at least one phishing-resistant authentication option at AAL2”, the middle assurance level, per section 2.2.2, while at the highest level, section 2.3.2, the cryptographic authenticator “SHALL provide phishing resistance”. The older term for the same idea was verifier impersonation resistance, still encountered in procurement documents.

The word to be suspicious of is “strong”. Strength, in the sense of key length, tamper resistance or how many factors are involved, is orthogonal to this property. A three-factor authenticator made of titanium that ends by displaying a number for you to type is phishable. A synced passkey in a consumer phone’s operating system is not.

Channel binding and origin binding: how the binding is made#

There are two families of solution and it is worth keeping them apart, because one of them mostly failed in the market and the other mostly succeeded.

Channel binding ties the authentication proof to the specific encrypted transport connection it travelled over. The general framework is RFC 5056. RFC 5929 of July 2010 defined the binding tls-unique for TLS up to version 1.2, deriving a value from the handshake so that a proof computed over it cannot be replayed on a different connection. That binding was found to interact badly with the triple handshake attack in the absence of the extended master secret extension, and RFC 9266 of July 2022 defines its replacement, tls-exporter, built on TLS exported keying material and made the default channel binding for TLS versions above 1.2. Token Binding, RFC 8471 of October 2018 with its companions RFC 8472 and RFC 8473, extended the idea to long-lived tokens: a client proves possession of a private key across multiple TLS connections, so a cookie could be bound to that key and rendered useless to anyone who stole the cookie alone. It is an elegant answer to the session theft problem described earlier. It did not achieve broad browser deployment and was withdrawn from the major browsers, which is why cookie theft remains the dominant post-authentication attack. [UNVERIFIED: the exact browser versions in which Token Binding support was added and removed]

Origin binding ties the proof to the name of the site rather than to the connection, and this is the one that won, because browsers already enforce a strict machine-checked notion of origin that a phishing site cannot fake without controlling the domain name.

In WebAuthn, whose Level 3 specification was a W3C Candidate Recommendation Snapshot dated 26 May 2026 as of August 2026, the binding is carried in two places. The first is the client data, assembled by the browser and passed through the authenticator so it cannot be edited by the page. It is a JSON object, hashed and signed as part of the assertion.

{
  "type": "webauthn.get",
  "challenge": "oW6Yv1nQ8sZ3kR2tLpA9cQ",
  "origin": "https://portal.northgate.example",
  "crossOrigin": false
}

The origin member is written by the browser from the actual origin of the calling page. A page served from ngate-portal.example cannot cause the string to say anything else. That single field is the whole defence against the reverse proxy, and it is why this chapter’s plain analogy was a key that reads the sign above the door.

The second place is the authenticator data, produced inside the authenticator itself.

authenticatorData, WebAuthn section 6.1
offset  len  field
0       32   rpIdHash: SHA-256 of the RP ID
32       1   flags: UP, UV, BE, BS, AT, ED
33       4   signCount, big endian
37      ..   attested credential data, extensions

The relying party identifier is normally the site’s registrable domain. Its SHA-256 hash is what the authenticator stores each credential against and what it stamps into every assertion. For our worked example the two values are as follows, and either can be recomputed by anyone with a hashing tool.

RP ID  portal.northgate.example
       427d4c9e09162547ab0e8dd3932864c7
       a87cf228e41433dad07453ae1cc40c00

RP ID  ngate-portal.example
       f25480138efe5aa935392192d0170004
       efcacc874652aa86105d1276704ca10b

Three separate checks have to fail for the attack to succeed, and they fail in sequence.

1 browser: is rpId a registrable suffix of the
  calling origin? ngate-portal.example is not a
  suffix of portal.northgate.example -> refuse
2 authenticator: do I hold a credential whose
  rpIdHash is f25480...? -> no credential -> stop
3 relying party, WebAuthn section 7.2: does
  C.origin equal my expected origin? -> no -> fail

Check one is enforced by the browser before the authenticator is contacted at all. Check two is enforced inside the authenticator, which is why a hardware key cannot be tricked even if the browser is replaced by a hostile client. Check three is enforced on the server, and it is the one relying parties get wrong: an implementation that accepts any origin, or that compares only the domain suffix, throws away the entire protection. The verification steps in section 7.2 of the WebAuthn specification are not optional, and the origin comparison is the one that matters most here.

The honest limits of origin binding are three, and they should be stated as plainly as the benefit. It protects the sign-in and not the session, so the cookie issued afterwards remains a bearer token unless separately bound. It protects only the paths that use it, so a site offering a one-time code as a fallback has kept the phishable path open and an attacker will simply steer the victim to it. And it does nothing against an attacker on the device itself, who does not need to phish anything.

The ranking, against each named attack#

The following two tables answer the question this chapter began with: which second factor stops which attacker. Entries read: no means the attack succeeds, yes means it does not, partly means it raises cost without removing the attack.

Two entries need explanation. Push is marked partly against real-time relay because a relay can trigger the prompt but cannot answer it; the attack becomes social rather than technical, which is a real reduction and not an elimination. Push is marked partly against SIM swap because the notification is delivered to a device rather than a number, so moving the number does not move the prompt, unless the account can be re-enrolled using the number, which on many services it can.

The one entry that no table captures is the recovery path. Every yes in the right-hand columns is conditional on the account not offering a telephone number as a way back in. If it does, the ranking of the login method is irrelevant, because the attacker will not attack the login.

Migrating, in the order that actually works#

The order matters more than the choice, because most failed migrations fail the same way: the strong method is added, the weak one is left in place as a fallback, and the attacker uses the fallback.

The sequence that works is: enrol at least two phishing-resistant credentials per user, so losing one is not an emergency; remove the phishable methods from the account entirely rather than demoting them; remove the telephone number from every recovery and step-up path; bind or shorten sessions, so a stolen cookie is worth less; instrument denied push prompts and impossible-travel sign-ins as security events; and only then measure.

The measurement that exists is unusually clean. Google required physical security keys for its staff from early 2017, and told KrebsOnSecurity in July 2018 that none of its more than 85,000 employees had been successfully phished on work accounts since, with a spokesperson saying: “We have had no reported or confirmed account takeovers since implementing security keys at Google.” Cloudflare’s July 2022 experience is the same result observed under attack rather than in aggregate. Neither is a controlled trial and neither claims that keys prevent every intrusion; both are consistent with the property argument rather than with a marketing claim.

The wider context, as of 2026, is that the attack has not receded. ENISA’s Threat Landscape 2025, published on 1 October 2025 and covering 1 July 2024 to 30 June 2025, analysed 4,875 incidents and reports that “phishing (60%), followed by vulnerability exploitation (21.3%) are the two leading intrusion access points”, naming adversary-in-the-middle kits that mimic sign-in portals and bypass multi-factor authentication. The Tycoon 2FA takedown of 4 March 2026 removed one platform of roughly two thousand subscribers. It did not remove the technique, which is public, documented and reproducible from an open-source repository.

18.98 Common wrong ideas#

Wrong: Turning on two-factor authentication protects you from phishing. Right: It protects you from an attacker replaying a stolen password later, which is a different attacker; a reverse proxy that relays your code within its window satisfies every check the site makes, and Microsoft’s own 12 July 2022 analysis of a campaign against more than 10,000 organizations states that the stolen session cookie works regardless of which sign-in method the victim used.

Wrong: A hardware token is phishing-resistant because it is hardware. Right: Phishing resistance is a property of the exchange, not the object; a token that displays six digits for a human to retype is exactly as relayable as an application, while a passkey stored in an ordinary phone’s operating system is unphishable because what leaves it is a signature over the requesting site’s name.

Wrong: Number matching fixes push fatigue. Right: It defeats an attacker who cannot speak to you, which is most automated abuse, but the attacker triggering the sign-in can see the number on his own screen, so a voice call of the kind Cisco documented on 10 August 2022 can simply tell you which digits to type; CISA places number matching in the second tier of its October 2022 hierarchy, explicitly as what to do until phishing-resistant methods are possible.

Wrong: SMS codes are weak because text messages are unencrypted. Right: The transport encryption is largely irrelevant; the two attacks that matter are reassignment of the number itself, which succeeded in 39 of 50 controlled attempts in the Princeton study published at SOUPS in August 2020, and diversion on the operator signalling network, which was used against German bank customers in January 2017 to collect one-time transaction numbers.

Wrong: SS7 attacks are historical, because modern networks use LTE and 5G. Right: Diameter carries the same functions with the same interconnect trust model, with Update-Location-Request and Authentication-Information-Request on the S6a interface of 3GPP TS 29.272 playing the roles UpdateLocation and SendAuthenticationInfo play in the older network, and older networks remain in service for roaming and fallback everywhere.

Wrong: If the padlock is showing, the site is genuine. Right: The padlock means the connection to whoever answered is encrypted, and a phishing proxy obtains a valid publicly trusted certificate for its own lookalike domain in under a minute at no cost; the browser is reporting the truth about the connection and saying nothing about who is at the other end.

Wrong: Once you have a security key, the account is safe. Right: Origin binding protects the act of signing in and not the session that follows, so a bearer cookie obtained by any means still works; and if the account still offers a one-time code as a fallback, or accepts a telephone number for recovery, the attacker will use that path instead and never meet the key at all.

Wrong: A SIM swap requires bribing an insider and is therefore rare. Right: It can be executed by an in-store visit with false information, a support call, or an online port-out request, and the United States Department of Justice records that the operative in the January 2024 hijack of a federal agency’s social media account admitted receiving about 50,000 United States dollars for performing SIM swaps, against reported losses of over 68 million United States dollars from 1,611 complaints to the FBI’s Internet Crime Complaint Center in 2021 alone.

Wrong: Phishing-resistant means the user cannot be fooled. Right: The user can be fooled completely, and in the Cloudflare episode of 20 July 2022 three employees were; the property is that being fooled produces nothing an attacker can use, because the authenticator refuses to act for a name it does not recognize.

18.99 Chapter summary in 20 lines#

1. Most second factors defeat an attacker who holds only a stolen password, which is a real and numerous attacker but not the one that takes accounts from prepared organizations.
2. An adversary-in-the-middle site is a reverse proxy, not a copy, and it relays the victim’s traffic to the genuine site in real time while rewriting Host, Origin, Referer, the Set-Cookie domain and any body references to the real name.
3. The attacker’s prize is not the password but the session cookie, because it is a bearer credential representing a completed authentication and it survives the password being changed.
4. Evilginx was released in 2017 as an nginx script and rebuilt as a standalone server on 26 July 2018, and Modlishka in 2019 added proxying of multiple destinations through one attacker domain.
5. The capability became a subscription product: Sekoia observed the Tycoon 2FA kit from August 2023 with pages sold from 120 United States dollars for ten days, and a takedown on 4 March 2026 seized over 300 domains from a platform reported to have used over 24,000 domains and to have around 2,000 subscribers.
6. Microsoft reported on 12 July 2022 that one adversary-in-the-middle campaign had attempted to target more than 10,000 organizations since September 2021, and stated that the technique works regardless of which sign-in method the victim used.
7. Group-IB’s 0ktapus report of 25 August 2022 records 169 phishing domains, 9,931 stolen credentials, 5,441 records containing multi-factor authentication codes and 136 identified victim organizations.
8. Cloudflare and Twilio were attacked in the same July and August 2022 campaign, and the difference in outcome was that Cloudflare’s hardware keys implement origin binding while Twilio’s second factor could be relayed.
9. Push fatigue needs no fake site: the attacker submits the password repeatedly until the victim approves, and Microsoft described exactly this on 22 March 2022 in its analysis of the group it tracked as DEV-0537.
10. Cisco was compromised on 24 May 2022 by combining a high volume of push requests with voice calls impersonating trusted support organizations, and Uber’s update of 19 September 2022 describes a contractor who eventually accepted one of the repeated requests.
11. Number matching, enforced across Microsoft Authenticator from 8 May 2023, replaces a tap with the transcription of a number shown on the sign-in screen, and defeats silent abuse but not an attacker who can read the number to the victim.
12. CISA’s fact sheets of 31 October 2022 rank FIDO/WebAuthn and public key infrastructure as phishing-resistant, place application codes and number-matched push below them, and describe SMS or voice as a last resort option.
13. A SIM swap moves a telephone number to an attacker’s card by store visit, support call, port-out request or insider, and the Princeton study published in August 2020 found 39 of 50 controlled attempts succeeded across five prepaid carriers.
14. The FBI’s Internet Crime Complaint Center recorded 320 SIM swap complaints with about 12 million United States dollars of adjusted losses from January 2018 to December 2020, and 1,611 complaints with over 68 million in 2021 alone.
15. In the hijack of a United States federal agency’s social media account on 9 January 2024, the operative admitted receiving about 50,000 United States dollars, and the agency itself recorded that multi-factor authentication had been disabled on the account since July 2023.
16. Signalling interception uses specific operations: SendRoutingInfoForSM to discover the subscriber identity and serving switch, UpdateLocation to redirect delivery, and MT-ForwardSM to receive the message, with Diameter equivalents on the S6a interface.
17. Exposure is set by the weakest path into a home network rather than by one’s own operator, which is why Global Title leasing matters and why Ofcom banned it on 22 April 2025, with existing leases ending on 22 April 2026.
18. An authenticator is phishable if any value exists that a user can be induced to produce and an attacker can present onward, and NIST SP 800-63B revision 4 of 31 July 2025 defines phishing resistance in section 3.2.5 as preventing submission of authentication secrets to an impostor relying party.
19. Origin binding is the working fix: the browser writes the true origin into the client data, the authenticator stamps the SHA-256 hash of the relying party identifier into the assertion, and the server compares the origin in section 7.2 of WebAuthn, so three independent checks must all be broken for a relay to succeed.
20. Origin binding protects the sign-in and not the session, so a chapter that ends here is incomplete: sessions must be bound or shortened, phishable fallbacks must be removed rather than demoted, and the recovery path must be closed, which the chapter “Recovery” takes up.

Chapter sources: CISA fact sheets “Implementing Phishing-Resistant MFA” and “Implementing Number Matching in MFA Applications”, both October 2022 and announced together on 31 October 2022, including the five-tier MFA hierarchy and the definition of push bombing; NIST Special Publication 800-63B revision 4, “Digital Identity Guidelines: Authentication and Authenticator Management”, 31 July 2025, sections 2.2.2, 2.3.2, 3.1.3.3 and 3.2.5, superseding SP 800-63-3 as of 1 August 2025; Group-IB, “Roasting 0ktapus: The phishing campaign going after Okta identity credentials”, 25 August 2022, with 169 domains, 9,931 credentials, 3,129 e-mail records, 5,441 MFA code records and 136 identified organizations of which 114 in the United States; Microsoft Security blog, “From cookie theft to BEC”, 12 July 2022, reporting attempts against more than 10,000 organizations since September 2021 and naming Evilginx2; Microsoft Security blog, “DEV-0537 criminal actor targeting organizations for data exfiltration and destruction”, 22 March 2022, on simple-approval MFA prompts, session token replay and SIM swapping, with DEV-0537 now tracked as Strawberry Tempest; Cisco Talos, “Cisco Talos shares insights related to recent cyber attack on Cisco”, 10 August 2022, on the 24 May 2022 compromise, MFA fatigue and voice phishing; Cloudflare blog, “The mechanics of a sophisticated phishing scam and how we stopped it”, August 2022, on the 20 July 2022 attack, 76 employees, Telegram relay and origin binding; Twilio incident report, “August 2022 Social Engineering Attack”, updated to 27 October 2022, reporting 209 affected customers and 93 Authy end users; Uber Newsroom security update of 19 September 2022; CISA, FBI and partners, advisory AA23-320A on Scattered Spider, 16 November 2023 revised 21 November 2023, with ATT&CK technique T1621; MITRE ATT&CK techniques T1557, T1539 and T1621, and software entry S9003 for evilginx2; Kuba Gretzky, Evilginx release notes for versions 2.0 of 26 July 2018, 2.4 of 14 September 2020, 3.0 of 10 May 2023 and 3.3 of 2 April 2024; Piotr Duszynski, Modlishka, released publicly in 2019; Sekoia, “Tycoon 2FA: an in-depth analysis of the latest version of the AiTM phishing kit”, 2024, and Trend Micro’s report of the Europol-coordinated takedown of 4 March 2026; FBI Internet Crime Complaint Center public service announcement of 8 February 2022 on SIM swapping; Lee, Kaiser, Mayer and Narayanan, “An Empirical Study of Wireless Carrier Authentication for SIM Swaps”, SOUPS 2020, August 2020; United States Department of Justice press releases on the guilty plea of 10 February 2025 and sentencing of 16 May 2025 of Eric Council Jr., and the Securities and Exchange Commission statement on the compromise of its social media account on 9 January 2024; FCC Report and Order FCC 23-95, WC Docket No. 21-341, adopted 15 November 2023, published in the Federal Register on 8 December 2023, amending 47 CFR 64.2010 and 47 CFR 52.37, and FCC public notice DA 24-308 of March 2024 on SS7 and Diameter security; GSMA FS.11 “SS7 Interconnect Security Monitoring and Firewall Guidelines”, FS.19 “Diameter Interconnect Security” and FS.21 “Interconnect Signalling Security Recommendations”, all members-only, together with the GSMA Global Title Leasing Code of Conduct with its compliance deadline of 31 December 2023 and the GSMA article “Fighting back against the abuse of Global Title leasing”; Ofcom statement on Global Titles and mobile network security, 22 April 2025, with existing leases ending 22 April 2026; Sueddeutsche Zeitung reporting of 3 May 2017 on the January 2017 SS7 thefts confirmed by O2-Telefonica, and Motherboard’s reporting on Metro Bank covered on 4 February 2019; 3GPP TS 29.272 for the Diameter S6a interface and TS 33.501 for 5G security architecture; W3C Web Authentication Level 3, Candidate Recommendation Snapshot of 26 May 2026, sections 5.8.1, 6.1 and 7.2, with FIDO CTAP 2.2 Proposed Standard of 14 July 2025 and CTAP 2.3 Proposed Standard of 26 February 2026; RFC 5056, RFC 5929 of July 2010, RFC 9266 of July 2022 and RFC 8471 of October 2018 with RFC 8472 and RFC 8473 on channel and token binding; ENISA Threat Landscape 2025, published 1 October 2025, covering 1 July 2024 to 30 June 2025 with 4,875 incidents analysed; Krebs on Security, “Google: Security Keys Neutralized Employee Phishing”, July 2018; Thomas and Moscicki, Google Security Blog, 17 May 2019, on the measured effectiveness of account hygiene.