Procmonning the Win11_24H2 build

This is a bunch of random notes from running Procmon on Win11_24H2 build.

We all know about autorun.inf that OS is checking when we attach a new device to the system, but on new devices the system is actually looking for more files — here’s the list:

  • \Device\HarddiskVolumeN\audio_ts\audio_ts.ifo
  • \Device\HarddiskVolumeN\autorun.inf
  • \Device\HarddiskVolumeN\AVCHD
  • \Device\HarddiskVolumeN\BDAV
  • \Device\HarddiskVolumeN\BDMV
  • \Device\HarddiskVolumeN\bootex.log
  • \Device\HarddiskVolumeN\DCIM
  • \Device\HarddiskVolumeN\desktop.ini
  • \Device\HarddiskVolumeN\dvd_rtav\vr_mangr.ifo
  • \Device\HarddiskVolumeN\EFI\Microsoft\Boot\BCD
  • \Device\HarddiskVolumeN\EFI\Microsoft\Boot\BCD.LOG
  • \Device\HarddiskVolumeN\EFI\Microsoft\Boot\Policies\UnlockToken.pol
  • \Device\HarddiskVolumeN\PRIVATE\AVCHD
  • \Device\HarddiskVolumeN\Recovery.txt
  • \Device\HarddiskVolumeN\SVCD\entries.svd
  • \Device\HarddiskVolumeN\SVCD\entries.vcd
  • \Device\HarddiskVolumeN\System Volume Information
  • \Device\HarddiskVolumeN\System Volume Information\AadRecoveryPasswordDelete
  • \Device\HarddiskVolumeN\System Volume Information\ClientRecoveryPasswordRotation
  • \Device\HarddiskVolumeN\System Volume Information\FveDecryptedVolumeFolder
  • \Device\HarddiskVolumeN\VCD\entries.vcd
  • \Device\HarddiskVolumeN\video_ts\video_ts.ifo
  • \Device\HarddiskVolumeN\WinReOfflineScanningResult.dat

Some of them are obviously media-related, some are Windows Backup-related, and some … I have no clue.

The other interesting bit is that when executed, lsass.exe is trying to load a phantom DLL named “”.dll:

  • C:\Windows\””.DLL
  • C:\Windows\System\””.DLL
  • C:\Windows\System32\””.DLL

While it looks like an attractive proposition, I am not sure if there is a way to exploit it 🙁 Still, need to come back to it to understand why the process is doing so. Perhaps there is a new data dumping opportunity here, somewhere…

There are a lot of new phantom DLLs, but they are tricky to play with. While writing this post I messed up this build’s booting so many times that I no longer understand which of these test phantom DLLs I added to the system contributed to the damage 🙂 I have added a list of potentials at the bottom of this post.

Then there is smss.exe trying to find these:

  • C:\Windows\apppatch\drvpatch.sdb
  • C:\Windows\System32\wowarmhw.dll
  • C:\Windows\System32\xtajit.dll
  • C:\Windows\System32\xtajit64.dll
  • C:\Windows\System32\xtajit64se.dll
  • C:\Windows\SysWOW64\wow64.dll
  • C:\Windows\SysWOW64\wow64base.dll
  • C:\Windows\SysWOW64\wow64con.dll
  • C:\Windows\SysWOW64\wow64win.dll
  • C:\Windows\SysWOW64\xtajit64.dll
  • C:\Windows\SysWOW64\xtajit64se.dll

Then spoolsv.exe trying to access these:

  • C:\Windows\System32
  • C:\Windows\System32\spool
  • C:\Windows\System32\spool\drivers
  • C:\Windows\System32\spool\drivers\ARM64
  • C:\WINDOWS\system32\spool\drivers\ARM64\3\New\
  • C:\WINDOWS\system32\spool\drivers\ARM64\3\Old\
  • C:\WINDOWS\system32\spool\drivers\ARM64\4\New\
  • C:\WINDOWS\system32\spool\drivers\ARM64\4\Old\
  • C:\Windows\System32\spool\drivers\IA64
  • C:\WINDOWS\system32\spool\drivers\IA64\3\New\
  • C:\WINDOWS\system32\spool\drivers\IA64\3\Old\
  • C:\Windows\System32\spool\drivers\W32X86
  • C:\Windows\System32\spool\drivers\W32X86\3\New
  • C:\Windows\System32\spool\drivers\W32X86\3\Old
  • C:\Windows\System32\spool\drivers\x64
  • C:\Windows\System32\spool\drivers\x64\3\New
  • C:\Windows\System32\spool\drivers\x64\3\Old
  • C:\WINDOWS\system32\spool\drivers\x64\4\New\
  • C:\WINDOWS\system32\spool\drivers\x64\4\Old\
  • C:\Windows\System32\spool\PRINTERS
  • C:\Windows\System32\spool\SERVERS
  • C:\Windows\System32\ualapi.dll
  • C:\Windows\System32\vfprint.dll

