Guide
Active Directory decoys
Fake accounts and a fake server in your own domain, placed where attackers look first. Any use of them leads to a Kandaro decoy.
Why Active Directory
Once someone is inside a Windows network, one of the first things they do is list the domain: users, service accounts, admins and servers. A few tempting entries in that list that lead nowhere real are some of the most reliable bait you can plant.
What gets created
In the Console, open Bait & breadcrumbs → Active Directory and choose a decoy. Kandaro generates a script for your domain. Your admin reviews it and runs it; Kandaro never connects to your domain and never receives domain credentials. The script creates exactly four things, and changes nothing that already exists:
- A service account (default
svc_sqlbackup) with a service principal name on the fake server, the kind of account attackers single out. - An admin-looking user (default
adm_backup). - A computer object and a DNS record for a fake server (default
vault01) that resolve to your Kandaro decoy.
Both accounts get a random 32-character password, stored by Kandaro as a fingerprint only, so the script is shown once. Names are editable; the defaults are chosen to look ordinary. No description mentions Kandaro or decoys.
Why these accounts can’t be used for real
Both accounts are denied every logon hour on your real domain, may only log on to the fake server, are never trusted for delegation and join no groups. Using them against a real domain controller fails. The decoy recognises the password itself, so trying it there raises a bait used alert that names the account.
Optionally, Kandaro can put the admin account’s password in its description, a classic mistake attackers search for. It makes the bait far more likely to be tried. It is off by default; turn it on deliberately.
Running the script
Always run it with the dry run first. It stops without changing anything if any of the names already exist.
# In an elevated PowerShell on a machine with RSAT (ActiveDirectory and DnsServer modules):
.\kandaro-ad-decoys-corp.acme.local.ps1 -DryRun # shows what it would do, changes nothing
.\kandaro-ad-decoys-corp.acme.local.ps1 # creates the decoys# As root on a Samba 4 domain controller:
sh kandaro-ad-decoys-corp.acme.local.sh --dry-run
sh kandaro-ad-decoys-corp.acme.local.shKeep the script private and delete it after use. To remove the decoys, delete the set in the Console: you get an undo script that removes exactly those objects, and only while they still look the way Kandaro created them.
What this does and doesn’t catch, today
- Caught: anyone who tries one of the accounts’ passwords at a Kandaro decoy, and anyone who connects to the fake server.
- Not yet: an attacker requesting a ticket for the service account to crack it offline (Kerberoasting) happens on your domain controller, not on a decoy. Catching that moment needs the domain controller’s logs, which is a later phase. With a 32-character random password the crack won’t succeed, so the attacker never gets a working password.
Up to 20 sets per organization.