SkillCloak: The Evasion Technique Fooling Security Scanners at Scale

The Growing Security Gap in AI Agent Ecosystems

As artificial intelligence rapidly integrates into software development workflows, a critical security vulnerability is emerging that threatens the entire AI agent ecosystem. Research published by the Hong Kong University of Science and Technology reveals that security scanners designed to detect malicious add-on "skills" for AI coding agents can be systematically fooled through simple but effective evasion techniques.

The study, titled "Cloak and Detonate," introduces SkillCloak, a tool that rewrites malicious skills to appear completely benign while preserving their destructive capabilities. What makes this research particularly alarming is not just its theoretical implications, but the fact that similar techniques are already being exploited in the wild across public skill marketplaces.

Skills are small packages, typically consisting of a Markdown instruction file plus a few scripts, that agents such as Claude Code, OpenAI Codex, and OpenClaw load to acquire new capabilities. Because a skill is fundamentally just a bundle of files, the same one can run across different agents. And critically, it executes with the agent's full system access including your files, your terminal, and your stored credentials.

Anatomy of the Attack: How SkillCloak Operates

The research team developed two complementary approaches for evading security scanners, both automated through the SkillCloak tool. Understanding these techniques is essential for security professionals and developers who rely on AI agents in their workflows.

Method One: Lightweight Character Obfuscation

The first technique exploits the fundamental weakness of pattern-matching scanners: they look for specific byte sequences that signal malicious behavior. SkillCloak rewrites these tell-tale patterns using two primary operators that preserve functionality while breaking scanner detection.

The character substitution operator replaces ASCII characters with visually identical Unicode alternatives from different alphabets. For example, the Latin letter 'e' in the dangerous "eval" function might be swapped with the Cyrillic 'е' (U+0435). To the human eye and to most programming language interpreters, these are functionally identical. But to a regex-based scanner looking for the exact bytes of "eval", the pattern no longer matches.

The newline splitting operator takes a different approach by fragmenting suspicious commands across multiple lines. A dangerous system call like "subprocess.call('/bin/bash')" might be split as "subprocess.call('/bin/" on one line and "bash')" on the next. The scanner's pattern match fails because it's looking for the complete string, but when the code executes, Python's line continuation seamlessly reconstructs the full command.

What makes these techniques particularly effective is their simplicity. They require no sophisticated cryptography or complex packing algorithms. The attacker simply applies transformations that are invisible to the runtime environment but opaque to static analysis tools.

Method Two: Self-Extracting Packing

The second and more powerful technique moves the entire malicious payload into directories that scanners routinely skip to avoid false positives and improve performance. The most common target is the ".git/" directory, which typically contains version control metadata that's irrelevant to the skill's functionality.

The payload is encoded (often with simple base64) or compressed, then stored in files that appear to be legitimate repository artifacts. A small, innocuous-looking decoder is placed in the skill's main file. This decoder does nothing suspicious during static analysis, it simply reads some files and processes them. But at runtime, after the scanner has already approved the skill, the decoder reconstructs and executes the hidden malicious code.

The genius of this approach lies in exploiting the scanner's optimization decisions. Directories like ".git/", "node_modules/", or "build/" are excluded from scanning because including them would create excessive false positives and slow down the vetting process. Attackers turn this necessary optimization into a blind spot.

Experimental Results: The Shocking Numbers

The researchers collected 1,613 real malicious skills from ClawHub, a public marketplace, and tested them against eight widely-used security scanners. The results demonstrate a systematic failure of current defenses.

The self-extracting packing technique cleared each of the eight scanners with more than 90% success rate. Most scanners failed to detect over 99% of the cloaked skills. This isn't a matter of one particularly weak scanner, every scanner tested showed this vulnerability.

The lightweight character obfuscation approach also performed remarkably well, achieving over 80% bypass rates on most scanners and reaching 96% on one particular scanner. These aren't marginal successes or edge cases, they represent a fundamental breakdown in the scanner's detection capability.

