During one of my engagements, I discovered some Windows devices that were affected by the MS17-010 vulnerability. One of these devices caught my attention as it’s something I haven’t encountered yet - a Windows Embedded operating system.
That’s weird. Maybe MSF’s auxiliary module gave me a false positive. Or maybe the authors of the exploit modules forgot to include the support for Windows Embedded.
To verify if the target was really vulnerable, I decided to use the original exploit for MS17-010. So, I fired up Fuzzbunch and then used SMBTouch. The result showed that the target was actually vulnerable via EternalBlue.
I then quickly used the EternalBlue module and the result was successful - the backdoor was successfully installed on the target. So I guessed the authors of the MSF exploit modules just forgot to add the support for Windows Embedded version.
Then I used DoublePulsar to inject the generated DLL to the target host. However, it failed with an error message of
[-] ERROR unrecognized OS string. I guessed the MSF modules were true after all that the Windows Embedded version was not supported.
With still a few hours left before the engagement ended, I decided to dig deeper and examined DoublePulsar. First, I searched for the error message that I got while attempting to use DoublePulsar. This string was found on the
.text section at
As seen from the graphical view, if the target machine is running Windows 7, it will take the left path, then proceed to detect whether its architecture is x86 or x64. If the target is not Windows 7, it will take the right path and do the other OS checks. Since there’s no check for Windows Embedded, the program ended up outputting the error message
[-] ERROR unrecognized OS string.