The Wizard of X – Oppa PlugX style, Part 2

Every once in a while I come back to have a second look at some stuff from the past. Today I had a quick look at xwizards.dll that I wrote about before and noticed that I forgot to mention one more thing.

The exported function RunWizard takes GUID as an input. If you register a DLL under a GUID of your choice you can load the DLL via xwizard.exe e.g.:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID]
"CLBVersion"=dword:00000012

[HKEY_CLASSES_ROOT\CLSID\{11111111-1111-1111-1111-111111111111}]
@="foobar"

[HKEY_CLASSES_ROOT\CLSID\{11111111-1111-1111-1111-111111111111}\InprocServer32]
@="C:\\test\\test.dll"
"ThreadingModel"="Both"

will register c:\test\test.dll under {11111111-1111-1111-1111-111111111111} GUID. All we have to do now is run:

  • xwizard RunWizard {11111111-1111-1111-1111-111111111111}

The curious case of svcpack1.dll

When you disassemble/decompile code produced by popular vendors you usually (blindly) assume that they got it right. I know of typical vulnerabilities, I know of business logic bugs, but somehow… I always feel that all the actions of programmers are either justified, or at least, reasonable within a scope of a particular operation…

This is why the case of svcpack1.dll is puzzling me.

Imagine a signed .exe from Microsoft literally injecting a remote thread into winlogon.exe. Imagine this thread doing nothing, but loading a library called `svcpack1.dll`. Okay. It’s a legacy code. It’s from a Service Pack Update executable, but still….

This is an interesting opportunity.

As I have said may times before… re-usigned binaries are probably a future of malicious activities. Signed, with a great reputation score, yet… given specific circumstances… possibly… really bad….