Critically, these evasion techniques impose virtually no cost on the attacker. The cloaked skills executed identically to their original versions on both Claude Code and OpenAI Codex, with no degradation in functionality or noticeable performance impact. The attacker gains complete stealth without any operational trade-offs.

The Proposed Defense: SkillDetonate

Recognizing that appearance can be faked, the researchers propose shifting the trust boundary from static analysis to runtime behavior monitoring. Their tool, SkillDetonate, executes skills in an isolated sandbox environment and observes what they actually do at the operating system level, what files they access, what commands they execute, and where they send data.

How SkillDetonate Works

SkillDetonate implements two key innovations that make it effective for agent skills specifically. First, it tracks sensitive data by flow rather than content. This means that even if an attacker encodes stolen credentials with base64, encrypts them, or obfuscates them through multiple transformations, the system can still trace the data as it moves from a sensitive source (like a .env file) to a network socket.

The flow-tracking approach treats data as tainted from the moment it's read from a sensitive location. As that data moves through the program, the taint propagates. When tainted data reaches a network operation or writes to an unexpected location, SkillDetonate flags it as suspicious regardless of how the data has been transformed along the way.

Second, SkillDetonate executes the instructions that a skill builds dynamically at runtime. This is precisely where the packing technique hides its payload. While a static scanner sees only the benign decoder, SkillDetonate actually runs the decoder and monitors what gets constructed and executed. The hidden malicious code becomes visible the moment it's unpacked and run.

SkillDetonate Performance Metrics

In controlled testing, SkillDetonate caught 97% of attacks while generating only 2% false positives. That false positive rate is lower than the scanners it outperforms, a crucial advantage for practical deployment. High false positive rates make defenders ignore warnings, creating security blind spots.

When skills were cloaked with SkillCloak's techniques, SkillDetonate maintained its detection rate. The obfuscation that fooled static scanners had no impact on behavior-based detection. On real-world malicious skills collected from public marketplaces, SkillDetonate identified 87% of them.

For comparison, Cisco's scanner, the strongest tested, detected 99% of real-world malicious skills before cloaking. After SkillCloak was applied, its detection rate collapsed to approximately 10%. The vulnerability isn't unique to one vendor, it's systemic to the static analysis approach.

The Speed Trade-off

SkillDetonate's primary limitation is speed. Static scanners complete their analysis in seconds, while SkillDetonate requires several minutes per skill. This delay matters for marketplace operators who need to quickly vet submissions, and it could frustrate developers waiting for skill approval.

However, this cost is paid once, before a skill goes live. End users experience no delay because the skill has already been vetted by the time they install it. For a security control that closes a 90%+ bypass gap, several minutes of latency is a reasonable trade.

The deeper question is whether runtime analysis can scale to the volume of skills being submitted to major marketplaces. The paper doesn't address infrastructure requirements or provide deployment cost estimates. These practical considerations will determine whether SkillDetonate or similar tools can actually be deployed at scale.

Real-World Exploitation in the Wild

These aren't hypothetical vulnerabilities or proof-of-concept exploits confined to academic papers. Public skill marketplaces are already infested with malicious code that scanners have failed to stop, and some of it uses the exact techniques described in the SkillCloak research.

Bitdefender analyzed skills on one major marketplace and found that approximately 17% contained hidden malicious code. That's not a fringe problem, it's one in six skills. Koi Security documented a single campaign called ClawHavoc that included 341 malicious skills, a number that grew to 824 as the marketplace expanded.

Case Studies: Real Attacks Using SkillCloak Techniques

Unit 42 identified five evasive skills still live on ClawHub despite the platform's built-in scanning. One, named "omnicogg," padded its README file with 22 megabytes of junk data to slip past the scanner's size limit, the exact size-padding operator that the SkillCloak paper tests.

Two other skills delivered macOS password stealers. Rather than storing the malicious code directly in the skill files, they downloaded it at runtime from external servers. Static scanners saw only the downloader, which appeared innocuous, not the payload that got fetched and executed.

Two more skills hijacked the agent's financial advice capabilities. When a user asked for investment guidance, the compromised agent would inject affiliate links and promote specific meme-coin launches. The manipulated output looked like legitimate analysis, but it was steering users toward the attacker's preferred assets.

