Anti-Sandboxing: Wait for Mouse Click

Overview

The Trojan Upclicker (as reported by eEye) uses the SetWindowsHookExA API with the WH_MOUSE_LL parameter to wait until the user lets up the left mouse button (WM_LBUTTONUP) before performing any malicious functionality (then it injects into Explorer.exe).

A sandbox environment that does not mimic mouse actions (probably most of them) will never execute the malicious behavior. This is probably effective against Kaspersky and others.

Source: The Trojan Upclicker

Component Reuse: None

Comments:

• 2015-08-03 15:59 [User #71473]:

  Good call.  Thanks for the cleanup.

• 2015-08-03 05:56 [User #524297]:

  done, should probably link around rather than create copies. have theirs link here or vice versa

  get User #4849738 to make you a Confluence poweruser.

• 2015-07-31 16:49 [User #71473]:

  So, uh, I tried to copy this so I could move the copy over to Detecting and Bypassing Personal Security Products (PSPs) , but it won’t let me move it.  Can one of y’all fine RDBers do me a solid and move it over?  Thanks!

PSPs vs. DLL Injection

PSPs have various levels of protections against injecting code into common processes.  Most PSPs appear to have a decent level of protection against their own running processes, and some protect various windows processes as well.  Here’s what we have observed to date:

• Kaspersky:
  • When running as SYSTEM, Kaspersky protects several Windows system processes that are ordinarily accessible: wininit.exe, csrss.exe and lsass.exe are all locked down.  Kaspersky does not appear to protect svchost.exe processes.  Additional research is needed to nail down exactly which processes are open for manipulation, but most SYSTEM process that can cause an immediate bluescreen are protected.
  • Kaspersky does not appear to protect user processes at all.  Explorer and dwm are both open for injection.  The Kaspersky sandbox, however, does appear to flag the injection of some types of payloads, so a KAV sandbox defeat prior to injection is recommended.
• AVG: AVG appears to protect explorer.exe.  It may also detect injection as malicious activity via the sandbox, so a sandbox defeat prior to injection is recommended.  We were able to successfully defeat the AVG sandbox with a large (100MB) malloc followed by a memset and free.
• Bitdefender: Bitdefender appears to protect explorer.exe.
• Rising: Flags injection into explorer.exe

For those processes that block injection into explorer.exe, we have had varying levels of success doing the following:

• Create a non-suspended process with a hidden window then inject into the process.  Some PSPs will flag this.  Others flag the hidden window. (low success)
• Create a suspended process with notepad.exe, cmd.exe or some other common binary, then inject into the suspended process.  Some PSPs still block the injection and thread creation (medium success)
• Create a suspended process using the PSPs own binaries.  We specifically target the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall keys for the target PSP and identified the uninstall binary from either the DisplayIcon or UninstallString values.  This was successful against AVG, Bitdefender and Rising. (great success!)

AVG Catches a Payload Dropped to Disk and Launched via Link File Well After Execution

User #14588054 and I ran into an issue with AVG recently.  IV&V discovered that a GravityTurn payload that we were dropping to disk and executing using DriftingShadows (Windows .LNK exploit on an SMB share) was being caught by AVG, but only after it had already dropped, executed, successfully beaconed and then terminated.  GravityTurn itself was not caught when manually executed, and DriftingShadows could drop and run benign payloads without being flagged. Weird and not good.

We tried several simple defeats (changing the drop location, changing the extension and even including a previously removed privelege escalation) to no avail.  Finally, we decided to try Process Hollowing.  This worked like a charm but was complicated by the fact that Drifting Shadows for 64-bit targets is a 64-bit DLL, and process hollowing only works from 32 bit loaders using 32-bit payloads.  The solution was to split the functionality into a 64-bit first stage DLL and a 32-bit loader DLL.  The link file launches the 64-bit DLL, which uses rundll32 to run the 32-bit DLL.  The 32-bit DLL in turn unwraps the compress/encrypted GravityTurn payload in memory and launches and hollows a 32-bit svchost.exe to host the payload.

It’s awesome, and by awesome I mean totally sweet.

#getoffmylawn #thanksSean

Rising Thinks You’re Signed

Owner: User #3375374

Rising will trust binaries with self-signed certificates. This generally works if Rising can not hit the Internet e.g. closed networks. There is no way for Rising to verify the certificate so just used the signtool in the Windows SDK.

F-Secure Entropy Defeat

UPDATE: Another technique seems to work fine for both F-Secure and Avira.  Cloning the manifest from a self-extracting RAR file seems to make both of these annoying troublemaker PSPs happy.  The resource type for the manifest is 24, the resource number is 1 and the resource language is 1033.

Note: This technique does cause issues with Kaspersky when used with Snowcrash.  Proceed with caution and test, test and retest:

 

Old Technique Follows:

F-Secure, not unlike Avira, seems to strongly dislike binaries that contain large sections of high entropy data. Unfortunately, the Rar! trick doesn’t fool F-Secure. However, it seems F-Secure is doing a different, but equally brain dead static string scan to see if an otherwise “dangerous” file is a totally legit Rar self extractor – it looks for strings contained in the string table resource of a RAR SFX.

Plop this RC file into your binary with Visual Studio or Reshacker, or use Clone resources on a sample self extracting RAR file.

NOTE: While this technique seems to work swimmingly against F-Secure, it makes Avira pitch a fit.  More research is needed to see if there is a way to defeat both F-Secure and Avira at the same time.