Category Archives: Random ideas

Inserting data into other processes’ address space

Posted on by

Code Injection almost always requires some sort of direct inter-process communication to inject the payload. Typically, the injecting process will first plant the shellcode inside other process’ address space, and then will attempt to trigger the execution of that code via remote thread, APC, patching (e.g. of NtClose function), or one of many recently described code execution tricks, etc..

There are obviously other more friendly alternatives, but mainly focused on loading a DLL in a forced/manipulated way (e.g. using LOLBIN techniques, phantom DLL loading, side-loading /OS bugs, plugX etc./, API trickery, etc.).

Over last few months I had discussions with many malware analysts and vulnerability researchers about various code/data injection tricks… This post is trying to give a very high level summary of available data injection tricks. Yes, the WriteProcessMemory and NtWriteVirtualMemory are not enough anymore (obviously!) but they are not the only option either…

Note here that actual code execution is a different story and not always possible. And actually, it is most of the time not even possible, but in this post we don’t care. This post is focusing primarily on ‘what-if’ scenarios… not all of them have to be successful.

Okay, for the lack of a better incentive… just think of injecting EICAR string into other processes just to see how the existing/running AV / EDR will react.

Curious? I sure am !

And if you need an immediate example – look at this post. We can instrument csrss.exe to receive any data we want by triggering the hard error with… a message a.k.a. data we fully control. We don’t even need to craft a dedicated file – we could simply call the NtRaiseHardError API with appropriate arguments…

Anyways… let’s come back to the data injection.

When we start thinking of possible injection avenues they are all over the place… Well… many articles were written about interprocess communication (IPC) and this is the first place where we can look at what’s available. As per the MS article, the most popular IPC mechanisms are:

  • Clipboard
  • COM
  • Data Copy
  • DDE
  • File Mapping
  • Mailslots
  • Pipes
  • RPC
  • Windows Sockets

But there is more…

For example, if you spawn a child process, you can pass data to it via the command line argument or via the environment block – this is because you can control these buffers 100% – you are the (bad) parent process after all!.

The command line-as-a-code-inject trick is something I saw many years ago (at least 12!) so it’s definitely not my original idea. For the second technique I am not sure there is any PoC, but for it to succeed, the environment block requires the data/code to be in a textual form with series of string=value pairs. Yes, actual environment variables and their values, or lookalikes. As with everything, there is already an existing body of knowledge to address that last bit e.g. English Shellcode (PDF warning) from Johns Hopkins University.

There is also an undocumented way to pass data to a child process via STARTUPINFO structure. See this post for more details.

For GUI applications, there are windows messages and their wrappers (e.g. SetWindowText, but also specific control messages e.g. WM_SETTEXT), and common control-specific messages (not covered here in detail); there are also windows properties (SetProp), specific commands to add/remove items from menus, etc.

Then there is a good old clipboard, Accessibility functions, WM_COPYDATA message, and many interfaces allowing remote programs to access some of the application data – often using some legacy method (e.g. IWebBrowser2, DDE). We can also play with resources and modify them, where applicable e.g. with MUI file poisoning nothing stops us from injecting extra data to signed processes using resources tweaked to our needs!

In some cases Registry Entries or configuration files (.ini, but also proprietary files) could work too – especially these that are always used by the target application and accessed/refreshed often (e.g. wincmd.ini for Total Commander). Anytime the program loads these settings/registry values they will be loaded somewhere into program memory (the data doesn’t even need to be correct all the time as long as it is being read by the target application and is stored in memory, even if temporarilyy).

Small shellcodes could replace Registry settings, in particular strings, paths and data ‘guaranteed’ to be available immediately, or almost immediately (f.ex. the MRU list), etc. Depending on how the target application stores/uses that data (locally, on stack, or globally in some non-volatile memory area) it could remain persistent for a while. And in some cases, e.g. with text editors, spreadsheets, files could be loaded anytime the application is re-launched. Data/code could be stored in templates, highlighting files, scripts, etc.

It’s very vague, of course, but it’s not hard to find locations that could be interesting e.g. for Regedit you could use its bookmarking area (HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Applets\Regedit\Favorites) to inject some data into that process. For Ultraedit you could look at Highlighting files, wincmd.ini is a great target for Total Commander, etc.

Registry settings are very interesting in general. What if e.g. we created a fake font, installed it on a targeted system and then made sure that it is loaded as a default for cmd.exe or powershell.exe terminal windows? The font could be a copy of one of the standard fonts, but additionally include some extra data ? What about a corporate wallpaper that could be slightly modified and include a small shell-code that would be always loaded to memory after logon (some consideration for bitmap storage format in memory is needed for this case, but it’s trivial given the number of device context- and bitmap-related functions offered by GDI).

