Recently, I had the privilege to write a detailed analysis of CVE-2023-34362 , which is series of several vulnerabilities in the MOVEit file transfer application that lead to remote code execution. One of the several vulnerabilities involved an ISAPI module - specifically, the MoveITISAPI.dll ISAPI extension. One of the many vulnerabilities that comprised the MOVEit RCE was a header-injection issue, where the ISAPI application parsed headers differently than the .net application. This point is going to dig into how to analyze and reverse engineer an ISAPI-based service!

This wasn’t the first time in the recent past I’d had to work on something written as an ISAPI module, and each time I feel like I have to start over and remember how it’s supposed to work. This time, I thought I’d combine my hastily-scrawled notes with some Googling, and try to write something that I (and others) can use in the future. As such, this will be a quick intro to ISAPI applications from the angle that matters to me - how to reverse engineer and debug them!

I want to preface this with: I’m not a Windows developer, and I’ve never run an IIS server on purpose. That means that I am approaching this with brute-force ignorance! I don’t have a lot of background context nor do I know the correct terminology for a lot of this stuff. Instead, I’m going to treat these are typical DLLs from typical applications, and approach them as such.

You can think of ISAPI as IIS’s equivalent to Apache or Nginx modules - that is, they are binaries written in a low-level language such as C, C++, or Delphi (no really, the Wikipedia page lists Delphi !) that are loaded into the IIS memory space as shared libraries. Since they’re low-level code, they can suffer from issues commonly found in low-level code, such as memory corruption. You’ve probably used Microsoft-supplied ISAPI modules without realizing it - they are used behind the scenes for .aspx applications, for example!

I found this helpful overview of ISAPI , which links to the other pages I mention below. It has a deprecation warning, but AFAICT no replacement page, so I can say it existed in June/2023 in case you need to use the Internet Archive to fetch it.

Depending on the application, ISAPI modules can either handle incoming requests by themselves (“ ISAPI extensions ”) or modify requests en route to their final handler (“ ISAPI filters ”). They’re both implemented as .dll files, but you can distinguish one from the other by looking at the list of exported functions (in a .dll file, an “exported function” is a function that can be called by the service that loads the .dll file). You can view exports in IDA Pro or Ghidra or other tools, but for these examples I found a simple CLI tool written in Ruby tool called pedump , which you can install via the Rubygems command gem install pedump .

Here are the exported functions in MOVEitISAPI.dll , which is the ISAPI module included with the MOVEit file transfer application:

The two that we’re interested in are GetExtensionVersion and HttpExtensionProc , which we’ll dig into later.

Let’s contrast the ISAPI module with an ISAPI filter - MOVEitFilt.dll :

The filter has two other functions - GetFilterVersion and HttpFilterProc .

So basically, you can figure out what type of ISAPI module you’re looking at by looking at the functions exported. In theory, there’s no reason why an ISAPI module can’t be both, but I’m not sure if anybody does that! Maybe for a CTF challenge I’ll try to develop an ISAPI Filter Extension that modifies its own requests :)

Let’s say you’re working on an application that runs on IIS, and you want to identify the attack surface - ie, find ISAPI modules. The probably-correct way to answer this is to open up the IIS manager ( InetMgr.exe ) and look at the configuration. But that’s boring!

Recalling my original promise, to use “brute-force ignorance”, let’s use some commandline tools to figure out what’s going on!

The IIS process is called w3wp.exe , so let’s use wmic to find all instances of w3wp.exe running (note that I’m using MOVEit as an example, but this will work on other applications as well):

Which outputs:

In this case, there are two IIS services running, with two different configurations: one is called the moveitdmz Pool and the other is called the moveitdmz ISAPI Pool . We can probably guess that the latter is what we want, but it turns out that the configurations are identical. I’m sure there’s some meaningful difference, but this is precisely where my knowledge of IIS ends so let’s just move on. :)

If we pick one of those configuration files and search it for “isapi”, we’ll find a ton of matches, because stuff like ASP are implemented as ISAPI modules. But if we look and search hard enough, we’ll find our modules:

This is well and good, but reading configuration files is hard and prone to missing stuff.

