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.

This is a bunch of legacy and not so popular anymore Registry locations that could have at some stage in the past support persistence by pointing to various editors associated with ‘viewing source of web pages’, and using Microsoft Office for editing HTML documents:

• HKCU\Software\Microsoft\Shared\HTML\Default Editor
• HKCU\SOFTWARE\Microsoft\Shared\HTML\Old Default Editor
• HKLM\SOFTWARE\Microsoft\Shared\HTML\Old Default Editor
• HKCU\Software\Microsoft\Internet Explorer\Default HTML Editor
• HKCU\Software\Microsoft\Internet Explorer\Default MHTML Editor
• HKLM\Software\Microsoft\Internet Explorer\Default HTML Editor
• HKLM\Software\Microsoft\Internet Explorer\Default MHTML Editor
• HKLM\Software\Wow6432Node\Microsoft\Internet Explorer\Default HTML Editor
• HKLM\Software\Wow6432Node\Microsoft\Internet Explorer\Default MHTML Editor

All the entries use the very same shell entries as shown on the below example: