How to use honey tokens effectively to detect intrusion in AWS

Deploy Honey token in AWS

In AWS, honey tokens are access keys for profiles that have absolutely no authorization within your infrastructure used to detect intrusion. You can generate and disperse as many tokens as you need in your environment.

If an unauthorized user gains access to one of these tokens, their instinctive reaction will probably be to attempt to perform actions within your AWS infrastructure, like aws sts get-caller-identity. However, as soon as an API call is made, an alert is immediately triggered, enabling you to detect an attack and react quickly to the potential threat.

This configuration offers several notable advantages:

• Security: Honey tokens are intrinsically secure, as they grant no privileges, providing an impenetrable barrier against malicious activity.
• Low false-positive rate: This approach keeps the rate of false-positive alerts extremely low, enabling your security team to focus on real threats without unnecessary distractions.
• High efficiency: AWS access keys are often low-hanging fruits and can’t really be identified as fake until you use them.

Implementing honey tokens can also be viewed as an early method for detecting intrusions, given their ease of implementation. However, it's important to highlight that this approach should be complemented with comprehensive logging and additional detection methods like Guard Duty to fully understand how the attackers breached your defenses.

How to deploy Honey token in your infrastructure

To deploy Honey Token in your infrastructure, we can use the good module GGCanary maintained by GitGuardian. I won’t explain how to set up Terraform in this article because it is already really well explained in the GitGuardian article. I’m assuming you have a Terraform codebase working. This code will need some adaptation to work with Terragrunt.

You will perhaps need to install python3.8 to your computer to make this work. For this, add this apt repo :

sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt update

And then install python3.8 and its dependencies

sudo apt install python3.8 python3.8-distutils

The important file will be the ggcanaries.auto.tfvars file, where all tokens will be generated. The syntax is the following:

users = {
  token1 = {
    tag_1  = "Tag1"
    source = "email"
  }
  token2 = {
		tag_1  = "Tag1"
		tag_2  = "Tag2"
		source = "VCS"	
	}
}

Here, you must create as many tokens as you need and describe them as precisely as you need. Note that you are limited to 30 tags per token and 5000 tokens.

To integrate this Terraform code into your existing infrastructure, simply add it as another layer and apply it using the following command:

terraform apply -var-file="terraform.tfvars”

Once the deployment is complete, all tokens will be seamlessly integrated into your infrastructure. You can retrieve a comprehensive list of all tokens by executing the following script:

./scripts/list_keys.sh

With your tokens in place, you're now ready to strategically position them within your infrastructure to effectively detect any potential intrusions. This is a crucial step in bolstering your security posture and proactively identifying threats.

Where to place those honey token

Determining the optimal placement for Honey Tokens is the most challenging step in the process.

The main objective is to detect potential attackers already present within your infrastructure rather than triggering alerts due to exposed Honey Tokens that could attract any curious onlooker. These tokens must be accessible only to an attacker with initial access. In a typical cloud kill chain, the privilege escalation often occurs in the following areas:

• Publicly exposed access keys
• Compromised 3rd-party services
• CICD pipelines
• Applications running within the cloud
• Developer access

When deploying Honey Tokens, it's unnecessary to address the issue of publicly exposed access keys, as our goal is to generate meaningful alerts. Placing honey tokens in every 3rd-party service accessing your infrastructure is also an impractical endeavor.

Let's focus on the more strategic options.

CICD

CICD pipelines often need AWS credentials to deploy in your infrastructure. You can find those credentials stored in plaintext, inadvertently left in Git histories, or kept safe as secrets in a Vault but susceptible to extraction by malicious actors leveraging custom CICD workflows. The GitOps approach increases the need for workloads to access AWS resources.

Furthermore, developers typically have more access rights than necessary, making them a target for attackers. Consequently, CICD pipelines are ideal locations for deploying Honey Tokens and detecting a compromised developer account.

However, avoid overly conspicuous placements, such as a repository named secret containing a file named .env with only two values, as attackers can detect such obvious decoys. Instead, consider placing tokens in likely locations, such as Git history, repository secrets, or hardcoded in a pipeline.

An essential consideration is determining the number of distinct Honey Tokens required. The answer varies based on your organization's security maturity. Honey Tokens should help us quickly detect which assets have been compromised. To achieve this, it's crucial to employ distinct Honey Tokens for each repository. These tokens can be strategically positioned as follows:

• One in the Git history of each repository
• One in the secrets of each repository or in the Vault
• One hardcoded within a CICD pipeline accessible to all developers

It is important to be able to quickly spot where the attacker is. For this, use as many tokens as you need.

If the attacker is a script kiddie employing tools like Trufflehog, detection will be automatic, as Trufflehog automatically tests for tokens.

Application running in the cloud

Another common path for compromising infrastructure is through applications. It is imperative to generate unique Honey Tokens to detect the specific applications that may have been compromised.

Attackers employ various tactics, such as Remote Code Execution, Local File Inclusion, SQL injection, and other methods to gain unauthorized access to sensitive data like AWS access keys and infiltrate your AWS infrastructure. The challenge here lies in placing Honey Tokens within every instance of the application.

In Kubernetes, this can be accomplished with tools like Kyverno. For EC2 instances, Honey Tokens can be set up using user data or Ansible. However, exercise caution with this approach, as these Honey Tokens will also be accessible from the CICD pipeline deploying the application.

If an alert triggers, it's possible that the attacker only has access to the repository deploying the application, not an RCE. In such cases, the attacker might trigger multiple Honey Tokens, not just one.

Developers access

Finally, consider the access keys used by developers. First, developers should prioritize using temporary credentials over access tokens. While it is theoretically possible to deploy Honey Tokens on every computer within the company, this approach is logistically challenging and might not yield commensurate rewards, considering the effort involved.

Moreover, it would be difficult to discern which user has been compromised in such a scenario. Instead, consider implementing alternative detection methods like a classical EDR on each computer.

Real-world example

Let’s try in the real world. After committing the AWS access key on my public GitHub, I got the first bot trying to connect to my AWS account 6 minutes later.

As you can see, bots use automatic tools like TruffleHog to test tokens. This method is really noisy and easy to detect, thanks to the bait we placed in our repository.

What to do after a detection

So, you've detected the presence of an attacker within your infrastructure, but what's the next step?

First and foremost, you must trace the source of the compromise. This is where Honey Tokens, while valuable, are not standalone solutions. You need to dive deep into your logs to identify which collaborator or application has been compromised. Once identified, it's imperative to promptly rotate their credentials. Following this critical step, you can initiate your incident response procedures.

If the Honey Token has originated from an application, it's essential to take swift action to contain the situation. Begin by isolating the affected application from the rest of your infrastructure to prevent the attacker from establishing backdoors or further infiltrating your systems. Next, examine your logs to find the specific vulnerability or exploit that the attacker employed. Armed with this knowledge, you can initiate remediation efforts to patch or mitigate the vulnerability.

Just like with any security system, it's really important to listen to feedback and make improvements. This is especially true after a security test like a red team assessment. If the auditors manage to avoid your trap, it's crucial to ask them why they didn't fall for it. This feedback can help you move your fake security token to a better hiding spot with a more inconspicuous name.

Conclusion

Honey tokens offer a powerful and proactive approach to detecting intrusions in AWS environments. By strategically placing access keys with no authorization, organizations can lure potential attackers into revealing their presence without exposing their infrastructure to real threats.

However, it's important to note that honey tokens should complement, not replace, comprehensive intrusion detection systems. As demonstrated by a real-world example, honey tokens can swiftly alert organizations to unauthorized access attempts, enabling them to take immediate action to protect their AWS environments.