The reminder I want to keep from this analysis is to check what the honeypot contributed before deciding what the traffic means. A count can be accurate as a database total and still be the wrong answer to the question I'm asking.
Dionaea made that concrete. Its connection table held 85,567 rows, but 9,244 were passive FTP listening records: sockets the sensor opened itself. Excluding those left approximately 76,300 connections. Calling the raw total attacker connections would have counted the sensor's own behavior as hostile activity.
Cowrie had a different version of the same trap. It accepted nearly any credential so interactions could progress to the payload stage. Its recorded login successes therefore reflected that configuration, not how successfully those credentials would compromise a normal host. The result needs the configuration beside it, not a dramatic success-rate headline.
Running was not the same as capturing
Mailoney was the uncomfortable example. The service was running, the port was listening and the session count was increasing. Yet all 517 sessions recorded a loopback source, and the credentials table had zero rows. The captured exchanges showed a banner and a timeout rather than authentication.
Those liveness checks answered whether the service was there. They did not establish useful source attribution or credential capture. For future me, the check needs to reach into the records: is the sensor retaining the evidence I expect to analyze? More sessions would not make that particular capture problem less important.
A missing column was not missing evidence
The SIP destination information was absent from the structured table. I initially treated it as unrecoverable, then recovered it from the raw bidirectional streams. The table stored methods and selected signaling metadata, but not the destinations.
That distinction is worth remembering. The structured view was incomplete for my question; the underlying capture was not. HTTP request paths also exposed cloud-metadata targeting that the JSON-body view had missed. Looking only at bodies had narrowed what I could see.
Before writing off a field, check the other retained evidence layers. That is a better next step than turning a schema limitation into a conclusion about the capture.
Plausible output still needed checking
My credential extraction paired lines and produced convincing-looking but reversed pairs. Proper JSON parsing changed the result. The mistake was in the extraction, not a surprising property of the traffic.
The apparent request-to-payload correlation also needed retracting. The relevant request records and captured samples did not establish the chain I had initially described. Related datasets were not enough to connect a particular request to a particular payload.
The useful habit here is to question the path from record to conclusion. What created this row? What did the configuration permit? Which fields did the extraction preserve? Which evidence layer did I leave out?
That is the note to come back to: check how the evidence was made before trusting the story it seems to tell.