Network Antivirus Evasion with XOR

Many organizations I speak with have instigated network filtering and security monitoring solutions targeted at identifying malicious binaries traversing their egress points. Something that they’ve been observing in recent months is the increase of suspicious binaries that are unsupported and non-executable. Ordinarily any intercepted binaries would be farmed off to static anti-virus scanners or tin-wrapped behavioral analysis engines for classification; however a growing volume of these binaries cannot be scanned or executed within virtual environments. What’s going on?

More often than not, these perimeter network defenses are encountering encoded and obfuscated malicious binaries – constructed purposefully by an attacker to bypass network threat detection products. These evasions aren’t anything new, it’s just that the tools and functionality to encode malicious binaries “on-the-fly” have become standard features in a growing number of automated attack delivery tools and DIY botnet construction kits.

The non-executable binaries are typically malicious binaries that have been encoded using simple, light weight, cryptographic techniques. They need to be decoded at the receivers end and decrypted back in to their “original” file format for proper malicious execution. In many cases the entire (original) malicious binary is encrypted using a simple XOR cipher. While there are no shortage of techniques that can be used (take a look at the default assortment of file encoders within the Metasploit MSFencode module for instance), XOR does seem popular and is more than “good enough” to bypass existing security technologies. Sometimes the simplest evasion techniques are the best.

Just to be clear though, we’re talking about malicious binaries that have been fully encrypted and require a separate application or script running on the victim’s computer to decrypt them (i.e. they cannot be executed by themselves) — not executable binaries that have been armored for local anti-virus evasion purposes and are shipped in an already executable format. There’s a very nice walk through of manually armoring files for the purpose of evading local host inspection of malicious binaries in “Bypassing Anti-Virus Scanners“, and there’s a good discussion of using Metasploit to construct evasive executable content over on offensive-security.com for comparisons sake.

The non-executable encrypted binaries are typically either droppers for newly compromised victims, or malicious updates for existing victim installations. In the case of newly compromised victims, the encrypted malicious binary will be requested by the attacker’s payload (e.g. shell script) and decrypted in memory before being installed on the victim. For existing victims, the encrypted binary will be requested by an already installed malware component, decrypted, and used to replace existing components of the malware installation.

There are other permutations to the theme as well. For example, the use of malicious Adobe Flash files that serve as the transport instigator for the malicious commands such as the imm32.dll dissected by Stop Malvertising, or the use of PNG files to propagate XOR’ed malware.

What does this mean for automated network-based anti-virus solutions (such as Norman, Trend Micro, etc.) and auto-signature-creator anti-virus products (such as FireEye, Palo Alto Networks’ Wildfire, etc.)? Since the intercepted binary is incapable of execution by itself and will never run under an emulated or virtualized behavioral system, it will not be automatically analyzed or classified as malicious. Only the targeted victim will uncover the unsavory payload.

Because the technique works so well and is so easy to do, we can expect the trend to continue. Organizations will capture more and more suspicious non-executable binaries going forward (often containing little or no hint as to what the file may potentially be).

What can be done? I believe a key perspective to dealing with this evasion technique is to better understand the suspicious nature of the file transfer. Consider it “contextual awareness”. Despite not being able to dissect and analyze the malicious binary directly, understanding the context of its transport will likely provide enough circumstantial evidence to arrive at a comfortable conclusion as to the maliciousness of the binary. For example:

• What is the reputation of the file download source? (E.g. a corporate entity, file sharing site, hacker forum)
• Is the source known to only host malware? (e.g. malicious files are encountered there frequently)
• Is the file requester already known to be infected? (e.g. the requester is a known botnet victim)
• Is there a cyclic pattern to the download file requests indicative of previous compromise? (e.g. an existing malware installation is requesting new updates)
• What is the nature of the source? (e.g. the hosting server is a known C&C server)
• What are the ports and protocols involved? (e.g. HTTP over a low (non-TCP80) port number)
• What are the parameters of the file? (e.g. the file is not readable by any commonly installed applications on the destination host, and is approximately the same size are regularly encountered malware samples)

At the end of the day, the attackers have the upper-hand when it comes to obfuscating malicious binaries. The increased application of XOR ciphers designed to evade network-based binary inspection tools and appliances makes sense, and is more than sufficient to thwart these protection technologies. In that case, it makes increasing sense to look for other network artifacts that can hint at the suspiciousness of the binaries makeup – and to use that contextual awareness to decide upon an automated defense reaction.