How DarkCoderSC reveals SFX files methodology

He describes the use of combining a DLL and a virus to automatically run the virus from the SFX delivery mechanism. “As of now,” he concludes, “you should not trust unknown SFX packages and don’t trust your anti-virus in this case because everything is encrypted by winRAR so they will not detect anything bad.”

Is this a new or serious problem?

It’s not new, says David Emm of KasperskyLabs. “The use of archiving and compression to obfuscate malware code goes back almost as long as there have been PC viruses.”

It’s not new, says Luis Corrons of PandaLabs. “I have seen malware using self-extracting archives for years.” It used to be dangerous, he says, explaining the historical context. In the early days of anti-virus, some AV products could not scan inside archives. Files had to be extracted before they could be analyzed, and numerous issues had to be resolved. “The SFX file is not malware per se, as it is only a container of files,” says Corrons, “and there were discussions to decide if it should be detected or not.” How should the AV company handle the problem? “If you have an SFX file containing a possible malware file, you cannot disinfect it, as the antivirus cannot rebuild the SFX. The only option is either to warn the user about what’s inside the file, or delete the SFX – but in doing that you are deleting all the files where only one may be malware and the others are not.” Most of these issues have long since been solved, he adds.

EMM explains that the AV product simply needs to understand the compression algorithm. “Our scan engine, for example, is able to handle thousands of different compression and archiving tools.” And, he adds, “a raft of proactive technologies – including, for example, sandboxing – allows us to analyze the activity of a given file before it runs, even if it’s something we haven’t seen before.”

It’s not new, says Graham Cluley of Sophos. “We've seen malware distributed via different compression methodologies since the 1990s. Most anti-virus products have been scanning inside compressed and archived files – including self-extractors – since the 1990s.” Many AV products can be updated to deal with new compression/archiving formats as simply as they are updated with new malware definitions. Furthermore, he adds, even if the self-extractor is not scanned inside by the anti-virus, and it “still spurts out a new infected file to disk which is then run, there is a chance for the on-access scanner to still intercept the decompressed file.”

It’s not new, but it does work, says Aryeh Goretsky of ESET. “It's a modern take on .ARC, .ZIP and ANSI bombs from the DOS era.” Goretsky explains that the process is legitimate, to run a setup program from inside the archive after the file has been extracted. “Most AV products scan archive files for a variety of threats, including suspicious self-extraction commands.” He sees the main problem as one of social engineering, “or at least a reliance on user naïveté that they will click through the option to run the file after extraction.”

According to Goretsky, “ESET detects this class of threats with the designation Archbomb.” He has data showing their detection back to 2007, but believes detection dates back to the DOS version of NOD from the 1990s. “I know McAfee had detection for them in VIRUSCAN back in the early 1990s.”

What’s hot on Infosecurity Magazine?