Tag Archives: Windows

Adding HFS+ read support to Windows

Recently I had a coworker request the ability to read an HFS+ formatted drive with Windows. I found a few scattered articles that pointed to Apple’s “Boot Camp Support Software” including an HFS+ driver, and it does.

How to add read only HFS+ support to Windows (64-bit) using Apple’s HFS+ drivers

Download the latest “Boot Camp Support Software”

Search the Apple support site for “boot camp support software”


I used “Boot Camp Support Software 5.1.5640”

Extract BootCamp.msi from \BootCamp\Drivers\Apple\


Opening the msi with Orca revealed two drivers as well as the registry entries required to make them work.

Orca_Component Orca_Registry

Extract the files from BootCamp.msi

(I used 7-Zip)


Copy the drivers

Copy AppleHFS.sys and AppleMNT.sys to c:\windows\system32\drivers


Add registry entries

Based on the information from BootCamp.msi I created the following registry entries.

AppleHFS AppleMNT

Copy the text below into a .reg file and execute it to add the required entries.


“Group”=”File System”
“Group”=”System Bus Extender”


Using Splunk to watch for new binaries

The method presented below can be used to track any log attribute in Splunk; this example demonstrates watching MD5 hashes of executed files and loaded modules.

I’ve enabled Process Auditing via the Group Policy Editor and configured WLS to provide MD5 hashes.


I also enabled the “ModuleMonitor” in WLS which tracks loaded modules by process


and configured it to provide MD5 hashes for these as well.


Now that we are receiving hashes for all executed files and loaded modules, let’s start tracking them in Splunk.

First we’ll need to create a lookup table, there are a few ways to do this, a quick way is simply:

| outputlookup md5tracker.csv

This will create an empty csv file named “md5tracker.csv”.


Next, we need to search for and add the desired data to the csv file. I like to preserve some of the metadata that WLS reports with each record for later use – avoid re-searching, etc.

index=windows MD5=* | dedup MD5 | lookup md5tracker.csv MD5 as MD5 OUTPUT FirstSeen as LookupFirstSeen | where NOT LookupFirstSeen LIKE “%” | eval FirstSeen=_time  | table FirstSeen, MD5, BaseFileName, CompanyName, FileDescription, FileVersion, InternalName, Language, Signed, Length | inputlookup md5tracker.csv append=t | dedup MD5 | outputlookup md5tracker.csv

OK, let’s break this down:

Find the desired records: index=windows MD5=*

Remove duplicates: dedup MD5

Lookup the MD5s in our lookup table, returning the date first seen: lookup md5tracker.csv MD5 as MD5 OUTPUT FirstSeen as LookupFirstSeen

Remove records that already exist (field will be non-null): where NOT LookupFirstSeen LIKE “%”

Preserve the time stamp as desired output field: eval FirstSeen=_time

Format the desired fields into a table: table FirstSeen, MD5, BaseFileName, CompanyName, FileDescription, FileVersion, InternalName, Language, Signed, Length

Bring all the old data in and append it: inputlookup md5tracker.csv append=t

Remove duplicates (just in case): dedup MD5

Write out the new + old data: outputlookup md5tracker.csv

After the first run, you should have the results from your chosen time period now stored in md5tracker.csv


You’ll want to save this search


and schedule it to run every x minutes for the last x minutes; I schedule mine for every 15 minutes.


Once this is complete you’ll now have a search that keeps your lookup table up-to-date. Now what?

What you do next depends on how closely you feel this needs monitored. I run a second search every x minutes that alerts on all new entries in the last x minutes (based on the FirstSeen) field.

| inputlookup md5tracker.csv | where now()-FirstSeen < 2200 | table FirstSeen, MD5, BaseFileName, CompanyName, FileDescription, FileVersion, InternalName, Language, Signed, Length

This simply take the entire table and selects all entries in the last 2200 seconds (2200 / 60 = 36.6 minutes) and formats the results into a table. I scheduled it to run every 35 minutes with some overlap time (hence 2200 instead of 2100).


I also like to take an export of the hashes every so often and check them against Team Cymru’s malware hash registry – https://hash.cymru.com/

| inputlookup md5tracker.csv | table MD5

