How to detect honeypots in AWS
This document suggests a way to detect and avoid honeypots set up for access key IDs in an AWS environment. Please read ahead to know more about the caveats :)
Last updated
This document suggests a way to detect and avoid honeypots set up for access key IDs in an AWS environment. Please read ahead to know more about the caveats :)
Last updated
I am, Tejas Zarekar, security engineer working in Bangalore, India with 7 years of experience in the field. I specialise in cloud security on AWS and enjoy automating boring stuff!
Imagine you're setting up a fake treasure chest to catch a thief. In the world of cybersecurity, this fake treasure chest is called a honeypot. It's a computer system designed to look like an easy target for hackers. When cyber attackers try to break in, the honeypot traps them and lets security experts study their moves. This helps in learning more about how hackers operate and in improving overall security measures.
Canary tokens are like digital tripwires designed to catch hackers in the act. Here's how they work with AWS access key IDs and secret keys:
Generate Canary Tokens: Using a service like canarytokens.org, you can create fake AWS access keys. These keys look real but are actually set up to alert you when someone tries to use them.
Plant the Tokens: You then place these fake access keys in locations where an attacker might find them, such as in code repositories, configuration files, or documentation.
Lure the Attacker: When an attacker discovers these fake keys and tries to use them, the canary token triggers an alert, notifying you of the unauthorised attempt. This helps you detect the attack early and respond accordingly.
By using canary tokens, you can turn the tables on hackers, gaining valuable insights into their actions and improving your security measures.
The only caveat of using this method to bypass honeypot requires you to know the account id before-hand. We are using a neat trick discovered by Tal Be'ery to deduce the account id from access key.
Imagine a scenario where the attacker finds a shell on an EC2 instance; their first action in-order to get a better foot-hold in the AWS infrastructure would be to get the credentials and move laterally. This can be achieved through querying IMDS endpoint on EC2 instance.
Attacker would get the credentials and authenticate themselves to AWS and assume identity of the EC2 machine.
Here, security team can proactively spoof this IMDS endpoint in-order to serve the canarytokens instead of legitimate IMDS endpoint. This is easily achieved by setting a iptables rule as shown below:
iptables -t nat -C OUTPUT -p tcp -d 169.254.169.254 --dport 80 -j DNAT --to-destination 127.0.0.1:54321
Setup and know more about IMDS-spoofing here - https://github.com/grahamhelton/IMDSpoof
Attacker would try to authenticate themselves using the spoofed IMDS credentials and trigger the honeypot alert.
Leaning on script devised by Tal Be'ery, the attacker can deduce the account-id from access-key id.
If the account id deduced from the access key id retrieved through compromised EC2 instance does not match the account id of victim, then its probably spoofed and would trigger the honey-pot alert.
Use the below script to get the account id from access-key id:
This is an sample scenario where the attacker can be weary of triggering alerts and verify if the access-key is a trap or not. Security team can be step ahead by spoofing the account-id via IMDS-spoofing as well.
There is a small niche where this method will work!
Eager to know more ways where knowing the account-id from access-key can be helpful (for both red and blue team)
TLDRSec: https://tldrsec.com/p/tldr-sec-263
CloudSecList: https://cloudseclist.com/issues/issue-271/
AWS Security Digest: https://awssecuritydigest.com/past-issues/aws-security-digest-193
Leadership in tech: https://newsletter.leadershipintech.com/p/depthfinding-for-managing-performance
HackerNews (submission): https://news.ycombinator.com/item?id=42820837