Recently, we have seen the emergence of a malware package known as, “Webcheck.dll” in breaches. The following scenario involving the “Acme Corporation” shows how the malware is deployed.
This is a malware case on a Point of Sale (POS) system at the Acme Corporation. I know that the malicious file in this case is called, “webcheck.dll”, and I know it was injected into the Explorer.exe process (seen from a RAM dump, but not relevant for this blog post). I really wanted to nail down the malware deployment, so my timeline needed to be expanded to include the registry and event logs. The information from the active file system was simply not enough for me to figure out what happened since all it gave me was the date that the file appeared on the system.
To accomplish this, I used Harlan Carvey’s “regtime.pl” (comes with SIFT 2.0) to integrate the LastWrite times of the SYSTEM and SOFTWARE hives and the NTUSER.DAT file for the user, “Administrator”. Additionally, I included the Windows Event logs using Kristinn Gudjonsson’s tool, Log2timeline.
Here is the command syntax I used for generating my supertimeline:
E:\fls –m ‘C:/’ –r –o 63 >> C:\cases\Acme\timeline\pos\pos_supertimeline_bodyfile
C:\> Perl C:\tools\regtime\regtime.pl –m HKLM_SYSTEM –r C:\cases\Acme\registry\pos\system >> C:\cases\Acme\timeline\pos\pos_supertimeline_bodyfile
(Repeat this step for each registry hive you want to include, changing the HKLM_ as appropriate. For the NTUSER file, I use HKU_).
C:\> Perl C:\tools\log2timeline\log2timeline.pl –m “SYSTEM_EVENTS” –z -f evt C:\cases\Acme\registry\SysEvent.evt >> C:\cases\Acme\timeline\pos\pos_supertimeline_bodyfile
Once you have your completed bodyfile, then you can use mactime.pl (Available in The Sleuth Kit) to convert it to a timeline. Here is the proper syntax:
C:/>Perl C:\tools\TSK\mactime.pl –d –b C:\cases\Acme\timeline\pos\pos_supertimeline_bodyfile >> C:\cases\Acme\timeline\pos\pos_supertimeline.csv
During the initial phases of the investigation, I found that the malware had a birth date on the infected systems of October 22, 2009.
Thu Oct 22 2009 02:08:20,10240,...b,r/rrwxrwxrwx,0,0,8840-128-3,'C:/'/WINDOWS/webcheck.dll
***There is a legitimate webcheck.dll located in C:\Windows\system32…this is obviously a different file by the same name.***
I verified the validity of the birth time through the Master File Table ($MFT) by comparing the birth date values from the $Standard_Information and $File_Name attributes (a different blog post for certain). This showed me that no modifications commonly referred to as “Time Stomping” had taken place. Once I knew I had a solid date, I could use that date as my focus for my super timeline search.
C:\cases\ACME\timeline\POS>strings pos_supertimeline.csv | grep -i "oct 22 2009"
Thu Oct 22 2009 02:08:08,0,m...,0,0,0,0,HKCU_ADMIN_USER/Software/Microsoft/Windows/CurrentVersion/Explorer/RunMRU
The first hit I had, as can be see above, refers to the RunMRU from the admin user. This key basically records the history of commands that are entered into the Windows “run prompt”. So, using Harlan Carvey’s RegRipper (available at www.regripper.net ), I parsed the admin users NTUSER.DAT file and extracted the RunMRU key.
RunMru
Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
LastWrite Time Thu Oct 22 02:08:08 2009 (UTC)
MRUList = cba
a regedit\1
b control userpasswords2\1
c cmd\1
As can be seen above, the LastWrite time on the key is October 22, 2009…same time and day the malware appeared. Hrm…coincidence…I don’t think so, but let’s keep digging. You can see that the MRUList is read, “cba”, which means that regedit was the last command typed into the run prompt.
So, the next item in my timeline shows that the InProcServer32 key for the Class ID (CLSID) for E6FB5E20-DE35-11CF-9C87-00AA005127ED was modified. So what the heck does that mean? Well, InProcServer32 is a registry key that indicates the path to threaded dlls. These are dlls that are used by various legitimate Windows processes to do different things. The snippet from my super timeline below shows the modification was made at the same time as the malware appeared…again…not a coincidence.
Thu Oct 22 2009 02:08:20,0,m...,0,0,0,0,HKLM_SOFTWARE/Classes/CLSID/{E6FB5E20-DE35-11CF-9C87-00AA005127ED}/InProcServer32
To illustrate further, here is the actual InProcServer32 key from my clean Windows XP box. Pay special attention to the path of the dll. It’s the absolute path, “C:\Windows\System32\webcheck.dll”.
“Known Good”
Now, the screenshot below is from the infected system. What a tick…what’s this? The key type has changed from “REG_SZ” to “REG_EXPAND_SZ”, and the path no longer points to an absolute path, but to an environment variable?! Mep?!
The “EXPAND” key type allows for…you guessed it…environment variables and special characters instead of just absolute paths. This is great for malware, since the writer of the malicious code can never be certain what the Windows root will be (based on the version of Windows). So now the threading for webcheck.dll is no longer pointing to the legitimate file, but to the malware!
“Known Infected”
Nice touch, eh! So when the Explorer.exe process is initiated, the dll will be loaded like normal, only instead of performing its standard function, it is siphoning credit card data. Additionally, I checked to make sure “webcheck” was an approved shell extension (HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved)…and it was listed. So not only did the attackers use a legitimate threading, but they made sure to use a shell extension that was trusted by Windows.
In conclusion, we have seen how to create a super timeline, and how they can provide value to a forensic investigation. I was able to identify exactly how the malware was deployed, and how it became part of the infected system. Also, now I have established a clear Indicator of Compromise, so that going forward, I can “crack” similar cases that much quicker.
Comments