Lots of research that concentrates on living off the land techniques focuses on finding legitimate OS binaries (both EXE and DLLs) that allow to:

load unsigned DLLs by the signed EXE files,

load code in an unexpected, unconventional way using phantom DLLs, sideloaded DLLs,

use native OS tools and abuse their functionality to download and upload files, maintain persistence, convert data, etc.,

break the process tree, and

many more.

Here, I propose to take it to a possible next, or at least parallel level.

If you are familiar with the ROP gadgets you know that it relies on re-using pieces of code belonging to loaded libraries already present in memory. These are used to chain together code blocks that may execute code of attackers’ choice. By its sole nature ROP is a complex beast and while it can be, and is now fully automated, it most of the time relies on the fact that the final piece of code is just a regular payload that the ROP chain transfer the control to…

I was wondering if it would be possible to re-use the ROP idea on a file-system level and build a library of high-level gadget-like signed executables and DLLs that could deliver the payload-like functionality, or at least its core building blocks. That would not only reduce the need to write the actual payload code – it would basically transfer the responsibility for the core functionality required by the attackers to signed libraries!

If it sounds weird, or complicated, let’s think for a second about existing installers. They implement and provide functionality that every single piece of malware needs: spawn processes, read file, write files, copying, downloading, uploading, same with the Registry operations, and more.

The installers have been abused by malware for a very long time, so it’s just a trivial example. I was thinking of something a little bit more refined and stealthy. Consider an example like this: a malicious document executes a macro; the macro drops a clean, signed executable produced by a well-known company – a file that not a single security solution can detect as malicious. It then instruments that signed executable to do all the dirty work. The chances are high that it would possibly bypass antivirus solutions, EDR, sandboxes and who knows, maybe even the Holy Grail – the whitelisting solutions.

Now that I formulated the idea in my head it was time to do some legwork…

I kicked off a number of searches within my files repository. After some poking around, eyeballing some code, a number of failed attempts I finally got lucky and hit the jackpot. To my surprise, I found a number of really interesting potentials!

The first interesting reusigned binary I came across is described below.

The nvuhda.exe and nvuhda6.exe are NVIDIA Uninstallers for 32- and 64-bit. When you execute them from a command line you will see the following screen:

The list of commands is shown below:

AddUninstall, Call, CheckPath, CheckRAID, ClassSweep, Copy, CopyV, CreateDevice, CreateShortcut, Del, DelBoot, DelBootQuiet, DelIniIfMatched, DelOemInfs, DelReg, DelRegE, DirAndApply, Echo, EnumDevices, EnumRegCmd, EnumRegNamesCmd, Eval, FindOEMInf, GetDrivePort, GetFolderPath, GetInfGUID, GetReg, Help, If, InstallDriver, InstallDriverEx, KillApp, RemoveDevice, Run, RunOnce, SendMessage, Set, SetEnv, SetReg, Sleep, Splash, StartLogging, StopLogging, SysCallAndWait, System, UnifyUninst, Uninstall, UnInstallEx, UninstallGUI, UninstallService, WaitOnRegDel

Hmm some of them look really interesting.

Using the ‘Help’ command we can retrieve more information about the commands:

We can run a few tests:

nvuhda6.exe System calc.exe spawns the Calculator

nvuhda6.exe Copy test.txt,test-2.txt copies ‘test.txt’ to ‘test-2.txt’

nvuhda6.exe SetReg HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\malware=malware.exe adds a persistence key

nvuhda6.exe CreateShortcut test.lnk,"Test","c:\windows\system32\calc.exe","","c:\windows\system32" creates a shortcut file ‘test.lnk’ pointing to calculator

nvuhda6.exe KillApp calculator.exe kills the instances of ‘calculator.exe’ process

and so on and and so forth, and finally

nvuhda6.exe Run foo will run commands from the file ‘foo’ (where commands are from the list above; it’s basically an install script)



It’s pretty much a Swiss-Army tool for doing a lot of legitimate operations on the system, but it could be certainly abused. The only issue is the UAC, because the file required Admin privileges in its manifest.

And… last, but not least – here’s the full list of commands: