Why you’re a target now

Three levels

The text therefore distinguishes between documented development, analogy and its own conclusion.

Documented developments show what has already been observed or demonstrated. Analogies from other areas of crime show mechanisms that could be relevant to identity attacks. The actual thesis of this text is built on top of that.

Where the available evidence does not directly carry a statement, that statement is not presented as a development that has already occurred, but marked as a possible consequence or explicitly as a conclusion drawn from the model.

Six terms are used throughout in one and the same sense:

An average household was not an uninteresting subject for a targeted identity attack because its accounts happened to be especially well protected in technical terms.

What mattered was an economic calculation: what does a successful attack promise - and what does it cost to attack this particular target? As long as the expected benefit does not justify the effort required, a target stays uninteresting. If that effort falls, the threshold moves: targets with a smaller possible return can begin to pay off too.

Part of that effort arises anew for every target. The attacker has to work out who the person is, which services they use, which routes in exist and which of them looks promising. It is precisely this target-specific effort that the rest of the argument turns on.

For the technical protection of an account is not automatically calibrated to how valuable successful access would be. Passwords can be reset, phone numbers serve as a factor or a recovery route, and accounts need procedures for people who forget their password or lose their phone.

In principle those procedures apply to ordinary users just as much as to people for whom unauthorised access would have considerably greater consequences - because of their rights, their knowledge or their authority to decide. The value of an account and the strength of its protective mechanisms therefore do not necessarily grow together.

Stricter procedures do exist. But they often have to be switched on separately, chosen deliberately or mandated organisationally. They are not automatically in place simply because a particular account would be especially valuable to an attacker.

Why part of the effort arises anew for every target

When one person is attacked deliberately and another is not, technology alone is not the reason. The attacker’s calculation matters too. Reconstructing a particular person from available information, finding their accounts and relationships, appearing credibly within their circle and getting past whatever checks there may be costs time, labour and resources.

Not all of these costs arise afresh for every target. Tools, infrastructure and general attack methods can be reused. The target-specific part of the attack can be reused only to a limited extent. What has been researched about one person cannot simply be transferred to the next. Anyone impersonating someone else on a call has to know that person’s circumstances and be able to react to unexpected questions.

That is where the limit to scaling has lain so far: every additional target brings additional effort for research, matching and adaptation. The cost per target therefore does not fall automatically just because more people are being attacked.

For an ordinary household this does not mean a targeted attack would be impossible. It can simply be too expensive relative to what there is to gain.

But if the way this target-specific effort grows with the number of targets changes, the whole calculation changes. FIG. 2 at the end of this chapter shows the two forms that stand against each other here.

The assumption behind it

Everything said so far assumes that the attacker acts economically. What is meant is the attacker who bears the costs of an attack and receives the possible return. For that attacker, the calculation decides directly which targets are worth it.

For other attackers the calculation looks different. Someone acting from personal or ideological motives does not have to make a financial gain. Someone working on commission is not assessing the victim’s haul but their own fee relative to effort and risk. The threshold described so far therefore does not apply to these groups in the same form.

Even for the economically acting attacker the model is a simplification. An attack can fail, and it can lead to the perpetrator being identified or prosecuted. Both belong in a complete calculation.

Attacker risk can also differ from one target to another. An attack on especially exposed people or significant organisations can trigger stronger protective measures and greater attention. Many separate attacks on private individuals, by contrast, can at first look like unrelated cases.

That does not mean, however, that additional attacks come without additional risk. As the number of attacks grows, so can the traces, the reports and the opportunities to spot a connection. What matters is therefore whether investigators have to look at incidents one by one or can identify a common origin.

LabHost shows why that difference matters. The investigation was directed not merely at individual phishing cases but at the infrastructure that numerous attackers were using in common. When a shared tool or a shared service is taken down, defence can suddenly make many attacks more expensive at once.

The same principle works in the other direction: when defence becomes cheaper and more readily available, it can make a cheaper attack unprofitable again. What is decisive, though, is whether that defence is actually deployed.

Where this idea comes from

The idea is not new. In 2001, in “Why Information Security is Hard - An Economic Perspective”, Ross Anderson showed that information security is not a purely technical problem. Who bears the cost of a security decision and who benefits from it matters too.

In 2010 Cormac Herley described a further difference: some attacks scale, because a large share of their cost arises independently of the number of victims. Targeted attacks, by contrast, create additional effort for every single target. For that effort to pay off, the expected value of a target has to be correspondingly high.

This text picks up at exactly that point. It asks what happens when it is precisely the part of the attack that used to arise anew for every target that becomes cheaper - and the threshold at which a targeted attack pays off therefore falls.

What the benefit of a target means here

Expected benefit has two sides in this model. FIG. 1 therefore shows them as separate bars.

Capital and return covers everything an attacker can turn to economic account directly or indirectly: money, crypto assets or other transferable holdings. It also includes a financial return that only arises through fraud, extortion or the resale of information obtained.

Assets that move quickly and are hard to claw back are particularly attractive. Self-custodied digital assets are a clear example: the holder controls the necessary key themselves. Once a transfer is authorised and executed, it generally cannot simply be reversed. With individual digital assets, issuers may nonetheless retain additional means of intervention.

Access and effect, by contrast, covers the value of what a compromised identity makes possible. That includes systems a person can reach, approvals they are allowed to grant, information in their mailbox, and contacts who trust a message because it appears to come from that person.

This value can extend far beyond the account itself. Anyone with particular rights, knowledge, decision-making authority or reach can become interesting as a route into a larger target - within a company, an administration, politics or journalism.

Data belongs in this second category too, where it enables further attacks. Contacts, internal procedures, communication patterns or information already confirmed can help to attack other people or systems more precisely. Access can therefore be valuable even though there is little wealth to take from the directly affected account.

The two forms can occur together. A target can be interesting because of its assets, because of its access - or because of both. Which side decides the calculation depends on what the attacker wants to achieve.

Why the benefit rises and the effort falls

Both sides of this calculation can change at the same time: for some households the possible return rises, while the target-specific effort of a targeted attack can fall.

One reason for the first development is self-custodied digital assets. Anyone holding larger crypto assets themselves possesses something that can be transferred directly in a successful attack. In the right-hand panel of FIG. 1 the bar for capital and return therefore grows.

There is also a particular feature of public blockchains: transactions and holdings are visible in principle. If an address can be matched to a person, it can also become visible which digital assets that address holds. According to a European Central Bank survey from November 2024, just under one household in ten in the euro area holds crypto assets. The holdings are predominantly small, and that share has not risen compared with 2022. The claim is therefore not that every household suddenly becomes a valuable target. For some households, however, the possible return from a successful attack can rise.

On the other side, the target-specific effort can fall. Information about people is already available from many sources today. What is expensive is not only obtaining it, but matching it up: which address, which account, which record and which contact actually belong to the same person?

It is precisely that work which can increasingly be automated. Machines can search large volumes of information, recognise commonalities and link details to one another. What used to require substantial research and manual matching for every target can thereby become faster and cheaper. Chapter 4 examines this development more closely.

The effect becomes especially clear when already structured customer data gets out. The maker of a hardware wallet does not automatically know the addresses or holdings managed with its device. But it can know who bought a device, where it was delivered and how the buyer can be reached.

If such data falls into the wrong hands, an attacker no longer has to search for possible targets entirely at random. They receive a pre-selection of people for whom holding digital assets is more likely than in the population at large - possibly already combined with names, addresses or ways of making contact.

That changes exactly the calculation from FIG. 1: the possible return can rise for individual households, while at the same time the effort of identifying those households as interesting targets in the first place falls.

Two kinds of attacker

This calculation does not bite at the same point for every attacker.

The first acts on their own account. For them the logic is immediate: if the expected return justifies effort and risk, an attack can pay off. If it does not, the target stays uninteresting. If the possible return rises or the effort falls, their threshold moves.

The second works on someone else’s behalf. For them the target itself does not have to be profitable. What matters is whether their fee justifies effort and risk. The value of the target, by contrast, is set by the client. A company is to be spied on, an operation disrupted, or access to particular information obtained. How much is spent on that depends on what the result is worth to the client.

That explains why a target can be valuable even when there is little wealth to take directly. With people in far-reaching positions, the benefit can lie precisely in their access, their decision-making authority or their effect on others.

Nor does such a commission have to stay entirely digital. Some steps require someone on the ground: to photograph something, collect it, place it or plug it into a device. Individual physical tasks can be outsourced too, without the person carrying them out needing to know the whole purpose. How far this principle of division of labour carries, and what is documented for it, is shown in Chapter 6.

The same economic principle becomes relevant when the real target is not wealth but reach and trust. Someone who speaks publicly and is heard by many people, or taken to be credible, possesses a form of access that does not show up in their account balance. The value lies in the people who respond to that person.

To make use of that access, an attacker does not necessarily have to take over the person’s account. They can try to imitate that identity or to influence the person’s actual communication. Voice, image and video can increasingly be generated synthetically. Another possibility is to feed a person false information deliberately, so that they pass it on themselves. In that case it is not their login that is overcome but their trust that is exploited.

The attacker’s alternative

Anyone working on their own account has another option: instead of investing a lot of effort in a single person, they can spread attacks widely.

A targeted attack therefore competes with the volume business. As long as the same outlay earns more through thousands of standardised attempts, there is little economic reason to prepare an ordinary household individually and at length.

The two models are not entirely separate, however. Broad attacks, data breaches and large data collections produce information about individual people. If that data is brought together and evaluated, it can be used to filter out people who look particularly interesting for a targeted attack.

The volume business can thereby take over part of the work that has made a targeted attack expensive until now: working out at all who might be worth the additional effort.

What is shifting in this calculation now

LabHost, the case from FIG. 2, lowered the technical barrier to entry considerably. Anyone paying there had neither to program a phishing page themselves nor to build the necessary infrastructure. They received a ready-made replica of a login page and the server it ran on. Templates for messages that could lure possible victims to those pages were on offer as well.

Anyone entering their username and password there did not send the data to their bank or their mail provider but to the attacker. The attacker could then see in a dashboard which data had come in.

Much of this they did not have to build themselves. For around 250 US dollars a month the necessary infrastructure could be bought in. Europol describes such phishing-as-a-service offerings as particularly relevant for actors at the lower end of criminal structures. What previously required technical skill of one’s own could thereby be replaced, at least in part, by a payment.

That does not make any individual target more valuable. What it lowers, to begin with, is the barrier to being able to carry out an attack at all.

Not every part of the attack becomes cheaper as a result, however. Europol distinguishes between credentials traded unverified in large volumes and access that has already been checked, which is offered deliberately and in part auctioned. For advertised access Europol refers to CrowdStrike, according to which its price rose by almost 50 per cent in 2024.

What can be cheap and scalable, then, is the raw material. What remains valuable is the work of turning it into working access to a specific target.

That is precisely where the next question of this text begins: what happens when this hitherto expensive work can increasingly be automated as well?

Modern systems can protect logins very strongly: with passkeys, hardware keys, authenticator apps or biometrics. Anyone setting out to protect an account usually starts there. But the login is only one of several ways in which a system grants or restores access.

Five terms are used repeatedly in what follows:

When the authenticator is lost

People lose authenticators. Phones break, security keys are mislaid, recovery codes disappear and employees leave companies. Services built for scale therefore generally need a way back into the account.

That is not a design flaw. Without recovery, losing a single authenticator could mean losing the account permanently. For the rightful user this second route is therefore necessary.

In security terms, however, it has an important consequence: recovery is an access path of its own. It leads into the same account but does without the authenticator the regular login demands. It becomes a problem when it is not the owner but an attacker who passes the checks provided for it.

That leaves at least two ways into the same account - and for the attacker’s calculation that is decisive:

An attacker does not pay the average of all routes. They look for the cheapest one that gets them in.

A strong login procedure makes the regular login more expensive to begin with. It does not automatically make another access path equally expensive. If a lost authenticator is replaced by a renewed identity check, for instance, security depends on what that check actually proves.

An identity document, a selfie or a video call can deliver proofs of differing strength. A cryptographically read chip in an identity document can technically confirm the authenticity of certain stored data. An image of an identity document cannot supply that cryptographic proof. With image- or video-based procedures, other features therefore have to be checked.

That such procedures can be vulnerable has been demonstrated in practice. In 2022 security researchers managed to deceive six video identification procedures under examination using manipulated material. That does not show that every identity check can be overcome in the same way. It shows that the actual strength of the recovery path depends on the specific check.

ILLUSTRATION

What is entertainment here runs live: the filter alters the camera image as it is being produced - on an ordinary phone, with no prior knowledge, used millions of times over. The box above asks what becomes of that when there is an identity check at the other end.

Why certain forms of this deception could become cheaper comes later.

None of this is an argument against strong login procedures.

How many ways in there actually are

Several ways into the same account also change the attacker’s question. Not: how strong is the login? But: which routes lead into this account - and which of them costs the least effort?

Besides the regular login, account recovery, sessions already running, authorised applications, additional users or the provider itself can all grant access. They serve different purposes and are secured to differing degrees, but they ultimately lead into the same system.

For the attacker’s calculation, then, the strongest barrier is not the only thing that counts. What matters is the cheapest access path that suffices for their purpose.

ILLUSTRATION

One gate, one keyring. The point is not how good the lock is, but how many ways there are to get behind the door.

Two of these routes deserve a closer look: the existing session and delegated access. They differ technically but share properties that matter for the attacker’s calculation.

The decisive difference from the regular login is therefore not that these routes are weaker in principle. They move the proof of security into the period after the login. An attacker who can take over an access already granted may no longer have to get past the original login barrier at all.

How such access ends up in the wrong hands

It has so far been left open how anyone gets hold of an existing session or a delegated access in the first place. One possible route does not run through the service at all, but through the user’s device.

Browsers and applications store information there that spares the user from having to prove their identity again at every action: session data, saved credentials or tokens of services already connected. Malware with sufficient rights on that device can try to read out such information or to take over its use. Which data is actually reachable depends on the operating system, the browser and the protective mechanism in place.

How malware or manipulated code gets onto a device is a question of its own. Possible routes run through everyday events: an attachment, a download from a replica site, a browser extension, a tampered update or a software component that another program pulls in automatically.

The last examples in particular lead to a larger problem. Software almost never consists solely of code from its actual maker. Programs use libraries, extensions and other components, which in turn can have dependencies of their own. Anyone using a program therefore relies on a whole chain of parties.

Such external dependencies are not a further access path. Compromising them does not attack a route into the account that the system provides; it attacks the environment in which those routes work.

Code from third parties is found both on the user’s device and in a provider’s systems. Its possible effect differs at those two places.

At the provider these can be libraries, payment or analytics services and scripts embedded into an application. If such a component contains an exploitable flaw or has been tampered with deliberately, it can become a shared point of attack.

What that makes possible depends on where the component is used and which rights it holds. Manipulated code could, for instance, alter content, capture input or reach data available to it.

The decisive difference from an attack on a single device lies in the reach: if a shared dependency is compromised at a central point, a single intervention can potentially reach many users or systems.

ILLUSTRATION

Every new block falls into a structure that is already standing. In a piece of software exactly that happens daily: updates, libraries and packages pulled in arrive inside something that already works. One difference remains - in the game, the display on the right tells you which block comes next.

On your own device the direction is different. Where a compromised component at the provider can potentially reach many users, on the device it is the digital access of a single person that is concentrated. That is where browsers, mail programs and other applications run, holding access that has already been granted.

