Sweet Deception: Mastering AWS Honey Tokens to Detect and Outsmart Attackers

Sweet Deception: Mastering AWS Honey Tokens to Detect and Outsmart Attackers

Speakers: Nick Frichette, Security Researcher, Datadog

Conference: fwd:cloudsec Europe 2025

YouTube: https://www.youtube.com/watch?v=R75ZTBnUwXk

Overview

Nick Frichette, a security researcher at Datadog, delivered a technically deep examination of AWS access key honey tokens — their implementation mechanisms, detection capabilities, known weaknesses, and strategies for building a more resilient deception program. The talk goes beyond the surface-level "sprinkle fake credentials and wait" narrative to reveal critical architectural details: not all API operations log to CloudTrail, some honey token providers inadvertently reveal themselves through IAM ARN naming conventions, and alternative detection mechanisms like the credential report and GetAccessKeyLastUsed API offer fundamentally different trade-offs in alerting speed versus coverage. With AWS's own Customer Incident Response Team reporting that leaked access keys account for 66% of initial access in incidents (20% of which are root credentials), the talk makes a compelling case for understanding honey tokens at the engineering level.

Background

▶ Watch: AWS CIRT statistic: 66% of incidents start with leaked access keys, 20% of th... (1:00)

Threat actors have a well-documented appetite for AWS access keys. Credentials leak through Git repositories, config files, network shares, and developer workstations, providing direct paths to initial access, lateral movement, resource hijacking, and ransomware. Honey tokens exploit this behavior by intentionally placing fake credentials in locations where attackers are likely to find them—once used, they trigger alerts that enable rapid incident response. The concept is not new; projects like SpaceCrab pioneered the approach years ago, and more recently Grafana published a blog post describing how Canary tokens helped them detect an intrusion. However, the implementation details matter enormously, and Frichette's research reveals that many popular honey token solutions contain exploitable weaknesses that sophisticated attackers can use to identify and avoid them.

Key Findings

▶ Watch: Introduces credential report-based tokens as a safety net that catches CloudT... (6:00)

Frichette categorized honey tokens into three distinct detection mechanisms, each with different coverage and speed characteristics. CloudTrail-based tokens are the traditional approach: create an IAM user, create an access key, and monitor CloudTrail for any usage of that key. These benefit from rich observability data (IP address, user agent, service, operation) and increasingly fast delivery, but they miss API operations that don't log to CloudTrail, including certain data events requiring advanced event selectors.

The critical weakness is that several providers embed identifying information in the IAM user's ARN path. SpaceCrab used a path called "spacecrab," GitGuardian's GG Canary uses "gg-canary," and Thinks Canary includes "canarytokens.com" in user names. An attacker who finds credentials can call an API operation that doesn't log to CloudTrail, receive a verbose error message containing the ARN, and determine whether the key is a honey token—all without triggering any alert.

Credential report-based tokens represent a more resilient approach, implemented by Thinks Canary as a "safety net" (on advice from Scott Piper). The credential report is a CSV generated every 4 hours containing an access_key_last_used_date column. This mechanism detects usage regardless of whether the operation logs to CloudTrail—including data events, CloudTrail bypasses, non-production endpoints, and undocumented APIs. The downside is severe latency (up to 4 hours) and loss of all contextual information beyond the timestamp and service name.

The third and most novel mechanism is the IAM GetAccessKeyLastUsed API, which Frichette proposes as an improvement over the credential report. It provides equivalent coverage (detecting all API usage including non-production endpoints and undocumented APIs) but can be polled at arbitrary intervals—every 5 or 6 minutes rather than every 4 hours—dramatically reducing detection latency. Like the credential report, it sacrifices IP address and user agent information.

Technical Deep Dive

▶ Watch: Discusses 4-hour detection latency window of credential report tokens and imp... (10:00)

