I was recently tagged in a Twitter thread about an obscure DOS feature in relation to auto-launching applications (commonly called persistence in offensive cyber security). Although the topic was addressed before I had a chance to respond, user @ivladdalvi brought up a secondary issue which felt a bit like a challenge.
A Quick History Lesson
For those not familiar, AUTOEXEC.BAT was a file executed by the DOS command processor at startup. Within early Windows NT operating systems, this functionality slightly changed so AUTOEXEC.BAT was parsed at user logon. Regardless of launch time, the purpose was almost always to set environment variables and kickoff low level applications and utilities.
As you can imagine, this functionality — along with similar files like WIN.INI, SYSTEM.INI, and CONFIG.SYS — were commonly abused by nefarious actors. One of the classic examples of this was the Pikachu worm which spread by email and overwrote AUTOEXEC.BAT to delete Windows’ critical system files:
As Windows NT continued to mature, these files were eventually deprecated, ported into the registry, and supposedly removed entirely. However, Microsoft has a long history of backwards compatibility and I couldn’t help explore whether Windows could be coaxed into still parsing this file.
The ParseAutoexec Value
I usually wouldn’t document quick, failed research like this but @Hexacorn (Adam) and I tend to operate on the same wavelength. His recent blog highlighting his failure to bypass Autoruns with the AutorunsDisabled functionality was my motivation for this.
Like Adam, I knew of some internal functionality that I thought could be leveraged for unexpected functionality. In this case, I was specifically thinking of an old Registry Value (introduced in NT 4.0) that was added to disable the parsing of AUTOEXEC.BAT. This long forgotten REG_SZ value was called “ParseAutoexec” and was located in “ Software\Microsoft\Windows NT\CurrentVersion\Winlogon”.
My hypothesis was simple: AUTOEXEC.BAT will be accessed (possibly even parsed) if I re-add the “ParseAutoexec” value to the expected registry key and set the value data to “1” (enabled). After adding the value to HKLM and the user specific HKU hive, I configured ProcMon to start logging at boot-up with the “Enable Boot Logging” option.
The VMs were rebooted and ProcMon recorded the data like a charm. With the data loaded, I configured a handful of filters to look for processes:
- Accessing paths containing the string “autoexec”
- Registry queries to the “Winlogon” registry keys
- Accessing files where the result was “NAME NOT FOUND”
Unfortunately, all filters returned empty results and satisfied my curiosity that that AUTOEXEC.BAT is probably dead.
What About The Persistence Functionality?
Although files like AUTOEXEC.BAT are no longer directly executed/parsed, almost all of the auto-starting functionality abused by hackers still exists deep within the Registry:
WIN.INI’s “Load=” and “Run=” parameters were moved to values in the HLKM & HKU “Software\Microsoft\Windows NT\CurrentVersion\Windows” keys. Goblin Panda actors were just caught this week abusing for their persistent foothold (nice blog @Sebdraven!).
SYSTEM.INI’s “Shell=” was also moved to a registry value but is located in the HLKM & HKU “Software\Microsoft\Windows NT\CurrentVersion\Winlogon” keys. Sadly, my team at Huntress Labs is constantly finding malware using these as well…
Parting Thoughts
Like all research, this is far from conclusive evidence that AUTOEXEC.BAT is truly dead. There’s likely endless amounts of reverse engineeering needed to fully confirm something so obscure. However, it seems likely that the ParseAutoexec value alone isn’t bringing this (unneeded) feature back ;) If you happen to see otherwise, please give me a holler and share what you’ve learned.
Hope you enjoyed this quick trip down memory lane!
