FaX - An Enhanced ActiveX Fuzzing Framework

August 23, 2016 by ATI Blog Team

Authors: Jarrod Johnson and Wei Gao
Ixia's Application and Threat Intelligence (ATI) Research Center is the nerve center for content generation across multiple business units. We provide the threat intelligence that powers ThreatARMOR’s Rap Sheet feature. We produce the applications and network attacks for BreakingPoint, IxLoad, and IxNetwork. We also do vulnerability discovery and analysis.

ActiveX Vulnerabilities

One category of vulnerabilities we are interested in is ActiveX control vulnerabilities. ActiveX is a framework created by Microsoft to extend the functionality of the Component Object Model (COM) and Object Linking Embedding (OLE) and apply it to content downloaded from networks. ActiveX control vulnerabilities can be triggered many ways. These can be due to a buffer overflow in a vulnerable method, or an untrusted pointer dereference of a vulnerable parameter, which can be controlled by a hacker through invoking the ActiveX control. Although ActiveX control vulnerabilities have been described for a long time, relevant vulnerabilities still come out regularly. For instance, recently CVE-2016-4529 was disclosed. This one is due to the deference of a vulnerable parameter as a function pointer in Schneider Electric SoMachine HVAC 2.02 and prior. Also, CVE-2015-8530, discovered by the ATI Research Center, is due to insufficient input validation on an argument passed into the Initialize() function within IBM SPSS Statistics.

Fuzzing is a methodology of identifying bugs or vulnerabilities in software by providing randomized inputs to programs to find test cases that cause a crash. There are many great commercial as well as open source fuzzing tools and frameworks available, such as Peach, Sully, AxMan, etc. AxMan is a web-based ActiveX fuzzing engine that was developed by H D Moore. The goal of AxMan is to identify vulnerabilities in COM objects through Internet Explorer. AxMan first lists all registered COM objects and their associated typelib information, then fuzzes each object's properties and methods.  AxMan is a great ActiveX fuzzing framework. It can fuzz all CLSIDs or a single user-supplied CLSID.  Below we've listed several things we like about it as well as what we wanted to improve.

What we like

It’s fast. Once everything is in place and all the COM objects have been instantiated, you can load the fuzzer, and watch it fly. It will iterate through all of the fuzzable classes, methods, and properties that compose that COM function. Another great feature is the amount of fuzzing arguments and types used.  Everything from combinations of arrays, format strings, file paths, numbers, etc. are used to try and break the function. Finally, it just works. We’ve used other ActiveX fuzzers, but haven’t had near the success as we have had with AxMan.

What we wanted to improve

The overall process of taking some software and fuzzing its controls seemed to contain too many steps and take too much time. Some of these steps even required another tool. You’re supposed to run axman.exe, which enumerates ALL the COM objects on your system and creates a giant list from which to iterate through at runtime. This takes a long time, but more importantly leaves us with several problems.

  1. We get all Windows System COM objects that we don’t care about fuzzing, and that may provide us with a bunch of false positives
  2. If we have x software and want to fuzz a specific CLSID, we need another tool like COM Raider to find the software, break down the IDs, and then plug them into the AxMan manual fuzzing feature. This can take some time, and is an area we thought we could improve upon.

Also, during our fuzzing we noticed that when Internet Explorer terminates, you can read the method and arguments used to break it in the status window at the bottom of the page. However, if the method or argument used is too long of a value, you may not be able to read the entire string (Note: it is recommended to use an http server to log the requests made so you can see what’s happening when the process crashes, however, during our testing we were not able to get the method and argument as exact as the value displayed on the bottom status window - which is the correct value).  Now that iexplore has crashed, we have to take note of which number in our list of CLSIDs we were on, so we can manually open the browser and begin fuzzing where we left off.  If we leave our computer and let the fuzzer run and come back, the Internet Explorer window may be corrupted or unreadable by the control it launched. Enter our enhanced fuzzer, built on and around AxMan. 

FaX – Fuzz ActiveX

Goals – keep it simple to operate, improve the software fuzzing process from download to fuzz, improve the logging, add debugging, and enhance/add automation.

And so it begins…

Platform – we chose to create this in a Windows virtual machine (VM) for the simple fact that starting over will be as easy as reverting the VM. Our VM base snapshot has Windows debugging tools, a debugger, a few treats, and an editor installed as well as AxMan and of course our code as well.

We begin by opening a command prompt - or if reverting the VM you’re presented with the script options straight away.


Upon the initial revert or starting of the VM for the first time, the user will be in the BASELINE state. This is the equivalent to already having run AxMan, which means all software, like debuggers and editors, has already been installed for testing and scanned along with the Windows system COM objects. This list will be our known good (stuff we’re not interested in fuzzing). However, if at anytime we need to add a new tool or want something installed permanently that we don’t want to fuzz, we would revert the snapshot, install the tool, and run the command –


Re-take the snapshot as your new BASELINE.

So the next step would be to install as much target software as you want to test.  Whether it’s an MP3 player or SCADA HMI software plus some other stuff with tons of ActiveX controls. Download the software, and install. If required - reboot the machine and then back in the command prompt enter the next command -

python TARGET


