Manipulating Windows File Protection and Indicators of Compromise

[Nytro]

[h=2]Tuesday, 06 December 2011[/h] [h=3]Manipulating Windows File Protection and Indicators of Compromise[/h] In my previous blog post I wrote about how when searching for malicious processes, it helps to know about Windows File Protection and how it works. Harlan Carvey commented about how he didn't see the connection between my mentioning WFP and hunting for malware. So, in this blog post, I thought I would clarify, as well as discuss how WFP can be subverted and what indicators of compromise that would leave behind.

Let's start with my methodology for hunting malware. Basically, WFP prevents a user from altering a legitimate windows process. If an attempt is made to alter one such file, the user will be informed that an attempt to alter a Windows protected file has taken place and either the alteration will simply be prevented from making a change, or the file will be copied from the version that is stored in dllcache.

Here is an example of file modification being prevented:

c:\Windows\System32>echo test123 >> dllhost.exe

Access is denied.

Here is an example of what the error looks like in the system logs:

c:\tw_pogue1\CEPOGUE-NGQ83PM\vol\evt_sys.txt: 506,System,Windows File Protection,INFORMATION,CEPOGUE-NGQ83PM,11/23/2011 10:05:42 AM,64001,None,"File replacement was attempted on the protected system file dllhost.exe. This file was restored to the original version to maintain system stability. The file version of the bad file is 5.1.2600.2180, the version of the system file is 5.1.2600.2180."

So, what many attackers will do, is slightly misspell the names of legitimate binaries so as to make them "look" like legitimate ones...something I call, "malware subterfuge". So instead of using the name, "dllhost.exe", they will use something like, "dl1host.exe" or, "dllhsot.exe". Alternatively, they can use the legitimate name if it's not in the same directory as the legitimate Windows binary. So, instead of making using, "C:\Windows\system32\dllhost.exe" they will use, "C:\Windows\System32\drivers\dllhost.exe".

Because of WFP, spotting malware can be easier for investigators who know what they are looking for. Also, you can see that WFP makes it difficult for an attacker to name their binary a legitimate Windows name, from a legitimate directory. Difficult, but not impossible.

As Harlan correctly pointed out on his blog, " Windows Incident Response", WFP can be disabled. This may sound scary, but actually happens all the time when Windows makes updates to existing files through the Windows Update process. Additionally, Harlan documented this process briefly in his book, "Windows Forensic Analysis, Second Edition" on pages 328 - 330. As Harlan states, "I found that there is reportedly an undocumented API call called SfcFileException (www.bitsum.com/aboutwfp) that will allegedly suspend WFP for one minute. WFP "listens" for file changes and "wakes up" when a file change event occurs for one of the designated protected files, and does not poll the protected files on a regular basis to determine whether any have been modified in some way. Suspending WFP for one minute is more than enough time to infect a file, and once WFP resumes there is no other way for it to detect that that a protected file has been modified."

Later, in a conversation with Harlan, we talked about the frequency of just such an attack. Personally, I have never seen this, and Harlan indicated that he has only seen it a few times. So, this was one of those things that is heavy in theory and light in research. So, I wanted to see what it would really look like if I disabled WFP and made a modification to a protected file. Would it leave behind any indicators of compromise in memory, event logs, or a forensic timeline?

