You are browsing the archive for Anti-Forensics.

IME code injection (old)

December 17, 2015 in Anti-*, Anti-Forensics, Malware Analysis

I like clever and unusual tricks that are meant to fool sandboxes or evade malware analysis (and fool researchers). One of the very first one I came across many years ago was a SetWinEventHook trick used by mebroot which was loading the malicious DLL into Windows Explorer. Since then I tried to keep a track of all new tricks since I believe they are one of the most interesting aspects of reverse engineering work + often indicate the sample using the trick may be more interesting than the ‘run off the mill’ malware.

In today’s post I will describe a very unusual trick which – while not new – is not very well-known. I came across it in the past while checking my sandbox reports. When I discovered this trick, what caught my attention was the following API sequence:

  • FindWindowA … Program Manager
  • PostMessageA … WM_INPUTLANGCHANGEREQUEST … E0010409
  • PostMessageA … WM_INPUTLANGCHANGEREQUEST … 00000409

Apparently something was trying to get a window handle of the Program Manager and then force it to change its language input. Any malware looking for the window of Program Manager (shell) or any other shell window and then sending some messages to it immediately triggers alarm in my head, and it was a good catch.

The trick is not new and some researchers did mention it in the past – f.ex. here, here, and here, and while the trick was explained by others I still think it is useful to bring it back and describe the clever mechanism behind it.

The trick works like this:

  • The malware drops a temporary file in a system folder (a copy of itself with a DLL bit set)
  • It then adds a fake keyboard layout E0010409 under the registry key
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\E0010409
  • Notably, it only adds ‘Layout File’ and ‘Layout Text’ entries under this key, skipping the ‘Ime File’ entry (which normally points to the actual IME DLL)

ime0

  • It then hooks the NtQueryValueKey and ImmLoadLayout APIs.
  • The first API – NtQueryValueKey – is hooked so that it can provide the necessary value of ‘Ime File’ entry when the ImmLoadLayout API is called (ImmLoadLayout calls RegQueryValueExW which in turn calls NtQueryValueKey)
  • This is a neat trick to avoid writing a suspicious entry (pointing to a malicious / executable file) to Registry and instead, provide the value via a hooked API

ime1

  • The second hooked API is ImmLoadLayout
  • The only reason it is hooked seems to be to handle a situation when malware is running with the AV running in a background; the malware doesn’t seem to like 360tray.exe process – if it detects it, it uses the hooked ImmLoadLayout to remove the whole HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts key – it’s a bit strange and this could be a test code – prior to deletion, the malware exports this key to a text file using ‘reg export’
  • The core of the trick is that at some stage the ImmLoadLayout API will be called by the OS from kernel
  • As far as I can tell is it is called via user-mode callback triggered from kernel mode routine ClientImmLoadLayout, which will call KeUserModeCallback with the number 84 (on XP) which in turn will call __ClientImmLoadLayout callback inside user32.dll – this sequence will ensure that the data about the new IME layout is registered inside internal structures of the win32k.sys
  • Malware then calls the PostMessageA API with WM_INPUTLANGCHANGEREQUEST and the new keyboard layout E0010409 which forces explorer.exe to call the ImmLoadIME API, which will retrieve the cached information about the malicious IME file via ImmGetImeInfoEx and then call LoadLibraryW (on XP)
  • The whole process doesn’t inject any code into Windows Explorer directly and doesn’t even write a path pointing to the malicious file into Registry

Note: the trick is old, doesn’t work on newer versions of Windows.

AntiEDR – Samples targeting EDR (Endpoint Detection and Response) solutions

November 7, 2015 in Anti-*, Anti-Forensics, Batch Analysis, Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

I have recently came across an non-intriguing intriguing sample belonging to a family of applications commonly known as a PUA/PUP (Potentially Unwanted Application/Program). The ‘intriguing’ part is that it is the first one I have ever came across that actively tries to detect an EDR solution installed on the system, and in this particular case – CarbonBlack.

The sample md5 is 1233411098A5EE69EB925C559B815510.

What caught my attention was a string ‘IsRunningCarbon’ that I came across when i was eyeballing some of the logs generated by my batch analysis script.

It was placed among many other interesting strings f.ex.:

  • IsTestingBox
  • IsVirtualMachine
  • HasVirtualDrive
  • IsRunningOnVMWare
  • IsRunningOnHyperV
  • IsRunningOnVBox
  • IsRunningOnXEN
  • IsRunningVPN
  • IsRunningIPSECLP2
  • IsRunningOpenVPN
  • IsRunningPPTP
  • IsRunningTools
  • IsRunningFiddler
  • IsRunningFiddlerCert
  • IsRunningDeepFreeze
  • IsRunningPacketCapture
  • IsRunningAVs
  • IsRunningESET
  • IsRunningVipre
  • IsRunningCarbon
  • IsFlashInstalled

so it looked like a part of a generic ‘sandbox/monitor/security product detection’ pack of routines.

When loaded into ILSPY, the code of the function referenced by the name turned out to be a simple ‘directory present’ check (if the ‘CarbonBlack’ directory exists in a predetermined location), but the message the existence of this routine in the code sends to the EDR vendors is that they start to be recognized.

carbonPerhaps it’s not a big deal, but certainly notable. Maybe it is time to introduce randomization in the way EDR-specific directories are named? Or hide them completely (rootkit)?

Of course, the detection of EDR was always possible, but since now it is being actively done I bet it’s just a matter of time when we will see first evasions…