Five months in to running the honeypot v2. Total compromise events logged: 67. Total interesting captures (excluding script-kiddie noise and obvious automated probes): roughly 14. Three of the recent ones are worth writing about.
As always, sanitised — no source IPs, no specific exploit details that would help anyone reading this attack their own infrastructure, no identifying details of any other targets the attackers may have hit. The point is to write about patterns.
Capture A: the rotating attacker
This one ran from late March through early May. A single attacker — judging by command patterns and timing — compromised the honeypot, used it briefly, left, came back two weeks later, used it briefly again, left, and so on. Five distinct sessions over six weeks.
What they did each session:
Session 1: enumeration only. Standard sequence — w, last, ps, netstat, ls /home, cat /etc/passwd. About four minutes. Did not attempt persistence. Logged out cleanly. Same shape as Capture One in January.
Session 2 (one week later): re-enumerated. Specifically checked whether the configuration had changed since session 1. It had not (deliberately). They went slightly further this time — examined /var/log modification times, ran find / -newer /etc/passwd 2>/dev/null to look for recent changes, checked for security software. Apparently satisfied that the host was still useful. Did not deploy anything.
Session 3 (two weeks later): came back, ran a single short command that I deliberately misread for thirty seconds before identifying. They had typed the command in a slightly distinctive way — small but characteristic — that I had previously seen in their first session. The command was a check for whether their future presence would be visible. They ran a tiny test script to see if its execution showed up in standard tools. They were probing for monitoring.
Session 4 (one week after session 3): deployed a small, custom backdoor. Crucially, this was the first session where they did anything irreversible. The backdoor was a kernel module — tiny, around 100 lines of C compiled to about 4 KB — that hooked into the syscall table to hide a specific PID range from ps. The PID range was for a daemon they planned to install later. The kernel module was elegant; the deployment was surgical.
Session 5 (a week later, then no return): deployed the daemon. Started it. Confirmed it was hidden from ps. Set up a connect-back schedule to a host they controlled. Logged out. Did not return again, as far as the captures show.
The entire sequence took six weeks. Each session was short — ten minutes maximum, mostly under five. The total time-on-keyboard was probably under an hour. The deliberation was the dominant feature.
The lesson: this is what a careful attacker looks like. Multiple short sessions over weeks. Each session has a specific narrow purpose. Probing for monitoring before doing anything sensitive. Deploying capability gradually. The on-host artefacts at any single point in time look minor. The cumulative effect is full compromise of the host with persistent hidden access.
Detection of this pattern requires temporal analysis. Looking at any single session in isolation, you might not flag anything. Looking across weeks, the pattern of returning visits with consistent command-style is itself a signature.
For real defenders: this is where structured logs that span weeks, fed into a tool that looks for behavioural patterns rather than instantaneous signatures, becomes essential.
Capture B: the data-collector
Different attacker, different shape. They compromised the honeypot via a different vulnerability. After the standard enumeration, instead of trying to install anything, they spent two hours collecting data.
Specifically:
- Pulled the full
/etc/passwdand/etc/shadow(the latter is empty on the honeypot, but they did not know that; they rancaton it and got nothing useful). - Pulled the full home-directory listings.
- Read every file in
/home/*/. - Read every config file in
/etc/. - Pulled
/var/log/wtmp,/var/log/messages,/var/log/auth.log. - Tried to pull
/root/.bash_history, which was empty by my deliberate construction. - Read every file in
/var/spool/mail.
They then issued a single tar command bundling all of this and attempting to send it via nc (netcat) to a remote host. The netcat outbound was blocked at the firewall. They tried again with wget --post-file=/tmp/data.tar.gz, also blocked. Tried again with ftp, blocked.
After about ten minutes of trying outbound exfiltration paths, they cleared their tracks (deleted /tmp/data.tar.gz, modified bash history) and exited.
The lesson: data collection is its own attack phase. The attacker was not going to install anything; they were going to take what they could get and leave. The defensive measure that mattered was outbound filtering — even though the attacker had successfully read most of the host's data, they could not get it out. The breach was contained at the exfiltration layer rather than the access layer.
For real defenders: outbound filtering deserves the same attention as inbound filtering. Many defensive postures focus on preventing access; the structural argument is that access will eventually happen and the question is what the attacker can do with it. Outbound filtering is, in many cases, what determines the answer.
Capture C: the relay attempt
The most operationally interesting recent capture. An attacker compromised the honeypot and immediately tried to install software making the honeypot a relay — specifically, a SMTP relay that they could use to send spam through.
The sequence:
- Standard enumeration.
- Confirmed they had root.
- Installed a small SMTP daemon listening on port 25001 (unusual port choice, presumably to avoid detection by standard scans).
- Modified the local mail-transport configuration to relay through their custom daemon.
- Tried to send a test mail through the relay. The outbound SMTP was blocked at the firewall.
- Tried to bypass the firewall by sending via a protocol the firewall did not recognise. Blocked because all outbound is blocked except specifically allowed flows.
- Spent thirty minutes investigating why the relay was not working.
- Eventually concluded the network was the problem. Logged out without uninstalling the relay.
The interesting thing here is what they were trying to do. The honeypot was, from their perspective, an asset to be conscripted into a spam infrastructure. Not exfiltration, not surveillance, not a foothold for further attacks — commercial use of compromised hosts.
The lesson: the threat actor population has economic motives that are not all about espionage or destruction. A substantial fraction of compromise activity, on the available evidence, is about turning compromised hosts into resources for further commercial activity. Spam relays. Click-fraud nodes. Credential collectors. The economy of cybercrime is starting to be visible.
For defenders: this is a different threat model than "someone wants to steal our data". The honeypot is being attacked because it is a useful resource, not because of its specific contents. The defensive implications are mostly about being a less useful resource — reduce outbound capacity, reduce reusability of compromised state, reduce the value of any compromise to a commercial attacker.
A small note on the cumulative picture
Five months of captures have given me a reasonably consistent picture of the threat-actor population that hits a fresh public IP. Roughly:
- 60% are automated scripts and unsophisticated operators. Easy to detect, easy to defeat.
- 25% are moderately skilled — competent enumeration, reasonable attempts at deployment, give up when blocked.
- 12% are commercially motivated. Trying to install spam relays, credential harvesters, or similar. Generally not very technically sophisticated but persistent.
- 3% are genuinely capable. Multiple sessions, careful instrumentation, surgical deployment. Caught only by off-host analysis over weeks.
The defensive measures that work against the first three categories are mostly the basic disciplines I have been writing about for two years. The fourth category requires more — the structural off-host logging, the temporal pattern analysis, the discipline that does not depend on any single host's view.
For the next quarter, I am going to focus more of my own attention on the fourth-category attacks. They are rare but consequential, and the defensive discipline they require is genuinely different from the rest. The honeypot will, I expect, continue to be the highest-leverage source of intelligence.
More as the year develops.