I’ve been sitting on this one for a month or so hoping I could uncover a better solution. Unfortunately I’ve not been as successful as I would like so here it is.
Chris Pogue at SpiderLab’s Anterior blog posted Manipulating Windows File Protection and Indicators of Compromise which contained lots of goodies.
Basically it was a carry on from a previous post on Windows File Protection and malware hunting. In this post Chris shows how WFP can be “subverted” by malware and what clues are available to the incident responder for searching based on his and Harlan Carvey’s prior work.
In Chris’s post he uses an unpublished tool to temporarily disable WFP, change “code” inside a protected system file, then allow WFP to restart, reboots the system and sees if WPF leaves the modded file alone. It did. Chris then documents the changes observed.
I’m focusing on this part here:
let's take a MD5 checksum of dllhost.exe for validation that we have successfully modified our target file.
c:\Windows\System32>md5deep dllhost.exe
a63dc5c2ea944e6657203e0c8edeaf61 c:\Windows\System32\dllhost.exe
OK, next, I ran a strings against the target file so make sure there was not the same string content that I decided to use. In this case, a series of upper case letter "A"s.
C:\test>strings c:\WINDOWS\system32\dllhost.exe | grep AAAAAAAA
Now, I am going to simply append 20 upper case "A"s to the end of the target file.
C:\test>echo AAAAAAAAAAAAAAAAAAAA >> c:\WINDOWS\system32\dllhost.exe
Let's run strings against the target file to see if the modification took.
C:\test>strings c:\WINDOWS\system32\dllhost.exe | grep AAAAA
AAAAAAAAAAAAAAAAAAAA <-- This is the results of the grep search.
Now let's check the MD5 checksum of the target file to see if it changed...as you can see by comparing it to the value from our initial MD5, it didn.
C:\test>md5deep c:\WINDOWS\system32\dllhost.exe
6fb2c878750a84946efacfc50c8e1f59 c:\WINDOWS\system32\dllhost.exe
(Note: I think Chris has a typo in the part I have bolded above. I suspect he meant to type “it did” as clearly the MD5 is now changed from the original file MD5 hash.)
While Chris focuses on the MFT and system logs to flag the event for additional attention, I was focusing on the (relatively easier to spot?) MD5 change itself. If you can spot that the change occurred, then maybe you can drill faster into the corresponding logs/records for event clues on the change itself.
Indeed, Rmdarcher commented in the post that one could “…run the System File Checker (sfc.exe)” to look for modifications. Chris agreed and responded,
“I think the real challenge is not in the identification of the modification, but in the detection of the single file that was modified.
“As I pointed out in the post, and what I still think is the real meat of the issue, is how to tell? How can you tell if a legitimate Windows process has become weaponized. Again, think the best way to even get the point where you can employ something like SFC, is through live analysis, and correlation of data points.”
So what go-to options does a sysadmin have to see if a system’s protected files have been compromised by malware short of combing through the MFT and system logs?
Here are the ones I have come up with so far.
As Rmdarcher commented there is the Windows System File Checker.
- System File Checker - Wikipedia
- How to Run the System File Checker (Sfc.exe) Offline in Windows 7 and Vista - The Winhelponline Blog
- Microsoft Windows XP - System File Checker (sfc) - Microsoft Windows XP Pro Product Documentation
- How to use the System File Checker tool to troubleshoot missing or corrupted system files on Windows Vista or on Windows 7 - Microsoft Support KB 929833
- Description of the System File Checker Tool (Sfc.exe) - Microsoft Support KB 185836
- Windows File Protection and Windows - WIndows Dev Center on MSDN
- Availability and description of the File Checksum Integrity Verifier utility - Microsoft Support KB 84120
- How to analyze the log file entries that the Microsoft Windows Resource Checker (SFC.exe) program generates in Windows Vista - Microsoft Support KB 928228
That was a good starting point and eventually led me next to the File Checksum Integrity Verifier from Microsoft.
Warning The Microsoft File Checksum Integrity Verifier (FCIV) utility is an unsupported command-line utility that computes MD5 or SHA1 cryptographic hashes for files. Microsoft does not provide support for this utility. Use this utility at your own risk. Microsoft Product Support Services (PSS) cannot answer questions about the File Checksum Integrity Verifier utility.
The File Checksum Integrity Verifier (FCIV) utility can generate MD5 or SHA-1 hash values for files to compare the values against a known good value. FCIV can compare hash values to make sure that the files have not been changed.
With the FCIV utility, you can also compute hashes of all your critical files and save the values in an XML file database. If you suspect that your computer may have been compromised, and important files have been changed, you can run a verification of the file system files against the XML database to determine which files have been modified.
The FCIV utility runs on Microsoft Windows 2000, Windows XP, and Windows Server 2003.
In this case you would need to generate a “baseline” on a known/good system like the one you are comparing against. I imagine you would need to be at the same patch-level as your target system otherwise you run the risk of getting lots of noise to sort through.
- Uncover File Manipulations With File Checksum Integrity Verifier [Windows] - ghacks.net
- How to use the Microsoft FCIV command-line checksum tool - Michael Cobb at SearchSecurity.co.UK
- Microsoft File Checksum Integrity Verifier (FCIV) -George Birbilis @zoomicon
In that last link above "Kirill" comments a tip that leads to another tool, FCIV for PowerShell.
http://www.sysadmins.lv/content/scripts/PSFCIV_1.0.ps1
The author, Vadims Podāns, maintains an English blog here: PowerShell Crypto Guy's weblog
Unfortunately, it doesn’t appear any of the FCIV for Powershell related posts are in English. You can hop over to the Russian pages and do some translations to get the meat of Vadims’s work here: FCIV (Russian original pages) or trust Google Translate here Google Translate versions of PowerShellFCIV tagged posts.
The tool I would probably reach for first is OSForensics by PassMark Software. This is a very strong tool in its own right, but the component we are focusing here on is the “Verify / Create Hash”.
From the OSForensics - Download Hash Sets page:
OSForensics allows you to use Hash Sets to quickly identify known safe files (such as operating system and program files) or known suspected files (such as viruses, trojans, hacker scripts) to reduce the need for further time-consuming analysis. You can download some sample hash sets below. They are individually zipped.
- Office 2007 Enterprise (Vista) hash set (1,313 KB)
- Office 2007 Enterprise (Win7) hash set (1,978 KB)
- Common Keyloggers hash set (124 KB)
- Win7 Ultimate (32-bit) hash set (18,825 KB)
- Win7 Enterprise (x64) hash set (11,670 KB)
- Vista Business (32-bit) hash set (8,475 KB)
- Vista Business (x64) hash set (8,069 KB)
- XP Professional SP3 (32-bit) hash set (1,889 KB)
- XP Professional SP2 (x64) hash set (1,456 KB)
This is a nice “baked-in” feature for looking for suspect files. And again, I’m not sure how much “noise” would need to be sifted through based on OS patching updates to the system files.
Another nice feature of OSForenics hashing support is the ability to Import NSRL hash sets from NIST.
There are a lot of great resources on the web related to use of the NSRL hash sets and similar collections.
- Hash Database - SANS Internet Storm Center
- National Software Reference Library - NSRL Project Web Site
- jessekornblum: NSRL Query Tool - Jesse Kornblum tips us to a new project NSRLQuery by Robert Hansen.
“He's written a client/server program, NSRLQuery, which takes the output of sha1deep and compare it against the NSRL. (Why SHA-1 hashes? The NSRL contains MD5, SHA-1, and CRC32 hashes. You have to pick one...) The results are written to files hits.txt and misses.txt. The former are the files from the NSRL, the latter are those which are not.”
- Malware Hash Registry - Team Cymru
- FileAdvisor | The Best Search Engine for Identifying Software Files - Bit9
md5deep and hashdeep (now at version 4.0.0) also provides a mechanism to “…to compute, match, and audit hashsets. With traditional matching, programs report if an input file matched one in a set of knows or if the input file did not match. It's hard to get a complete sense of the state of the input files compared to the set of knowns. It's possible to have matched files, missing files, files that have moved in the set, and to find new files not in the set. Hashdeep can report all of these conditions. It can even spot hash collisions, when an input file matches a known file in one hash algorithm but not in others. The results are displayed in an audit report.”
More on md5deep/hashdeep Audit Mode.
I see that George M. Garner Jr.’s Forensic Acquisition Utilities set includes the following tool that may be of use:
FMData.exe: An original utility to collect files system metadata, to produce and verify security catalogs (cryptographic hash sets) using one or more cryptographic hash algorithms and to verify system binaries using the system file checker (SFC) API.
Finally, there is the application “ICE ECC” from ice-graphics. This is probably an “off-label” application and I’m not sure how well it would work on a C:\Windows\System like directory. Again, you would need to first “baseline” a known/pure system and then you could compare a suspect system against that baseline to look for clues.
If anyone else knows of any ways to either baseline and/or cross-check the hashes on protected Windows System files to ensure their integrity hasn’t been subverted/compromised by an injected malware attack like Chris and Harlan originally discuss, please drop a line in the comments regarding the tool and/or technique.
Much appreciated.
--Claus V.
0 comments:
Post a Comment