I discussed Winsock-based persistence in the past.

There is one more.

It is a bit unusual, as it has to do with automatic proxy configuration, so it’s a bit tricky to reproduce. I have honestly not made an attempt to fully understand the logic winsock uses to determine how to find the proxy, plus it’s pretty late and I only discovered it now so maybe some other time…

For the purpose of this post, one thing that is interesting is this key:

• HKCR\AutoProxyTypes

The two standard entries underneath are:

• Application/x-internet-signup
• Application/x-ns-proxy-autoconfig

It turns out you can add your own e.g.:

Winsock will enumerate the AutoProxyTypes key children nodes while trying to find the proxy and will load DLLs located underneath.

I had luck reproducing it on Windows 7 while tinkering with the Internet Options/Lan Settings (enabling/disabling it), but could not make it work on Windows 10. I may come back to do some more testing later on, but for now this screenshot should suffice:

Looking for new ways to load code persistently I had a quick glance at Java. While it may not be present on all systems, it’s out there on at least 3 billions devices (so the ad claims).

The first thing that caught my eyes were these nice command line options:

• -agentlib:<agent-lib-name>=<options>
• -agentpath:<path-to-agent>=<options>

The agent library is just a DLL that needs to export an Agent_OnLoad function. I quickly prepared a test DLL with a dummy export and got it to load as shown below:

• java -agentlib:c:\Test\javaagent

• java -agentpath:c:\Test\javaagent.dll

So, the first takeaway is that if there is java.exe on the system, you can use it to load unsigned DLL, same way as xwizards, and tones of other similar tricks from @subtee.

Having a way to load DLL is one thing, being able to load it persistently is another.

This is where JAVA_TOOL_OPTIONS environment variable comes handy.

Once you set it to f.ex.:

set JAVA_TOOL_OPTIONS=-agentpath:c:\Test\javaagent.dll

the library will be loaded anytime java.exe starts.

Obviously, these errors shown on the screenshots is just me being lazy – my dummy library should return appropriate value for the java.exe to be happy about, and so it can actually continue the execution. Ignoring that, the second takeaway is that as long as you make the JAVA_TOOL_OPTIONS variable persistent f.ex. via the Registry:

HKCU\Environment\JAVA_TOOL_OPTIONS=
-agentpath:c:\Test\javaagent.dll

– the library will be loaded anytime java.exe starts.

The JAVA_TOOL_OPTIONS has a few undocumented sibling variables called _JAVA_OPTIONS and IBM_JAVA_OPTIONS as explained here. These can be leveraged as well. The Windows Java version I tested (jre1.8.0_144) refers to _JAVA_OPTIONS during the start-up, so you can add persistence via this Registry entry:

HKCU\Environment\_JAVA_OPTIONS=
-agentpath:c:\Test\javaagent.dll

I have not confirmed the below, but I guess there are other options for toying around with persistence using Java. Looking at the CLI help we can see the following possible avenues for exploration:

• -javaagent:<jarpath>[=<options>] – load Java programming language agent, see java.lang.instrument
• -classpath <class search path of directories and zip/jar files> -fA ; separated list of directories, JAR archives, and ZIP archives to search for class files.
• -Xbootclasspath:<directories and zip/jar files separated by ;> – set search path for bootstrap classes and resources
• -Xbootclasspath/a:<directories and zip/jar files separated by ;> – append to end of bootstrap class path
• -Xbootclasspath/p:<directories and zip/jar files separated by ;> – prepend in front of bootstrap class path

There is also another variable worth looking at: _ALT_JAVA_HOME_DIR. By changing it, you can manipulate the path that Java Virtual Machine uses while it is looking for Java Run-Time Environment. This may open some possibilities for companion virus-like persistence.