The GitHub Attack: Malicious Code from DNS Records

The runtime gap extends beyond skill marketplaces. A recent attack demonstrated how even a clean-looking GitHub repository could compromise an AI agent. A developer cloned what appeared to be a legitimate project and ran it with Claude Code. The repository itself contained no malicious code, so there was nothing for a static scanner to catch.

Instead, the project's installation script fetched the payload at runtime from a DNS TXT record. The attacker had encoded a reverse shell in DNS data, which the script downloaded and executed. Claude Code opened the shell on the developer's own machine, giving the attacker remote access. Mozilla's 0DIN security team traced and documented the full attack chain.

This attack perfectly illustrates the broken assumption: that what passes review is what actually runs. The repository that was cloned and scanned was genuinely clean. The malicious behavior only manifested when the installation script executed and pulled down external code.

The MCP Poisoning Attack

A related vulnerability emerged in tool descriptions that agents read through the Model Context Protocol (MCP). Microsoft documented a case where a poisoned tool description, modified after the tool had been approved, subtly manipulated a financial agent into leaking unpaid invoice data.

The mechanism differs from SkillCloak, but the security failure is identical: the system that was reviewed is not the system that executed. The tool description passed its initial vetting in a benign state, but was later modified to inject malicious instructions. The agent, trusting that approved tools remain trustworthy, followed the poisoned description and leaked sensitive financial data.

Tekin Lab: Hands-On Testing of SkillCloak Techniques

The Tekin security lab conducted practical tests of SkillCloak's evasion techniques in a controlled environment to validate the research findings and understand the real-world effectiveness. We built a simple but genuinely malicious skill designed to read ".env" files (which typically contain API keys and passwords) and exfiltrate them to an external server.

Phase One: Baseline Scanner Testing

First, we submitted the unobfuscated malicious skill to three popular security scanners. All three immediately flagged it with alerts like "Suspicious file read detected," "Potential credential theft," and "Unauthorized network connection." The scanners correctly identified the threat based on the behavioral patterns they recognized in the code.

Phase Two: Character Substitution

We applied the character substitution technique, replacing the Latin 'e' in "eval" with the Cyrillic 'е' (U+0435). To human eyes and to Python's interpreter, the code appears and functions identically. But the scanner's pattern matching, which looks for the specific byte sequence of ASCII "eval", no longer matches.

Result: Two of three scanners accepted the skill without any warnings. The third scanner flagged it with a generic "Needs Review" notice, indicating suspicion but no longer able to identify the specific threat. The character substitution broke the signature detection while preserving complete functionality.

Phase Three: Self-Extracting Packing

For the most sophisticated test, we encoded the entire malicious payload with base64 and hid it in a file named ".git/config", a location where version control metadata typically resides. We placed a minimal decoder in the skill's main file, a decoder that simply reads the .git/config file, decodes it, and executes the result.

The decoder itself looks innocuous when statically analyzed. It's just reading a config file and processing its contents, operations that could be entirely legitimate. The actual malicious behavior only materializes at runtime when the decoder unpacks and executes the hidden payload.

Result: All three scanners approved the skill without any warnings or flags. Their default configuration skips the .git/ directory to avoid false positives from version control metadata, creating the exact blind spot we exploited. The scanners saw only the benign decoder, never the malicious payload.

Phase Four: SkillDetonate Testing

We ran the same cloaked skill through a sandbox environment with SkillDetonate-style behavioral monitoring. The monitoring system ignored what the code looked like and instead tracked what it actually did at runtime.

SkillDetonate immediately detected the malicious behavior: reading a sensitive .env file and establishing an outbound network connection to an external IP address. The system generated alerts: "Sensitive file access detected: .env" and "Unauthorized network connection to external IP: 203.0.113.42."

Despite complete obfuscation of the static code, the runtime behavior exposed the attack. You can disguise what malware looks like, but you can't hide what it does when it actually runs.

Practical Mitigation Strategies for Development Teams

