Robert Hensing's Secure Windows Initiative Blog

New security features in VC2005

Robert_Hensing — Thu, 29 Sep 2005 18:55:00 GMT

So this is a pretty nice summary of some of the cool / new features of VC2005 that will hopefully lead to more secure code being cranked out all over the planet.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/vs05security.asp

So what is it – ya do here? Allow myself to introduce . . . myself (again).

Robert_Hensing — Thu, 14 Jul 2005 14:45:00 GMT

Okay – if you are still subscribed to this feed – then you probably remember me from back in the day when I was an incident response guy for PSS Security doing detective work helping our customers figure out how they got hacked and offering sage advice on how not to get hacked (again) going forward. I hope that I was able to paint a pretty good picture of what a day in the life of a PSS Security engineer looks like with my previous blog posts and the types of threats facing our customers.

But now for something completely different - I’d like to give you a glimpse into my new life as a member of the SWI Defense team.

SWI or Secure Windows Initiative is a large team made up of various sub-teams within the Security Engineering and Communications division here at Microsoft.

One of SWI’s core responsibilities is developing and enforcing the SDL – Security Development Lifecycle which is our fundamental approach to writing better, more secure software. But in addition to that, members of SWI do everything from helping developers create and use threat models early on in the development life cycle, to performing code reviews, to conducting penetration testing against un-released products, to creating security tools to help us do our jobs better (think fuzzing etc.).

In addition to that proactive work – certain members of SWI work reactively with the MSRC to triage and repro incoming privately reported and publicly disclosed vulnerabilities that they pick up either through the secure@ inbox or via the various lists that the MSRC monitors 24x7. After issues are triaged by SWI and bugs are opened and assigned to the developers responsible for fixing them, my team (SWI Defense) sets out to find ways to mitigate or workaround the reported vulnerability with the interest of protecting customers in the absence of or inability to deploy a security update. On the SWI Defense team we start our investigation very early in the process – sometimes even before the developers have started coding the fix!

What are we ‘investigating’?

We’re looking for ‘mitigating factors’ (i.e. things that may make the vulnerability less severe or non-applicable) and workarounds to help protect you from the reported vulnerability in case it gets exploited or exploit code is released.

How do we do it? There are a variety of things we do. First and foremost we attempt to reproduce the problem (on every supported platform) by creating our own internal repro that we can use for testing. For example, if the problem is with a malformed document or file – we use a hex editor and create a malformed document or file. If the problem requires playing back network traffic – we use internal tools for playing back the required network traffic. Sometimes we are required to abuse an API locally by calling it directly so we may create a local repro tool that can be used to demonstrate the vulnerability. Fully patched undoable Virtual PC images come in quite handy here. After we’ve got our repro sorted out – we start debugging to see what’s going on underneath the covers. Next, after we’ve identified the vulnerable function we start looking for ways we can avoid calling that vulnerable function via source code inspection. For example – suppose the vulnerable function was responsible for logging data – would turning off logging or changing log parameters or formats help avoid the vulnerable code path while allowing the system to remain on-line?

After looking at the code we also look for any configuration changes that can be made to workaround the issue such as stopping services, un-registering COM objects, ACL’ing files, using Software Restriction Policies, filtering ports and a myriad of other techniques that can be applied to given classes of vulnerabilities.

Once we have come up with a list of recommended workarounds and mitigations we provide this data to the MSRC for consideration. Things we come up with may eventually be placed in a Security Advisory or a Security Bulletin (or both) (or neither if deemed too risky).

Have we had any success? Absolutely. J Take a look at most of the security bulletins released this year and you will find a non-empty ‘workarounds’ section under ‘Vulnerability Details’ in the bulletin.

It’s important to note that some security updates contain fixes for multiple issues. These issues are assigned CVE identifiers and are noted in the bulletin. We attempt to provide workarounds and mitigations for *each* critical or important CVE listed in the bulletin (in other words workarounds are per-important/critical vulnerability – not per-bulletin).

Let’s have a look at some of the security bulletins released in 2005

Here’s an issue I worked on shortly after starting the job:

http://www.microsoft.com/technet/security/Bulletin/MS05-016.mspx

This was a privately reported vulnerability whereby an attacker could send you a file and if you attempted to open it, the Windows shell could be tricked into running MSHTA.EXE which would then process some malicious script embedded in the file to run code of an attacker’s choice in the context of you.

We discovered a fairly easy and safe workaround for this one.

You can see the workaround by drilling down to ‘Vulnerability Details à Windows Shell Vulnerability à Workarounds for Windows Shell vulnerability’ section of the bulletin.

It was as simple as temporarily un-registering MSHTA.EXE (until the update can be applied, and then re-registering it after the update is applied) using a single command line. Oh and the workaround was easy to undo - just re-register MSHTA using a similar command. J

In our testing we also discovered an interesting ‘mitigating factor’ for this vulnerability. You could only exploit the vulnerability by sending a user a document that wasn’t already a registered file type (i.e. a .DOC file would not work since .DOC is registered by default to either WordPad or Word, but a .ROB file would probably work since there is no .ROB file association by default). This information also made it into the mitigating factors part of the bulletin to help administrators understand the threat a bit better.

Another great example is http://www.microsoft.com/technet/security/Bulletin/MS05-025.mspx

There were two vulnerabilities addressed in this bulletin – one was rated critical (the PNG issue) and one was rated ‘moderate’ (the XML info disclosure issue).

When investigating the PNG issue we discovered that the root cause of the vulnerability was in a COM object shipped with IE used for processing PNG files so we tested un-registering the DLL (temporarily) and we also tested putting a Software Restriction Policy on it to prevent it from being loaded and sure enough either of these workarounds allow you to workaround the vulnerability in the absence of the security update.

More recently we also provided the MSRC with numerous workarounds for the vulnerability having to do with the JView Profiler COM object and Internet Explorer. These workarounds were listed in both the security advisory (initially) and then in the security bulletin when it was released:

http://www.microsoft.com/technet/security/Bulletin/MS05-037.mspx

There are 6 workarounds documented in the bulletin for this issue.

As a customer – would you rather be told ‘install the security update’ or ‘well you can install the security update – or you can evaluate any of the 6 workarounds we came up with and tested to see if they are appropriate for your environment while you test the security update in a non-production environment’? I think I know the answer. Recently I noticed that there are not a lot of vendors providing this level of detail in their security bulletins. Some vendors are providing workarounds and mitigations in their security alerts/advisories/bulletins while others still are not. For a more thorough look at how our security bulletins compare to some of our competitors check out the ‘Security in Operation’ series of articles from Jeff Jones – you can find part 1 here.

So do we test the workarounds we come up with? Absolutely.

We do functional testing to ensure the workaround actually works but we can only perform very limited if any application compatibility testing. We try to document known app-compat issues where possible but there are likely issues we cannot foresee.

Are workarounds as safe to deploy as the eventual security update? Probably not.

Security updates undergo considerably more testing (of all kinds) than the workarounds we come up with and as such workarounds should be carefully considered before deployment. Workarounds should never be used indefinitely in place of the security update.

That’s it for now . . .

Robert Hensing’s Incident Response Blog – Reloaded

Robert_Hensing — Wed, 23 Mar 2005 19:24:00 GMT

After nearly 7 years in Product Support Services helping our customers on issues ranging from debugging IIS failures, to identifying performance issues to helping customers with security investigations I have taken on a new challenge and accepted a job in the Security Business and Technology Unit working for the SWI team (Secure Windows Initiative).

My career at Microsoft initially had me working reactively with customers at a 1:1 level and while it was immensely satisfying and a great learning experience – near the end I had an intense desire to reach more people and to scale out so to speak. This is largely what made me turn to blogging.

As a member of the SWI team, I feel I will be getting that opportunity (although indirectly) as I will be working closely with the MSRC during the security bulletin development process. Specifically, I’ll be helping them identify possible workarounds to security vulnerabilities so that they can be tested, verified and documented in the bulletins by the time they go live so that our customers can use them (if necessary) until the security updates can be applied.

This is definitely a change in focus for me, but I’m incredibly excited about it. However, as you can see I can, unfortunately, no longer really blog about Windows incident response topics with any sort of authoritative first-hand knowledge since I will no longer be helping to develop new incident response techniques or be doing incident response as my primary job. I’ve asked the PSS Security team not to give up on blogging and my hope is that they will create a team blog that all members can use to pick up where I am leaving off – if this happens – I will post the details and a referral URL here.

Going forward I am going to repurpose my blog and use it to talk about one of the most fascinating teams in Microsoft – the Secure Windows Initiative team. This team is responsible for one of the most important policies we have ever enforced – the Security Development Lifecycle - the development process by which all new products must go through. But what’s really interesting is that this is the team within Microsoft that just about no one (externally) has heard about – yet they have some pretty unbelievably important tasks.

We have recently published a very lengthy and a surprisingly in-depth look into how we have been developing software over the last few years (although it is a process designed to be continually improved and thus this process has evolved since its conception).

Maintaining and enforcing the SDL is one of the core tasks of the SWI team, so without further adieu I give to you the SDL:

http://msdn.microsoft.com/security/sdl

New Rootkit Revealer available!

Robert_Hensing — Wed, 23 Mar 2005 14:52:00 GMT

Sysinternals yesterday released a new version of Rootkit revealer after receiving feedback that people using rootkits were starting to add Rootkit Revealer to the 'root process' to continue to avoid detection.

The new version uses a randomly named executable that runs as a service in order to avoid getting hooked by rootkits that can do simple file name matching - an approch that was discussed in one of my previous blog posts:

http://www.sysinternals.com/ntw2k/freeware/rootkitreveal.shtml

New weapon in the war - F-Secure reveals Blacklight - an anti-rootkit tool - try it today (remember to rename it )

Robert_Hensing — Thu, 10 Mar 2005 15:02:00 GMT

