Using Windows File Auditing to Detect Honeyfile Access

Over the years, a vast amount of research has been focused towards honeypots. Honeypots have evolved from the traditional emulated operating system and service to include a variety of honey “things”. For example, “honeytokens”, “honeycreds” and as described in this article, “honeyfiles”.

A honeyfile, or sometimes referred as a honeydoc, is an individual file that is enticing to an attacker, which is scrupulously monitored, generating alerts when any form of interaction takes place - for example, when the file is read, deleted or modified.

A honeyfile can be an effective proactive approach to detecting malicious activity on a corporate network. By studying your organisation’s threats and most valuable assets, honeyfiles can be created that can entice interaction. It may also be possible to infer an attacker’s objectives using different types of files. Using a file named “MySQL Passwords” as an example – an insider without technical skills and knowledge is unlikely to gain from accessing this file, whereas an external hacker may see this as a quick win opportunity. Similarly, an insider may be more drawn towards a file named “End of Year Finances”, compared to that of an external hacker, whose focus may be on compromising high value parts of the network. Motives aside, monitoring for any kind of activity on these files could be a good indication of malicious activity on the network.

A common high-value target for an attacker is file shares. File shares are often gold-mines of business sensitive data, making them a worthwhile target for an insider or external attacker. However, identifying malicious activity on a file share is commonly a difficult task. File shares are typically very active, and with auditing enabled, produce large volumes of logs making it difficult to transform and process these logs into proactive detection of malicious activity, instead primarily used for post-incident investigations.

Another common approach to identifying malicious activity on a file share is using honeytokens. Simply, a honeytoken is stored within a file, when the file is opened, a domain is contacted and an alert is generated. Although this may appear to be an effective and relatively covert approach, a fundamental flaw with honeytokens is the requirement for network connections, whether this be internally or externally. A sophisticated attacker will be aware of these detection mechanisms, and will often siphon files onto an isolated network prior to opening them. A solution for injecting honeytokens into Microsoft office documents was found in recent alleged leaks of CIA files https://www.rt.com/news/386433-wikileaks-cia-scribbles-microsoft-office/ and as a low effort technique would not need to be successful 100% of the time to be worthwhile.

This article investigates an alternate solution to creating a honeyfile by taking advantage of native Windows auditing. This approach will attempt to address problems with existing solutions by providing a honeyfile that is easy to implement, low-noise and generally low false-positive. The article will then provide a breakdown of anti-detection techniques, and the potential of increased operational costs before highlighting the overall limitations to this approach.

The auditing function native to Windows provides all of the necessary functionality required to create a honeyfile. Windows auditing presents opportunities where other solutions fail. For example, Windows auditing does not require a network connection - identified as an evasion technique with the honeytoken approach. Similarly, with a precise auditing configuration, logs can be kept to a minimal, whilst still being effective at detecting an attacker.

Along with file auditing, Windows auditing can be used to audit a vast amount of activity, for example logins/logoffs, changes to the registry, removable drive usage and more. While this article will focus specifically on a honeyfile, more information of Windows security auditing can be found https://technet.microsoft.com/en-us/library/dn319078(v=ws.11).aspx and https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor.

Before defining the audit policy on the honeyfile, the “Audit File System” found in “Advanced Audit Policy Configuration” must be configured to “Success” within group policy. The image below illustrates the required policy:

This feature is available on Windows Vista and Windows Server 2008R2 or above.

The “Audit File System” policy will generate audit logs on file system objects that have a system access control list (SACL) specified. Simply, a SACL will generate audit logs if the access event matches the defined policy. It is possible to define a SACL on what Windows securable objects. Without delving into what makes up a Windows (securable) object, when an audit policy is defined on a file, this in effect notifies Windows of what activity should be audited. More information can be found https://msdn.microsoft.com/en-us/library/windows/desktop/aa379557(v=vs.85).aspx.

With group policy configured, we can begin auditing the honeypot file. First create or modify a file for monitoring - in the following example, the file is named “honeyfile.txt”. Navigate to the file properties, select the “Security” tab, “Advanced” and finally the “Auditing” tab. With no auditing pre-defined, add an auditing entry by selecting the “Add” button.

As we want to monitor activity on the file from everyone, we can add the principal group “Everyone”. Concerned with only success events, select a type of “Success”. While it may be tempting to select “Full Control”, this will produce a large amount of noise, and make the alerts difficult to interpret. We will focus on a subset of the permissions, shown in the image below:

• List folder/read data - Triggers when the file is read, the properties are displayed, when the file is copied, and when a file is executed.
• Create files/write data - Triggers when the contents of the file is modified.

• Write attributes - Triggers when the attributes are modified (displayed in file properties).

• Write extended attributes - Triggers when extended attributes are modified (file properties, Advanced)

• Delete - Triggers when the file is deleted and renamed.

• Change permissions - Triggers when the file permissions are modified.

• Take ownership - Triggers when file ownership is changed.

Configuring the above permissions will provide a verbose logging trail, so that it is possible to monitor and alert upon suspicious activity.

Now that auditing has been enabled, we can begin interpreting the logs. All file auditing logs are written to the Windows Security log with an Event ID of 4663. Analysing the event, we can begin to develop an understanding of what type of activity has taken place on the file, for example, if the file has been read, deleted or modified. Interpretation of the Accesses or AccessMask properties allow us to identify the specific activity that has caused the event log to trigger. The following image demonstrates an example alert:

A breakdown of the Accesses and AccessMask properties and the type of activity they correlate to is provided below:

File Read

