Saturday, November 14, 2009

It's about time...

Sometimes you need a tool, and you just don't have one available to do the thing you need done.

Recently, I was doing some analysis, and as part of that was running regslack to see what I could find in the unallocated space of some Registry hive files. Within the hex dump of unallocated space, I could see what appeared to be Registry keys (signature "nk"), but these were in the unallocated space dumps, not as part of deleted keys that had been extracted by Jolanta's regslack tool. I could also see, right there in my editor, what appeared to be a FILETIME date/time stamp. So I had a string that comprised the date/time stamp, but no way to translate it quickly.

So I wrote a tool.

I called this tool Decode64, as I wanted to decode the 64-bit FILETIME objects...but from the starting point of a binary value, the way RegRipper does it. No, I needed to be able to start with a string. So I wrote Decode64 to take a string representing the date/time stamp (analyst pastes it into a textfield...how easy is that??) and with the push of a button, translate that to both a Unix epoch time, as well as to a human-readable time, in GMT format.

Now, if you look closely at the graphic with this post, you'll see that the string entered into the first field is not indicative of a 64-bit timestamp...nope, it's one of those 128-bit timestamps that MS uses (i.e., in the Scheduled Task .job file format, and in various Registry values beginning with Vista). Consider that an Easter egg. ;-) So, I'll be using this to not only determine if something falls within my incident timeframe, but to also enter information into a timeline via the TLN tool that I wrote, and included with the timeline tools in the Win4n6 group.

Speaking of time, when I talk to folks about analyzing images for indications of malware infections, I will usually start with asking what AV product was installed. What most folks don't realize is that many Windows systems will have the MS Malicious Software Removal Tool (MRT) installed, and that the MRT maintains a log of activity, to include anything it finds and removes during a scan. I thought, cool...I can include that information in a timeline, IF I can parse it out. Now I can. ;-)

C:\tools>mrtparse.pl -f mrt.log -s YoUrMoM
1257686548|MRT|YoUrMoM|| - Backdoor:Win32/Rbot in file://C:\WINDOWS\system32\ss
ms.exe (sigseq 0x000016677E6E8F8A)
1257686548|MRT|YoUrMoM|| - Win32/Rbot and Removed!


As you can see, mrtparse.pl is a pretty simple script. Right now what it does is parse through the mrt.log file looking for any segment of the log file that contains a return code between 6 and 13 (all I've see so far is 0 and 6). Once it finds such a segment, it parses out what was found. Pretty simple.

I only have a couple of log files for testing, so the functionality of the script is limited at this point. Also, I don't have anything definitive that describes the format that the time is maintained in (i.e., local system time or GMT). So there is definitely area for improvement, but those are both easy fixes, as well.

Some other thoughts I had were to include all return codes of "0", as well. My thought that it would be a good idea if you could see something like a malware file being added to the system, and the results of tools such as MRT and AV right in there, as well.

NOTE: Keep in mind that MRT is NOT an AV solution (...and you're going to ask me, "...but what is?", aren't you??) - it's more akin to a microscanner (similar to Stinger) in that it only protects against a very specific list of malware.

A possible next step would be to look at adding support for Windows Defender logs...

Resources
A note on Defender settings
Default Scheduled Tasks in Vista
Defender not working and IE homepage set to "about:blank"?
AV recommendations for Windows (links to log files)

4 comments:

Anonymous said...

You should try dcode: http://www.digital-detective.co.uk/freetools/decode.asp

Keydet89 said...

Why? DCode doesn't give me the Unix epoch time, and it doesn't appear to handle the 128-bit times that I need decoded.

Anonymous said...

Harlan,

You obviously took a lot of time to think of a name? Why use one which is almost identical to an existing tool performing the same type of conversion?

The timestamp structure you are describing is a SYSTEMTIME date/time structure. It is not a 128bit timestamp but a collection of 16 bit values in a 128 bit structure. I am not sure why you have shrouded this in mystery and not actually explained this? In fact, anyone with a calculator can work it out without using a tool. As we can see from your example, the first two bytes D907 is 0x07D9 or 2009 in decimal. The rest isn’t complicated.

http://msdn.microsoft.com/en-us/library/ms724950(VS.85).aspx

I also disagree with what you are saying about the SYSTEMTIME structure not appearing in the registry until Vista? I remember this structure in Windows 2000. It is also the format Microsoft uses to store standard and daylight date/time values as part of the TIME_ZONE_INFORMATION structure and can easily be found in XP.

Keydet89 said...

You obviously took a lot of time to think of a name?

Wow, you're going to bust my chops over something like a name, and not even sign your posts? Wow.

Thanks for sharing the link. Maybe the reason you feel that I've "shrouded it in mystery" may be due to the fact that I hadn't yet found that link. I don't see you taking the same sort of tact (or lack thereof) with others who've posted similarly.

Also, if you're going take to me to task about other locations where this structure can be found, why are you then "shrouding" those locations in mystery?

Some of us post this stuff...I guess part of that is putting up with anonymous folks with bad attitudes.

Thanks again for you input.