Beating shields of EDR with the 16-bit setup

This is probably the most bizarre way of breaking the process tree you will see today, but well, it works, so there you go…

Have you ever wondered what these guys are?

  • C:\Windows\System32\InstallShield\setup.exe
  • C:\Windows\SysWOW64\InstallShield\setup.exe

Yup, me neither – until today.

Turns out that this is a very old school InstallShield setup program.

It has an interesting property that it is signed and exists on lots of versions of Windows.

It turns out that you can use it for at least two different purposes.

  • Side-load _setup.dll it relies on (signed .exe loading unsigned DLL)
  • Spawn .exe of your choice, breaking the process tree in a very lame way

The first one is trivial.

The second one is the really weird one – we have to create a fake setup directory layout that will allow us to execute program of our choice.

We need these files to pull it off:

  • _inst32i.ex_
    • the binary that is required by setup.exe; after toying around with an existing _inst32i.ex_ file from some old installation I came up with this minimalistic file layout that you need to save as _inst32i.ex_
00 : 2A AB 79 D8 00 01 00 00 00 00 00 00 00 00 00 00 *.y............. 000
10 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 016
20 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 032
30 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 048
40 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 ................ 064
50 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 080
60 : 00 00 00 00 00 00 0B 00 49 4E 53 54 41 4C 4C 2E ........INSTALL. 096
70 : 45 58 45 01 00 58 00 00 00 00 00 00 00 00 00 00 EXE..X.......... 112
80 : 00 00 00 00 00 00 00 00 00 00 09 00 7A 64 61 74 ............zdat 128
90 : 61 2E 64 6C 6C 01 00 5A 00 00 00 00 00 00 00 00 a.dll..Z........ 144
A0 : 00 00 00 00 00 00 00 00 00 00 00 00 0B 00 57 55 ..............WU 160
B0 : 54 4C 39 35 69 2E 44 4C 4C 01 00 58 00 00 00 00 TL95i.DLL..X.... 176
C0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 192
D0 : 0A 00 42 4F 4F 54 31 36 2E 45 58 45 01 00 58    ..BOOT16.EXE..X  208
  • _setup.dll
    • already on the system
  • layout.bin
    • just type “echo > layout.bin”
  • setup.exe
    • already on the system, signed
  • SETUP.LID
[Languages]
key0=0009
Default=0009
count=1

Finally, the payload – save it inside this file:

  • xtract_all.exe

or, make xtract_all.exe a dummy and store the payload inside the  _isdel.exe file.

Now, all you have to do is to run:

setup.exe /extract_all /s

This will execute setup.exe in a silent mode, and will force it to launch both xtract_all.exe and _isdel.exe.

Interestingly, the _isdel.exe is launched from the same directory, but xtract_all.exe will be executed from the %TEMP% directory.

Yup. It’s complicated, I told you 😉

This can be taken a step further. Instead of using the /extract_all trick, you can actually generate your own _inst32i.ex_ file that may hold the payload. Since it’s an old proprietary InstallShield package file format, it is unlikely its content is scanned for malware. To generate a payload you may either use an InstallShield installer (if you can find one!), or.. reverse engineer the package file format…

Running programs via Proxy & jumping on a EDR-bypass trampoline, Part 2

Update

After my post Zod contacted me with this mike-dropping link: Ultimate AppLocker ByPass List. Really lots of good stuff there! Thx Zod!

Old Post

In the first part I listed a couple of examples of programs that may be used as a proxy to launch other programs. In the meantime, subTee kicked off a very interesting thread on Twitter listing a number of signed .exe binaries that can be used as a proxy to load a DLL. Yesterday I came across a few cool posts by @0rbz_. This in return reminded me of my first post and I decided to add a few more proxy/living off the land ideas.

There is a number of signed .exe that can be used to load other .exes or .dlls and as a result – break standard EDR detection rules, or bypass some whitelisting. This may sometimes involve copying the signed binary to your folder in order to sideload your DLL (PlugX is a very good example, funnily enough – in many cases they don’t even need to bring a signed .exe and fetch one that is typically present on the system).

Here is the list:

  • AppVLP.exe – to launch .exe
    • From this Tweet by @0rbz_
    • Just run C:\Program Files\Microsoft Office\root\client\AppVLP.exe <exename>
  • pcalua.exe
    • From this Tweet by @0rbz_ and mentioned on this forum
    • Just run C:\windows\system32\pcalua.exe -a <exename>
  • odbcconf.exe – to load .dll
  • odbcad32.exe – to load .dll via GUI
    • drop c:\windows\system32\<dllfile>
    • run odbcad32.exe
    • go to Tracing Tab
    • choose Custom Trace DLL
    • hit Start Tracing Now
  • WinMail.exe – to load .dll
    • copy c:\Program Files\Windows Mail\WinMail.exe to your folder
    • name your DLL ‘msoe.dll’
    • launch one of these
      • WinMail.exe /identcatalog
      • WinMail.exe /identfileslist:foo
      • WinMail.exe /identfile:foo
  • xwizard.exe – to load .dll
    • From my previous post
    • copy c:\WINDOWS\system32\xwizard.exe to your folder
    • name your DLL ‘xwizards.dll’
    • run xwizard.exe with at least two arguments
  • java.exe – to load .dll
    • From my previous post
    • run java -agentlib:<dllname>
      or
    • run java -agentpath:<dllname_with_dll_extension>
  • any other phantom / sideloaded dlls – to load .dll

If you know of any other tricks like this, please let me know. Thanks!

p.s. as I was about to post it, Huntress Labs just published yet another cool technique using WseClientSvc.exe passthru.exe calc.exe!