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:
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.
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 updateAnd then install python3.8 and its dependencies
sudo apt install python3.8 python3.8-distutilsThe 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.shWith 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.
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:
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 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:
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.
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.
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.
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.
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.
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.