Wow! 64! Lolbin! Bring back NetMeeting!

Posted on by

All Windows Lolbins are dead.

Right?

The native OS program that I never looked at caught my attention today. Its location is:

  • c:\windows\SysWOW64\instnm.exe

And it caught my attention, because its filename implies it is some sort of installer. And since installers are renowned for offering LOLBIN functionality I started digging…

The version info made me shiver…
– 32-bit NetMeeting Installer for Win64.

Que?

I have not heard of ‘NetMeeting’ for at least 700 years…

To my surprise, the program is very small (8K) and after loading it into IDA I realized why. It uses Setup APIs to install… stuff.

So, my hunch was right and the LOLBIN opportunity became real.

Like a dog that got thrown a bone I raised to the occasion and unleashed all the research powers at my disposal. I painstakingly crafted (googled it really) an artisan .inf file that satisfies the ugly desires of SetupOpenInfFileW API that I spotted in the first line of decompiled code:

[Version]
Signature=$CHICAGO$
LayoutFile=layout.inf

[DefaultInstall]
RegisterDlls=foo

[foo]
11,,test.dll, 1

I proceeded to collect my winning lottery ticket and… nothing happened.

Like a wounded offensive researcher so eager to release his pervert creations… I scowled. I have already created a web site (with a logo), a github repo, and a joke to piss off critics of offensive research. Could I be so shortsighted that I did all this without a foresight of failure? Gods of research must be very pleased seeing me struggling, I thought… and in an attempt to reconcile with them I put my hopes in a paradigm shift that I decided to empower my research with.

Like a dog that was thrown a ribeye steak, I scowled again… then I pushed that envelope and proceeded to unleash all the research powers at my disposal, plus one. I decided to actually read the second line of code that IDA presented to me in its wisdom:

SetupOpenAppendInfFileW

With a cautious candor I sniffed around this inferior piece of code and then I realized that my soul left my body… and I scowled again, because it dawned on me (didn’t read the RTFM) that… what led me to the garden of evil was a stupid cross-reference. It turns out, you see, that the API I listed above, one whose name should never be mentioned again has… expectations.

That entitled bratwurst of a code that happened to be used by instnm.exe requires that the .inf file you provide as a command line argument contains a reference to the LayoutFile so that it can, wait for it, make two .inf become one. I bet the guy who wrote that piece of code listened to Spice Girls for too long. The idiot almost costed me my reputation and caused this post to be that long.

Like a dog that became wolf and was thrown a piece of A5 wagyu I scowled again… In an unprecedented move that this blog has never witnessed I created 2 .inf files to save this LOLBIN almost-catastrophe:

layout.inf

[Version]
Signature=$CHICAGO$
[DefaultInstall]

instnm.inf

[Version]
Signature=$CHICAGO$
LayoutFile=layout.inf

[DefaultInstall]
RegisterDlls=foo

[foo]
11,,test.dll, 1

I proceeded to collect my winning lottery ticket and… again… nothing happened.

G-O-D D-A-M-N I-T!

Like a…

I went old-school. I Launched Procmon, found out this idiot coder wants my DLL in c:\windows\syswow64. But I don’t want to place it there. I drop it in c:\test. Bite me. I then make my new instnm.inf file:

[Version]
Signature=$CHICAGO$
LayoutFile=layout.inf
[DefaultInstall]
RegisterDlls=foo
[foo]
11,,..\..\..\..\..\test\test.dll, 1

Then this happens:

NetMeeting is back!

New Code Injection/Execution – Marsh…mellow

Posted on by

All righty… this is a cool one, because it’s so… vague.

How do you describe a generic code execution technique without showing examples?

You show le video…

Then you explain that… any windows message above WM_USER is a potential code execution massacre. Yes. The GIF you looked at is just a simple example of enumerating all windows and their children, and then running a simple loop on all the windows handles. Each iteration of that loop sends a Window Message WM_USER (up to WM_USER+1000) to these windows owned by various processes.

It sounds stupid but it’s not. It counter-marshals (pun intended) the whole system of windows message marshaling…

Common controls use WM_USER+ messages. Custom controls use WM_USER+ messages. Every app is most likely using _some_ controls that are relying on WM_USER+ message. So yeah.. you just narrow this one down that allows you to swap content of a pointer of your choice and you have your code running inside another process user space.

This is the most vague code injection post you will probably come across, but let me tell you this: it describes a whole class of shatter attacks that are either happening, or are going to happen.

Hint: a good message to start playing with is EM_SETTEXTEX (WM_USER+97).

People pointing out Brett Moore’s work are absolutely right. The above idea is identical in principle, just generalized to cover the whole WM_USER spectrum (that includes custom messages that are application-specific & may require per-app research which opens up a lot of pathways to custom code injections e.g. Nvidia, AMD, Intel, Dell etc. GUI applications that are always on).