Cyber Adversaries, or malware authors, are motivated to remove the traces of the malware’s execution for a variety of reasons including evading “Defense Mechanisms”, as well as ensuring the malware researchers cant access the malicious files easily. MITRE ATT&CK Matrix categorizes tactics for such “Defense Mechanisms” under techniques for “Indicator Removal on Host” with various sub-techniques, one of them being “File Deletion”
One of the critical elements of an effective Cyber Security strategy is ‘breadth of visibility’. Needless to say, the breadth of visibility goes hand in hand with the ability to manage the costs of creating that visibility. Such costs would include not only just the costs of the sensors to generate that visibility or the cost of storage of data, but also the operational and analytical costs involved in being able to generate insights from that visibility because “visibility” itself has many nuanced layers. For example, in the world of endpoint security, EDRs provide such sensors and usually have coverage for detecting file deletion events. The importance of capturing file deletion gets additional validation when, arguably, one of the most commonly used tools for monitoring system activities, Microsoft’s Sysmon tool added the capability for monitoring file delete events starting with version 11.0 released in the early part of 2020. But does that mean this visibility suffices the coverage of the technique that the ATT&CK Matrix is alluding to? Let’s find out.
The standard Win32 method to delete a file requires that the file be opened with FILE_FLAG_DELETE_ON_CLOSE such that when CreateFile() API is invoked with this flag, the file is marked for deletion upon closure of the handle. Similar functionality is wrapped in the DeleteFile() API that lets you delete the file from the file system. Either of the 2 methods are captured through a Windows mini-filter driver or via API monitoring (used by most EDR sensors or other monitoring tools) where the same set of operations are observed, irrespective of which userland Win32 API was used. Such events get reported as Event 26 (FileDelete) by Sysmon as described in the blog above. A similar event is captured by EclecticIQ’s Osquery Extension which provides the real-time events monitoring capability into the Osquery agent. Osquery’s SQL interface allows to format and structure such events in easy to ingest, store, and inquest SQL tables to assist with generating insights on visibility data.
The picture above shows both the agent sensors, Sysmon and Osquery agent with EclecticIQ Extension, capturing a file delete event that was generated by a test tool posted here. But then here comes a catch. [Wouldn’t make for an interesting read if there was no catch]
Windows OS provides more than one method for a file to get deleted. In order to self-delete, malware like Zero-Access use another trick that would help them evade such monitoring of delete files. This method requires that the DeleteFile member of the file’s FILE_DISPOSITION_INFORMATION be set to TRUE with SetFileInformationByHandle () API.
In the above picture, the test tool creates a dummy file and deletes it by setting the DeleteFile flag in its FILE_DISPOSITION_INFORMATION. Apparently, when a file is deleted with this technique, Sysmon doesn’t trigger a FileDelete Event. When the same test is run with Sysmon v13.31 running in the background, we can see that Sysmon captured the FileCreated event but doesn’t report any FileDelete event.
Such nuanced gaps in visibility are what enable malware authors to adopt techniques for avoiding detection from Blue Teamers and Incident Responders.
In the latest release of EclecticIQ Osquery Extension (also shipped as part of EclecticIQ Endpoint Response), this capability has been added to detect the file deletions by setting the Disposition, over and above the existing capabilities of capturing file delete events. The event shows up under file system events collected by the extension with action as FIlE_DELETE_BY_DISP.
Combining the dual advantages of Osquery’s SQL form factor and visibility into a range of real-time events on Windows OS via an extension, the EclecticIQ Agent aims at solving both problems, i.e collection of data in a query-able, structured, relational format right at the sensor along with a breadth of capabilities to minimize blind spots.
To learn more, visit EclecticIQ Endpoint Response or contact firstname.lastname@example.org