Honeytokens act like tripwires, alerting organizations of malicious cyber threats lurking at the footsteps of their sensitive data.
They're a very effective intrusion detection system. So effective, in fact, that the European Union Agency for Cybersecurity (ENISA) highly recommends their use in network security.
If strategically distributed thought an ecosystem, honeytokens could prevent supply chain attacks and improve compliance with Joe Biden's Cybersecurity Executive Order.
What are Honeytokens?
Honeytokens, also known as honeypots, are fake IT resources used to detect cybercriminal activities.
Cybercriminals think these decoy resources are legitimate and attempt to exploit them. These superfluous attempts are detected, alerting organizations to malicious activity in their computer systems.
Honeytokens are a proactive method of cyber-defense. Instead of responding to cyberattacks after they've occurred, honeytokens allow organizations to detected data breach attempts so that targeted resources can be most effectively defended.
Besides revealing prospective attack strategies, honeytokens could also uncover the identity of attackers, making it possible to track and incriminate them.
Honeytokens turn an attack surface against threat actors, making cybercriminals victims of their own malicious schemes.
Can Honeytokens Prevent Supply Chain Attacks?
No cyber defense method is guaranteed to prevent supply chain attacks. Honeytokens, however, provide advanced warnings of malicious activity in a network which, if rapidly responded to with appropriate remediation efforts, could significantly limit the impact of a supply chain attack.
Because supply chain attackers breach targets through compromised vendors, honeytoken offer the best digital supply chain protection if vendors incorporate them into their information security.
Any organization offering third-party services should practice due diligence by surrounding their sensitive resources with honeytokens.
Honeytokens could also alert stakeholders to insider threats facilitating a supply chain attack.
Types of Honeytokens
There are different forms of Honeytokens to mirror the many different forms of sensitive resources that attract cybercriminals. Some common examples are listed below:
Canarytokens
Canarytokens can generate different types of honeytokens through a free open-source web application. This is the simplest method of creating honeytokens.
To generate Canarytokens, head to canarytokens.org, select your honeytoken type, and specify the email address that should be contacted when each honeytoken is activated.
But like all rapid computer security solutions, there are limitations to using Canarytokens.
The domain for tracking Canarytokens cannot be modified, and it includes the Canarytokens.org URL. Perceptive cybercriminals will notice this and realize they are interacting with bugged resources.
The other major drawback is that you cannot specify the data that honeytokens generate.
To overcome these limitations, Canarytokens can be run from a dedicated servicer, such as a Virtual Machine in a public cloud.
The other serious limitation of Canarytokens is that they cannot be generated, deployed, and managed at scale.
Small ecosystems could speckle their access points with Canarytokens, but multi-dimensional infrastructures requiring thousands of honeytokens could not.
Complex ecosystems should generate their own honeytokens at scale by configuring AWS keys.
Amazon Web Services (AWS) keys
AWS controls access throughout its infrastructure through a series of keys. In a reconnaissance campaign, lower privilege keys could provide attackers with the intelligence required to breach higher privileged accesses.
So all AWS access levels should, ideally, have honeytokens that are triggered during breach attempts.
AWS keys can be configured as honeytokens that are placed along attack surfaces that could be traversed by cybercriminals. This could include the supply chain, GitHub repositories, desktops, or text files.
How to create AWS Honeytokens
To create AWS honeytokens, it's good practice to start by creating an empty AWS account. This will make setting directives much easier and mitigate incorrect performance caused by errors.
By default, all IAM users have zero privileges, however, to ensure this is always the case, a deny all policy should be enforced.
Here's an example:
{ "Version": "2021-02-12",
"Statement":
{ "Effect": "Deny",
"Action": "*",
"Resource": "*", } }
AWS CloudTrail will need to be activated to log all token access activities. To integrate an alert system for all triggered tokens, the open-source tool SteamAlert can be used.
Each AWS account has a limit of 5,000 users and each user can have a maximum of 2 tokens. 10,000 honeytokens should be sufficient for most AWS infrastructures.
But AWS does not have the functionality to configure honeytokens at scale. To meet this essential requirement, Project Spacecrab was developed.
What is Project Spacecrab?
Project Spacecrab was developed in 2018 by Daniel Grzelak, head of security at Atlassian. Grzelak developed the tool to help organizations rapidly scale their cybersecurity efforts.
The open-source tool is capable of generating several thousand AWS honeytokens across every endpoint in an ecosystem.
Once generated, Spacecrab tracks the location of each token, when they were generated, and who created each of them.
The alerting pipeline can also be configured to specify how each honeytoken's alarm should be triggered.
How does Project Spacecrab work?
By default, all AWS keys generated by Project Spacecrab have a deny-all policy, so they cannot be used to access sensitive resources. If an attacker attempts to use a Spacecrab honeytoken, the actions are loaded into an S3 bucket, then a Lambada function for analysis.
Honeytoken events are sent to an AWS SNS topic which triggers more Lambadas for each of the configured alerting methods.
The two standard alerting actions include Amazon's Simple Email Service and PagerDuty Events API v2. Additional custom alert functions can be developed and be implemented.
Fake database records
SQL injection is a common attack method where threat actors inject SQL commands into text fields to access and manipulate back-end databases.
Fake database records will distract threat actors from real sensitive records, and the compromise of these fake records will reveal loopholes in database security.
Fake records need to be very appealing to cybercriminals. Sensitive information such as financial records, and records containing privileged names, are irresistible to threat actors.
Fake executable files
This is an advanced form of honeytoken. Fake executable files are fully operational decoy software programs. When they're accessed, a covert signal is sent from the software, identifying when they're in use.
These signals identify the attacker's IP address and any names linked to their systems.
Fake executable files could be very effective at identifying supply chain attack attempts involving software manipulation. The SolarWinds supply chain attack resulted from a compromised update to its Orion Product.
But honeytoken software will only reveal incriminating details if the attacker's external ports are blocked when the decoy programs are running.
Sophisticated cybercriminals are unlikely to leave their machines unprotected, but cybercrime is not only practiced by acerbic hackers.
Sophomorphic criminals frequently attempt cyberattacks that could be thwarted with fake executable files.
If decoy software honeytokens are utilized, care must be taken to ensure cybersecurity laws are not violated.
Covert embedded links
This type of honeytoken will also only work if an attacker's machine is unprotected. Embedded links within resources files, when clicked, send a cladestine signal to the organization being targeted with details of the attacker's identify and attack methods.
Web beacons
Web beacon honeytokens adopt the same tracking mechanism as marketing tools. A web beacon is a link to a hidden embedded object. This could be a transparent picture or a pixel.
Web beacons can be appended to any document type that could seem like a sensitive resource to cyberattackers.
When the web link within the web beacon is clicked, the attacker's computer will covertly relinquish its identifying information to the organization being targeted.
Web beacons could uncover the following information about an attacker:
- Browser versions
- Email addresses
- IP address
- Operating system details
- Location
Like embedded links and fake executable files, web beacons will only work if an attacker is not protected behind a firewall.
Browser cookies
Browser cookies are packets of data that disclose details of users browsing websites. Because they contain identifiable information, their usage is strictly regulated in Europe.
Browser cookies are a highly effective form of honeytoken because they could circumvent blocked endpoints. There's still a human error factor required for these honeytokens to work.
Browser cookies only provide useful cybercrime intelligence criminals do not regularly clear their browser chache information. But such routine maintenance is usually overlooked, even by seasoned cybercriminals.
Fake email addresses
This is a very basic type of Honeytoken. If a fake email address within an enterprise resource receives phishing emails, it's an indication that the enterprise resource was breached.
Phishing emails are not the only indicators of compromise, breached emails can be also leaked on the dark web. Such events are difficult to discover without a sophisticated data leak detection solution.
For a fake email honeytoken to be convincing, it needs to look like it belongs to a privileged staff member in the targeted organization.
How to Deploy Honeytokens
Honeytokens should be deployed strategically to cover all of the resources an attacker might try to compromise.
There are 3 phases of efficient honeytoken deployment.
Phase 1: Identify all Honeytoken deployment points
First, all critical resources and endpoints need to be identified and logged so that they can be protected by honeytokens.
Critical deployment points could include:
- Laptops
- VPN servers
- Bastion hosts
- Databases
- Production servers
A log should be kept of each honeytoken deployment point. Complex ecosystems should use a token management solution such as Project Spacecrab.
Rather than sending generated honeytoken to different teams for deployment, each team should generate their own honeytoken locally. Otherwise, each stage of the delivery path could trigger false positives.
Phase 2: Integrate Honeytoken events into Incident Response Plan
For honeytoken deployment efforts to be scaleable, rather than only being notified via email, triggered events should be autonomously fed into Incident Response Plans.
This could involve pushing trigger events into Slack, PageDuty, or Jira. If you're using Canarytokens, this is done by specifying webhooks instead of an email when generating tokens.
How to set up incoming webhooks for Slack.
How to set up incoming webhooks for PageDuty.
How to set up incoming webhooks for Jira.
But trigger alerts are only useful if they identify the locations of each event. To achieve this, lookup tables should be integrated into detection rules.
Lookup tables should be highly descriptive so that targeted resources can be isolated and defended rapidly.
For example:
"Honeytoken <insert key ID> is located in Anna's Microsoft Surface Pro 7 with serial number <insert serial number> in ~/.aws/credentials"
Phase 3: Scale Honeytokens deployments
Now that all prospective deployment points are identified and token trigger events are configured, it's time to deploy all honeytokens.
Ideally, this should be an automated process, otherwise, the project will need to be manually managed to ensure all departments administer their honeytokens correctly.
The more honeytokens that are deployed, the more verifications exist for each triggered events. This minimizes false positives that cause superfluous incident responses and waste security resources.
How to Respond to Honeytoken Triggers
After confirming that a triggered event is not a false positive, an organization should immediately follow its Incident Response Plan (IRP).
IRP's ensure all security team members remain focused and in control during a high-duress cyberattack event.
An IRP should outline how to rapidly locate each comprised system through honeytoken trigger information.
Once narrowed down, the resources should be immediately isolated. This could include disabling user access, sending third-party risk assessments, or disconnecting servers.