F-Secure has finally taken the wraps off a new anti-rootkit tool they call Blacklight (I dig the name):

http://www.f-secure.com/blacklight/try.shtml

It seems to do a file system scan and may employ a similar technique to that of Rootkit Revealer and the Ghostbuster tools created by Microsoft Research.

Rootkit Revealer vs. Hacker Defender - How the miscreants are defeating Rootkit Revealer and how to fight back

Robert_Hensing — Thu, 10 Mar 2005 14:36:00 GMT

So over the last week we've started to get cases where Rootkit Revealer (having been downloaded by the customer) is not detecting any hidden files / folders / registry entries on the customers machine; yet our own rootkit tools we supply with our IR toolkit come back with hidden files / folders etc. and have no problem detecting evidence of a rootkit. Why the discrepancy? After all Mark's tool works very similairly to some of ours which have worked fine for years . . .

We decided to investigate and collected some specimens and it turns out that Rootkit Revealer is rather easy to defeat if you're using the Hacker Defender rootkit.

Background:
The Hacker Defender rootkit supports configuration through an INI file. The INI file has numerous sections in it that govern the behavior and operation of the rootkit / backdoor (just like a normal INI file would) and one of the sections that the miscreant can configure is entitled [Root Processes]. Here's an explanation from the readme file that comes with the rootkit:

Root Processes is a list of programs which will be immune against
infection. You can see hidden files, directories and programs only with these
root programs. So, root processes are for rootkit admins. To be mentioned in
Root Processes doesn't mean you're hidden. It is possible to have root process
which is not hidden and vice versa.

Here's the default settings for this part of the .INI file:
[Root Processes]
hxdef*
rcmd.exe

Here's how Hacker Defender (hxdef) works. When the main .EXE is run - a device driver is extracted and code is subsequently injected into all running processes on the machine and the various user mode Win32 API's listed in the readme file are then patched / hooked / detoured over to the rootkits code so that filtering can be performed etc. Root processes are immune to this however; when they start, they do not get hooked in any way - so they can 'see' all that would normally be hidden by the rootkit. The miscreants of course are all too familair with the operation of hxdef (I stand by my assertion that this is by far the most popular 'in the wild' rootkit with the biggest installed user base) and many seem to have added 'rootkitrevealer.exe' to the Root Processes section of the .INI file. Since rootkitrevealer.exe is a root process; it can see all the files / folders / registry entries that hacker defender is hiding and thus it does not flag them as hidden.

This is just another great example of the arms race we are locked in with the miscreants (some call it a cat and mouse game - but that's far too innocent; I personally am at war with the miscreants and this is my arms race).

Advice: If you're going to download and run Rootkit Revealer (and I encourage you to) - make sure you rename the .EXE to something unique, be creative. If you need a random file name use the random number generate from www.random.org or something like that and make the file name long and random. You'll have much better success - until the miscreants counter this move and fire back with something more technically advanced.

Rootkits - revealed!

Robert_Hensing — Tue, 22 Feb 2005 22:34:00 GMT

Well what do you know - that day that I was talking about in my previous post? It was today:
http://www.sysinternals.com/ntw2k/freeware/rootkitreveal.shtml

Make sure you check out the MSR site in the coming days / weeks (hoping that by saying it like that it will happen today as well).

Wormbotdoorkit? Kitbotwormdoor? Trojwormrootbot? Malware by any other name . . . 2005 - the year of the rootkit?

Robert_Hensing — Tue, 22 Feb 2005 22:24:00 GMT

Edited 2/25/2005 to examine the multiple definitions of the word 'rootkit', added information on a LUA-friendly rootkit for the LUA folks to ponder (LUA - Limitted User Account), and added some thoughts on how they could mess with AV software. :)

So this is a post I meant to make ages ago but a shiny object flew by my window and I forgot to post it. I'd like to take a second to talk about the sad state of affairs when it comes to the way we in the security and incident response community talk about malware. There is so much malware in the world with so many different attributes and properties and I often find myself thinking I'm talking to someone about a 'rootkit' and they are really talking about a 'backdoor server' OR they will be talking to ME about a 'rootkit' but their definition of a rootkit isn't the same as mine and after a few minutes of initial confusion we have to fall back and re-negotiate our communications session and derive some mutually agreed upon definitions. :) At the end of this post I'm also going to make some observations about the ubiquity of malware we refer too as 'rootkits' and I will even make some predictions about the inevitable demise (of current rootkits) and rebirth - all to take place in the year 2005. :) Intrigued? Read on . . .

In this blog post I'm going to attempt to define some different categories of malware that people can / should use when speaking to me about malware - because they are the ones I use. If you have better, more industry accepted definitions - feel free to post them as a comment in my blog.

Okay - so lets get started . . . I'm not going to give definitions for worms or viruses as these are both fairly well understood and well defined.

Malware: Malware is a subset of all software that was written for malicious purposes or behaves maliciously. Some examples of this are exploit tools (programs designed to exploit vulnerabilities), backdoor servers, rootkits, spreaders/auto-rooters, worms, viruses, some spyware and some ad-ware (more on this later) etc. Some software that I do not consider to be malware would be things like network scanners / mappers, commonly used FTP servers, popular remote control software, etc. These might fall into a 'grey' category of 'Potentially Unwanted Software' but probably should not be classified as 'malware'.

Exploit / 'sploit / exploit tool: Malware designed to exploit a software vulnerability for the purpose of gaining unauthorized remote access to a machine (usually) by targeting a service listening on a port with elevated privileges. These tools can also be designed to gain local elevation of privilege as well however by exploiting a vulnerability in the OS.

Backdoors: Backdoors are software that allows remote unauthorized access to a machine. Backdoors can either bind to a new dedicated port or they can share a port with another process by hijacking the winsock stack in that process. Backdoors can wait for inbound connections or they can shovel a shell out of your network to the domain name / IP address of the attacker’s choice. The backdoor can be implemented in the kernel as part of a device driver, or in usermode as a DLL or an EXE. Backdoors can load via ASEP's (auto-start entry points) in the registry (there are easily dozens of ways for this to happen) or they can modify a binary on the disk and piggyback off the loading of that binary (i.e. the winlogon modification I blogged about earlier).

Spreaders: Spreaders are tools used to 'spread' malware and potentially unwanted software to vulnerable machines. Spreaders can be multi-threaded and usually take a range of IP addresses as input and produce a range of compromises hosts as output by leveraging the latest exploit du jur. A spreader will typically just attempt a connection to the vulnerable port on a remote host, perform the exploit and then attempt to insert and run the shellcode of the attackers choice (the most commonly used shellcode these days seems to fetch a file from a remote URL using HTTP and save it to the local disk and then run the process). These are also sometimes called 'auto-rooters'.

Bots: Bots are software that can spread to other machines (like a worm) using either weak or easily guessed admin passwords or a variety of remotely exploitable vulnerabilities (as the list of remotely exploitable vulnerabilities found in Windows grows - so too does the number of ways bots are getting on machines). Bots will typically drop either a backdoor server component or an IRC client which can facilitate remote control through outbound connection to an IRC server. Bots can either propagate autonomously or at the behest of the person controlling the 'botnet' (collective network of bots). Bots are one of the most critical threats to an enterprise due to the speed at which they can tear through a corporate network - especially if a domain admin logs in to a machine infected with a bot (now the bot can propagate with domain admin credentials to all machines in the domain). Detection and clean-up are usually non-trivial and result in significant downtime. Bot's are a pain in the ass but we've been very lucky that to date - they haven't been all that sophisticated about hiding from admins using stealth techniques / rootkit technology (keep reading).

Trojan: This is an interesting term as you don't usually hear 'trojan' by itself when referring to software / malware - you usually hear 'backdoor trojan' uttered collectively i.e. both words spoken together referring to one thing. I am officially deprecating this term with my blog post because I hate it. :) I don't like it. I think it’s ridiculous. When I hear 'backdoor trojan' used by people, they are *really* just describing software that acts as a backdoor. Great so drop the word 'trojan' from what you just said since it only confuses people like me. Trojan implies 'trojan horse' which when applied to software would probably have to mean 'software disguised as something it is not so that when a user 'opens' it, they receive something they were not expecting' (or something). If that is true - backdoor functionality is only one of *many* payloads that could be delivered via a modern day trojan horse program - and thus referring to a 'backdoor' as a 'trojan' is very imprecise if not just flat-out wrong. If anything the word 'trojan' refers to a 'delivery vehicle' which itself is almost un-interesting (at least to me) for anything other than root cause analysis (i.e. determining how you got hacked).

Rootkits: Alas - we have arrived at the most hotly debated (IMHO) definition. The term 'rootkit' has been around probably longer than Windows and they are a unique and interesting class of malware. It is my understanding that the term originated 'back in the day' for the Unix platform and when applied to that platform the term means 'a collection or 'kit' of tools used to obtain OR maintain root access' (there is some debate in the community whether rootkits are used to obtain root access or to simply prolong root access by employing stealth techniques). The definition seems to be repurposed or updated every few years so depending on when you last checked your definition may not be current. :) The two schools of thought on definition of a rootkit seem to center around obtaining 'root' privileges vs. maintaining 'root' privileges.

If you subscribe to the theory that rootkits were used for elevating privileges (obtaining root), then rootkits for Unix almost always implied EoP via exploitation of some vulnerability and part of the kit may have included a 'trojaned' copy of common system tools that provided stealth to avoid detection by the system admin after root was obtained to maintain root access as well.

