You'd still have to know which exchange the call was coming from, to track it that way.
And he drives RC forklift under his house to store Klein bottles he's selling! https://www.youtube.com/watch?v=-k3mVnRlQLU
I don't imagine you're catching many serious attackers just by exposing fake servers vulnerable to MS17 for example.
Could you explain more about your strategies and which types of attackers you can say you'd catch with surety?
Yes, for some types of honeypots credentials can be useful. Although it bears to keep in mind that the more accessible you make your honeypots, credentials, and other "detection elements", to more you open yourself to false alarms. Some vendors in our space plant credentials to every endpoint and I've heard mostly negative results (legitimate users clicking stuff out of curiousity, which completely destroys the key benefit of using honey/deception things.)
> I don't imagine you're catching many serious attackers just by exposing fake servers vulnerable to MS17 for example.Could you explain more about your strategies and which types of attackers you can say you'd catch with surety?
One use case we suggest is tying your honeypot strategy with your existing internal vulnerability & threat management, in practice for example circulating the types of honeypots you have to reflect acute, high-value vulnerabilities - or for slightly more advanced orgs who are on top of their threat intelligence, they could actively plant honeypots that match asset types threat actors in their industry space have been known to target.
Tie that with creds, integrations and such where applicable and you have a pretty decent palette for catching events that also bear useful and timely security telemetry.
They're not going to scan your service, or attempt to attack it without observing actual workflows of their target's employees. If the employees are not using the honeypots, they won't either.
What strategy do you employ to catch attackers at that level? I'm not critical of honeypots in general. But I would like to know some success stories, since I have not witnessed their success myself, and have a hard time believing they'd help against attackers that have the skills to penetrate otherwise well defended organizations.
That being said, it's entirely possible large financial services has both resources & mandate to run something more effective, like build in-house detection suites or use other things that provide a better signal than honeypotting. As said in the original post, it's one way of doing it and depends on your use case whether it's a good one or not.
I primarily deal with big financials and fintechs. The problems they have are very difficult to solve. They are slow, have big legacy processes and tech and combine that with large targets on their backs. The signal to noise ration is very bad, given the amount of users and old weird tech in the network. They need something better than 1000s of "Suspicious file on machine" warnings EDR generates for them. Or "beaconing detected" every time a youtube endpoint changes or something.
They can only tackle one single security measure at a time, because any change is a Big Project given the existing infrastructure, red tape and ways of working.
I always come to the the conclusion that honeypots would not work. The security is good enough to ensure that the threats that do slip past will not make the mistake of scanning the network once inside. They'd probably not even notice there were any honeypots in the network.
To catch them when they're moving in the network you'd need to give them credentials that appear to give them the keys to the kingdom. Perhaps a user present on each machine that appears to be admin on a domain controller that does not exist? That'd be a honeypot server + credential...
My email is in my profile, so if you're up for it, send me a message. Seeing it's slightly unconventional to solicit chats via message boards so no hard feelings if not interested and if so no need to reply.
Thanks for the conversation any how!
One example would be emulating a forgotten file server with SMB1 enabled. The homepage of Thinkst Canary https://canary.tools/ gives a good overview.
You do need to consider the type of honeypot used - asking the question "what is the goal the adversary has" is a good question to ask and optimizing you honeypots based on that is a smart thing. An internal threat is going to look for specific types of assets, and you need to build honeypots (or decoys, as the modern lingo calls them) that look like those assets.
The question really was what the intention is, not the effect.
Catching attacks from within the organisation might just be a side-effect of catching remote hackers for example. The effect is then ‘both’, but the intention is the latter.
Why the question deserves a better answer than “why not both” is that the reasoning behind using internal honeypots is interesting. Which arguments speak for it, which against.
So let’s not kill this question thread with a too shallow answer.
I've seen decoys mentioned in infosec Twitter quite a few times recently (I think more about OSS ones), and I'd like to learn more about how they are generally actually used, what the expectations are etc.
Mitre SHIELD (shield.mitre.org) lays out the different types of capabilities there are in this domain but doesn't have a lot of practical how-to advice which is what I think you're more after.
If you think it would be helpful I can send you our "product guide" which touches a bit on the decoy best practices. If this sounds useful message me at simo@[the domain in my profile] and I'll send it over.
I might actually write something about it online also, sounds like it could be useful knowledge for many.
That should be reasonably easy to simulate, and (I'm guessing) Netbackup infrastructure would be significantly interesting to any hacker once they've popped an org.
That being said - I could easily see this as a future trend (targeting backups) and it is not remotely a bad idea.
With NetBackup (and probably other "Enterprise Backup" software too) the NetBackup master servers have ~root level access to pretty much every server in an Enterprise. Or at least, every server being backed up. Which is likely to be everything important. ;)
NetBackup master servers also have the capability to run commands (as root) remotely on systems-they-back-up, and have those commands not be logged by the auditing on the systems (or anywhere really).
To my mind, that seems like a handy thing for hackers to target. ;)
I could see use cases where you would involve others like IT or dev in the deception process..
The more interesting use case for most is planting these in your network internals, which gives an added benefit of early, high-fidelity threat detection in addition to the "threat intelligence" bonuses. It's not completely trivial to set up, but can be a reasonably quick way to build good detection capability into even very disparate environments.
A vast majority of organizations still lack good situational awareness of their infrastructures and this is one way of improving on that.