Two hours from first access to theft: the economics of intrusion have changed

Most SME security policies are calibrated to a human tempo. Alerts are checked in the morning, tickets are handled during the day, the contractor calls back within four hours, and the security review is monthly. The chapter of the report devoted to affiliates of the ShinyHunters collective explains why that tempo no longer means anything.

The real timings #

Anthropic describes this actor's operational tempo as “relatively consistent”, which is an understatement. The raw figures:

• One software vendor compromise: only a few hours between first access and bulk data theft.
• Another: from a single stolen developer token to full administrative control of the victim's cloud environment in about three hours.
• A session store dump: more than 2,100 sets of authentication tokens covering more than 40 customer organisations, in about 34 hours. The report specifies: “AI agents performed nearly all of the work.”

These timings only describe the way in. The report adds that the actor then moved on to iteratively draining internal databases and then, in supply chain cases, the data of end customers, one target after another. Three hours is less than the call-back time in many managed services contracts. It is less than a weekend, less than a bank holiday, less than a week's leave. The report puts it in economic terms: what used to separate well-resourced operations from the rest (reconnaissance, tool development, processing stolen data) is now delegated to models running in parallel. The measured result: “breaches completed in two to three hours, and dozens of victims handled in parallel by individual operators.”

The life cycle of an intrusion, as the report breaks it down #

The value of this chapter lies not in the anecdote but in the method. Anthropic breaks the full chain down into eight stages, each with its own tooling. We go through it here because, read backwards, it is a list of checkpoints for an SME.

1. Sourcing and reconnaissance. Most intrusions start from credentials that are already compromised. The rest come from mass scanning, e-mail phishing, voice phishing and lookalike domain names designed to persuade an employee to open up access. In practice: the most common way in is not your firewall, it is a password already in circulation and a member of staff who gets a phone call.
2. Discovery. Exposed access tokens are found at industrial scale by automated extraction projects: application binaries, code repositories and integrations, code executed in the browser, credential vaults, container images, cloud metadata endpoints, open storage, and AI agents deployed by the victim. The report cites a project that downloads an entire app store to search it for session tokens. In practice: this is the subject of yesterday's article, and it is dealt with by a secrets scanner, not by a policy.
3. Validation and qualification. Everything found is tested before use: bulk validation of cloud keys, login oracles written for the occasion, live replay against production, scoring of resale value, offline cracking. In practice: between the leak and the first attempt against your systems, there is no grace period.
4. Expansion inside the victim. A single valid credential is used to spread: dumping the secrets of an entire cluster, amplifying administration tokens, injecting into CI/CD pipelines, extracting databases and session tables, recovering signing keys from dumps, and fanning out the supplier's permissions to each of its customers. In practice: the compromise of one account is never the end of the story, it is the start of the inventory.
5. Exfiltration channels. The report counts six: consumer cloud storage, a private file server behind an encrypted mesh network, a feed to a messaging bot, staging inside the victim's own cloud, command and control channels, and plain bulk extraction via API. In practice: filtering outbound traffic against a blocklist is not enough. Two of these six channels look like legitimate services, and a third never even leaves your premises.
6. Storage. The loot is stored for reuse and resale: self-hosted infrastructure that serves the stolen databases again, a loot tree per victim, a messaging-based warehouse that also serves as a shop window, and pools of keys that are still valid. In practice: your data survives the incident, indexed and searchable. That is why a leak is never entirely “closed”.
7. Minting lasting access. New credentials are created so that the operation survives your rotation: cloud API keys in your own accounts, developer keys on platforms, forged sessions and second-factor codes, network backdoors. In practice: changing passwords is not remediation. Until someone has listed what was created during the intrusion, access is still open.
8. Monetisation. Resale channels and key pools, direct financial theft, extortion over stolen data, bug bounty income on the side as a double agent, and bulk data kept as leverage. In practice: paying a ransom buys nothing, since the stock already has a use value elsewhere.

The knock-on effect: your vendor is your attack surface #

The most profitable pattern described in the report is not the direct attack, it is the knock-on effect through the supplier. One affiliate specialised in this: after compromising a software-as-a-service vendor, it used that foot in the door to extract the data of around 200 of the vendor's customer organisations, before moving on to the session store dump mentioned above. In another case, the actor exploited a cross-site scripting flaw to get in, escalated its privileges, then exfiltrated the data of thousands of downstream customer organisations. The model helped it understand and manipulate the development and authentication interfaces, forge and convert privileged tokens, and build the cross-tenant bulk export tools.

The end victims did nothing wrong. They chose a piece of software, connected their directory, granted the permissions requested during installation, and that was all. This is precisely the point we have been hammering home since our article on the Cloud Act explained for SMEs: the question is not only “is my provider reliable”, but “how many third parties can reach my data, and through what mechanism”.

What the report calls “vibe hacking” #

The description is worth quoting, because it explains how an average operator gets expert results. The operator gives a general objective (“use this credential at this entity”, “retrieve the data from this set of targets”) and then lets the model assess the environment, write and run scripts, produce summaries, and start again until the task is done. Anthropic adds the sentence that matters: “Very often, the operator may not directly understand each target environment or the complexities of finding and accessing valuable information, instead deferring the specifics to the AI.”

The direct corollary, and the most brutal conclusion of this chapter: security through obscurity is over. The report says so in black and white. An unusual configuration, an obscure business software package, an in-house ERP from 2009: all of these slowed down a human who had to learn the system before attacking it. A model reads the documentation, the error messages and the decompiled code as fast as it receives them. In the report's words, “everything connected to the internet is a potential target for exploitation.”

