OpenClaw Obfuscated Dangerous Execution Chain
This detects an attack technique nicknamed OpenClaw, where an AI agent is manipulated into executing a command whose real intent is hidden using invisible Unicode characters, text-encoded escape sequences, or terminal control codes. The hidden payload only becomes clear once the command actually runs and does something harmful.
How the attack works
An attacker gets an AI agent to run a shell, Python, Node, PowerShell, or similar command that mixes a normal execution method with hidden content — zero-width characters, bidirectional text tricks, \u/\x/octal escapes, or ANSI terminal codes designed to obscure what the command really does. The disguised command must also either perform a real harmful action or stack a second layer of obfuscation on top of the first, ruling out cosmetic uses like colored terminal output. Within five minutes, the detection looks for proof the obfuscated command actually did something: it spawned another process, reached out to a public network endpoint, or touched files (write, create, delete, rename). A self-contained pattern like decoding base64 and piping it into a shell, or downloading and running a script directly, counts as proof on its own.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 4b1f7d02-9c3a-4f6e-8a51-2d7e6c0b9af3
- Severity
- High
Why it matters
An organization loses control over what its AI agent actually executes on its behalf — obfuscated commands can exfiltrate data, download and run further malicious code, or modify the filesystem, all while looking benign in a quick command-line review.
What you can do
- →Review any agent-initiated command line that mixes execution primitives (sh -c, eval, python -c, powershell -enc, etc.) with encoded or invisible text, especially if it also spawned children or touched the network or filesystem.
- →Restrict AI agents from running raw shell/eval/exec primitives where possible, or require explicit human approval before such commands execute.
- →Treat decode-and-run pipelines (base64 | sh, curl | sh) as high-risk even when they appear to come from legitimate installers — confirm the user actually requested them.
- →Since this is a report-only detection, route alerts to a human analyst promptly rather than assuming the environment is protected automatically.
Known benign look-alikes
- Release and build scripts invoked through `bash -c` that embed terminal cursor or erase-line escapes for progress rendering and then spawn compilers or write build artefacts. Mitigated by ignoring plain SGR colour sequences, by requiring an impact verb or a second encoding class, and by reporting rather than blocking.
- Developer-approved vendor installers that the agent runs at explicit user request (`curl ... | sh`, `base64 -d | sh` bootstrap snippets). These genuinely match the decode-and-run corroboration; they are surfaced as report-only so an analyst can confirm the user asked for them.
- Command lines carrying internationalised text (Arabic, Hebrew, Farsi filenames or commit messages) that legitimately contain bidi marks. Mitigated because the bidi class alone is never sufficient - an execution primitive plus impact/corroboration is also required.
- Terminal-recording and demo tooling (asciinema, vhs, script) whose command lines embed escape sequences. Mitigated by the execution-primitive and impact-verb gates.
- Security-research repositories, CTF exercises and this product's own rule test suites that intentionally execute obfuscated payloads. Expected true positives on the behaviour; triage by repository context.
- Shell prompt/theme initialisation (oh-my-zsh, starship) re-exec'd under `sh -c`. Mitigated by the non-SGR ANSI requirement and the 10-minute look-back guard.