Third-party or manipulated code executed there with sufficient rights can therefore try to reach exactly that access, or to take over its use. On one side, many people stand behind a shared system. On the other, many accounts stand behind a single device.

With delegated access a third form of concentration arises - and for it the user’s device does not have to be compromised at all.

When a user grants an application access to their mailbox, their calendar or another service, that application receives a digital authorisation for it, typically in the form of a token. That authorisation is then administered by the application and can - depending on the architecture - be stored on its systems.

Part of the security thereby moves. The user granted the authorisation once, but it then has to be protected where the application administers it as well.

If that system is compromised, an attacker does not necessarily have to attack the affected users individually again through their devices or their regular login. Instead they attack a place where access already granted by many users can converge. Which access they could actually take over depends on how it is stored, on the protective mechanisms and on the permissions in question.

Added to this are the application’s own dependencies. Hardly any service performs every task itself: other providers may store data, send messages, run analytics or supply infrastructure. If credentials or authorisations are passed on to such systems, another place arises whose security becomes relevant to the same access.

The user may have given their consent to one application. Technically, however, the security of that access can then depend on several systems involved.

It also works without access to the device - and without the provider itself being compromised. An attacker can insert themselves between the user and the real service.

To do so they lead the user via a link to a replica login page at a third-party address. What the user enters there is passed on to the real service. A one-time code can be forwarded the same way, immediately. The real service therefore sees what is in principle a valid login attempt, while the attacker tries to take over the access that results from it.

An additional password or a classic one-time code does not necessarily prevent such an attack, because both can be entered by the user and passed on. Phishing-resistant procedures such as passkeys or FIDO2 security keys work differently: the cryptographic proof is bound to the real service, or rather to its domain. On a replica page a valid proof for the real domain therefore cannot simply be produced.

Two things about this are notable for the calculation.

The first: none of the routes described so far has to break the login itself. With a compromised device, access already granted can be taken over. With delegated access the authorisation already exists. And in the phishing attack described, the real login is carried out by the user in person.

Strong authentication is therefore by no means worthless. It makes certain attack routes considerably more expensive and can prevent others entirely. But it does not automatically protect every access already granted or obtained by another route.

The second concerns the cost structure. Malware and broadly scattered phishing can at first be deployed scalably. The substantial effort sits in tooling, infrastructure and distribution; additional potential victims do not cause the same additional effort as in an attack prepared individually from the outset.

That brings back the lower curve from Chapter 1. A broadly scattered attack can first reach many people and only afterwards show where something usable was found.

Parts of this effort can fall too. Texts can be generated and translated automatically, variants of web pages produced more quickly, and existing code altered or reused more easily. Europol also describes a market for ready-made tools and services through which technical capability can be bought in.

The attacker therefore does not have to master every component of their attack themselves. They can automate, take over or buy in as a service a growing share of the work required.

ILLUSTRATION

Anyone casting a net does not pick out the fish. That fits the calculation better than the image of precise, targeted access. There is one difference, though: a real catch would have to be rummaged through, this one does not - it is searchable. Anyone pursuing a particular target simply asks it a question.

What the net brings in gets traded. And that changes the calculation for a targeted attack. Such an attack begins with somebody having to know something about their target: where they are a customer, how they can be reached, what they use. Exactly that kind of information can be sitting in what was collected broadly beforehand. In the collecting it was a by-product; for the targeted attack it is the beginning - and the attacker can buy it rather than work it out. The precondition is knowing where such things are offered. There are specialised dealers and marketplaces for that, brokering stolen data and access.

What lies behind a single point of access

How far access reaches depends on what someone has obtained. Between an account and a device there is more than one step.

If it stops at an account, even that is more than a single point of entry. A mailbox is a source of material: it reveals which providers someone is a customer of, how they write, whom they know and which invoices are outstanding. In targeted attacks, research and preparation form a substantial block of cost, and a mailbox can already hold part of that information in one place. On top of that, recovery for many other services runs through the email address. A mailbox is therefore not simply one account among many; it can itself become the starting point for access to further accounts.

Where the smartphone is concerned, the concentration is greater still. On a device that is permanently online, numerous signed-in applications and existing sessions come together. The authenticator that generates a second factor or confirms a login may sit there too. And increasingly the same device takes on functions for digital identity credentials that used to be kept more separate, on other carriers or documents.

That makes the smartphone a particular point in the calculation: on a single device, communication, existing access, authentication and identity functions can all converge.

This is not a theoretical fringe case. ENISA describes mobile devices as a relevant target and documents malware designed to obtain credentials or existing account access directly on the device.

For the calculation this means: an access route can be comparatively cheap and still lead a long way. What access yields is not decided by how hard it was to obtain, but by where it ends.

Where such access turns up in everyday life

Delegated access is granted so that an application can do its job: enter appointments, sort invoices, search the mail. For that it needs the corresponding rights. And anyone who takes over such access can act within those rights too.

An authorisation granted can reach further than a single action would require. What it covers is settled when it is granted, not at each individual use.

The same basic idea - reusing access already granted - also exists without any third-party service. With Signal, for instance, a further device can be connected to an account by QR code. That is not delegated access but an additional equal point of entry to the same account: a further device gains access.

A documented case shows how this intended mechanism can be misused. Anyone who gets a user to scan a QR code prepared for the purpose can, under certain circumstances, link a device controlled by the attacker to the account. Neither a stolen password nor malware installed on the victim’s device is required for it.

