- Unsupervised Learning
- Posts
- Implementing Honeytokens, Honeynets, and Honeytraps With Zero Budget
Implementing Honeytokens, Honeynets, and Honeytraps With Zero Budget
Honeytraps are a class of detective controls that work by leaving false treasure lying about for attackers to find. When they take the bait you’re notified immediately that something’s up.
The key concept is that you put these treasures in places that would not be accessed legitimately. This way you can be relatively sure that if they’re touched it’s an actual malicious event.
What I like about Honeytraps is that they work especially well where security isn’t that mature yet. Let’s say you have 10,000 servers that you should be capturing extensive logs for, monitoring those logs, and doing incident response on. Far too few companies have that infrastructure in place, but they might be able to put 3-10 honeytraps out that tell you when someone’s there.
An extreme illustration says you can either detect malicious activity by monitoring infinity in a perfect way, or you can do it by putting one single juicy item out there that you’re sure any attacker would definitely go after. You find the bad guy either way, but one is, well, infinitely less difficult to implement.
That’s extreme, but it shows the point. Let’s talk about some of the traps you can set.
Various Honeytrap techniques
Leave a backup.zip file in the root of your web servers. Place files in it that call home to you when opened. Think, 2014-Taxes-Sanberg.xls and source-snapshot.zip. Violently log and respond.
Place a juicy false directory in a place that nobody normally accesses, i.e. in a place that you only find by exploring, not by doing normal work. Violently log and respond.
For insider threat, place an interesting directory or file nearby others that are normally used, e.g., a directory called Updated Salaries or 2017 Management Strategic Plans. Violently log and respond.
Place rows and tables in your databases that are full of data and look interesting, but that aren’t queried as part of your applications. Have extremely unique strings in them that, when seen, indicate that foul shit is happening. Violently log and respond.
[ NOTE: Be aware that Honeytrapping is a form of trolling, and if you troll the wrong person it’s like poking a bear and yelling, “I’ve got your cub! I’ve got your cub!” while laughing and running away. It doesn’t mean you shouldn’t do it; just keep in mind that there’s a tradeoff when you’re basically running a CTF on your network. Ideally you’d keep your traps as silent and non-trolly as possible. As you add trollishness you potentially add unwanted scrutiny. ]
Use low-interaction Honey Listeners in your DMZ that capture connections, credentials, and (potentially) what they do if you give them a shell. These systems aren’t part of your actual infrastructure so unless there’s a misconfiguration you should get very little traffic to them. That’s why it’s good to monitor them. Violently log and respond.
[ NOTE: If you’re doing any security testing of your own, that’s likely to be one of the main sources of traffic to your Honeytraps. Find a way to tune that noise, but be cautious of false negatives if you do it incorrectly. ]
Create breaks in your internal network space, such as going from 10.26.5.0/24 to 10.26.7.0/24 (skipping 10.26.6.0). Place Honey Listeners there, IDSs, etc. Any intelligent, manual, or interactive behavior there should not be legitimate since none of your applications are actually pointing to that network. Violently log and respond.
Set incorrect HTTP Server headers (like Apache when you run Nginx), and capture activity that targets the fake tech specifically (this works for any fake tech, not just web). Violently log and respond.
Place comments in your source code that look like developer notes that were left behind, like, “Remove master cookie before production: 3xY022-n8m91Q-tt1cV0-P9v7rE”. If you see that cookie being set in any of your infrastructure, you have a real attacker. Violently log and respond.
Honey meta
So here are some general concepts that apply regardless of which detection points you use.
The more manual the discovery technique that is required to find your Honeytrap the higher the priority you should log (and respond to) it at
Try to set up as many ways to detect as possible. File access logging, firewall detection capabilities, HIPS/HIDS, NIPS/NIDS, etc.
Keep in mind the tradeoff above of potentially intriguing attackers with your traps. It’s not a huge relative concern, however, if you’re in bad shape defensively. They probably have easy access to your stuff anyway. Just realize the best thing you can do is 1) have solid defenses, and 2) not be targeted. Don’t let your trap infrastructure break number two.
Summary
You can do some extremely effective Honeytrapping for very little time/money.
Remember that this is a layer on top of, or a stop gap before, real security. Don’t use this as a replacement.
The more you deploy the better, but remember to make your detection and response workflows as simple as possible. Don’t give yourself too much work that takes you off the task of doing real security.
Control the impulse to be cute and trolly in your traps. Bears have more time than you do.
Happy trapping!
Notes
For the love of Crom, don’t take my points above to mean you can do Honeytrap Defense instead of actually logging, monitoring, and responding. No. That’s not what I’m saying. I’m saying that if you’re a soup sandwich then you can use this to help you while you’re getting sorted out (and after as well).
Adding to the previous point, the better your fundamental defenses, the less benefit you’ll get from Honeytraps, for the simple reason that you’d notice those probes and things already in other ways. They still will have value in a mature shop, however, just not as much. You should still do both, though. It’s about the layers, after all.
There are also commercial tools that can help you with this infrastructure. Canary is one such offering, but this post focuses on the different things you can do for free.
If you give attackers a real shell as part of a Honeypot, realize that you’ve made a lot of extra work for yourself. If you’re doing Honeytraps as a stop-gap for real security, stop it. Go get your full logging and response infrastructure going before you implement this type of high-maintanence technique. Also, mind the trolling advice above.
I’ll continue to add more trap techniques as I remember them. If you have any cool ones let me know!