Honey Tokens: Turning Attackers’ Curiosity into a Security Advantage Using Coralogix

Back to Resources

Honey Tokens are a security deception mechanism designed to detect unauthorized access or malicious activity by creating fake credentials, API keys, or cloud resources that should never be accessed under normal conditions. If an attacker interacts with a Honey Token, it triggers a pre-defined alert, helping security teams identify breaches early.

In a cloud environment, one should always assume compromise due to the cloud infrastructure’s complex and dynamic nature, where multiple risk factors contribute to potential security breaches.

The human factor plays a significant role, as misconfigurations—such as overly permissive IAM policies, exposed storage buckets, or unencrypted databases—are among the leading causes of cloud security incidents.

Supply chain risks, including compromised third-party dependencies and insecure CI/CD pipelines, further increase the attack surface.

Additionally, credential leakage, whether through exposed API keys in public repositories or phishing attacks against cloud administrators, can provide attackers with unauthorized access.

Given these risks, among other things, organizations must adopt continuous monitoring with automated threat detection to identify anomalies before they escalate. Assuming compromise ensures that security teams operate with a proactive mindset, focusing on rapid detection, containment, and response rather than relying solely on perimeter defenses.

Using Honey Tokens enhances security by detecting unauthorized access early and exposing attackers before they cause harm. These deceptive tokens act as tripwires, triggering alerts when accessed. Since legitimate users should never interact with them, any activity is a red flag, helping identify attack vectors like compromised credentials or insider threats. Unlike traditional security controls, Honey Tokens provide behavior-based detection, making them effective against zero-day exploits. Lightweight and cost-effective, they improve threat visibility and incident response when integrated with Coralogix.

Types of Honey Tokens

Honey tokens come in different forms, each designed to lure attackers and provide valuable insights into their activities. Organizations can enhance their security monitoring and threat detection across multiple attack vectors by deploying various types of honey tokens. Here are the most common types:

• Decoy Files – These files are labeled with sensitive names, such as “Financial Records” or “Employee Data,” to attract unauthorized access.
• Fake Credentials – These are non-functional login credentials planted in expected locations. Any attempt to use them signals potential credential theft and helps trace the attacker’s origin.
• Decoy Database Records – These false database entries resemble real sensitive data, allowing security teams to detect unauthorized access attempts and study attackers’ objectives.
• Canary Tokens – These are small triggers embedded in applications, servers, or URLs that notify security teams when accessed. They can be disguised as API keys, browser cookies, or unique URLs to track malicious activity.
• Email-Based Honey Tokens – These involve fake email addresses that, when targeted in phishing campaigns or hacker communications, provide insights into attackers’ tactics and sources.

By strategically placing honey tokens, organizations can improve their ability to detect and respond to security threats before real damage occurs.

Common Places AWS Access Keys Are Misplaced

AWS access keys are often misplaced in various locations, either by human error, insecure development practices, or overlooked configurations. A very common practice by attackers is to scan for exposed credentials in these areas, making them ideal places to plant honey tokens—decoy credentials designed to trigger alerts when used.

Here are some of the most common locations where AWS keys are inadvertently leaked, to name a few, and how you can leverage them for security monitoring.

1. Code Repositories – The Goldmine for Attackers Developers frequently make the critical mistake of hardcoding AWS access keys during the development process into source code and pushing them to version control systems like GitHub, GitLab, Bitbucket, or AWS CodeCommit. Even private repositories are not immune—compromised developer accounts or accidental public exposure can leak credentials. Attackers routinely scan public repositories for credentials using tools like Gitrob and TruffleHog. To counter this risk, honey tokens can be embedded in configuration files (config.json, .env files) or within scripts. Any attempt to use these credentials can then serve as an immediate indicator of unauthorized access.
2. Cloud Storage – The Hidden Credential Dump AWS S3 buckets, EFS, FSx, and even EBS snapshots are often used to store backup files, logs, or configuration data. Unfortunately, access keys sometimes end up in these storage solutions, either due to improper security controls or poor file organization. Attackers frequently probe for misconfigured S3 buckets and open shares, making them an excellent place for honey tokens. By placing decoy credentials inside a log file or old backup, you can detect unauthorized scanning and credential theft attempts in your cloud storage environment.
3. CI/CD Pipelines & Automation Tools – A Growing Risk Continuous integration and deployment (CI/CD) pipelines automate software delivery but often involve credentials stored as environment variables or embedded in scripts. Jenkins, GitHub Actions, GitLab CI/CD, and Bitbucket Pipelines are notorious for accidental key exposure, especially when debug logs are left enabled. Infrastructure-as-code tools like Terraform, CloudFormation, and Ansible scripts can also be sources of credential leakage. Security teams can insert honey tokens into pipeline configurations or automation scripts to detect misuse and enhance visibility into unauthorized actions.
4. Email & Collaboration Tools – The Unintentional Leak In fast-paced development teams, credentials often get shared over communication tools like Slack, Microsoft Teams, Google Drive file share, or even a simple email. Attackers gaining access to these platforms, either through phishing or compromised accounts, can search for AWS access keys (and not only) in old messages or shared documentation (e.g., Google Docs, Notion, Confluence). It is to note that in these sorts of platforms, access key leaks might be the least of the organization’s concerns. information such as the client’s records or other Personally identifiable information (PII) is most likely a critical asset to jeopardize. By strategically placing honey tokens in documentation or chat messages, security teams can track whether attackers attempt to use credentials from leaked conversations.

