No, this isn't about lousy detection rate. I think we're pretty much resigned to that, irrespective of the latest fancy marketing terms the industry uses to sell us the same failed concept. This is about the forensic quality, or rather lack thereof, of anti-virus. So far so good. This used to be cool back when all we wanted our anti-virus to do was to get rid of the threat. But these days are over. Increasingly now, anti-virus alerts us (maybe) to a persistent threat that has been on the system for days, weeks, heck, even months. And deleting or quarantining such a threat causes a serious problem: It modifies or eradicates evidence. Yes, we get an alert, but then we are like the CSI guys who get called to a murder scene that doesn't have a body. Sure we can spend hours trying to lift DNA off cigarette stubs, but things would be so much easier if the caller could tell us what exactly he has seen where, and where the body was?
In other words: If anti-virus removes a registry key to unhook a DLL, why can't the AV log tell me (a) where this registry key was and (b) when it was created? You know, this would give a first indication on how far back we have to dig to determine what data was stolen. The same holds true for the actual threat files that get deleted or quarantined: A full MAC (modify/access/create) timestamp in the logs shouldn't be too much to ask for? Maybe garnished with an MD5 checksum for good measure, so that the analyst can tell right away if the exact same threat has been seen on another PC already? |
Daniel 385 Posts ISC Handler Nov 2nd 2012 |
Thread locked Subscribe |
Nov 2nd 2012 9 years ago |
I've been learning about reverse engineering malware for a little bit, and have noticed the same problem. Fortunately, Carbon Black seems to fill in the gap.
http://www.carbonblack.com/case-study-malware-infection-2/ http://www.sysforensics.org/2012/06/look-at-carbon-black.html |
Anonymous |
Quote |
Nov 2nd 2012 9 years ago |
Can't agree more given that some a/v forensics is such an essential requirement these days, especially in costing the time to rectify the aftermath and damage limitations.
What is also made all the more difficult, is there is often no definitive 'list' of what files/keys should and should NOT be on the system at any point in time - dates, signatures can be spoofed, with certificates and any registry keys only secured in software installation restore points - all have been vulnerable to compromise. Building an image and wiping the disk with the saved image every day would be extreme to say the least! Highly impracticable given the number of registry reads/writes, would be to keep an accurate image of a complete disk installation and a copy at the beginning of each day. Subsequent comparisons could be logged for differences - but the overhead and analysis would likely be unacceptable. Logging is one way forward, but how do you protect the logs if the OS API calls and/or disk file system has been compromised? ps. notice VUPEN have reportedly found a number of 0-day vulns in Windows 8. Things can only get tougher without better tools. |
Anonymous |
Quote |
Nov 2nd 2012 9 years ago |
I believe Sourcefire's new anit-malware solutions fills these gaps. I'm going off marketing stuff though, I've yet to get my hands on it.
|
Anonymous |
Quote |
Nov 2nd 2012 9 years ago |
Fireeye box does exactly that and more. Granted it should built in the endpoint security solution.
|
Anonymous |
Quote |
Nov 2nd 2012 9 years ago |
In my experience, prevention is where to put the focus. Since AV is no longer effective at prevention, we need to significantly improve our prevention capability. When AV finds something, I consider that a failure of prevention. It's not that I disagree with you, it's just that there is only so much time and money to spend and the bad guys are winning. I think you do make a good point to the extent that AV forensics can help you identify chinks in the preventive armor. The (serious) limitation of AV presently is that it now finds such a small percentage of malware, it is also going to show you a correspondingly low percentage of your armor chinks.
|
PhilBAR 24 Posts |
Quote |
Nov 2nd 2012 9 years ago |
Looking at it from their point of view why should they include forensics features in their products? The number of end users that would find this feature useful is surely very low. I doubt it would even be 1%. And unless law enforcement is going to start investigating malware at the endpoint level for everyone who reports malware, there is even less reason for them to do so. I suppose they might also take the case that forensics evidence might help the bad guys make a better product to avoid detection and removal.
|
KBR 63 Posts |
Quote |
Nov 2nd 2012 9 years ago |
FireEye does do wonders, but on the endpoint, the closest thing I've seen is vSentry from Bromium. It is still in it's infancy, but it looks very promising.
http://www.bromium.com/product/introducing-vsentry.html |
KBR 6 Posts |
Quote |
Nov 2nd 2012 9 years ago |
@Phil In my experience, detection is where to put the focus. Since passwords which used to be considered sufficiently strong are no longer effective at prevention, we need to significantly improve our detection capability... ;)
|
KBR 15 Posts |
Quote |
Nov 2nd 2012 9 years ago |
Why are we still thinking that AV is a battle we can win? We know the number of samples is beyond the capabilities of blacklisting AV. The bad guys test there malware against all the major versions before deploying and the average zero-day doesn't get detected for what ~3 months??
Isn't it about time we gave up on trying to find all the bad and started whitelisting all the good? Shouldn’t we refuse any code that the developer doesn’t digitally sign – so we know where it came from? Limit the allowed application to trusted companies? Further from that switch to whitelisting AV – nothing is allowed to run that’s not approved. We’re aiming to lock down most of our company workstation: We’ll have trusted fileshares: \\company\installs \\company\executables \\company\deployments User can only install/run things from those locations; the whitelisting AV will block anything else. Gatekeepers in each area will be able to upload software to the fileshare – the fileshare will run blacklisting AV to make sure it’s clear. You can download virus.exe or virus.dll as many times as you like – if it’s not approved it can’t run. ATMs have been doing it for years! |
KBR 1 Posts |
Quote |
Nov 5th 2012 9 years ago |
Thank you for bringing up this issue. Our in-house forensics team performs full forensic analyses on all hosts in our organization that are suspected of being infected/compromised (as identified by IDS, AV or other detection systems). One major gripe we've always had is that endpoint AV is constantly making the lives of our forensic analysts difficult for no good reason. When AV quarantines or cleans a threat it would be absolutely trivial for it to capture the necessary metadata (e.g., MAC timestamps, regkey creation times, etc...) that would allow for a proper forensic timeline to be built. Instead due to laziness/sloppiness, the vendors simply don't bother. This metadata is crucial information that anyone who is delving more deeply into any incident will need. By altering evidence without recording even the most basic of metadata it can completely (and unnecessarily) stymie an investigation into an incident. Worse still, if the AV has a bad file sitting in quarantine, even if the summary AV alert failed to collect or display the necessary information about the event, you'd think you could at least just remove the file from quarantine and examine it with its metadata intact. No such luck, that would make too much sense! Instead when the file is restored to disk, the AV allows the file system to completely alter the MAC information, meaning there's no way to view the original values! Again, it would be absolutely trivial for AV products to collect the necessary metadata but they simply refuse to do so. Our organization has brought this issue up many, many, many, times with various AV vendors whenever we have their reps in house. They even acknowledge that they've heard many other forensic organizations make this (trivial) feature request, but our pleas always seemingly fall on deaf ears. It's incredibly frustrating.
On another note, forget about the whitelisting solutions that many in this forum seem to be alluding too as an alternative to standard AV. Just give it a little more thought and you'll realize that that's just trading one intractable problem for another. |
KBR 1 Posts |
Quote |
Nov 6th 2012 9 years ago |
Sign Up for Free or Log In to start participating in the conversation!