Beyond good ol’ Run key, Part 113

This is another one where I just document things that are not commonly known, but _are_ very well documented for years, and defo still worth describing in this series.

While looking at the well-known dbghelp.dll library I noticed that it looks for entries under:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\KnownManagedDebuggingDlls

These entries are enumerated and then loaded via LoadLibrary

Quick google session followed and I found this awesome post from 2007.

—–Original Message—–
From:
Subject: RE: managed minidump
Auxiliary DLLs are loaded inside of MiniDumpWriteDump when it finds a registered auxiliary DLL for a module in the target process. The lookup is to take the full path of the module and see if there’s a registered auxiliary DLL. You can’t have multiple aux DLLs for a single module path.
—–Original Message—–
From: Junfeng Zhang
Subject: RE: managed minidump
When are auxiliary dlls loaded?
What is the behavior when there are multiple entries under each key?
—–Original Message—–
From:
Subject: RE: managed minidump
Both are filled with string values of the form = . MiniDumpAuxiliaryDlls lists helper DLLs that the minidump code can use to get additional data during dump generation. For example, mscorwks.dll has a registered auxiliary of mscordacwks.dll, which provides extra CLR memory data for a minidump.
KnownManagedDebuggingDlls is a security measure so that a debugger, when attempting to load extra support DLLs for managed debugging, can know what DLLs are approved for use on the system. The CLR registers mscordacwks.dll here, for example.
Both are kept in HKLM so that they can only be written by an admin.
—–Original Message—–
From: Junfeng Zhang
Subject: managed minidump
How does OS use the following two registry keys?
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MiniDumpAuxiliaryDlls
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\KnownManagedDebuggingDlls

As you see, not only KnownManagedDebuggingDlls, but also MiniDumpAuxiliaryDlls branch is of value for threat hunters.

Beyond good ol’ Run key, Part 112

This is a pretty ancient persistence trick one can use on systems where IBM’s Java Control Panel is still present.

On these systems you will find Registry Key:

HKLM\SOFTWARE\IBM\Java2 Runtime Environment\
<version>\

and a Value Name underneath called:

JavaHome = <directory>

By changing this value, one can ensure that next time the Control Panel applet is called, the signed CPL file will launch a bin\javacpl.exe program from this path.

In other words, for the example old version 1.6.0 one could change the value name to this:

HKLM\SOFTWARE\IBM\Java2 Runtime Environment\
1.6.0\JavaHome=c:\test

and then drop a malicious c:\Test\bin\javacpl.exe file.

I have not tested it, but I am pretty sure that changing the value of that variable will definitely affect the way Java works, so things will be probably broken, unless proper links to files are established for all the content residing in the actual JavaHome directory.

Yes, it’s ancient, and probably dead by this time + not worth pursuing, but just documenting… because why not.