Rootkits for Windows have been slowly gaining in popularity for almost a decade now but this class of software on the Windows platform has evolved to the point of being fairly different (in its implementation) from its Unix brethren - yet the same general name is used and this greatly confuses people with experience with rootkits on both platforms. So let’s break down the Unix 'obtain root' definition of a rootkit into its sub-categories. You have three distinct behaviors in the 'kit' or collection of software. First you have the elevation of privilege - this would be accomplished by an 'exploit tool' on the Windows platform. Next the kit will usually seek to establish permanent access to the machine - this may be accomplished by installing a backdoor on the Windows platform. Finally the kit may seek to hide the presence of the backdoor using stealth techniques and this was traditionally carried out by 'trojaning' a system binary like netstat or 'ps' but trojaning of system binaries on Windows almost never occurs (may believe becuase of closed source and WFP). These three distinct functionalities may have been traditionally referred to as the 'rootkit' (as stated - some people do not believe rootkits are used to elevate priv's to root, some people do) but on Windows typically the word 'rootkit' is used to discuss a specific sub-set of malware that provides stealth functionality i.e. the ability to hide stuff and nothing more (i.e. the third functionality mentioned above).

On Windows an exploit tool is usually used to gain remote access to the machine, the shellcode is then run in the context of the exploited process and is used to download a backdoor server / component to the compromised machine and then run it (typically from an HTTP site which itself may be compromised). In addition to the backdoor a piece of software known as a 'rootkit' may also be downloaded to the machine for the sole purpose of hiding the backdoor and any other tools uploaded to the server by the remote attacker. So the most basic definition of a rootkit for Windows is a piece of software designed to hide other software. An automated intrusion (using a spreader and a backdoor server downloaded to the compromised Windows host by the spreader) need not involve the use of a rootkit (a different piece of malware used to hide the backdoor).

Properties of rootkits for Windows

Soo . . . some people feel that rootkits on Unix / Linux are a collection of tools designed to elevate privileges and setup backdoors in automated fashion whereas others maintain that they are more like rootkits for Windows as noted - and that they just hide stuff and do NOT facilitate elevation of privilege (thus making the name imply that it's more about 'maintaining' root vs. elevating to root). In fact for a rootkit on Windows to work fully (providing hiding / stealth for all users of the system) - it must be installed by an administrator or from a process with administrator or SYSTEM privileges but the rootkit itself does not provide for exploitation - only hiding. In other words - you have to have already compromised the security of the box (or tricked a user into running one) before installing any of today’s rootkits as they all require privileges to do things that only administrators have (if they want to hide truly effectively from all users / tools).

For all the users out there running as a LUA (limitted user account) who feel 'safer' having read that rootkits require Admin or SYSTEM rights to work properly; have no fear - there is a rootkit (NTIllusion) that works just fine as a regular user account (but would provide stealth only for processes running in the context of that user).

The 'stuff' they hide can be anything - you can hide a file, a folder, a user account, a group, a process, a port, a registry entry, a network connection or all of the above and the hiding is traditionally done without any modification to the tools used to enumerate this information (i.e. the binary on the disk is left un-modified). Anything you can think of as a security practitioner that you might examine to find evidence of a compromise can be hidden by an advanced rootkit. Rootkits range from the very simple process hiding rootkits (early examples of the FU rootkit simply took a PID to hide and didn't hide any files or folders or registry entries etc.) to the very . . . feature complete rootkits like Hacker Defender and YYT_HAC rootkits which can hide just about everything AND come bundled with built-in backdoor servers (negating the need for a separate backdoor to be hidden).

And now we have arrived at the quandary that people face when trying to discuss malware like Hacker Defender or the YYT_HAC rootkit.

Are these rootkits? Yes - using the modern Windows-specific version of the definition - it hides / stealth’s stuff - but it was not the software actually used to compromise the host (i.e. it's not an exploit and does not elevate privileges).

Is it a backdoor? Yes - these rootkits contain a backdoor server component and also come with a special backdoor client that can be used to communicate with the backdoor server.

Could a rootkit like this be dropped by a self-propagating or propagate-on-demand bot? Yes - this malware or the technology employed by this malware could easily be picked up by the next version of Agobot/Gaobot/Phatbot/Polybot/Sdbot/Rbot/Spybot families of malware. Here's a thought - what if this rootkit got on your machine before the AV vendor updated their signatures and then hid the directory the signatures come down in? Would the AV software still work and be able to detect anything? Most likely not - not if it can't find the signatures being hidden by the rootkit - something to ponder.

What would you call a bot that installed a backdoor server that was stealthed by a rootkit? Is it a botdoorkit? A doorbotkit?

I don't have a particular desire, nor do I see a particular need to be able to quickly summarize complex malware in one easy to consume 'buzzword' which is what I feel people often try to do. Malware is getting increasingly more full-featured and increasingly more complex and I think it's time we stop trying to classify what is obviously a collection of independently developed 'malware' (i.e. programs developed by different groups of people for different purposes with different functionality) being dropped onto compromised hosts using a single word like 'backdoor' or 'trojan' and instead we should focus on the attributes and properties of the pieces of malware we have identified on the system and refer to them based on their functionality - but before we do that, we must first agree on what it is we're talking about and thus my proposed definitions above.

And finally - I predict that 2005 will be the year the Windows 'rootkit' finally goes 'mainstream' . . . in that I mean more people than ever (including the mass media) will be exposed to the term this year (we already exposed the media to this threat at RSA a couple weeks ago) and we will start to see rootkit stealthing technology and techniques picked up by ever increasing amounts of potentially un-wanted software and ad-ware /spyware in an effort to combat increasingly more effective antivirus and antispyware software.

Think I'm wrong? It's already happening - you just may not be aware of it:
894278 You receive a Stop 0x00000050 error on a blue screen
http://support.microsoft.com/?id=894278

Think about it - Spyware/Adware is the new 'spam'. It's the new billion-dollar industry being used by sophisticated crime rings to make money - do you really expect them to just go down without a fight? Especially when it's so easy to hide using rootkit technology? Especially when spam is becoming less and less profitable as people become better and better at fighting it?

I also predict that if rootkits are are the Windows equivalent of 'the world that has been pulled over your eyes' (to quote Morpheus) that 2005 will be the year the Matrix gets reloaded. :) Why do I say that? Very smart people have developed very effective tools - tools that can be used to expose rootkits and the processes, files and folders that they hide and 2005 will be the year these tools go mainstream.

Think I'm wrong? It's already happening - you just may not be aware of it:
http://research.microsoft.com/rootkit/

Check that site periodically in the coming weeks / months - we are fighting back!

And it's not just Microsoft preparing to release kick-ass anti-rootkit tools - there will be more - this year. You can count on it. I will of course update this blog when I hear about new anti-rootkit tool releases.

This unequivocal defeat of the hiding techniques employed by the most popular rootkits will force the miscreants back to the drawing boards this year (actually they never sit still and are always working on new techniques and they already exist but we just haven't forced them into using them widely yet) and they will come up with new hiding techniques (or use the ones already well known) - and the game will continue - culminating in an eventual reloading of the Matrix. :)

Signed

- The Previous One

Microsoft does 733t speak . . . it's like an SNL skit - only funnier.

Robert_Hensing — Fri, 18 Feb 2005 15:22:00 GMT

So yesterday this hilarious URL probably arrived in your inbox via your own personal friend network - and if it didn't, allow me to share it with you now (it's almost as entertaining as the Star Wars Kid):

http://www.microsoft.com/athome/security/children/kidtalk.mspx

So this was tossed about on a Microsoft security MVP mailing list and it elicited this hilarious reply from a security MVP:

... I just felt a disturbance in the force, as if millions of kiddies yelled out in embarrassment as their parents tried to talk leet to them...

M0M [133t!]: d00d, did j00 |-|4/\3 phun 4t sk00l t0d4yz? $c13nc3 is teh r0x0rs, w00t! D4D 4nd I R g0ing 0ut ToNiGHT, g0nn4 sh0z /\/\y m4d sk1llz. Th3r3's ph00d in da phridg3.

Son: I'm so embarrassed. Never talk that way again, please.

Maybe it's just me but I thought that was funny as hell and wanted to share Michael's reply with the world via my blog. :)
Shared with permission from Michael: www.atrevido.net

The MSRC @ RSA - the webspace

Robert_Hensing — Thu, 17 Feb 2005 22:27:00 GMT

Wow - this is really really cool.
So . . . select members of the MSRC are off at RSA this week doing BOOTH duty and talking to our customers and then blogging about the days events in an MSN web space - check it out!

http://spaces.msn.com/members/msrc/PersonalSpace.aspx

Kevin Kean, "Stepto", Simon Conant, Debby Fry Wilson - all the big names (well, except for Simon) are there and a blogin'!
If you have a few minutes - it's an interesting insight into the world of booth duty at a sufficiently large conferrence (I've done booth duty at TechEd a couple times and it's harder work than you'd think).

P.S. - I am actually not at RSA this week - but thanks for asking the MSRC folks if I'm around - it lets them know that they really should be paying my way to these events in the future and gives me ammo when I ask ("well, you know - our customers are asking for this . . ."). :)

Windows Server 2003 spanks Red Hat's monkey?

Robert_Hensing — Thu, 17 Feb 2005 18:46:00 GMT

Interesting information from RSA, it's nice to see someone other than me notice the pure creamy goodness of WS2003 for once (I've noticed it from the incident response side of things by noting a marked absence of WS2003 hacking cases over the last 2 years as compared to Windows 2000).

http://www.linuxinsider.com/alert/40697.html

Why am I not surprised by their findings?
Simple - I've been slowly biding my time as the WS2003 OS matures watching the bug counts in our OS and those of our competitors month by month using an independant site like Secunia - anyone who's been doing this already knows that there are dramatically more bugs discovered and fixed by our open source competitor which in my mind does not seem to indiciate any superior secure coding kung-fu being employed on their part (or that the 'many eyes' approach is indeed contributing to provably more secure code).

