Many security product-lines leverage sandboxing in order to detect more behavior analysis versus traditional signature based detection. Most behavior analytics are trivial to fake or circumvent depending on the technology. Regardless, these technologies are designed to handle the mass prevalent / mass infection methods, not targeted or custom malicious software. One example of this is by placing long time delays inside of the malicious code which triggers the sandbox environment to be tricked/fooled in detecting call outs to command and control or file droppers, etc. One of the methods TrustedSec has used for a while and has been known for a long period of time is using core detection. Most commonly, this technique is being used in the Dyreza banking Trojan for sandbox evasion. The method is extremely simple, takes only a couple of lines of code, and works on almost any virtualization/sandbox technology on the market today. The way that most sandbox technologies work is by first creating a simulated environment - usually that of Windows or a Linux operating system (with wine-esk emulation) in order to determine how incoming malicious software occurs. These virtual machines need to be heavily tweaked for efficiency and to not have a major hardware performance hit in order to operate under normal conditions. In this case, during simulated testing in our experience, it was found that a majority of the sandbox technologies leverage 1 core which is plenty for normal operation and to perform analysis quickly. This is done for efficiency and to ensure that under heavy load, it can still process a large amount of queries in fast manner. Under our testing conditions, we found three of the major sandbox technologies were vulnerable to this specific type of attack and went without detection. Most sandbox technology analyzes both web content and incoming emails for malicious content and only requires minimal routines to be performed. This would be registry hooking, network communications, dropper files, and traditional malicious behavior. Since these technologies consistently leverage 1 core and the majority of systems in the workforce need to leverage more than 1 core, it's easy to determine when inside of a sandbox simply based on the amount of cores in a system. In order to skirt around the detection, simply detect how many cores we are operating under, and if it’s 1, there’s a high chance that we are inside of a sandbox technology. There are a few methods on top of this; however, this one appears to be one of the more reliable methods for circumvention. In the below diagram, most sandbox technologies look at either (or both) web content and incoming/outgoing SMTP for malicious content. This could be executables, PDFs, documents, spreadsheets Applets, browser simulations, and more. Basic pattern criteria is that if a specific monitored application performs suspicious behavior, flag it as a potential malicious file. Below depicts how this works from a technology perspective: Based on web content and incoming/outgoing email, if something matches a criteria, a virtual machine is created and traditional inspection occurs on one of these systems. In order to circumvent this, we need to make a baseline of what the virtual machine looks like. There are many ways of flagging a system as a virtual machine, but most sandbox systems have similar characteristics, most specifically the cores on the systems for analysis. Some offload the analysis to a cloud infrastructure in order to perform the analysis and not actually on the system itself. Below are two lines of Python that detect how many cores the environment CPU has: Next, let’s run the code to see how many cores the system is running: Now let’s say we are inside of a sandbox technology which most notably will be running under 1 core and where most computers will be running under several cores: In this example, if we ran the code and were within a sandbox with 1 core, we would simply exit our program and not perform any functions. If we are running in more than 1 core, we do our evil things. This method is highly effective and reliable as almost every computer that would be targeted including workstations, laptops, and servers are running way more than 1 core. This method works on any programming language, most notably our favorite exploitation method, PowerShell:

Get-WmiObject –class Win32_processor | ft NumberOfCores

This simple PowerShell command can automatically detect and respond back with the number of cores a general machine is running under: The methods for this is nothing new, but still today surprisingly effective against the major players in this space. While the way around these pieces of technology is trivial, having a solid security program with multiple layers is the best approach for defense. One piece of technology in an environment doesn't make an organization safer from attack - especially if a security program doesn't exist. As an industry, if we focus on building security programs from a foundation and augmenting technology to help assist a program, we can have multiple layers of defense - not just that of a shiny box that blinks and has awesome pie charts. Remember, security takes hard work and effort which doesn't have short cuts with technology. A healthy security program is that of an organization that understands why security is important first. Technology can help that defense - but ONLY when a program exists and is healthy. For defense against this specific type of attack, focus on a monitoring and detection program that has actual human beings looking for threats against your organization and spending a significant amount of time hardening your endpoints. That's where all of the attackers are hitting right now, and hard. As of a few moments ago, TrustedSec has released a new version of the Social-Engineer Toolkit (SET) v6.3.2 which incorporates this method into pyinjector and multi-pyinjector. This article was written by David Kennedy - CEO of TrustedSec