Active Directory Login Canarytoken

The Active Directory Login Canarytoken allows a user to receive alerts when specific credentials that have been planted are used by an attacker. This article runs through how to set up a Canarytoken, and how to get the most use out of them.

Setup

Note: this Canarytoken is intended for deployment on a Domain Controller, and can only trigger while that machine is powered on.

Create an Active Directory Login Canarytoken on your Console and enter a memo that will help you remember where this Canarytoken has been deployed. Some plausible-sounding artificial usernames are randomly generated here that will trigger the Canarytoken, but if you'd like to enter your own fake usernames you can do so at this stage. Note that once the Canarytoken is created, those usernames are read-only.

Download the Canarytoken - you'll receive a PowerShell script that you can run as follows:

The script will run and set up a Scheduled Task that will monitor for these usernames, and trigger an alert when they're used. Note that these are not real accounts - and if any of the usernames that were specified at creation time are real accounts, they'll be excluded from the list of fake usernames.

That's it, your Canarytoken is now ready to trigger!

If you'd like to test it, run something like:

runas /user:token_username_here cmd

and enter anything as a password, then head over to your Console to catch the alert coming through.

Note: As part of the Canarytoken's deployment via the script, audit policies on your domain are edited to enable auditing of failed authentication attempts. This has been known to fail due to the presence of an audit.csv file. If you run into errors during the Canarytoken setup relating to audit policies, delete the file on the Domain Controller which is usually found at C:\Windows\system32\grouppolicy\machine\microsoft\windows nt\audit\audit.csv and try to run the script again.

Alert fields

When an alert is triggered, you'll see a few fields that are captured:

• Date - the time of the incident
• Source IP - your attacker's IP, note this is different to the source IP higher up in the modal, which corresponds to the DNS server IP
• Source host - attacker's machine name from where the login attempt originated
• Username - the fake username that was tried
• Domain controller - the DC where the failed login was registered
• Event record ID - the unique ID of the event in your Windows audit log

Using a simple PowerShell command on the machine where the audit log entry is stored, you can search for more information from this specific event:

$event = Get-WinEvent -FilterXPath "*[System/EventRecordID=588620]"
$event | Format-List *

where 588620 would be the Event record ID you're searching for in the event log.

Alternatively you could search in the Event Viewer UI, which will also show you all the available information relating to this specific event:

Canarytoken heartbeats

This Canarytoken type also includes a heartbeat, which allows us to see how long it's been since a Canarytoken was last seen (so you know it's alive and kicking, ready to trigger). This will show up on the Canarytoken pane as a duration since the last check-in, which is usually every minute.

Deleting your Canarytoken

If you'd like to delete the Canarytoken, you'll need to delete it on your Console, and also run a PowerShell command to clean up the scheduled task that was created. Grab it from your Canarytoken's pane in the console and run it on the domain controller:

powershell.exe Unregister-ScheduledTask -TaskName your-unique-task-name -Confirm:$false

Ideas for catching attackers with your Canarytoken

Attackers tend to use tools to quickly search for credentials that may be stored in plaintext in common locations across your Windows environment. By leaving your Canarytoken's usernames (and some made-up passwords) lying around in these places, you'll stand a better chance at seeing attackers bump into these fake credentials which they're sure to try.

Let's take a look at a few simple things you could do to get started to plant these credentials:

1. A simple "domain_credentials.txt": it may sound too straightforward, but simply leaving these usernames in a text file with some fake passwords would be an easy way to leave them somewhere they'd be stumbled upon in the event of a breach. We've done this for you already, ready to download from the Canarytoken's pane in your console.
2. Inside unattend.xml: local admin passwords are known to be stored here, so taking the time to add in your tokened usernames with some fake passwords could also bring them across the path of an attacker. There are guides online around this, like this source.
3. Web files and IIS config: web folders are also known to contain usernames and passwords, such as inside web.config or connectionstrings.config usually found at C:\inetpub\wwwroot, so adding your Canarytoken credentials here could be a good idea.

These are just 3 simple ways you might want to try to plant your Canarytoken's credentials to increase the likelihood they'll be found by an attacker, but searching online for where attackers find plaintext usernames and passwords on Windows machines will lead you to many other alternatives you may like to try. If you'd like assistance with this, we'd be happy to help get you started, just reach out to us.