Sandboxie Detection

If it doesn't fit elsewhere, it goes here
Post Reply
sludge
Posts: 1
Joined: Sun Jan 25, 2015 2:49 pm

Sandboxie Detection

Post by sludge » Sun Jan 25, 2015 3:04 pm

Hello,

I use Sandboxie for some light malware analysis, I have never run in to a piece of malware that had this functionality. However, I know it has been out for quite some time (the original snippet was around 2009) and it is still active today.

Code: Select all

bool IsInSandbox()
{
    char* sModule[] = { "SbieDll.dll" };   
    for( int i = 0; i < ( sizeof( sModule ) / sizeof( char* ) ); i++ )
    {
        if( GetModuleHandle( sModule[ i ] ) ) {
            return true;
        }
    }
    return false;
}

I know you can also it determine by the window text also.I know this is not a life or death detection as stated there are easy fixes for programs with this functionality, however I just thought I would write about it.

Thanks for your time.

menlo
Posts: 1
Joined: Thu Mar 05, 2015 8:10 am

Re: Sandboxie Detection

Post by menlo » Thu Mar 05, 2015 8:36 am

Actually I was made aware of SandboxIE through a podcast years ago from Gibson - grc.com and have been showing people this technology ever since (IT Consultant).
I just found this quote in an Ars Technica article about the CrytoLocker 2.0 reverse engineering discoveries:

http://bit.ly/1aKC5ya
Cloaking enabled

The installation components of CryptoWall 2.0 are cloaked by multiple levels of encryption, with three distinct stages of installation each using a different encryption method to disguise the components installed. And like many modern pieces of malware, CryptoWall 2.0 has a virtual machine check in its code that disables the attack when the malware is installed within a virtual instance—in part to prevent security researchers from isolating and analyzing its behavior.

The VM checker code, in the first stage of CryptoWall’s dropper sequence, checks the system for running processes, searching for VMware and VirtualBox services or the Sandboxie application partitioning library. If the coast is clear, the code does some best practices-based memory handling to release memory used in the initial drop mode, then launches another dropper disguised as a Windows Explorer process.
with more information about the breakdown here:
https://blogs.cisco.com/security/talos/cryptowall-2

The comments are also insightful - one comment on the Cisco blog mentions the fact that they check snort.org for "Cryptolocker 2.0" , but I suppose you can also search for snort SID's are 32521 & 31223 (this ID list will probably grow over time.)

I know it sounds a little esoteric, but I supposed you can't develop without keeping informed of ways exploits are written against your application. So just in case you guys missed this I wanted to post it. It is probably a good idea to figure out the names of the current 'checker' code snippets and the phrasing the hacker community uses and set up google alerts? RSS stuff like this Cisco blog?

Thanks for everything and keeping us safe!

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest