If you are defending an enterprise network, you should be using some form of honey token or canary, which is just something you place in your environment that no one should access. If any interaction is detected, it is usually an indicator of unauthorized activity. Using pseudo domain accounts as honey tokens usually illuminate the risk bubble for network owners, therefore I recommend using pseudo files with windows file auditing turned on and configured.
Almost every incident response write up that I read shows that the adversary, once inside a network, will conduct file and folder discovery in order to find various sensitive documents. We can leverage this knowledge to create “tripwires” throughout the defended terrain as an indicator of potential compromise.
Creating the Object Access GPO
In order to enable auditing at scale, we will need to create a group policy object (GPO) that enables the object access file system audit policy. We will see this later as Windows Security Event ID 4663. (Note: DISA STIGs turn on some auditing).
Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Polices
Generate Pseudo Files and Folders
According to the MITRE attack framework, an unauthorized user will try to scan for files and folders on multiple endpoints, in order to gain situational awareness and shape further actions.
Trend Micro has a blog post about a Trickbot variant that looks for VNC credentials in .vnc.lnk files and Fox-IT has a whitepaper titled Operation Wocao where there was evidence of deliberate search queries for KeePass database (*.kdbx) files.
We can leverage this information by impersonating any of these files in order to solicit interaction. These files should be created based on your threat model and enterprise attributes. Here are some example files:
- servers.kdbx (KeePass database)
- id_rsa.key (ssh private key)
- cloud_vps.ovpn (VPN config with credentials)
- backup.zip (password protected zip with enticing contents)
- “%UserProfile%\.aws” (AWS CLI configuration directory)
I installed KeePass in a Windows VM and populated it with random usernames and passwords. I used the AWS CLI tool to create the AWS configuration directory contents. Do not create these files with the same file size. While researching ideas for token files, Michael Banks, suggested using CloudWatch to detect usage of inactive API tokens.
Configure template audit ACL
Once you have chosen your honey token files and have them ready for deployment we will now create a template file configured with the file audit ACL we need to apply to our honey tokens once they are placed on the remote systems.
-> New-Item -ItemType Directory -Path c:\Users\mechanic\tokens
-> New-Item -Path c:\Users\mechanic\tokens\token_tpl.txt
Now using the windows explorer file manager, simply right click the token_tpl.txt file and select properties > security > advanced > auditing. Then select ‘Add‘ followed by ‘Select a Principal‘. You should be presented with the following prompt:
Input ‘Everyone‘ and then press OK. For the type select ‘All‘, which will capture success and failure attempts.
Click ‘OK’ and exit all dialog boxes.
View Template Audit Settings
We can use PowerShell to verify that the settings are present. Open an admin PowerShell console and type the following:
-> $acl = Get-Acl -Path .\token_tpl.txt –Audit
-> $acl | FL
Path : Path : Microsoft.PowerShell.Core\FileSystem::C:\tokens\token_tpl.txt
Owner : FAKELABS\mechanic
Group : FAKELABS\Domain Users
Access : BUILTIN\Administrators Allow FullControl
NT AUTHORITY\SYSTEM Allow FullControl
BUILTIN\Users Allow ReadAndExecute, Synchronize
NT AUTHORITY\Authenticated Users Allow Modify, Synchronize
Audit : Everyone Success, Failure Read
If you run this command before applying the audit settings the Audit field will be blank.
Deploying honey tokens using PowerShell (PoSh)
Think carefully about where you will deploy your honey tokens. Do some analysis of your asset inventory and consider locations such as a jump server or other potentially high-value targets. The actual location on disk should be such that there will be no interaction from users, admins, or automation processes.
I provisioned three virtual machines and joined them to a local windows domain in my test lab. They will be used to demonstrate deploying the honey tokens, configuring auditing and monitoring for interaction.
Windows 10 Enterprise
Windows 10 Enterprise
Windows Server 2016
We will deploy the honey tokens in the following configuration:
|Hinata||Admin Workstation||.aws\config .aws\credentials||c:\marcus.jones.sa\.aws\config|
Stay tuned for the next installment where we will continue this blue team tactic.