Beyond good ol’ Run key, Part 104

February 23, 2019 in Anti-Forensics, Autostart (Persistence)

Today’s entry is not about new persistence mechanism, but about a few relatively less known mechanisms that are involved in the Windows startup on newer versions of the OS, and are primarily involved during the user log on process.

Newer versions of Windows completely re-engineered the Task Manager application. I personally detest it, and prefer to use Process Hacker, or Process Explorer, or even command line, but… I guess if all this fancy, detail-hiding stuff in newer Windows versions means some sort of progress (tablets-centric interface, and laptops will die), then it means I am probably the old-fashioned problem here… and I currently solve it by using proper old-school tools 🙂


As much as I hate new Task Manager in win8/win10, I have to look at what it does, even if it’s just from a ‘curiosity’ perspective – one that focuses on forensics artifacts it creates, and various ways we can abuse these new ‘features’…

One of the less known Registry entries utilized by the standard ‘startup’ routine (i.e. the one that is primarily driven by Windows Explorer e.g. Run, RunOnce keys, Startup folder, etc.), after the userinit.exe finishes its work, are these three locations in the Registry:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\<entries>
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\SessionInfo\1\RunStuffHasBeenRun
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\SessionInfo\1\StartupHasBeenRun

For the first one, the <entries> refer to ‘standard’ startup entries like Run Key, Startup folder, etc.. This key is populated by Task Manager/Startup tab when we enable/disable entries:

Some people claim it is already abused by malware, but I have not tested it.

We can use Procmon to track this activity e.g. for 3 Run entries we can see this enumeration and each entry is checked against the StartupApproved list:

For the second entry… when I searched for it online, I quickly discovered that it seems to be really old and was discussed many times. For example, one of the older twits from @swiftonsecurity mentions it (in 2014!).

What is its meaning though?

Basically, if the value is not set, it is set when Explorer starts (note that it is for a specific session registry node for which the function SHCreateSessionKey opens a dedicated volatile Registry entry created during logon by userinit.exe). It then guards the repetitive execution of most of the legacy autostart and Registry startup entries.

For the third entry, it’s very similar to the second one, it just guards a different set of startup execution. If the entry exists, it prevents the Startup folders from being enumerated over and over again for a given session.

I think the primary reasons for these two entries is to prevent recurring execution of programs that are meant to execute during logon, but should not execute when e.g. Windows Explorer crashes and is restarted, or perhaps when sessions flips between interactive (user with a direct access to the box), and Terminal session/RDP (? need to test if userinit creates separate sessions for this; may depend on the licenses stipulating number of concurrent sessions available). There may be other scenarios(?).

Since we talk about things happening around startup, I want to refer to a more recent discovery that I already briefly discussed on this blog, and which has been discovered by Samir (kudos!). Thanks to his analysis we can now track execution of at least some of the autostart entries. We can do so by looking at Microsoft-Windows-Shell-Core/Operational logs and its 9707/9708 events.

Last, but not least, if you see Registry entries, or folders named AutorunsDisabled you will of course know these have been ‘imprisoned’ by someone using Autoruns and ticking off some entries.

Now… for the bonus part…

When we talk about startup locations, it’s easy to forget that all of them are executed in a sequence. For example, as a part of this sequence, Windows Explorer enumerates and executes Run keys first, only then it executes stuff from the Startup folders. With that knowledge it is possible to create a number of artifacts that are clean, perhaps even volatile (only exist during the start-up process). Autoruns and other tools will see bogus entries, or entries that on their own look non-malicious. One could use Run keys to create a new file on the system, which in turn could be executed by the shell:startup folder from a .lnk file pointing to the non-existing file (more precisely, file that only exists during startup, and is then deleted – see next sentence). After that, the temporarily file could be deleted by another startup entry. I think race conditions like this could be an interesting development in the future.

Finally, one more entry to look at:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Serialize\StartupDelayInMSec

The default value is 10000 ms. The max value is 3600000 ms. When changed, it affects how long the OS will wait for the ‘standard’ startup entries to execute. Many optimizing guides suggest changes to this registry entry (making it 0 removes all the delays).

Comments are closed.