Rundll32 and Phantom DLL lolbins

This may be a new, kinda ephemereal addition to the lolbin world (not sure if anyone covered it before).

Windows 11 comes with a large number of DLLs – some of which are broken.

DuCsps.dll on Windows 11 Pro 22H2

The DuCsps.dll imports 2 APIs from UpdateAPI.dll:

  • GetInstalledPackageInfo, and
  • FreeInstalledPackageInfo.

The problem is that there is no UpdateAPI.dll. It may be present in other versions of Windows, but it’s not present in 22H2 (note: I have not tested all the subversions, so YMMV).

tssrvlic.dll on Windows 11 Pro 22H2

The same goes for tssrvlic.dll that imports 3 APIs from a non-existing TlsBrand.dll:

  • RDSGetProductAccessRights,
  • W2K3ADPUCALDetailsCreator, and
  • RDSProductDetailsCreator

They both create a lolbin opportunity via a missing phantom DLL, and an attacker can simply bring in their versions of malicious UpdateAPI.dll or TlsBrand.dll, and then run (from the same directory where these payloads are located) the following rundll32 commands:

rundll32 DuCsps.dll, foo

rundll32 tssrvlic.dll, bar

where foo and bar can be anything.

See below:

Beyond good ol’ Run key, Part 133

Java programs compiled into executable form using launch4j have a few interesting features that make them a good target for both persistence and LOLBIN-ish activities.

When the executable starts it checks the environment for a presence of Java Runtime Environment (JRE) and while doing so it is checking a number of locations:

  • 64-bit search: HKLM\SOFTWARE\JavaSoft\Java Runtime Environment
  • 32-bit search: HKLM\SOFTWARE\JavaSoft\Java Runtime Environment
  • 64-bit search: HKLM\SOFTWARE\JavaSoft\Java Development Kit
  • 32-bit search: HKLM\SOFTWARE\JavaSoft\Java Development Kit
  • 64-bit search: HKLM\SOFTWARE\JavaSoft\JRE
  • 32-bit search: HKLM\SOFTWARE\JavaSoft\JRE
  • 64-bit search: HKLM\SOFTWARE\JavaSoft\JDK
  • 32-bit search: HKLM\SOFTWARE\JavaSoft\JDK
  • 64-bit search: HKLM\SOFTWARE\IBM\Java Runtime Environment
  • 32-bit search: HKLM\SOFTWARE\IBM\Java Runtime Environment
  • 64-bit search: HKLM\SOFTWARE\IBM\Java2 Runtime Environment
  • 32-bit search: HKLM\SOFTWARE\IBM\Java2 Runtime Environment
  • 64-bit search: HKLM\SOFTWARE\IBM\Java Development Kit
  • 32-bit search: HKLM\SOFTWARE\IBM\Java Development Kit

The JAVA_HOME environment variable is not being used.

Placing malicious entry under any of these branches e.g.:

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.8]
"JavaHome"="c:\test"

and then dropping malicious c:\test\jre\bin\javaw.exe will cause the original program compiled with launch4j 9when launched) to spawn that malicious javaw.exe.

And as a little bonus, the stub of launch4j accepts these debug command line arguments (or uses equivalent values of environment variables shown in parenthesis):

  • –l4j-debug (or Launch4j=*debug*)
  • –l4j-debug-all (or Launch4j=*debug-all*)

When any of these two are present a launch4j.log log file will be created with all the information needed for troubleshooting (the second option generating more verbose version of the log file).