You are browsing the archive for Anti-Forensics.

Beyond good ol’ Run key, Part 48

October 21, 2016 in Anti-Forensics, Autostart (Persistence), Forensic Analysis, Incident Response, Malware Analysis

I have just updated my very old post about HKLM\SOFTWARE\Microsoft\VBA\Monitors. I discovered its additional ‘properties’ while looking at the VBE (Visual Basic Engine). On the way, I have also discovered that Visual Basic for Application’s old-school IDE allows programmers to create Add-ins. A quick googling followed and I immediately found a number of Addins for VBE – I was actually quite surprised that there are so many!

Seriously, there is a huge interest in it! With all the C, Java, python programmers out there… it would seem that VBA is strong and here to stay…

So, anyway… I didn’t spend much time on it as many programmers already provide good examples of VBE Add-ins, so I will just document where to find the possible persistence entries.

The Add-ins are discovered by VBE by enumeration of the following key:

  • HKCU\Software\Microsoft\VBA\VBE\6.0\Addins\<AddInName>\…

Each Add-in has a dedicated subkey where it lists the properties:

  • Description – Full description
  • FriendlyName – Short name
  • LoadBehavior – A DWORD that indicates whether the Add-in is loaded at startup (1), is currently unloaded (0)
  • SatelliteDllName + SatelliteDllPath  – references to localized information about the plug-in

So, anyone wanting to load the VBE Add-in needs to set up the Registry key with the aforementioned values, and then create the appropriate entries under HKCR:

  • HKCR\<AddInName>\Clsid = <GUID>
  • HKCR\CLSID\{<GUID>}\InprocServer32 = …

Beyond good ol’ Run key, Part 47

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

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: