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).

Beyond good ol’ Run key, Part 132

This is a very unpromising persistence mechanism relying on environment variables (again).

Combing through OpenSSL source code I came across two variables that it relies on and they are described here:

  • OPENSSL_MODULES – Specifies the directory from which cryptographic providers are loaded.
  • OPENSSL_ENGINES – Specifies the directory from which dynamic engines are loaded

Example of a code excerpt from a signed DLL that is compiled with a support for OPENSSL_MODULES is shown below:

The good news is that most of Windows-based executables and DLLs that are compiled from OpenSSL sources do not have these variables built-in. I have checked my repo and online repositories as well and it looks like there really are not too many of them available (barely a few). Second good news is that even if compiled with support for these variables, they won’t be used unless specific functions of OpenSSL are called. Despite some moderate efforts to produce a POC I couldn’t find any good candidate. As such, using them as a persistence mechanism is a poor choice indeed. Still, worth documenting, as usual.