You are browsing the archive for Anti-*.

Beyond good ol’ Run key, Part 72

February 9, 2018 in Anti-*, Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

In my old post I described a simple trick that shows how to set up a hot key that can be assigned to execute shortcuts (.LNK files) placed on a Desktop or in a Start Menu. This action survives reboots and logon/logoffs so it’s a nice, and somehow accidental persistence mechanism.

Turns out there is one more variant of this trick that relies on using the .URL files.

Placing a .URL files containing the following data:

[InternetShortcut]
URL=file:///c:/windows/system32/calc.exe
HotKey=768

on a Desktop will assign CTRL+SHIFT sequence to an action that will trigger the execution of the calculator.

The Hotkey can be assigned either manually (via properties):

– in such case you won’t be able to assign the more trickier combinations like CTRL+SHIFT. Or we can do it manually, and in such case all the hotkey tricks are available. All you have to do is to assign a proper value to the HotKey parameter inside the .url file.

You can find out what values represent what codes or by experimenting… or… you can cheat and read this old guide: An Unofficial Guide to the URL File Format.

 

 

PROPagate follow-up #2 – Some more Shattering Attack Potentials

February 4, 2018 in Anti-*, Code Injection, Compromise Detection, EDR, Incident Response, Malware Analysis

A few months back I discovered a new code injection technique that I named PROPagate. Using a subclass of a well-known shatter attack one can modify the callback function pointers inside other processes by using Windows APIs like SetProp, and potentially others. After pointing out a few ideas I put it on a back burner for a while, but I knew I will want to explore some more possibilities in the future.

In particular, I was curious what are the chances one could force the remote process to indirectly call the ‘prohibited’ functions like SetWindowLong, SetClassLong (or their newer alternatives SetWindowLongPtr and SetClassLongPtr), but with the arguments that we control (i.e. from a remote process). These API are ‘prohibited’ because they can only be called in a context of a process that owns them, so we can’t directly call them and target windows that belong to other processes.

It turns out his may be possible!

If there is one common way of using the SetWindowLong API it is to set up pointers, and/or filling-in window-specific memory areas (allocated per window instance) with some values that are initialized immediately after the window is created. The same thing happens when the window is destroyed – during the latter these memory areas are usually freed and set to zeroes, and callbacks are discarded.

These two actions are associated with two very specific window messages:

  • WM_NCCREATE
  • WM_NCDESTROY

In fact, many ‘native’ windows kick off their existence by setting some callbacks in their message handling routines during processing of these two messages.

With that in mind, I started looking at existing processes and got some interesting findings. Here is a snippet of a routine I found inside Windows Explorer that could be potentially abused by a remote process:

Or, it’s disassembly equivalent (in response to WM_NCCREATE message):

So… since we can still freely send messages between windows it would seem that there is a lot of things that can be done here. One could send a specially crafted WM_NCCREATE message to a window that owns this routine and achieve a controlled code execution inside another process (the lParam needs to pass the checks and include pointer to memory area that includes a callback that will be executed afterwards – this callback could point to malicious code). I may be of course wrong, but need to explore it further when I find more time.

The other interesting thing I noticed is that some existing windows procedures are already written in a way that makes it harder to exploit this issue. They check if the window-specific data was set, and only if it was NOT they allow to call the SetWindowLong function. That is, they avoid executing the same initialization code twice.