Monitoring clipboard – a quick antisandbox trick

Posted on by

Many existing anti-sandbox tricks rely on using timers, detecting mouse movement, checking the presence of the security tools, detecting virtualization, etc. While the list of existing tricks is long I don’t recall seeing clipboard monitoring being mentioned in this context and was curious if anyone discussed that before. Quick google search didn’t bring any results so I thought I will at least describe a high-level idea (FWIW most of the stuff I found online refers to malware monitoring clipboard in order to steal data that is copied to it – this includes an in-depth post by Michael Ligh who discusses it in a context of Volatility framework.)

Btw. if you know any malware that is already using this trick it would be great if you could let me know. Thanks!

As per Microsoft, there are three ways to check if the clipboard content has changed; all of them rely on using dedicated APIs + in some cases require processing of window messages:

  • Monitoring GetClipboardSequenceNumber return value changes
  • AddClipboardFormatListener + WM_CLIPBOARDUPDATE message
  • SetClipboardViewer + WM_DRAWCLIPBOARD message

There are at least two ways to incorporate these functions in an anti-sandbox routine:

  • One can use GetClipboardSequenceNumber API in a way similar to rdstc / GetTickCount trick and stall the code execution until a decent number of clipboard changes occurred (under assumption that the real person is actually using the system and CTRL+C/CTRL+V will generate enough changes to trigger the payload)
  • Using AddClipboardFormatListener / SetClipboardViewer will require creation of a worker window that will need to respond to the respective clipboard change window messages and when they arrive, the program can increase the internal counter until the threshold is met; only then execute the payload

Both are very easy to implement, and I won’t be providing a PoC code as you can grab it from MSDN and/or popular coding forums.

So, if you write sandboxes you may consider monitoring use of these APIs and trigger appropriate playbook that will generate a sequence of clipboard changes to trigger the code execution.

It’s good to mention that all of these APIs have their Nt equivalents that are processed by the win32u.dll/win32kfull.sys:

  • NtUserGetClipboardSequenceNumber
  • NtUserAddClipboardFormatListener
  • NtUserSetClipboardViewer

So may be worth monitoring them on this level too.

Beyond good ol’ Run key, Part 77

Posted on by

This is one more about hh.exe program that is used when you open the .chm files.

The hh.exe functionality is implemented by the hhctrl.ocx library. When hh.exe is started it tries to find the hhctrl.ocx library by checking the following Registry value:

HKCR\CLSID\{52A2AAAE-085D-4187-97EA-8C30DB990436}\InprocServer32

The library that the value points to is then loaded.

If the library doesn’t exist, or the loading didn’t succeed the hh.exe gives it another go and attempts to load the library using the hard-coded name hhctrl.ocx and relying on the LoadLibrary function (and as a result is a subject to side-loading attacks).

As such, there seem to be at least 2 opportunities here:

  • Drop c:\WINDOWS\hhctrl.ocx and delete the HKCR\CLSID\{52A2AAAE… value so running hh.exe will sideload the c:\WINDOWS\hhctrl.ocx
  • Replace the value of the HKCR\CLSID\{52A2AAAE… to point to your own lib and run hh.exe – this will load the lib of choice

Both can be used as a LOLBin / Persistence trick (or a combo).