Bypassing File-based Sandboxes

[Usr6]

Diamonds are a girl’s best friend. Prime numbers are a mathematician’s best friend. And file-based sandboxes are an IT security researcher’s best friend.

Unfortunately, malware authors know this. Aware that researchers are using sandboxes to monitor file behavior, attackers are building sandbox-evading techniques into new advanced persistent threat (APT) attacks — and even using these tricks to resurrect notorious malware classics.

As my colleague Zheng Bu and I explain in an upcoming presentation at the Black Hat USA conference, malware is using a variety of checks to determine whether it is running in a sandbox and “play dead” until it reaches a live target. These checks fall into several categories:

• Human interaction — mouse clicks and dialog boxes
  
• Configuration-specific — sleep calls, time triggers, and process hiding
  
• Environment-specific — version, embedded iframes, and DLL loaders
  
• VMware-specific — system-service lists, unique files, and the VMX port
  

Here are a few recent examples we have found.

Khelios

The Khelios botnet, declared dead in 2011, has since resurrected. To evade detection within file-based sandboxes, one of the new Khelios samples (also known as the Trojan Nap) found in 2013, calls the SleepEx() API with a 10-minute time out. Because most sandboxes are set to execute a sample for a short time frame (usually seconds), the Nap sample simply delays malicious activity beyond the monitored time period of most sandboxes to evade detection. The sample called to the undocumented Windows API function NtDelayExecution() to perform an extended sleep call.

Poison Ivy

The infamous remote-access tool Poison Ivy, which has been used extensively in targeted attacks, appears to have not been significantly updated since 2008. But a 2012 sample of the Trojan UpClicker, which is used as a wrapper around Poison IVY, employs the SetWindowsHookEX() API function to hide its malicious activity. By sending 0EH as the parameter to the function, the malicious code is activated only when the left mouse button is clicked and released. Because most file-based sandboxes do not mimic human interaction, this malware remains dormant during analysis and evades detection.

PushDo

PushDo, yet another infamous malware example, checks the build number of the Windows OS. Once identified, it finds a pointer to the PspCreateProcessNotify() API routine, to deregister all existing process callbacks — including any of the sandbox’s monitoring modules. Once all callbacks are deregistered, the malware creates and deletes processes without being detected.

Hastati

Trojan Hastati was designed to wipe out all the hard drives of a computer in Korea. It used the GetLocalTime() API function to activate itself at 2 PM on March 20, 2013. If the sample is monitored in a file-based sandbox before that time and date, it does not execute, evading detection.

UpClicker, PushDo, and Nap are just some of the resurrected advanced malware that use evasion techniques against file-based sandboxes.

In first part of our Black Hat presentation, we provide an in-depth, technical analysis of these evasion methods, which bypass sandboxes commonly used by the anti-virus industry. The talk also compares the effectiveness of three file-based sandboxes in detecting these tactics. And we will provide a live demonstration of some of these anti-analysis techniques operating in the wild.

Sursa: Hot Knives Through Butter: Bypassing File-based Sandboxes | FireEye Blog

[Byte-ul]

Tu ai citit macar ce ai postat ma? Ce treaba are asta cu un tutorial?