You are browsing the archive for Reusigned Binaries.

Re-usigned binaries: NVFBC Screen & Video Capture library

June 7, 2019 in Living off the land, LOLBins, Malware Analysis, Reusigned Binaries, Silly

Traditional screen grabbing malware uses a bunch of GDI APIs: CreateDC, CreateCompatibleDC, CreateCompatibleBitmap, BitBlt. It may also use GDI+ to save screenshots as JPEG, GIF, PNG, etc. There are plenty of code examples online that demonstrate how to do it. Now, it turns out that the very same functionality can be programmed via existing and pretty convenient wrapper libraries that are offered by some of the GFX card vendors.

While poking around NVIDIA files I came across a very intriguing document NVIDIA Capture SDK Programming Guide [PDF Warning]. It describes a set of functions that help to capture screen/video snapshots using a NVIDIA helper library called NVFBC (or NVFBC64 on 64-bit systems). There is also an accompanying document called NVIDIA Capture Sdk Sample Descriptions [PDF Warning] that introduces samples that utilize NVIDIA SDK to do some screen/video capture work.

For instance, NvFBCToSys demonstrates how to use the NvFBCToSys interface to copy the desktop into a system memory buffer and save it as a file. The DX9/DX10/DX11/GL IFR SimpleSample targets DirectX 9, 10, 11, and OpenGL to capture and render target to a file. The DX9IFRSimpleHWEncode
captures a renders target, compresses it, and write it to a video file. Googling around it’s easy to find more samples with a similar code.

So, again, by introducing a signed proxy library one can deliver a desired functionality and potentially evade some of the security tools. Imagine reading and writing files via Java library, taking screenshots via NVFBC library, and utilizing other legitimate libraries for other purposes. You end up with a Frankenstein’s monster, but one that may be harder and harder to distinguish from a legitimate software.

Re-usigned binaries: Java’s nio.dll as a proxy for Windows API

June 6, 2019 in Living off the land, LOLBins, Malware Analysis, Reusigned Binaries, Silly

This is a very silly idea, but it intends to be more a food for a thought than anything else. I mentioned before that signed binaries can be used to do almost anything. All we have to do is to find them and… instrument them.

The below is an example of such binary, courtesy of Java.

Browsing through function names exported by Java libraries I came across a very interesting pattern. One of the libraries nio.dll includes a very interesting set of function names, e.g.:

  • _Java_sun_nio_fs_WindowsNativeDispatcher_BackupRead0@44
  • _Java_sun_nio_fs_WindowsNativeDispatcher_BackupSeek@32
  • _Java_sun_nio_fs_WindowsNativeDispatcher_CloseHandle@16
  • _Java_sun_nio_fs_WindowsNativeDispatcher_CopyFileEx0@36
  • _Java_sun_nio_fs_WindowsNativeDispatcher_CreateDirectory0@24
  • _Java_sun_nio_fs_WindowsNativeDispatcher_CreateFile0@40
  • _Java_sun_nio_fs_WindowsNativeDispatcher_CreateHardLink0@24
  • _Java_sun_nio_fs_WindowsNativeDispatcher_DeleteFile0@16
  • _Java_sun_nio_fs_WindowsNativeDispatcher_DuplicateTokenEx@20
  • _Java_sun_nio_fs_WindowsNativeDispatcher_FindClose@16
  • _Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0@20
  • _Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile1@24
  • _Java_sun_nio_ch_Net_socket0@20
  • _Java_sun_nio_ch_Net_listen@16
  • _Java_sun_nio_ch_Net_connect0@24
  • etc. (170+ functions total)

Curious, I inspected code of some functions, and quickly discovered that these are just wrappers for your regular Windows API. And since they are we can use them to do Windows API stuff for us.

I quickly coded a simple example that uses:

  • _Java_sun_nio_fs_WindowsNativeDispatcher_CreateFile0

to create a test.txt file. The prototype for the function was slightly different than the CreateFile one, but it’s easy to map them with IDA:

a0=0
a1=0
LPCWSTR lpFileName
a4=0
DWORD dwDesiredAccess
DWORD dwShareMode
LPSECURITY_ATTRIBUTES lpSecurityAttributes
a8=0
DWORD dwCreationDisposition
DWORD dwFlagsAndAttributes
HANDLE hTemplateFile --> ignored

It’s a basic stuff, but since it works, it’s easy to imagine proxying most of available operations via these functions.

One may ask – what would be a purpose of such silly maneuver ?

When you call CreateFile from your code it is from within the image of a .exe file (after it is launched). In other words – it’s a direct call from the program. If a PE file this program was loaded from is unsigned it is going to hit a radar of any security solution that keeps an eye on these things. Many of them progressed from simple API monitors to be more context-aware. They may attempt to interpret a flow of events (sequence of API calls + their context), and remove parts of the reports that may be superfluous. All they have to do is look at the stack, retrieve the return address of the API call and see within boundaries of which code it was called from.

In one of my older posts I described it in more detail and insisted that removing trace of unimportant, in-between calls from the logs in sandbox reports is an important step that improves the readability of the code flow. This doesn’t work all the time, and this post is just one of many examples that may help to fool such ‘readability-oriented report wrappers’.

Since APIs called from an unsigned program may get a much higher risk score than the very same API called from within a trusted code we can try to change the odds.

We can think of libraries like nio.dll as of an API proxy. Proxying calls via a signed library may change the detection odds.

Last, but not least – with code proxy comes great responsibility. As such, the test program is dependent on a couple of Java DLLs (because nio.dll depends on them):

  • java.dll
  • jvm.dll
  • net.dll
  • nio.dll
  • verify.dll

While unintended, such loaded signed DLLs may actually add more credibility to the process. Programs that load signed libraries only cannot be bad, right?