AD decoy accounts
AD decoy accounts are accounts in your domain that attack tools single out, but that nobody uses. Nobody has a reason to request a ticket for them or sign in with them, so any attempt means someone is attacking your domain right now. A task on every domain controller reports those attempts to a custom honeypot. Each alert shows the source address, and the account that made the request when there is one. [!NOTE] AD decoy accounts are in beta. Whether you can use them depends on your plan: they're included with custom honeypots in the Professional plan and higher (see Subscription). They come in the same signed download as the AD CS decoy. The decoys Decoy What attackers see What alerts Alert Kerberoasting A service account with an SPN (for example MSSQLSvc/… or HTTP/…) that allows RC4, the classic Kerberoasting target A request for a service ticket for it kerberoast, critical: the account that asked and its address AS-REP roasting An account with Do not require Kerberos pre-authentication A ticket request for it without pre-authentication asrep_roast, critical: the source address Planted credentials An account whose password is in a Group Policy Preferences file in SYSVOL (a mapped drive with a saved password). Every attack toolkit decrypts these. Any attempt to sign in with that account gpp_credential_used, critical: the source address or computer Password-spray canaries Accounts named like common spray targets (for example helpdesk, backup, test) A failed sign-in for one of them password_spray, high: the source address or computer Kerberoasting and password spraying are among the most common ways attackers get further in Active Directory. Tools such as Rubeus, Impacket, NetExec and BloodHound point attackers straight at accounts like these. How the decoys stay safe The passwords can't be cracked. Each decoy has a 120-character random password that nobody sees or knows, so the tickets attackers get by roasting are useless. The planted account can never sign in. Its password is in SYSVOL on purpose, so its logon hours are set to none: every sign-in fails, and is reported. The GPO holding the file is linked nowhere, so it applies to no computer or user. No rights. The decoys are in no group but Domain Users, and are marked sensitive and cannot be delegated. Fail closed. If a decoy is ever added to a group, given admin protection (adminCount), or (for the planted account) allowed to sign in, the task disables it at once and alerts you. To do that, the installer lets domain controllers change one property of the decoy accounts, the one that disables them. A decoy signing in successfully is reported as critical. It should never happen. Before you start You need: A domain controller to run the installer on, and a Domain Admin account, used once. The task runs as SYSTEM. HTTPS access from every domain controller to your OrbitalCyber address. PowerShell remoting (WinRM) from that domain controller to the others, so the installer can set up the watcher on them. It's on by default on Windows Server. Without it, you set up each domain controller by hand (see Set up a domain controller by hand). Tell your AD team about the decoys, so nobody deletes them, uses them, or "fixes" them. Set up the decoys Go to Honeypots > Custom. Under Add a honeypot, select AD decoy accounts, then the Set up tab. Select Create and download the config file. Your browser downloads orbital-ad-decoys.json, which holds the custom honeypot's token. It isn't shown again. Select Download the signed installer and unzip it on a domain controller, next to the config file. Choose the decoys and their names in the form (see Decoy names). The console writes the install command from it. On that domain controller, open Windows PowerShell as administrator, signed in as a Domain Admin. In the installer's folder, run the command the console shows. It looks like this: Confirm when asked. The installer lists each domain controller as it sets it up. Delete orbital-ad-decoys.json…
OrbitalCyber documentation