Introduction


Have you ever investigated a data leakage case involving a suspect potentially leaking data to an external storage device? In this article we show the importance of a good forensic readiness strategy and well-thought-out auditing policies.

More specifically, we explain how the recording of non-default Windows event logs can help you prove the copying of data to external USB storage devices in scenarios where only the Windows source system is available for analysis, but not the targeted USB storage device.

Background Story


In a recent engagement, we at Compass have been asked to investigate a potential data leakage, where one of our customers had very specific suspicions that an employee performed a potentially unauthorized copying of sensitive documents to an external storage device. Since the corresponding USB device was no longer available, the customer asked us to extract evidence from the user’s corporate laptop, from which the data was presumably copied. The time period of interest could be narrowed down by our customer to a one-week time frame. Our goal hence was to provide a list of files that the user copied to an external storage device in a forensically sound manner.

After imaging the provided laptop’s hard disk, we started our analysis. It turned out, that we as forensic investigators were in a very admirable situation, in the sense that our customer had an exemplary auditing policy enforced on their client workstations. Only because of this, we could provide them with the complete evidence they requested.

In the remainder of this article, we will explain these non-default Windows event logs that were recorded by the customer’s auditing policy and show you what evidence, with respect to data leakage, they provide. Following this, we will briefly compare this to what we could have extracted from the corresponding Windows 10 system in case only default settings were enabled. On the basis of one very specific example, the comparison should illustrate the benefits of investing in forensic readiness to be well prepared in case of an incident.

External Device Access Auditing with Windows Security Event Logs


Windows event logs are one of the treasure rooms when it comes to forensic investigations. They give an audit trail that records system and user events, mostly indispensable during investigative assessments. However, mainly because of efficiency reasons, not all technically possible events are logged by default. If you are not considering this, you might miss invaluable information for certain investigative scenarios.

The example that we discuss in this article, is the investigation of data leakage via external storage devices. Unless probably for the case that you completely block all connections of external storage devices, you might consider adjusting your auditing policies [Ref. #1], so that the Security event log records the following EIDs.

Audit Plug and Play Activity

Event ID 6416: A new external device was recognized by the system

If enabled, Windows logs at least one event with ID 6416 when a new external device is connected to the system. Events are logged repeatedly; i.e. new events are added whenever the same device connects. From the above sample, we can learn that a “USB Mass Storage Device” got connected to the investigated system (“DESKTOP-007”) on the 15th April 2019, at 09:20. In addition, the entry tells us the device’s vendor and product IDs (“01234” and “56789”), as well as the corresponding serial number (“ABCDE”). Another entry with EID 6416, logged at the same time, might further list the volume name (e.g. “E:”), that was assigned to the connected device (not shown here).

Audit Removable Storage Activity

EID 4663: An attempt was made to access an object

The events with ID 4663 document actual operations performed against files and other objects. For the discussed scenario, these events provide the most valuable information. Each time a removable storage device is interacted with, a log entry is recorded. Typical interactions in this context include file and folder creations, reads, modifications or deletions.

The example above shows that the user “SpecialAgent007” copied (“Accesses: AppendData”) a document with name “SecretGadgets.docx” to the external mass storage device, approximately 3 minutes after the device was connected (devices can be matched between EIDs 6416 and 4663 based on the Object Name – not shown in the examples above). Further we can learn that the “explorer.exe” process was used for the operation, indicating that the user copied the file using Windows File Explorer application.

If you rethink of our goal mentioned in the Background Story above, it is quite obvious how we were able to provide the requested evidence. Filter the extracted Security event log for the relevant EIDs, narrow down the results to the time frame of interest and remove irrelevant access types, such as “ReadData (or List Directory)”. That’s it.

In the real-world case, we ended up with a list of 831 unique files. The identified evidence provides technical evidence that the files were copied from the analyzed corporate laptop to the external USB storage device of interest.

External Device Access Auditing with Default Windows Artifacts


What if you would not have had the “Audit Removable Storage” events recorded in the first place (which as mentioned is the default on Windows 10)?

Windows by default collects a wide variety of artifacts, useful for different purposes during an investigation. An excellent overview thereof is provided by the SANS forensics posters (in the context of this article, of special interest is the Windows Forensic Analysis poster [Ref. #2 and #3]).

For the discussed data leakage scenario via USB devices, most of these artifacts however only provide minor evidence. We will demonstrate this based on the real-world case we mentioned above, where we reviewed the following artifacts for this purpose:

  • Shortcut (LNK) files: A Windows artifact, automatically created upon opening local and remote data files and documents.
  • Jump lists: A Windows artifact that allows viewing recently used items (media files, tasks, etc.).
  • Shell bags: A Windows artifact showing which/when folders were accessed on the local machine, the network and/or removable devices.
  • Recent files: A Windows artifact, tracking the last files and folders opened.
  • File stats: File system timestamp information.

Without going into too much details about the technical analysis, it turned out that with these Windows default artifacts, we would have only been able to find 7 out of 831 files that were copied to the external storage device. This is less than 0.8%.

The main problem is, that artifacts such as shortcut files or jump lists are only generated when files are actually opened. In other words, the 7 files that we managed to correlate with the external USB mass storage device, are the ones the user accessed/opened on the connected device after the copy operation.

Further, this evidence alone might not be a strict technical prove that the corresponding files were actually copied from the investigated system. It only proves that the files were present on the connected storage device, and from there opened at a certain point in time.

Other Ways to Monitor External Device Usage


In this article we focused on auditing external device usage through Windows event logs. Of course, other options exist, e.g. by running third-party monitoring tools on the client workstations. One popular tool that can be used to this end, is for instance the System Monitor (Sysmon) tool of the Windows Sysinternals tool suite [Ref. #4].

Conclusion


Reviewing auditing policies, and in general trying to achieve a good level of forensic readiness, is crucial to successful incident handling. Investing and preparing prior to incidents will pay back in both what you will be able to analyze during an incident, and the efficiency to do so.

In this article, we have shown this with a very specific example, namely the leakage of data via external mass storage devices. However, the thematic is much more general and should address your entire organizational landscape.

If you are interested in a forensic readiness assessment or need a team at hand that can jump on incidents and forensic cases 24/7/365, then you are kindly invited to visit our dedicated incident response webpage and drop us a note.

References


  1. Audit Policy Recommendations, Microsoft, https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations
  2. SANS posters, https://www.sans.org/security-resources/posters
  3. SANS Windows Forensics Analysis poster, https://www.sans.org/security-resources/posters/dfir/windows-forensic-analysis-170
  4. Sysmon Tool, Windows Sysinternals tool suite, https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon