Beyond good ol’ Run key, Part 47

September 29, 2016 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

Update 2018-10-09

It looks like some of the entries also include ..\IdentityStore\Providers\DLLPath value name that could be abused for persistence.

Old Post

The persistence mechanism that I am going to describe today is not for the faint-hearted.

When Windows 10 starts, lsass.exe loads Authentication Packages (AP) from the following registry location:

  • HKLM\SOFTWARE\Microsoft\IdentityStore\Providers

The location contains a number of subkeys that use GUID-based naming convention. The default ones are:

  • {B16898C6-A148-4967-9171-64D755DA8520}
    • ApPluginDLLPath=aadcloudap.dll
  • {D7F9888F-E3FC-49B0-9EA6-A85B5F392A4F}
    • ApPluginDLLPath=MicrosoftAccountCloudAP.dll

It’s tempting to add your own f.ex.



The LoadParameters key must contain the Enabled value name – this ensures the DLL is loaded.

However…. there is a little problem (yet it’s one that is good to have!) – the Microsoft developers had a foresight here and made it quite difficult for anyone to abuse these keys.


The DLLs are loaded using LoadLibraryEx with the LOAD_LIBRARY_SEARCH_SYSTEM32 and  LOAD_LIBRARY_REQUIRE_SIGNED_TARGET options on.

  • This means that the DLL must be placed inside the c:\windows\system32 directory (LOAD_LIBRARY_SEARCH_SYSTEM32).
  • Secondly, the DLL loaded from this location must be signed.
  • Thirdly, the DLL not only must be signed, but also compiled with the /INTEGRITYCHECK option on. This ensures that the Kernel-Mode Code Signing (KMCS) checks are enforced.

Finally, the Registry key is owned by Trustedinstaller. One needs to change the owner to modify the access rights and grant the permissions to add/modify the keys.

Practical aspects of it mean that it’s relatively hard to test it (I may describe how to do it later).

Here’s an example from the test system:


Comments are closed.