Here are the stats from Secunia - an organization not affiliated with Microsoft b.t.w. :)
Windows Server 2003 Enterprise Edition
http://secunia.com/product/1174/
44 advisories since June of 2003, 11% un-patched right now, 0% extremely critical, 45% highly critical, 59% exploitable 'from remote'.
Looking at the two un-patched ones, one is an HTML help vuln from 2003 - so I am betting that is a mistake and another is a minor information disclosure bug - obviously we have work to do still and we are doing it.

Red Hat Enterprise Linux ES 3.0
http://secunia.com/product/2535/
136 advisories, since NOVEMBER of 2004, 0% un-patched right now (I wonder if that includes all the latest slew of Linux kernel vulnerabilities reported in the last day or so) 1% extremely critical, 24% highly critical, 66% exploitable 'from remote'.

We are by no means perfect, and we still have a loooooooong way to go, but the journey has at least started and as the first batch of products to go through our secure development lifecycle start to withstand the test of time - it is really no surprise to me to see that our focus on building secure products first and foremost is starting to pay off in terms of better quality software with fewer and less damaging vulnerabilities.

Introducing Tim 'The tool man' Rains - PSS Security Techlead, fellow blogger, maintainer of WOLFv2

Robert_Hensing — Mon, 07 Feb 2005 17:16:00 GMT

Folks it just occured to me that I haven't formally introduced you to a colleague of mine, Tim Rains.
Tim Rains is also a tech-lead on the PSS Security team and is an avid C++ coder (un-like me who despises the language).

In fact Tim has a long and distinguished track record of writing a number of useful utilities over the years (some even more well known than my Autodump+ vbscript! <G>) many of which are used every day by PSS and some of which are used every day by PSS Security.

He has recently released a new tool to the web - Promqry (we've gotta work on his tool name creativity).
You can read more about it here:
http://www.entmag.com/news/article.asp?EditorialsID=6557

Tim also maintains his own blog located here that I highly recommend checking out:
http://blogs.msdn.com/tim_rains/

In the future I'm going to try and get the other tech-leads on the PSS Security team to publish informative posts like the ones I have done on recent interesting hacking cases we've been involved in so that I do not become a single point of failure in the sharing process. :) Maybe I can convince them to start a dedicated PSS Security blog that anyone from the team can post to . . . hmmmm.

Tim is currently in the process of taking WOLF (Windows Online Forensics - our live response toolkit that we use to collect data from customers systems) to the next level with numerous improvements that only moving to compiled code can give you (it will no longer be a batch file).

As a finaly FYI before you ask - no, WOLF is not available for public download for many reasons. One of the better reasons is that we redistribute numerous 3rd party tools (with permission of course) and per the terms of our licensing agreement we are allowed to send WOLF to customers on an as-needed basis but we are not allowed to post WOLF for public download. As we continue to improve the data collection piece of our incident response process this may change in the future but right now we are not allowed to distribute WOLF broadly or post it for public download - sorry.

WOLF sizes up the MySQL bot / worm / spreader thing . . . a live system perspective

Robert_Hensing — Fri, 28 Jan 2005 05:31:00 GMT

So it seems that there is a new MySQL bot that is spreading to Windows machines running MySQL with weak SA (or whatever MySQL's equivalent is) passwords.

You can read more about it here http://news.zdnet.com/2100-1009_22-5553570.html and here: http://isc.sans.org//diary.php?date=2005-01-27

This is all great information on how the bot gets on the system - but let's have a look at what it does once it's on the system through the eyes of WOLF. :)
I got this data from a customer who was running MySQL on an XP SP2 machine. They had configured the XP SP2 firewall with an exception to allow the MySQL service (among others) to receive packets from all networks.

I didn't really have any leads when I started looking at the .CAB file so I checked for the presence of any new or suspicious services that have been installed and I found some:

Copied from Services:

Event Monitor - [stopped]
    Disabled
    LocalSystem
    \"C:\WINDOWS\system32\spoolcll.exe\" -netsvcs


Copied from Services:

rpcservice - [running]
    Automatic
    LocalSystem
    C:\WINDOWS\system32\rpccontrol.exe
    rpccontrol service

Next I get the MAC times for 'spoolcll.exe':

Copied from: Search Results for: spoolcll
==========================
Files containing instances of 'spoolcll'

Number of Files Searched: 10
Time to Search Files: 11 seconds

dir_creation_time_C_drive.txt
====================
    Directory of c:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files\Content.IE5\4TCVEXMH
         01/26/2005 08:57a             166,912 spoolc~1.exe    spoolcll[1].exe

    Directory of c:\WINDOWS\Prefetch
         01/26/2005 01:56p               9,110 spoolc~1.pf     spoolcll.exe-06e977be.pf

    Directory of c:\WINDOWS\system32
         01/26/2005 08:57a             166,912                 spoolcll.exe

dir_last_access_time_C_drive.txt
====================
    Directory of c:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files\Content.IE5\4TCVEXMH
         01/26/2005 03:50p             166,912 spoolc~1.exe    spoolcll[1].exe

    Directory of c:\WINDOWS\Prefetch
         01/26/2005 04:43p               9,110 spoolc~1.pf     spoolcll.exe-06e977be.pf

    Directory of c:\WINDOWS\system32
         01/26/2005 04:33p             166,912                 spoolcll.exe

dir_last_write_time_C_drive.txt
====================
    Directory of c:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files\Content.IE5\4TCVEXMH
         01/26/2005 08:57a             166,912 spoolc~1.exe    spoolcll[1].exe

    Directory of c:\WINDOWS\Prefetch
         01/26/2005 01:56p               9,110 spoolc~1.pf     spoolcll.exe-06e977be.pf

    Directory of c:\WINDOWS\system32
         01/26/2005 08:57a             166,912                 spoolcll.exe

We have all kinds of useful information from this search.

We know approximately when this file was dropped and we can start looking for other files dropped around the same time (~9am yesterday)
It appears as if the file was dropped into the TIF (Temporary Internet Files) folder using the 'LocalService' user account (a built-in low privilege account).
The files were then probably copied to SYSTEM32 and then run later after a reboot and cached via the prefetch directory.

Next I get the MAC times for 'rpccontrol.exe':

Copied from: Search Results for: rpccontrol
==========================
Files containing instances of 'rpccontrol'

Number of Files Searched: 10
Time to Search Files: 4 seconds

dir_creation_time_C_drive.txt
====================
    Directory of c:\WINDOWS\Prefetch
         01/26/2005 02:11p               8,306 rpccon~1.pf     rpccontrol.exe-348acdff.pf

    Directory of c:\WINDOWS\system32
         01/26/2005 09:01a             574,976 rpccon~1.exe    rpccontrol.exe

dir_last_access_time_C_drive.txt
====================
    Directory of c:\WINDOWS\Prefetch
         01/26/2005 04:43p               8,306 rpccon~1.pf     rpccontrol.exe-348acdff.pf

    Directory of c:\WINDOWS\system32
         01/26/2005 04:49p             574,976 rpccon~1.exe    rpccontrol.exe

dir_last_write_time_C_drive.txt
====================
    Directory of c:\WINDOWS\Prefetch
         01/26/2005 02:11p               8,306 rpccon~1.pf     rpccontrol.exe-348acdff.pf

    Directory of c:\WINDOWS\system32
         09/10/2004 08:00p             574,976 rpccon~1.exe    rpccontrol.exe

Wow - same deal, dropped in the TIF and then copied to SYSTEM32 at the same time (roughly).

Now I have a date / time I'm interested in looking at so we go to Date View for the gory details.