What follows from this is not to connect nothing any more. What follows is that access already granted should be managed as deliberately as the login itself: it should be visible and revocable, and, where sensible and technically provided for, limited in time or in scope.

What of this lies in your own hands

How the routes listed here are built is mostly decided not by the account holder but by the provider: how long a session lasts, whether a password change ends it, how recovery is constructed, and what a support agent may see or reset in a customer account.

Four things lie chiefly in your own hands: which login procedure you choose, as far as the provider leaves a choice; which once-granted access you let stand; whether keys, tokens and permissions no longer needed are revoked or renewed; and what runs on your own device.

The third point carries more weight than it sounds. Withdrawing a known access ends precisely that access. Reviewing and renewing regularly, by contrast, can also surface permissions long since forgotten: the old app password in the mail program, the API key of a tool nobody has used for two years, or an application whose access nobody needs any more. What matters here is that the old permissions actually become invalid.

Self-custodied digital assets are a special case. With a classic wallet that has no recovery or administrative authority behind it, the decisive control lies with the holder alone. There is no provider to reset a forgotten key, no support desk to restore access - and therefore, at this level, nobody an attacker could persuade to hand out a new way in.

That leaves the holder.

The holder can be induced to disclose their key or its recovery data. Or they can use the key themselves to approve a transaction or an authorisation whose actual effect is different from what they assume. The attacker then does not have to break the key. They get its owner to use it.

That is precisely what is particular about self-custody: it removes certain attack routes that run through providers and recovery, but shifts the responsibility for them onto the holder. And the price for that sits on the same balance sheet: where no recovery authority exists, nobody can restore access if it is lost either.

ILLUSTRATION

Whoever approves decides on the basis of what the screen shows. They have nothing else. At Bybit the interface looked as it always did - only what was actually being signed was not on it.

The same routes at the provider

These routes do not only exist for the individual. A provider or contractor likewise has logins, recovery procedures, existing sessions, delegated access, co-authorised access and support accounts - and uses third-party code.

If one of those routes is taken over there, the reach can be considerably greater than with a single user. What is attacked is then not each customer account on its own but a place already authorised to act for many customers (FIG. 6). How many can actually be reached depends on which rights the compromised access holds.

Most of the documented cases in this chapter follow that pattern - Okta, Uber, LastPass, British Airways, Polyfill: what was attacked was not the customer directly but a place their security partly depended on. The Signal case is an exception. There the user was induced to grant an intended form of access themselves.

And it does not stop at access. Such a place also keeps holdings. Two fundamentally different things can sit in them.

One is details about customers: contracts, histories, messages or master data already verified. In themselves they open no account. Their value arises where they can be used for a later attack.

Some checks rest on asking for details about a customer: a security question, or a support agent on the phone trying to establish who they are speaking to. Anyone who already holds the underlying details no longer has to research them. Where other proofs are demanded, the same data at least remains preparatory work for further steps.

There is an economic difference in this: the cost of collecting, matching and in part verifying these details was originally borne by the company. Whoever later obtains the resulting data holding does not have to do that work again. And because information can be copied, the same data can then be passed on more than once.

What such a holding is actually worth depends, however, on how expensive it remains to match it with other material belonging to a specific person. Chapter 4 deals with that.

A data holding once collected and matched can therefore lower the preparation costs of several later attacks. If it is sold repeatedly, different actors can moreover set their sights on the same victim independently of one another.

The other is credentials that have no business being in such holdings at all. At Okta, for instance, files uploaded by customers into the support system contained session tokens.

The difference counts because the two kinds of material age differently. A token has a limited technical validity. Personal details, by contrast, can remain usable for far longer. Changing a password or signing out does not make a name, date of birth, address, provider relationships or other already known details unknown again.

That describes what an attack can come in through and what it finds there. What remains is the question of what a single successful step is worth - and the answer is uncomfortable for anyone picturing a simple chain.

The chain is most often played through on SIM swapping - the process in which an attacker gets a mobile operator to transfer someone else’s number to a SIM card of their own. Whoever has the phone number supposedly has everything else. That is exactly where it can be shown why this is not so.

A phone number cannot be taken over automatically just because someone knows a name, email address and date of birth. Mobile operators can demand customer passwords, existing accounts, documents or other proofs.

The same applies to mail accounts, banks and corporate access. Well-secured systems demand additional, mutually independent proofs for critical changes: a device already registered, a strong authenticator or a renewed check. It is precisely such independent hurdles that break the chain. The loss of a single channel then does not automatically lead to the next account.

How much hangs on this is shown by the takeover of the US Securities and Exchange Commission’s X account on 9 January 2024. In that case control over the associated phone number was enough to obtain control over the account as well - multi-factor authentication had, according to the agency, been disabled months earlier and not re-enabled.

The sequence as described by the agency, all times in the New York time zone:

The post at 16:11 read: “Today the SEC grants approval for #Bitcoin ETFs for listing on all registered national securities exchanges. The approved Bitcoin ETFs will be subject to ongoing surveillance and compliance measures to ensure continued investor protection.” With it appeared an image carrying a quotation attributed to the then chair.

