Detect Malicious Activity with AWS Honey Tokens

What this lab covers

You place decoy credentials and resources in an AWS environment and build the alerting pipeline that tells you the moment anyone touches them, using native services rather than a third-party product.

The lab is as much about detection design as about AWS. Deciding where a decoy belongs, and naming it so that it is discovered by an attacker enumerating the account but never touched by a colleague, is the part that determines whether it works.

It suits defenders and detection engineers, and it is a good counterweight to offensive labs because it produces something you can deploy in your own environment immediately.

How honey tokens work in AWS

A honey token is a resource that exists only to be interacted with by someone who should not be there. In AWS that might be an IAM user whose credentials are placed where an attacker would look, a bucket with an inviting name, or a secret that no application references.

Detection comes from the control plane. Any use of a decoy credential is recorded in CloudTrail, and because the credential is attached to nothing and permitted to do nothing, even a failed attempt is a complete signal. You do not need the action to succeed to know someone tried.

Naming is the whole craft. A decoy called honeypot-do-not-use will be avoided by attackers and produces nothing. A decoy that looks like the most valuable thing in the account, sitting where a real credential would be, gets used. It also must not be attractive to colleagues, since a decoy that staff stumble into is a false positive generator.

How to detect this in your own environment

Wire the alert to a person, not a dashboard. The value of a honey token is that it fires rarely and means something, so it should page someone rather than accumulate in a queue where it will be reviewed next week.

Alert on both success and failure. An access denied response to a decoy credential is as informative as a successful call, and often more so, because it suggests the attacker is probing rather than acting.

Record everything about the attempt. Source address, user agent and requested action tell you whether this is a scanner that found a leaked key or someone already inside the environment, and those two situations call for very different responses.

How to prevent it

This lab is a detection control rather than a preventive one, and it is worth being clear about that. Honey tokens do not stop an intrusion, they tell you one is happening, so they complement rather than replace least privilege and credential hygiene.

Make sure the decoy cannot do anything. A honey token with real permissions is not a detection mechanism, it is a liability, so the attached identity should be permitted nothing at all.

Document the decoys somewhere your responders will find them during an incident. A team that does not know a resource is a decoy will spend the first hour of an incident investigating their own trap.

Real-world context

Decoy credentials are a long-standing and effective detection technique, and they are particularly well suited to cloud environments because the control plane logs every API call by default, so no agent or additional collection is required.

They are especially effective against the leaked credential case. Publicly exposed keys are picked up by automated scanning within minutes, so a decoy key placed in a repository will usually tell you about an exposure faster than any scanning you run yourself.

The approach corresponds to established deception practice and complements the discovery techniques catalogd under MITRE ATT&CK T1087 Account Discovery and T1580 Cloud Infrastructure Discovery, by placing bait precisely where that discovery will look.

Applying this at work

• Create one decoy IAM user with no permissions and alert on any use of its credentials.
• Place a decoy credential in a repository, a build system and a shared document store, since those are three different exposure paths.
• Name decoys so they look valuable to an attacker and uninteresting to your colleagues.
• Route the alert to a paging channel, not to a dashboard.
• Add a line to your incident runbook listing which resources are decoys, so responders do not investigate their own trap.

Frequently asked questions

What makes a honey token different from other detections?

It has no legitimate use, so there is no normal behavior to distinguish it from. Any interaction is unauthorised by definition, which makes it one of the few detections with an essentially zero false positive rate.

Does a honey token need permissions to work?

No, and it should not have any. Detection comes from the attempt being logged, not from it succeeding. A decoy identity with real permissions is a liability rather than a control.

Where should decoy credentials be placed?

Where an attacker would look and a colleague would not: repositories, build systems, shared documents and configuration stores. Placement and naming determine whether the decoy is ever used.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack paths and the detection opportunities against them, and is assessed hands-on in a live AWS account.