At long last - a blog post about Incident Response in the self-proclaimed 'Incident Response' blog!

Before I finally crash for the night there are two things I wanted to bring to the attention of folks interested in Windows IR that my team has come across in recent weeks. 

Below I'm going to discuss two hiding / obfuscation techniques that are surprisingly easy to implement and alarmingly effective at meeting their objective of hiding from administrators in plain site.

First - let's talk about wierd file names.  We got a security related escalation last week where a customer had a file like this on their drive:

12/22/2004 02:21p 389,120 ??plorer.exe

Notice the strange question marks showing up in the CMD shell when doing the DIR command?  In Explorer a file with this name could not be found.  We investigated further and used a tool called 'renamer' to get some more information on this file - here's the output:

0435 0445 0070 006c 006f 0072 0065 0072 002e 0065 0078 0065

Notice the unicode character codes highlighted in orange above?
So 0435 is this character: http://www.fileformat.info/info/unicode/char/0435/index.htm
And 0445 is this one: http://www.fileformat.info/info/unicode/char/0445/index.htm

So these are Cyrillic characters and 0435 is a Cyrillic (е) that looks like a Latin 'e' and 0445 is a Cyrillic (х) that looks like a Latin 'x' . . . interesting no?
Why is this so clever?  Several reasons:

1. Despite appearances this file is not the traditional 'explorer.exe' the 'e' and the 'x' are technically different characters even though visually they look the same when rendered inside of the shell (Explorer).  Since they are different characters this is a completely different file name on the file system and this malicious 'explorer.exe' can co-exist in the same directory as the real 'explorer.exe' (even though in this case the miscreants put it in system32 they could have easily placed it in winnt and it would have coexisted side by side with the real explorer.exe without triggering SFP).
2. This process will show up as 'explorer.exe' in Task Manager just like the real explorer . . .

The only clue in this case that something was strange was the fact that in a command shell - the unicode characters were represented with question marks.
A quick look through the Cyrillic letters in the Charmap.exe utility shows that other letters just ripe for the 'spoofing' are: МНОРСТвгемнорсту

A behavior I observed here is that in Explorer when you have the directory open and the files are sorted alphabetically by name (the default) - this malicious 'explorer' always shows up last after files starting with 'z'.  This makes sense given that these characters are wwwwaaayyy down the character map from the good old Latin letters we use.

Similairly in a CMD shell when doing a DIR this file shows up last as well in the default DIR mode (which is sorting alphabetically as well) AND the unicode characters are represented with ??'s.

I'm not sure whether we'll see this method rise in popularity any time soon - a quick search on "??plorer.exe" on Google yields a number of hits from a couple of months ago so apparently this is not a new trend per se and its hard to guage whether we'll see more of this going forward given how easy it is to create files with unicode characters in their names.  I'm actually always amazed at how few cases we get involving another easy file hiding technique - alternate data streams - but I'm not complaining . . .

Moving right along, we also recently stumbled across something else interesting that we see from time to time but recently we discovered why we see this.  From time to time we've seen cases where files have a creation date of: 12/31/1979.  Why is this interesting?  It's not interesting that this is a clearly spoofed creation date - it should be a surprise to no incident response specialists that miscreants can alter the MAC times of files on the file system after they've been created with freely available tools built for this task.

The interesting thing here is that this date is 1 day before the oldest date you can do a search on in the Windows search GUI.  Try hitting 'F3' right now or going to Start-->Search -  you can't specify a date earlier than 1/1/1980 when performing searches . . . again, you'd have to do your search from a command shell to find files created on this date.

Both of these tricks / techniques exploit limitations of the Windows GUI - both of these techniques can be detected by using the built-in command shell - good 'ole CMD.EXE.

And now you know - and knowing is half the battle. :)

I'd like to give thanks to Matthew and Kenny from the PSS Security team for sharing this information . . . we hope you find it useful.  Happy hunting!