Honeytraps are a class of detective controls that work by leaving little false treasures lying about for people to find. And when they open, use, or transfer those items you’re notified immediately that someone’s doing something they shouldn’t.
The key concept is that you put these treasures in places that would not be accessed legitimately . This way you can be sure that if they’re touched it’s a malicious event.
What I like about Honeytraps is that they work especially well when the rest of your defensive infrastructure is not where it needs to be. Let’s say you have 10,000 servers that you should be capturing extensive logs for, monitoring those logs, and doing incident response on. Very few companies have that infrastructure in place, but they might be able to put 50 honeytraps out that absolutely tell you when someone’s there.
So the extreme idea is that you can either detect malicious activity by monitoring infinity in a perfect way, or you can do it by putting one 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.
Anyway, let’s talk about some of the trap tactics.
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 network space internally, 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 metaSo 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 Isis, 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!