Update

Turns out @sixtyvividtails has already discovered the very same issue via a minimalist PE file back in June. Touche!

Old Post

This is a silly example of a basic mistake leading to a funny discovery…

When I was experimenting with the imported phantom DLLs I accidentally placed a dummy 64-bit DLL in a place of a 32-bit phantom DLL called WDSUTIL.dll that was imported by the 32-bit uxlib.dll. I then attempted to enforce loading of uxlib.dll with a 32-bit version of rundll32.exe by referencing its full path c:\WINDOWS\SysWOW64\rundll32.exe:

c:\windows\syswow64\rundll32 uxlib.dll bar

Turns out that loading of the 32-bit library with an import that points to DLL that is actually 64-bit creates a chain of never-ending executions of the very same command line!

What happens is that when the 32-bit DLL (uxlib.dll) is loaded, the importing fails on the 64-bit phantomDLL (WDSUTIL.dll) which leads rundll32.exe to receive the ERROR_BAD_EXE_FORMAT error from the loading attempt, which in turn leads it to follow the internal _TryWow64Scenario path in its code, which… literally means creating a new SysWow64’s rundll32.exe process with the very same command line passed to it – aka repeating the cycle that we have started this test with!

This leads to a cascade of new rundll32.exe processes being spawn, and it’s similar in nature to regsvr32.exe bomb:

Yes, it is a dolbin!