For fifteen minutes the false report stood on the account of a regulatory authority without a public correction. According to the US Department of Justice, the Bitcoin price rose by more than 1,000 dollars per unit immediately afterwards and fell by more than 2,000 after the correction.

RECONSTRUCTION, NOT A SCREENSHOT

This is what appeared through the regulator’s account on 9 January 2024: seal, verification tick, agency name. Nothing about it looked false, because nothing about it was false - except the sender. The reconstruction reproduces the appearance, not the documented wording and not the documented time; both are given in the text above.

What matters for the calculation is not merely that a phone number was taken over. What matters is what lay behind it: in this case the successful first step led all the way to an account whose publications moved the market directly.

Against that stands a second case. In August 2022 Cloudflare publicly described how a phishing attack that hit several companies simultaneously failed against the hardware security keys in use there.

The two cases show the same calculation from two sides, on two different routes: one worked because a decisive control was missing; the other ended because a bound control held.

Which brings us back to SIM swapping, where this section began - the SEC case was one itself. That a phone number alone is not enough is emphatically not an all-clear. A mail account and a phone number remain especially valuable, because many services use them simultaneously for communication, recovery and confirmation. If one of those channels is compromised, its reach can therefore extend far beyond the first point of access.

The domino does not fall by itself. What happens is more mundane: every successful step can make the next one cheaper. Details already confirmed, existing sessions and delegated access can be used for further steps. Anyone who has a billing address from a mailbox no longer has to research it at the next provider. Anyone already controlling a confirmed communication channel does not have to obtain that proof first.

That does not make the next step automatically successful. But its effort can fall. And the less a further attempt costs, the more further attempts become economically defensible - and the greater the probability of eventually meeting a process whose remaining hurdle is low enough.

An identity was never necessarily a secret. What was always expensive was the matching.

Employer, phone number, email addresses, provider relationships, family members, writing style, data from old breaches - much of this could be found before as well. The real work of a targeted attack consisted in bringing scattered information together: recognising that a line from one holding and a line from another refer to the same person - and building a usable picture of the target out of that.

Part of this material no longer even has to be searched for; today it can be bought. Chapter 2 describes how such holdings arise and get passed on. What changes above all, then, is the effort needed to turn scattered information into a specific target.

That is precisely the item standing first in the list below.

A targeted attack consists of several cost items. None of them disappears entirely, but not all of them stay equally expensive.

The conclusion to draw from this is not that a targeted identity attack could be automated in full. What matters is how many of its target-specific cost items fall - and by how much. The less human work an additional target requires, the further its cost per target falls, even if individual steps still demand a person.

So far this has been mainly about the routes that lead directly to an account or an authorisation. But the route to a target does not have to be direct. The first thing attacked need not be the actual end target.

Other parties can become relevant here in two different ways: they hold something that is missing for a later step - or they sit between two sides and help determine what arrives from one at the other.

A system therefore does not have to hold access to a particular account to be valuable to an attacker. Sometimes it is enough that it knows something, confirms something or has already checked something that would otherwise have to be obtained or checked elsewhere.

In a direct attack, part of the preparation arises anew for every target - that is how it stood in the calculation in Chapter 1. With a shared intermediate target, by contrast, the same work can arise once and then bear on several possible end targets.

That is precisely where the concentration effect lies: a provider holding mailbox access or other permissions for many users bundles in one place something that would otherwise have to be reached at each user separately. If that place is attacked successfully, the one-off effort can be spread across several possible end targets - the cost per reachable target falls.

The individual’s mailbox then does not have to be reached through the individual at all. The relevant route can run through a service the user granted access to two years ago and has forgotten about since.

The party in between

An intermediate target supplies a component, and another step follows after it. Alongside that there is a second mechanism, which works differently.

Many processes do not run directly from one party to another. One side issues or approves something, the other receives it and processes it further. In between there can be a party through which that process runs and which helps determine what arrives at the end: a portal, an interface, a user interface or a service provider.

If that party is influenced, the attacker does not necessarily have to change either endpoint. It can be enough to change what is transmitted, processed or displayed between them.

The receiving side then gets something that appears to come from the expected source but need no longer correspond to what the other side originally intended or presented. If checking is done solely through that same intermediary, the alteration can be hard to detect.

At Bybit this pattern showed itself particularly clearly: between the signatories and the transaction actually signed sat an interface whose display had been manipulated. The signatories thereby confirmed a transaction whose actual effect did not correspond to what the interface conveyed to them.

A related pattern is shown by two cases from Chapter 2: at British Airways the payment page was altered so that customer data was additionally transmitted to the attackers. In the Polyfill case, altered code could be delivered to numerous websites through a shared external dependency, without the operators of those sites having to change any of their own code for it.

What the cases have in common is not the same technical attack. What they have in common is the position of the intervention: what was altered was a party or component between what one side intended and what was displayed, processed or executed on the other.

Both roles occur, and they do not exclude one another. The same party can contribute something and pass something through at the same time. What it contributes as an intermediate target opens nothing by itself - it supplies something that is missing elsewhere. The simplest instance of that is an identifier.

When an identifier becomes a person

An identifier does not have to contain a name to be valuable to an attacker. At first it may stand only for the fact that several events belong to the same user, device or account. Only additional information can turn that into a connection to a specific person.

