Umami honeypots: deception that flavors the environment

Umami honeypots

Umami is the fifth taste. It doesn't register as its own flavor, but it makes everything around it taste more complete. Some honeypots work the same way. They rarely trigger alerts on their own. They don't catch attackers directly. Their job is to make the surrounding environment convincing enough that the real traps land. Call them umami honeypots. A honeypot isn't a service. It's an environment.

The goal isn't one service doing everything. It's separate honeypots on the same network making each other believable. The objective is studying behavior, not tripping wires. Alerts come from the traps themselves. Umami keeps actors in the environment long enough to walk into one.

Attackers validate before they commit

In prior RDP honeypot deployments, a pattern showed up regardless of skill level: actors treat a compromised machine as a recon platform before deploying anything valuable.

The sequence looked roughly the same each time. Mimikatz runs first to dump credentials from memory. Then nltest and other AD-enumeration commands to identify the domain, followed by searching the domain name to check whether it belongs to a real organization. Folder structures get browsed: Desktop, Documents, network shares, client directories (read-only bait). Whatever credentials turn up get fed into GUI-based network scanners like Advanced IP Scanner or Angry IP Scanner to map the internal network.

Each step is a question. Are there credentials worth reusing? Is this a real domain attached to a real company? Does the file system look lived-in? Are there other machines worth pivoting to?

If the environment doesn't answer those questions convincingly, you get the B-team response. Commodity tooling. Ransomware with no working decryption key. A quick disconnect.

A separate cluster of actors followed a different pattern entirely. They landed through brute-forced RDP credentials, deployed another brute forcer targeting external hosts, and continued the chain outward. Their goal was pivot infrastructure, not data. Different intent, but both groups probed the environment before choosing their next move.

The hypervisor that nobody exploits

A virtualization management panel tells an attacker something useful before they touch it. The environment is virtualized, so multiple services on adjacent IPs make sense. There are VMs on a shared host. MAC addresses look hypervisor-generated because they are. The whole network reads like a homelab or a small MSP running consolidated workloads. The panel itself might never get exploited. Its presence answers questions the attacker was already asking.

In one fleet engagement, an actor read a .env file served by a web-facing honeypot. The file contained fake credentials: application passwords, admin usernames, email addresses. Standard bait. The actor discovered the virtualization management panel running on the same subnet and replayed every password from the .env against the panel's login within seconds. When those failed, they permuted usernames harvested from the same file and tried again with different combinations.

The infrastructure honeypot became a collection point because it existed in the right place with the right shape. The web application gave up credentials, and the virtualization panel was sitting there ready to receive them. The actor connected those dots without prompting.

A full engagement report covering this actor's complete session is published here.

The hosting ecosystem that answers back

A hosting control panel in the wild doesn't exist in isolation. There are reseller accounts, PHP applications, databases, customer home directories. The fleet's emulator seeds this ecosystem: fabricated user accounts, responsive management APIs, per-customer directory structures that look like years of accumulated hosting business.

One actor fired roughly 100 management API calls in under a minute after bypassing authentication, then provisioned reseller accounts with plausible small-business names. They didn't fumble around looking for endpoints. They expected the hosting ecosystem to be there, and they used it like someone who'd done this before.

A pair of actors deployed a secret-harvester webshell that scraped for database configs, container orchestration credentials, PHP sessions, and payment-webhook configs. They weren't interested in the control panel itself. They wanted the full surrounding service stack a real hosting environment would have: databases, payment integrations, container runtime secrets.

An analysis across hundreds of IPs over two weeks identified four behavioral archetypes:

1. Surface scanners who collect the banner and move on.
2. Auth testers who try a credential list and leave.
3. Tooling deployers who drop a webshell and start harvesting.
4. Credential harvesters who go deep into the ecosystem and stay.

The actors who went deepest were the ones who found the ecosystem answering back.

Without seeded accounts and responsive APIs, these actors bail after the first empty response. The ecosystem is umami for the exploit chain.

Several engagement reports covering these behavioral archetypes and their kill chains are published or in progress. Deeper dives to follow.

The RDP session that went quiet

In prior RDP honeypot deployments outside the fleet, one session showed exactly what happens when the environment fails.

Session telemetry showed the actor landing and running the standard loop: Mimikatz for credential dumps, nltest for AD domain info, folder browsing through Desktop, Documents, network shares, and client directories (read-only bait). Then they fed harvested credentials into a GUI-based scanner and port-scanned the internal network.

Nothing answered. No machines on adjacent IPs. No services behind the ports. No AD domain resolving to a real-looking entity. The network was empty.

The actor disconnected. Came back after a pause. Went through some of the same steps again, back and forth, as if double-checking. Eventually they deployed Corona ransomware, a strain with no working decryption key. They knew the target wasn't worth real tooling. Corona was the B-team closer for a network that didn't pass the check.

If that port scan had found a domain controller, a file server with actual content, workstations with browser history, the actor would have committed real tools. The emptiness was the tell.

Skill levels varied across these sessions. Some actors ran cracked versions of commercial scanners. Others could barely operate tools without a GUI readme open on the desktop. A few were methodical and patient. The environment either passes or it doesn't, regardless of who's sitting at the keyboard.

Choosing your umami

A good umami node answers a question the attacker is already asking. A hypervisor explains why VMs exist on adjacent IPs. A DNS server makes hostnames resolve. A CI/CD dashboard says "people build and ship code here."

It should also explain something that would otherwise look suspicious. A /24 with six services and no management plane is odd. Add a virtualization panel and the topology clicks into place.

It doesn't need to be high-fidelity itself. A login page that never lets anyone in still does its job as environmental context. The fidelity bar is lower. The service just needs to justify the trap, not be one.

Services that exist in isolation are anti-umami. A standalone database with no application talking to it raises questions instead of answering them. A DNS server that doesn't resolve any of the hostnames the attacker found in configs is worse than no DNS at all. If the supporting service contradicts the story, it damages the environment more than its absence would.

Close

When designing a deception environment, think about what an attacker would ask about the surroundings before trusting the trap. Then build the honeypots that answer those questions.

Those honeypots won't top the alert dashboard. They might not generate a single event. But without them, the actors whose tooling you actually want to capture see through everything else.