Beyond good ol’ Run key, Part 110

This is rather short post and it refers to a qt.conf file. If you can find such a file on a system it can be often modified to affect the settings of a Qt framework that is used by some application installed on your system. You may find many occurrences of this file in the environment. Not all the programs respect these settings though.

The change could be redirecting Qt framework to load plugins from a different directory than expected, etc. See the first link that explains the settings stored inside the file.

There are tones of applications leveraging Qt and actually more and more are Enterprise solutions so it’s a kinda unexpected, but still decent persistence mechanism and due to unpredictability of the qt.conf file file location – kinda stealthy.

How to do ‘the bad’ stuff?

This simple config will load plugins from a c:\test path:

[Paths]
Plugins=c:\test

Obviously, real plugins need to be loaded as well so it’s a bit like a path companion type of persistence that needs some housekeeping to make it work.

Beyond good ol’ Run key, Part 109

This is probably the least practical persistence mechanism I came across. This is because as far as I know loading external DLLs into Metro apps requires a lot effort (file need to be signed, have special rights, be included in a manifest, etc. — see the linked post for more details). In other words, it is practically impossible, unless there is some newer research that I missed. And in any case, even if we managed to load that DLL it would end up inside a process space of a low privilege app.

However… always good to document it. Especially that this is about a close cousin of old Office Test key I covered in 2014 & I think it’s my first Metro persistence trick.

When you run the Mail program that is built-in windows 10 you are actually running a Metro app HxOutlook.exe that executes from the following location:

C:\Program Files\WindowsApps\microsoft.windowscommunicationsapps_16005.11425.20190.0_x64__8wekyb3d8bbwe\HxOutlook.exe

If you look at the Process Monitor logs collected during this app start-up you will notice that the app tries to read the following key:

\REGISTRY\…\LocalState\HKEY_CURRENT_USER\Software\Microsoft\Office Test\Special\PerfImm

Of course, when I saw it, I immediately thought of my old post, because the key name looks so similar.

Now, the Registry entry shown above may be a bit confusing. It is HKCU location, but since this is a Metro app you won’t find these entries inside your user hive. Instead, you will need to look for a small, app-dedicated hive placed in the following location:

c:\Users\<user>\AppData\Local\Packages\microsoft.windowscommunicationsapps_8wekyb3d8bbwe\Settings\settings.dat

The rule of a thumb is that if you see LocalState in a Registry entry, it means it’s a app hive.

In order to modify it, you need to:

  • kill all the processes that access this hive file first (e.g. HxOutlook.exe process); otherwise you will get access denied errors
  • use reg load command to attach it to HCU or HKLM hive
  • from there, you can navigate to the appropriate Office Test location via Regedit
  • modify the entry
  • run reg unload to save the changes to the settings.dat file

It’s actually a very straightforward process.

Okay. Once I did it I re-run the program and discovered what value the program is actually looking for is this:

EnableCodeMarkerCallback

If this value is set, the program will try to load the following library:

appcodemarkerimm.dll

The library is loaded via LoadPackagedLibrary API, and then the program tries to resolve a bunch of functions exported by this library:

  • GetPerfhostHookVersion
  • InitPerf
  • PerfCodeMarker
  • InitPerf_v3
  • PerfCodeMarker_v3
  • UnInitPerf_v3

I have not implemented a PoC, because of the issues I mentioned earlier, and it doesn’t seem to be worth trying it at all, but it’s an interesting curiosity nevertheless…

And there is a little bit more…

By looking for instances of appcodemarkerimm inside all files in the HxOutlook directory, I came across a few more ‘potentials’ e.g. Spy.dll and XamlSpy.dll referenced by a number of libraries. These two are not present so probably are also a part of a testing suite.