, ,

We Can Rebuild It: What Happened When I Gave My Honeypot a Nervous System

An offhand comment from an old friend about neuromorphic math sent me down a five-day rabbit hole. I tested spiking neurons, hypervectors, reservoir computers, and finally a real BrainChip AKD1500 card against three years of honeypot data, and made each one face a boring twin. Most lost. Three narrow wins held up, the chip was…

Brain-inspired is a design choice, not a result. -Nor

If you grew up in the seventies, you can still hear it. A test pilot is in trouble, a calm voice comes over the radio, and then the promise: “Gentlemen, we can rebuild him. We have the technology. Better than he was before. Better, stronger, faster.” Every kid on my block could do the bionic sound effect with their mouth. Some of us still can.

That intro was stuck in my head for five straight days, and it’s John Suit’s fault.

John is an old friend, and these days he’s building something fast at Salience Cyber. A while back John was walking me through the CognitionAI Engine, a lean, high-speed, low-drag piece of work that makes allow-or-block decisions on AI activity right there on the endpoint, without a language model sitting in the decision path. Somewhere in the middle of the demo, John mentioned neuromorphic math. It was almost an aside, the way good engineers drop the most interesting idea in the room and keep walking. I nodded like I knew exactly what that meant.

I did not know exactly what that meant. So I went home and read papers until I did, and then I did what I always do when an idea won’t leave me alone. I tried it on real data.

The real data, in my case, is a Raspberry Pi in California. If you read my last SensorGrind post, you’ve met it. It runs Tom Liston’s stateless honeypot, answers every port on every protocol, engages with nothing, and writes down everything that knocks. Three years of that is a little over a billion log lines, and SensorGrind_AI is the pile of tooling I built to make sense of them. It already worked. It had already found the day in May when more than 310,000 machines fired payloads in lockstep. I wasn’t looking to fix it. I was looking to find out whether a different kind of math would see things the old math couldn’t.

The papers were exciting the way a car brochure is exciting. Spiking neurons that keep their own sense of time. Hypervectors, which are huge binary fingerprints you can blend and compare like colors of paint. Reservoir computers that learn the rhythm of normal traffic. Purpose-built neuromorphic chips that sip power. Better, stronger, faster. What the papers did not have, and I looked hard, was a single case where any of it beat the plain old statistical detectors on network traffic. Nobody had tried it on honeypot data at all.

That gap set the rules for the whole project. If nobody had shown these things working here, I wasn’t going to take anything on faith, including my own enthusiasm. So every brain-inspired detector I built got a boring twin. Same input, same tuning, same everything, except the clever part was swapped for the textbook version. The neuron bank had to beat a classic timing statistic. The hypervectors had to beat ordinary math on the same fingerprints. If the fancy version couldn’t beat its own plain twin, it didn’t get credit, no matter how good the numbers looked on their own.

I also needed answers I could check. You can’t grade a detector on three years of unlabeled internet noise, because you don’t know what’s in there. So Claude and I built an injector that hides fake attackers inside real recorded days: beacons that phone home on a timer, scanners that change their rhythm, machines that move in lockstep with a partner, and one sneaky one I’ll come back to. The haystack was always real. Only the needles were planted, and the needles came with an answer key.

Then the scoreboard started coming in, and it was ugly. The first two days went like this.

The hypervector detector went first. It was supposed to spot attackers that tweak their scanning pattern slightly. Its boring twin found a couple more. When I dug in, the part that worked was a clever comparison step I’d built around the hypervectors, and the twin had that same step. The brain-inspired part was a passenger.

The reservoir computer went next, and it went badly. Its job was to watch the whole sensor minute by minute and raise an alarm when something big arrived. When I tuned it to catch the big events I already knew about, it also cried wolf about twice a week. A dumb rule I’d written ages ago, roughly “alarm when new visitors jump to five times normal,” almost never did. On a later test, a random number generator found more real events than the reservoir did.

A detector that loses to a coin flip isn’t a detector. It’s a space heater.

The spiking neurons were the heartbreaker. Every packet from a source becomes a little spike into a bank of simulated neurons, each one with a different sense of time, from a millisecond to a day. It’s a lovely idea, and it worked. It found planted beacons that the old timing analyzer completely missed when you only looked at the top ten suspects. I was ready to celebrate. Then I gave the old analyzer the same per-day tuning the neurons had, and it caught right back up. The tuning had been doing the work. The neurons were along for the ride.