“Living off the land” applied to AI #

Security practitioners use the expression living off the land for attacks that only use tools already present on the victim's systems: no software brought in, so nothing abnormal to detect. The report observes that these same operators applied the principle to AI. They treated the AI supply chain both as a target and as a resource: they stole the AI keys found in the environments they attacked and used them as extra computing capacity for the rest of their operations. One of these keys was used for about three weeks to carry out secondary attacks against other organisations.

For an SME, this comes down to one sentence: your subscription to an AI service is no longer just an expense, it is an asset that attackers come looking for during the intrusion, and that then funds the next intrusion. In every documented case, the keys came from customer environments; Anthropic's systems were not compromised.

The scale, and the blurring of roles #

The report gives an idea of the loot. At a technology supplier: more than one terabyte of data, including hundreds of thousands of national identifiers and millions of payment card records, staged on a public website to put pressure on the victim. At an airline: access to systems containing tens of millions of passenger records. At an energy company: the operators claimed they could remotely control the charging current of charging points installed at customers' homes.

At the end of the chain, one of the French-speaking operators ran his own shop. It sold stolen bank card records, enriched with the identity of the issuing bank, the cardholder's full personal data and an interactive map of the victims' addresses. The storefront was distributed through a messaging mini-app backed by a home-made database platform, which along the way aggregated several French leak datasets into a search service, including a file of around 400,000 records from a telecoms operator, IBAN and BIC included. The shop's domain name impersonated that of the French national police; the report considers that it served as the shop's branding, not as a phishing lure.

One detail is worth noting, because it is on the defender's side. The report notes that these operators' operational security discipline was uneven: one of them left lying around the address of his own jump box, several messaging bot tokens, a proxy with hard-coded credentials, and even uploaded a file to a public sharing site from inside a victim's environment. In other words: they leave traces on your systems. Those traces are only useful on one condition: that you keep logs, away from the machine that produces them.

The double agent: bug bounty in the morning, extortion in the afternoon #

The same actor collected bug bounties of 2,000 and 5,000 dollars from two companies it had also infiltrated and held to ransom, treating responsible disclosure programmes as an extra source of income from the same targets. The report adds that it also harvested other researchers' public submissions as a source of reconnaissance during its targeted attacks.

What this changes for you: whatever is published about your vulnerabilities, by you or by a third party, is raw material for the next attacker. This is not an argument against responsible disclosure, which remains good practice. It is an argument for fixing before the disclosure deadline expires, and for not assuming that a vulnerability report received is a vulnerability report dealt with.

The questions to put to a supplier, now #

An SME cannot audit the vendor of its payroll software. It can, however, ask seven questions whose answers can be checked, and turn down a supplier that cannot answer them in writing.

1. How quickly do you inform me of a compromise? The GDPR gives a controller 72 hours to notify the CNIL (the French data protection authority); your contract must therefore require a much shorter deadline from the processor. “As soon as possible” is not a deadline.
2. How long do your tokens live, and can I revoke them myself? A session token that lasts six months is a token that will be replayed.
3. Are your administrative accesses named and protected by a second factor, including for your support teams? The question is about their access to your data.
4. Where is my data hosted, and with which sub-processors? The list must exist and be provided: it is an obligation under Article 28 of the GDPR, not a favour.
5. Can I export my data without your help? A backup that does not depend on the vendor is the only one that survives the vendor's bad day.
6. What do you log, and can I retrieve those logs? Without exportable logs, you will never know what was accessed in your account. And in light of the chapter above, the real question is: do you keep a record of token and account creation, not just of logins?
7. What happens if one of your other customers is compromised? In the knock-on pattern, the tenant next door is a path into yours. The answer must mention isolation, not good intentions.

And on your side #

• Quarterly review of the applications connected to your directory and your e-mail; revoke everything no longer in use. This is the action on this list with the best ratio of effort to effect.
• Conditional access: restrict administrative logins to managed devices, and block countries you never work from.
• Alerts on the creation of tokens and privileged accounts. An escalation in three hours produces events; someone still has to receive them. That is the subject of tomorrow's article, and the reason a SIEM exists.
• Centralised, retained logs, away from the machine that produces them. This is the condition for taking advantage of the attackers' blunders mentioned above.
• Backups out of reach, independent of the supplier and of the main cloud account: the immutable 3-2-1 rule has not changed, what has changed is how quickly you need to use it.
• A written, dated recovery plan that assumes the supplier is unavailable and uncooperative: that is the disaster recovery plan, exercised once a year.
• An honest assessment to start with, if all this seems out of reach: the self-audit of ANSSI's 42 measures can be done in-house, and it ranks the work by real urgency.

Tomorrow: the espionage actor that taught its agents to rebuild its malware for as long as an antivirus spotted it, and what that does to signature-based detection.

Sources #

• Anthropic, Detecting and countering misuse of AI: September 2026 (10 September 2026): Cyber operations chapter, GTG-50014 section ShinyHunters smash-and-grab opportunists: intrusion timings, knock-on effect through the supplier, stolen card shop, uneven operational discipline, double role of bug bounty and extortion.
• Same report: Attack lifecycle and AI integration figures: the eight stages (sourcing and reconnaissance, discovery, validation, expansion inside the victim, exfiltration channels, storage, minting lasting access, monetisation).
• Same report: Prevailing trends section for the wording on the economics of attack and breaches completed in two to three hours.
• Our overview: Eight months of AI misuse, and yesterday's instalment on stolen API keys.
• On notification deadlines and the chain of processors: The Cloud Act explained for SMEs.