Archive for the ‘Digital Forensics’ Category

Launching New Forensics Blog Site with RSA

Saturday, August 8th, 2009

I am thrilled to announce that I launched a new blog last week on the RSA365 Conference site (  This new blog will focus specifically on Digital Forensics.

Together with four other friends and colleagues in the field, we will be discussing weekly topics related to digital forensics.  I hope this blog will provide a different perspective on this area of information security from what is already available online.

The following is the description of the blog:

Take a Byte Out of CyberCrime

A star panel of digital forensic and incident response experts discuss a proactive approach to forensics, covering preventative measures to implement before an incident occurs.

The other members of our virtual panel are:

  • Jim DeLorimier – CIRT/Forensic Team Leader, NJ Manufacturer’s Insurance
  • Eric Gentry – Principal Consultant, Verizon Business
  • Lt. John McLean – Detective, NEMLEC Computer Crime Unit, Medford Police
  • David Thomas – Attorney, Greenberg Traurig, LLP

I hope you will find these discussions helpful when preparing for future investigations.

Discount on SANS Forensics Course

Sunday, April 26th, 2009

You can receive a 10% discount on the @Home version of the SANS Security 508: Computer Forensics, Investigation, and Response course in June with the discount code: 508EW. You can find details about this course and the @Home format on the SANS site.

I took a course in this format last fall and really enjoyed the flexibility. It is a great compromise between the typical 6 day conference format, with all the travel and impact on your work schedule, and the On Demand format, that doesn’t provide the live interaction with the instructor. You can attend the class from anywhere and still benefit from the live interaction with the most experienced instructors.

If you want to attend the full version of the course, the Massachusetts Attorney General’s Office is hosting the same course in person. A significant discount of the regular price of over $4,000 will be applied for law enforcement. Discounts are applied at the time of registration. The course will be held at the University of Massachusetts, Boston campus between June 22 and June 27, 2009. Information related to the course can be found here:

Upcoming Forensic Training in New England

Saturday, April 4th, 2009

I am happy to report that there are several upcoming training opportunities in the New England area focused on digital forensics.

Check out the following:

April 21-22, 2009
WEBCASE – Online Investigations
Medford Police Department
Registration Form

May 11, 2009
Live Data & Acquisition Class
BitSec Forensics
Details & Registration

May 18-22, 2009
Access Data Inc. FTK V2 with 5-Day ACE Certification Class
Medford Police Department
Details & Registration

July 14-16, 2009
Introduction to Mac Forensics
Champlain College
Course Description
Contact: Gary Kessler

Keep an eye on the training page, hosted by the New England chapter of the HTCIA, for future opportunities.

Another Reason to Focus on DNS Security

Friday, March 27th, 2009

This week I found an instance of the Rogue DHCP Server malware that caused an outage on a segment of the network when systems starting getting their DHCP leases from it instead of the legitimate DHCP server. This was particularly nasty because the malware overrides your DNS entries with two external DNS servers ( and Now if you just have outboud DNS queries restricted to your known internal DNS servers (as you should), you should see failed entries in your firewall logs and those clients will fail to resolve any DNS names.

If you don’t have this in place, the client’s DNS resolution could be very easily poisoned. You send out a request to resolve to a malicious DNS server, and it could return any IP address it wants, even a fake banking site. I don’t think there have been any signs that these particular DNS entries are doing anything this specific, but the opportunity exists. The Internet Storm Center and others have been covering this latest instance of the malware:

ISC Diary: new rogue-DHCP server malware
Softpedia News: DNS Poisoning Malware Gets Upgrade

I recommend monitoring for any attempts to query DNS from the two ip addresses listed above. This may help you identify any instances of this malware that hasn’t been caught by your AV yet.

This once again highlights the need for strong DNS controls. You should restrict all DNS queries initiated from inside your network to centrally managed internal DNS servers. Those servers should then be configured for recursive DNS querying out the Internet as needed. These controls would not prevent an outage like the one the rogue DHCP malware can cause, but at least it is limited to a single segment and you won’t have to worry about DNS poisoning from unauthorized DNS servers on the Internet.

Another thing to consider is the affect this malware could have on servers that may use DHCP with reserved addresses as opposed to setting static addresses. Also keeping your client systems (workstations and laptops) which are most likely to get infected off the same layer 2 segment as any servers can help reduce your exposure. Ultimately, preventing a rogue DHCP server is very difficult, but you can limit the damage.

McAfee Virus Definitions in Memory?

Saturday, January 10th, 2009

I had an interesting experience recently with a customer that I thought was worth sharing. In this case, their IDS system triggered an alarm related to the Blaster worm. As we investigated the situation further, it turned out that the two hosts involved were a server that gathers backup images from VMWare ESX servers and sends the images over to the backup server. From the IDS signature, it appeared that the source host was attempting to communicate on SMB port 445, and appeared to be sending a TFTP command to retrieve a system file. The payload also indicated that this activity was the result of a Blaster exploit being launched.

My first thought was that one of the VMWare images being backed up could be infected with the Blaster worm. We determined which server image was being backed up at that time. As I asked them more about what the server does, they told me it is a Windows server where files from several partners are uploaded. It seemed a likely place for an infection. We started by checking the anti-virus software (McAfee) on that server. The signatures were up to date and we ran a full scan which returned no results. We also downloaded the Blaster specific clean up utilities and ran those with no results. The system appeared to be clean.

Next we recovered the backup file that had triggered the IDS alarm, and ran a strings search against it with the keywords from the IDS signature. These keywords included: “dragore’s sploit.sasser.x.launching at”, “tftp -i.GET dcom.exe.P..M.s\Startup”, and “MARB.MEOW”. The only hits were in the pagefile.sys file on the image. If it was infected, the only evidence may not have been written to the disk or else it was encoded in some way. We had already verified at this point that the VMWare server was not sending TFTP commands over SMB as the IDS signature indicated, but we still couldn’t be sure that the code to do so had not been on the server at some point, at least in memory. If this was the case, where had it gone?

I figured the next logical step would be to get a current dump of memory from the server and also a copy of memory from the restored backup. I used the FDPro v1.3 from HB Gary (a free tool) to dump the memory along with the pagefile. I then imported it into a trial version of HB Gary’s Responder product. With this, I was able to map the part of memory with the suspicious keywords back to the mcshield.exe process. The keywords were part of virus definitions for McAfee that had gotten written to the pagefile. McAfee decodes these definitions in memory which is why they were not found on the disk with a strings search. I also found several other malware related keywords in these same processes for other definitions.

Finally I checked several other systems running McAfee and found the same thing. Throughout the next week, several other backups of other servers also triggered the IDS alarms as the definition files exceeded the physical memory space and were written to the pagefile.

With this information, we were able to whitelist this activity between the VMWare ESX server and the backup server. This is another great example of how we always assume the worst going into the investigation but need to be open to all possibilities.