Honeypot as a Service: catching the attacker on their first move
By Kike Gandia · Threats · 5 min read
An attacker who is already inside your network makes no noise. They use valid credentials they bought or stole, tools that came preinstalled on the system, and protocols your team looks at every day without a second thought. They run nothing an antivirus would recognize. That is why the useful question is not whether you could stop them, but how long it would take you to notice they are there.
The problem isn't detecting the attack; it's detecting it in time
The time an intruder stays in a network before being discovered (the dwell time) has been falling for years. The global median published by Mandiant in its M-Trends report is now around ten days, a far cry from the months it took a decade ago.
That figure is less reassuring than it looks, because a median hides exactly what matters. It has dropped mainly because ransomware gives itself away: it encrypts the files and leaves a note. Those intrusions are "detected" quickly by definition, and they drag the statistic down. The ones that do real damage (industrial espionage, persistent access, slow exfiltration) are precisely the ones nobody uncovers in ten days, because their goal is never to be uncovered at all.
And there is a more uncomfortable asymmetry: a sizable share of organizations do not find out on their own, but because someone outside tells them. A customer, a supplier, law enforcement, or the attacker themselves demanding a ransom.
The rule that turns a decoy into a reliable alarm
A honeypot is an asset placed there to be attacked: a server, a file share, a database, or simply a set of credentials that look real but grant access to nothing. The key is not the technology; it is the rule that comes with it.
That asset has no legitimate use. Nobody in your company has any reason to touch it. So any interaction with it is suspicious from the outset.
That inversion changes everything. An EDR or a SIEM has to decide whether an odd behavior is an attack or just John from accounting doing something odd on a Tuesday. A decoy does not have to decide anything: either nobody touches it, or somebody has.
It is worth being honest about the caveat, because this is where most homegrown deployments fall over: a badly placed decoy does generate noise. Vulnerability scanners sweep it, asset inventory agents discover it, the backup system tries to index it, and a curious administrator logs in to see what that unfamiliar machine is. None of that is an attack. The difference between an alarm you trust and one you end up muting lies in excluding those known sources before you switch the alert on, not afterward.
Why almost nobody maintains their own honeypots
Deploying one is easy. There are excellent open-source tools and you can stand one up in an afternoon. The hard part starts the next day, and it is the reason so many deception projects end up switched off and forgotten in a corner of the rack.
What has to be sustained over time
- The decoy has to stay believable: hostnames that fit your real naming convention, not a "honeypot-01" that gives the trap away in ten seconds.
- The decoy credentials have to rotate and have a usage history. An account created yesterday, with zero logins and a password that never expires, is the first thing an experienced attacker rules out.
- The banners and versions of the emulated services have to be kept up to date, because there are public scanners that fingerprint honeypots by their default signature.
- There has to be someone on the other end at three in the morning on a Sunday, because that is when it goes off.
That last point decides whether the project is worth anything. An extremely high-fidelity alarm that nobody looks at until Monday is not early detection: it is a very precise timestamp for the start of an incident that has already blown up in your face.
If you want to build it yourself, the technical breakdown is in our guide to honeypots and canary tokens: specific tools, configuration, and how to keep a red team from spotting them. This article is about the other part: who keeps it alive.
IoT: where a decoy is most believable
As companies fill their offices and plants with connected devices, IoT has become the preferred way in. IP cameras, industrial sensors, network printers, access control, HVAC. Almost all of them share the same three problems: firmware nobody patches, factory credentials nobody changed, and a network position far more privileged than their function justifies.
For an attacker who has just come in through the guest Wi-Fi or an exposed port, a smart thermostat or an unpatched camera is exactly what they expect to find. And that is the advantage: an IoT decoy does not need to hide that it is old and vulnerable, because that is precisely what makes it plausible. Emulating a poorly maintained device is much easier than emulating a convincing production server.
In an industrial environment the same reasoning extends to plant-floor protocols. A device that answers on Modbus or S7comm and is not part of any real process won't be touched by an operator: whoever touches it is mapping the OT network.
What you see when the alarm goes off
A useful alert is not an email that says "suspicious activity detected". It is a notification that lets you decide in thirty seconds whether to get someone out of bed.
| Attacker phase | What they do | Which decoy catches it |
|---|---|---|
| Internal reconnaissance | Sweeps the network to see what is there | Decoy services on every VLAN |
| Credential hunting | Combs through file shares and documentation | Trap files with fake credentials |
| Lateral movement | Hops from one machine to another | Decoy SMB and RDP resources |
| Domain privilege escalation | Requests tickets, dumps memory | Decoy service accounts |
| Exfiltration | Moves data out | Documents that call home when opened outside the network |
Every alert arrives with the source address, the credential used, the exact time, and what they tried to do. That is what turns the alert into a decision rather than just another open tab.
On the right side of the asymmetry
The saying that the defender has to be right every time and the attacker only once captures why defense is so exhausting. Decoys flip that problem on its head inside your network.
When the network is seeded with assets that no legitimate user touches, it is the attacker who has to get every move right. Every share they open, every credential they try, every machine they scan is a roll of the dice that can give them away. And you only need them to slip once.
It does not replace anything. Not the EDR, not patching, not segmentation, not backups that actually restore. It is the layer that assumes everything else will fail at some point, and decides that when that day comes you want to know on day one, not on day thirty.
Related service
Managed security (MSSP): continuous monitoring and response
Topics
#Honeypot #Deception #Early-detection #IoT #Lateral-movement #MSSP
Keep reading
- Honeypots and canary tokens: defending corporate networks against sophisticated adversaries
- Which bucket does your product fall into? An interactive Cyber Resilience Act classifier
- How a company falls: a simulator of the final lapses
- Bybit Hack Analysis (III): Implications and the Future of Crypto Security After the Bybit Hack
- How to Share Credentials and Encrypted Files Securely with Third Parties