Archive for January, 2009

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.