Skip to main content

Trapdoor - The serverless HTTP honeypot

 

Today we are announcing the release of Trapdoor, our AWS-based serverless honeypot. 

The idea of a serverless honeytoken isn't new. Adel released his honeyLambda a few years ago and we've been working with it for quite some time. It was because of this experience and the goal of improving on what was already a great idea that we decided to go to the drawing board and see how we would change and tweak the concept. 

What is it?

Trapdoor is a serverless application that can be deployed in any AWS environment. Its goal is to receive HTTP requests with the intent of identifying, and alerting, on its visitors. The URLs generated by Trapdoor can also be referred to as honeytokens. 

While you can get creative on how to use it, one of the goals of a honeytoken is to be hidden or stored in a "safe" place and, if accessed, fire of an alarm, as access to the token would be considered a compromise or unauthorized access. 

This example is the passive way of using deception tactics. Additionally users can also create Trapdoor tokens and save them inside of other honeypots. Much can be said about ideas to trick a botnet operator to move away from the zombies and make the operator himself access a URL, but we'll leave you to figure that part out. 

Features of Trapdoor

Trapdoor has two deception mechanisms:

  • HTTP session & User Agent
  • Client Fingerprinting

In HTTP mode we will retrieve and notify on what is available in an HTTP session (IP, location, device type, etc) and User Agent (browser, OS, etc). Information from HTTP is always available and the Trapdoor operator will always be alerted on it. However, if the visitor allows JavaScript to run, we deploy the client fingerprint payload. 

In Client Fingerprinting mode Trapdoor will, aggressively, attempt to retrieve a wide range of information from the client, namely:

  • Screen resolution
  • Laptop battery level
  • If browser is in Incognito mode
  • If the visitor was utilizing Tor to access Trapdoor
  • CPU type
  • and more!

It is important to mention that since Trapdoor is very much in an alpha stage changes to the reported information will likely occur based on our experience as well as community feedback (which we'd like to receive).

Stateful client fingerprint and tracking

Another interesting feature is that Trapdoor will also attempt to create a unique identifier per client/visitor and save that information so that we can maintain a state of that visitor's actions (how many times a particular user accessed a honeytoken and other information). Trapdoor tracks and reports based on two identifiers: 

  • Visitor IP Address
  • Unique Client Fingerprint

This allows us to report not only on individual, ad-hoc visits, but also provide a history-aware alert when notifying users of access to their honeytoken.

The main motivation for developing the stateful client fingerprinting was to create the ability to track visitors who might hop between exit nodes (from a VPN, Tor, etc). With this feature we will attempt to track the user and provide that information on the alert. Before moving on to the alerting section, here's a quick example of how this feature translates into actionable tracking:

Alerting

We went back and forward on which methods we should support. Ultimately we decided to rely on Slack messages as those provided us with the highest level of control and interactions

An interesting aspect of notifications, and as concerned users of alert fatigue, Trapdoor will first report access to the honeytoken using the HTTP-derived data. If the JavaScript-based methods are successful, that same message will be edited to include the additional information that was gathered by the second deception method.

A notification (and these will age poorly with time as we continuously change how it looks) will look something along the lines of:

Early release and community contributions

We considered releasing Trapdoor after we went through additional testing but eventually decided against it. It is important to mention that this is a very early release and while we're actively improving the application things will change (and possibly break) frequently. 

All installations of Trapdoor through the AWS SAR benefit from the latest code changes. You're encouraged to keep your deployment updated to make use of these changes.

We'd also love to have community involvement in this project. Let us know of any ideas you have for improvements or any bugs you run in to. Contributions in terms of features to Trapdoor are also very much encouraged and welcome. If in doubt about contributing, reach out to us. We'll help you out.

Legal notice

3CORESec is releasing this project as a proof-of-concept for the research community.

Please remember that it might not be legal to run Trapdoor in some countries and that the information you will be accessing could be considered personal data.

If you decide to deploy, install or run Trapdoor you will be agreeing to release and hold us harmless from any responsibility resulting or arising directly or indirectly from the use of Trapdoor.

You are solely and exclusively responsible for the use of Trapdoor.

Feedback

Feel free to reach out to us on Twitter or joining our Community Slack. We'd love to hear what you think of Trapdoor and maybe add some features to it.

Labels:

Popular posts from this blog

Community Update - 3CORESec Blacklist 📓 🍯

Recently we tweeted about some issues we had with 3CORESec Blacklist , a platform that shares - openly and freely - a subset of the information seen and processed by our honeypot network.  While those issues have been addressed, and seeing as significant changes were made to how we monitor the generation of the lists (which is reflected in our status page ) and how we determine if an IP should be listed as an offending IP or not, this felt like a good opportunity to write a bit more about the platform as well as the changes we made.   For regular users of Blacklist 📓 the first thing they’ll notice is an increase on the numbers of IPs we include. That is a direct result of the changes we made and the growth of the honeypot network itself. We have not - and will not - ever increase the period for which we query the honeypot network, as we believe anything higher than 24h (as specified in the project page) for IP addresses can quickly fall into a decaying state that adds litt...
Read more

Detection as Code (DaC) challenges - Introducing Automata

This blog post is the second part of our Detection as Code (DaC) challenges series. You can read part one here . The development process of detections by itself doesn't pose a lot of barriers for security engineering teams, as they are typically done in a lab/controlled environment, but after tuning and deploying rules to a SIEM, the work is only starting. Many things can go wrong after this, and a process of continued and automated testing is crucial. Detection Validation In an ideal (and fictional) world, once the datasets are parsed, normalized, and put into production, detections developed by your team would work forever. Still, the reality is quite different. Maintenance is heavy work that needs to be done frequently - especially if you work on an MSP - but the reality is that the ecosystem lacks tooling and processes to do it proactively. Effectiveness is an important metric and crucial to the successful response of incidents in time, and effectiveness is what we aim to ensu...
Read more