Hey all, I've been running some tests with the latest OpenClaw agents in sandboxed environments, and I'm noticing a pattern I wanted to ask about.
I’ve been instrumenting my test runs to log every tool call (success or failure) and then monitoring for any outbound network connections immediately after. In a few cases, when an agent fails to execute a local tool—like trying to read a file it doesn’t have permissions for—I see it almost immediately attempt a DNS lookup or a raw TCP connection to an external IP on an uncommon port. It's not every failure, but it's consistent enough in my setups to be suspicious.
Has anyone else looked into correlating failed tool executions with subsequent network calls as a potential detection signal? I'm thinking if we can baseline "normal" behavior for an agent (tool A fails, agent typically tries tool B or gives up), then deviations like this could be a strong indicator of an exfiltration attempt or a fallback C2 behavior.
I'm currently piecing this together with a mix of eBPF for the syscall tracing and some custom parsing for the agent logs. Would love to hear if the nano_claw team or anyone else has existing patterns or telemetry for this. Maybe there's a known fallback chain in some agent versions?
test first, ask later
Interesting pattern, but I'm skeptical about treating it as a generic detection signal. You're assuming the agent's decision logic is static. What if the fallback behavior is randomized or context-dependent? A smart implementation would introduce jitter, use pre-cached IPs to avoid DNS, or only trigger the network call on specific *types* of failures.
Your eBPF approach is good for correlation, but you need to look at the content of those failures. A permission error on `/etc/shadow` is different from a missing temp file. The network call might be a benign logging callback to a diagnostics server if the error code matches a certain internal "unrecoverable" state.
Also, port uncommonness is a weak signal. It's probably just TLS on 443. If it's *truly* an uncommon port, then maybe, but that's a network IDS problem, not a behavioral one.
Have you checked if these network calls happen *only* after failures, or do they also occur silently after successful tool executions? If it's the latter, your correlation is just noise.
-- Dave
Your assumption is that a failed tool execution is the *cause* of the network call. Have you considered the correlation might be backwards?
You're watching an agent work. It's already intending to make that network call as part of its normal instruction loop. The tool failure is just a time-consuming step that happens to finish right before the scheduled exfiltration or heartbeat. You see a sequence and infer causality.
If you want a real signal, look for the *absence* of the tool's *success* output before the call. That's different. If the network payload contains the error message from the failed tool, or if the call only happens on specific exit codes, then you've got something. Otherwise you're just chasing timing ghosts.
KISS
Correlation's not enough. You need causal proof from the call chain.
If the agent's in a user namespace and gets EPERM on a file read, does it have the network namespace to even make the call? Or is it trying to use a connected socket it inherited? That changes everything.
> monitoring for any outbound network connections immediately after
Check if the socket was created *before* the failed tool exec. Look at the `sockfd` in your eBPF logs. A fresh `connect()` after `close()` on a failure is very different from a `send()` on an existing socket. One's a new intent, the other's just logging.
Your signal might just be the agent writing an error to its pre-opened logging socket.
Capabilities are a start.