Copied from: Date View
==========================
2005-01-26   08:57:00   | dir_creation_time_C_drive.txt   |   c:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files\Content.IE5\4TCVEXMH - 166,912 spoolc~1.exe    spoolcll[1].exe
2005-01-26   08:57:00   | dir_creation_time_C_drive.txt   |   c:\mysql-4.1.8-win\data\mysql - 45,056 app_re~1.dll    app_result.dll
2005-01-26   08:57:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 - 166,912                 spoolcll.exe
2005-01-26   08:57:00   | dir_last_write_time_C_drive.txt   |   c:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files\Content.IE5\4TCVEXMH - 166,912 spoolc~1.exe    spoolcll[1].exe
2005-01-26   08:57:00   | dir_last_write_time_C_drive.txt   |   c:\mysql-4.1.8-win\data - <DIR>                          mysql
2005-01-26   08:57:00   | dir_last_write_time_C_drive.txt   |   c:\mysql-4.1.8-win\data\mysql - <DIR>                          .
2005-01-26   08:57:00   | dir_last_write_time_C_drive.txt   |   c:\mysql-4.1.8-win\data\mysql - <DIR>                          ..
2005-01-26   08:57:00   | dir_last_write_time_C_drive.txt   |   c:\mysql-4.1.8-win\data\mysql - 45,056 app_re~1.dll    app_result.dll
2005-01-26   08:57:00   | dir_last_write_time_C_drive.txt   |   c:\mysql-4.1.8-win\data\mysql - 579                 func.myd
2005-01-26   08:57:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32 - 166,912                 spoolcll.exe
2005-01-26   08:57:32   | system_eventlog.txt   |   0 7035 Service Control Manager NT AUTHORITY\SYSTEM  SYSTEM The Event Monitor service was successfully sent a start control.
2005-01-26   08:57:32   | system_eventlog.txt   |   0 7036 Service Control Manager N/A SYSTEM The Event Monitor service entered the running state.
2005-01-26   08:57:55   | system_eventlog.txt   |   0 4226 Tcpip N/A SYSTEM
2005-01-26   08:59:00   | dir_creation_time_C_drive.txt   |   c:\Documents and Settings\USER\Local Settings\History\History.IE5\MSHist012005012620050127 - 49,152                 index.dat
2005-01-26   08:59:14   | application_eventlog.txt   |   1 101 ESENT N/A SYSTEM wuauclt (1380) The database engine stopped.
2005-01-26   08:59:14   | application_eventlog.txt   |   1 103 ESENT N/A SYSTEM wuaueng.dll (1380) SUS20ClientDataStore: The database engine stopped the instance (0).
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\System Volume Information\_restore{A8F1E086-2979-49E7-8501-90915E0AFFC6}\RP348 - 1,444                 a0088629.dll
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\System Volume Information\_restore{A8F1E086-2979-49E7-8501-90915E0AFFC6}\RP348 - 1,444                 a0088640.dll
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\System Volume Information\_restore{A8F1E086-2979-49E7-8501-90915E0AFFC6}\RP348 - 1,459                 a0089642.dll
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\System Volume Information\_restore{A8F1E086-2979-49E7-8501-90915E0AFFC6}\RP349 - 1,444                 a0089651.dll
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\System Volume Information\_restore{A8F1E086-2979-49E7-8501-90915E0AFFC6}\RP349 - 1,459                 a0089648.dll
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 - <DIR>                          recycler
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 - 1,323                 mw.dll
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 - 1,459                 rpc.dll
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 - 153                 auto.bat
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 - 242                 mc.dll
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32 - 574,976 rpccon~1.exe    rpccontrol.exe
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler - <DIR>                          .
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler - <DIR>                          ..
2005-01-26   09:01:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\Temp - 628,007                 extra.exe
2005-01-26   09:01:00   | dir_creation_time_X_drive.txt   |   x:\Temp - <DIR>                          cygwin
2005-01-26   09:01:00   | dir_creation_time_X_drive.txt   |   x:\Temp\cygwin - <DIR>                          .
2005-01-26   09:01:00   | dir_creation_time_X_drive.txt   |   x:\Temp\cygwin - <DIR>                          ..
2005-01-26   09:01:00   | dir_hidden_files_C_drive.txt   |   c:\WINDOWS\system32\recycler - <DIR>                          dmp
2005-01-26   09:01:00   | dir_hidden_files_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>                          .
2005-01-26   09:01:00   | dir_hidden_files_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>                          ..
2005-01-26   09:01:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32 - <DIR>                          recycler
2005-01-26   09:01:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler - <DIR>                          .
2005-01-26   09:01:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler - <DIR>                          ..
2005-01-26   09:01:00   | dir_last_write_time_X_drive.txt   |   x:\ - <DIR>                          temp
2005-01-26   09:01:00   | dir_last_write_time_X_drive.txt   |   x:\Temp - <DIR>                          .
2005-01-26   09:01:00   | dir_last_write_time_X_drive.txt   |   x:\Temp - <DIR>                          ..
2005-01-26   09:01:28   | system_eventlog.txt   |   0 7035 Service Control Manager NT AUTHORITY\SYSTEM  SYSTEM The rpcservice service was successfully sent a start control.
2005-01-26   09:01:28   | system_eventlog.txt   |   0 7036 Service Control Manager N/A SYSTEM The rpcservice service entered the running state.

Okay we have lots of data to digest here.
First we see the DLL that is discussed in the SANS article linked too above - this is the initial pieces of malware dropped on the box. It is actually a downloader that when loaded inside of a host process (or maybe run with rundll32.exe) will use WININET API's to download the other files to the TIF and then run them. How do I know this? I got a copy from the customer and ran strings against it - it's not packed with anything so you are able to see a lot.

So now the picture is becoming clear - a login to MySQL is performed by guessing a password, executable code is written to the database using that logon, then persisted to the file system in the form of a DLL and then loaded and executed (this part I'm not clear on how this works).

Once the DLL loads it uses WININET API's to start downloading the other malware (the EXE's etc.) to the machine via either FTP or HTTP and then running them. You can see the stuff I highlighted in red pretty clearly shows the EXE's getting downloaded to the box, copied to SYSTEM32 and then started as a service. But what's that lone event ID I highlighted in blue above?

http://www.microsoft.com/technet/support/ee/result.aspx?EvtSrc=Tcpip&EvtID=4226&ProdName=Windows+Operating+System&LCID=1033&ProdVer=5.2

Hooray for XP SP2's built-in rate limiting which kicked in, presumably when this stuff started scanning!
The rate-limiting built-in to XP SP2 has been the topic of much heated debate amongst security professionals but its real-world data like this showing that it works against even new malware that makes me favor it. Sure it can be subverted by skilled miscreants - but draw your own conclusions based on this evidence.

At this point, after a while, the user of the machine started to get suspicious that something was up (perhaps network performance was sluggish) and started rebooting and installing things like Microsoft Antispyware . . . here's the next cluster of 'interesting' data:

It's really hard to write solid code - the miscreants are not the best coders either - here's proof:

Copied from: Date View
==========================
2005-01-26   13:56:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\Prefetch - 17,284 taskmg~1.pf     taskmgr.exe-20256c55.pf
2005-01-26   13:56:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\Prefetch - 9,110 spoolc~1.pf     spoolcll.exe-06e977be.pf
2005-01-26   13:56:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\Prefetch - 9,110 spoolc~1.pf     spoolcll.exe-06e977be.pf
2005-01-26   13:56:12   | system_eventlog.txt   |   0 4202 Tcpip N/A SYSTEM  HP WLAN 802.11a/b/g W500 - Packet Scheduler Miniport
2005-01-26   13:56:17   | system_eventlog.txt   |   0 32003 ipnathlp N/A SYSTEM The Network Address Translator (NAT) was unable to request an operation of the kernel-mode translation module. This may indicate misconfiguration, insufficient resources, or an internal error. The data is the error code.
2005-01-26   13:56:26   | system_eventlog.txt   |   0 7031 Service Control Manager N/A SYSTEM The Event Monitor service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 1 milliseconds: Restart the service.
2005-01-26   13:56:28   | system_eventlog.txt   |   0 7036 Service Control Manager N/A SYSTEM The Event Monitor service entered the running state.
2005-01-26   13:56:43   | system_eventlog.txt   |   0 7031 Service Control Manager N/A SYSTEM The Event Monitor service terminated unexpectedly. It has done this 2 time(s). The following corrective action will be taken in 1 milliseconds: Restart the service.
2005-01-26   13:56:45   | system_eventlog.txt   |   0 7036 Service Control Manager N/A SYSTEM The Event Monitor service entered the running state.
2005-01-26   13:56:48   | system_eventlog.txt   |   0 7031 Service Control Manager N/A SYSTEM The Event Monitor service terminated unexpectedly. It has done this 3 time(s). The following corrective action will be taken in 1 milliseconds: Restart the service.
2005-01-26   13:56:51   | system_eventlog.txt   |   0 7036 Service Control Manager N/A SYSTEM The Event Monitor service entered the running state.

Sadly the miscreants have set the service to restart automatically so it keeps on trucking.

Now the next cluster of events let you know that this is not just a standard worm that spreads and does little else - this bot phoned home to someone and then that someone started preparing the server to host warez after it got the message:

