You are browsing the archive for Anti-Forensics.

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:


Beyond good ol’ Run key, Part 46

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

A persistent mechanism that requires a user interaction is probably deemed to fail, but there is still some potential here (I described some functionality like this before) and that’s why I am going to talk about yet another little trick like this here…

Every once in a while Windows needs to tell the user about something important. The standard way to do it is through these annoying balloons at the bottom of the tray’s area (or system area, or whatever they call it nowadays – this changes all the time). One of the first examples of such ‘important’ notification was the Tour in Windows XP. Anytime you install XP from the scratch, or add a new user and that user logs on, the annoying balloon immediately shows up:

tourThe balloons like this are created using the IUserNotification interface. Clicking the ‘cloud’ area executes a program that is associated with the balloon. And this this is the interactivity part I mentioned. The user needs to click the thing to launch the application associated with the message.

Now that we know how the interactive part works, let’s explore the persistence bit.

Windows uses a mechanism called PostBootReminder to preserve a list of important notifications that system will show after the reboot. The name is misleading as these notifications are user-related and stored in the user’s Registry hive. So it’s not really Post Boot, but when Shell is loaded. One just needs to log off and log on again and the thingie will trigger.

Adding PostBootReminder entries is relatively easy. The below reg file is a simple example of such notification:

"Text"="Yet another lame persistence mechanism-wannabe..."
"ToolTip"="Hello World!"

As we can see, the entries are stored under the HKCU key:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\PostBootReminders\<name>

Once the system reads and creates the notification, it deletes the entry. So, in some way it works like a RunOnce key.

The Tour application that is being executed by Windows XP is scheduled the same way, except it is added not prior to reboot/log off, but when Windows Explorer starts. There is a Registry entry:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Applets\Tour\RunCount

that dictates whether the Tour app will get scheduled via PostBootReminders mechanism.

This is obviously a bit of an archaeologic trivia, but I can mention that the name of that PostBootReminders entry is ‘Microsoft.OfferTour’. Of course, being clever reader as you are, you will surely notice that the Tour Registry key, together with a replacement of the Tour program executable (tourstart.exe) could work as a nice persistence mechanism as well (back when replacing files in system32 was easier).

Another trivia to add: there is one more fake PostBootReminders  entry added by Windows Explorer on Windows XP. It is called ‘Microsoft.FixScreenResolution’


and is supposed to help fixing the screen resolution. This entry is controlled by the following Registry key:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\DontShowMeThisDialogAgain\ScreenCheck

The conditions when it is launched are a bit more complex than just a presence/value of the Registry entry and are described in detail here.

Going back to the future – Windows 10 continues to use the very same mechanism. The known PostBootReminders  entries include:

  • Microsoft.AuditingLogIsFull
  • Microsoft.CachedLogon
  • Microsoft.KerbCredentialsExpired
  • Microsoft.LogoffWarning
  • Microsoft.LogonHoursWarning
  • Microsoft.NetDriveReconnectFailed
  • Microsoft.PasswordExpiryWarning
  • Microsoft.SmartCardUnlockRequired
  • Microsoft.SubscriberFailed
  • ProfileError

Going back to the .reg example I posted above – the arguments of the PostBootReminders subkey are passed directly to methods of IUserNotification interface, so their explanation can be easily found by exploring the Microsoft site: Title, Text and TypeFlags, RetryInterval, RetryCount, ShowTime, IconResource, ToolTip. The ShellExecute is just a path to the executable. It is worth mentioning that there is also one more entry that can be added – CLSID – this represents the GUID of the class that will be instantiated if present, but I have not explored it yet and not sure how it works.

As I mentioned, I doubt this thing can fly, but who knows… one could annoy the user, by making the message never go away (hint: RetryCount/RetryInterval), until clicked – same as on the animation below 🙂 [you may need to click to watch]