This is a silly idea that attempts to abuse one very specific class of Error Messages on Windows: the ones that show up when OS is unable to load a DLL or resolve an API function that an executable is relying on.
On Windows 10 we will see the message below if a DLL is missing (here: kernel3x.dll is missing):

Or this (for an API):

Earlier versions of Windows are a little bit more descriptive as they include a reference to an API as well – in this case a very long non-existing function name:

The longest API name I could use is 248 characters. That’s plenty.
These message boxes come in response to a call to a NtRaiseHardError function. When the ntdll.dll is starting new process it tries to load statically linked libraries and resolve all the functions one by one. If anything fails, the error is raised e.g.
- 0xC0000135 STATUS_DLL_NOT_FOUND missing DLL
- 0xC0000138 STATUS_ORDINAL_NOT_FOUND function imported by ordinal not found
- 0xC0000139 STATUS_ENTRYPOINT_NOT_FOUND unresolved API function
Information about these hard errors is added to the Event Logs (Event ID 26 under System), which may come handy as a way to trace ‘failed processes’ e.g.:

Interestingly, all these error message boxes are actually ‘owned’ by the csrss.exe process – a very interesting target from an attacker’s perspective.
At this stage one can immediately note that:
- the message relies on a data directly embedded inside a ‘corrupted’ file i.e. the input data is controlled by file developers and there doesn’t seem to be any input sanitation (but in fairness, why should there be one really?)
- it means we can produce a file with long file name, placed in a location using a long path, using non-existing DLL name(s) and/or API names (248 characters) which in turn will appear in the message box in a way we planned. yup, we can control a big part of the message!
- this may help to develop simple social engineering attacks
- a more subtle implication of the above is that we could potentially inject _any_ code/data into csrss.exe process w/o raising any flag (while achieving a code execution is obviously much harder, having an ability to easily inject data into csrss.exe is a nice bonus); this could be abused in a number of ways e.g:
- a very simple, yet naughty example could be a program using an EICAR as an API name; I have not tested it, but there is a dangerous possibility system could BSOD if AV decided to terminate the process with this string inside
- misdirection / planting evidence e.g. IOCs of other campaigns, non-sensical URLs, etc. so that they can be found during memory inspection & act as a red herring for analysts
- …
So… we have four ways (path, file name, DLL name, API) to influence that error message on Windows 7, and three on Windows 10 (path, file name, DLL name). With these we can deliver at least two variants of Social Engineering tricks:
- By swapping an API name with a text of our choice we can attempt to persuade the user to do something they wouldn’t normally do. For example we could try to phish credentials:

- Manual or ‘persuaded’ bypass of UAC
As long as we don’t close the error message it will continue to appear on the desktop. A funny side-effect (at least on Windows 10) is that it will often keep re-appearing on top of all windows, including the one shown by the UAC dialog box e.g.:

That is, if we run 2 programs where the first one is an intentionally corrupted .exe with our message of choice, and then the program that is requiring the UAC approval, we could overlap the UAC window with our message e.g:

All in all, not a big deal, just an interesting curiosity.