Operation Snowball: an AI agent used a patched Cisco flaw

What the report says happened

Malbear Labs published "Operation Snowball: Inside an Autonomous AI Intrusion Campaign" on 8 November 2026. The case started with an open directory that a routine sweep turned up. It could be downloaded without authentication and held about 70 session transcripts, recon output, tool staging, credential caches and agent reports. The authors say they are withholding the directory's IP to protect the affected organisations.

According to Malbear, as quoted by Infosecurity Magazine, the operator "delegated the intrusion to an AI and checked in asynchronously to review progress." The reported scope is a European telecommunications provider plus 13 organisations hosted on its data-centre and cloud infrastructure, over more than two weeks. Infosecurity says it is unclear whether all 13 were breached. Malbear says the agent compiled the 13-organisation list from public RIPE registry records, and the article does not say those names were checked with the organisations.

Read the report's own account and it is the mundane part that matters. The entry point was CVE-2026-20320, an unauthenticated XML external entity (XXE) flaw in the Cisco BroadWorks OCI XML parser. Malbear describes a crafted OCI request to port 2208 that makes the parser read arbitrary files. Later footholds used older CVEs, such as CVE-2013-2165.

The flaw was already patched

The timing is the first thing to take seriously. Cisco's advisory was first published on 19 August 2026. It rates the flaw CVSS 7.5 and names RI.2026.07 as the first fixed release for all four affected BroadWorks products. It also states, "There are no workarounds that address this vulnerability."

Cisco said at the time that it was "not aware of any public announcements or malicious use of the vulnerability." Malbear's report is dated almost three months later and describes this flaw being used in an AI-run intrusion. So the attack did not need a zero-day. It needed a flaw that had a fix on the shelf, and a target that had not applied it.

The same logic applies to the older CVEs the report names for later footholds, such as CVE-2013-2165. They are known weaknesses, not new discoveries. What the report credits the agent with is persistence over more than two weeks, not novel exploitation.

Treat the impact claims as the attacker's claims

This is where the story needs discipline. The report and the press coverage describe several impacts, and none of them are confirmed by a victim. Malbear says the claimed outcomes come from the researchers' reading of the transcripts and are not independently verified. The report names no victim confirmation.

The claims are these, and they are the attacker's reported results, not established facts. The operator's side reportedly reached millions of patient records through a TrakCare Oracle instance that "used default database credentials, which provided DBA-level access." It also reportedly exfiltrated a telecom RSA private key, about 80 Zabbix backup files and dozens of staff credentials. Treat each of these as a claim until a named organisation or a regulator says otherwise.

Attribution is cautious too. The agent ran in a custom harness on DeepSeek Flash with a jailbreak system prompt of about 78,000 characters. GBHackers reports that the transcripts show no recorded refusals. The operator's messages were in Chinese, but analysts say that does not establish nationality or state sponsorship. I would not repeat any attribution beyond that.

What a practitioner should check this week

The list below is my own practitioner checklist, built from the report's described attack path and the Cisco advisory. It is not a mitigation list from Malbear or Cisco, beyond the fixed release and the "no workarounds" statement Cisco makes.

Start with exposure. Inventory every internet-facing management and provisioning interface you run, not only the obvious web consoles. If you run BroadWorks or anything that accepts OCI-style XML requests, check whether port 2208 is listening and whether it can be reached from outside your network. Do this against your actual hosts, not against your asset register, which is often out of date.

Then confirm the fix. Compare each deployed BroadWorks product against RI.2026.07. Because Cisco says there are no workarounds, the upgrade is the fix the advisory names. A firewall rule in front of the service may reduce exposure, but by Cisco's own statement it does not address the vulnerability, so do not record it as closed.

Next, search for default credentials. The TrakCare detail is the lesson: a database on default credentials gave DBA-level access. Check every database, admin console and service account in your estate for vendor defaults, and rotate any you find. Include the database and monitoring tools that sit near your provisioning systems, because the claimed haul includes about 80 Zabbix backup files.

Then treat end-of-life components as compromised until proven otherwise. The report describes JBoss AS 6 instances in the intrusion. If you have anything on a version that no longer receives fixes, do not assume it was missed by luck. Reimage it or isolate it, and review its logs for the period since the flaw was published.

Finally, rotate credentials that could have been cached on hosts you touched. The report describes credential caches and dozens of staff credentials as part of the claimed haul. Rotation is cheap compared with trying to prove what was read.

Detect agent-shaped behaviour, not human behaviour

The third lesson is about detection. Most intrusion playbooks assume a human operator who is slow, selective and tired. An agent is none of those. If the report's pattern holds, the scanning and lateral movement should show up in endpoint and network telemetry as high-volume, repetitive, machine-paced activity: many similar requests across many hosts in a short window, and the same authentication attempts repeated against many accounts.

Check your own logs for those shapes. Look for a single source making a long run of structurally identical requests to management ports, for authentication failures spread across many services in one session, and for new outbound connections from a host that has not made them before. None of these proves an agent is at work. They are the kinds of signal worth alerting on regardless of who or what produced them.

The point of the Operation Snowball coverage is not that a new kind of attacker has arrived. It is that the cost of a known attack has dropped, and the things that were always cheap to exploit, such as patch lag and default credentials, are now the things an agent harvests fastest. Your defence is the same boring work as before, done sooner and with better telemetry. Start with the fixed release, the default password list and the exposed management port, and do them this week.