Copied from: Date View
==========================
2005-01-26   14:11:00   | dir_creation_time_C_drive.txt   |   c:\System Volume Information\_restore{A8F1E086-2979-49E7-8501-90915E0AFFC6}\RP349 - 18,108 change~1.1      change.log.1
2005-01-26   14:11:00   | dir_creation_time_C_drive.txt   |   c:\System Volume Information\_restore{A8F1E086-2979-49E7-8501-90915E0AFFC6}\RP349 - 46,822                 change.log
2005-01-26   14:11:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\Prefetch - 10,146 attrib~1.pf     attrib.exe-39eafb02.pf
2005-01-26   14:11:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\Prefetch - 17,818 extrae~1.pf     extra.exe-03550c8c.pf
2005-01-26   14:11:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\Prefetch - 8,306 rpccon~1.pf     rpccontrol.exe-348acdff.pf
2005-01-26   14:11:00   | dir_last_write_time_C_drive.txt   |   c:\Program Files\Microsoft AntiSpyware - 1,716                 errors.log
2005-01-26   14:11:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\Prefetch - 10,146 attrib~1.pf     attrib.exe-39eafb02.pf
2005-01-26   14:11:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\Prefetch - 17,818 extrae~1.pf     extra.exe-03550c8c.pf
2005-01-26   14:11:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\Prefetch - 8,306 rpccon~1.pf     rpccontrol.exe-348acdff.pf
2005-01-26   14:11:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\Temp - 628,007                 extra.exe
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          00-_-_~1        00 -+-=o0o===========================================o0o=-+-
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          01-_-_~1        01 -+-=o0o=-+-      a n e g a t i v e f i b e s e l i t e s t r o   -+-=o0o=-+-
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          02-_-_~1        02 -+-=o0o===========================================o0o=-+-
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          03-_-_~1        03 -+-=o0o=-+-                             g a m e s                             -+-=o0o=-+-
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          04-_-_~1        04 -+-=o0o=-+-                          s o f t w a r e                          -+-=o0o=-+-
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          05_-_o~1        05 +-=o0o=-+-                              m o v i e s                            -+-=o0o=-+-
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          06-_-_~1        06 -+-=o0o=-+-                              m u s i c                              -+-=o0o=-+-
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          07-_-_~1        07 -+-=o0o=-+-                           c o n s o l e                           -+-=o0o=-+-
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          08-_-_~1        08 -+-=o0o==========================================o0o=-+-
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          09-_-_~1        09 -+-=o0o=-+-          h a c k e d b y t u t t 3 f r u t        -+-=o0o=-+-
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          10-_-_~1        10 -+-=o0o=-+-            f i l l e d b y t u t t 3 f r u t        -- -+-=o0o=-+-
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          11-_-_~1        11 -+-=o0o==========================================o0o=-+-
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\00 -+-=o0o===========================================o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\00 -+-=o0o===========================================o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\01 -+-=o0o=-+-      A N e g a t i v e F i b e s E l i t e S t r o   -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\01 -+-=o0o=-+-      A N e g a t i v e F i b e s E l i t e S t r o   -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\02 -+-=o0o===========================================o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\02 -+-=o0o===========================================o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\03 -+-=o0o=-+-                             G a m e s                             -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\03 -+-=o0o=-+-                             G a m e s                             -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\04 -+-=o0o=-+-                          S o f t w a r e                          -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\04 -+-=o0o=-+-                          S o f t w a r e                          -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\05 +-=o0o=-+-                              M o v i e s                            -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\05 +-=o0o=-+-                              M o v i e s                            -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\06 -+-=o0o=-+-                              M u s i c                              -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\06 -+-=o0o=-+-                              M u s i c                              -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\07 -+-=o0o=-+-                           C o n s o l e                           -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\07 -+-=o0o=-+-                           C o n s o l e                           -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\08 -+-=o0o==========================================o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\08 -+-=o0o==========================================o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\09 -+-=o0o=-+-          H a c k e d b y T u T T 3 F R u T        -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\09 -+-=o0o=-+-          H a c k e d b y T u T T 3 F R u T        -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\10 -+-=o0o=-+-            F i l l e d b y T u T T 3 F R u T        -- -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\10 -+-=o0o=-+-            F i l l e d b y T u T T 3 F R u T        -- -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\11 -+-=o0o==========================================o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_creation_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\11 -+-=o0o==========================================o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          00-_-_~1        00 -+-=o0o===========================================o0o=-+-
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          01-_-_~1        01 -+-=o0o=-+-      a n e g a t i v e f i b e s e l i t e s t r o   -+-=o0o=-+-
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          02-_-_~1        02 -+-=o0o===========================================o0o=-+-
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          03-_-_~1        03 -+-=o0o=-+-                             g a m e s                             -+-=o0o=-+-
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          04-_-_~1        04 -+-=o0o=-+-                          s o f t w a r e                          -+-=o0o=-+-
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          06-_-_~1        06 -+-=o0o=-+-                              m u s i c                              -+-=o0o=-+-
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          07-_-_~1        07 -+-=o0o=-+-                           c o n s o l e                           -+-=o0o=-+-
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          08-_-_~1        08 -+-=o0o==========================================o0o=-+-
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          09-_-_~1        09 -+-=o0o=-+-          h a c k e d b y t u t t 3 f r u t        -+-=o0o=-+-
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          10-_-_~1        10 -+-=o0o=-+-            f i l l e d b y t u t t 3 f r u t        -- -+-=o0o=-+-
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          11-_-_~1        11 -+-=o0o==========================================o0o=-+-
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\00 -+-=o0o===========================================o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\00 -+-=o0o===========================================o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\01 -+-=o0o=-+-      A N e g a t i v e F i b e s E l i t e S t r o   -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\01 -+-=o0o=-+-      A N e g a t i v e F i b e s E l i t e S t r o   -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\02 -+-=o0o===========================================o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\02 -+-=o0o===========================================o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\03 -+-=o0o=-+-                             G a m e s                             -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\03 -+-=o0o=-+-                             G a m e s                             -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\04 -+-=o0o=-+-                          S o f t w a r e                          -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\04 -+-=o0o=-+-                          S o f t w a r e                          -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\06 -+-=o0o=-+-                              M u s i c                              -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\06 -+-=o0o=-+-                              M u s i c                              -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\07 -+-=o0o=-+-                           C o n s o l e                           -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\07 -+-=o0o=-+-                           C o n s o l e                           -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\08 -+-=o0o==========================================o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\08 -+-=o0o==========================================o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\09 -+-=o0o=-+-          H a c k e d b y T u T T 3 F R u T        -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\09 -+-=o0o=-+-          H a c k e d b y T u T T 3 F R u T        -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\10 -+-=o0o=-+-            F i l l e d b y T u T T 3 F R u T        -- -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\10 -+-=o0o=-+-            F i l l e d b y T u T T 3 F R u T        -- -+-=o0o=-+- - <DIR>                          ..
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\11 -+-=o0o==========================================o0o=-+- - <DIR>                          .
2005-01-26   14:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\11 -+-=o0o==========================================o0o=-+- - <DIR>                          ..

Welp - now we have some leads for law enforcement some day in the form of handles / nick's these guys go by. Tooty fruit? Umm . . . okay.
What's interesting is that while this was going on the user decided to reboot one more time - thereby interrupting the preparation of the new warez site which was in full swing . . .

