Enhancing Security for AWS Static Websites: A PoC Implementation of Honeytokens

One of the challenges in the cybersecurity domain is finding effective, low-cost solutions that are quick to implement and minimize risk. As I constantly repeat, cybersecurity is all about risks.

In this article, I’d like to talk about one of my favorite tools in the cybersecurity arsenal — Honeytokens and share a small PoC of how to use them in a static site in AWS.

First of all, what are honeytokens? In simple terms, honeytokens are digital decoys. They are designed to detect unauthorized access or suspicious activities within a system or network. By acting as bait, they can draw out and expose attackers.

Let’s see an example: Imagine you are using Active Directory. You can create a fake user (with no permissions) that nobody should use and then configure your system to raise an alert whenever this fake user is accessed. So if you ever get a notification that someone has accessed or tried to access this fake user, it indicates unauthorized access — someone is poking around where they shouldn’t be. You can even leave the user and password on your desktop to detect if any malicious user has accessed your computer and is trying to move laterally or escalate privileges.

If you would like to know more about honeytokens, I’d recommend checking out a segment from the Active Defense & Cyber Deception course by Black Hills Information Security. You can find it here.

While looking at ways to detect attacks and scrapping attempts in cases where we share content from a bucket behind Amazon’s CloudFront, I thought that one line of defense could be using honeytokens.

We can use a custom behavior from CloudFront to generate a path and add them to our site that (this will be our honeytoken ), when accessed, will call a Lambda@Edge function. This function will then update a Web Application Firewall (WAF) IP Set (from a Web ACL used by the CloudFront distribution) with the IP that requested the honeytoken path.

By continuously monitoring the honeytoken path, we can identify and block IP addresses interacting with them. The assumption is that legitimate users would never click or interact with these hidden paths.

To test this scenario, I prepared the infrastructure using Terraform. It includes:

• An S3 bucket to host your content
• A CloudFront distribution to serve your content
• A Lambda@Edge function that is triggered on viewer requests to a specific path (honeypot) on the CloudFront distribution
• An AWS WAF IP Set, which the Lambda function uses to block IP addresses
• A Web ACL that uses the IP Set to block requests from the blocked IP addresses

The deployment is easy, but due to restrictions on Lambda@Edge functions, environment variables are not allowed. Therefore, the Lambda function must have the IP Set ID hardcoded into its code.

If you are interested in testing it, look at the terraform code and try it by yourself https://github.com/adanalvarez/aws-edge-honeypot-poc