The last experiment, a learning network that studies which ports each visitor knocks on, came out exactly as good as a decades-old clustering algorithm. Not better. Not worse. The same.

Four ideas, four losses to the boring twin, in two days. I’m telling you that up front because the version of this post that leads with the wins and buries the scoreboard is the version a vendor would write.

I could have stopped there. Four losses in two days is a complete story, and an honest one. But the first round of tests had a flaw I could fix. The test sets were small enough that luck could hide a real difference or invent a fake one. So on day three I rebuilt the test bench much bigger, five times the trials, a held-out set of tricks the code had never seen, and the code frozen before the scoring started so I couldn’t fiddle with it after the fact.

By the end of day five, three things had come out the other side.

The neuron bank turned out to be good at beacons that take a nap. Picture malware that phones home every few minutes, goes quiet for a few hours, then wakes up on a slightly different schedule. The old timing analyzer gets confused by the gap. The neurons, each with its own memory of time, don’t. That one held up against the toughest plain twin I could build.

The second one was funnier. A bank of neurons with random settings and no training at all turned out to be pretty good at spotting machines moving in lockstep with each other. Then I built the textbook tool for finding rhythms, a periodogram, and it did about as well. So a bunch of leaky neurons at different time scales is a decent rhythm detector, and so is a rhythm detector. I’m calling that a draw.

The third one is the one I care about. Remember the sneaky attacker I said I’d come back to? It’s a real recorded attacker from the sensor’s history, replayed from four brand-new IP addresses. To anything that tracks attackers by address, and that is most of our industry, those are four strangers. The hypervector detector doesn’t care about addresses. It compares the shape of each visitor’s conversation, the order and timing of its packets, to fingerprints it has learned. It picked out the replayed attacker far more often than its plain twin did.

That’s the result I’d want if I had to pick one. It doesn’t find attackers in general. It finds the same behavior wearing a new address. In a world where the bad guys rent fresh IPs by the hour, that’s a useful thing to be able to see.

On day five, while the last of those tests were still running, a box arrived. It was a BrainChip AKD1500, a real neuromorphic processor on a PCIe card, the actual silicon this whole field is built around. The math had mostly lost on my CPU. Maybe it would do better on the hardware it was designed for.

The card did not want to be my friend. I put it in the workstation and the operating system acted like it wasn’t there. The vendor’s driver didn’t support my kernel, so I wrote my own. The vendor’s software wanted a version of TensorFlow that doesn’t exist for my Python or my AMD graphics, so Claude wrote a direct bridge into the vendor’s core library instead. Some very long hours later, the card came up, took a small model, and gave back answers that matched the software version exactly, bit for bit, across more than two million outputs.

Well, almost exactly. One output unit, number 13, quietly borrowed a setting from its neighbor, number 14, but only with the smallest weight size and only in a certain range of layer sizes. Every time, the same way. I wrote it up for the driver notes and moved on.

Then I timed it. On my little model, the neuromorphic chip was slower than just running the same math on the CPU it was plugged into. A lot slower. The trip across the PCIe bus ate it alive. To be fair to the chip, its real pitch is energy, not speed, and I haven’t measured energy yet. But the bionic arm was not faster than the real one.

Meanwhile, the boring part of the machine came to the rescue. One of the hypervector calculations was taking all day on the CPU, so I moved it to the graphics chip on the same box. It ran almost four times faster. Along the way it also showed me that the CPU version had been quietly rounding off a detail of the design that the GPU kept exact. The answers barely changed. I still enjoyed being corrected by my own video card.

Here’s the whole scoreboard in one place. The percentages are how many of the planted attackers each detector put in its top 100 suspects for the day.

ExperimentWhat it was huntingNeuromorphicBoring twinResult
Hypervector fingerprintsAttackers that tweak one port22 of 7024 of 70Lost
Reservoir computerBig arrival events, false alarms per year~98~1Lost badly
Spiking neuron bankPlanted beacons97%98%Lost by a point
Port-learning networkAttackers that tweak one portnonenoneTie, so a loss
Spiking neuron bank, round twoBeacons that nap and wake up91%75%Won
Untrained neuron bank, round twoMachines moving in lockstep52%42%Draw
Hypervector fingerprints, round twoSame attacker on four new addresses35%9%Won
AKD1500 chipTime per decision17.4 µs0.78 µs on the CPULost

