You are browsing the archive for Anti-Forensics.

PE files and the DemoScene

March 14, 2019 in Anti-Forensics, File Formats ZOO

One of the most creative ways of constructing PE files come not from malware authors, but from so-called DemoScene. Squeezing in everything possible in the smallest possible file is a form of an art. It has roots in competitions that forced the participants to use very restrictive environment to produce the best demo effect possible. From a file format perspective, this resulted in many cool productions where the PE file structure looks completely non-sensical, almost like non-PE, yet when executed, still produces some sort of demo effect.

See for yourself. Is this a valid PE file?

There is no visible DOS Stub, no strings, no library names, no API names, it looks like an old DOS MZ file. At least at a first glance.

It actually is a PE file though.

Many PE Editors, Viewers, and Dumpers have a serious problem analyzing this sort of files, because they can’t handle exceptions that happen during processing. They are typically triggered by some of the PE header structure fields being re-used by demos to store actual code/data for the presentation (no byte is wasted). These values tend to be random, and definitely outside of the boundaries of a file, or image in memory. Operating system loader ignores many of such out-of-bound indexes, while PE tools tend to ‘trust’ the content, and interpret them as valid values, and… eventually fail.

I won’t be naming names, but can confirm that among a couple of tools that I tested, some failed to load this file, some didn’t show proper code from the entry point, because they miscalculated the offset where the code is located.

Overall, it’s good to test your parsers by including such PE curiosities in your test bed ( is a great source for these, but don’t forget Corkami repo – Ange took the art of hand crafted PEs to a completely new level).

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