Internet is a cool place, because luckily there are some good souls who points us in a right direction. The technique I described below was presented as early as July 2003 by Oliver Lavery from iDefense! Thanks to modexp for pointing it out.
Old Post
This is a trivial case of yet another functionality available that can help to execute code in a remote process. Same as with PROPagate technique, it only affects selected windows, but it can of course be used as an evasion, especially in early stages of compromise.
Edit controls (including Rich Edit) are very common Windows controls present in most applications. They are either embedded directly, or as subclassed windows. When they display text in multiline mode they use so-called EditWordBreakProc callback function. Anytime the control needs to do something related to word wrapping the procedure will be called.
One can modify this function for any window by sending EM_SETWORDBREAKPROC message to it. If windows is an Edit control or its descendant, funny things may happen.
In order to see which windows are susceptible to such modification I created a simple demo program that basically sends this message to every window on my desktop.
After looking around and running some potential victim programs I quickly found a good candidate to demo the technique: The Sticky Notes (StikyNot).
I ran it under the debugger to catch the moment it crashes, and then ran my test program. It changed the procedure for every window to 0x12345678.
And this is what happens when you start typing in Sticky Notes after the procedure was changed:
I bet there are more programs that can be targeted this way, but as usual, I leave it as a home work to the reader :-
Modexp shared a nice POC here. Csaba shared a nice POC here.
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.
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:
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!
