4. SAN FRANCISCO 2017
Honey techniques
The art of detecting malicious
behavior by monitoring attackers’
access to, and interaction with,
attractive false targets purposely
placed within your organization.
4
5. SAN FRANCISCO 2017
Many names
• Honey pots
• Honey nets
• Honey tokens
• Honey files
• Honey traps
• Honey $foos
5
6. SAN FRANCISCO 2017
Hidden (fake) treasure
• Leaving enticing things where
they might be found
• Could be anywhere in the stack
• Anywhere in the organization
• Key point is out of band of
normal operation
• More off-path = more signal
6
8. SAN FRANCISCO 2017
Time and place
• Key benefit is that it can magnify
a small team
• You might not be able to cover
everything (yet) with two people,
but you CAN respond to high-
signal events
• Don’t let this replace
fundamentals!
8
10. SAN FRANCISCO 2017
Network ranges
• Cut out a piece of your network,
and put only detection / response
there
• IDS it up
• 10.100.5.0/24, 10.100.7.0/24
• 10.100.6.0/24 is empty!
• Violently log and respond
10
11. SAN FRANCISCO 2017
Honey daemons
• Create application listeners on various
ports that shouldn’t be touched by normal
applications
• Can be in a DMZ, in the cloud, or on the
internal network
• E.g.: SSH listeners on non-standard ports
• Log bruteforce attempts
• Log and respond
11
12. SAN FRANCISCO 2017
Web servers
• Leave a backup.zip file in your
root directory for all those
dirbusters out there
• Put some stuff in it like
2014_taxes_copy2.html, etc.
• Have it launch a JS request for a
honey URL that you capture
• Violently log and respond
12
13. SAN FRANCISCO 2017
Web applications
• Leave a comment in the code for a god
cookie
<!– For test admin use
AdminCookie=sl2K9lwlel4gAksl7dA0LA7wl
-->
• If you see that cookie, there’s no way for
it to be legit
• Violently log and respond
13
14. SAN FRANCISCO 2017
File servers
• Create a juicy directory parallel or one level up from
a common access location
- Salaries2017
- Prohibited Content (admin)
- RestrictedHRFiles
• There are more chances for legitimate curiosity
here, so you may want to add additional filters
• Expect a good number of “um, you probably want
to hide this”, which is high noise and low signal
• Log and respond
14
15. SAN FRANCISCO 2017
URLs
• Have one or more URLs that sound juicy that
you log requests to
- admin.intranet.lan
- assetmanager02.company.com
• Nothing legitimate points to these URLs
• Incoming requests can provide some
information about the inquisitor
• Log and respond
15
16. SAN FRANCISCO 2017
Github
• Leave some API or SSH keys deep within your
repositories (maybe even deleted)
- API access
- SSH access
• Anyone using these are purposely rifling
through your content online looking for a way
in
• Violently log and respond
16
17. SAN FRANCISCO 2017
App credentials
• Leave credential sets sitting in various
places (web server, file server, github,
etc.) and wait for people to try to use them
• You can tie credential sets to different
locations, so you have some idea of
what was being explored
• You can rotate semi-frequently to get
more accuracy
• Violently log and respond
17
18. SAN FRANCISCO 2017
AWS
• Create fake AWS access keys
• Tie them to accounts that have no permissions
• Drop them at ~/.aws/credentials
• Configure CloudTrail and CloudWatch to log
and notify on key usage
• CREDIT: https://blog.komand.com/early-warning-detectors-using-
aws-access-keys-honeytokens
• Violently log and respond
18
19. SAN FRANCISCO 2017
DNS
• Hints to certain domains or hostnames that don’t
have any applications or servers associated with
them
• Note who tries to resolve those names
- assetmanager02.company.com
- backups.intranet.lan
• Zone files
• Asset lists (.txt or .xlsx)
• Log and respond
19
20. SAN FRANCISCO 2017
Database
• Create false databases, tables, and data
• Not used by any real applications
• Add names, numbers, URLs, and other content
that you can flag in IDS/IPS/DLP
• Will only get accessed if there’s a SQLi situation
or a complete server compromise
• Have some way of detecting that the contnent
was explored after the fact (website logs, phone
calls, values entered into fields, etc.)
• Violently log and respond
20
22. SAN FRANCISCO 2017
Logging without response is like
clapping with one hand
• Don’t wire up detectors without taking
them all the way to logging, alerting,
and responding
• Use your existing infrastructure if you
have it
• Try to avoid super-custom texting to
one person, etc. Make it operational
• Test periodically to make sure
detection and response is still working
22
24. SAN FRANCISCO 2017
There are downsides to running a CTF
on your production network
• Honey traps are an awful lot like trolling
• If you build it, they might hack
• Attracting attention is sometimes the
worst thing you can do
• Temper your honeythings to be fun,
self-deprecating, etc.
• Don’t throw down gauntlets, taunt, etc.
• They have more time than you do
24
25. SAN FRANCISCO 2017
Honey maturity
• Low interaction is better for lower
maturity shops
• The more manual and out of band the
trap, the higher the signal
• If you have the time to watch attackers
play in high-interaction honeypots, you
should probably be spending that time
improving your fundamental defenses
• Monitor your time sink carefully; don’t
let it dominate your strategy
25
27. SAN FRANCISCO 2017
Implementing in the real world
• Visibility is key!
• A little can go a long way
• Focus the traps around your jewels
(app/net/cloud/db/etc)
• There are commercial options as well
(CanaryTools is one) HT Haroon Meer
• It’s best to have signal from everything, but
honey techniques let you shortcut by getting
high value signal from very few things
• Fundamentals > honeyfoos
27
28. SAN FRANCISCO 2017
Interact
• @danielmiessler
• daniel.miessler@ioactive.com
• https://danielmiessler.com/podcast
28