My recommendation, and personal approach, is to just copy the entire application to a Linux system, then use grep :

Then work your way backwards to IIS to see how they’re served. Easy! :)

Let’s switch from generically talking about ISAPI modules to talking specifically about ISAPI Extensions - the type of module that serves a page directly, as opposed to the modules that filter requests. Filters will be similar, just different function names.

Microsoft provides an overview of ISAPI extensions here , which I’m going to use a bit.

ISAPI modules are shared libraries (ie, .dll files) that are loaded into the address space of IIS. When any .dll file is loaded (ISAPI or otherwise), the first function that’s called is always DllMain :

It’s the .dll equivalent to main() in a typical C application, except that it’s called multiple times in the .dll’s lifecycle. The fdwReason argument specifies why it’s being called:

This isn’t anything special with ISAPI modules, and there’s a good chance that the DllMain function isn’t used at all - it simply has to return true . If it IS used, you’ll most likely see the DLL_PROCESS_ATTACH and DLL_PROCESS_DETACH reasons being used to initialize and clean up.

After the ISAPI module is loaded, IIS will call the GetExtensionVersion() exported function. You can read about the function in Microsoft’s documentation , but the important part is the definition:

HSE_VERSION_INFO is a fairly simple structure with just two fields:

As far as I know, these are free-form values. I added a struct called HSE_VERSION_INFO into IDA Pro, and it already knew the structure:

And it let me decorate rcx (the pVer argument on a 64-bit machine) with the proper field names (still using MOVEitISAPI.dll as an example):

This function is also called exactly once in the ISAPI module lifecycle, which means it can (and often IS) used to initialize variables. Keep an eye out in both DllMain and GetExtensionVersion for initialized variables!

The real meat of an ISAPI extension is HttpExtensionProc() , which is executed each time somebody accesses the extension. It’s where all the interesting stuff is going to happen.

The definition of the function is:

Once again, it takes exactly one argument, which is stored in rcx (on a 64-bit host), or on top of the stack (on 32-bit). We’ll stick to 64-bit.

The argument is a pointer to a EXTENSION_CONTROL_BLOCK structure, which has the following definition:

Once again, if you add a struct called EXTENSION_CONTROL_BLOCK to IDA Pro, it’s aware of the structure and size of all the fields:

The most interesting fields are:

Additionally, four function pointers are passed in that structure:

Once you know the structure of the incoming data, you can identify a lot of what’s going on in the module; for example, this code:

Appears to be copying the query string. We can all but confirm that in the next line, which uses var_5838 :

It passes what looks like the query string, and the literal string “ep”, to another function. Without ever looking at that function, I named it get_field_from_querystring_maybe . That’s later confirmed with:

We can also find the callback functions, like GetServerVariable , being used to read values from the environment:

From here, it’s a pretty typical Windows application, and can be reversed as such. That could be a good or bad thing, depending on your comfort level.. but one thing we CAN do is attach a debugger. Let’s see how!

Thanks to the magic of “this being a normal .dll file”, we can debug this just like any program with a .dll file.

First, we need to figure out which process is actually serving that .dll. You could look at configs and stuff, but that’s boring. You can bruteforce and debug every w3wp.exe process, and that’s what I normally do, but I actually found a better way while writing this blog.. you can use tasklist /m <DLL> to check which processes have a specific .dll loaded:

That’s kinda magic, and could have saved me SO much trouble in the past!

Anyways, once you know the PID (in this case, 5248), you can attach a debugger such as windbg . When you attach, you should see the ISAPI modules loaded into memory as if they’re standard .dll files (because they are):

Due to ASLR, the addresses probably won’t match the addresses you see in other tools, but that’s a starting point!

You can use the x command to get a list of the exported addresses:

You can also put a breakpoint on the HttpExtensionProc function (be sure to pass in the module name, since there will be multiple ISAPI modules with the same names):

Then send some request:

And observe in the debugger, using the field offsets we saw earlier (I imagine you can use dx to dump the whole object if you load the definition into windbg, which I don’t know how to do):

From there, you can use break-on-access ( ba ) and other stuff to track the data, if desired! Whatever you want to do!