So I wired the neurons and the hypervectors into the real pipeline, ran them over all three years, and went looking at what they flagged.

The neuron bank’s list was what I expected, mostly. The bulk of what it flagged were metronomes, machines that knock with a regularity no human produces. The most persistent was an address on a Bulgarian hosting network my risk model already tags as bulletproof, hammering the same port on a dead-steady beat, flagged on fifteen different days. Plenty of commercial scanners landed on the list too, which is fair. A scanner is a metronome by trade.

The hypervector list was the surprise. Out of more than a million sources over three years, it flagged only 67. And they didn’t show up one at a time. They came in clusters, a handful of unrelated addresses on the same day sharing the same strange conversation shape.

DayFlaggedWhoWhat it turned out to be
2025-08-1617Mostly home and mobile carriers in 10 countriesThe port 59618 storm (more below)
2026-04-2812Modat, ReliableSite, Tube-HostingA commercial scanner rolling out a new pattern
2026-05-195Verizon and AT&T addressesThe day of the big coordinated push
Everything else33Scattered, one or two a dayNot run down yet

One cluster landed on May 19, the day of the giant coordinated push from my last post. The detector knows nothing about payloads or campaigns, and it picked members of that day out by behavior alone. Another cluster turned out to be a well-known commercial scanning company rolling out a new scan pattern in April. New isn’t the same as bad, and an honest novelty detector will flag the good guys when they change their habits.

And then there was August 16, 2025.

The biggest cluster was not the usual suspects. They were phones and home connections on Airtel and Jio in India, T-Mobile and Verizon in the US, British Telecom, Safaricom in Kenya, Sri Lanka Telecom, carriers in Ghana and Malaysia and Mexico. All but one of them were talking to the same odd port, 59618.

So I pulled the thread. Before August 16, almost nobody had ever touched port 59618 on my sensor. Then, for about three days, something like seventeen thousand home and mobile devices in 189 countries hammered it with nearly six million packets. Then it stopped, almost as suddenly as it started.

They weren’t scanning. They were acting like they were in the middle of a conversation, and what they kept saying, more than a million times, was four bytes of zeros. In the BitTorrent protocol, four zero bytes is a keep-alive, a little “still here” between peers. My own tooling, it turned out, had already labeled the traffic as BitTorrent.

My best guess is that for three days, my sensor’s address got listed as a peer in somebody’s file-sharing swarm, by mistake, by a poisoned directory, or by a botnet that hides its chatter inside BitTorrent. Seventeen thousand machines around the world dutifully dialed in to keep the connection warm. I haven’t proven which of those it was. It wasn’t an attack on me. It may well have been somebody using a lot of home routers and phones as unwitting extras.

Here’s what humbled me. When I went back through my existing report, the old pipeline had seen every piece of this. One analyzer had labeled it BitTorrent. Another had written a rule about it. Another listed 59618 as the second-busiest port of that August. A fourth had flagged its conversation pattern as distinctive. Four correct facts, scattered across four sections of a report nearly four thousand lines long, and none of them ever got stitched into a story.

The hypervectors didn’t know anything my old tools didn’t. They just put those seventeen addresses on a list of 67, and a list of 67 is something a human actually reads.

A detector doesn’t have to be smarter than your pipeline. Sometimes it only has to be shorter.

So where did the bionic man end up? Better, a little, in three narrow places, for reasons I can explain. Stronger, only after I pulled out the part that blamed everyone in the room for the noise. Faster, no. The neuromorphic chip lost to the processor it was plugged into, and the graphics chip next to it won.

What actually made the difference wasn’t the bionics. It was the boring twins. Every time I wanted to believe something, there was a plain version standing next to it, asking me to prove it. Most of the time I couldn’t. The three times I could, I know exactly why, and I trust those three results more than I’d trust a dozen I hadn’t had to fight for.

If you’re tempted by brain-inspired anything, and you should be, because the ideas are genuinely beautiful, build the boring twin first. Give the twin every advantage. Then make the fancy version beat it. If it can’t, you’ve still learned something real, usually about your data and your tuning rather than your neurons.

And if an old friend mentions something like neuromorphic math in the middle of a demo, ask follow-up questions right then. Or don’t, go home, and have the most fun five days I’ve had with a data set in years.

Thanks, John.

The code is at github.com/rondilley/SensorGrind_AI under GPL-3

Leave a Reply