That’s it. Now going back to the fuzzer directory for our final command – 

python -f

and we're off!


At the bottom of the Internet Explorer window you’ll notice lots of COM objects being cycled through and, when one is found with fuzzable methods, it will try to load and fuzz it. 

Once a fuzzable object is loaded, AxMan begins fuzzing. The next thing you’ll see is a Javascript alert msg popup that is somewhat of a necessary evil we added for logging.

To better explain the logging, let’s look at an example function in fuzzer.js


On line 101, we can see that we open an XMLHTTP request to our listening TCP server to capture the current window status, which is the method and arguments being used to fuzz our ActiveX control.  This is the data that is received by the server and written to our log file so we have an exact log of all arguments used to fuzz. 

What we ran into unfortunately, was that these requests and messages were occurring way too fast for our server to keep up, and it couldn’t log everything. We experimented with a setTimeout function, but in the end had to go with an alert window to introduce a delay between XMLHTTP requests. While this does slightly slow down the execution of the fuzzer, it gives a more exact representation of the fuzzer at the time of the crash that can be re-visited later in our logs.

An example of this is seen in the command prompt after the fuzzer starts. If you look in the command prompt a couple images above, you can see the HTTP POST request with the full CLSID, method, and argument appended to the end.

Next we need to deal with these alert windows.  For each argument that is used to fuzz each method there’s an alert window. So we need a way to disable them quickly. 

For this we chose the application buzof, which allows you to set specific parameters that represent a mouse clicking a window box. We set timing of this program very low so it looks as though the message windows are almost always displayed, however, in reality the fuzzer is proceeding at a rapid rate, which can be seen in the bottom left the window status bar.

So after we get a crash, what happens?

Let’s take a look at to see what’s going on.


In our execute function, the first thing we see is that we call our TCP server. This Python server is listening on local port 9000, waiting to write all data received to a log.txt file.  


Further down, we call our debugging script pyddbg. Pydbg is a windows debugger written in Python, and it is what we chose to use for debugging our ActiveX crashes.

In we call our pydbg python script and pass it several arguments. To see how this works we examine

sys.argv[0] + " <prog> <file_to_open> <log_dir> <timeout> <info> <clsid>

Which, for our fuzzing example, can be viewed as: 

iexplore.exe index.html  \path\to\log  600  Fuzzing MP3 Player  {0000100-0000-0010-8000-00AA006D2EA4}


Our debugger script set’s a breakpoint, attaches to the process, runs, and waits for our crash. When an access violation is reached, we generate the log with all relevant register and address information.

So finishing up in our script, we essentially have an array of objects or CLSIDs, and one by one we open iexplore.exe, attach to the process with pydbg, and begin using axman’s core fuzzing engine to fuzz our COM objects. Once the process terminates, a crash file is generated with the name being the CLSID, and all register information at the time of the crash is logged.


It's worth noting that the file is also saved at the time of the crash (index.html), however, since our index file imports our javascript objects and doesn't actually contain the code being fuzzed, that file doesn't help us here.

Once the iexplore.exe process dies, execution of the program is immediately returned to the loop in, which iterates to the next CLSID in the list and the whole process is restarted. For the previous COM object that crashed the process, we add it to AxMan’s existing blacklist. This functionality allows us to skip over it next time we run our fuzzer. We can then re-visit our log file to see the last HTTP request made to determine what argument was used to crash the ActiveX control. 

Additional Material

A couple of things not covered that we wanted to mention here are that we kept the AxMan ability to fuzz a single control by introducing a delay in the browser upon its initial execution. This allows a user to manually click on the index.html file without kicking off the fuzzer – if he/she then clicks inside the text field, the automated fuzzing is cancelled, the pwn button becomes available to use, and if a CLSID known, it can be entered in the field for fuzzing. 

We additionally didn’t cover how we scraped the new ActiveX controls, and differentiated them from the known good system controls. Below is our utility script that houses a bunch of useful functions we needed to import and use at various times. 

 As you can see, we run axman save to a directory and then re-run after installing the target software, save to a different directory and perform a diff on the files before fuzzing.


So after gathering all of this information related to our ActiveX control crash, we can construct a proof of concept and begin more manual in-depth testing to try and determine the nature of the crash.

For example this might look something like:



    <object id="id1" CLASSID="clsid:8Axxx2x-x5x7-xxBx-x5xx-09Exxxxx7xFx"></object>



    var obj = document.getElementByID("id1");

    obj.vulnMethod = ARG;



In conclusion, the FaX fuzzing framework enhances the AxMan fuzzing engine and improves its usability…at least for us. We kept it simple to operate, and improved the software fuzzing process from download to vulnerability/crash analysis, by improving the logging, adding debugging, and automating the COM object enumeration process in a more user-friendly and time critical manner. Fuzzing with FaX is now as simple as - find the target, turn on the VM, install the software, enter a command, grab on something else. It really has improved our internal vulnerability and bug discovery process enough that we can now spend more time focused in other areas to continue delivering more quality content to our users. Future work might include integrating with Terminal Notifier so we get a Mac alert message window when we’ve hit a crash.

Leverage Subscription Service to Stay Ahead of Attacks

The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.