AI Cyberattacks: What Actually Changed

In June I wrote that AI attacks were keynote material rather than what shows up when I get the incident-response call. I still think the reasoning was right. The conclusion needs updating.

At the end of August, one attacker pointed hundreds of AI agents at print servers and broke into 395 organisations across 48 countries. Not a lab exercise and not a vendor demo. Real companies, real domain admin, documented afterwards in forensic detail by the threat intelligence firm GreyNoise.

Here is the part every headline this week has skipped. The attack itself was completely ordinary. Nothing in it would have surprised anyone doing this work five years ago. What was new was the clock.

What happened to 395 organisations#

The target was PaperCut NG/MF, print management software that sits on a server inside a lot of schools, universities and mid-sized companies. Two flaws were involved: CVE-2026-81578, an authentication bypass rated 8.8, and CVE-2026-82078, a critical 9.4 that allows arbitrary Java code to run through the database connection utilities. Chained, they let an unauthenticated stranger on the internet run code on the server.

The campaign began on 31 August. By the time GreyNoise published its analysis on 10 September, the operator had reached 440 PaperCut instances belonging to 395 distinct organisations. Education took the worst of it with 204 victims, which follows directly from what the software is - followed by retail, professional services and hospitality. The United States had the most victims at 98, then the United Kingdom, France, Spain and Canada.

The outcomes are worth separating, because "395 organisations breached" flattens a real difference:

280 organisations had credentials harvested.
147 had operating system or domain secrets taken.
12 were taken to full domain administrator.

Twelve out of 395 is a small conversion rate. It is also twelve organisations that lost their entire Windows estate to a machine.

The only number that matters: three days#

PaperCut published its security bulletin on 27 August. The first emergency patch shipped on 28 August, and a second one followed later the same day after researchers at watchTowr found ways around the first. On 31 August, both flaws went into CISA's Known Exploited Vulnerabilities catalogue.

31 August is also the day the campaign started.

So the window between "a fix exists" and "an automated campaign is working through everyone who has not applied it" was three days. Not three weeks, not a quarter. Three days, over a bank holiday weekend in the UK, for software that lives on a print server that nobody thinks about and no one is on call for.

That interval is the thing that actually changed, and it is worth being precise about why. The gap between a patch landing and mass exploitation has always existed because someone had to do the work: read the advisory, diff the patch, write a reliable exploit, build target lists, then grind through them. That work took a competent person days to weeks. It is now the sort of thing you can hand to a fleet of agents and go to bed.

What the AI actually did#

GreyNoise's timings are the most useful part of the report, because they are the part you cannot argue with.

From an empty workspace to the first working remote code execution against a real victim: under four hours. First domain admin came two hours after that.
Once the process was repeatable, the fastest jump from code execution to domain admin was five minutes. At one high school, initial access to domain admin took seven.
At one point, eleven organisations were compromised in twenty-six seconds.

The tooling behind it was not exotic either. The operator ran agents on OpenAI's Codex alongside a DeepSeek model, and generated target lists through Netlas, a commercial internet scanning service that anyone can sign up for. This was assembled from parts you can buy.

The agents were also not particularly well behaved. The operator maintained a list of 28 countries to stay away from, presumably for their own legal comfort, and the agents went outside it anyway. Read that however you like, but do not read it as machine intent. It is what happens when you delegate to something that does not understand why the rule exists.

What it didn't do#

This is where the hype and the evidence part company.

The AI did not write novel malware. Everything after the break-in was standard, years-old tooling that any penetration tester has on hand: Mimikatz, BloodHound, SharpHound, Rubeus, Certipy, Impacket. There was no self-modifying code, no new technique, nothing that required a fresh detection signature.

The AI did not find a new vulnerability either. It used two that had already been found, already been disclosed, and already been fixed.

And it did not beat security controls that were actually in place. GreyNoise notes that a Cloudflare web application firewall blocked one of the attempts outright. Ordinary, unglamorous controls still worked exactly as designed. What the AI removed was the human bottleneck between knowing about a flaw and exploiting it everywhere at once.

This is not a one-off, either. Anthropic published a 154-page threat report the same week covering December 2025 to August 2026, documenting more than 40 distinct threat groups using its models across a spectrum that runs from asking questions, through directed operations, to running with almost no human input. The PaperCut campaign is the clearest documented case, not the only one.

Why the patch made it easier#

Here is the uncomfortable bit, and the reason I think this story is being told backwards.

