In part 2, we simulated adversary interaction with our deployed tokens and then leveraged Windows Event Viewer to assess the generated artifacts. What follows will be several options for getting the audit logs from the endpoints to a centralized medium for analysis.
In order to see when there has been interaction with our honey tokens, we have several options (Not Exhaustive):
- Leveraging Windows Event Viewer
- Manual query using PowerShell
- Using Windows Event Forwarding (WEF) to a WEC Server
- Log aggregation using Splunk Universal Forwarders
Viewing Audit Logs in Windows Event Viewer
Windows Event Viewer is the native way to check your logs on a windows system. Manually checking your logs this way will not scale in large environments. However, it is important to know how to view the local audit logs on an endpoint.
Start by navigating to the Control Panel > System & Security and then select Administrative Tools.
Double click Event Viewer and then select the Security log as depicted above. The action pane on right will populate with a few options. Select ‘filter current log’ which will present the dialog box below. Enter EID 4663 and press the OK button.
After clicking the OK button, the center pane will display the audit events similar to what we saw in part two. If you do not see any logs then I would advise you to go back and review part two of this blog post. Keep in mind that this method can become tedious when reviewing event logs from multiple systems. We will take a look at more scalable options in the next sections.
Viewing Audit Logs Using PowerShell
We can use the PowerShell (PoSh) Get-WinEvent cmdlet to view local and remote Windows Event Logs at scale. The screenshot below shows how to use PoSh on the command line to retrieve our three test systems’ security logs.
The previous command returns all security events. Wading through all of these logs can be cumbersome when looking for interaction with our honey tokens. In the screenshot below, we modify the PoSh command line to only show security logs with event ID 4663 in the output.
A more robust solution would be to write a PoSh script that automates reporting when there is a security event related to any of the tokens distributed in your environment. Using code to poll and parse has the added advantage of not requiring an agent on the systems. However, you must protect the script and limit access even to administrators since it is a map to all of your traps.
Deploying Splunk Universal Forwarders via GPO
I wrote a blog post here, that goes over how to deploy the Splunk UF using a Group Policy Object.
Configuring Splunk UF to Ship Logs
Windows Event ID 4663 is found in the Security Event Log, so we will need to configure the Splunk Universal Forwarder (UF) on each endpoint to send the Security Event logs to our Splunk Indexer. A Splunk Deployment Server (DS) allows us to distribute the configuration settings using an app at scale. Installing and configuring a DS and UF will not be covered in this blog post; however, Splunk documentation details how to install and configure a DS and UF.
If you only have a handful of systems, you can configure the UF without an app by placing the inputs.conf under:
Ensure the inputs.conf file has the following contents:
[WinEventLog://Security] disabled = 0 start_from = oldest current_only = 0 evt_resolve_ad_obj = 1 checkpointInterval = 5 blacklist1 = EventCode="4688" Message="New Process Name:\s+.*SplunkUniversalForwarder" renderXml=false index = wineventlog
Note: You will need to properly tune your inputs.conf to capture other event logs and scope the traffic you forward. This blog post is tailored to meet the objectives of capturing honey token logs and does not reflect a comprehensive security configuration.
Splunk has an inputs.conf specification file that covers all the configuration option details, but for our purposes the above configuration will get the job done. The blacklist1 option prevents the UF from sending the noisy events that the UF generates. You may need to restart the UF after you update the configuration and then you should see security events in your SIEM by selecting the wineventlog index as depicted below.
You should see some of the events we generated from part two of this series. If the data is not parsed correctly then you need to ensure you have the Windows Technical Addon installed on your indexer.
Shipping audit logs from a Windows Event Collector (WEC)
If you have a Windows Event Collector (WEC) configured in your environment, I would recommend installing a Splunk Universal Forwarder (UF) or WinLogBeats to ship the logs to a Security Information Event Management (SIEM) platform. This solution is similar to placing an agent on each endpoint, which we discuss in this blog post’s preceding paragraphs. If you already have Splunk deployed, then it may be appropriate to use a UF. WinLogBeats can also send logs to Splunk using an HTTP Event Collector (HEC) and several other destinations such as Apache Kafka, Logstash, or Elasticsearch. However, you have to decide which design makes sense to deploy.
Viewing audit logs in Splunk Web
Now that our logs are being ingested into Splunk we can build search queries that can identify if there are logs associated with our honey tokens. During testing you will obviously have logs and may even need to baseline against EDR or IT related automations that scrub perform directory walks.
The output from the search is below for reference.
Notice that we can clearly see the honey token path and associated host system. The Access column helps you understand the interaction. This will change based on which permissions you set during the setup phase of this series.
The screenshot below we can see which process and user acccout triggered the audit event. This search can be saved and run on a schedule or configured as an alert. If you have a large amount of honey tokens an inputlookup table is ideal
There are thousands of attacks leveraged against computer networks every day. Companies spend millions of dollars on technology to mitigate these attacks, but many of these attempts still result in a breach. According to the Verizon Data Breach Investigations Report (DBIR), more than half of security breaches each year take a month or more to detect. These facts and statistics highlight the challenging task that Information Security Professionals face each day. Using a detective control such as a honey token can increase a security team’s ability to detect intrusions rapidly. One of the earliest examples of successful employment of honey tokens is The Cuckoo’s Egg, a real-life account of Cliff Stoll’s pursuit of a network intruder. In the book, honey tokens contributed to the subsequent takedown of a German Hacker.
The honey tokens described in this three part series are very effective tripwires against an unwitting adversary. Think carefully about your organization’s threat model and use this information to develop and position honey tokens in your environment where they will gain the most value.
Thanks for reading.