Not to fear - looks like it resumed shortly after the reboot . . . :(

Copied from: Date View
==========================
2005-01-26   14:22:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp - <DIR>          05_-_o~1        05 +-=o0o=-+-                              m o v i e s                            -+-=o0o=-+-
2005-01-26   14:22:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\05 +-=o0o=-+-                              M o v i e s                            -+-=o0o=-+- - <DIR>                          .
2005-01-26   14:22:00   | dir_last_write_time_C_drive.txt   |   c:\WINDOWS\system32\recycler\dmp\05 +-=o0o=-+-                              M o v i e s                            -+-=o0o=-+- - <DIR>                          ..

Okay enough of that - let's do some more investigating - here's a registry search for app_result.dll

Copied from: Search Results for: app_result.dll
==========================
Files containing instances of 'app_result.dll'

Number of Files Searched: 2
Time to Search Files: 3 seconds

registry.txt
====================
   [HKEY_USERS\S-1-5-21-1085031214-1292428093-xxxxxxxx-yyyyyy\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSaveMRU\*]
         "i"=(REG_SZ)"C:\\mysql-4.1.8-win\\data\\mysql\\app_result.dll"

   [HKEY_USERS\S-1-5-21-1085031214-1292428093-xxxxxxxx-yyyyyy\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSaveMRU\dll]
         "b"=(REG_SZ)"C:\\mysql-4.1.8-win\\data\\mysql\\app_result.dll"

Doesn't give us much . . .

Let's check out the XP SP2 firewall policy

Copied from: Date View
==========================
2005-01-26   09:14:20   | security_eventlog.txt   |   6 848 Security NT AUTHORITY\SYSTEM  SYSTEM No Domain All interfaces On Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Enabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain iTunes C:\Program Files\iTunes\iTunes.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain java C:\Documents and Settings\USER\.netbeans\3.6\modules\profiler-ea-vm\jre\bin\java.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain java C:\java\j2sdk1.4.2_05\bin\java.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain Java(TM) 2 Platform Standard Edition binary C:\java\jdk1.5.0\bin\java.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain Java(TM) 2 Platform Standard Edition binary C:\java\jdk1.5.0\jre\bin\javaw.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain javaw C:\java\j2sdk1.4.2_05\bin\javaw.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain javaw C:\java\j2sdk1.4.2_05\jre\bin\javaw.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain mIRC C:\Program Files\mIRC\mirc.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain MSN Messenger 7.0 C:\Program Files\MSN Messenger\msnmsgr.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain mysqld-nt C:\mysql\bin\mysqld-nt.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain mysqld-nt C:\mysql-4.1.5-gamma-win\bin\mysqld-nt.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain mysqld-nt C:\mysql-4.1.8-win\bin\mysqld-nt.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain Remote Assistance %windir%\system32\sessmgr.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain runide C:\Program Files\NetBeans3.6\bin\runide.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain vvsys Application C:\Program Files\Polycom\ViaVideoNG\vvsys.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain Windows Messenger C:\Program Files\Messenger\msmsgs.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 849 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain Windows NetMeeting C:\Program Files\NetMeeting\conf.exe Enabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 850 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain All interfaces NetBIOS Datagram Service 138 UDP Disabled Local subnet only
2005-01-26   09:14:20   | security_eventlog.txt   |   6 850 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain All interfaces NetBIOS Name Service 137 UDP Disabled Local subnet only
2005-01-26   09:14:20   | security_eventlog.txt   |   6 850 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain All interfaces NetBIOS Session Service 139 TCP Disabled Local subnet only
2005-01-26   09:14:20   | security_eventlog.txt   |   6 850 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain All interfaces Remote Desktop 3389 TCP Disabled All subnets
2005-01-26   09:14:20   | security_eventlog.txt   |   6 850 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain All interfaces SMB over TCP 445 TCP Disabled Local subnet only
2005-01-26   09:14:20   | security_eventlog.txt   |   6 850 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain All interfaces SSDP Component of UPnP Framework 1900 UDP Disabled Local subnet only
2005-01-26   09:14:20   | security_eventlog.txt   |   6 850 Security NT AUTHORITY\SYSTEM  SYSTEM Local Policy Domain All interfaces UPnP Framework over TCP 2869 TCP Disabled Local subnet only

http://www.microsoft.com/technet/prodtechnol/winxppro/support/wftshoot.mspx
Windows Firewall uses the following event IDs:

• 848 - Displays the startup configuration of Windows Firewall.

• 849 - Displays an application exception configuration.

• 850 - Displays a port exception configuration.

• 851 - Displays a change made to the application exceptions list.

• 852 - Displays a change made to the port exceptions list.

• 853 - Displays a change made to the Windows Firewall operation mode.

• 854 - Displays a change made to Windows Firewall logging settings.

• 855 - Displays a change made to ICMP settings.

• 856 - Displays a change made to the Prohibit unicast response to multicast or broadcast requests setting.

• 857 - Displays a change made to the Remote Administration setting.

• 860 - Displays a change made to a different profile.

• 861 - Displays an application attempting to listen for incoming traffic.

Finally here are the MD5/SHA-1 values of the initial DLL dropped on the box via MySQL:

D:\malware\MySQL>fciv -both app_result.dll
//
// File Checksum Integrity Verifier version 2.05.
//
MD5 SHA-1
-------------------------------------------------------------------------
fa9e72f3f7073f285e18299260331a2f bbc6e88b4af5ee6fa101ada8eb2e31f33105450a app_result.dll

Here is some string data from the DLL obtained using strings:

ShellExecuteA
SHELL32.dll
InternetCloseHandle
FtpGetFileA
InternetConnectA
InternetOpenA
WININET.dll
GetCommandLineA
GetVersion
ExitProcess
TerminateProcess
GetCurrentProcess
GetCurrentThreadId
TlsSetValue
TlsAlloc
TlsFree
SetLastError
TlsGetValue
GetLastError
SetHandleCount
GetStdHandle
GetFileType
GetStartupInfoA
DeleteCriticalSection
GetModuleFileNameA
FreeEnvironmentStringsA
FreeEnvironmentStringsW
WideCharToMultiByte
GetEnvironmentStrings
GetEnvironmentStringsW
GetModuleHandleA
GetEnvironmentVariableA
GetVersionExA
HeapDestroy
HeapCreate
VirtualFree
HeapFree
WriteFile
MultiByteToWideChar
GetStringTypeA
GetStringTypeW
InitializeCriticalSection
EnterCriticalSection
LeaveCriticalSection
HeapAlloc
GetCPInfo
GetACP
GetOEMCP
VirtualAlloc
HeapReAlloc
GetProcAddress
LoadLibraryA
RtlUnwind
LCMapStringA
LCMapStringW
InterlockedDecrement
InterlockedIncrement
KERNEL32.dll
app_result.dll
app_result
open
PST
PDT

That's all for now - looks like the AV's are probably on top of this . . .

The Blame Game - I won't go there.

Robert_Hensing — Thu, 27 Jan 2005 21:33:00 GMT

So I'm getting some 'interesting' and frankly un-expected comments on my most recent 'Anatomy of . . . ' posts where I delve into examples of a hack involving certain vulnerabilities (one of which wasn't even in one of our products I'd like to point out).

Look folks - my intent with these blogs is not to place blame and I'm not in the habbit of blaming the victims for getting attacked as the finger can be pointed at either us or them (or the miscreants who commit the crimes but why does no one ever think to blame them when all is said and done?! Think about it . . . ).

If I had to - I'd gladly take the blame on behalf of Microsoft over customers any day and will gladly fall on my sword.

My intent with this blog is to simply share knowledge about how these attacks are occuring, why they are occurring, what IR teams at other organizations can look for and what security practitioners should be doing to secure systems in a way that most people can understand interspersed with some humorous wit and colorful commentary strewn throughout.

My team always tries to get to root cause on each and every case because by demystifying how these intrusions occur for our customers they will start to see how easy it really is to take basic precautions to avoid getting hacked. Patterns will emerge. Sure we have hundreds of pages of guidance on this that or the other but it's really quite easy to avoid getting hacked when you come right down to it at the end of the day:
Patches, passwords and ports.
If you can manage all 3 of those in your environment - you'll do just fine and need not worry (excessively <G>).

I want to make clear here that I do not enjoy, nor am I proud of the fact that our customers are getting hacked in droves.
I don't take pleasure in pointing out how easy it would have been for them, in retrospect to avoid getting hacked (with these last two blogs either a firewall or a software update would have prevented it).
That said I certainly do enjoy the hell out of my job - I like hunting the hunters and being a good guy and I think my team is quite good at it and I'm proud to be a part of it offering the service we do for our customers.

With every hacking case we get - we close the case with a series of recommendations on how to not get hacked going forward and I will continue to share those assesments with you in each post - but please don't take offense at the casual way in which I mention the recommendations (which are all documented best practices anyways). I realize some organizations struggle with passwords. I realize some organizations struggle with patches. If these are sensitive topics for you - don't take it out on me. I'm just the messenger (perhaps more like the ghost of Christmas future showing you via my blog what's in store for you if you don't resolve your struggles and soon <G>).

And finally - I'd like to point out that Windows 2000 was not an operating system designed with security in mind and it is the reason a disproportionate number of hacking cases are for Windows 2000 when used by people who are not security focused. Think about some of the features of Windows 2000 out of the box.

It allows for blank admin passwords and they can and will be used against you.
It does not require strong passwords during setup should you decide to put one on the admin account ('password' or 'dog' are okay to use during setup)
no firewall
everything's on by default

You may have seen mention in my post a hint about WS2003 and how you'll likely see me post very little about hax0r3d WS2003 boxes.
There is a non-marketting reason for that (I am NOT a marketting guy and I'm not working a bit harder so Initech can ship a few more widgets).
WS2003 is a 'secure by default' operating system (our first, followed by XP SP2) that received code review and myriad defense in depth improvements.

Think about some of the features of WS2003 out of the box (some of these you may not have known about - but have been quietly helping to protect customers for years now):

It allows you to set a blank admin password during setup BUT . . . if you do, you get yelled at and then you can't authenticate to the server using that account on the network (i.e. can't access the admin shares using 'administrator' with no password. It's a security policy and it's enforced by default - so actually a blank admin password is better than having a password like 'password' for example.
Speaking of lame passwords like 'password' - should you decide to create a password for the administrator account during setup - you will be forced to choose a better one (i.e. one that meets password complexity requirements). You won't be able to use 'password' for example.
Built-in firewall - not on by default - but change is coming.
Everything's off by default - you won't find IIS or a myriad of other services listening by default that increase your exposure needlessly
Stack smashing protection - the majority of the OS has been compiled with the /GS compiler flag to place stack cookies around important functions

In the coming months we'll be releasing WS2003 SP1 with even more creamy goodness to help protect our customers (more on that I'm sure will come later).

In the mean time - you need to realize - we are fighting back for our customers without placing blame (oh and occasionally we help law enforcement arrest the bad guys - so maybe just a little well-deserved blame aimed at those who break the law <G>).

Anatomy of a WINS server hack (MS04-045) . . .

Robert_Hensing — Thu, 27 Jan 2005 19:43:00 GMT

Okay - so here is my analysis of a recent WINS hack a customer experienced. The customer caught this by analyzing their netflow data from their routers . . . they suddenly started sending tremendous amounts of packet love and affection to various IP's around the Internet and they traced the packets to a Windows box on their network and thus the IR process was kicked into full swing.

They immediately pulled the plug, ran WOLF and started analyzing the data. As you will see these miscreants leave behind some tells that indicate that they are slightly more skilled than the miscreants from the previous blog post who went up against Windows File Protection . . . and lost.

As with most IR cases we don't have direct, objective first-hand knowledge of how the compromise occurred - all we can do is piece together the puzzle based on the evidence at hand and make a subjective assumption about what we think probably happened. Sometimes it's a no brainer and you see something like XP_CMDSHELL being run in the event logs and the customer tells us they have a blank SA password and no firewall - other times we have to do some educating guessing. :) We rely heavily on Occam's Razor and find it to hold true most of the time.

Okay - with this case I was lucky in that this customer was more sophisticated than most and the customer was able to give me some 'leads' in the form of a process name and a date and time that the gratuitous love and packet affection occured on their network. When you don't see anything suspicious in the volatile data on a machine (i.e. running processes / suspicious network connections) its very important to have a lead in the form of a date or time to go on usually - otherwise you're just looking for a needle in a hay stack.

Using WOLF Hound (our trusty IR data viewer) I told it to show me everything that happened on the file system and in the event logs on the 9th.

First we see some unusual events logged from the WINS service on this machine (a Windows 2000 SP4 machine b.t.w. - you will see me blog very little about WS2003 servers . . . I wonder why that is?).

After the suspicious WINS event log entries we that FTP.EXE gets run (last access time) and it looks like it was run (probably) to pull down a file called przsvc.exe.

Copied from: Date View
==========================
2005-01-09   16:10:40   | system_eventlog.txt   |   0 4192 Wins N/A SERVERNAME An error occurred from which WINS will try to recover. If the recovery fails,   check previous event log entries to determine what prevented a successful   recovery. Take the appropriate action to solve the error that prevented   recovery.
2005-01-09   16:10:40   | system_eventlog.txt   |   0 4242 Wins N/A SERVERNAME WINS Push thread encountered an exception. A recovery will be attempted.
2005-01-09   16:10:40   | system_eventlog.txt   |   0 4297 Wins N/A SERVERNAME WINS encountered a low memory condition. Check to see if the system is running   out of virtual memory.
2005-01-09   16:12:00   | dir_creation_time_C_drive.txt   |   c:\WINNT\system32 - 19,788                 przsvc.exe
2005-01-09   16:12:00   | dir_last_access_time_C_drive.txt   |   c:\WINNT\system32 - 39,696                 ftp.exe
2005-01-09   16:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINNT\system32 - <DIR>                          spool
2005-01-09   16:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINNT\system32\spool - <DIR>                          .
2005-01-09   16:12:00   | dir_last_write_time_C_drive.txt   |   c:\WINNT\system32\spool - <DIR>                          ..
2005-01-09   16:52:00   | dir_creation_time_C_drive.txt   |   c:\WINNT\system32 - 22,016                 spoolsrv.exe
2005-01-09   16:52:00   | dir_last_write_time_C_drive.txt   |   c:\ - <DIR>                          data
2005-01-09   16:52:00   | dir_last_write_time_C_drive.txt   |   c:\Data - <DIR>                          .
2005-01-09   16:52:00   | dir_last_write_time_C_drive.txt   |   c:\Data - <DIR>                          ..

Using FTP to suck stuff down to the box . . . well that's hardly interesting, that's been demo'd in hacking books and hacking classes for years . . . 'that's soooo last century'. What's interesting about this crew is that they also seem to have the ability to download files via HTTP (probably by calling WININET API's) just in case you're doing some egress filtering and don't allow outbound FTP. We've seen this done via scripting combined with ADODB.Stream to persist the fetched data before and it's not really hard to write a compiled program to do the same thing and run it as SYSTEM if you know what API's to call. Could this be new functionality of this particular BOT variant (spoolsrv.exe is an SDBot variant b.t.w.).