Exploitation of these flaws did not start after the patch. Huntress observed the first attempts on 26 August, a day before PaperCut's bulletin. That early activity was slow, careful and narrow: two customers, focused on system discovery, no follow-on malware. That is what a human working a zero-day looks like. It is expensive, so you spend it carefully.

The mass campaign only arrived after the fix was public. That is not a coincidence and it is not an argument against patching. A patch is a description of the bug. It always has been. What used to protect you was that turning that description into a working exploit and a target list was slow enough that most people got their updates applied first.

That assumption is now wrong, and it was load-bearing for a lot of patching policy. "We patch within 30 days" was a reasonable position written against a threat that took weeks to organise. Against this, a 30-day window is not a policy, it is a queue.

Note also that patching once was not enough here. The first emergency patch was bypassed and replaced the same day, and on 11 September PaperCut rolled everything into maintenance releases 26.0.5, 25.0.13 and 24.1.10. Anyone who applied the 28 August patch in the morning and stopped reading was not finished.

What to change if you don't have a security team#

None of what follows is new advice. It is the same advice with the deadline moved forward, which is the honest version of what this incident demands.

Know what of yours answers the public internet. Not the list from 2024. The current one, including the things installed by a department rather than by IT. You cannot patch an emergency in three days if finding the box takes two. This is the single highest-value thing on the list and most organisations cannot do it today.
Subscribe to advisories for your specific products. For every internet-facing application you run, find the vendor's security bulletin feed and put it somewhere a human reads. Waiting to hear about it from the news costs you most of the window.
Decide now who may patch out of hours, and how. The three-day clock started on a Thursday before a long weekend. Work out in advance who is allowed to take a print server down at 9pm on a Sunday without a meeting, because the meeting is the expensive part.
Check that the fix actually landed, and check again. The first patch here was bypassed within a day. Verify versions after the fact rather than trusting that the change ticket closed.
Keep the boring controls. A WAF blocked one of these attempts. Network segmentation would have limited what those twelve domain-admin compromises turned into. None of it is exciting and all of it still works.
Assume credentials on that box are gone. In 280 of these cases the outcome was harvested credentials. If a server of yours was exposed and unpatched during the window, rotate what was on it rather than waiting for proof it was used. The identity layer is where this becomes a real breach.

If you want to know which of these you would actually manage under time pressure, that is a question a test answers better than a policy document.

What this means if you're not a company#

Very little, and I would rather say that than invent a task for you.

Nothing in this campaign targeted consumers. Your laptop does not run PaperCut, and there is no setting to change tonight. If you take one thing from it, take the general shape rather than the specifics: the time between a security update appearing and it mattering has got shorter, on everything. When your phone, browser or computer offers you an update, the sensible response is now to take it rather than to defer it for a week. That is the whole consumer lesson, and it is a small one.

The other thing worth carrying away is a calibration point. When you next read that AI is producing unstoppable new cyberweapons, this is the best-documented case anyone has, and it was old tools moving quickly. That should make you more careful about patching and less impressed by the marketing.

Summary#

One operator used hundreds of AI agents to breach 395 organisations in 48 countries, reaching full domain admin at twelve of them. It is the best-documented AI-run campaign so far.
The window between patch and mass exploitation was three days. PaperCut fixed the flaws on 28 August; the campaign began on 31 August.
Nothing about the attack was novel. Mimikatz, BloodHound, Rubeus and Impacket did the work after the break-in, and both flaws were already public and fixed.
What AI removed was the human bottleneck between a patch being published and it being exploited everywhere at once. Empty workspace to working exploit took under four hours.
A patch is a description of the bug. It always has been. What protected you was that acting on that description used to be slow.
Know what of yours answers the internet, subscribe to vendor advisories for those products, and agree in advance who can patch out of hours.
Verify the fix landed. The first emergency patch was bypassed and replaced the same day.
Ordinary controls still worked. A web application firewall blocked one attempt. This is not an argument for new tooling; it is an argument for a shorter clock.
For individuals there is no action here beyond taking updates when they are offered rather than deferring them.

This is general threat guidance, not an assessment of your environment. The question this incident actually raises - whether you could find and patch every internet-facing system you own inside three days - is one an external surface review or penetration test answers properly, and most organisations are surprised by the answer. If you build software as well as run it, the same speed problem applies to your dependencies. See what we do, then get in touch. And if you want the wider picture of what is actually breaking companies right now, start here.