Accesses: ReadData (or ListDirectory)

AccessMask: 0x1

File Write

Accesses: WriteData (or AddFile)

AccessMask: 0x2

File Delete

Accesses: DELETE

AccessMask: 0x10000

File Rename

Accesses: DELETE

AccessMask: 0x10000

File Copy

Accesses: ReadData (or ListDirectory)

AccessMask: 0x1

File Permissions Change

Accesses: WRITE_DAC

AccessMask: 0x40000

File Ownership Change

Accesses: WRITE_OWNER

AccessMask: 0x80000

The audit policy on the honeyfile is designed so that (almost) all interaction with the file is logged. A problem arises when Windows services, for example, the Windows Search service, interacts with the file. The Windows Search service, a replacement for the former Windows Indexing service, is an optional feature on Windows servers that performs indexing on file shares. Indexing a file share is intended to allow clients to perform faster and more efficient searches on the share. The Windows Search service will perform indexing on a file each time the file is modified  causing a file read to occur by the indexing service. This false-positive is not indicative of malicious activity and can therefore be ignored. It is possible to disregard this activity by filtering on the process that performs the indexing; SearchProtocolHost.exe.

Consequently, this may present an opportunity for attackers to masquerade as the “SearchProtocolHost.exe” process (or any whitelisted process), so that interaction with the file is ignored. While it can be considered possible, an attacker would require knowledge of the honeyfile to do this, therefore rendering the honeyfile ineffective anyway.

Further potential applications that could cause false-positives are anti-viruses. Generally, anti-viruses will immediately scan files when they are saved onto the disk, categorising if a file is malicious or not. Furthermore, anti-viruses will also periodically scan the entire disk, looking for hidden malicious files. This could trigger false alerts.

Event ID 4663 is a verbose log, and a large amount of information can be drawn from it. Along with the type of activity performed on the file, in certain circumstances the process is also encapsulated within the log. For the process to be included, the activity needs to be performed on the file share itself. For example, using PowerShell to read the contents of a file specifically on a file share, will produce a file read log with the corresponding process name equal to PowerShell.exe. However, replicating the steps but on a client connected to the file share will log the file read, without the process. When processes are captured within the event, this is indicative that the activity was performed on the file share and could therefore signify that the file share is compromised. Where processes are captured within the event should be considered to be of higher criticality, as this indicates that the activity was performed from on file share itself, potentially indicating that the file share is compromised.

The audit configurations detailed above are focused on keeping logs to a minimum, logging only what is deemed necessary, however there is still an obvious increase in logs that are generated. It is important to take this into consideration when, for example, your SIEM solution bases cost on the volume of data ingested. Where this may be a concern, it may be possible to:

• Filter logs on the client, only ingesting logs that are required (Event ID 4663).
• Alternatively to auditing an entire file share, focus auditing solely on individual files. In a linear fashion, decreasing the number of files that are audited correlates to a decrease in logs generated. 

The concept of a honeypot is to effectively deceive the attacker into thinking that the system - or in this case, file - they are interacting with is in fact legitimate. If a user is able to identify a honeypot, it is highly unlikely that the behaviours that follow are what would have been completed under normal circumstances. Using malware as an example; the more sophisticated strains of malware will detect when it is running within a sandbox. Malware analysis systems will combat this by intentionally hiding the sandbox attributes from malware. Similarly, honeypots will hide the fact that it is a honeypot, exposing only what is perceived to be legitimate functionality.

In this scenario, the tell-tale signs that could reveal the intentions of the honeyfile is the auditing. A user with the correct privileges may identify that auditing is enabled on an individual file, while not on others, causing an increase in suspicion.

The following could help towards minimising that potential risk of attackers identifying the honeypot, reducing the likelihood of attackers identifying the honeypot:

• Enforce strict access control permissions on files so that users are unable to view the auditing entries.
• Enable logging on all files/folders and apply filtering on the logs server side.

Enforcing strict access control permissions is an effective remediation however there are limitations to this. While this may remove standard users from viewing audit entries, this will not stop administrators. An administrator has the ability to view, reconfigure and/or delete audit policies. If privileged users are a perceived threat, then following the second option is recommended.

Enabling auditing on all files/folders has its positives and negatives. Firstly, as logging is enabled on all files/folders, if an incident were to occur that’s beyond the scope of the honeyfile, an audit trail will exist for investigative purposes. A simple search through the logs could help towards building up a picture of the incident, aiding in attribution. However, enabling auditing on a large and busy file share will inevitably produce a large volume of logs. This operational cost should certainly be considered when going down this route.

One exception to interacting with the file that does not produce logs is when a search is performed and the contents of the search matches that of the content of the file. To test this, a text file was created and with the words “MWR test file” written to the file. Performing a search of “MWR” reveals the file, however, this was not logged. A small snippet of the contents of the file is presented to the user that is not actively logged. However, it should be noted that this exception occurs only when the Windows Search service has been enabled as indexing has been performed on the contents of the file.

However, despite this limitation, logs are produced when files are indexed and when a file retrieved or modified. An attacker is more likely to search and then open or retrieve the files of interest, with the latter activities logged.

To summarise, Windows auditing presents covert opportunities of detecting malicious activity on a network, and more specifically, a file share. Unlike alternative methods of honeypotting a file, Windows auditing is not limited to specific file types, does not require network connectivity, is difficult to bypass, and can be integrated seamlessly into existing monitoring solutions. Additionally, initial setup is trivial, taking advantage of native Windows functionality, and when configured correctly, alerts are low-volume/high-fidelity.