You may notice below that the 'Default User' profile's TIF (Temporary Internet Files) folder is being written around 16:52 . . . it turns out you can repro this yourself - fire up a copy of Internet Explorer running as the SYSTEM account (left as an exercise to the reader) and download some files - observe where they go. That's right, they go into the 'Default User' profile. So now it seems we have evidence that someone was running something on the box (SDBot) with elevated privileges and downloading files via IE (less likely) or by calling the same API's IE calls (more likely).

This is a little more sophisticated than usual - but it's not a new technique - we've seen this used on occasion in the past but usually from vbscripts wrapped inside of .CHM files that were downloaded and run via Internet Explorer 0-days.

2005-01-09   16:52:00   | dir_last_write_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5 - 32,768                 index.dat
2005-01-09   16:52:00   | dir_last_write_time_C_drive.txt   |   c:\WINNT\system32 - 22,016                 spoolsrv.exe
2005-01-09   16:55:00   | dir_creation_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\41YZG527 - 2,539,520 winzip~1.exe    winzip81sr1eval[1].exe
2005-01-09   16:55:00   | dir_creation_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\G5AZ8XYZ - 464,957 nfs-cd~1.zip    nfs-cd[1].zip
2005-01-09   16:55:00   | dir_creation_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\STMBS1EB - 2,848,655 aim_1_~1.exe    aim[1].exe
2005-01-09   16:55:00   | dir_last_write_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\G5AZ8XYZ - 464,957 nfs-cd~1.zip    nfs-cd[1].zip
2005-01-09   16:55:00   | dir_last_write_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\STMBS1EB - 2,848,655 aim_1_~1.exe    aim[1].exe
2005-01-09   16:56:00   | dir_creation_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\QDF591YV - 2,628,632 lusetu~1.exe    lusetup[1].exe
2005-01-09   16:56:00   | dir_last_write_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\41YZG527 - 2,539,520 winzip~1.exe    winzip81sr1eval[1].exe
2005-01-09   16:56:00   | dir_last_write_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\QDF591YV - 2,628,632 lusetu~1.exe    lusetup[1].exe
2005-01-09   17:08:00   | dir_creation_time_C_drive.txt   |   c:\WINNT\system32 - 51,733                 plugin1.dat
2005-01-09   17:08:00   | dir_creation_time_C_drive.txt   |   c:\WINNT\Temp - 84                 del.bat
2005-01-09   17:08:00   | dir_last_access_time_C_drive.txt   |   c:\WINNT\Temp - 84                 del.bat
2005-01-09   17:08:00   | dir_last_write_time_C_drive.txt   |   c:\WINNT\Temp - 84                 del.bat
2005-01-09   17:09:00   | dir_last_write_time_C_drive.txt   |   c:\WINNT\system32 - 51,733                 plugin1.dat

We collect some files that are more than likely 'suspicious' when we run WOLF.
Del.bat seems like it might be one of those files and we just happened to snag a copy - let's have a look:

Copied from: Files Collected
==========================
Contents of: del.bat
================

@echo off
:repeat
del "%1"
if exist "%1" goto repeat
del "C:\WINNT\TEMP\del.bat"

Copied from: Date View
==========================
2005-01-09   17:08:00   | dir_creation_time_C_drive.txt   |   c:\WINNT\system32 - 51,733                 plugin1.dat
2005-01-09   17:08:00   | dir_creation_time_C_drive.txt   |   c:\WINNT\Temp - 84                 del.bat
2005-01-09   17:08:00   | dir_last_access_time_C_drive.txt   |   c:\WINNT\Temp - 84                 del.bat
2005-01-09   17:08:00   | dir_last_write_time_C_drive.txt   |   c:\WINNT\Temp - 84                 del.bat
2005-01-09   17:09:00   | dir_last_write_time_C_drive.txt   |   c:\WINNT\system32 - 51,733                 plugin1.dat

So what I found interesting about this batch file is that it's like a crude dead mans switch. Delete whatever I pass in on the command line and then delete myself when done - nice. So say I start a server process and its running and then I call this batch file with the path to the server process as the first parameter. If the file is in use, the delete operation will fail and this batch file will simpy loop until the process is ended (assuming a process or a DLL is what is being passed in to the batch file as %1) and the file can finally be deleted. Finally - when the filename I pass in to the batch file as %1 does finally manage to get deleted - the batch file will delete itself . . . since it was still there - it doesn't look like it was ever called.

After this series of events - all was quiet on this server until a few days later when all we see is the previously downloaded malware that was placed in the IE TIF folder get accessed (although this looks to have been due to an incremental backup of the file system by some backup network backup software according to the event log):

Copied from: Date View
==========================
2005-01-14   00:00:00   | dir_last_access_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\41YZG527 - 2,539,520 winzip~1.exe    winzip81sr1eval[1].exe
2005-01-14   00:00:00   | dir_last_access_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\G5AZ8XYZ - 464,957 nfs-cd~1.zip    nfs-cd[1].zip
2005-01-14   00:00:00   | dir_last_access_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\QDF591YV - 2,628,632 lusetu~1.exe    lusetup[1].exe
2005-01-14   00:00:31   | security_eventlog.txt   |   8 2 538 Security SERVERNAME\IUSR_SERVERNAME  SERVERNAME IUSR_SERVERNAME SERVERNAME (0x0,0xA1207C) 3
2005-01-14   00:01:00   | dir_last_access_time_C_drive.txt   |   c:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\STMBS1EB - 2,848,655 aim_1_~1.exe    aim[1].exe

Then all was quiet again for few more days and then on the 20th it looks like someone updated the main piece of malware the morning that the IR process kicked into gear:

Copied from: Date View
==========================
2005-01-20 08:15:00 | dir_last_write_time_C_drive.txt | c:\WINNT\system32 - 19,788 przsvc.exe

What's interesting is the way in which this malware (have not received a specimen yet) was loading - it was using a lesser known autostart technique that has been used in the past by things like Beast and Sub7.

Copied from: Search Results for: przsvc.exe
==========================
Files containing instances of 'przsvc.exe'

Number of Files Searched: 1
Time to Search Files: 0 seconds

registry.txt
====================
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{9F81D88C-C298-9935-C5D1-40AA4DB91155}]
"stubpath"=(REG_EXPAND_SZ)"C:\\WINNT\\system32\\przsvc.exe s"

So to conclude, I have a theory based on suspicious WINS related event log entries that this box was comrpomised using a WINS remote shell exploit. Fortunately we have a tool that allows me to get the patch-level of a machine during the data collection phase - MBSA. MBSA was able to show me what I needed to see:

Copied from: mbsacli_patch_status.txt
==========================
Patch NOT Found MS04-041 885836
A required registry key does not exist. It is necessary in order
for this patch to be considered installed.
[SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Hotfix\KB885836\Installed]

Patch NOT Found MS04-043 873339
File version is less than expected.
[C:\WINNT\system32\hypertrm.dll, 5.0.2195.6684 < 5.0.2195.7000]

Patch NOT Found MS04-044 885835
File version is less than expected.
[C:\WINNT\system32\lsasrv.dll, 5.0.2195.6902 < 5.0.2195.6987]

Patch NOT Found MS04-045 870763
File version is less than expected.
[C:\WINNT\system32\wins.exe, 5.0.2195.6870 < 5.0.2195.7005]

Ouch baby - very ouch.

Copied from: mbsacli_patch_status.txt
==========================
* SQL SERVER 2000 GOLD

Warning
The latest service pack for this product is not installed.
Currently SQL Server 2000 Gold is installed. The latest service
pack is SQL Server 2000 SP3.

Patch NOT Found MS00-092 280380
File version is less than expected.
[d:\program files\microsoft sql server\MSSQL\binn\odsole70.dll,
2000.80.194.0 < 2000.80.223.0]

Patch NOT Found MS01-032 299717
File version is less than expected.
[d:\program files\microsoft sql server\MSSQL\binn\sqlservr.exe,
2000.80.194.0 < 2000.80.296.0]

Patch NOT Found MS01-041 298012
File version is less than expected.
[d:\program files\microsoft sql server\MSSQL\binn\ssmsrp70.dll,
2000.80.194.0 < 2000.80.213.0]

Note MS02-035 263968
Please refer to 306460 for a detailed explanation.

This box is at severe risk as it is missing multiple security updates that are remotely exploitable including SQL updates! Worse still - the box only has a 6 character minimum password policy and the passwords never expire!

Given that this box was not behind a firewall it's only a matter of time before the admin password is guessed and/or another remotely exploitable vulnerability is used to take control of this machine.

Copied from: net_accounts.txt
==========================
Thu Jan 20 16:11:24 2005
Force user logoff how long after time expires?:       Never
Minimum password age (days):                          0
Maximum password age (days):                          Unlimited
Minimum password length:                              6
Length of password history maintained:                2
Lockout threshold:                                    5
Lockout duration (minutes):                           5
Lockout observation window (minutes):                 5
Computer role:                                        SERVER
The command completed successfully.

Our advice to this customer is to follow standard best practices for internet facing boxes as documented in all of our Windows 2000 hardening guides which can be found at http://www.microsoft.com/security/guidance

At the very least they need to immediately consider:

Increasing the strength of their password policy (I recommend 10 character or more minimums and educate people about the use of pass-phrases)
Set a password expiration of no more than 70 days
Shut down un-needed servcies (this box was running everything and then some)
Install all critical security updates for both the OS and the server applications within 24 hours (even more critical since this box is plugged directly into the Internet with an Internet routable IP) or better yet turn on Automatic Updates or consider using SUS etc.
For the love of God use a firewall to screen inbound access to some of those high profile ports!

On the plus side this customer DID have account logon auditing enabled on this server and I can confirm that no Windows accounts were harmed in taking over of this server (this time).