Sunday, August 17, 2008

Situation Normal....

When analyzing a disk image or live system we're often confronted with the need to scan the system for malware. We need to know what was on the system, if anything, and what capabilities it has. Many people scan with well known vendor utilities like Symantec Antivirus or Mcafee. Others scan with some less popular tools, but all have the same end in mind; Find malware on the system by signature. I think it's past time we as examiners be honest with ourselves. Antivirus is not sufficient when attempting to detect the presence of malware on a system. Sure, it functions and will catch what it's aware of, but malware changes too rapdily for antivirus to be effective. You can scan a system or disk image all you want, but if the signature does not exist, you have no hope. Case in point: Asprox botnet related files. Yes I'm still watching it. Today I grabbed four of the newest binaries available.

The results from virustotal?
1,2,3,4

This is of course brand new malware on the block. But this is obviously a frequent thing.

Guess what? You don't stand a chance. If you're scanning a system for malware in the next few days because you're processing an image for a case, or responding to an incident..FAIL. You can not, based on an antivirus scan, even pretend to claim that the system is malware free. Your certainty level suffers greatly and that friends is what we call doubt.

Now, just because a binary evades signature detection doesn't mean you can't detect it. We just need to adapt out methodology when we search. As examiners we must accept the fact that Antivirus is a failing technology in that it consistently falls short and is no longer reliable if you base your conclusions on the results of a scan.

As such it's time to look at alternative methods when determining the presence of malware. Malware detection in forensics needs to move to a more behavioral based approach. Booting a disk image in vmware and looking at system behavior is a must. Capturing memory and analyzing it is a must. Running a sniffer is a must when the vm is booted. Using multiple antivirus products is no longer an option. I'd suggest that at least three products be used to scan all disk images and systems during response and/or forensics. What am I using? Symantec, Kaspersky, Bitdefender. With the samples I listed above, of course these wouldn't work..but the point is simply this: Just as more sources of evidence leads to a more solid case, the more sources that get consulted during a malware analysis leads to a higher degree of reliability in the results. Is it perfect? No, not at all. Is it more reliable? yes, it's more reliable if you:

1) Look at the filesystem for things that don't fit; new files in system32,new drivers, new services, new batch files, vbs scripts etc.
2) Scan with multiple AV products.
3) Boot the disk image in Vmware, watch the behavior of the system, capture memory, run a network sniffer.
4) Analyze memory, the behavior and the sniffer output(put it through snort and reconstruct streams).

This is far better and more reliable than simply stating "I scanned the disk image with Antivirus Product X, and could not identify any malware on the system. The system is clean."

5 comments:

Anonymous said...

This is, of course, why the trojan defense works... we can't prove a negative "There is no malware on this system..." We can only say that so far, based on our tools and analysis, we have not found any malware. And with malware being able to detect that it is running in a VM and changing it's behavior, residing only in memory and not touching the disk, etc... that leaves enough wiggle room for the defense to claim it was a new malware, undetectable, etc...

and the jury and judge will buy it...

H. Carvey said...

There are a number of other things that can be done, and have served me well during incident response and forensic analysis where AV products have not detected malware. Specifically, Registry analysis - using RegRipper, take a look at ASEPs (MS term - "auto start entry points") used for persistence. Check the ubiquitous Run key for entries that are unusual. Sort the Services subkeys (from the correct ControlSet) for services or device drivers that may have been added recently, particular near the time of the incident.

I've actually seen the use of the "Image File Execution Options" Registry key in the wild...which was pretty cool. I've also seen some other interesting uses of Registry keys...but an examiner should not forget to also check the locations within the file system, as well.

hogfly said...

Harlan,
I knew I forgot something! Of course regripper. I've used it in the past 3 malware investigations I've done. It simply rocks and saves me loads of time. I'll be sending you hives soon.

Anonymous said...

Mr. Hogfly,

Check out Yi-Min Wang and associates' work: http://research.microsoft.com/csm/strider/Strider_Gatekeeper_Usenix_LISA_2004.pdf

T

hogfly said...

Troy calling me Mr. hogfly? I get a huge kick out of that, like you take me seriously or something. That paper looks great, I'll have to read it tomorrow.