This is a multipart blog post, read part one and then continue here.
We enabled filesystem auditing, created our audit template, and staged our honey tokens for deployment in part one. In part two, we will deploy the honey tokens and identify various methods for monitoring adversary interaction.
Deploying honey tokens using PowerShell (PoSh)
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.
We will deploy the honey tokens in the following configuration:
| Hostname | Purpose | Token | Destination Path |
|---|---|---|---|
| Hinata | Admin Workstation | .aws\config .aws\credentials | c:\marcus.jones.sa\.aws\config c:\marcus.jones.sa\.aws\credentials |
| Bruce | Jump Host | servers.kdbx | c:\admin_tools\keepass\servers.kdbx |
| Yagami | File Server | brocade_cfgs.zip | c:\backups\brocade_cfgs.zip |
I created a PowerShell script that automates the deployment of the honey tokens enterprise-wide. Unless you have a handful of computers, I would recommend developing a method to automate this process or use the script provided. Below is an example of the script execution and output.
-> tokendrop.ps1
[-] Connecting to remote host: Hinata
[-] Validating local token(s)
[-] Dropping token: c:\users\marcus.jones.sa\.aws\config
[-] Setting Audit ACL
[-] Validating local token(s)
[-] Dropping token: c:\users\marcus.jones.sa\.aws\credentials
[-] Setting Audit ACL
[-] Connecting to remote host: Yagami
[-] Validating local token(s)
[-] Dropping token c:\backups\brocade_cfgs.zip
[-] Setting Audit ACL
[-] Connecting to remote host: Hinata
[-] Validating local token(s)
[-] Dropping token: c:\admin_tools\keepass\servers.kdbx
[-] Setting Audit ACL
[-] Completed: 4 token(s) dropped across 3 host(s)
Validating audit settings on remote systems
It is essential to ensure that our files have the correct audit settings; otherwise, we will not receive alerts from our “tripwires.”
The following command checks the audit settings on a remote system:
PS C:> $auth = Get-Credentials
PS C:> Invoke-Command -ComputerName yagami -ScriptBlock {
>> Get-Acl -Path c:\backups\brocade_cfgs.zip -Audit | FL AuditToString } -Credential $auth
AuditToString : Everyone Success, Failure Read
The output above confirms the expected audit setting is configured on our remote token. If you do not get a similar output then the settings were not applied correctly. We can do this for each host or use the Graphical User Interface (GUI) to check each token for the audit settings.
Note: Interacting with our tokens will generate audit events that could identify avenues of approach to avoid.
Once you are satified that a good sample size of your tokens have the audit template applied we will now transition to testing.
Test Audit Event Generation
There are several ways that an adversary can interact with our honey tokens. Testing each anticipated method will help increase confidence in our ability to capture the interaction. There are four honey tokens aka honey files in our lab. We will simulate the adversary by using PowerShell Remoting, Remote Desktop, and Process Injection to interact with these honey tokens and review the local Windows Security Event Log to see if the interactions are captured.
PowerShell Remoting
We will use PowerShell remoting as our first test case.
To make things easier, I create and store a security credentials object in a variable.
PS C:> $admin_auth = Get-Credentials
Then connect to the desired system using a powershell remoting session.
PS C:> Enter-PSSession yagami -Credential $admin_auth [yagami]: PS C:\Users\vanya\Documents>
In order for the above to work, I created and applied a GPO that enables PowerShell Remoting on each test system. There are plenty of references on the web if you need help configuring PS Remoting.
While connected to the yagami server I navigate to the location of the honey token and perform a directory listing.
[yagami]: PS C:\Users\vanya\Documents> Set-Location -Path C:\backups\
[yagami]: PS C:\backups> Get-ChildItem
Directory: C:\backups
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 8/21/2020 8:00 PM 77568945 brocade_cfgs.zip
[yagami]: PS C:\backups>
Keep in mind that a directory listing will not generate a 4663 EID unless we add the audit settings to the parent directory.
Here we will extract the archive and observe the audit access log. You can use a password protected the zip file, which will still generate an audit event if the adversary tries and fails to extract with the contents.
[yagami]: PS C:\backups> Expand-Archive .\brocade_cfgs.zip
In the screenshot above, there is a lot of useful information for a security analyst. The main areas of concern are the persona, object name, and process name. This particular test case used PowerShell remoting, which aligns with the logged process named wsmprovhost.exe that, according to Microsoft, is an artifact of a Windows Remote PowerShell session. We can conclude that if an adversary interacts with our file over a remote PowerShell session, there is a high probability, we will observe a similar wsmprovhost process.
Note: If you use PowerShell without a WinRM session the process name will not be wsmprovhost it will be powershell.exe
Remote Desktop
In our second test-case, we will use a Remote Desktop Client to interact with one of our honey tokens. The goal is to identify and validate the security event logs generated by our actions.
We will remotely connect to and use the Hinata workstation, which has the AWS credential file. I created a demo admin user named Vanya, that I will use for authentication.
If you opted to enable auditing on the parent directory then the directory listing above will also generate 4663 Event IDs, this can be useful to capture directory traversal searches. Attempting to view the AWS credentials file’s contents introduces the ‘open with’ dialog from which we can select the notepad text editor.
Using the ‘open with’ dialog generates the event log above on the Hinata workstation. We can identify the user, process, and token involved. The source computer is also captured, but not depicted above. From an analyst perspective this is supporting evidence that the vanya account interacted with the AWS crendentials file, which should be anomalous and not routine. Choose your tokens so that there is minimal incidental interactions. If this user has to work with authentic AWS credentials then this would not be a good choice for a token.
Using notepad to open the credentials file generates the event log above.
Simulated Memory Resident Malware
Fileless malware, process hollowing, process injection, and many other memory-resident techniques can be challenging to detect. According to the Verizon Data Breach Investigations Report, 56% of breaches took months or longer to discover. Our goal is to help defenders lower the average time it takes to detect a breach, also known as the mean time to detection (MTTD). For the last test case, we turn to the Metasploit Framework (MSF), which will allow us to simulate malware conducting reconnaissance and exfiltration in memory.
Note: Setting up an environment is outside the scope of this blog post, so we will only demonstrate the process and provide the results.
There is an established meterpreter session in the image above connected to Bruce, our Windows 10 jump host. We started the test with a search for KeePass database files under the root directory (C:). This database would usually store a sizeable amount of passwords for the Administrator of the system. So if placed in a convincing location, it is an attractive honey token. After a few moments, we see the full path to the database file. Remember that the search alone will not generate a 4663 EID unless you configure auditing on the token’s parent directory.
After navigating to the KeePass database file location, we simulate exfiltration by using the download function of the meterpreter shell. We can see the event log generated by the demo malware that gave us our initial access in the following image.
Meterpreter has a process migration feature that allows us to simulate and test malicious process injection. We used the migration functionality to pivot from the initial access malware running in memory to the windows explorer.exe process. Once we completed the migration we repeated the same search and download for KeePass database files and the follow log was generated.
In the next and final installment of this series, we will look at various ways to ship our logs from these windows hosts using a simple powershell script as well as more roboust solutions that integrate well with a Security Information and Event Management (SIEM) platform.
Thanks for reading.