What are Honeypots?
A honeypot, in its simplest form, is a decoy system or network designed to attract hackers. By mimicking the vulnerabilities and data of real systems, honeypots serve as a trap to lure attackers, allowing security teams to study their methods, monitor their activities, and alert in case of breach. Traditionally, Web Honeypots are just fake stand-alone web applications with exploitable vulnerabilities in them, in the blog post we will dive into a lesser known type of honeypots which I call a “Production Web-Based Honeypots”, which is a method of setting small traps inside production web applications in an effort to detect breaches
What is a Production Web-Based Honeypot?
A Production Web-Based Honeypot is just like a normal web honeypot, I.E a fake resource which triggers some alarm once someone trips it only, it is implemented as part of a production web based application, like a SaaS application and it’s not a standalone application. The idea here is to incorporate several honeypot traps inside our production environment so we can detect if an attacker has managed to bypass a layer of defense in our production web application.
For example, we can integrate into our application “Honeypot secrets”. Honeypot Secrets can be a username and password you “accidentally” left in your source code or it can be an SSH key, JWT, or any sort of key. If an attacker tries to use the honeypot secret to access some resource you own, then an alarm would be triggered. Since there is no real legitimate use for honeypot secret, and it should not be publicly accessible, then if an attempt to use the honeypot secret was made, a we can suspect that someone nefarious managed to gain access to our source code (or wherever we left the secret) and is attempting to elevate their privileges by accessing other resources.
But Why a “Production” Honeypots?
A honeypot is an essential tool for organization that wants to reduce their “Time to Detection”. Time to Detection (TTD) is a crucial metric that measures the span between the initial occurrence of a security breach and the moment it is detected. This metric is pivotal as it directly influences the overall impact of a security incident on an organization’s resources and data integrity.
The faster an organization can detect a breach, the quicker it can respond, potentially mitigating harmful effects such as data loss, financial damage, and reputation harm. A prolonged TTD gives attackers more time to explore the network, steal sensitive information, establish persistent threats, and inflict significant damage. TTD according to research are on average very long. In IBM’s 2022 data security report, it was reported that it took an average of 277 days for businesses to identify and report a data breach.
By building our honeypot as part of production system, we increase the likelihood that we can detect a breach in our production system and shorten the TTD.
Some Ideas for Web-Based Honeypots
Implementing Honeypots in your web application can come in many forms. Feel free to get creative with these ideas and adjust them to your particular assets and use cases. Here are a few methods:
1) Honeypot Secrets
As previously described honeypot secrets can be any typical secret that may be luring to an attacker such as JWTs, passwords, SSH keys, etc. If someone tries to connect using these secrets, then an alert is triggered. The majority of the heavy lifting here is implementing an external server that triggers when a specific secret is used, but nothing too fancy is required. A basic alarm system could be an AWS Lambda function that sends a message to a Slack channel that you monitor. You could “accidentally” leave the honeypot secrets in various places you want to monitor like comments in your source code, config files, inside your database, on a Linux ENV, or anywhere you want to set your trap. I recommend avoiding placing the secrets in places that may be publicly accessible like public JavaScript files, public GitHub repositories and so on, in order to reduce false positives.
2) Honeypot Endpoints
Honeypot Endpoints are fake endpoints or URLs that are not linked from any visible part of the application. Any access to these URLs can signal unauthorized access attempts. So you could, for example, add a new route to a micro-service with an interesting name that may enticing to an attacker with source code access such as “/admin/c11e84df-9d07-434d-b394-298c218d3542/getAllusers” or something similar.
You want to avoid setting up routes that may be guessable using automatic tools, so the route’s URL should be fairly complex.
You would also want to avoid making it too obvious that the function being executed by the micro-service is a honeypot (we are assuming here that the attacker has source code read access), so I suggest sending a request to an external server that trips the alarm like in the following example:
In the following example we have a simple NodeJS micro-service that triggers an HTTP request to a honeypot if the endpoint /admin/c11e84df-9d07-434d-b394-298c218d3542/getAllusers is called. once someBackendHonepot.local receives an HTTP request, it will triggers an alert.
You don’t have to actually set up a route in order to create this honeypot routes, alternatively, you could just reference the honey endpoint somewhere in your source code (this is the lure) and configure your WAF or logging system to alert whenever someone calls the URI.
3) Honeypot Accounts
Create application-level user accounts with no legitimate activity, conveniently leave the access credentials to these account laying around somewhere (in source code, DB, or anyplace you want). Any successful attempt to login with these accounts can be flagged as suspicious.
This type of honeypot is more suitable for specific types of applications which allow users to create their own accounts. Also you would need a way to track logins to these honeypot accounts, which most application can do pretty easily using their logging systems.
Who should implement production honeypots?
Implementing honeypot in an organization is usually not one of the first steps organizations takes towards improving their security and especially not honeypots in productions, so I would categorize this strategy as an advanced one. Before implementing Production Web-Based Honeypots you need to make sure you are performing the SDLC basics first like threat modeling, penetration testing, code scanning, incident response planning and code reviews. Once you have the basics nailed down, and you want to move to the next level, then Production Web-Based Honeypots are a good solution that alerts you when a real incident has occurred.
Considerations when implementing Web-Based Honeypots
Changing things in production, like adding new routes or resources can impact user experience so always use with caution. Always ensure the relevant stake holders are on board with these changes before implementing them.
In addition, the security team or any other relevant people, such as security champions should know the honeypot exists. Otherwise no one will be listening to the alerts coming in, or someone will simply remove the honeypots altogether (as they will likely flag your code scanning tools). So you’ll need to keep an inventory of the honeypots and their associated keys or accounts.
Conclusion
Web Based Production Honeypots are an underutilized tool that, if implemented correctly, can significantly reduce the time of detection whenever there is a breach in your production system. Implementing a Web Based Production Honeypot is relatively simple and low cost compared to other cyber security tools out there so I encourage security teams worldwide to experiment and be creative when adopting this strategy.