You are browsing the archive for Reusigned Binaries.

Bring your own lolbas?

July 5, 2019 in Living off the land, LOLBins, Reusigned Binaries

Recently, I was wondering what is the best term for binaries/scripts that are signed, can do the Lolbas thing, but are not necessarily installed on the system.

So far I have been covering many of these using a generic term ‘Re-usigned binaries’ (portmanteau of ‘reuse’ and ‘signed’). But it’s not catchy enough. Could a better term be ‘Bring your own lolbas/lolbin’? BYOL? Kinda similar to Bring Your Own Vulnerability (BYOV)? In fact a BYOL is a subset of BYOV.

I have covered many BYOL examples before. And I believe there will be a lot more in the future. After a very fertile research period lolbin fans explored most of the native OS executables, DLLs, scripts. It’s a natural course of events that their eyes will eventually turn to the other stuff.

The other stuff can be e.g. 7Zip program signed by legitimate companies. @Oddvarmoe posted about it on Twitter in April:

It triggered my interest and I set on a path to discover more instances of various 7zip components signed by legitimate companies. The results of a very basic research are very promising: there are plenty of these:

  • ASUSTeK Computer Inc.
  • HUAWEI Technologies Co., Ltd.
  • NVIDIA Corporation
  • Samsung Electronics CO., LTD.
  • Trend Micro, Inc.

I won’t be posting hashes, because… well… why burning them… The other less obvious bit is that these signed components are often old and could contain unpatched vulnerabilities as well.

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.