I remember seeing a Tweet (long time ago) where someone was demo-ing that you you can execute any program, no matter what file extension, by simply providing a path to it from a cmd.exe shell and hitting enter.
It works.
All you have to do is type a file name in a current directory, or a full path reference and hit enter – the file, as long as it is a PE exe, will simply execute.
Pause for a moment to reflect on some funny side effects that come with this feature.
Your .exe can have any file extension. You can rename your .exe to ‘Red squirrel population dynamics – data set 2019.xlsx’, or ‘My novel that will be better than Stephen King.docx’, and launch it from cmd.exe without launching Excel or Word in the end, as one might expect. You can also pass these file names to other instance of cmd.exe via ‘/C’ argument and I bet anyone seeing it will think you are into squirrel data crunching, or writing the new Netflix TV Series.
You could even create a file:
- c:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE foo.doc
– it could mislead some EDRs or analysts.
Back to that original Tweet – at that time I got curious and had a quick look at cmd.exe code. I quickly discovered that it always take a stab at CreateProcess API first. That is, it just tries to execute the existing file, if possible. This is unlike Windows Explorer that primarily relies on ShellExecute* APIs – and these do rely on file extensions.
Okay, so I did that quick research long time ago and thought this is the end of the story.
Until I saw this post from Mitja wondering about the very same issue in a context of a very interesting (and kinda first in its own genre /due to HIPAA legal implications/) research from Cylera by D00RT_RM.
Of course, once I saw Mitja’s post I reacted with a knee-jerk reply that stated what I discovered in the past.
BUT
Mitja came back with an observation that there must be more to this, because you can still launch a text file in a Notepad if you just type the name of a text file inside the cmd.exe shell and hit Enter.
This got me curious again, and after a few more IDA screens and some dynamic testing I discovered that Mitja was right, and the way cmd.exe executes stuff is indeed a bit twisted.
The behavior of cmd.exe depends on the value of this Registry entry:
- HKCU\Software\Microsoft\Command Processor\EnableExtensions
If this value is zero (extensions disabled), the cmd.exe will run the file path via CreateProcess only; if it fails, we will see a message ‘<filename> is not a valid Win32 application.’:
If the value is 1 though (default since Windows XP), the cmd.exe will first attempt to execute the file via CreateProcess, and if it fails (only ERROR_BAD_EXE_FORMAT or ERROR_ELEVATION_REQUIRED errors are handled), it will pass the path to ShellExecuteWorker API that in turn will execute ShellExecuteEx — in the end mimicking the way Windows Explorer ‘opens’ files.
I think it’s a good option and probably an expected User Interface behavior, but it does make for a curiosity that is worth knowing about.
And I really liked that this second take at the research happened, because:
- Mitja provided a feedback to my earlier research
- This in turn triggered my further research
- This in turn made this post possible
So, the lesson learned is: always work under assumption that your knowledge is incomplete and can be always improved. The feedback and back and forth on Twitter has proven many times to me how useful the feedback and technical convos are, and let’s hope there will be more of it in the future. Thanks Mitja!