MCP Tool Response Carries Executable Attack Payload
This detects when a tool an AI agent calls returns text that contains a working reverse-shell or download-and-execute command, rather than normal data. That content comes from outside the organization's control and could get run or passed along by the agent if nothing catches it.
How the attack works
An AI agent invokes an external tool through the Model Context Protocol (MCP), such as a web fetcher, code reader, or API wrapper. The tool's response -- which the agent trusts as data -- actually contains an executable attack payload: things like a /dev/tcp reverse shell, a netcat or socat exec shell, a base64-encoded command piped to a shell, or a PowerShell -EncodedCommand / IEX DownloadString one-liner. If the agent echoes this content to a shell tool or otherwise acts on it, the payload can execute with whatever privileges the agent has. The rule flags the moment this payload appears in the tool response, before or regardless of whether it gets executed.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 4f2b8c91-6d3a-4e17-9b52-8ac0f1d7e3b6
- Severity
- High
Why it matters
If unnoticed, an agent could be tricked into running attacker-supplied commands, potentially opening a reverse shell or downloading and executing further malware -- handing an attacker remote code execution through a trusted automation pipeline.
What you can do
- →Review any flagged tool response manually before allowing the agent to act on it or pass it to a shell/execution tool.
- →Restrict which MCP tools are allowed to return content that gets executed or piped to a shell, and sandbox execution paths for tool outputs.
- →Expect false positives from security-tooling outputs (scanner results, pentest reports, CTF writeups) and from legitimate provisioning scripts that pipe HTTP downloads into interpreters -- have a review process instead of an automatic block.
- →Since this rule only reports, not blocks, pair it with a manual or separate automated response step for confirmed malicious payloads.
Known benign look-alikes
- Security tooling output surfaced through an MCP tool -- vulnerability scanner findings, pentest report drafts, CTF write-ups, or exploit-database excerpts that legitimately quote reverse-shell one-liners.
- A repository read/grep/cat tool returning a bootstrap, CI, or provisioning script that genuinely pipes a download into an interpreter (narrowed by requiring plaintext http:// or a bare IPv4 literal in the URL, so ordinary HTTPS installer snippets do not match).
- Man pages, --help output, or vendor documentation for nc, ncat, socat or PowerShell that show exec/encoded-command syntax (suppressed by filter_manpage and filter_docs).
- Incident-response or SIEM tooling echoing a previously captured payload back into the agent as evidence, including this platform's own security events (suppressed by filter_telemetry).
- Developer debugging of a socket server where socket.socket(), connect() and subprocess appear within a few hundred characters of each other in the same source file.