You are browsing the archive for Code Injection.

Talking to, and handling (edit) boxes

June 28, 2019 in Code Injection

In my older posts I mentioned that data injection techniques are as important as code execution. If you can sneak in some data into another process’ address space w/o being caught… you get a foot in a door for a stealth code execution/evasion.

Writing data to other processes is quite easy, but finding where it is actually stored is much harder. Nowadays, aggressive enumeration / scanning of memory regions of other processes’ address space will surely trigger some alerts (it’s a technique known as RAM Scraping and some security solutions detect it).

Luckily, windows messages come to the rescue again – they are still benefiting from a very unrestricted access to memory of other processes while providing a convenient interface to access this goodness (an the interface itself is kinda hard to monitor).

EM_GETHANDLE and EM_SETHANDLE messages are used by Edit Controls. When you send the first of these messages you will get an address to a buffer where the edit control stores its text (i.e. whatever you e.g. type in Notepad). When you send the second – you can actually change the address of this buffer to whatever you want, even if temporarily.

You could therefore launch Notepad, send keystrokes to it to ‘type’ a set of characters – a cleverly crafted shellcode – or simply launch the program to open your payload file as text, and then find the memory of the address where this data is stored via EM_GETHANDLE message, and then finally use one of the known code execution techniques to run this code.

The shellcode itself needs to be Unicode-compatible (if you use English letters only, each 8-bit character will be converted to Unicode as a 16-bit word with a leading zero; shellcode needs to take this into account). Luckily, the fact characters must be Unicode is actually beneficial, as the characters can be almost anything and these may form a nice binary shellcode (i.e. you could save the shellcode natively as UTF16 and use BOM to let Notepad know how to load the file). Notably, E9 and EB (opcodes for unconditional jumps) seem to be easy to inject w/o any tricks (both of them are Latin letters ‘e’ with accents).

Code Execution via surgical callback overwrites (e.g. DNS memory functions)

June 12, 2019 in Code Injection, Sysmon

Today I looked at Sysmon v10 and its support for logging DNS queries. It’s a pretty cool feature that intercepts all the DNS requests on a monitored host, and if possible, maps them to the process name making that request. It is a nice addition to Sysmon’s already awesome logging capabilities.

Just for fun, I created a simple POC that used DnsQuery_A API to send a multiline DNS query, because I wanted to see how Sysmon will react to it. It was obviously a non-sensical exercise, but it’s fun to see we can modify the layout of Event Logs by introducing some unexpected, redundant data:

Anyway…

I decided to look at the DnsQuery_A function in IDA as well. I was curious if/what characters it accepts & if there is any limit to the buffer it can process. This was a quick & dirty attempt to see if I could send a query that Sysmon would truncate in a similar fashion as I described in this post.

While digging into the code I noticed an interesting way dnsapi.dll is allocating memory. Instead of a fixed (inline) function it relies on a couple of callbacks. One of them is a memory allocation routine. When the library needs memory, it calls the function, and if it is not set, it relies on its own internal routines.

This immediately caught my attention. If we can find the address of this callback inside a remote process we can use it to execute code next time DNS library asks for memory.

This is the memory allocation function used by DnsQuery_* functions (32-bit):

Under normal circumstances finding callback pointers in a remote process memory is quite hard and noisy (lots of ReadProcessMemory calls, possible disassembling). Unless of course there is an interface we can use to surgically target some specific callback (e.g. using documented windows messages, or SetProp function). As far as I can tell there is no such interface in our case.

I found a surrogate solution that we can try to exploit though.

When I looked at references to the callback function (which I named fnMemAlloc on the listing above) I discovered a exported function called DnsApiHeapReset. It takes 3 arguments and each of them is … a callback replacement:

I quickly analyzed each callback’s role and they just are 3 basic/core memory allocation/reallocation/release primitives.

So…

If we can locate the address of dnsapi.dll in a remote process (easy), find the address of exported DnsApiHeapReset function (easy), then with a basic parsing of its code we can discover the address of each callback (also easy). Then, with a single, surgical WriteProcessMemory call we can modify any of them.

This is not a new code injection trick. It’s just one way to execute code without engaging remote threads, APCs, windows hooks, side-loading, process hollowing, patching API code (e.g. NtClose), etc..

There are of course tons of other callbacks like this, but finding their exact location without any point of reference is hard. Or… not really. Just think of all the Windows Procedures – all of them are callbacks.