Infrastructure

Exploit foundries: your firewall has become the front line

Two undergraduates in Changsha ran an automated pipeline that decrypts firmware, decompiles it through thousands of calls, forms hypotheses about vulnerabilities, writes the exploit and tests it in a lab, in a loop, day and night. More than a dozen unknown vulnerabilities in a month on network devices, some fifty organisations targeted, thirteen collection agents on a scheduled task. What this means for an SME's inventory.

Exploit foundries: your firewall has become the front line
Contents (11 sections)
  1. What the report calls an exploit foundry
  2. Who ran the factory
  3. The scale of the targeting, and three concrete victims
  4. The firmware loop, step by step
  5. The attack surface reconnaissance loop
  6. The fleet of thirteen collection agents
  7. Persistent campaign memory
  8. Agent swarms
  9. The warning not to miss
  10. What this means for an SME: you are the edge
  11. Sources

Before going into detail, the report takes care to correct a common misconception: “Many commentators focus on the risk of AI developing exploits at scale. While this is a danger, the risk from AI adoption is more pronounced across the cyber kill chain, where adversaries can operate faster, across a broader and deeper surface area, with fewer resources.” Keep this sentence in mind until the end of the article: the chapter that follows describes a spectacular exploit factory, and that is precisely what makes it misleading.

What the report calls an exploit foundry #

Historically, offensive operations ran up against two ceilings: the availability of exploits that work, and the availability of operators able to use them. An exploit foundry is a setup that removes the first. Anthropic identified several actors who had set up autonomous pipelines tasked with conducting vulnerability research agentically, on a continuous basis. The finding is understated: in several cases, AI significantly accelerated the pace of research, testing and exploit design.

Who ran the factory #

The operation is referenced as GTG-10007. The operators, Chinese speakers, probably lived in Changsha, in Hunan. Two of them were identified as undergraduates at a school of computing and communications at a university in the province. One had done an internship at a Chinese security vendor and was interviewing with another for an offensive cyber role. This detail is not anecdotal: it gives the exact measure of the level required to operate such a pipeline in 2026.

From cases like this, the report draws a conclusion that complicates analysts' work: sophistication has stopped being a reliable signal of who is behind an operation. A flawless technical sequence no longer tells you whether you are facing a state service or two motivated students. For an SME, the consequence is simple: there is no longer any point asking “who would come after us?”.

The report describes AI as the engineering and orchestration layer of the entire programme. Five workstreams ran in parallel, with shared tooling and infrastructure:

  • the intrusions themselves, against production systems;
  • reconnaissance of foreign government networks, in the Middle East, Europe and South-East Asia;
  • reverse engineering of security products in search of new vulnerabilities;
  • development and testing of custom malware;
  • building and maintaining an intelligence collection platform.

The scale of the targeting, and three concrete victims #

The team targeted some fifty organisations: education, retail, energy, technology, healthcare, finance, manufacturing, plus several government agencies around the world. Three results are described in detail, and none of the three is a ministry of defence:

  • an online education company compromised, with hundreds of megabytes of pupils' personal data extracted from its cloud storage;
  • a retailer whose production systems were reached, with access to internal machines and a demonstrated ability to modify the live environment, meaning the ability to change prices, stock levels or flows;
  • a South-East Asian government agency, from which citizen records were taken: names, phone numbers, home addresses.

The firmware loop, step by step #

Here is the pipeline described by the report, as it ran without human involvement.

  1. Acquisition. The manufacturer's firmware images are retrieved and decrypted using a specialised skill written for the purpose, then unpacked into usable file systems. This is the step manufacturers believe is protective: it is the first to fall.
  2. Mapping. An agent loads the binaries into a decompiler through a tool server, skims the image, then works through the decompilation and cross-reference chains. The report speaks of thousands of decompilation calls, with consecutive sequences dominating the call stream: in other words, the machine reads the product line by line, without tiring.
  3. Hypotheses. The agent forms vulnerability hypotheses from a knowledge base it enriches over time and from earlier proof-of-concept research. Parallel agents hunt for vulnerable patterns component by component, with two standing instructions: demand evidence, and use the project memory.
  4. Writing. The pipeline has exploit code written against the hypotheses retained.
  5. Testing. The code is tried against lab copies of the targeted product. This is the piece that changes everything: without a test bench, an exploit remains a theory.
  6. Iteration. The code is fixed and retried in a loop until it works.
  7. Capitalisation. The working exploit joins the operator's private portfolio: a stock that only goes stale as fast as patches are published.

