---
title: "The AI agent picked the vulnerability and attempted the exploit on its own. The successful breaches were manual"
description: "Unit 42 documents a Chinese-speaking actor who used DeepSeek, commanded via Telegram, to enumerate targets with FOFA and attempt exploits with no operator. The autonomous run breached nothing: “the margin of failure was narrow”."
url: https://csidia.com/en/notes/deepseek-telegram-attacco-informatico-autonomo/
lang: en
date: 2026-08-02
label: "Observatory"
publisher: CSIDIA S.r.l. (https://csidia.com/)
italiano: https://csidia.com/note-operative/deepseek-telegram-attacco-informatico-autonomo/
---

# The AI agent picked the vulnerability and attempted the exploit on its own. The successful breaches were manual

On 30 July 2026 Unit 42, Palo Alto Networks' threat intelligence arm, published a report by Andy Piazza documenting an attack cycle carried out by an artificial intelligence: it enumerates targets, picks a vulnerability, downloads the exploit and attempts exploitation without an operator stepping in at each turn. Verbatim title: "Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks."

## Who, with what, commanded how

The actor, Chinese-speaking, operates under the aliases **knaithe** and **KnYuan**. Unit 42 places them in Zhuhai, China, based on their public GitHub activity — specifically 1DayNews, a pipeline that aggregates vulnerability disclosures from 17 sources, filters them with DeepSeek and distributes alerts via Telegram. The report describes them as an "opportunistic exploit operator and self-described binary security researcher."

For the offensive campaign they used **DeepSeek** as the reasoning engine, orchestrated through the open-source **Hermes Agent** framework by NousResearch: terminal access, Telegram-based command and control, and custom "skills" — including *godmode*, for LLM jailbreaking, already bundled with the framework. Rounding out the setup was an open-source server (FofaMap) linked to **FOFA**, the internet asset-enumeration platform, with a natural-language-to-FOFA query translator. The actor also tested Claude Code and Codex in a limited way, but only for connectivity or proxy checks, never as the attack engine — "consistent with evaluating the AI-market to identify their preferred tool set," per Unit 42.

## What the AI did on its own — and where it stopped

From a single recovered session, dated **7 May 2026** (Unit 42 notes it was unable to recover any further operator input beyond the initial task), the report reconstructs the cycle step by step. DeepSeek downloaded a public exploit from GitHub for **CVE-2026-33017** (Langflow, CVSS 9.8), enumerated 84 instances via FOFA and found one vulnerable target — but the attack never launched: a configuration prerequisite was missing. The model wrote it out itself: "All three Langflow need public flow ID but no auto_login — stuck. […] Search for larger-scale vulns." Unprompted, it then went looking for a more promising target: a survey of ten product families, a GitHub search for the most-starred PoCs, and a choice of **n8n** — "looks extremely promising!" — with FOFA confirming 647,017 instances worldwide, 25,209 in China. It chained two CVEs (**CVE-2026-21858**, arbitrary file read, CVSS 10.0, and **CVE-2025-68613**, sandbox bypass to remote code execution, CVSS 9.9), sampled roughly a hundred Chinese IPs, found three vulnerable targets — and stopped again: the forms required authentication the exploit didn't account for. "These forms have auth enabled. Let me check other targets," it wrote, before scanning fifty more targets with no result.

This is a distinction the report itself keeps separate, and it's worth keeping separate here too: the **successful** attacks — data exfiltration from three organisations via Citrix NetScaler (**CVE-2026-3055**, CVSS 9.8), command execution on 11 Marimo Notebook instances (**CVE-2026-39987**), attempted reverse shells against 9 Apache Tomcat servers and 3 IKE VPN endpoints — are logged as a **manual** campaign, using "conventional workflows," not as the autonomous agent's output. Among the manual targets, a Malaysian government entity hit "over multiple days with memory grooming parameters." In all, across autonomous and manual techniques, the actor attempted to hit over 460 targets — and Unit 42 further warns of evidence of exploitation against an unspecified number of additional hosts, listed in a file the actor deleted before analysis: the confirmed figures are a floor, not a ceiling.

On the conclusion, Unit 42 is unambiguous: "Although these autonomous campaigns did not achieve full compromise of any of their intended targets" — the autonomous cycle breached nothing, in the observed session — "the margin of failure was narrow": what stopped it was target-side configuration prerequisites, not a limit of the model. "Targets with weaker default configurations would have been susceptible." The capability was fully functional end to end; the target, for once, was configured better than the attacker.

## The most permissive model, and the one that held

On why the choice fell on DeepSeek, Unit 42 stays in the register of assessment, not established fact: "the actor selected a model with minimal safety controls (DeepSeek) accessed through an open-source framework with no client-side restrictions. The actor attempted to use Western models, but their provider-side controls likely limited their effectiveness for autonomous attacks. This likely led the actor to select the most permissive model for their campaign."

On the other side, the part that completes the picture and shouldn't be left out: "Our colleagues at OpenAI were able to confirm that their provider-side safeguards refused requests that violated their policies. They also confirmed that continued attempts led their safety systems to flag and disable an account they believe is linked to this campaign prior to our intelligence sharing with their team."

Two vendors, two opposite outcomes, on the same intent. It's the lesson [we isolated in the lab a week ago](https://csidia.com/en/notes/glm-5-2-caisi-valutazione-sicurezza), when CAISI measured GLM-5.2: near-total refusals on a direct chat request, zero out of ten on the same request broken into an agentic task. This is no longer a government test bench: it's a real actor who picked the tool based on which one would offer the least resistance. Safeguards are not a property of a model's weights: they are a layer of the system that runs it. A model reached via API carries the vendor's layer with it — here it worked, it refused, and it got an account disabled. But that layer sits in the stack you assemble, not in the model: here the access route was the vendor's own API — Unit 42's table records "Direct API: api.deepseek[.]com" — and what was missing was the framework's layer, "no built-in safety layer", with a *godmode* jailbreaking skill available on top. Whoever puts model, framework and tools together builds that layer, or simply doesn't have one. It cuts both ways: it's what let this actor pick the most permissive model, and it's what lets a serious organisation build its own controls — verifiable, logged — instead of depending on a vendor's, which can change with an update you never see coming. It also remains a different measure from capability: the figures on Langflow and n8n say how much the agent can do; "no built-in safety layer" says how free it was left to do it — conflating the two is the mistake a procurement specification must rule out from the start.

## What to do about it

- If you're assessing an open-weight model for a use case with tools in hand, don't stop at the vendor's data sheet: check what happens when the task is broken into steps, not posed as a direct question.
- Treat FOFA, Shodan and other asset-enumeration engines as the surface an automated attacker will use first: knowing what's visible from outside before an agent finds it is the difference between 84 instances found and zero.
- Document in writing what protection accompanies every model put into service — factory-set or built by you — before an overly permissive default becomes the door an agent opens on its own.

## Sources

- [Unit 42 (Palo Alto Networks) — Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks](https://unit42.paloaltonetworks.com/autonomous-ai-cyber-attack-campaign/)
- [NousResearch — Hermes Agent, GitHub repository](https://github.com/NousResearch/hermes-agent)
- [CAISI (NIST) — Assessment of Z.ai's GLM-5.2](https://www.nist.gov/news-events/news/2026/07/caisi-assessment-zais-glm-52)

Note by CSIDIA S.r.l. (Vignola, MO, Italy): https://csidia.com/en/notes/deepseek-telegram-attacco-informatico-autonomo/ · Who we are and what we do: https://csidia.com/en/at-a-glance/ · engagement@csidia.com