Coralogix In Action

By ingesting logs from both CloudTrail and Google Workspace, we can monitor all changes happening within both platforms and monitor the activity of both tokens in a single console.

We will now simulate two scenarios

• Leaked access keys found in a public GitHub repository
• Decoy sensitive file found in Google Drive

Planting the decoys

For AWS, we will first create the user and its access key with no permissions

to ease the process, we can use Terraform:

provider "aws" {
  region  = "eu-west-1"
}
resource "aws_iam_user" "this" {
  name = "foo"
}
resource "aws_iam_access_key" "this" {
  user  = aws_iam_user.this.name
}
locals {
  credentials = {
    access_key = aws_iam_access_key.this.id
    secret_key = aws_iam_access_key.this.secret
  }
}
resource "local_file" "this" {
  filename = "credentials.json"
  content  = jsonencode(local.credentials)
}

Note: In a real Honey Token used in a production environment, use a better name than “foo”. attackers might recognize this testing name and will refrain from using it.

After the running above Terraform, we get an additional file named credentials.json with a similar content to the following:

{
  "access_key": "AKIA3LVX...",
  "secret_key": "OjycnxVKdyRv..."
}

Now that we have the user with access keys ready, let’s plant them in a demo code:

For Google Drive, we will create a file called user_data.xlsx which we will make public to anyone with this link in the main Drive directory. It’s important to note that for a real scenario it is recommended to place the file in a path that will appear real enough to arise the curiosity of the unwanted entity.

Setup the alerts in Coralogix

For AWS

With the query:

userIdentity.type:"IAMUser" AND userIdentity.accessKeyId:"AKIA3LVX..."

For Google Drive

With the query:

id.applicationName:"drive" AND event.parameters.doc_title:"user_data.xlsx"

Investigating AWS Credentials

When the attacker finds the credentials and configures them in his AWS CLI, he will most likely try to first enumerate his permissions.

The first and most used API call is usually the get-caller-identity for the STS service to see the underlined user’s name. the response will look something like this

After knowing the user’s name, the attacker will try to understand what he can do in the environment

all those actions should be faced with AccessDenied response, as this user should not have any permissions attached

When an alert triggers, we can then investigate what the attacker tried to do. and of course to verify that he wasn’t able to perform any actions in the environment

we can use the query (the same as the alert)

userIdentity.type:"IAMUser" AND userIdentity.accessKeyId:"AKIA3LVX..."

and then do the “Show Graph For Key” action in the explore screen of Coralogix

We can then verify that those action were not successful by enhancing the query

userIdentity.type:"IAMUser" AND userIdentity.accessKeyId:"AKIA3LVX..." AND NOT errorCode:"AccessDenied"

The only outcome should be the log for the get-caller-identity action that was initially performed.

In conclusion

Honey Tokens serve as an effective security deception mechanism, helping organizations detect unauthorized access and malicious activity by deploying fake credentials, API keys, decoy database records, and other lures that should never be accessed under normal conditions. Any interaction with these tokens should be monitored and have pre-defined alerts set up, allowing security teams to identify attackers early and analyze their tactics.

In cloud environments, security risks stem from misconfigurations, supply chain vulnerabilities, credential leaks, and zero-day exploits. Attackers frequently scan for exposed credentials in repositories, cloud storage, CI/CD pipelines, and collaboration tools, making these locations ideal for planting honey tokens. By strategically placing decoy AWS keys and monitoring unauthorized use, organizations can gain valuable intelligence on attack vectors, enhance threat visibility, and strengthen their incident response. Assuming compromise as a security mindset ensures that teams focus on proactive threat detection and rapid mitigation rather than relying solely on perimeter defenses.