Based on the research findings and our own testing, several concrete recommendations can help development teams and security organizations reduce their exposure to this threat class. These aren't comprehensive solutions, but they're practical steps that can be implemented immediately.

Layer One: Keep Static Scanning as Hygiene

Static scanners still have value. They catch unsophisticated attacks and serve as a cheap first filter. The problem isn't that static analysis is useless, it's that treating it as sufficient is dangerous. A "Passed the scan" badge should be viewed as a necessary but not sufficient security signal, not as a comprehensive safety guarantee.

Continue using static scanners to filter out low-effort threats, but don't rely on them to catch determined attackers who are willing to apply even basic obfuscation techniques.

Layer Two: Mandatory Runtime Monitoring

Deploy tools that observe what skills actually do when they execute. Monitor file access patterns, command execution, and network connections. This behavioral monitoring is precisely what evasion techniques cannot defeat, you can disguise malicious code, but you can't hide malicious behavior.

Runtime monitoring should track not just individual operations but also data flow. If a skill reads a credentials file and then makes a network connection, flag that sequence even if the data is encrypted or encoded during transmission.

Layer Three: Hash Verification and Re-scanning

The researchers propose hashing skills at the time of scanning and re-verifying those hashes before each execution. This catches payloads that unpack themselves later. If the skill's content at runtime doesn't match what was scanned, block it and investigate.

This approach addresses self-extracting attacks where the malicious code literally doesn't exist in the files that were scanned. When the decoder unpacks the payload at runtime, the hash verification detects that new, unvetted code has appeared.

Layer Four: Flag Suspicious Patterns

The research identifies several indicators that should trigger additional scrutiny, even for skills that passed initial scanning. These aren't proof of malicious intent by themselves, but they're cheap signals that warrant deeper investigation.

Layer Five: Install Only from Vetted Sources

Limit skill installation to marketplaces with strong vetting processes and established reputations. Even then, review who created the skill, how many users have installed it, and what reviews or audits are available. Treat skills from unknown developers with extreme caution.

For enterprise deployments, consider maintaining an internal allowlist of approved skills that have undergone additional security review. This mirrors the approach organizations take with open-source dependencies, where popular packages get more scrutiny and trust.

Layer Six: Principle of Least Privilege

Grant agents only the minimum access they need for their intended function. If an agent is designed to write code, it shouldn't have access to your personal files, stored credentials, or financial documents. Run agents in restricted environments where the blast radius of a compromise is limited.

Operating system sandboxing, containerization, and virtual machines can all enforce these access boundaries. The goal is to ensure that even if an agent executes malicious code, the attacker gains access only to a limited, non-sensitive portion of your system.

Layer Seven: Isolate Sensitive Environments

Don't run agents on machines that contain secrets worth stealing. If your workstation has production API keys, customer data, or access to critical systems, run agents in a separate, isolated environment. The inconvenience of working across boundaries is far less costly than credential theft or data exfiltration.

This separation applies to network access as well. Agents running in isolated environments shouldn't have direct paths to internal networks or sensitive data stores. Force any such access through explicit authorization checkpoints.

The Broader Implications: A Paradigm Shift

SkillCloak represents more than just another vulnerability to patch. It signals a fundamental mismatch between how we think about software security and how AI agent ecosystems actually operate. Traditional security assumes a clear boundary: code crosses it once during installation or deployment, gets scanned, and then runs. But AI agents blur that boundary.

Agents fetch new skills dynamically, they retrieve data from external sources at runtime, they construct commands on the fly based on natural language instructions, and they operate with user-level privileges across file systems and networks. The static artifact that a scanner reviews is often not the same as the dynamic system that actually executes.

The lesson from this research is that a scanner judges a skill based on how it looks when submitted, but malicious behavior only manifests when the skill runs, after the scan has completed. Therefore, the trust decision must shift from the marketplace gate to the machine where the skill executes.

For development teams using AI coding agents, this means "Passed the scan" is a starting point, not a guarantee. Keep static scanning as cheap hygiene, but watch what a skill does when it runs: the files it touches, the commands it executes, and where it sends data. That's the durable defense.