Category Archives: Autostart (Persistence)

Debug Environment Variable are \o/

Posted on by

Looking at the list of debug environment variables one can immediately spot a lot of room for abuse.

One can hypothesize that setting e.g. _NT_SYMBOL_PATH, _NT_ALT_SYMBOL_PATH, _NT_SYMBOL_PROXY, SRCSRV_INI_FILE to point to a malicious server will ensure that next time OS or any application tries to reach out to Symbol server, it will actually ping the malicious server first. It could be a nice semi-covert channel to communicate with C2. Moreso, if executed via proxy e.g. via existing software (ideally OS or some coding components) e.g. Windows Error Reporting (WEFault.exe), debuggers (windbg, cdb), sysinternals tools (ProcMon), and other reversing tools (IDA), etc – the fact it’s the good guys calling out may help to hide the activity from prying eyes of EDR/AV.

Other ideas can circle around abusing paths e.g. _NT_DEBUGGER_EXTENSION_PATH and WINDBG_INVOKE_EDITOR to use them both as a persistence method and/or for LOLBIN purposes.

In my tests, not all tools obey these environment variables so YMMV.

Beyond good ol’ Run key, Part 133

Posted on by

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