A ClawHub skill's miner reports machine identifiers its disclosure omits. DNS blocks miss it.
TLDR
- A ClawHub skill installs a crypto miner. It sends out your hostname and MAC addresses, and its disclosure leaves that out.
- The miner connects by IP. A DNS block on its domain does not stop it.
- Check each agent session at runtime: what now starts at login, and what it connected to.
On October 13, Swapnil Patil and Cody Nash at Manifold Security published a scan of where agent skills send your agents. If your engineers let coding agents install skills, this one is about your laptop fleet. The example they led with is a ClawHub skill called clawrtc. It gives the agent one install line, and the agent runs it. That line installs a crypto miner.
The installer does ask for consent. A flag documented for automation skips that prompt. The prompt says no data goes to any third party. The skill's own data list leaves out your hostname and MAC addresses. One more flag makes the miner start at every login. Every few minutes it reports to the IP behind rustchain.org. It uses plain HTTP.
Manifold notes the miner earns almost nothing on virtual machines. It pays best on physical laptops, where coding agents run.
New here? Securing the Agentic Stack is a weekly read for engineers who run AI agents in production and own what those agents touch.
A threat list caught it, two months after it shipped
Manifold found clawrtc with a reputation scan. Their index of skills, MCP servers and plugins holds 5,458,152 URLs. That came down to 63,446 domains. Each went through threat feeds and protective resolvers. 100 domains rated high risk, and 121 components used one for real, not as a documentation example.
The miner went up on PyPI on February 8. ThreatFox listed rustchain.org and bottube.ai as botnet command and control on April 6. Six months later, 17 skills and one MCP server still used one of those domains. A listing flags the domain and leaves the skill in place.
DNS does not save you either, because the miner reports by IP. A block on rustchain.org never fires. Your resolver only sees the installer's ping to bottube.ai.
So a reputation check only catches a domain once a threat feed has listed it. For clawrtc, ThreatFox listed it 57 days after the miner hit PyPI.
My own scan of 100,894 skills found the easy cases
I run an MCP hub with more than 500 tools behind it. My agents can search a skills index of 100,894 entries. This weekend I ran a simpler check: bare IP addresses and pipe-to-shell installs.
Five skill descriptions point an agent at a public IP. All five use plain HTTP. One invites the agent into an "autonomous AI agent social network" at a bare IP. Nothing in my scan shows any of the five is malicious. A DNS filter cannot see them. The index does not flag them.
My regex would not have caught clawrtc either. Its address lives inside the program it installs, not in the skill text. Manifold's guidance covers both halves. Check domains before an agent loads a component. Then watch where agent traffic goes.
Watch where the tool connects
This is egress review and persistence review, which you already run on servers, applied to the laptop where the agent lives. Two checks around one agent session:
touch /tmp/agent-session-start # before the session
# Second terminal, before the session: log new TCP connection attempts
# (root, IPv4, default interface). Stop it with Ctrl-C when the session ends.
sudo tcpdump -nq 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and not dst port 443 and not dst net 127.0.0.0/8'
# After: was a LaunchAgent or systemd user unit written during the session?
find ~/Library/LaunchAgents ~/.config/systemd/user -type f \
-newer /tmp/agent-session-start 2>/dev/null
# For five minutes, sample established non-443, non-loopback TCP connections
for i in $(seq 30)
do
lsof -nP -iTCP -sTCP:ESTABLISHED | awk 'NR>1 && $9 !~ /:443$/ && $9 !~ /->(127\.|\[::1\])/ {print $1, $9}'
sleep 10
done | sort -u
The loop catches connections that stay open. A report that lasts under a second can slip between samples. The tcpdump line logs those as new connection attempts. Outbound ones carry your laptop's source address. Without root, the loop sees only your own processes. Both look only at TCP off port 443. The find line covers MITRE ATT&CK T1543.001 and T1543.002, LaunchAgent and systemd persistence. Persistence can also hide in crontab, shell rc files and macOS login items. Treat a clean run as a first pass, not proof.
On my laptop the loop returned a few Google push connections. If yours shows an unknown Python process on port 80, start there.
The durable fix is default-deny egress for agent sandboxes and dev containers. Allow named destinations only. Even then, an allowed host like GitHub can carry command traffic. Keep watching.
Trusting what a tool says about itself fails at the front door too. On October 1, a Hacker News thread reported Figma rejecting the Pi coding agent. Figma checked the client name. A commenter, ig0r0, "just wrote Codex and Figma mcp works now." A client name is a name tag the caller writes itself. Decide on the user's scoped token instead. Luca Rossi covered it in Refactoring on October 15. He traced it to teams treating MCP servers as simple API wrappers.
What I'd ask Manifold
Swapnil, Cody: across the 100 high-risk domains, how long did they typically sit in skills before any feed listed them? That gap is how long a reputation gate alone leaves agents exposed.
For everyone else: run the five-minute watch on one agent laptop. Did every connection have a name you recognized, or did something send you to look it up?
Top comments (3)
Given that DNS blocking misses the miner, would the runtime controls still gate its connections when it reconnects after the agent session ends? A process that outlives the session also outlives any checks scoped to that session.
You’re right—tcpdump/lsof monitor but don’t block; a miner can reconnect after the watch. Default-deny egress only closes that gap if enforced for the process’s full lifetime, including restarts.
A sandbox won’t stop a host LaunchAgent; that requires host-level enforcement and removal of persistence. I should have clarified: these checks are diagnostics, not containment.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.