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

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.