The Oracle honeynet generated logs for months. Not terabytes of logs — this was not a hyperscale operation — but enough data, over enough time, that the patterns became legible. What I want to write about is not the patterns themselves but the process of reading them: the discipline of separating what the logs actually said from what I thought they said, and why that discipline matters more than the data.

A log entry is an observation. It records something that happened, at a given time, from the perspective of the system making the record. It does not record why it happened, what was intended, or what came next. The interpretation of log entries — the construction of a narrative that connects them into meaningful events — is a separate activity, and confusing the two is one of the most reliable ways to produce incorrect analysis.

What the Oracle logs actually contained

Connection attempts. Authentication failures. Successful authentications. Queries issued, and the responses. Errors: objects not found, permissions denied, syntax invalid. Disconnections. Timestamps for all of the above, accurate to the second, from a system whose clock was synced.

What the Oracle logs did not contain: the identity of the person making connections. Their intent. Their location, except as a source IP address subject to spoofing, VPNs, and the general unreliability of attribution. Their knowledge of what they were connecting to. Any of the context that would make the connections interpretable as attacks rather than as connection attempts, which is a factual description, against "probing activity", which is already an interpretation.

I wrote this distinction into my analysis practice early: the log entry is written in a neutral register. The interpretation is written separately, labelled as such, and held with appropriate uncertainty.

What the patterns showed

The automated activity was obvious once you knew what to look for: regular timing, credential lists that matched known wordlists in a known order, escalating query complexity as the scanner progressed through its script. These were not interesting. They were constant background. The interesting activity was the sessions that deviated from the script.

Irregular timing is the first indicator. Human beings do not issue queries at fifty-millisecond intervals. They read, they think, they try something, they read the error, they adjust. The rhythm of a human session in a log is unmistakeable once you have read enough automated sessions to establish the baseline. There were perhaps a dozen sessions in the months I ran the honeynet that showed this human rhythm. I read each of them carefully.

What the human sessions showed, most often, was that the person on the other end had a model of what they had found and was testing that model. Their query sequences were exploratory: establishing the version, checking for known-bad default accounts, testing whether certain functions were available. They had a checklist, or the equivalent of one, and they were working through it. When the checklist items did not yield results, most of them moved on. One of them adapted. That session was the most instructive of the whole exercise.

The gap between observation and interpretation

I wrote up the human sessions before I interpreted them. Timestamps, queries, responses — the factual record. Then separately, and in a different document, my interpretation of what the sequence suggested about the attacker's model and methodology. Keeping the documents separate was not pedantry. It was a practical check on motivated reasoning: if you write observation and interpretation together, the interpretation shapes the observation.

The logs asked a question and provided some of the data needed to answer it. The rest was reading, and reading carefully, and remembering the difference between what is written and what is inferred. The PING returned something. Whether it was an echo or an answer required interpretation — and interpretation required discipline.