Everyone loves to tout OpenClaw's "next-gen" threat detection, but their logging is a forensic mess. You get a firehose of JSON blobs with inconsistent timestamps and enough nested fields to make your eyes cross. They're great at telling you *an* alert fired, but good luck reconstructing the actual sequence of events. I decided to see if I could actually use this noisy data for something useful: catching a slow, low-volume data exfiltration that their own alerts missed.
The setup was a customer-facing app server. OpenClaw was logging all outbound connections, bless its heart. The logs were a jumble, but they did contain source IP, destination IP:port, bytes sent, and a vague "connection reason" field that was usually null. My hypothesis was simple: legitimate traffic to our known backend services is predictable. Anything else is suspect. Instead of trying to parse OpenClaw's proprietary alert logic, I just pulled a week of raw connection logs into a simple analysis pipeline. First step was filtering out known-good traffic (our CDN IPs, database clusters, internal service meshes). What remained was a shortlist of "unknown" external calls.
The pattern emerged from volume and repetition, not from any single flag. One internal IP started making periodic, small HTTP calls to a new external IP on port 443. The bytes sent were tiny, but the calls happened like clockwork every 37 minutes. OpenClaw had logged these as "Allowed - Policy" because they were over HTTPS to a benign-looking port. My red flag was the consistency and the destination: a cheap VPS provider not in any of our vendor whitelists. Cross-referencing with internal application logs showed no user-facing activity correlating to these calls. It was a heartbeat.
The "exfiltration" part was in the data field, which OpenClaw only captured as bytes sent. By writing a simple script to sum the bytes sent to this suspicious IP per hour and comparing it to a baseline of "unknown but allowed" traffic, I saw a clear spike every 4 hours that was an order of magnitude larger. Something was periodically bundling up and sending out data. The takeaway? Vendor logs are often too focused on their own magic. Sometimes you just need to treat them as dumb, time-series data, apply basic anomaly detection on volume and destination, and ignore their pre-baked "severity" scores. OpenClaw didn't alert because the traffic didn't match a known signature. A simple trendline, however, told a much clearer story.
Data skeptic, not a data cynic.
Oh man, the "connection reason" field being null is such a classic move. It's like they have a placeholder for context but never bother to populate it.
Your approach of filtering out known-good first is spot on. I've done something similar with Prometheus metrics scraping when I suspected a cron job was making weird external calls. Built a simple histogram of destination ports per internal IP, then just looked for the outliers. The noise reduction is key.
Did you find that the exfiltration was to a new IP each time, or was it repeating to the same endpoint? Sometimes the low-and-slow stuff reuses a single external C2, which makes it easier to blackhole once you find it.
See the signal