You are browsing the archive for Reversing.

Enter Sandbox – part 15: rE[mn]u[mn]eration games

November 24, 2017 in Reversing, Sandboxing

Observing a malware is one thing. Observing the very same malware in a rich context is another.

The traditional approach to sandboxes focuses on scoring the sample’s badness, extracting IOCs, and not focusing that much on the in-depth analysis. It’s understandable, because in-depth analysis are not the ultimate goal. Still… being able to extract more information that may help with the manual analysis is always welcome. And it’s actually getting better – the competition is slowly changing the landscape and newer sandboxes support memory dumping, PE file rebuilding, show nice process / thread trees, various graphs, etc… and place more and more hooks in place. And then again, even if they intercept the most popular APIs, inline functions, or even intercept virtual tables, it may still not be enough.

I thought, what would happen if I intercepted not only the most popular APIs that are used by malware, but also these that are less-frequently looked at, and in particular, these that may help to understand a flow of events in a better context – enriching the data that sandbox presents and making the in-depth analysis easier.

What are these APIs?

Let me show you an example…

Imagine you intercept the function CreateToolhelp32Snapshot to take a note of the fact that the malware is enumerating processes. This may add to the ‘badness’ weight, but on its own is not a malicious feature per se. Lots of ‘clean’ processes enumerate processes.

What if we not only did that, but also intercepted Process32First and Process32Next?

This could be the result (output is simplified to demo the idea):

CreateToolhelp32Snapshot
Process32First: [System Process]
Process32Next: System
Process32Next: smss.exe
Process32Next: csrss.exe
Process32Next: winlogon.exe
Process32Next: services.exe
Process32Next: lsass.exe
Process32Next: svchost.exe
Process32Next: svchost.exe
Process32Next: svchost.exe
Process32Next: svchost.exe
Process32Next: svchost.exe
Process32Next: spoolsv.exe
Process32Next: explorer.exe
Opens Process: %WINDOWS%\explorer.exe
VirtualAllocEx: %WINDOWS%\explorer.exe
NtWriteVirtualMemory: %WINDOWS%\explorer.exe
VirtualAllocEx: %WINDOWS%\explorer.exe
NtWriteVirtualMemory: %WINDOWS%\explorer.exe
VirtualAllocEx: %WINDOWS%\explorer.exe
NtWriteVirtualMemory: %WINDOWS%\explorer.exe
VirtualAllocEx: %WINDOWS%\explorer.exe
NtWriteVirtualMemory: %WINDOWS%\explorer.exe
VirtualAllocEx: %WINDOWS%\explorer.exe
NtWriteVirtualMemory: %WINDOWS%\explorer.exe
CreateRemoteThread: %WINDOWS%\explorer.exe
NtResumeThread: %WINDOWS%\explorer.exe

Analysing a log like this tells you straight away that the malware is enumerating processes, and when it finds explorer.exe, it injects a bunch of buffers into it (possibly mapping sections of the PE payload?), and then creates a remote thread. As a result, the explorer.exe process now is hosting malicious payload.

While the code injection into explorer.exe can be deducted from manual dynamic analysis, or may be even obviously apparent when we are evaluating the process tree and network connections from a report generated by a sandbox, there is a subtle difference. The context these 2 additional intercepted APIs provide allows to be quite certain that the malware is actually quite specifically looking for the explorer.exe, and not for the other process.

It also tells us HOW the process is found.

And mind you, this is actually not a trivial question if you are doing in-depth malware analysis.

There are cases where this determination is very important. Having an ability to quickly determine if we are missing some target process on the test system can save us a lot of time spent on mundane manual analysis. This is actually one of the first questions your customer will ask you, especially when it comes to targeted attacks. It is a very responsible job to deliver the results and not to miss stuff!

When you look at malware that is highly targeted, f.ex. malware that is targeting Point of Sale systems, running it through a sandbox may _not_ give you any good results, because you either won’t see the process enumeration at all, or may miss the name of the process that the malware is looking for. The malware will look ‘broken’ to us. I can’t count how many times I wasted time on manual analysis and even incorrectly concluded that the malware is ‘broken’ while looking at heavily obfuscated, or bloatwarish malware samples. Until I started looking at the context of the early exit.

It is really helpful to be able to cheat a bit.

For the case of the process enumeration one can not only intercept the Process32First and Process32Next functions, but also enhance the results with the interception of string comparison functions.

If we get lucky, the result could look like this:

Process32First: [System Process]
lstrcmpiA ([System Process], explorer.exe)
Process32Next: System
lstrcmpiA (System, explorer.exe)
Process32Next: smss.exe
lstrcmpiA (smss.exe, explorer.exe)
Process32Next: csrss.exe
lstrcmpiA (csrss.exe, explorer.exe)
Process32Next: winlogon.exe
lstrcmpiA (winlogon.exe, explorer.exe)
Process32Next: services.exe
lstrcmpiA (services.exe, explorer.exe)
Process32Next: lsass.exe
lstrcmpiA (lsass.exe, explorer.exe)
Process32Next: vmacthlp.exe
lstrcmpiA (vmacthlp.exe, explorer.exe)
Process32Next: svchost.exe
lstrcmpiA (svchost.exe, explorer.exe)
Process32Next: svchost.exe
lstrcmpiA (svchost.exe, explorer.exe)
Process32Next: svchost.exe
lstrcmpiA (svchost.exe, explorer.exe)
Process32Next: svchost.exe
lstrcmpiA (svchost.exe, explorer.exe)
Process32Next: svchost.exe
lstrcmpiA (svchost.exe, explorer.exe)
Process32Next: spoolsv.exe
lstrcmpiA (spoolsv.exe, explorer.exe)
Process32Next: PERSFW.exe
lstrcmpiA (PERSFW.exe, explorer.exe)
Process32Next: explorer.exe
lstrcmpiA (explorer.exe, explorer.exe)

