My Road to Digital Forensics Excellence

Investigation Workflow – Intrusion Incidents

Posted by Paul Bobby on November 4, 2008

Intrusions incidents comprise those situations in which malicious software has either been executed on a computer, or a computer has become the destination for malicious activity from an already compromise device. These investigations require a specific approach as the primary determination is whether or not the malware was able to successfully execute against the computer.


AV gets a bad-rap sometimes, it is the prime example of playing catch-up to the adversary; sure, some of the vendors publish one or two updates per week, but does that matter when your network has been hit by yet another zero-day or AV evading variant. Regardless, AV logs should be checked every time. If you’re lucky, the logs may in fact contain information about the current incident, but at the very least it is as good a record as you have for the kinds of activity that have been seen on this computer.

A couple of events in the Event Log can be searched for, 7035 and 7036 correspond to the starting and stopping of the McAfee service. These events are significant in that malware often attempts to disable AV prior to infecting or completely executing on the device.

File-system Indicators

The $MFT, $Logfile and Pagefile should be searched for malware indicators. Of course this can often only be done after some form of malware analysis has taken place. The prefetch may show the file once executed. Regarding timestamps, the Entry Modified timestamp (in Encase), that is the time the MFT record itself was modified, is often a more reliable timeframe indicator than created, written or modified due to timestomping.


Check the following registry keys for DLLs associated with the generic svchost.exe (I’ll write a detailed article later)

  • HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Svchost
  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Service
Crash Information

The drwtsn32.log and user.dmp files may contain crash and debug details from the malware. I have seen data from Adobe Acrobat reader in these logs when malware attempted to exploit a patched copy of AcroRd32.exe

System Restore Points

Much has been written about these, but remember, for every system check you perform, especially those against the current registry, they can all be repeated against the System Restore point versions of the files.


I have seen malware created Alternate Data Streams to a specific folder for the purposes of storing keystroke logging data. Yes, finally I’ve actually seen malware use an ADS. Next event? Stego actually being used for real.

There is a SYSTEM user, and profile, in %systemroot%\config.

What do you suggest?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: