This is a quick blurb about idea I shared on Twitter today.

When you create a child process system calls a combo of these two functions:

• NtAllocateVirtualMemory
• NtWriteVirtualMemory

One could intercept these calls (using a hardware breakpoint, patching, or even tracing), and when memory buffer is allocated, extend the allocation size literally creating a code/data cave. Then when the writing is done, build a buffer that will contain the original data meant to be written & appended buffer e.g. shellcode that will fill-in the cave.

Now it’s only a matter of executing the code, which could be done using GUI-based tricks (e.g. Propagate, or common windows callback procedures).

Note: the APIs may need to be changed on 64-bit system if the parent and child process are mixed architecture (NtWow64AllocateVirtualMemory64 & NtWow64WriteVirtualMemory64).

This is just a blurb for an idea that I posted on Twitter today. I have not figured it out yet per se, but just jotting down notes.

Programs reading command line by design as well as software offering assistive technology offer an interesting opportunity to inject stuff into their process via reverse data injection. That is, the sole nature of them reading data from other processes will copy for us buffer we feed to them. Then just need to find out what is the address of that buffer & execute it (the latter is harder part).

As I was testing how popular methods of listing processes and command line retrieval work I noticed some inconsistencies in the way various programs report the results. The following list the preliminary findings:

Process list tools show command line buffer program started with

• Tasklist /v
• WMIC path win32_process
• Get-Process – doesn’t show command line line! need to use Get-WmiObject
• Taskmgr.exe

Process list tools show command line buffer program modified after start:

• Process Hacker
• Process Explorer (truncated to first Unicode null character)

This is not a huge difference, but in the instance of Process Hacker and Process Explorer you could use the fact they read the most up to date buffer content to e.g. transmit data in chunks, plus you don’t need to feed the logs with shellcode passed as a command line (i.e. can change command line buffer in memory, and only after child program is launched).

With regards to assistive technology, I covered it in the past. Their under the hood secrets rely heavily on ReadProcessMemory function that is reading data from other controls, hence you could feed a shellcode this way to a UI automation software.