That makes the in-depth malware analysis supereasy, doesn’t?

I think there is a potential market for supporting in-depth malware analysis with sandbox technology – make the interception configurable (offer a list of APIs to monitor, allow time to run to be selected manually, rebuild files, perhaps give live access to the analysis box, etc.).

Reversing ykS is the limit.

And while I do commercial in-depth analysis and I may be shooting myself in a foot here, I can’t stress enough how important ROI is for both you and the customer.

PROPagate – a new code injection trick

October 26, 2017 in Anti-*, Code Injection, Compromise Detection, EDR, Incident Response, Malware Analysis, Reversing, Sandboxing

Executing code inside a different process space is typically achieved via an injected DLL /system-wide hooks, sideloading, etc./, executing remote threads, APCs, intercepting and modifying the thread context of remote threads, etc. Then there is Gapz/Powerloader code injection (a.k.a. EWMI), AtomBombing, and mapping/unmapping trick with the NtClose patch.

There is one more.

Remember Shatter attacks?

I believe that Gapz trick was created as an attempt to bypass what has been mitigated by the User Interface Privilege Isolation (UIPI). Interestingly, there is actually more than one way to do it, and the trick that I am going to describe below is a much cleaner variant of it – it doesn’t even need any ROP.

There is a class of windows always present on the system that use window subclassing. Window subclassing is just a fancy name for hooking, because during the subclassing process an old window procedure is preserved while the new one is being assigned to the window. The new one then intercepts all the window messages, does whatever it has to do, and then calls the old one.

The ‘native’ window subclassing is done using the SetWindowSubclass API.

When a window is subclassed it gains a new property stored inside its internal structures and with a name depending on a version of comctl32.dll:

  • UxSubclassInfo – version 6.x
  • CC32SubclassInfo – version 5.x

Looking at properties of Windows Explorer child windows we can see that plenty of them use this particular subclassing property:

So do other Windows applications – pretty much any program that is leveraging standard windows controls can be of interest, including say… OllyDbg:When the SetWindowSubclass is called it is using SetProp API to set one of these two properties (UxSubclassInfo, or CC32SubclassInfo) to point to an area in memory where the old function pointer will be stored. When the new message routine is called, it will then call GetProp API for the given window and once its old procedure address is retrieved – it is executed.

Coming back for a moment to the aforementioned shattering attacks. We can’t use SetWindowLong or SetClassLong (or their newer SetWindowLongPtr and SetClassLongPtr alternatives) any longer to set the address of the window procedure for windows belonging to the other processes (via GWL_WNDPROC or GCL_WNDPROC). However, the SetProp function is not affected by this limitation. When it comes to the process at the lower of equal  integrity level the Microsoft documentation says:

SetProp is subject to the restrictions of User Interface Privilege Isolation (UIPI). A process can only call this function on a window belonging to a process of lesser or equal integrity level. When UIPI blocks property changes, GetLastError will return 5.

So, if we talk about other user applications in the same session – there is plenty of them and we can modify their windows’ properties freely!

I guess you know by now where it is heading:

  • We can freely modify the property of a window belonging to another process.
  • We also know some properties point to memory region that store an old address of a procedure of the subclassed window.
  • The routine that address points to will be at some stage executed.

All we need is a structure that UxSubclassInfo/CC32SubclassInfo properties are using. This is actually pretty easy – you can check what SetProp is doing for these subclassed windows. You will quickly realize that the old procedure is stored at the offset 0x14 from the beginning of that memory region (the structure is a bit more complex as it may contain a number of callbacks, but the first one is at 0x14).

So, injecting a small buffer into a target process, ensuring the expected structure is properly filled-in and and pointing to the payload and then changing the respective window property will ensure the payload is executed next time the message is received by the window (this can be enforced by sending a message).

When I discovered it, I wrote a quick & dirty POC that enumerates all windows with the aforementioned properties (there is lots of them so pretty much every GUI application is affected). For each subclassing property found I changed it to a random value – as a result Windows Explorer, Total Commander, Process Hacker, Ollydbg, and a few more applications crashed immediately. That was a good sign. I then created a very small shellcode that shows a Message Box on a desktop window and tested it on Windows 10 (under normal account).

The moment when the shellcode is being called in a first random target (here, Total Commander):

Of course, it also works in Windows Explorer, this is how it looks like when executed:


If we check with Process Explorer, we can see the window belongs to explorer.exe:Testing it on a good ol’ Windows XP and injecting the shellcode into Windows Explorer shows a nice cascade of executed shellcodes for each window exposing the subclassing property (in terms of special effects XP always beats Windows 10 – the latter freezes after first messagebox shows up; and in case you are wondering why it freezes – it’s because my shellcode is simple and once executed it is basically damaging the running application):

For obvious reasons I won’t be attaching the source code.

If you are an EDR or sandboxing vendor you should consider monitoring SetProp/SetWindowSubclass APIs as well as their NT alternatives and system services.

And…

This is not the end. There are many other generic properties that can be potentially leveraged in a very same way:

  • The Microsoft Foundation Class Library (MFC) uses ‘AfxOldWndProc423’ property to subclass its windows
  • ControlOfs[HEX] – properties associated with Delphi applications reference in-memory Visual Component Library (VCL) objects
  • New windows framework e.g. Microsoft.Windows.WindowFactory.* needs more research
  • A number of custom controls use ‘subclass’ and I bet they can be modified in a similar way
  • Some properties expose COM/OLE Interfaces e.g. OleDropTargetInterface

If you are curious if it works between 32- and 64- bit processes… yes, it does!