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:

LPCWSTR lpFileName
DWORD dwDesiredAccess
DWORD dwShareMode
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?

Comments are closed.