Export the results from Splunk, open the file in a spreadsheet, and copy/paste them into Team Cymru’s lookup for a quick analysis. An enterprising person might also create a custom Splunk command that uses their DNS lookup service (https://www.team-cymru.org/Services/MHR/#dns) and puts the results into the lookup table itself…

I currently have 23,537 executable hashes and 131,885 module (dll, etc) hashes, and see a few new ones at most search intervals during normal business hours. After the initial gathering, the periodic alerts are easy to quickly review, and you’ll know everything that is running on your Windows hosts.

Have your IOCs come to you

So, you’ve got the latest list of IOCs from a recent APT / malware report, time to kick off the scanner(s) / agent(s) of you choice and wait for the results. Wouldn’t it be nice to do a quick search of your logs and have the answer in seconds?  You’re already collecting logs from your Windows hosts (right?), shouldn’t they be doing more for you than providing logs?

Windows logging tools seem to have been stuck for a while at providing just the logs. The Splunk Universal Forwarder is an excellent example of a free, modern logging tool that does more than logs, and works with more than the Splunk server (hint hint); but even it does not provide what I believe is necessary data to support cyber security, forensics, and incident response.

Why not collect process hashes, named pipes, mutexes, semaphores, loaded modules, etc., and send them with the logs? Why not have these in real-time and be able to search your entire enterprise in seconds? There are plenty of server-side tools to collect, parse, and index  all of your logs; hosted on or off-site, free or pay. So, why not? You could know within minutes every new binary that is executed, including it’s metadata. You could know the initial infection vector, have the IOCs immediately, search all your hosts simultaneously, and that’s just the beginning!

Not finding a tool (at the time) that did what I wanted, I created WLS to provide exactly that; logs and the extra data to support answers I needed. There may be other programs that do this now (I’d love to know!), and I hope that others find this data as useful as I do.

Here are some WLS logs that answer example questions:

What did Firefox launch today that was downloaded from the internet?

Mar 15 09:05:24 [host] Security: LogType=”WLS”, BaseFileName=”Firefox Setup 19.0.2.exe”, Channel=”Security”, CommandLine=”‘C:\Users\Jason\Downloads\Firefox Setup 19.0.2.exe'”, CompanyName=”Mozilla”, Computer=”[host]”, CreatorProcessName=”firefox”, EventID=”4688″, EventRecordID=”65653″, ExecutionProcessID=”4″, ExecutionThreadID=”68″, FileDescription=”Firefox”, FileVersion=”4.42″, InternalName=”7zS.sfx”, Keywords=”0x8020000000000000″, Language=”English (United States)”, Length=”20564720″, Level=”0″, MD5=”68266231DF9FAF07018BAD5E028BDE67″, NewHash=”True”, NewProcessId=”0x1744″, NewProcessName=”C:\Users\Jason\Downloads\Firefox Setup 19.0.2.exe”, Opcode=”0″, ProcessId=”0xd58″, ProductVersion=”4.42″, ProviderGuid=”{54849625-5478-4994-A5BA-3E3B0328C30D}”, ProviderName=”Microsoft-Windows-Security-Auditing”, Recent=”True”, SHA1=”D0B0B20F1365BCDE53067012FFDAD23B52688028″, Signed=”True”, SubjectDomainName=”[host]”, SubjectLogonId=”0x25e5350″, SubjectUserName=”Jason”, SubjectUserSid=”[sid]”, Task=”13312″, TokenElevationType=”%%1938″, ValidSignatureDate=”True”, Version=”0″, Zone=”3″

Has a process with the  MD5 of 626A24ED1228580B9518C01930936DF9 executed?

Mar 22 19:29:00 [host] Security: LogType=”WLS”, BaseFileName=”GoogleUpdate.exe”, Cached=”True”, Channel=”Security”, CompanyName=”Google Inc.”, Computer=”[host]”, CreatorProcessName=”taskeng”, EventID=”4688″, EventRecordID=”67948″, ExecutionProcessID=”4″, ExecutionThreadID=”48″, FileDescription=”Google Installer”, FileVersion=”″, InternalName=”Google Update”, Keywords=”0x8020000000000000″, Language=”English (United States)”, Length=”133104″, Level=”0″, MD5=”626A24ED1228580B9518C01930936DF9″, NewProcessId=”0x16b4″, NewProcessName=”C:\Users\Jason\AppData\Local\Google\Update\GoogleUpdate.exe”, Opcode=”0″, ProcessId=”0xfcc”, ProductVersion=”″, ProviderGuid=”{54849625-5478-4994-A5BA-3E3B0328C30D}”, ProviderName=”Microsoft-Windows-Security-Auditing”, Recent=”True”, SHA1=”DCB86149B70829BB4320811B12686AE00131DBC3″, Signed=”True”, SubjectDomainName=”[host]”, SubjectLogonId=”0x25e5350″, SubjectUserName=”Jason”, SubjectUserSid=”[sid]”, Task=”13312″, TokenElevationType=”%%1938″, ValidSignatureDate=”False”, Version=”0″, Zone=”0″

What about a named pipe that starts with “chrome”?

Mar 19 23:44:51 [host] WLS_NamedPipeMonitor: LogType=”WLS”, ChangeType=”Created”, WLSKey=”10375″, Name=”chrome.5748.0.150278265″

Anything load mpengine.dll?

Mar 22 03:21:45 [host] WLS_ModuleMonitor: LogType=”WLS”, BaseFileName=”mpengine.dll”, ChangeType=”Added”, CompanyName=”Microsoft Corporation”, WLSKey=”14514″, FileDescription=”Microsoft Malware Protection Engine”, FileName=”c:\programdata\microsoft\microsoft antimalware\definition updates\{d9b17332-a27d-4442-8ff1-793d9607fc2e}\mpengine.dll”, FileVersion=”1.1.9302.0″, InternalName=”mpengine”, Language=”English (United States)”, Length=”7108640″, MD5=”9F4003841689C663254D54177EB97219″, Process=”MsMpEng”, ProductVersion=”1.1.9302.0″, SHA1=”F2F46BBE3F931B0927B2FEFE9707C0063C6872D6″, Zone=”0″

If you’d like more information on WLS, send me a note via the contact form.

What is WLS?

The Windows Logging Service (WLS) is a Windows service that forwards your event logs, along with user defined contextual data, to your log server.

Each process execution log is augmented with:

  • Creator process name
  • Command line parameters

and optionally:

  • Any file metadata (attributes, MAC times, version, size, etc)
  • Digital signature flag
  • Entropy
  • Environmental variables (per process)
  • Hashes (MD5, RIPEMD160, SHA1, SHA256, SHA384, SHA512)
  • Zone

WLS can also log the following information to your log server:

  • Certificates
  • Devices
  • Drives
  • File system changes – including file metadata
  • Listening and connected ports, with associated process information
  • Loaded modules – including file metadata
  • Mutexes, semaphores, and other Windows objects
  • Named pipes
  • Optical media used
  • Performance counters
  • Registry changes
  • WMI information

I’ll cover the details of each of these features and configuration examples in upcoming posts, as well as provide example Splunk searches I use for day-to-day operations.

If you’d like more information on WLS, send me a note via the contact form. WLS is currently available to US entities, but does require a signed license agreement.