You are browsing the archive for EDR.

‘Plata o plomo’ code injections/execution tricks

May 26, 2019 in Anti-*, Anti-Forensics, Archaeology, Code Injection, EDR, Living off the land, Malware Analysis, Reusigned Binaries

This post is not about a single injection. It is about a class on its own.

At the moment I know of only two instances of code injection/execution that fit this category perfectly, and I am going to describe them below, but I bet there is more…

First of all, why ‘plata o plomo’? It’s obvious. In today’s world every security research needs a cheezy name ;), right?. Secondly, the ‘plata o plomo’ fits the cases perfectly – it’s ‘either silver, or lead’. And when it comes to code injection/execution – it’s definitely a lead. Or Ulead.

Okay. What about the actual ‘code injection/execution’ bit?

This Endgame post presents a very comprehensive overview of what was out there back when it was written in 2017. It’s a great starter for anyone interested in this topic. However, many things have changed since it was posted + the article omitted a number of interesting techniques anyway.

The below is a summary of all existing code injection tricks that I know/could think of (ping me if I missed anything):

Notably, the last few links on the list above are leading to modexp.wordpress.com blog. After reading it for a while, and talking to author on a couple of occasions, and finally eyeballing the github repo associated with posts and older work of the author, I can only bow to this programmer’s coding, and manual code crafting skills! This blog is really high on my list and I highly recommend it!

Anyway… back to the topic of this post:

  • What if I told you… that there are developers our there that make the whole game of code injection extremely easy? No trickery, no code trampolines, no obscure undocumented structures, not even forgotten, legacy code paths, windows shattering, let alone ROP, gadgets to be relied upon. None whatsoever needed.
  • What if I told you that you can just provide an address of the code you want to execute in a nice, user-friendly way ?
  • What if this code actually executed according to your wishes ? In User or Kernel mode.
  • What if I told you the programs facilitating this are signed as well?

In other words: what if code execution/injection was there ‘by design’?

Yes… it’s a mind blowing idea. And yes, as I stated before in my Law Of A Threat Hunter (LOATH):

For every two distant technologies there exist a developer that will bring them together.

So… if you can find such program / driver you get a clean shot at a golden opportunity – a signed process or DLL offering a controlled code execution, and then most likely an AV/EDR bypass. And as I mentioned earlier – there exist at least 2 such applications/kernel drivers that I am aware of that fit this description perfectly, and I bet there are more.

Cuz… if it is signed, then it’s good. Right?

I first heard of Capcom driver from the zerosum0x0 blog (yet another great blog to follow!). The post I linked to introduces a tool called puppetstrings that tries to exploit the vulnerability in a aforementioned capcom driver. The vulnerability is actually supersilly – when you send a special IOCTL request to the capcom driver, it will temporarily disable Supervisor Mode Execution Protection Enable (SNEP) mode, call a callback procedure controlled by the user (in a user address space), then return and restore SNEP state…

How crazy is that? I mean: HOW CRAZY IS THAT ?

When I read about it and the whole concept of ‘Bring Your Own Vulnerability’ (BYOV) for the first time I actually really liked the idea and thought it could be expanded to Bring Your Own Functionality (BYOF). I speculated that there are other applications/drivers that are written in a sloppy way, all for good reasons though – and they may not even need any vulnerability at all! And I finally found my first.

In fairness, I have been actually toying around with the concept of reusigned binaries for a while. Lolbins are easy wins, low-hanging fruits, but there is tones of other legitimate software out there that gives clever users more than the developers meant to. We can re-use signed binaries to give us keylogging capability, kill a process, wipe a drive, spawn a new process if we need it, and modify Registry, install Services, and so on and so forth. Not only it is an interesting area for research – I actually believe that this is an inevitable future of many pentesting or red team engagements, let alone nation attacks. And some of the existing attacks already show that a possession of signed drivers/software that can be used for BYOV/BYOF can be leveraged to bring a lot of havoc – e.g. signed EldoS RawDisk drivers were used by Shamoon to wipe out the orgs’ media.

Welcome the ‘Plata o plomo’ contestant number 2.

