3 ms·

I'm wondering, given how threat actors normally behave when intruding into networks, do you also have honey user credentials in the network? I don't imagine yo

by SCHiM 6y ago

I'm wondering, given how threat actors normally behave when intruding into networks, do you also have honey user credentials in the network? 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?

merlinscholz 6y ago
Internal honeypots as early warning system are called Canaries. Usually they run on a just slightly outdated and vulnerable software version, so that an attacker does not need credentials. One example would be emulating a forgotten file server with SMB1 enabled. The homepage of Thinkst Canary https://canary.tools/ https://canary.tools/ gives a good overview.
- waihtis 6y ago
  Canaries has been pretty much replaced by decoys as the "official" term, as denoted by the MITRE SHIELD framework: https://shield.mitre.org/matrix/ https://shield.mitre.org/matrix/
  - qwantim1 6y ago
    Canary (in a coal mine) makes more sense to me if the goal is an early warning system.
waihtis 6y ago
> I'm wondering, given how threat actors normally behave when intruding into networks, do you also have honey user credentials in the network? 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.
- SCHiM 6y ago
  So say you're in charge at a financial organization, and you're sprinkling fake alliance servers here and there in your network. How is that going to catch an actor like lazerus? 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.
  - waihtis 6y ago
    Actually in this scenario an alliance server may be a poor asset to replicate specifically because of what you stated - if the attacker is watching the traffic it's easy to spot. The more powerful place would be to be interferring with in the lateral movement stage, since there's bound to be some of that in any given attack. 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.
    - SCHiM 6y ago
      Right but that's just it. I've always toyed with the idea of honeypots in my mind. But I'm not sure what type to incorporate into existing security measures. 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...

by SCHiM 6y ago

merlinscholz 6y ago

Internal honeypots as early warning system are called Canaries. Usually they run on a just slightly outdated and vulnerable software version, so that an attacker does not need credentials. One example would be emulating a forgotten file server with SMB1 enabled. The homepage of Thinkst Canary https://canary.tools/ https://canary.tools/ gives a good overview.

waihtis 6y ago
Canaries has been pretty much replaced by decoys as the "official" term, as denoted by the MITRE SHIELD framework: https://shield.mitre.org/matrix/ https://shield.mitre.org/matrix/
- qwantim1 6y ago
  Canary (in a coal mine) makes more sense to me if the goal is an early warning system.

waihtis 6y ago

> I'm wondering, given how threat actors normally behave when intruding into networks, do you also have honey user credentials in the network? 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.

SCHiM 6y ago
So say you're in charge at a financial organization, and you're sprinkling fake alliance servers here and there in your network. How is that going to catch an actor like lazerus? 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.
- waihtis 6y ago
  Actually in this scenario an alliance server may be a poor asset to replicate specifically because of what you stated - if the attacker is watching the traffic it's easy to spot. The more powerful place would be to be interferring with in the lateral movement stage, since there's bound to be some of that in any given attack. 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.
  - SCHiM 6y ago
    Right but that's just it. I've always toyed with the idea of honeypots in my mind. But I'm not sure what type to incorporate into existing security measures. 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...