My first step in answering these questions was to get a hold of the tools mentioned by Harlan from Bitsum Technology. I contacted the developer, who was gracious enough to send me a copy for research. I have left his name out of this post for privacy (No, I will not release his code, so don't ask!). If you want to do your own research, feel free to visit Bitsum Technologies like I did.

With my copy of WFP_deprotect in "hand", I copied it to a Windows XP VM that I use for malware analysis. To keep things simple (as I am only trying to illustrate the potential of the tool, and the IOC left behind by modification) I decided to only append a series of capital, "AAAA"s to the end of a protected file.

So, I stopped WFP:

?

Next, 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

Finally, I waited the minute that it would take for WFP to kick back on, and I rebooted the system. Then, I ran strings against the target file again, and check it out...my "A"s are now at the end of the file.

Mission accomplished. I successfully edited a file that was protected by WFP. Once WFP kicked back on, the modified version of the target file is now the version that the system considers to be "good". Any attempt to modified the new version of the WFP protect file by users, or AV, or anything else (except by the same means that I used to modify the file in the first place) would be stopped.

Now, my change was relatively simple...I just threw some "A"s at the end of the file. Think about the implications if I had more nefarious goals in mind. I could modify a WFP protected file, allowing it to maintain its original functionality while maybe appending a key logger, or memory dumper to the end of the file. Now, the new weaponized process would have a legitimate Windows name, run from a legitimate directory, BECAUSE it would actually BE the legitimate file as far as the operating system was concerned.

OK, so let's say I am working a case where this actually happened. My initial effort to detect malware would not yield any results because all of the running processes would have their expected names, and be running from their expected directories. So now what? Are we all hosed if we run into this, or are there IOCs that would be left behind by this kind of modification?

Well, don't lose faith, because there indeed ARE IOCs...which I am about to explain...

First of all, the forensic timeline (one of my favorite tools) would show access and modification times that would be updated:

Below are the entries from the Master File Table ($MFT), the Standard_Information (SI) attribute is on the top (above the file name), and the File_Name (FN) attribute are on the bottom (below the file name). Notice the Access and Change dates are Nov 23, 2011, which is the date I ran my test.

M: Wed Nov 23 15:35:37 2011 Z

A: Wed Nov 23 16:04:46 2011 Z

C: Wed Nov 23 16:04:28 2011 Z

B: Wed Nov 23 15:35:37 2011 Z

FN: dllhost.exe Parent Ref: 865 Parent Seq: 3

M: Wed Nov 23 15:35:37 2011 Z

A: Wed Nov 23 15:35:54 2011 Z

C: Wed Nov 23 15:48:56 2011 Z

B: Wed Nov 23 15:35:37 2011 Z

M: Wed Nov 23 16:07:57 2011 Z

A: Wed Nov 23 16:23:54 2011 Z

C: Wed Nov 23 16:23:54 2011 Z

B: Thu Aug 23 12:00:00 2001 Z

FN: dllhost.exe Parent Ref: 29 Parent Seq: 1

M: Wed Aug 4 06:56:50 2004 Z

A: Wed Nov 23 16:05:41 2011 Z

C: Wed Nov 23 16:05:42 2011 Z

B: Wed Jan 26 20:37:00 2011 Z

Remember our error from the system event logs? Let's take a closer look in conjunction with the timeline data...

c:\tw_pogue1\CEPOGUE-NGQ83PM\vol\evt_sys.txt: 506,System,Windows File Protection,INFORMATION,CEPOGUE-NGQ83PM,11/23/2011 10:05:42 AM,64001,None,"File replacement was attempted on the protected system file dllhost.exe. This file was restored to the original version to maintain system stability. The file version of the bad file is 5.1.2600.2180, the version of the system file is 5.1.2600.2180.

Within two (2) seconds, the original file from the ServicePackFile directory is accessed, created again in the LastGood directory, accessed in dllcache, and the modified back to its original state in the system32 directory.

Wed Nov 23 2011 10:05:41,5120,.a..,r/rrwxrwxrwx,0,0,32127-128-3,"C:/WINDOWS/ServicePackFiles/i386/dllhost.exe"

Wed Nov 23 2011 10:05:41,5126,.acb,r/rrwxrwxrwx,0,0,974-128-4,"C:/WINDOWS/LastGood/system32/dllhost.exe"

Wed Nov 23 2011 10:05:47,5120,.ac.,r/rrwxrwxrwx,0,0,978-128-1,"C:/WINDOWS/system32/dllcache/dllhost.exe"

Wed Nov 23 2011 10:07:57,5166,m...,r/rrwxrwxrwx,0,0,975-128-3,"C:/WINDOWS/system32/dllhost.exe"

OK...so we can see the attempted change, but what about the actual change? Is there any evidence of that? Well...not really, no. I ran my volatile collection script against the VM which gathers a huge amount of data as well as the contents of memory. Apart from dllhost.exe being present, apart from the timeline, there were not any IOCs of modification. Pretty scary huh!

So, what can we learn from testing this type of attack?

First of all, knowing that this type of attack vector exists is a good start!

Second, it underscores the importance of creating a forensic timeline, and understanding how to read its contents.

Third, it is critically important to conduct live analysis in cases where you suspect that malware is present. Simply relying on AV signatures to identify and prevent malicious process from being executed is just not going to be effective anymore. Good investigators are going to need to start getting better at behavioral analysis, and being well versed enough with how operating systems "should" run under "normal" conditions so that they can quickly identify spot something that is "abnormal".

Finally, we are going to have to get better at identifying multiple data points that all indicate the same activity did (or did not) take place. For example, simply identifying the presence of a file would be a single data point. However, if you identify the presence of that same file AND can match that up with an entry in the event logs AND see timeline activity, AND have live analysis data that show "unusual" behavior, THEN you may have something a bit more noteworthy.

In such a case, you could use that intel to help identify the likely malicious process, and extract it for further analysis.

So bottom line, while this is a relatively simple attack, it can present an extremely difficult scenario for an forensic investigator to successfully identify. Successful detection will require a combination of techniques, that yield multiple data points that will need to be expertly strung together so that a meaningful theory can be formulated.

Posted by Chris Pogue on Tuesday, 06 December 2011 at 08:24 AM

Sursa: Manipulating Windows File Protection and Indicators of Compromise - SpiderLabs Anterior

[Paul4games]

Foarte interesant, sub Windows Vista/7 acel api nedocumentat are nevie de privilegii de administrator?