The stated yield: “One workflow iterating continuously on network appliances yielded more than a dozen possible zero day findings in a single month.” In parallel, a sustained research effort targeted a major security product, from the class of software deployed precisely to detect intrusions. It produced several previously unknown vulnerabilities, which the actor validated in its own lab, and the same effort yielded working exploits against several families of network and security appliances. In a separate stream, these same appliances were being attacked at real government customers around the world.

What this changes for you: the stock of unknown vulnerabilities targeting edge devices no longer depends on the number of researchers available. It depends on the compute budget an actor is willing to spend on it. In practice, the interval between two security advisories from your manufacturer is going to shrink, and so is the window between a patch being published and being exploited. An organisation that applies its patches “next quarter” is no longer taking a small extra risk: it is structurally placing itself on the wrong side of this race.

The attack surface reconnaissance loop #

A second pipeline ran continuously, unrelated to the first. Its input: scan scopes derived from target business sectors. Its engine: an exposed asset search service, queried through a dedicated tool server, supplemented by probes that fingerprint the results. Its output: a map of the exposed surface, whose entry points are checked against already known vulnerabilities. And each pass feeds a persistent project memory, which widens the target list for the next round. The framework was used against several foreign government and diplomatic agencies, and against more than a dozen Chinese companies.

What this changes: the question is no longer “am I interesting?” but “am I listed?”. An asset search engine sees your public address, your service banner and your version number. Checking against known vulnerabilities is automatic, and it costs nothing.

The fleet of thirteen collection agents #

Third pipeline: thirteen permanent collection agents, triggered by a scheduled task, tasked with identifying and downloading content from target websites, including public US military and government sites, such as calls for tender, and social media profiles. The means: layered crawlers, anti-bot evasion techniques, and exit through commercial proxies. An adjacent pipeline summarised and scored the retrieved content in the format of an intelligence note, before delivery to a distribution portal. The report stresses the point that matters: this fleet ran on a preset schedule, with no human in the loop.

The collection platform behind this fleet harvested, in bulk and unattended, open-source material aligned with state intelligence priorities: publicly available military doctrine and official publications, specialist regional defence press, public policy sources. Nothing illegal about the raw material: it is all public. What is new is scaling up to industrial level a monitoring task that once kept entire teams busy, and turning it automatically into usable notes.

Persistent campaign memory #

What binds it all together is less spectacular and more important than everything else. Target lists, harvested credentials, the state of each engagement, standing instructions: everything was kept between work sessions. Each restart therefore picked up mid-campaign, with the accumulated context, and the collection and vulnerability research capabilities kept running while their owners were away. An offensive operation stops being a series of individual efforts and becomes a process, with a state, a queue and incident recovery.

Agent swarms #

The report speaks of agent swarms: a lead agent breaks down the reconnaissance and post-exploitation work, then distributes it to many sub-agents that run in parallel. It is the difference between a craftsman and an assembly line. An operator no longer follows one lead at a time, they follow thirty, and only review the results.

When an intrusion succeeded, the assistant enumerated the machines, escalated through credential reuse and exposed administration interfaces, harvested credentials and data stores, sent the material back to the operator's infrastructure, then moved on to the next machine with what it had just harvested. A detail that says a lot about the team's caution: despite worldwide targeting in the automated pipelines, the intrusions carried out by hand focused exclusively on Chinese victims.

What this changes in practice for your defence: the two levers that slow down an agent swarm are those that cut off lateral movement. One, credentials that only work in one place: no identical local administrator password on thirty machines, no service account reused between two applications. Two, administration interfaces that do not respond from just any machine on the network. An agent that enumerates, escalates and pivots feeds on exactly these two conveniences.

The warning not to miss #