The decisive point is therefore not the identifier on its own but the place at which identifier and identity are joined together. The same basic pattern is found with device and advertising identifiers as with addresses on a public blockchain: the identifier can be visible or stored for a long time without it being known whom it belongs to. If that connection is added later, earlier events become attributable too.

From this follows a property in time that the static calculation in Chapter 1 lacks: the effort for research and matching does not have to arise at the moment of the attack. It can have been incurred years earlier and borne by somebody else.

On this reading, stored identifiers are a possible advance payment against later attack costs. As long as the connection to a person is missing, what they say remains limited. If that connection arises later, material already held can gain value retrospectively.

The length of time over which linkable identifiers are retained thereby becomes a factor in the calculation too: the longer material stays available and remains attributable afterwards, the less of it an attacker has to obtain afresh at the moment of the attack.

The assistant as a point of concentration

An identifier is one of the smallest contributions an intermediate target can make. At the other end stands a point where a great deal can accumulate at once.

An isolated large language model (LLM) without access to personal or corporate systems changes this calculation only to a limited degree; what artificial intelligence can make cheaper in research, matching and personalisation is set out in Chapter 4.

It becomes different with an assistant allowed to reach mail, calendar, files, contacts or internal systems for its work. Three things can converge at that point. The categorisation is this text’s own description, not an established taxonomy.

Not every assistant has all three levels. But the more of them come together, the greater the significance of that single point.

This creates a series of trust relationships: the user trusts the assistant, the assistant uses tools, and those tools in turn hold permissions towards further systems. A security problem therefore does not have to lie in the language model itself. It can arise at any point in that arrangement.

There is a further particularity: an assistant processes content it did not produce itself - documents, mail or web pages. For a language model, such content can be more than data; it can influence the model’s behaviour. That is precisely the problem of indirect prompt injection: an instruction can sit in material the user is merely having the assistant read or process.

It becomes dangerous above all where reading and acting are connected. If the assistant can use tools on the basis of what it has read, third-party content, delegated authorisation and capacity to act meet at the same point.

Its position thereby resembles the intermediary in FIG. 7, without being technically the same case. At Bybit an interface had to be compromised in order to alter the display between intention and approval. With an assistant, controlled external content can already attempt to influence what the system does next. Whether an action actually results depends on which rights, tools and approval steps the system has.

The delegated access here is the same basic mechanism as in Chapter 2: the user has granted one system rights towards other systems. What is new is the additional question of what decides, within that system, when and for what those rights are used.

A system therefore does not become a more interesting target because it uses AI. It can become more interesting because context, permissions and capacity to act converge there. The point of concentration is then not the model alone but the whole arrangement that enables it to act.

When trust concentrates

One particular form of intermediate target deserves a section of its own: a party whose verification result is adopted by others.

Where systems trust a signed or institutionally confirmed credential, they do not check every underlying fact themselves. They rely on another party having already carried out that check. An identity provider, a certification authority, a public agency or a company’s internal identity system can thereby become a trust anchor.

The basic pattern is not new. Its significance grows where many further systems adopt the same verification result. The cost of the check then arises once, but its result carries on having effect in several places.

A cryptographic check can show whether a credential comes from the expected source and has remained unchanged since it was issued. It does not automatically answer whether the underlying statement was correct in the first place. A credential can be genuine and still be wrong.

What is open to attack is therefore not only the credential itself. Also relevant are the check it rests on, the party that issues it, and the systems through which it is verified and used.

Against this stands a well-known maxim: don’t trust, verify. As an attitude it is right; as a complete description it falls short. Verification has preconditions of its own: a procedure, a device, software, keys, data, or a party whose result is accepted.

Whoever verifies therefore does not eliminate trust entirely. They decide what their verification rests on.

The Bybit case shows the practical significance of that difference: the signatories wanted to check a transaction, but the interface through which its content was conveyed to them had been manipulated. A check is therefore only as informative as the properties it actually verifies independently.

The decisive question is thus not only whether trust is placed, but in whom, in what, and at which point in the chain.

None of this is an argument against central verification bodies. Specialised bodies can standardise checks and carry them out consistently. Concentration can thereby raise the quality of a check and at the same time enlarge the reach of an error.

How far that effect extends depends on the downstream systems: on reach, permissions, means of revocation and additional controls. An error at a trust anchor therefore does not mean automatic total failure - but the more systems adopt its result, the greater its effect can become.

Finally, who bears those consequences is not a purely technical question. Duties, responsibilities and the consequences of error can be allocated contractually or by regulation. With eIDAS, for example, Europe has a legal framework for electronic identification and trust services that places such trust relationships not only technically but also legally.

Much of what has been described so far can be passed on as information: a component, an authorisation, a ready-made verification result. Information can be copied, stored and handed on. Not everything an attack has to get past has that property.

At the end there can remain a last metre that is bound to something: to a device, an authenticator, a person, a second channel or a particular process.

The idea of a fully autonomous agent independently taking over an identity therefore falls short. Not because software is inherently too weak, but because some processes demand more than the right information: a proof bound to something the attacker cannot simply copy out of a data holding.

In many everyday procedures, information about a person continues to play an important part: name, date of birth, address, number, voice or face. But information has one decisive property: it can be reproduced.

Information about a person therefore does not in itself prove that this person is acting right now or controls a particular authenticator.

Presented or verifiable

