Skip to main content

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 little value to the user. 

Additionally more hosts are now part of the network, leading to visibility in countries and locations that were previously not available/reported on. 

We consider this an important explanation as it should be clear that our goal is not to bump the numbers but instead focus on providing an actionable service. That will always be our goal with the project and the increased size of the lists doesn’t come at the cost of quality.

When we're talking about numbers we can't ignore what goes into them. It's not our goal with the project to provide users with information that an Internet scanning project just queried our server (and possibly, subsequently, whoever relies on the lists). That's why, from the beginning of the project, we've included information to request feedback (if you happen to run into a "legitimate scanner") as well as developing PTR Bouncer, our community project that aims to document scanners and, through a MISP Warning List and a script, keep them away from any IP list.

Seeing as most of the projects that are doing surveys of the Internet go through the process of setting up a proper PTR record (often requested by the ISP to avoid abuse complaints towards them), we feel like looking for PTR records is a good way to prove ownership of a scanner so that it can be whitelisted. 

Like everything we do, we'd love to hear your feedback and thoughts on this approach. While we're happy to whitelist individual IPs, we feel this approach does not scale nor provide a proper fix. 

📉 Everyone likes stats!

3CORESec Blacklist 📓 serves an average of 25k retrievals every day. The ~2500 offending IPs present in the lists are generated from ~300.000 events in a 24 hour period. The lists are generated 4 times per day to maintain a low level of indicator decay. That is, if you making this information actionable, it's with good certainty that we very recently saw that IP (or multiple) participating in whatever category we reported them on.

The events are registered by our network of 12 hosts in 9 different countries. The lists are downloaded in ~50 countries on a daily basis. The Netherlands is the most active country. 


Users rely more in the individual lists than the combined list:

Future

We have some interesting features being developed for Blacklist 📓 which will be available in the upcoming weeks. From providing more ways to interact with the data as well as making new content/indicators available for download. Stay tuned!

Feedback & Researcher Access

If you're a researcher that would like access to the Blacklist 📓 backend so that you can - amongst other things - query for specific information and look for trends, feel free to reach out to us. While we can't guarantee that we'll provide access to everyone, if the work you're doing is for the public good, we'd love to be a part of it.

Have any ideas of additional indicators that you'd like us to share, or a cool deception technique that you feel would make the project better, we'd love to hear about it. 

While we're on the topic of deception, did you ever gave our Trapdoor project a try? Wes, from SecurityOnion, wrote an excellent article on how he's deceiving adversaries with Trapdoor and logging it in SecurityOnion.  

Lastly, if you'd like to work on security deception or general information security research, we're hiring! Ping us on Twitter or join our Community Slack.

Popular posts from this blog

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

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 ta