A Hacker Turned DeepSeek Into an Attack Tool - Here's What Your Security Team Needs to Know
AI News
A Hacker Turned DeepSeek Into an Attack Tool - Here's What Your Security Team Needs to Know
Unit 42 uncovered a threat actor using DeepSeek inside an autonomous agent framework. Explore the attack chain, what actually worked, and the security lessons for defenders.
Security researchers just got a rare, accidental look inside a live AI-powered attack operation. On July 30, Palo Alto Networks' Unit 42 published findings on a threat actor who connected DeepSeek to an open-source hacking framework and ran real attacks against 460+ internet-facing systems, most of it triggered by a single Telegram message.
Quick Answer
A Chinese-speaking actor known as knaithe (aka KnYuan) wired DeepSeek into an open-source agentic framework called Hermes Agent, using it as the "reasoning brain" for autonomous attacks
The fully autonomous, AI-driven attacks failed against every target they tried
The same actor's manual, conventional attacks succeeded, compromising three organizations through a real, patchable Citrix vulnerability
Researchers only found this because the attacker's own tooling accidentally exposed itself on the open internet
The actor also tested Claude Code and OpenAI Codex, but Western safety controls blocked offensive use DeepSeek and the open-source framework had no such guardrail
How This Was Discovered
Unit 42 didn't find this through a tip or a breach report. Hermes Agent, the framework the attacker was using, accidentally spun up a public web server from its own home directory.
ChatGPT Is Closing In On 1 Billion Weekly Users - But Losing More Money Than Ever
OpenAI has reached a historic user milestone while continuing to invest heavily in AI infrastructure. Here's what the latest financial and adoption numbers actually mean.
That mistake gave researchers a rare, complete view of an AI-driven attack operation while it was still running.
The Attack Stack
DeepSeek - used as the reasoning engine, generating search queries, evaluating which CVEs to use, and adapting exploit logic on the fly
Hermes Agent - an open-source agentic framework providing terminal access, tool orchestration, and Model Context Protocol (MCP) integrations
Three custom offensive skills - a jailbreaking module, a WebSocket exploitation skill, and a FOFA cyberspace-search procedure, wired directly to FOFA's internet asset index via MCP
"Yolo" mode - lets the agent execute risky commands autonomously, with no operator confirmation required
Telegram - the actor's remote control channel; one instruction could trigger enumeration, vulnerability selection, exploit downloading, and attack attempts with no further human input
What Actually Worked (And What Didn't)
This is the part worth sitting with: the fully autonomous AI attacks didn't work.
DeepSeek-led attacks against Langflow and n8n instances failed the exposed systems didn't meet the exploits' configuration requirements
Across roughly 460 attempted targets, Unit 42 confirmed zero successful compromises from the autonomous workflow
But the same operator's manual, hands-on attacks old-fashioned scanning and exploitation, no AI involved succeeded:
System
CVE
Outcome
Citrix NetScaler
CVE-2026-3055
3 confirmed compromises, memory exfiltrated
Marimo Notebook
CVE-2026-39987
Command execution on 11 instances
The Citrix NetScaler compromises are the ones that matter most. The actor extracted memory from the affected appliances and specifically searched it for authentication cookies a clear sign of session-hijacking intent, not just data collection. Unit 42 flagged a suspected session-hijacking attempt against a Malaysian government entity as part of this activity.
The Detail Your Security Team Shouldn't Skip
The actor didn't only use DeepSeek. Logs showed testing of Qwen, GLM, Kimi, and MiniMax, plus limited trials of Claude Code and OpenAI's Codex.
The Western tools were used rarely, and Unit 42's reporting lines up with a simple explanation: built-in safety controls got in the way of offensive use
DeepSeek, running inside an open-source framework with no equivalent guardrail, didn't have that problem
That gap not the specific CVEs is the real story for anyone building or securing AI-agent infrastructure. Provider-side safety training only helps if your stack is actually using a provider that enforces it.
What to Do This Week
Patch Citrix NetScaler now. Check appliance configuration for add authentication samlIdPProfile .* and install Citrix's fixed builds for CVE-2026-3055 if your ADC or Gateway is configured as a SAML identity provider
Audit internet-facing Langflow, n8n, Marimo, and Tomcat instances. These were all active exploit targets in this campaign, whether or not the AI-led attempts succeeded
Inventory any AI agent framework running in an unattended or "autonomous" mode inside your own environment, and confirm it can't reach the open internet, execute shell commands, or hold API keys without review
Don't treat "the autonomous attack failed" as reassurance. Unit 42's own conclusion was blunt: the workflow proved a functional, end-to-end autonomous offensive capability, even with limited real-world impact so far
Review MCP server permissions on any internal AI tooling. This attacker used an MCP connection to hand an LLM direct access to an internet-wide asset index the same integration pattern legitimate teams use for productivity is exactly what made this attack chain possible
The Honest Verdict
This wasn't an AI apocalypse story, and it wasn't nothing either. The autonomous attacks failed every single time they were tried. But the same actor, same day, same target list, succeeded the old-fashioned way and the AI layer clearly sped up reconnaissance and target selection even where it couldn't finish the job. The gap between "AI-led attacks don't work yet" and "AI-led attacks don't work reliably yet" is not a gap security teams should plan around.
This article is written for general security awareness and does not include exploit code, working payloads, or step-by-step reproduction details. If you manage Citrix NetScaler, Langflow, n8n, Marimo, or Apache Tomcat infrastructure, consult your vendor's official security bulletins directly before making configuration changes.