Back to the sentence at the start. The risk is not concentrated on producing exploits: it is spread across the whole attack chain. Reconnaissance, tool development, data processing, exploitation: every link has been raised by AI, and it is the combination that makes the difference. The report adds two nuances worth quoting. First, humans keep the decisions that matter to them: target selection, monetising results, review. Second, autonomy and severity are two separate axes: several of the most serious compromises in the report come from operations where a human directed every step.

The conclusion is economic, and it is the one that should persuade a company director. Autonomy compresses the cost of a campaign (fewer skills required, less work per victim) without changing the potential gain. This shift makes previously marginal targets viable, and encourages higher-volume, lower-touch operations.

What this means for an SME: you are the edge #

An SME is not targeted for its secrets. It is targeted because its firewall, its VPN concentrator, its NAS, its e-mail gateway, its multifunction printer or its IP camera are reachable from the internet and known to an asset search engine. Monitoring of edge devices exploited very quickly after a vulnerability is published was already ANSSI's main point in its latest overview; this chapter explains where the stock of vulnerabilities comes from, and why the era of quiet vulnerabilities is ending.

  1. Take inventory of what is exposed. Not what you think you expose: what actually responds. An external scan from the internet, once a quarter, across all your public addresses. Half the findings will be things nobody knew were switched on.
  2. Take off the internet everything that has no business being there. Administration interfaces, RDP, databases, monitoring dashboards: behind a VPN or a bastion host, never directly exposed. This is the measure that removes the most risk for the least money.
  3. Decide on patches in days, not months. On an edge device with an unauthenticated code execution flaw, the window is counted in hours. Our answer is tooling that shows the state of the estate and leaves the decision to a human, backed by daily CVE monitoring.
  4. Treat end of support as an outage. A device that no longer receives patches is not “a bit old”: it is permanently vulnerable to everything that comes out, and the foundry described here works regardless of its age. It gets replaced, or it comes off the network.
  5. Subscribe to the advisories from your equipment vendors, and know within an hour whether you are affected. That requires knowing which models and versions you run, hence point 1.
  6. Segment. The NAS, the cameras and the door controller have no business being on the same network as the accounts department. A compromise at the edge must remain a compromise at the edge. We described a firewall configuration trap that shows why segmentation has to be checked rather than assumed.
  7. Log and look. An edge device that sends its logs nowhere will tell you nothing on the day it is taken over. Centralised collection is what turns a hunch into a finding.
  8. Do not count on obscurity. Changing a port, hiding a banner, avoiding obvious names: this delays a curious human by ten minutes and an agent by zero seconds.

Tomorrow, a change of register: the chapter on illicit distillation, and why what you type into a cheap AI assistant does not stay where you think.

Sources #

About
01/Read nextThree articles

Related articles

Infrastructure

Intermittent SERVFAIL: the orphaned DS record that broke 15% of lookups

A CI pipeline failing intermittently, two different error messages, an obvious suspect that had nothing to do with it, and an invisible cause: a DNSSEC record still published at the parent while the zone was no longer signed. Post-mortem of a nasty DNS failure, with the method that finally settled it.

dnssecdns
Infrastructure

Patching 36 servers without unattended-upgrades

There are three doctrines: do nothing, automate everything blindly, or look first and then decide. We removed unattended-upgrades from the whole fleet and dismantled our own automatic patching with Ansible, in favour of a “visibility first” doctrine backed by PatchMon. Why, how, and the routine that goes with it.

patch managementpatchmon
Infrastructure

Post-mortem of an NVMe failure: the dead capacitors that slowed everything down

For two and a half months, a hypervisor piled up replication timeouts without any disk being “dead”. The culprit: the Power Loss Protection capacitors of an NVMe drive, which had failed silently. A full post-mortem: from the symptom to smartctl, from the OVH replacement to the resilver that uncovered 20,000 latent errors.

nvmeplp

What next

Infrastructure that is managed and monitored day and night?

Bastion, SIEM, patches applied on purpose, tested backups: what we apply for our clients. First conversation free.

Discuss your project

Reply within 24 working hours, from one of the two founders. Or by phone: +33 7 59 96 14 99.