Attacks
GMON exploitation harnessing SEH: Exceptions are good

VP of Hacking
Updated
Jun 16, 2020
14 min
This is the fourth article on the series of exploiting Vulnserver
, a VbD
(Vulnerable-by-Design) application in which you can practice Windows exploit development.
In our previous posts, we have successfully exploited TRUN, and GTER commands. Both of them had something in common: direct EIP
overwrite, in which our buffer directly overwrote the saved return address
on the stack frame of the affected function with a JMP
instruction to execute the code on our controlled buffer.
In this post, we will exploit the GMON
command using a Structured Exception Handling (SEH
) overwrite to take control of the flow of Vulnserver.
Structured Exception Handling
SEH
is a non-standard mechanism created by Microsoft to handle exceptions of applications using a uniform structure. It allows C/C++
programs using the well-known exception handling syntax (try-except-finally
) used by other high-level imperative languages. Here’s an example:
As you may imply, this code will try to execute strcpy()
, and if it fails because INSUFFICIENT_MEMORY
, it will execute my_exception_handler()
.
As there may be many exceptions, some explicitly declared by the application and other by the OS
, the handlers are tied together by a chain of _EXCEPTION_REGISTRATION_RECORD
structures, the last one (identified by FFFFFFFF
) being the default handler.
When an exception occurs, the OS
will walk the SEH
chain, finding which of them can handle that exception. If none of the handlers have that exception registered, the default handler (FFFFFFFF
) will be triggered.
The structure of _EXCEPTION_REGISTRATION_RECORD
is:
Here the Next
parameter is a pointer to the next exception handler, also called nSEH
, and the Handler
parameter is a pointer to the handler itself. We can see the exception handler’s chain on a debugger:

And on the stack, it is shown as:

More information on SEH
can be found on Microsoft’s site.
SEH exploiting
To oversimplify, the main goal of exploiting a program using SEH
is to have the ability to overwrite the exception handler pointer (my_exception_handler()
in our example) of the vulnerable function with a pointer to our controlled code.
Some things must be in place for us to successfully exploit an application using SEH
:
The application must have
SEH
built-in. This is a compile-time option.Our buffer will be allowed to pass far enough in the stack frame to reach the function’s
SEH
handler.The application must be compiled with
SafeSEH=Off
.
SafeSEH
is a mechanism created since Windows XP that statically defines the list of the allowed exception handlers, and if the application tries to call something different, a crash will happen.
Ok, now with that summary of SEH
, let’s get our hands dirty.
Fuzzing GMON
As with the other Vulnserver commands, the GMON
command takes a single parameter, so, we can reuse our Spike fuzz template:
Remember that the s_string
command will send an immutable string to the fuzzed protocol, and s_string_variable
tells Spike
to use that string as a fuzz point.
And run it:

We got the crash!
And as with the other Vulnserver commands, it seems that 5060 bytes of data triggered the crash:

We can create our first proof-of-concept exploit:
exploit.py.
Now run our exploit with vulnserver.exe
attached to a debugger:

As you can see, we effectively crashed vulnserver.exe
, but EIP
does not seem to be mangled by our buffer.
However, if we look at the SEH
chain table, we will see this:

That means that we effectively triggered an exception and overwrote the exception handler with our buffer. If we trigger the exception handler (in Immunity Debugger, it’s done with Shift+F9
) this will happen:

We control EIP!
That means that we have control over the process execution flow again.
We can now exploit this.
Exploiting
We first need to find the exact offset on where the SEH
handler gets overwritten. We can do that by creating a cyclic pattern using pattern_create.rb
from Metasploit:
Let’s add that pattern to our exploit:
And run it:

As you can see, the handler was overwritten with 346F4533
. To find the offset in which the SEH
handler gets overwritten, we can use pattern_offset.rb
:
Great, the offset on which the SEH
handler starts to be overwritten is 3551
.
To check that offset, we can inject:
3551
A
characters4
B
characters5000 - 3551 - 4 = 1445
C
characters
If the SEH
handler gets overwritten with our B
buffer, we got it right. This is our updated exploit:
And the result:

