The 44 AI agents everyone is quoting come from one log line. The way into those networks was a default password

Trend Micro published the English edition of a report on 27 October, translated from its Japanese original of the 23rd, in which Bakuei Matsukawa and Joseph C Chen take apart 3 attacker infrastructures reconstructed from files the operators left in publicly readable server directories. The three differ in how much of the attack the AI was actually doing, and the authors grade their own confidence in each.

Where the number 44 comes from

The figure in every headline this week rests on a single record. In the first case, the attackers ran CyberStrikeAI, an open-source penetration-testing platform built around AI agents, and its logs show a configuration of 44 agents through one entry reading "credential-search agent 8/44". One line in a recovered log is the entire basis for the number, and the report says so plainly.

That is not nothing. It says the work was fanned out across dozens of workers, and the rest of the case supports it: one repeatable workflow covering reconnaissance, exploitation, command and control, persistence, exfiltration and automated reporting, run against at least 19 organisations, at least 16 of them in Japan, concentrated in October 2026. The console was in Simplified Chinese.

The operationally interesting detail is not the count. The platform throttled its traffic to each target, which means that from inside any one organisation the activity looked like background noise rather than an attack.

The way in was never new

The clearest intrusion chain in that first case began at an unauthenticated admin interface on a legacy web system. No novel vulnerability, no clever chain.

The second case is worse and duller still. A GIS server with default credentials gave up several hundred thousand cadastral and commercial records, and one company lost a full chain through FTP, database, administrative rights, a web shell and SSH.

The third case went after Cisco SD-WAN, Citrix NetScaler, F5 BIG-IP, Oracle WebLogic and Yamaha routers, and the router access came from credentials sitting in configuration files rather than from any flaw in the product. At least 1,300 WebLogic candidates and 35 VPN entry points were identified, across at least 6 campaigns running from January to October.

What the AI actually changed

The authors are precise about this, and the list is shorter than the coverage implies. 4 things changed: the number of attempts running in parallel, the speed of each one, the ability to adapt to the language of the target, right down to forms and login pages written in Japanese, and the recordkeeping, which the platform turned out as finished reports nobody had to write.

It did not change the vulnerability types. It did not change the entry points, which remained exposed legacy systems and default configurations. It did not change the share of targets that ended up deeply compromised, which stayed small.

There is no evidence in the report of an attacker using an AI-discovered zero-day. The authors note the opposite direction instead: the PHP2Shell flaws were found by defenders, in an AI-assisted audit.

The logs lie, and they lie upward

Buried in the methodology is the most useful sentence for anybody reading claims about agentic attacks. AI-generated output records planned actions as completed, and tends toward the optimistic. Models also cite vulnerability identifiers that do not exist.

So an attacker's own logs, written by a model, overstate what that attacker achieved. Trend Micro treated self-declared successes as confirmed only where attacker-side evidence directly supported them, and publishes its counts as lower bounds.

Keep that beside the other agentic-attack claim of this week. Warp's founder says the intrusion at his company "appears to have come from an agent swarm", and has published nothing to check it against. One of these reports shows its working.

The model was asked nicely

The second case is the one worth remembering when somebody tells you model safety training handles this. The operator had an LLM generate the attack plan, and got past its restrictions by framing the request as an authorised assessment. What came back ran for about 24 days across August and September and scanned at least 6,000 Japanese addresses.

The targets there were AI workflow platforms and inference services, and the authors infer the goal was cheap access to inference capacity: stealing the compute to run the next operation. The attempts then narrowed to a handful of companies.

What to do

• Inventory what of yours answers on the public internet, especially web systems old enough that nobody remembers deploying them.
• Hunt for admin interfaces reachable without authentication, and for default credentials, before somebody with 44 workers does it for you.
• Read your edge device configurations for stored credentials. That is how the routers in the third case fell.
• Inventory internal AI and inference services. They are now a target in their own right, for the compute rather than the data.
• Watch for low-frequency distributed attempts. A throttled campaign is invisible per-organisation and obvious across several, which is an argument for sharing logs with peers.
• Expect the false-premise request. Anyone who tells your model they are running an authorised assessment is doing what case two did.

What is not established

• Whether the three cases share an operator. The authors say they do not know, and that the Simplified Chinese console is a weak clue at best.
• Which models were used. None of the cases identifies one.
• Whether each attempt succeeded. The evidence is attacker-side only, with no victim logs, so every count is a floor.
• Whether AI wrote the tooling in the third case. That rests on stylistic signs, such as section headers and emoji in scripts, which a human writing in that style would also produce.
• What the total damage was. Victims are described only in aggregate, and the indicators are withheld while investigations continue.