CourseWare

I've updated my courseware to provide two courses as a follow-on to my book, Basic (Level 1) and Advanced (Level 2) Windows Incident Response, respectively.

The Basic (Level 1) course covers:

• Basic Concepts of Incident Response (Locard's Exchange Principle in the digital realm, etc.)
  
• Incident Preparation (Principle of Least Privilege, host configuration, monitoring, etc.)
  
• Data Hiding (how data is hidden on live systems; NTFS ADSs, rootkits, etc.)
  
• Data Collection and Analysis (collecting and analyzing information from live systems)
  

The Advanced (Level 2) course covers:

• Review of the Level 1 course
• Log (Event Log and IIS) Analysis
• Using scanners and sniffers (advanced network mapping, sniffing, TCP stream reconstruction, etc.)
  
• Malware Analysis (how to analyze suspicious files)
  

Each course is two days in length, and highly intensive. And it's not just lecture...I don't get in front of a classroom and pontificate. My courses are very interactive, and include hands-on labs and exercises. That way, you leave the courses having used what you've learned.

I'm working with a couple of places to provide facilities for the training, and once I've finalized something, I'll be blogging about it. I've also provided training on-site, having the hosting company provide the facilities, systems, catering, etc., as well as the attendees.

If you're interested in the training, please feel free to contact me.

Interesting ADS tool

In following up some leads with information on NTFS Alternate Data Streams (ADSs), I ran across an interesting tool, called Stream Explorer. This one looks very interesting, and should definitely be included on any Windows IR CD. Use something like LADS or CrucialADS to scan a system for ADSs, then use Stream Explorer to see what's in those ADSs.

ADSs have increasingly been an issue over the years, largely due to the fact that while Windows admins don't seem to be familiar with them at all, the "bad guys" are. ADSs are used by malware, and by pen-testers to hide tools.

ADSs have been part of my presentations for a couple of years, going back even to DefCon9. SP2 for XP has added a couple of new wrinkles to the mix; I'm talking about the zoneID added to files downloaded via IE or as OutLook attachments. These zoneID ADSs tell the Explorer shell to post a warning dialog to the user when the files are accessed (double-clicked). Quite expectedly, the zoneIDs are ignored by the command prompt (cmd.exe).

Have you seen ADSs in use on systems? If so, give me some specifics...

Why do we have to make things so hard?

This blog entry should probably be subtitled, "What happened to the KISS principle??"

Not too long ago, I picked up this entry on the Viruslist.com site, and wanted to find out more about this change in adware/malware. I checked out the comments that followed the post, and got a lead...the "viral adware" is also known as Holax. Googling, I found this at the CA site, but beyond that, I haven't found a great deal of (useful) information as of yet.

First off, what's the issue? It seems that the adware (causes ads to appear in IE), CoolWebSearch (CWS) has been modified to be more difficult to detect and/or remove. Evidently, the initial infection occurs via the MHTML URL Processing Vulnerability, which seems to be specific to Outlook. Once on the system, it drops a DLL into the %SYSTEM% directory; according to CA...though I'm not sure which directory this is supposed to refer to...on my XP Home system, that variable doesn't seem to exist. CA says it's the "system32" directory.

Next, the malware (at this point, it's malware, as CWS is still being installed) searches for executables loaded automatically by the Run and RunServices keys, as well as in the StartUp folders (current user and All Users), and modifies the import tables (DLLs loaded when the program is run) to include a reference to it's DLL.

From the CA description: "The trojan attempts to modify each executable it finds. As most of these programs are constantly running, they can't be modified directly. Instead, the trojan makes a copy of each executable in the temporary directory, and modifies the copy. It then tells Windows to replace each original file with the modified copy the next time the operating system is restarted."

Okay, so...what do you do? I'd say that the first step is prevention...which means patching your system. Since the explanation from MS says that this issue is specific to Outlook, then perhaps not running Outlook would be another step to consider.

Now, how about detection? According to CA, the installed adware is capable of updating itself from a site called crdrcr.com. Also, the DLL installed in the system32 directory has a random name, starting with the letters "MS". So, searching the system32 directory for all DLLs that start with those letters (i.e., "c:\>dir [winnt|windows]\system32\ms*.dll") and is not a legit DLL would be a way of quickly determining if you've been infected.

So how do you determine if the DLL is legit? Well, MS used to have a tool available called "showbinarymfr.exe" that would've been very useful for this, but since it seems to have been removed from the MS site, you'll have to use some other means of locating it. I've written Perl scripts that use the Win32::File::Ver module (can also use Win32::Exe) to retrieve file version information from executable (.exe, .dll, .sys, etc) files. What you'd be looking for is any of the DLLs resulting from the above 'dir' command that do not contain file version information specific to Microsoft, or any other legitimate software manufacturer (i.e., Adobe, etc.).

If you know what DLL you're looking for specifically, listdlls would be helpful.

Finally, CA wasn't too clear about how the malware "tells Windows to replace each original file". However, I have seen other adware/malware that uses the wininit.ini file to perform file replacements upon system restart. So you might also check for (or the contents of) this file, as well.

Just another fun bit of malware, eh?

I guess my real issue with this isn't so much that the malware's out there, but that the anti-virus industry seems to be spread rather thin when it comes to providing information about what malware does when it infects a system. There doesn't seem to be a real standard when it comes to malware write-ups, even within the same company, and in many cases, you can't seem to put together a complete, consolidated picture of what the malware does even by going to multiple sites. Hopefully, my upcoming article on malware analysis (my courseware will be more detailed, and will include hands-on exercises) will shed some light on this...

Thanks, and I hope everyone has a very Merry Christmas, and a Happy New Year!

Mounted Devices

Ever wondered what devices have been mounted to your Windows system, particularly external storage devices? Things like USB-connected storage? Well, it's not hard to tell. Simply navigate to the following Registry key:

HKLM\System\MountedDevices

If you're using RegEdit, the Name column in the right-hand pane will list a series of entries. Right-click on one that looks like "\DosDevices\", and choose "Modify Binary Data" from the context menu that appears. An "Edit Binary Value" dialog window will open, and for external storage devices, you'll see "\??\Storage#RemoveableMedia" at the beginning of the entry.

Tools like the First Responder Unit, part of the Forensic Server Project, can be used to retrieve this data from a system. An interesting side effect is that the FRU will also get the LastWrite time of the Registry key, letting you know when the last entry was written to MountedDevices.

Windows Rootkits

I was reading a thread over on the SecurityFocus Security-Basics list about hidden files and processes this morning...it seemed to address rootkits. It was very interesting to read through the thread and see the processes followed, given the information posted in the first post, by the respondants.

With regards to the hidden process, the original poster (OP) stated that he used nmap to detect an FTP server listening on a non-standard port...given that he didn't say which port it was, all we can assume at this point is that it wasn't port 21. The OP went on to say that he connected to the port using an FTP client, and when he sat at the console, he used several tools...Active Ports, Fport, and TCPView...but couldn't "see" the listening port.

At the final entry in the thread, the OP stated that he'd found the rootkit, but didn't say which one it was. I think it's interesting to see the process or methodology people (re: Windows administrators) use when they're in a situation like that...they know that a port is open, via nmap and connecting to it, but don't see it when they're at the console. There's nothing wrong with the tools that the OP used, but I would like to make some suggestions with regards to the methodology that was used...

In my book, I did some research using AFX Rootkit 2003 (other rootkits will be analyzed in the second edition) and found that there are subtleties that can be taken advantage of when looking to see if there is a rootkit installed. For example, the HackerDefender rootkit installs as a service, and can (allegedly) be detected by such tools as RKDetect. RKDetect enumerates services via WMI and the SCM, and compares the two for anomolies. This is the same sort of approach I used in the rootkit detection script I included in my book, though my approach looks at Registry keys, files, services, processes, etc.

Another tool to use would have been tlist.exe from the Microsoft Debugger Tools, as this tool lets you see which processes are associated with which services. I haven't worked specifically with the HackerDefender rootkit, but I have found that tools like pslist.exe from SysInternals can also be used as part of an anomoly detection methodology.

My point is that relying on one technique usually isn't enough, particularly in the face of rootkits. Use multiple tools...I prefer openports.exe over fport.exe for process-to-port mapping, for example. I'd also compare the contents of the HKLM\..\Run key when retrieved remotely to those retrieved locally...the same for the various subkeys under the Services key. This is due to the fact that when the enumeration is done remotely, the APIs on the remote system aren't being hooked by the rootkit. Looking for disparities will help you see if something untoward has been installed.

One final thing...one of the respondants recommended using a tool called "HideWindow" to see which windows were open on the desktop but not visible. This was an interesting response, because on the surface, it seems off-topic. What it really is is a lack of understanding of tools and rootkits in particular. I took a look at HideWindow when I wrote the No Stone Unturned series for SecurityFocus. This tool simply makes a window invisible to the desktop, but does nothing to hide the process.

So, I guess we continue down the road...

DNSLint

Having trouble diagnosing DNS issues? Have you been trying to implement AD and been running into problems with the DNS? If so, check out DNSLint, a utility from Tim Rains of MS. This looks like an excellent addition to any system administrator's toolkit...

What about WMI?

Yeah, what about it?

Oh, wait...what is it?

WMI stands for "Windows Management Instrumentation". In a nutshell, it's a great way to access a lot of information provided by Windows (NT 4.0 SP4 and above) systems. You can access WMI through VB or VBScript, but I prefer to do so via Perl.

Some of the neat things you can do with WMI include getting hardware and software inventories of systems, while never leaving your desk. Linux systems have a hardware lister called lshw...with WMI, you can write a tool that will reach out to all the systems you can connect to and gather up the same information. Want processes, patches, installed applications (inventory of software licenses) instead? No problem!

Am I wrong on this?

I have to wonder sometimes...am I wrong to espouse my opinion with regards to incident response activities, particularly on Windows systems?

The frustration I run into is something I see both online and at work. Here's the scenario...an admin in charge of a Windows system (could be a dual-hatted Linux admin, or an MCSE) finds that something suspicious is going on. He does some cursory checks, such as a port scan, perhaps, and with exception of a few vague statements ("I didn't see anything suspicious in the Task Manager"), provides no further information. At that point, he now wants to know if the box has been "hacked" (I cringe at the use of that word).

My point about this is, why can't people simply do the few simple things to gather information before making a decision, either to blow away to box, or post online? So the question I come to, is, is it wrong for me to espouse a view that an academic approach needs to be taken to incident response? When I say "academic" approach, what I'm referring to is collecting and analyzing facts. It's simple, people...really. Cause and effect. I can't get into my car...not because it's been "hacked" (shudder), but because I'm using the wrong key. Therefore, when your Windows 2003 server suddenly becomes a warez server, one thing to do would be to start checking your logs. If you've got IIS installed, check the web and FTP logs. That's a good start.

As a side note, I just want to say that I once worked at a large telecommunications company, and while investigating just such an incident, I requested the IIS 5.0 web logs from the Windows 2000 server...and received a zipped archive containing three .evt files. Uh...guys...IIS does not log to the Event Log.

Finally, on that topic...why do so many admins seem to think that the only thing Windows systems are good for is to be rebuilt? The default behaviour seems to be, "I found something I don't recognize, so I'm going to blow the system away and rebuild it." And what good does that do, particularly if not long after you go live, the system is re-infected or re-compromised? No root cause analysis (RCA) is done, so how do you know what caused the system to start acting up? And remember folks, not all issues are fixed with a patch...I've handled a great many warez incidents in which the FTP server was set up to allow the anonymous user to write to the drive. As yet, I haven't seen a patch for that.

Another thing I see is folks talking about malware or processes being "hidden from Windows". "Hidden" how? Most malware to "hides" from the administrator by not using names such as "badsoftwarehere.exe" and "nastywarez.exe"...oddly enough, this is still highly effective. Forget rootkits...for the vast majority of exploits and "hiding", nothing that sophisticated is necessary. I've done analysis on systems where I've looked over the admin's shoulder at the Task Manager, with him pointing and saying, "See? See? Nothing!", and I can clearly see two spyware processes. Ugh. I know I've got superpowers, but that's not one of them. The processes aren't "hidden", you're simply incapable of seeing them...there's a difference.

Am I wrong to ask people to collect facts, and be specific?

Tools

Every now and again, I see posts ('specially in the public lists) about security tools. Many times, the poster says, "...if you want a tool that does X, go to this site...", without naming the tool that he (or she, just to be fair) has in mind. I still see posts that say, "Go to SysInternals.com and get the PSTools...", when not a single one of the PSTools will meet the needs expressed by the original poster.

Many times, people just don't seem to understand that like anything else, tools have limitations. Take fport.exe from FoundStone, for example...an excellent tool and one of the first of its kind, but it has to be run from an account that has admin privileges. Just something to keep in mind. My personal preference for such tools (i.e., process-to-port mapping) is openports.exe.

Depending on what I'm doing, I may prefer to use CLI (command line interface) tools over the ones with the nice GUIs (say "gooey"). This is largely due to the fact that the CLI tools send their output to STDOUT, i.e., the screen. From there, it can be easily redirected to a file, or captured and sent out over a socket to a waiting server, as is the case with the Forensic Server Project. Don't get me wrong, GUI tools have their place and can be useful, but it still comes down to the right tool for the right job. Many times I see folks posting in the lists about how they find some unusual activity coming from a system, and while they can administer the machine, they can't get to it physically to run their GUI tools. That's where the CLI versions of the tools come into play...as long as you have the necessary network connection, you can use the tools (some may require that you also use psexec.exe) to get the information you need.

Another tool I like to use is tlist.exe (from the Microsoft Debugger Tools, not the Resource Kit). This is a great tool that allows you to retrieve process information from a system. You can, of course, get the process name and PID, as you can with pslist.exe and Task Manager, but you will also be able to retrieve the command line used to launch the tool. This is especially useful in incident response, as the name of the process alone doesn't do you much good, but knowing where in the file system to find the executeable image, and what arguments were used to launch the process, are extremely helpful.

More info to come on tools...

Help for home users

Home users often seem to be the "forgotten market" when it comes to security. This could be for a variety of reasons, but regardless, in many cases, exploit attempts are traced back to networks populated by home users.

Well, Microsoft has a Security At Home site that may be very beneficial to home users, and perhaps even small business owners. This site has links to information about protecting yourself while shopping online, the first three steps to protecting yourself, information about worms and spyware, etc. It's definitely a good resource.

Also for home users, spyware and adware are a big issue. What do you do? My recommendation has always been to use several anti-spyware tools, rather than relying on a single tool. For example, some good ones I've used are Spybot Search and Destroy, LavaSoft's AdAware, and HiJackThis. Other tools I've heard good things about are SpySweeper and PestPatrol. Now, I've only evaluated the first three tools mentioned, and I've only used them in cases where we've downloaded the tool to the system, installed and updated it and run it...I haven't really taken a look at tools that allow centralized management, something small businesses would be interested in.

Data Hiding on Live Systems

To me, "data hiding" means much more than steganography, from the Greek for "covered writing". To me, it means hiding data, through any means.

The most simple means of hiding data that remains extremely effective today is simply changing the name of the file. This is effective against your usual, everyday admin, who's overtasked, undertrained, and underpaid. Here's one really good example...install a bit of malware, say, a backdoor, on a system. Put it in a temp directory and call it "svchost.exe" (10 points to anyone who can tell me why writing that file to the system32 directory won't be effective). Launch it, and then open Task Manager, and tell me which one of the listed "svchost.exe" processes is the malware, and why (random guessing doesn't count). 'Nuff said.

Many moons ago, I wrote a pretty detailed paper on NTFS Alternate Data Streams (ADSs). I'm not providing a link here, as I'll be updating and moving the paper soon. However, those updates are relatively minor, given the fact that the operating system vendor provides no means of detecting or viewing the existence of arbitrary ADSs within the filesystem. The vendor provides applications (Indexing Server) and functionality (Summary tab in File Properties dialog) that make use of ADSs, but nothing in the Explorer shell to see if there are any ADSs. In the paper I wrote, I suggested that the vendor employ an icon for an alternate data stream that's a scarlet "A".

There are other means of hiding data in a live system...via OLE "structured storage", in the Registry, etc. My hope is that providing this information in my book, via instruction, and via conference presentations, the level of security awareness will be raised and these means will be less effective.

Patching Saga

If you're running Windows XP SP2, you want to take a look at a critical update that was released...uhm...hold on...on Tues. From the "SYMPTOMS" section of the article:

"After you set up Microsoft Windows Firewall in Microsoft Windows XP Service Pack 2 (SP2), you may discover that your computer can be accessed by anyone on the Internet when you use a dial-up connection to connect to the Internet."

Hhhmmm. Install XP SP2, and the nifty new firewall (albiet ingress-filtering only!!) is only inplace for network connections other than dial-up? Ooopppsss!

Article Publication

I got word this morning that the article I wrote for the Digital Investigation journal has been published online via ScienceDirect. The article is titled, "Instant messaging investigations on a live Windows XP system".

I'm currently working on another article entitled, "Malware Analysis for Windows Administrators". This one is going to be more indepth and technical, but I'm not going to address issues of disassembly and debugging. Why is that, you ask? Well, from my experience, most folks (not just Windows admins) aren't really familiar with debugging and disassembly. I took assembly language programming for the Motorola 68000 microprocessor while I was in grad school, and if it's not something that you do and do consistently, it really doesn't stay with you. However, I do think that the steps I'm outlining for both static and dynamic analysis of malware will be extremely useful to Windows administrators, incident responders, and a wide variety of other folks who are just interested in finding out what that odd piece of software does.

Script Encoding

I was reviewing the Full-Disclosure archives over on Neohapsis this morning, and ran across a post about an online script decoder. I thought that this was pretty interesting, but aside from decoding the encoded scripts, my thoughts took another avenue (as they often tend to do)...

What happens if you have your malware, and you use something like Exe2Vbs (zipped archive here) to create a VBScript, then encoded that script with Microsoft's Script Encoder tool? Theoretical stuff aside, what would this "look like" to an Anti-Virus tool? Anyone want to try it?

XP SP2 and making USB storage read-only

Windows XP SP 2 added the functionality to make USB block storage devices read-only. In order to do so, navigate to the following key:

HKLM\System\CurrentControlSet\Control\StorageDevicePolicies

Add a DWORD value named "WriteProtect", and set the value to "0" to disable, "1" to enable.

This is not only useful in home (for parents) and corporate (for admins) environments, but would also be useful where data collected during incident response activities, or your tools, are written to a USB-connected thumb drive.

See also:

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2otech.mspx#XSLTsection127121120120

First Test Post

This is my first test post of this blog.