Then we have address books for various programs, templates, databases (e.g. SQLITE3 in so many applications), backup files, icons, cursors, pictures, animations, and so on and so forth. If any of these can be loaded to memory by default, it is a possible place to inject whatever we want.

Then there are trivial cases: for example Notepad loading a binary file into its window won’t make sense as we will see the corrupted garbage, but we only care about what’s in memory, not what’s displayed on GUI; if the binary resides in memory for a while, then it could be used as a data/code storage (i.e. shellcode could be loaded into Notepad memory directly via command line argument, from a file; also, as mentioned above the shellcode could appear as a typical English text so there is no issues with encoding/code mapping).

This can go and on…

Many of these leave a lot of forensic traces in memory, of course, but I believe they will become harder and harder to pinpoint using traditional DFIR methods.

The truth is that data sharing (read: injection) is actually a BIG part of native Windows architecture. While I focused on trivial cases, let’s not forget about many others to which I already alluded earlier: shared memory sections, pipes, sockets, IOCTLs accepting incorrect buffers, and many other interprocess communication methods – they all will sooner or later be abused one way or another. Living Off the land. Bring Your Own Vulnerability. Bring Your Own Lolbin. Blend in.

IMHO abusing the Native Architecture and signed executables and drivers is going to be something we will see more on regular basis. As usual, seasoned vulnerability researchers and companies focused on finding  escalation of privileges, and local/remote code execution bugs pave this road for many years, but it’s only now gaining its momentum…

So, yes… IMHO from a defense perspective it’s a battle already lost.

Let’s hope AV and EDRs will focus more on plain-vanilla Data Injection trickery soon…

Or we all succumb to a completely new Windows paradigm — apps. No more hacking, no more reversing, just a controlled, sandboxed, “telemetrized” environment and… the end of some era… a better one than the one that follows… at least, IMHO

Poisoning MUI files

Posted on by

In one of my older posts about persistence tricks I described a mechanism relying on a modification of MUI files. The idea was that if you could change a string inside a MUI file – a string so specific that is actually directly passed to one of the program executing functions (e.g. ShellExecute) during program run-time – you could achieve some sort of persistence. The idea is kinda OK, but the real world renders it completely useless. It’s just really hard to find programs that match the criteria…

There is one more interesting bit you can do with MUI files tho.

If you copy Notepad.exe and its associated En-Us\notepad.exe.mui file to a different directory, you now have an environment where you can launch a signed OS binary with its MUI file under your control. The MUI file is signed too, but this fact doesn’t seem to be checked during the program execution. So, we can play around with it.

My first test was a simple change to the way Notepad shows ‘working’ file name in its title. The original resource string:

  • %1 – Notepad

refers to a placeholder ‘%1’ (file name), followed by a hyphen, and then comes the ‘Notepad’ string. We are of course very familiar with this template being rendered into something like this:

When you open a file, or Save content of your Notepad window that ‘Untitled’ part in the title will be replaced by an actual file name.

Coming back to the resource strings – as mentioned earlier, the ‘%1’ refers to an argument that is replaced by a ‘working’ file name by program during its run-time. Could we add more arguments?

To test it, I changed that template string into:

  • %1 %2 %3 – Notepad

– assuming that program will fetch additional arguments from its stack while it renders the title of the main window. This indeed occurs and when I relaunched Notepad I immediately got this ‘corrupted’ title window:

A-ha. This is a good sign. We now know that can modify the MUI file and cause Notepad to misbehave.

This finding opens doors to a possible more systematic research on a controlled modification of MUI strings to force programs to behave erratically, or crash, at least. And who knows, maybe in some instances also to controlled code execution, or signed OS binary acting as a lolbin.

The latter is actually not that far from our reach. If you can find a signed program that fetches URL directly from MUI file and either opens it directly via an API, or places it on its UI so that it can be clicked you can easily swap that URL with a link to a local ‘badguy’ file (e.g. ‘file://c:/test/badguy.exe’). Launching the program, and/or clicking the link will ‘lolbinexecute’ the badguy.exe. The interaction is required, but the proxied execution via a signed OS binary is achieved.

A quick query over the default Windows install highlights some candidates (.exe.mui files with references to ‘http’ strings), but I couldn’t find any that would be easy to use as a demo. Oh well.. Maybe the technique is not that interesting after all ?

BUT

There is one more thing we can do with it. Since we know that we can insert anything we want into a MUI file, what about we smuggle in some payload into a memory space of a signed .exe? The signed .exe will have this payload embedded and present in memory immediately after launch. No need for WriteProcessMemory.

To test the idea I added an EICAR file to my test Notepad MUI file. After launching the .exe and searching for EICAR string in memory I was able to pinpoint it like this:

The memory seems to be PAGE_WRITECOPY protected so it may pose a problem, but at least the data is already there.

There may be other ideas here that I missed.