There seems to be a lot of cross-architectural code logic present here that needs further exploration.

There also seem to be more phantom DLL loading opportunities that are only available under specific conditions:

  • C:\Windows\System32\Unknown.DLL (loaded by svchost.exe when AFAICT there is no network connectivity)
  • C:\WINDOWS\SYSTEM32\windowsdefender:\.DLL – a potential phantom DLL but impossible due to file/ADS naming limitations

And finally, there is really a lot of paths the OS is trying to access in the procmon log that suggests some incoherent environment variable parsing:

  • C:\Windows\System32\%ProgramFiles(arm)%
  • C:\WINDOWS\system32\%systemroot%\system32\wbem\cimwin32.dll
  • C:\WINDOWS\system32\%systemroot%\system32\wbem\wmipcima.dll
  • C:\WINDOWS\%WINDIR%\System32\SPP\Migration\sppgenmig.dat
  • C:\WINDOWS\%WINDIR%\System32\SPP\Migration\sppmig.dat
  • C:\Windows\System32\%SystemRoot%\ProgramData\Microsoft\Windows\AppRepository\Packages\MicrosoftWindows.Client.AIX_1000.26100.29.0_x64__cw5n1h2txyewy\ActivationStore.dat
  • C:\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\%SystemRoot%\ProgramData\Microsoft\Windows\AppRepository\Packages\MicrosoftWindows.Client.AIX_1000.26100.29.0_x64__cw5n1h2txyewy\ActivationStore.dat
  • C:\WINDOWS\%WINDIR%\System32\SPP\Migration\sppgenmig.dat
  • C:\WINDOWS\system32\%systemroot%\system32\wbem\wmiprov.dll
  • C:\Users\<USER>\Desktop\%1
  • C:\Users\Public\Desktop\%1

That’s a lot of sideloading and potential LPE vulns to explore…

The full list of possible phantom DLLs can be found here (win11_24H2_phantom_dlls.txt). Some of them are obvious path problems, but many are real phantom DLLs.

Some notes on Windows 11 Notepad

The new win11 version of Notepad accepts a few command line options that i have not seen documented anywhere (or only documented partially).

  • /A – forces Notepad to read the input file as ANSI
  • /W – forces Notepad to read the input file as WIDE (Unicode 16LE)
  • /.SETUP – tells Notepad it was launched by the Installer; AFAICT running Notepad with this option literally DoSes it
  • /.SETUP <filename> – same as above except we try to open the file <filename> — still DoS though
  • RestartByRestartManager:<GUID> – mentioned by @nas_bench here – used to restore some of the AutoSaved documents; the information is saved under HKCU\Software\Microsoft\Notepad\Autosave\GUID in a form of three coma-separated values f.ex.:

so analyzing this key and its children may have some DFIR value, potentially.

The first value is a code page (0,1=ANSI; 2,3=Unicode LE/BE; 4,5=UTF8 with or w/o BOM, 6=Chinese), second is probably a document path, and the third is a working directory. These all need to be confirmed as I am making quick&dirty assumptions here.

Launching c:\windows\notepad.exe under xdbg makes the old-fashioned Notepad window appear, with a banner encouraging the user to launch the new version of Notepad (Microsoft app):

This behavior is a bit unexpected and am wondering if it could be somehow abused.

The Launch button executes the so-called Centennial version of Notepad located here:

%LOCALAPPDATA%\Microsoft\WindowsApps\Microsoft.WindowsNotepad_8wekyb3d8bbwe\notepad.exe

In some circumstances a file probe.autosave may be created by new Notepad.

The info about currently opened tabs seems to be stored in this folder:

C:\Users\<USER>\AppData\Local\Packages\Microsoft.WindowsNotepad_8wekyb3d8bbwe\LocalState

and there (already) is a library for parsing these.

Launching notepad.exe leads to Windows App being executed, because of these new settings in the Registry:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe\0
AppExecutionAliasRedirect = 1
AppExecutionAliasRedirectPackages = *
FilterFullPath = C:\Windows\System32\notepad.exe

Changing the value of AppExecutionAliasRedirect from 1 to 0 will bring the old Notepad back. And lo and behold, there is a ‘legitimate’ way to disable new Notepad too – the Advanced App Settings allow us to disable the so-called Windows Apps aliases:

Once you disable the Notepad alias, the old Notepad will return. And if you want to disable that annoying banner showing up in this old Notepad you can add the following Registry entry:

HKCU\Software\Microsoft\Notepad
ShowStoreBanner (dword) = 0

And with that, we are back to the good ol’ Notepad version we all love 😉

The Windows 11 changes are very interesting from the DFIR perspective. Many old programs we took for granted (for decades!) are now exhibiting new behaviors that need an additional research effort. This is actually quite exciting because we all want to close cases in a conclusive way and knowing how to interpret the superset of all forensic artifacts is of a paramount importance…