countering malware quality assurance

just a quick post to point out something i just realized - maybe it's obvious to others, maybe not...

i was reading dancho danchev's umpteenth post on malware q/a when it struck me that the recent trend by vendors to put the scanning engine in the cloud effectively kills malware q/a... i suggested before that randomizing heuristic parameters might combat it, but that's probabilistic and comes at the cost of false positives... cloud-based scanning on the other hand ensures that the scanner implementing this new architecture cannot be used effectively (if at all) in traditional malware q/a because the samples will either be given to a server that the av vendor controls (thus destroying the samples' value to an attacker), or if the malware tester manages to sever the ties with the av server then the testing will give an incomplete and misleading result regarding the detectability of the malware in question...

each new scanner that goes this route is another scanner removed from the pool of scanners that malware q/a testers can use and with symantec, mcafee, trend, and panda (and perhaps more that i can't think of at the moment) having already gone this route that's a significant portion of the av user-base which will soon no longer be at the mercy of malware q/a...

i have no idea if this was intended or serendipitous, but either way it's still a good thing - and once again it proves the point that for every measure there exists a countermeasure...

adapting to malware quality assurance

as previously mentioned, malware quality assurance is an attack against heurstics... the idea is to make the malware sufficiently dissimilar to other malware that most heuristic engines find little of anything to be suspicious about...

and unfortunately, it works... at the time of writing, av-comparatives.org's latest retrospective test show that most of the results are grouped around a 40% detection rate... there are some outliers (in both directions) but 40% seems to be the general ballpark for most products when it comes to detecting new/unknown malware...

that's not really a score to be proud of... maybe once upon a time when new malware was comparatively rare, the remaining 60% of those few new pieces of malware for the small window of opportunity during which they remained new/unknown weren't really a big deal... at the current rate of new malware creation 60% miss rate is a big deal... users need to adapt and vendors need to adapt too...

users can adapt by taking any number of steps to prevent new/unknown programs (malware or otherwise) from executing or getting significant system privileges... this includes things like running as a limited user rather than an administrator, using behaviour blocking/HIPS software, using application whitelisting, using sandboxing, etc...

vendors can adapt by making those techniques/technologies easier to find, easier to understand, and easier to use... but there's one more thing... at one point i thought malware qa was pretty much the last nail in the coffin of heuristics but it's occurred to me that there's one thing vendors might be able to try to breathe some life back into heuristics...

polymorphism (sort of)... by which i mean changing/tweaking the heuristic algorithm frequently enough so as to make the results of malware qa less useful... the premise of malware qa is that if the malware is undetected right now it will stay undetected until the malware gets found by someone-somewhere, then gets sent to an anti-malware vendor for analysis, gets analyzed, gets added to the signature database, and that signature database update gets distributed to the potential victim population... create new malware fast enough and that window of opportunity, small though it may be in the ideal defender case, is still big enough... if instead that window of opportunity was significantly less predictable, malware quality assurance wouldn't offer the same kind of assurance it does now...

that's a high-level thought, though... i don't pretend to know how feasible it is to implement (i'm hoping that some engines have parameters originally intended to adjust it's sensitivity to various conditions and that could be randomized)... i do know that this would likely increase the number of false alarms, and probably worse still make those false alarms equally unpredictable, so maybe it's a bad idea but it's an idea none-the-less and i offer it for free to anyone who wants to try it...

what is malware qa?

malware quality assurance is a process in which malware writers test their malware in order to determine whether the malware meets the degree of effectiveness they had hoped for (and obviously one where they throw out those instances that don't meet the grade)...

malware quality assurance indicates a level of maturity and professionalism on the malware writer's part, and although the term could be used to describe a variety of things (some as banal as running a virus to see if it reproduces), it is generally used to refer to the practice of running a large number of anti-malware scanners on a given sample to determine how likely that sample is to go undetected when used in the wild (which may thereby establish an objective measure of the malware sample's monetary worth)...

it is sometimes incorrectly suggested that anti-detection malware qa underscores a weakness in traditional signature-based known-malware scanning... in reality, any new piece of malware will bypass a good known-malware scanner (because the good ones are so exacting so as to eliminate false alarms) so long as it's not a byte-for-byte match with a previously known piece of malware - this is by definition, and there's no need to perform any quality assurance tests to prove it... malware qa is actually an attack against heuristics, because it is the heuristic engines that would be detecting these new/unknown malware samples the malware writers are testing, not the known-malware scanning engines...

back to index