Deception Technologies
Overview
It is becoming increasingly difficult to stay ahead of threat actors, however, there are some defence mechanisms that can be employed by cybersecurity teams to assist with detecting adversaries. Security teams can utilise deception technologies to create honeypots within the environment to catch anomalies before they manifest into a cybersecurity incident.
Deception technologies aim to deceive attackers by creating traps and decoys across the environment to imitate genuine accounts, files or assets. Once the adversary triggers the decoy, an event or log will be generated for (hopefully) further investigation by the security team. These honeypots and alerts will assist with decreasing the dwell time of attackers within the network, thus expediting the average time to detect and remediate threats before they become a problem.
This post will demonstrate some zero cost deception technologies that can be easily implemented by administrators and security teams to assist with catching threat actors. The technologies covered will include injecting fake credentials with Cmdkey, honeypot kerberos accounts and canary tokens.
Cmdkey
Cmdkey is the command line utility for Windows credential manager, which can be used to create, list and delete stored usernames, passwords or credentials. Cmdkey can legitimately be used by administrators to run scripts using credentials stored withing Windows credential manager, eliminating the need to manually enter credentials or have them stored in the script. However, these credentials do not have to be legitimate or valid credentials, which is great news for defenders attempting to setup honeypots. These fake credentials can then be monitored using Windows Event logs, Endpoint Detection Response anti-virus solutions (EDR) and security information and event management (SIEM) logs to then trigger alerts when these accounts have been used.
The below steps will show how to inject fake credentials using cmdkey:
Open an administrator command prompt window
Inject a fake credential by using the below string in the open command prompt window. For this example we will be creating a fake credential which will appear to be a backup administrator account. I will also be using the name of the domain controller as the computer name, this is to appear as though this is a cached credential that was used to RDP into the domain controller previously.cmdkey /add:<computer_name> /user:<domain>\<fake_username> /pass:<fake_password>
The credential can be checked by running cmdkey /list or by checking Windows credential manager
When attempting to RDP into the domain controller, the RDP window will show that there is a cached credential for this server that exists. However, when attempting to RDP with the cached account it will fail as this account/credentials do not exist in the domain.
When the login attempt fails, it will generate an event in the Windows security event log. This event id can either be monitored via a SIEM and alerted upon or a task can be scheduled using Task Scheduler to trigger an email to be sent.
Wrapping up the usage of cmdkey as a deception technology, it should be noted that as many credentials can be setup on various servers/machines to coerce threat actors into leveraging these credentials. It is highly recommended to inject these credentials on servers that are more susceptible to attack/servers that are enticing to the threat actor.
Honeypot Accounts
A honeypot account is an account strategically positioned in a network to look interesting for an attacker. If any contact is made with the honeypot account than an alert is sent to the security team to investigate. The primary aim of using the honeypot account in this context is to detect Kerberoasting.
The below steps below will outline how to setup a honeypot account which can be utilised to detect kerberoasting attacks.
On the domain controller open Active Directory Users and Computers and create a new domain administrator account with a similar naming convention to existing domain administrator accounts (in this example we will use backupadmin to simulate a backup administrator account). When creating the account, use an extremely complex password of 128 randomly generated characters. This will prevent the attacker from cracking the password.
NOTE: The purpose of giving the account domain administrator membership is to make it appear as though the administrator was lazy and gave the account domain admin rights instead of setting it up correctly. This tactic is used to assist with tricking the threat actor into targeting this account.
After adding the account to the domain admins group, a suitable Service Principal Name (SPN) should be chosen. This SPN is what the threat actor will see when they conduct a Kerberoasting attack, so it’s important to make it appear legitimate, such as a MSSQL service account. It’s also essential to make it a unique name so check existing SPN’s and double check the “adminCount” attribute is set to 1.
Enable "Audit Kerberos Service Ticket Operations" logging to capture 4769 events, which occur when a Kerberos service ticket is requested.
If there is a SIEM in the environment, then these events may already be captured.
Create a custom event view to identify when a Kerberos service ticket is requested for our honeypot account. This can be accomplished by using the following XPath query that contains the newly created account. If this step is not completed, there will be thousands of 4769 event logs and it will be difficult to identify malicious activity.
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(Level=4 or Level=0) and (EventID=4769)]] and
* [EventData[Data[@Name='ServiceName']=backupadmin]]</Select>
</Query>
</QueryList>
After all the above steps have been completed a kerberoasting attack can be tested to see if the alerting works.
The event is successfully picked up in the custom event view.
These event logs can either be captured by EDR, forwarded to a SIEM, or a scheduled task can be created so that a script runs and sends an email when the honeypot account has been tripped.
Canary Tokens
Canary tokens are basically a tripwire and will alert when they are interacted with. The token can be a file, folder, URL, DNS hostname or even a registry key that alerts when a certain application is interacted with. When the token is interacted with it will trigger an alert, notifying the owner. There are various ways canary tokens can be implemented, however, Thinkst has made this very easy to setup and free for a number of different token types. For this guide I will walkthrough implementing the "Sensitive Windows Commands" token as the files and folders tokens are quite simple and intuitive to deploy and use.
First we will open a browser and navigate to the Thinkst Canary Tokens page - https://canarytokens.org/generate
From the drop down select "Sensitive command token" and fill in the fields required for the token. It is recommended accurately fill in this information as it will assist with identifying the process and locating the system that this token was triggered on.
Once you click create my token you will be able to download the canary token to deploy it on your chosen server or servers. The additional advantage of the registry file token is that it can be deployed to a number of servers by taking advantage of group policy which will demonstrated later in this post.
Opening the canary token registry file with a text editor, we can see how it functions. The registry key will modify values within the registry to monitor for usage of the command we entered when creating the token, in this case netsh.exe. Inspecting the alerting for the canary token we can see that it will launch PowerShell via a minimised command prompt window. The PowerShell command will then collect several environment variables to send along with the alert, consisting of username, computername and a DNS resolution for the computername. This information will assist with determining the machine and the account associated with the activity that triggered the canary.
It was possible to see PowerShell quickly flash in the taskbar before exiting when testing the canary token by running netsh (It was not possible to capture the PowerShell activity as it disappeared too quick).
Checking the history of the token reveals that it has been triggered. You should also receive an email if you have email alerts turned on for the token.
Reviewing the history of the token you can see the level of detailed information that can be obtained. It is possible to determine the username of the user, computer and time when the canary was activated, along with other information including the description entered earlier.
This wraps up the basic implemention and usage of a "Sensitive Windows Commands" canary.
Additional GPO Steps
The below steps will show how to push this registry key based canary token out via Group Policy Object (GPO). Open Group Policy Management on the domain controller. Right-click on the domain and select "Create a GPO in this domain, and Link it here...".
Give the new GPO a meaningful name like Canarytoken to help with administering it in the future.
Right-click on the new "Canarytoken" and select "Edit..."
Navigate to User Configuration > Preferences > Windows Settings > Registry. Right-click Registry and select New > Registry Item.
Click on the elipsis (...) next to the key path which will open the Registry Item Browser. Navigate to the location in the canary token registry file, in this case "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\" and select the command name which in this example was netsh.exe. Click the GlobalFlag DWORD and them click Select to close the Registry Item Browser.
Then click Apply on the New Registry Properties window to apply the changes.
Repeat the above process for the ReportingMode and MonitorProcess keys which can be found under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\netsh.exe". NOTE: Substitute netsh.exe for the command you used when you created your canary token.
We can run "gpupdate /force" on a domain joined machine and check if the registry keys have been pushed by opening up Registry Editor and verifying that the keys from the canary token are there.
Finally we can test if it works by once again running netsh.exe and seeing if the alert generated now contains the details on the new machine where we pushed out the GPO. Viewing the incident list for the canary token we can see it is the computer with the GPO applied and new domain user, which means our canary token GPO is functioning as intended.
Conclusion
This post only went through a few ways organisations can implement zero cost deception technologies. There are still many other free deception technology techniques that can be implemented to help keep networks secure and thwart threat actors from achieving their goals.
References
- Cmdkey
- Honeypot Accounts
- Canary Tokens
Comments ()