Awesome!
Now, what would normally happen is to find a JMP ESP
instruction.
However, let’s look at the state of the stack after triggering the exception handler:

We can see several things here:
EIP
is42424242
.There are 8 bytes between the
ESP
at0104EBA0
and a pointer to our buffer at0104EBA8
.So, if we’d run a
JMP ESP
, we’d land at a place in the stack which we don’t control, and exploitation would likely fail.
So we need to find a way of removing those 8 bytes off of the stack in order to redirect the execution flow to 0104EBA8
which has a pointer to our controlled buffer.
POP/POP/RET
The x86 stack is a LIFO
(Last In First Out) structure where the last item pushed into the stack is the first to be popped back. Each PUSH
instruction will push exactly 4 bytes into the stack, decreasing the stack pointer (ESP = ESP - 4
) and every POP
instruction will pop exactly 4 bytes off of the stack, increasing the stack pointer (ESP = ESP + 4
).
With that in mind, and knowing that we need to remove 8 bytes of the stack to then return to 0104EBA8
which has a pointer to our controlled buffer, we need to find an address that contains a sequence of these instructions:
The first POP
will remove the first 4 bytes of the stack, the next POP
the other 4 bytes. The RET
will place the pointer at 0104EBA8
to EIP
which will redirect the execution flow to our buffer.
We can find those 3 instructions using many ways. I will use mona.py
:
This will tell mona.py
to find POP/POP/RET
instruction sequences and omit addresses with null characters (-cp nonull
), omit addresses on modules compiled with SafeSEH
(-cm safeseh=off
), and omit addresses on modules of the OS
(-o
).

And we got 12 different options. We can choose any of those. I will choose the sequence at 625011FB
just because :)
We can now update our exploit with that address:
And run it:

Weeeeeeeh! We overwrote the SEH
handler, triggered the exception, and redirected to a POP/POP/RET
sequence that returned to our controlled buffer!
However…!
We landed only 4 bytes before our injected POP/POP/RET
address. Remember the _EXCEPTION_REGISTRATION_RECORD
structure? It has 2 members: the SEH
handler, which we are overwriting with the POP/POP/RET
address, and the pointer to the next exception handler, also called nSEH
. Well, we landed at nSEH
.
However, just after the injected address there’s a good 43 bytes buffer, and before nSEH
we had our 3500+ bytes buffer of A
.
So, what’s next? That’s right! We must jump around again!
Jump around
We only have 4 bytes to perform our first jump. Fortunately for us, short jumps are only 2 bytes long.
We must perform a short jump of at least 8 bytes to pass over our injected POP/POP/RET
address and land on our C
buffer. We can get the needed opcodes using nasm_shell.rb
:
Fun fact: Note that we told to perform a 10 byte (0xa
) jump, and the returned opcode was EB08
. It’s because the JMP
will calculate the offset including the length of the JMP
instruction, which is 2 bytes.
OK, with our short jump opcode we can update our exploit:
And see if we could effectively jump over the SEH
handler:

es! We are past our SEH
handler. Now we have enough room of bytes to perform a long jump back to the start of our A
buffer. With the debugger’s help, we get the needed offset by simply telling it to jump to the start of our A
buffer and letting it calculate the offset.

As you can see, the resultant bytes are E9 16 F2 FF FF
.
Let’s update our exploit with that:
And check it:

Great! All that’s left is to insert a shellcode. Let’s do that.
Getting shell
We can create a reverse shellcode using msfvenom
from Metasploit:
And with that, we can have the final exploit:
Let’s check it:

Our shell! We are getting good at it, aren’t we?
You can download the final exploit here
Conclusion
Exploiting applications using SEH
overwriting is just a little different than the vanilla EIP
overwrite. However, you must take care of the little details all the way down to get a successful exploitation. You can check different SEH
-based exploits at the Vulnserver LTER, the QuickZIP exploiting and the Netscanner exploiting articles.
Get started with Fluid Attacks' PTaaS right now
Related posts