Didier Stevens recently posted a Python script that will create a .VBS script with an embedded executable. This kind of reminds me of the stories about MIT in the late '60's, when the freshmen would try to crash the server, and the admins wrote the "servercrash" script...to sort of remove the mystery and ability to claim bragging rights from the whole mess.

Didier's script presents an interesting opportunity...what would you look for if you were analyzing a system and trying to determine if something like this had been used? Any thoughts? Grab the Python script, maybe install ActivePython, and see what you come up with...

I've been offline and not posting for a while, I know...not much time to post with so much going on during my day job (but that's a Good Thing).

A couple of new things have popped up recently that I wanted to share with everyone. First, Didier Stevens has produced an update to his UserAssist program, for parsing the UserAssist Registry keys on a live system. This update parses the GUIDs, giving you even more information about the user's activities. This is something that I'll have to add to my own tools that parse the same keys, but during post-mortem analysis.

Second, Peter Burkholder over at Ellipsis has produced a patch for running my Forensic Server Project (FSP) on *nix-variant systems, to include MacOSX. I have said from the very beginning that this could be done, and Peter has gone and done it! Very cool!

Jesse Kornblum has released md5deep 2.0, which has some new features and bug fixes...check it out.

If I've missed anything, please drop me a line and let me know...

Didier Stevens has continued some of his excellent work regarding the UserAssist keys in the Registry. This morning, he posted an entry that explains part of the value names that appear when you decode (ie, un-ROT-13) the names. He has added the capability of providing an explanation to his UserAssist tool.

When you decode the value names from beneath the UserAssist\{GUID}\Count keys, you see that the value names begin with "UEME_" and include names like "RUNPIDL" and "RUNCPL", to name just a few. Since research into these Registry entries began, no one has really known or explored what these refer to...until now. Didier has done an excellent (say "excellent" the way Mr. Burns...more data on Wikipedia...does from "The Simpons", while tenting your fingers...) job of digging into what they mean, as well as providing that explanation via his tool.

If you get a chance, please be sure to thank Didier for his work, and if you see him at a conference, buy him a beer!

Addendum, 5 Sept: Rich over at ForensicZone.com has an interesting web page posted about extracting UserAssist key value names from memory dumps. This is a very interesting move on Rich's part...I've been looking at memory dumps and finding the "magic numbers" for Registry keys and values, but I have yet (due to time constraints) to go as far as writing code to pull out the key/value structures. The interesting thing about this (I think...being the complete nerd that I am) is that if we dump the contents of physical memory and then are capable of parsing out images used by each process as well as the memory used by each process, we can then (potentially) find Registry keys and values that we can associate with a specific process, but have yet to be written to disk! In addition, we know from the Registry key structure that the keys (albeit not the values) have a timestamp associated with them, increasing their evidentary value. Great catch, Rich! I hope you and Didier keep up the great work you've been doing!

Addendum, 7 Sept: Wow, when things get rolling, it's amazing! Didier and I have exchanged a couple of emails discussing various aspects of the UserAssist keys and some of the more esoteric settings that are out there, and according to some, have actually been used! Didier's a veritable fountain of energy and enthusiasm when it comes to researching this kind of thing, so keep an eye on his blog for more good things!

Not long ago, Didier Stevens blogged about Windows Safe Mode and some Registry keys/values that pertain to Safe Mode. He filed this blog entry under "hacking". One of the cool things about computer forensics is that it's the flip side of hacking...discovering artifacts or "footprints" to find what kind of things happened on a system when it was "hacked".

Didier points out in his blog post how easy it is to write your own service that launches from Safe Mode. As more and more malware authors seem to be choosing a Windows service over the ubiquitous Run key in order to maintain the persistence of their malware on a system, it simply makes sense that a check should be made of the SafeBoot (Windows 2000, XP) key, as well.

Is this really such an issue, something you should be concerned about when performing IR or conducting an investigation? Let me add some perspective...not long ago, I examined a worm that had infected several systems, and it created an entry for itself in the RunOnce key; the entry was prepended with a "*". Does anyone get the significance of that?

I received an email from Didier Stevens this morning, letting me know that he'd mentioned me in an article that he wrote for (In)Secure Magazine (issue 1.10, Feb 2007). His article, "ROT-13 is used in Windows? You're joking!" starts on pg 72 of the PDF, and runs through pg 77, where he mentions my ProScript.

Didier's article is on the use of ROT-13 to "encrypt" information that Windows uses to keep track of most frequently used programs (MFUPs). These MFUPs are tracked in order to populate the new Start menu, in both the pinned list (left side) as well as the most frequently used programs list (at the bottom)...see Didier's article for the full explanation.

The ProScript that Didier mentions is a Perl script (go figure, right??) that works with Technology Pathway's ProDiscover forensic analysis product, and parses the NTUSER.DAT files for all of the users on the system, extracting and "decrypting" the UserAssist entries and sorting them in order based on the timestamps that Didier mentions in his article. The ProScript is run against an image that is open in ProDiscover.

I also use a Perl script that parses the raw NTUSER.DAT files, and collects the same information...an excerpt of the output appears below:

G:\book2\DVD\ch4\code>pnu.pl d:\cases\ntuser.dat
LastWrite time = Mon Sep 26 23:33:06 2005 (UTC)
Mon Sep 26 23:33:06 2005 (UTC)
UEME_RUNPATH
UEME_RUNPATH:C:\WINDOWS\system32\notepad.exe
Mon Sep 26 23:26:43 2005 (UTC)
UEME_RUNPATH:Z:\WINNT\system32\sol.exe
Mon Sep 26 23:22:30 2005 (UTC)
UEME_UISCUT
UEME_RUNPATH:Downloads.lnk
Mon Sep 26 23:16:26 2005 (UTC)
UEME_RUNPATH:C:\Program Files\Morpheus\Morpheus.exe
Mon Sep 26 23:16:25 2005 (UTC)
UEME_RUNPATH:Morpheus.lnk
Mon Sep 26 23:15:04 2005 (UTC)
UEME_RUNPATH:C:\Program Files\Internet Explorer\iexplore.exe
Mon Sep 26 23:04:08 2005 (UTC)
UEME_RUNPATH:d:\bintext.exe

The UserAssist keys record user activities that are performed via the shell (ie, Windows Explorer). The UserAssist key actually has two subkeys, both of which are GUIDs or CLSIDs...one for the Active Desktop, and the other for the Internet Toolbar. If you've installed IE 7.0, you will see a third subkey.

Both the ProScript and the Perl script mentioned here will be available on the DVD that accompanies my next book, Windows Forensic Analysis, due our later this spring from Syngress/Elsevier.

Didier's got some other very interesting posts on his blog, so be sure to check it out when you get a chance.