There are many forms of malcode concealment, from the “obfuscated beyond recognition” to “in plain sight” yet seldom have we seen hijacking of compiler runtime stubs (although infection of compilers, ala Induc, has already been explored and exploited [2,3])
Obfuscation is typically easy to spot (especially when the authors try very hard to make it difficult to analyze) .
One variation of such a technique is to hijack a call to a constructor or initialization routine within a compiler-emitted stub and point it at the malcode, with the assumption that most AV engines (and analysts) recognize and skip (or pay less attention to) compiler generated stubs.
Shown below is an example of a typical compiler generated stub which has a few calls to subordinate functions, all of which have well defined purposes and are typically not user-controlled.
In a second sample, we see that the code at the entry point is almost identical to that of the previous except that the call to
__setdefaultprecision has been redirected to malcode.
Following this call confirms our suspicions of a hijacked compiler stub…
Could this be a sign of desperation as the malware authors scramble to get one over the anti virus industry, or is it a case of directed evolution? What ever the reason, rest assured that we’re not so easily out-foxed by such schemes.
*picture courtesy of photobucket.com