The non-production endpoint discovery is particularly interesting from a technical perspective. Frichette demonstrated that thousands of API endpoints exist across AWS that accept standard credential authentication but don't log to CloudTrail. His example endpoint, simba-gamus2.api.aws, was associated with the FSX service and accepted fsx:DescribeBackups operations. These endpoints return verbose error messages that reveal the full IAM ARN, enabling fingerprinting without detection via CloudTrail. Critically, even these non-production endpoints update the credential report's last-used timestamp, making credential report-based detection effective against this attack vector.

For fingerprinting honey tokens without triggering them, Frichette described two approaches. The first exploits the fact that every AWS access key encodes the associated account ID. Research from Eden Steel and Tal Berry showed this can be decoded entirely offline without making any API calls. The account ID can then be checked against known honey token provider accounts—this is exactly how TruffleHog identifies Thinks Canary tokens without triggering alerts, by maintaining a list of free-tier Canary token AWS account IDs.

The second fingerprinting method, from researcher Rad Kawar, combines account ID extraction with cross-account resource enumeration. Since Thinks Canary's infrastructure is partially open source, an attacker can enumerate the existence of specific IAM roles, users, or S3 buckets within the decoded account ID to confirm it belongs to the honey token provider. Thinks Canary has since mitigated this by adding random suffixes to resource names.

Frichette strongly recommended combining all three detection mechanisms: CloudTrail for rich contextual data on most operations, and GetAccessKeyLastUsed (or credential report) as a resilient backup that catches evasive usage. These approaches are complementary, not mutually exclusive.

Demo / Proof of Concept

▶ Watch: Proposes IAM GetAccessKeyLastUsed as a novel third detection mechanism with 5... (11:30)

Frichette demonstrated the fingerprinting technique against several popular honey token providers, showing how error messages from non-CloudTrail-logged API calls reveal the ARN path containing provider-identifying strings. He showed screenshots of GG Canary exposing "gg-canary" and Thinks Canary exposing "canarytokens.com" in their user paths. He also demonstrated the FSX non-production endpoint accepting credentials and returning identifiable error messages. No live exploit was performed, but the screenshots provided clear evidence of each weakness.

Defensive Implications

▶ Watch: Rad Kawar's side-channel attack using cross-account resource enumeration to i... (15:30)

Organizations deploying honey tokens should audit their implementations for identifiable naming patterns in IAM user ARNs. If using self-hosted solutions like GG Canary's Terraform-based deployment, customize user paths and resource names to remove default identifiers. Combine CloudTrail-based alerting with either credential report polling or GetAccessKeyLastUsed automation to catch evasive API usage. Self-hosting tokens in your own AWS account mitigates account ID fingerprinting, since your account won't appear on public lists of known honey token providers. Consider the latency implications of each detection method and design response procedures accordingly—a credential report-only token gives an attacker up to 4 hours of undetected activity. Extend deception beyond access keys to honey resources like S3 buckets, RDS databases, and DynamoDB tables for defense in depth.

Key Takeaways

• Not all AWS API operations log to CloudTrail, making CloudTrail-only honey tokens vulnerable to silent fingerprinting by sophisticated attackers
• Many popular honey token providers inadvertently reveal themselves through IAM ARN naming conventions that attackers can discover without triggering alerts
• The IAM GetAccessKeyLastUsed API offers a superior alternative to credential report polling — same resilient coverage but with configurable polling intervals instead of a 4-hour minimum
• Access key account IDs can be decoded offline without any API calls, enabling attackers to check against known honey token provider accounts
• Combining detection mechanisms (CloudTrail + GetAccessKeyLastUsed) provides both rich observability data and resilient coverage against evasive techniques
• Self-hosting honey tokens in your own AWS account provides the strongest defense against fingerprinting and side-channel identification

About the Speaker(s)

Nick Frichette is a security researcher at Datadog, known for his extensive work on AWS security, cloud attack techniques, and deception technology. He is recognized in the cloud security community for his research published at securitylabs.datadoghq.com and has been described as "the terror of the cloud providers." His work has been influential in advancing the understanding of AWS internals and attack surface enumeration.