Deception technology and techniques are having a resurgence, expanding beyond the ‘traditional’ high/low- interaction honeypots, into honeyfiles, honeytokens and (as you may have guessed from title) honeyusers. Today is the culmination of a “what if?” idea I’d been thinking for years, actually started working on earlier in the year (but then 2020 happened), but is now released. For those that want to skip ahead, GitHub repo here.
As name suggests project deploys dummy users into an AWS account, which can then be lost, embedded or leaked in places an adversary may come across them. Created users have (*almost) no permissions to do anything, but that attempted activity can be monitored and alerted on, giving 100% true positive threat intel of unauthorised activity within your environment.
(*almost no permissions: Given AWS API model, STS call get-caller-identity will succeed; but this is a read only function providing metadata of the honeyuser itself.
N.B. if any cloud red-teamers are aware of an exploit that can chain from just the information leaked from this call, I’d love to know more)
Full information available in the projects ReadMe, but high-level architecture of the components deployed by Terraform:
Once created, any from the dummy user will trigger a notification, which can be consumed by whatever alert/monitoring/threatIntel platform you’re leveraging (or just a simple email)
If you don’t want to run some infrastructure as code scripts from a random InfoSecMonkey on the Internet (I won’t hold it against you). Take a look at Thinkst’ Canary project, where you can implement similar tokens (and MANY more, seriously, Thinkst deserve massive props, or at least a follow) without needing to get your hands dirty directly, and via a nice webUI.
Finally, I’ll end with a request: I’d love to end with a request: If you’re sprinkling deception users across your estate with this project (or any other method), I’d love to hear some war-stories if they’re not locked behind NDAs.