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 🙂

Anyways…

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).

This is yet another feature of Windows. This time it is a configuration settings for Event Viewer.

When you open the program via eventvr.exe/msc it will launch the mmc.exe which in turn will load an Event Viewer snap-in. The Event Viewer allows to view the system / application logs that we all should be familiar with.

As part of an user experience the Event Viewer offers a clickable Event Log Online Help link:

When the link is clicked, the mmc.exe will open a default help Microsoft link which will be rendered by the currently set up (default) browser.

It turns out that the default setting of this feature can be changed. It is very nicely described here, but the bottom line is that we can launch a program of our choice instead of the default browser; we just need to modify one, or more of the following registry entries:

HKLM\SOFTWARE\Microsoft\Windows NT\
CurrentVersion\Event Viewer\

• MicrosoftRedirectionURL=<url>
• MicrosoftRedirectionProgramCommandLineParameters=<args>
• MicrosoftRedirectionProgram=<program>

The MicrosoftRedirectionURL can be changed to e.g. file://c:\windows\system32\notepad.exe, or MicrosoftRedirectionProgram can point to the executable directly. One can also tinker with the command line parameters e.g. in a combo with a lolbin.

There is one gotcha moment while setting up this thing – there exist Wow6432Node equivalent for these entries, but they don’t seem to be usable; even if entries under this key are changed, and the Event Viewer is launched from a syswow64 directory (to enforce 32-bit version), the OS will still launch the proper 64-bit version anyway. Perhaps there is a way to enforce the 32-bit version to run, but I have not explored it

Also, we want to ensure the user is not asked for approval to send the data from the log to Microsoft (this dialog box shows up before the program is ran):

To do so, we just need to ensure this DWORD is changed to 0:

HKCU\Software\Microsoft\Windows NT\
CurrentVersion\Event Viewer\ConfirmUrl=0
 

And that’s it. Plus, it’s time for a small bonus.

While I was playing around with Event Viewer, I noticed that it uses Richedit control to render the data it shows. One of the features of this control is that it is automatically recognizing URLs embedded inside the data. As such, it highlights them and make them clickable.

A malicious user could inject a malicious link pointing to a full path on a disk into the logs (e.g. if sysmon is logging, or 4688+cmd line logging is enabled), and then make the richedit convert this path into a clickable link. When I posted this discovery on Twitter, it got immediately evilriched by Brent Muir, who asked if it could be used as a privilege escalation. This was confirmed by me and Csaba Fitzl in the same thread. Thanks to everyone who chipped in on that thread.