Patching DoublePulsar to Exploit Windows Embedded Machines

During one of my engagements, I discovered some Windows devices that were affected by the MS17-010vulnerability. One of these devices caught my attention as it’s something I haven’t encountered yet – a Windows Embedded operating system. MS17-010 Auxiliary Module

Since it’s vulnerable to MS17-010, I immediately tried the relevant Metasploit modules. However, none of them worked. All I got was just an error saying that the target OS is not supported. MS17-010 Eternalblue

Even the new MS17-010 module (exploit/windows/smb/ms17_010_psexec) didn’t work. New MS17-010

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.

Meme

To verify if the target was really vulnerable, I decided to use the original exploit for MS17-010. So, I fired up Fuzzbunchand then used SMBTouch. The result showed that the target was actually vulnerable via EternalBlueSMBTouch

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. EternalBlue

Since the backdoor was already installed, the last thing that needs to be done to complete the exploitation and gain a shell was to use DoublePulsar. First, I generated a shell in DLL format. MSFvenom

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. DoublePulsar Failed

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 .textsection at 0x0040376CError String

To have a better understanding on how DoublePulsar ended up with that error message, I decided to follow the program’s flow using IDA’s graphical view. Graph View

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 stringProgram Flow

By analyzing further the “Windows 7 OS Check”, I observed that I could “force” the program to take the left path by modifying the instruction jz short loc_403641 to jnz short loc_403641Windows7 Check

To do this, I went to Edit > Patch program > Change byteChange Byte

Then I changed the value 74 (opcode of JZ) to 75 (opcode of JNZ)Patch Bytes

This is what it looked like after modifying the jump instruction. New Instruction

I then created a DIF file by going to File > Produce file > Create DIF file…DIF File

Then used @stalkr_’s script (https://stalkr.net/files/ida/idadif.py) in order to patch the modified exe file. Patched

Then moved back the modified Doublepulsar-1.3.1.exe to its original location. Modified DoublePulsar

Using the modified DoublePulsar, I was able to inject the generated DLL payload to the target host. DoublePulsar Worked

And gained a SYSTEM shell. Shell

(Visited 45 times, 1 visits today)