Finding Cryptolocker Encrypted Files using the NTFS Master File Table

For the most part, everyone seems to be familiar with the new variants of Cyptolocker making the rounds these days. To quickly summarize, this form of ransomware that encrypts documents and pictures found on local and mapped network drives in an attempt to obtain payment for the decryption keys. The attackers are using decent encryption and the malware is very efficient. A good write up can be found here.

Recently, I dealt with an infection and during forensic analysis noted that the NTFS Master File Table $SI Creation and Modified dates remained unchanged on files encrypted. I made a note of this for later and circled back around during post analysis.

Since the infection not only encrypted all the documents on the user's local drive but also files located on mapped file shares too, I decided to grab the MFT from the Windows file server. Using analyzeMFT and MFTParser, I was able to parse the 9 GB $MFT in a reasonable time frame. Identifying some known encrypted files by the $FN file name, I noted the only date in the MFT record that coincided with the infection was the MFT Entry Date or date the MFT record itself was modified. Using this, I filtered out all records that had $SI or $FN time stamps that preceded this.

The result was I was able to identify over 4400 files encrypted on the file share. Not bad for an infection that only lasted a few hours before being caught by the most recent Antivirus signature. Load up the backup tapes boys!

Happy Hunting!

Updated November 27, 2013 2:15 PM

After exchanging a few emails with some people in the industry, I think what we are seeing here is an example of File System Tunneling. To be specific, if a file is removed and replaced with the same file name (in the same folder) of a NTFS drive within fifteen seconds (default with NTFS) it will retain the original NTFS attributes. I have seen this before with other Trojans as a way to avoid detection. Just an educated hunch. More info on File System Tunneling can be found here. Thanks to all who responded to me.

Updated November 27, 2013 3:00 PM

Just a quick update of some of the IOC's (Indicators of Compromise: MD5, SHA1, Location) for this particular variant;

2a790b8d3da80746dde3f5c740293f3e    7d27c048df06b586f43d6b3ea4a6405b2539bc2c    \\.\PHYSICALDRIVE1\Partition 2 [305043MB]\NONAME [NTFS]\[root]\ProgramData\Symantec\SRTSP\Quarantine\APEA53C866.exe
f1e2de2a9135138ef5b15093612dd813    ea64129f9634ce8a7c3f5e0dd8c2e70af46ae8a5    \\.\PHYSICALDRIVE1\Partition 2 [305043MB]\NONAME [NTFS]\[root]\Users\%userprofile%\AppData\Local\Temp\e483.tmp.exe
714e8f7603e8e395b6699cea3928ac81    36f40d0be83410e911a1f4231eeef4e863551cee    \\.\PHYSICALDRIVE1\Partition 2 [305043MB]\NONAME [NTFS]\[root]\Users\%userprofile%\AppData\Roaming\dhsjabss\dhsjabss
17610024a03e28af43085ef7ad5b65ba    77f9d6e43b8cb1881396a8e1275e75e329ca7037    \\.\PHYSICALDRIVE1\Partition 2 [305043MB]\NONAME [NTFS]\[root]\Users\%userprofile%\AppData\Roaming\dhsjabss\egudsjba.exe
621f35fd095eff9c5dd3e8c7b7514c1e    f03233e323f9a49354f2d6c565b6ec95595cc950    \\.\PHYSICALDRIVE1\Partition 2 [305043MB]\NONAME [NTFS]\[root]\Users\%userprofile%\Desktop\Iqbcxbvszzgdxjvbp.bmp

I wanted to also comment on using software restriction policies in Windows to block executable's from running from locations such as C:\Users\%userprofile%\AppData\Local\Temp. With no local admin rights, users only have the ability to write to three locations on modern versions of Windows (by default). Thee are;

C:\$Recycle.Bin
C:\ProgramData
C:\Users\%Userprofile%

The attackers know this and 99% of infections I see in my environment are using these locations efficiently (including this one).

Unfortunately, a lot of legitimate software also use these locations. So using, suggestions such as Software Restriction Policies, to stop the execution from these locations in a large enterprise environment may or may not be realistic. I suspect adding rules, to check if the executable is legitimately signed, would reduce false positives. I am, however, seeing malicious code signed on occasion. In conclusion, there is no silver bullet here but I personally plan to explore these defenses more and will update what I find as I do.

Lastly, some online posts of this malware has mentioned the use of the HKEY_CURRENT_USER\Software\CryptoLocker location in the Windows registry as a way to determine what files have been encrypted. I just wanted to mention, that I did carve the ntuser.dat file from the compromised system and noted that this location did exist in the registry. It however, did not contain any entries on what files were encrypted.

Updated December 05, 2013 3:00 PM

Since Michael Mimosa over at Threat Post was kind enough to link back to my post, I thought I would return the favor. Forensics Method Quickly Identifies CryptoLocker Encrypted Files

ZAccess/Sirefef.P Artifacts

I wanted to share a few interesting artifacts from two ZAccess/Sirefef.P compromises I recently had to deal with. In both infections, malicious files were written to hidden sub directories located in the User and System accounts $Recycle.Bin's. Much like other variants of this Trojan, these files were injected into legitimate processes including explorer.exe and services.exe. At first I thought the infection had mucked with the permissions of the hidden sub directories within the Recycle.Bin but then noticed the S-1-5-18 SID, indicating the use of the SYSTEM account.





The first compromise went a step further and overwrote the Wdf01000.sys driver under \SystemRoot\System32\Drivers. I would have missed this if I had not dumped the NTFS Master File Table and used the $SI Entry Date when creating my timeline. By overwriting the existing file, it would appear the other NTFS timestamps were preserved due to File System Tunneling (ref: KB172190 and WIR Blog). A very interesting artifact indeed.

The first variant loaded some typical Fake Antivirus into the C:\ProgramData folder. Nothing new there but with the second variant, I noted the creation of a lot of Internet cache files under \SystemRoot\System32\Config\Systemprofile\AppData in what appeared to be the presence of click fraud.

Overall, a couple of interesting variants that I enjoyed playing with. Here's the hashes for reference.

[root]\$Recycle.Bin\S-1-5-18\$a032773db1be215125d280696ec7b357\n
MD5: 3aaac8a9352dde4e2073a7814514bd9d
SHA1: 321132983c3fc25448e19ae63e65cb127f28c5b7 

[root]\$Recycle.Bin\S-1-5-18\$f58c247e192203c97063e19c12229833\n
MD5: cfaddbb43ba973f8d15d7d2e50c63476
SHA1: 34206a971fe3cbb1acf2ce8bb9f145bfd78e256e 

Happy Hunting!

The WTF of the Week

Last week someone mentioned to me you can retrieve your Wireless SSID and Encryption key for the Verizon FIOS Actiontec router via the support menu of the TV guide. Somehow this did not surprise me and since the router is most likely sitting next to your TV, well physical access has been gained anyways.But it did get me curious on if Verizon allowed this functionality via the customers online account. Five minutes later...Well I'll just let these screen shots speak for themselves.

Now I could insert a rant here. But really what's the point? We all know this is just a bad idea. So remember to shred your bills or as I prefer put them to good use with the fire pit on a Saturday night.

 

Happy Hunting!