4 ms·

Decoy Defenses: How Honeypots Sweeten Cybersecurity Strategies

15 points by iphone14pro 3y ago

bigbacaloa 3y ago
Reads like an AI generated essay.
- nubinetwork 3y ago
  Everything on their blog does have a fake feel to it...
- hosteur 3y ago
  Agreed. Strange how it made front page. With only 6 point no less.
- clemailacct1 3y ago
  Yeah, it was a very shallow read. This read to me like AI generated content and not so,etching written by someone with hands on experience deploying honeypots or tokens.
denton-scratch 3y ago
> One such innovative strategy is the use of honeypots Innovative? Honeypots have been around since forever. A modest article, with much to be modest about.
_8j50 3y ago
Both honeypots and canaries have one rule that makes them hard to implement: the moment they generate false positives to where a human has to spend time investigating the cause, they become ineffective. They are not meant to be alert sources that tell you bad stuff is happening, they are supposed to be high fidelity indicators of a compromise. So, internet facing honeypots are usually not useful for detection because everybody and their mother is trying to hack you on the internet. The conditions you could monitor for on honeypots, you almost always should be monitoring on prod boxes too, so the value is more limited there. If you have internal honeypots then failed attempts to compromise them should be ignored and they should be AD joined (long topic). The purpose of internal honeypots is to detect lateral movement and to an attacker, they should not look any different than any of your other similar devices. So, if I have an ssh key,domain password or dumped nthash/kerberos ticket, it should work just same on the honeypot. Furthermore, once compromised they should have content like files and apps that makes them look legit so the threar actor can spend time enumerating on the honeypot so you can learn about their intentions. But most importantly, they should not gain more accesss but they should be able to pivot using existing access from the honeypot to elsewhere. Lastly, I am more of a fan of canaries staged right. New-HoneyHash.ps1 is my favorite. For linux admins, I suggest having a legitimate user account that can't sudo and has password/creds expire like any human user and then deploy that user with private keys that can access other things all over your environment and setup centralized SSH login monitoring. The moment that account is used to login to anywhere should page every admin/security person. And you can use this types of canaries on internet facing stuff.
- hosteur 3y ago
  > If you have internal honeypots then failed attempts to compromise them should be ignored and they should be AD joined (long topic) Would you mind elaborating a bit on this?
  - _8j50 3y ago
    Failed attempts generate FPs when random vuln scanners or noisy apps used by IT people try to "discover" resources by attempting logins using whatever credential they have. You want it to be AD joined because if it isn't, you miss out on the most popular means of lateral movement: using domain user/service accounts. Typically bad guys run adfind, sharphound or the like to find easy and valuable targets and attack paths. The honeypot should show up as a valuable target that is only slightly misconfigured (e.g.: domain users can RDP to it and it runs interesting services), so attackers would move to the honeypot using domain credentials that are legitimate. I should have said this in my original post but measures like this and threathunting done right can catch even the most sophisticated APTs (catching them is only the start though)
    - entropyie 3y ago
      Internet facing honeypots have a place in detecting threat actors in the "pre-attack" phase (see MITRE), but you need a more sophisticated methodology to filter out all the background noise from script kiddies. You may find that threat actor's OpSec is less disciplined in the pre attack phase also, meaning you get more chances for real attribution.

15 points by iphone14pro 3y ago

bigbacaloa 3y ago

Reads like an AI generated essay.

nubinetwork 3y ago
Everything on their blog does have a fake feel to it...
hosteur 3y ago
Agreed. Strange how it made front page. With only 6 point no less.
clemailacct1 3y ago
Yeah, it was a very shallow read. This read to me like AI generated content and not so,etching written by someone with hands on experience deploying honeypots or tokens.

denton-scratch 3y ago

> One such innovative strategy is the use of honeypots Innovative? Honeypots have been around since forever. A modest article, with much to be modest about.

_8j50 3y ago

Both honeypots and canaries have one rule that makes them hard to implement: the moment they generate false positives to where a human has to spend time investigating the cause, they become ineffective. They are not meant to be alert sources that tell you bad stuff is happening, they are supposed to be high fidelity indicators of a compromise. So, internet facing honeypots are usually not useful for detection because everybody and their mother is trying to hack you on the internet. The conditions you could monitor for on honeypots, you almost always should be monitoring on prod boxes too, so the value is more limited there. If you have internal honeypots then failed attempts to compromise them should be ignored and they should be AD joined (long topic). The purpose of internal honeypots is to detect lateral movement and to an attacker, they should not look any different than any of your other similar devices. So, if I have an ssh key,domain password or dumped nthash/kerberos ticket, it should work just same on the honeypot. Furthermore, once compromised they should have content like files and apps that makes them look legit so the threar actor can spend time enumerating on the honeypot so you can learn about their intentions. But most importantly, they should not gain more accesss but they should be able to pivot using existing access from the honeypot to elsewhere. Lastly, I am more of a fan of canaries staged right. New-HoneyHash.ps1 is my favorite. For linux admins, I suggest having a legitimate user account that can't sudo and has password/creds expire like any human user and then deploy that user with private keys that can access other things all over your environment and setup centralized SSH login monitoring. The moment that account is used to login to anywhere should page every admin/security person. And you can use this types of canaries on internet facing stuff.

hosteur 3y ago
> If you have internal honeypots then failed attempts to compromise them should be ignored and they should be AD joined (long topic) Would you mind elaborating a bit on this?
- _8j50 3y ago
  Failed attempts generate FPs when random vuln scanners or noisy apps used by IT people try to "discover" resources by attempting logins using whatever credential they have. You want it to be AD joined because if it isn't, you miss out on the most popular means of lateral movement: using domain user/service accounts. Typically bad guys run adfind, sharphound or the like to find easy and valuable targets and attack paths. The honeypot should show up as a valuable target that is only slightly misconfigured (e.g.: domain users can RDP to it and it runs interesting services), so attackers would move to the honeypot using domain credentials that are legitimate. I should have said this in my original post but measures like this and threathunting done right can catch even the most sophisticated APTs (catching them is only the start though)
  - entropyie 3y ago
    Internet facing honeypots have a place in detecting threat actors in the "pre-attack" phase (see MITRE), but you need a more sophisticated methodology to filter out all the background noise from script kiddies. You may find that threat actor's OpSec is less disciplined in the pre attack phase also, meaning you get more chances for real attribution.