Ulead Burn.Now 4.5 is an old app from year 2007 that was used to burn ISOs on CDs/DVDs. Nowadays this feature is not really needed – the whole cloud buzz makes cloud so popular and offers far more space & flexibility that the old (and dying) media burning industry can’t really compare. As far as I can tell this Ulead app is no longer updated, but the beauty of good old is that it is out there.

Now, for the juicy part. Apart from doing what it was meant to, the application (or at least this particular version) includes a very interesting feature (most likely for testing purposes):

  • If you set a specific environment variable to a certain decimal value the app would retrieve it during run-time, convert it into an address, and finally…. make a code jump to that address!

Yes. You hear that right. OMGWTFBBQ. You can literally tell the app to execute your shellcode from a specific location in memory!

Let’s start with a name of that Environment variable:

  • GLOBAL_HOOK_ENVIRONMENT_STRING

In the below demo I set it to 195936478 (0xBADC0DE). and then run the application under Olly to demonstrate when the main program jumps to the 0xBADC0DE location:

You may be concerned about required UI interaction. This is actually not an obstacle. If one was about to use it maliciously, one could engage basic GUI automation techniques to ‘click’ that OK button. It’s actually pretty trivial with available APIs (e.g. FindWindow, or enumeration via EnumChildWindows to find the required window, then sending WM_COMMAND/BN_CLICKED, WM_LBUTTONDOWN, etc messages to the button window).

Also, the name of the environment variable is present in a number of components of this application, including a number of DLLs. As such, there is a high possibility that one could simply instrument these DLLs to execute the shellcode e.g. via a customized DLL loader (provided we injected a shellcode beforehand).

A quick grep for GLOBAL_HOOK_ENVIRONMENT_STRING inside the installation directory (c:\Program Files\Ulead Systems\Ulead Burn.Now 4.5 SE) shows the following list of files that include a reference to it:

  • SH_PEShareComm.dll
  • SH_ObjComm.dll
  • SH_BaseDV.dll
  • PS_UndoManager.dll
  • PS_TextMedia.dll
  • PS_RTObjMgr.dll
  • PS_Register.dll
  • PS_PSShareComm.dll
  • PS_PSPhotoAction.dll
  • PS_PS2SlideShow.dll
  • PS_PS2Base.dll
  • PS_PrintCDCoverCtrl.dll
  • PS_PEShareComm.dll
  • PS_PaperTemplDB.dll
  • PS_PaperTemplCtrl.dll
  • PS_ObjComm.dll
  • PS_MenuTool.dll
  • PS_MediaBase.dll
  • PS_IPEDLL.dll
  • PS_GUIBase.dll
  • PS_CommonControl.dll
  • PS_CDLabelBase.dll
  • PS_AddTextCtrl.dll
  • HDRf.dll
  • Fourier.dll
  • CDLabel.dll

All of them are signed. So it’s almost certain that _some_ of these could be loaded outside of the main program, and then instructed to execute the shellcode.

Coming back to where this post started – when it comes to ‘Plata o plomo’ and code injection – it’s always the lead. Developers make and will make stupid mistakes, they write and will write code that is often meant to be only used internally, but sometimes it will make it out to the releases available to general public, and into signed packages.

The lesson learned is that what is green on VirusTotal is never green from a blue teamer’s perspective. We need a better process (and a long way) to declare things ‘truly green’ for that matter. For a long time now we know that the authenticode signatures are just an ersatz of security and while always useful (better to have them than not to), we should no longer rely on them blindly.

Future attacks will engage signed binaries more. There is no doubt. We need a dedicated team of analysts in every security companies to start looking at vulnerabilities present in these, and also ‘built-in’ features that make the ‘green’ VT stuff vulnerable to abuse. Again, I am more than certain there is a lot of this stuff out there. Only a few weeks ago @Oddvarmoe published his findings about the 7z binary he found that is signed by Nvidia. Any such ‘signed popular tool’ instance is interesting from at last two angles:

  • It is signed+ ‘perceived as good in general’, so may (and most likely will) sneak in through EDR/AV filters
  • if it is old version enough, it may include many interesting vulnerabilities – – some may allow to execute shellcode or do some other funny stuff

As such… the era of Lolbins, BYOV, BYOF will catch many companies off-guard.

Inserting data into other processes’ address space

May 18, 2019 in Anti-*, Anti-Forensics, Code Injection, Compromise Detection, EDR, Random ideas

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