There is a category of security research that looks, from the outside, remarkably like doing nothing. You set something up. You make it look inviting. You wait. You read. You wait some more. It is called a honeynet, and I ran one for long enough that I came to regard it as one of the most instructive things I have ever done.

The setup was straightforward, as these things go. I had access to a network segment I could instrument fully, and I deployed an Oracle database server that was, on the surface, a plausible target: a real service, listening on the expected port, with a configuration that looked like a production system someone had forgotten to harden. It was not connected to anything real. It was connected to everything I needed to observe it.

Then I waited.

What honeynets teach you about attackers

The first thing you learn from a honeynet is how much automated activity there is. Within hours of the service appearing on the network, probes arrived. Not human probes — scripted ones, sweeping ranges, testing credentials, looking for known-bad configurations. The internet, it turns out, is continuously being scanned by things that are neither patient nor creative. They simply try everything they know, at scale, all the time.

The second thing you learn is how to distinguish automated activity from human attention. Automated scanners have tells: the timing is regular, the credential lists are familiar (admin/admin, oracle/oracle, the same hundred passwords in the same order), and they move on quickly if nothing immediately yields. Human attackers are different. The timing is irregular. They pause and think. They try things that suggest they have read the error messages. They adapt.

The Oracle instance attracted both. The automated noise was constant and easy to filter. The human activity, when it arrived, was genuinely interesting to observe.

The patience problem

Running a honeynet requires a specific kind of discipline that I had not fully appreciated before I tried it: you must not interfere. The temptation is enormous. You see something happening, you understand what it is, and every instinct says to respond — to block the attacker, to close the vulnerability they are probing, to do something. The entire point of the exercise is to observe, not to intervene, and that restraint is genuinely difficult to maintain.

I developed a habit during the honeynet period that I still use: writing down observations in the present tense, as they happened, before interpreting them. Not “an attacker is attempting to escalate privileges” but “a connection from this address has issued this sequence of queries in this order”. The interpretation comes later, when you have the full picture. The observation has to stay clean.

This habit — separating observation from interpretation — is one of the things the honeynet gave me that I have carried into every subsequent piece of research. When I am reading DTrace output or an Endpoint Security event stream, I write down what I see before I write down what I think it means. The two are related, but they are not the same thing, and conflating them is one of the most reliable ways to convince yourself of something that is not quite true.

What the Oracle logs said

Oracle's audit logging is, when properly configured, remarkably detailed. Every connection, every failed authentication, every query that touched a sensitive table. The honeynet was configured to log everything, and I read those logs carefully, over weeks, until the patterns became familiar.

What the logs revealed, over time, was less about any specific technique and more about the economy of attack. Most of the activity was opportunistic: automated tools looking for low-hanging fruit, moving on when they did not find it. The sustained, methodical activity — the kind that suggested a human being with a specific goal — was rarer, but when it appeared, it was illuminating. Not because the techniques were novel, but because of what the choices revealed about the attacker's model of what they had found.

They had a model. It was sometimes wrong. Reading the gap between their model and reality — visible in which queries they tried, in what order, with what apparent assumptions — was the most interesting part of the whole exercise.

What I took away

I eventually took the honeynet down, as you must eventually take all honeynets down: the data had stopped teaching me new things, and the operational overhead of maintaining it carefully was no longer justified by the return. But the habits it built have lasted.

Patience as a method. Observation before interpretation. The log as truth, the interpretation as hypothesis. The willingness to wait for something to reveal itself rather than trying to force the revelation. These are not exclusively honeynet skills. They are research skills, and the honeynet is an unusually good place to develop them because the stakes are low, the data is rich, and the temptation to interfere gives you something specific to practise resisting.

---