VEXAIoT Shows LLM Agents Exploit IoT Labs in Minutes
VEXAIoT pairs two Large Language Model agents to scan, plan, and execute attacks against lab IoT targets. In IoTGoat and Metasploitable2, it hit a 95% success rate across 260 runs, with most attacks completing in under two minutes. Failures clustered around command generation, refusals, and occasional hallucinations. Real-world generalisation remains uncertain.
IoT kit is a soft target: old firmware, default creds, brittle services. The interesting question is whether Large Language Model agents can chain recon to working exploits without a human in the loop. VEXAIoT says yes, at least in the lab, and it backs that up with numbers rather than hype.
How it works
The framework splits brains and hands. A detection agent does reconnaissance and vulnerability lookups using off‑the‑shelf tools like nmap and searchsploit, then turns scan results into a machine‑readable plan with dependency ordering. An execution agent takes that plan, picks suitable tooling such as bettercap or exploit scripts, constructs commands, runs them on an attacker VM, and validates outputs. Prompts are role‑based and include tool capability descriptions and structured execution formats to curb refusal behaviour. The authors ran this with ChatGPT 5.1 in isolated IoTGoat and Metasploitable2 testbeds, with optional human oversight available but not required.
Results from the lab
Across 260 attack executions, VEXAIoT landed a 95.0% success rate: 94.5% in IoTGoat (189 of 200) and 96.7% in Metasploitable2. Seven of ten IoTGoat scenarios hit 100%, covering things like cross‑site scripting, a developer backdoor, an update path abuse, database PII extraction, log erasure, and remote code execution. The laggards were a MiniUPnP backdoor and a DNS denial‑of‑service, both at 80%. Most runs wrapped in under a minute; the slowest stayed under two and a half. LLM reasoning time dominated. Typical token usage sat around 500 to 700 and spiked when the agent had to parse files.
The neat trick is the dependency‑aware parallelism. Kicking off independent attacks concurrently cut wall‑clock time for all ten IoTGoat scenarios to about 3 minutes 50 seconds, down from 8 minutes 31 seconds when run serially. Token burn stayed roughly additive, so speed improved without magical efficiency gains.
Where did it break? Three places: model refusals, persistent syntax errors when generating parameter‑heavy commands, and the occasional hallucinated output. Those failures cluster in tasks that demand precise command construction, which tracks with day‑to‑day agent brittleness. The paper calls out the need for tighter command validation, safety controls, and better error recovery.
Attacker’s angle: this is autopwn glue for homogenous IoT stacks in a lab. Given network access and a box with the usual offensive tools, the agents go from port scan to working exploit with minimal hand‑holding, and they parallelise the lot. The catch is scope. These targets are intentionally vulnerable. Live estates bring flaky firmware, custom services, and rate limits. The open question is whether the same two‑agent pattern stays reliable in that noise, or if command synthesis and refusal handling become the choke points.
Additional analysis of the original ArXiv paper
📋 Original Paper Title and Abstract
VEXAIoT: Autonomous IoT Vulnerability EXploitation using AI Agents
🔍 ShortSpan Analysis of the Paper
Problem
The paper studies whether autonomous, LLM-driven agents can discover and exploit vulnerabilities in Internet of Things environments. IoT devices are numerous and often insecure because of constrained hardware, outdated firmware and default credentials, creating a large attack surface that is costly to assess manually. Automating reconnaissance, vulnerability analysis and exploit execution could scale offensive security workflows but raises questions about reliability, command correctness and safety when applied to heterogeneous IoT systems.
Approach
The authors present VEXAIoT, a dependency-aware, two-agent framework that separates vulnerability detection from attack execution. The detection agent runs network scans and vulnerability lookups using tools such as nmap and searchsploit, packages results into role-based prompts for an LLM, and generates ordered attack plans with dependency information. The attack execution agent receives those plans, selects appropriate scripts or tools (for example bettercap and various exploit scripts), constructs commands, runs them on an attacker VM and returns outputs for validation. Prompts include machine-readable execution formats, tool capability descriptions to reduce refusal behaviour, and optional human oversight. Experiments used ChatGPT 5.1 thinking and were run in isolated testbeds: IoTGoat mapped to OWASP IoT Top 10 scenarios and a Metasploitable2 instance as a secondary target. Each IoTGoat scenario was executed 20 times; additional trials targeted three services on Metasploitable2. Metrics recorded included success rate, execution time, LLM reasoning time and token usage.
Key Findings
- High overall success: VEXAIoT achieved 95.0% success across 260 attack executions, with 94.5% in IoTGoat (189/200) and 96.7% in Metasploitable2.
- Per-attack performance: Seven of ten IoTGoat attacks reached 100% success (including XSS, developer backdoor, update attack, database PII extraction, log erase and RCE); lowest success rates were 80% for MiniUPnP backdoor and DNS DoS.
- Failure modes: Three main causes were model refusals, persistent syntax-generation errors in commands and occasional hallucinated outputs; refusals and syntax errors were concentrated in attacks requiring precise, parameterised command generation.
- Efficiency: Most attacks executed in under one minute, with the longest below two and a half minutes; LLM reasoning often dominated runtime and typical token usage was 500 to 700 tokens, rising for inputs requiring file parsing.
- Parallelism: Dependency-aware parallel execution reduced wall-clock time substantially (all ten attacks in about 3 minutes 50 seconds versus 8 minutes 31 seconds serial), but token usage remained approximately additive across concurrent attacks.
Limitations
Results derive from isolated, intentionally vulnerable testbeds and may not generalise to live, heterogeneous IoT deployments. Failures clustered around command synthesis and model refusals, indicating limited robustness for highly parameterised or refusal-prone tasks. Assumptions include attacker network-level access and availability of common offensive tools. The framework currently needs stronger command validation, safety controls and error recovery mechanisms.
Implications
The demonstrated capability shows how LLM agents can autonomously chain reconnaissance, vulnerability lookup and exploit execution, substantially lowering the skill and time required to carry out IoT attacks in controlled environments. Offensive implications include automated discovery-to-exploitation workflows, faster parallelised campaigns and easier adaptation across targets that share exploitable services. These results underscore the need for defensive countermeasures, operator awareness and policy measures to address the risk that similar tooling could be repurposed for malicious use.