The line is usually drawn between physical and digital: the document in your hand against the file on the screen. For security a different line matters more: is something merely presented, or can its authenticity and binding be verified independently?

Images, depictions of documents, voices and videos can be generated synthetically. That does not readily defeat a check that actually verifies authenticity and binding. What it puts under pressure above all are procedures whose probative value depends substantially on whether something looks or sounds plausible.

A credential that is verifiable technically, cryptographically or institutionally works differently: what it establishes is not meant to rest on its presentation being convincing.

What forces an attack out of the purely information-based

What remains laborious is whatever is bound to something an attacker cannot simply reproduce from existing information: control over a registered device or an authenticator, physical presence, a robust means of legitimation, an independent decision by a human being, a second channel or a waiting period.

These barriers are not equally strong, nor are they insurmountable. But they change the calculation: at these points, information alone is no longer enough.

What can be handed off and what cannot

That raises the question of whether such bound steps can also be organised more cheaply. In part.

Mere presence, a local observation or a delivery can in principle be taken over by another person without that person needing to know the whole context. The more strongly an action is bound to a particular person, a particular device or a particular means of legitimation, by contrast, the less interchangeable its execution becomes.

Not every task can therefore be delegated equally easily.

At the same time the coordination itself can remain separate: one party decides which pieces of information belong together, which task is needed next and how individual results are brought together.

That complex undertakings can be organised through a division of labour is not hypothetical. This organisational principle is, however, documented chiefly in other areas of crime so far, not as a general model of economically motivated identity attacks.

Carrying this over to such attacks is therefore an analytical assumption of this text, not a documented practice.

What matters about it is neither the political origin of individual documented examples nor any particular communication service. What matters is the organisational principle: digital coordination can separate commissioning, brokering, execution and consolidation from one another.

A large undertaking demands an actor who can do and know a great many things at once. Many small tasks, by contrast, can be distributed among several participants, none of whom has to know the whole context.

Both sides of the calculation are now in place: on the attack side, individual costs can fall. At the same time, information, permissions and trust can concentrate at places on which many further systems depend.

The development can be condensed into three mechanisms.

The same technical development that makes research and coordination cheaper can at the same time create new points of concentration inside legitimate systems. The more deeply an assistant is embedded in working processes, the more context, permissions and capacity to act can come together at one point. That is a conclusion of this text, not a measured rule.

For defence, one direction of view follows above all: it has to act where the calculation can be influenced - and not only at the most visible barrier.

Recovery then belongs to the security of the login. Delegated access and existing sessions are trust relationships in their own right. External verification bodies belong to the attack surface, even where they hold no direct access to an account. And an attribute that can easily be researched or reproduced has only limited probative value on its own.

Defence can act on both sides of the calculation. An additional independent control, a bound authenticator or a waiting period can raise the attacker’s effort. Detection, revocation and reversibility, by contrast, can limit what successful access yields in the first place.

None of these measures has to make an attack impossible in order to be effective. What counts in security economics is whether it shifts the calculation far enough: the necessary effort upwards or the expected benefit downwards.

This comes at a price. Measures that make an attack more expensive can make legitimate use more laborious too. A waiting period on critical changes hits the attacker just as much as the customer in a hurry. A second independent channel costs devices, time or support. Recovery with especially high requirements can make legitimate access harder for people.

Convenient recovery routes are therefore not automatically an omission. They are part of a trade-off between security, availability and usability. Security thereby also becomes a question of distribution: who bears the additional friction - and who bears the damage when it is absent?

A second quantity belongs in that trade-off. Chapter 1 called assets especially attractive when they move quickly and are hard to claw back. That can be generalised: successful access is worth less to an attacker if its consequences can be detected, contained, revoked or reversed quickly.

Detection, revocation and reversibility therefore act on the calculation as well - only on the other side. They do not necessarily raise the effort of the attack. They can lower its expected benefit.

One objection remains, and it is central to this model: the calculation so far looks mainly at what happens when individual costs fall on the attack side. It does not mean that defence stands still.

Defensive techniques develop further too. Phishing-resistant authentication, more strongly bound credentials, better detection and more restrictive recovery processes can for their part raise the effort or limit the possible damage.

Which side develops faster is not something this text answers. Its claim is narrower: the costs on the attack side are not a constant. If they fall, a technically unchanged barrier need no longer have the same economic protective effect as before.

That leaves the question in the title.

Anyone who has not been a worthwhile target so far may have been spared for one reason alone: the target-specific effort did not add up. That is not a fixed property of the target but an economic threshold - and that threshold can shift without anything changing in their technical security.

If the effort falls far enough, the wall does not necessarily change. What changes is who finds it worth reaching.

The set of economically interesting targets can grow as a result. By the logic of this model, the targets added are precisely those whose expected benefit previously lay just below the cost of a targeted attack. From the inside this change is barely visible: nothing need have changed about your account, your password or your authenticator. What changed is the calculation on the other side.

None of this requires an attacker to pick out a particular person from the start.

Information can first be collected broadly, copied, combined or traded. The selection can happen only afterwards: when it becomes apparent which of the identities, accounts or points of access at hand justify further target-specific effort.

That reverses the order. A target is not always chosen first and the necessary information sought afterwards. The information can already be there - and only then is it decided for which targets the next step adds up.