Internet Exploiter: Understanding vulnerabilities in Internet Explorer

Internet Explorer has been a core part of the Microsoft Windows operating system since 1995. While further development has officially ceased in favour of the Edge browser, Microsoft continues to issue patches due to its continued use. Current statistics estimate that approximately 4% of the internet still uses Internet Explorer, thus continuing to have a larger user-base than browsers such as Opera. Yet, despite the persistent popularity of this browser, there are very few modern resources delving into it beyond a high level view or a paragraph on a few low-level aspects.

This blog post aims to provide some much needed insight into how one of the core components of Internet Explorer operates internally by examining how vulnerabilities such as use-after-frees can arise in it.

For those who wish to view the final exploit, it can be found here.

During this post, CVE-2020-0674 will be the point of focus. It was discovered by Qihoo 360 who had found it being used in the wild. The vulnerability itself resides in the legacy "JavaScript" (JScript !== JavaScript apparently) engine module jscript.dll.

The description for this bug is that a use-after-free exists in the Array object's sort function when a callback function is executed. The arguments for this function are not tracked by the garbage collector (GC) and so can be used to cause a use-after-free.

A basic proof-of-concept (PoC) trigger can be written for this bug, as shown below:

When this code is executed by using the wscript program, the stack trace below shows the crash, confirming that the crash occurred during the IsAStringObj method.

Although this is the legacy engine, Internet Explorer 11 can be made to load this dll instead of the current one by forcing the browser into Internet Explorer 8 Compatibility Mode.

It's possible to do this by using a scripting language attribute not supported by JScript 9, such as the encode or compact languages.

The video showing that this vulnerability can be triggered in Internet Explorer 11 can be seen below:

While it's trivial to build a trigger for a bug using just the description, without understanding much about what the underlying cause is a significant amount of knowledge is missed and doing so can also lead to potentially missing undiscovered bugs that are similar in nature.

Before diving into the vulnerability, the JScript engine itself must be explored. You cannot find the root-cause of a vulnerability if you don't understand the code it's in.

JScript is an interpreted language, meaning that there are a number of components that are involved in the process of executing code:

• Scanning - Takes the input script and tokenizes it (The Scanner class handles this). This stage checks lexical correctness.
• Parsing and Compilation - Creates an AST and generates Microsoft P-Code (Both performed by the Parser class). This stage checks the syntactic correctness.
• Execution - Takes the generated P-Code and executes it.

It's important to note that while Scanning and Parsing may seem like separate steps, in reality they interleave each other. This is done to avoid wasting processing power when an error is encountered. To explain this, consider the following script:

The first line would trigger an error because although 23 + is lexically correct, it is not syntactically correct. However, if scanning were to be independent of parsing, the remainder of the code would be scanned and immediately discarded due to the error, thus wasting resources on redundant tasks.

After these two steps are completed, the execution of the P-Code takes place. P-Code is a series of intermediate languages written by Microsoft and used in the implementation of languages like Microsoft Visual Basic. JScript uses a P-Code language to execute code using simple opcodes in a stack-based machine. The core of this functionality resides in the CScriptRuntime::Run function, which uses a jump table to decide which basic operation to perform using the opcode.

The example below aims to give an idea of how JavaScript code translates into P-Code:

This would result in the following P-Code (Excluding calls to the Garbage Collector):

After executing the instructions at points 1-5 the variable stack looks like the following:

An understanding of how various items are laid out in memory is required since the vulnerability relates to how the engine handles variable tracking. This information is exceedingly relevant to identifying the root cause of this vulnerability.

In JScript variables are represented in the following VAR structure:

It is essentially the same as the VARIANT structure. A number of type values can be found on the Microsoft Docs website.

The stack-based machine described in the interpreter section operates on a stack that holds values stored as VAR structs.

With regards to objects, JScript separates them into two categories: Native and non-native. Non-native objects are ones that are constructed by web developers in JavaScript. An example of this would be:

Native objects (also known as builtins) on the other hand are ones for which the functionality is programmed into the engine itself. Examples of this are Date, RegExp, and Array. These classes all inherit from the NameTbl class, which defines the default behaviour for an object. Below you can see how the Array object overrides some of the inherited functions:

Strings that have been parsed by the engine (such as variable names in the JavaScript code that the engine needs to find) are stored in a structure called a symbol. It's represented using a SYM structure, as follows:

While SYMs are used for lookups, the names and property values themselves are actually stored in a separate structure. This is how a variable name is associated with a particular object or value:

Since CVE-2020-0674 is a garbage collection issue, it's crucial to understand how the legacy JScript garbage collector works internally.

The GC functions in the engine are used to perform a number of steps:

• Mark - Traverses the VARs and marks them to be freed.
• Scavenge - Calls the scavenger functions to identify which VARs are currently referenced and unmarks them.
• Reclaim - Frees the VARs that are still marked.

In jscript.dll, the GC uses a series of doubly-linked blocks. Each block contains storage space for 100 VAR structs. Blocks take the form of a structure called a GcBlock:

When an entire block is freed (In either the GcBlockFactory::FreeBlk function or the GcAlloc::ReclaimGarbage function) it is added to a list of free blocks, ready to be used by the next block allocation. However, if 50 blocks are already in the free list then the block is not added to the list but instead deallocated.

In order to free a block, all the VARs it contains must first be freed. A VAR is marked for collection by setting the 12th bit of the type. If a scavenger function declares that this variable is still in use, the bit is set to 0.

The main logic for all of this is in the GcContext::CollectCore function which marks the variables (GcContext::SetMark), calls the scavenger functions, and then reclaims them (GcContext::Reclaim).

Scavenger functions are either root scavengers such as ScavVarList::ScavengeRoots or object scavengers that execute the NameTbl::ScavengeCore function (or the function that the object has overridden it with, for example RegExpObj::ScavengeCore) that run for each object that currently exists.

The garbage collection process is triggered after a number of heuristics but can be called manually in the code by using the CollectGarbage() JavaScript function, as done in the proof-of-concept. This can be used to the advantage of an exploit developer to perform heap feng-shui and manipulate the heap to structure chunks in a particular way to make vulnerability exploitation easier.

Now onto analysing the root cause of the vulnerability in question. To begin with, differential debugging can be used. This is a technique whereby an individual traces two executions and compares the resulting paths. In doing so it's possible to identify differences in the execution and therefore the changes that have been made to the code, making it especially relevant to reverse engineering.

By viewing the function traces during the affected code, the patch is significantly clearer. With the basic understanding of the JScript GC above, it's evident that in the original trigger the variables firstE1 and secondE1 are not linked upon creation. Differential debugging can be used before sort is called up to just as the callback begins executing.

The minimised test case for this is seen below:

WScript.Echo is used here as a blocking function that provides a popup (Similar to the usual alert JavaScript function) at either end of the interesting functionality. When the first Echo call is hit, function tracing is started. It is then stopped when the second Echo call is hit.

This PoC was tested on updates KB4534251 (before the patch) and KB4537767 (after the patch) and the results were compared.

There were a number of changes to functions which was likely down to refactoring by the development team such as the removal of the VAR::VAR function, and the change from the CallWithFrameOnStack function handling the main function call logic to being a wrapper for a new function called PerformCall (Perhaps to make patch-diffing a little harder due to unmatched function names or because the function name no longer matched the code itself).

After reducing the function calls that remain the same, the clear point of difference is that a new object called ScavVarList has been created prior to the CScriptRuntime::Run call. During the initialisation of the object, there is also a call to IScavengerBase::LinkToGc which indicates that this addition might be the key to the patch.

As the name suggests, ScavVarList is a scavenger object that un-marks objects during garbage collection and therefore fits with the description of the vulnerability.

To make this clearer, patch-diffing can be used to identify where this object is created in PerformCall and what is done prior to the function call in CallWithFrameOnStack.

Both functions clearly differ fairly greatly, however a number of basic blocks remain in both. By highlighting the important lines of this code before and at the actual CScriptRuntime::Run call, it's clear that the main difference in the setup of the call is the introduction of the ScavVarList object:

Although at this point the root cause might seem clear, significant refactoring was done between the vulnerable version and the patched version so verification is fairly crucial. By breaking on the call to IScavengerBase::LinkToGc and skipping over, the original bug is triggered with the same crash, thus confirming the theory.

Use-after-free bugs are interesting but in order to exploit them, much more work must be done. In the exploitation section, some concepts for the x64 version of jscript are discussed. The first step is to convert this bug into a type confusion by reallocating the freed area that the untracked variable points to and constructing a fake object. Type confusion allows for a much wider range of attacks to be performed by constructing exploit primitives.

In order to cause a type confusion, let's consider the original memory layout once the sort callback is entered and untracked_1 is set:

The variable untracked_1 points to an Object in an Array. In memory this object is located in a GcBlock struct, as was mentioned in the GC section. Note that prior to the object that the untracked variable points to, there are 50 other GcBlocks (Equating to 500 stored vars). This is fundamental to exploiting the use-after-free since the first 50 GcBlocks will not be deallocated but instead be added to a list of free blocks.

Once the CollectGarbage function is called, the memory layout will instead look like the following:

The untracked_1 variable now points to freed memory. The aim from here is to allocate controlled data over this section. In order to allocate over these free chunks, the size of the data must match (or almost match) the size of the free chunk. This chunk size can be calculated by looking at the GcBlock structure:

• Forward pointer (8 bytes)
• Backward pointer (8 bytes)
• 100 VAR structs (100 * 24)
  • VAR type (8 bytes)
  • VAR object pointer (8 bytes)
  • VAR unused or next pointer (8 bytes)

This results in a 0x970-byte chunk.

The untracked variable could be pointing anywhere in the VAR array of this block, so the obvious solution is to spray the target data throughout the entire chunk (in essence, making a fake GcBlock). It's also unknown which block the variable will be pointing in so a large number of GcBlocks will have to be freed so the fake GcBlock spray can be repeated a number of times.

A fake VAR struct can be generated using the helper function called makeVariant discussed in Mcafee's analysis of CVE-2018-8653. Below is the annotated form of this function:

This function generates a string of 24 bytes (The size of a VAR struct) that appears to be a VAR in memory.

One way to cause an allocation of a given size is to use JavaScript properties to cause an allocation. In JScript, a NameList is used to link information such as property names and when a new property is created it allocates space to store the VVAL structure discussed previously. However, the size of our string can't be exactly what is desired since structure headers, character size conversions, and any data that needs to be stored with the VVAL structure need to be considered.

The NameList::FCreateVval function uses the NoRelAlloc::PvAlloc function to allocate data. The size that FCreateVval passes to PvAlloc is:

PvAlloc then uses this value in a second equation that is used as the parameter for the malloc allocation:

A property name with length 0x239 therefore results in an allocation of exactly 0x970 bytes. When this chunk is allocated, the UTF-16 property name is copied over, starting at offset 0x48. This means that padding is required to align the fake VARs with GcBlock VARs. The amount of padding is calculated by the following:

By repeating this, there will eventually be an overlap between the location pointed to by the untracked variable and a property name string. The layout in memory will therefore be as follows:

This overlap will allow the fake VAR to be treated as a real VAR. A proof-of-concept for type confusion can be seen below:

After this is executed, a popup will occur showing the number 1234, proving a type confusion from a property name string to an integer VAR.

However there is an obvious problem with this methodology. Currently the probability of success is still quite low as there is only one untracked pointer. Multiple untracked variables would be needed in order to increase the chance of an overlap. Ivan Fratric in his partial exploit for CVE-2018-8353 (in which the lastIndex property of a RegExp object was untracked) created a number of RegExp objects and used the lastIndex of each one to point to a different offset in the target array. This meant that once the objects in the array were freed, each of those RegExp objects would point to an area that could have been overlapped:

However, running the sort function multiple times in succession isn't an option since the GC has to occur within it, still leaving only two untracked variables being useful. A comparable technique for this is to instead use recursion. The sort function will call sort on an array with itself as a callback. Each depth of this recursion adds two more untracked variables. The resulting sort function becomes as so:

The reason for using object properties for the exploit is twofold. As well as supporting the allocation of a specific size it can be used to leak addresses in a number of different ways, therefore bypassing ASLR.

The first is made possible by the fact that the object property string is stored in the first half of the allocated area it's possible to leak pointers that were left over from the previous GcBlock structure because heap blocks are not zeroed out when freed or allocated for performance reasons. This means that a fake VAR can be created and only supply the type value. Consider a freed block that contained the following VARs:

By adding one character to the end of the VAR spray it's possible to alter the type of the last variable:

Since the type has been changed from 0x81 to 0x5, the obj_ptr takes a different meaning. In this case, 0x5 is the type value for a 64-bit float and the obj_ptr value is treated as a float value instead of a pointer which can be read from to leak the object pointer. The fake GcBlock generation code could therefore be changed to the following:

The second technique has proven to be much more useful and involves leaking the pointer to the next property from the VVAL struct. It involves manipulating the hash value in the struct to act as a VAR type. By looking at the hash function, it's clear that a single character name can be used to cause the hash value to be a particular result:

If an untracked variable were pointing to the hash value in the VVAL struct (by carefully padding property names so this occurs), the hash would be treated as the type of that VAR and the next property pointer would be treated as the object pointer. The question then arises how a single character name could be used to create a string that's large enough to cause the reallocation of a freed GcBlock. This can be solved by understanding why PvAlloc operates the way that it does; the reason that allocating a 0x239-character property name expands during the allocation calculation to 0x970 bytes is because PvAlloc isn't allocating for one VVAL but also for any other related VVAL structs that can fit in that area, such as other property names for a particular object. Therefore allocating a single-byte property name "\u0005" after this 0x239-character property name is created will cause PvAlloc to return a pointer inside the 0x970-byte block just after the previous property name because the original VVAL only took up 0x4fa bytes (VVAL struct + name string), leaving 0x476 bytes of free space remaining in the allocated area.

In order to leak the pointer to the next property, a third property must be made in order to fill the next property pointer of the hash-manipulating property.

This can be written in JavaScript as the following sort function:

This results in the following VVAL in memory, in which the hash and the name_len combine to be 0x200000005, making the VAR type 0x0005:

One of the most useful primitives in exploitation is an arbitrary read primitive. Combined with an infoleak, it can prove to be incredibly useful, allowing the attacker to continually traverse pointers in objects to identify the address of a target destination. In JScript there are a number of ways you can create an arbitrary read primitive.

One trivial way involves constructing a fake string object in which the object pointer of the VAR is the location to be read. The string method charCodeAt could be used to read the WORD value at that address. The caveat of this method is that if the DWORD prior to the address is null, then no bytes can be read from the address. This is due to the string object being a BSTR, causing the DWORD before the start of the string to act as the size of the string. It's possible to work around this issue by instead using the length property to read several bytes. A right shift must also be considered since the actual length value (the BSTR length) is divided by two since the BSTR counts characters as bytes, whereas JavaScript counts characters in UTF-16. Therefore, an arbitrary byte can be read by setting the string pointer two bytes ahead, shifting the length value right by 7 more bits and performing an AND operation on the value with 0xFF to read the character value.

After the initial exploit is run to create a number of pointers to string objects, the vulnerable function does not need to be re-run. Since the untracked variables have been saved in an array, their object pointers still point to the original GcBlock addresses so all that needs to be done is to remove the existing properties property values, collect the garbage to erase them, and replace them by spraying new ones. The stability of this method can be improved by spraying identification numbers during the exploit to find the exact object that needs to be freed in order to reallocate over a selected untracked variable. For example:

Once this has been performed, the target object can be freed and reallocated easily by creating the following JavaScript function:

Once the location can be reliably rewritten, the next step is to create a VAR that points to the name string of the final property. Since this name can be changed using the rewrite function, it can be used to create a fake VAR, as so:

With this fake object, the rewrite function can be used to create a read primitive by changing the fake object string pointer to the target address:

An alternative primitive exists for reading up to 0xffffffff bytes from an offset. For the 32-bit browser, this allows the entire address-space after the variable to be referenced. However, 64-bit means that this is only useful for reading a small area of memory. It involves constructing a string such as:

By creating a large number of variables with this string, the GcBlock will be sprayed with the string pointer. The first infoleak technique discussed above can then be used to leak the address of the string. Once this address is obtained, the type-confusion technique can be used to create a new string VAR in which the object pointer is 4 bytes ahead of the string location. This will cause 0xffffffff to be treated as the BSTR length, allowing the charCodeAt function to be used to read the value of arbitrary memory addresses.

A third option could be used in which several variables are almost entirely overlapped. This option is much more stable but has limitations. Consider the following VAR:

The VAR type is 5, causing the object pointer to be treated as a float value. Now consider a second variable that points to a VAR 2 bytes before the start of this VAR:

These two VARs almost completely overlap. By spraying the uninitialised memory prior to creating these variables, it would be possible to overwrite the two bytes of out-of-bounds memory and thus change the type of the overlapping variable:

If this second variable is made a string, as shown above, then the object pointer can be used for an arbitrary read. The float VAR can be used to alter the 48 most significant bits of the string VAR object pointer, however the last 16 bits cannot be changed.

For the purpose of this exploit, the first option is going to be used.

During the exploitation process the addresses of a number of variables will need to be found such as leaking a JScript vftable or when getting the address of strings. At this point, a VVAL pointer has been leaked and the exact object that needs to be freed and reallocated has been identified, forming a read primitive.

The address-of primitive becomes trivial to implement using the functions discussed in the previous section:

The above code assumes that the object will be located within the 32-bit range, as it has proven to be during testing. It works by setting the VAR at the start of the leaked VVAL location to be the target object, and replaces the arbitrary read string to point to the object pointer of this VAR. Once this has been read, it is repeated with the second VAR and the object pointer is retrieved, as so:

Since there is no way to know what versions of DLLs are being used on the target system and therefore what the offsets are to required functions, identifying the base of these modules must be done programmatically using an infoleak and the read primitive discussed in the previous segment. The basic overview for this is as follows:

1. Leak a module pointer from an object.
2. Set the lower 16 bits of the address to 0.
3. Check whether the DOS header or stub is found at the expected offset from the base.
4. If not, decrement the address by 0x10000.
5. Repeat 2, 3, and 4 until the DOS header or stub is identified.

Step one is fairly simple. Starting with leaking a jscript.dll pointer, all that needs to be done is:

• Create a new JavaScript object.
• Use the addrof primitive discussed above to get the address of the VAR struct.
• Follow the object pointers in the VAR (offset 8) to reach the main object (For example a RegExpObj or NameTbl object).
• Read the vftable pointer at offset 0.

Implementing steps 2 to 5 in JavaScript can be done as follows:

Once the base is discovered, the next step is to find an address belonging to the target DLL we want to use a function in. At the base of jscript.dll is the IMAGE_DOS_HEADER struct.

After this header is the DOS stub code, usually used to display that the executable cannot be run on DOS. The member e_lfanew contains the offset from the base of the module to the IMAGE_NT_HEADERS struct. This struct contains wraps around a second struct called IMAGE_OPTIONAL_HEADER which contains more information about the PE file.

The important part from here is the DataDirectory member. This array contains a number of IMAGE_DATA_DIRECTORY structs that give the offsets to various data directories, such as the Export and Import directories. The offsets of each of these directories is static from the start of the IMAGE_OPTIONAL_HEADER, with the Export directory at offset 0x70 and the Import directory at offset 0x78.

The Import directory contains a repeated structure that is used for each imported module. The structure contains two important members: ModuleName and ImportAddressTable(IAT). ModuleName points to a string containing the module name ("msvcrt.dll", for example) and ImportAddressTable points to an array of imported function pointers. By selecting the first function in the IAT, the steps described earlier for jscript.dll can be repeated to identify the base of the target module.

The following function shows how this can be performed in the exploit:

Once the base of the target module has been found, the target function must be located. This is done by parsing the Export directory in the target module. The Export directory uses one structure containing three important members: AddressOfFunctions, AddressOfNames, and AddressOfNameOrdinals. Using these, it's possible to find the desired target function. AddressOfNames is an array of pointers to function name strings. Once the desired function is found by iterating through the array, the index of that name is used as an index for the AddressOfNameOrdinals array. This array contains a series of numbers that act as indexes for the AddressOfFunctions array, which contains function pointers.

Since there are many similar names for functions, (For example _stricmp and _stricmp_l) the following JavaScript function is a little larger as to accommodate checking up to 16 bytes. It's also useful to note that the following function doesn't search the list of exports linearly but is instead optimised to use binary search, saving a significant amount of time:

At this point the target functions have been located but a trigger is still required to change the flow of execution and call them.

The simplest way to do this is to create a fake vftable in a fake object and trigger one of the functions. A good target for calling a vftable function is using the typeof operator. If the JScript type of the VAR pointing to the object is 0x81, then the code will call the function pointer at vftable + 0x138 to detect which type string to use:

However, this comes with a problem: only one address can be supplied. Since the attack is not on the stack, a ROP chain can't simply be written and executed. The solution to this problem is to move the stack pointer to another area of memory that is in control, such as a leaked string. This is a technique known as stack pivoting. In order to find the perfect gadget for this exploit, a number of conditions need to be met:

• Static DLL offsets cannot be relied upon - There's no way of knowing what version of the DLL is being used. As such, they must be easily locatable by finding and searching through functions in modules.
• Gadgets that wouldn't exist if a slight code alteration were made should be avoided in order to work through as many versions of the DLL as possible. An example of a bad choice would be a gadget such as mov rax, [rsp + 0x14h]; ret which may not exist if the stack frame were changed by adding a new variable to the function.

The rax register at the time of the vftable call contains the address of the vftable. Therefore, the gadget xchg eax, esp; retn was chosen for the stack pivot. The reason that the 32-bit registers in the instruction are acceptable for the exploit is because the heap location, although randomised, tends to be at a fairly low address. The xchg instruction also zeros out the unused bits of the registers (The upper 32-bits of rax and rsp), making this perfect for a 64-bit pivot.

The bytes that make up this gadget exist in the instruction setz bl in the msvcrt.dll function system, which sets the least significant byte of rbx to 0. This is later used as the return value (dictating success or not) of the function. Since this is not something that is likely to change, it meets the criteria listed above.

As for how instructions can be broken down into other instructions, this is made clearer by examining the bytes associated with them:

In order to find the bytes 94 C3 dynamically without static offsets, the Import directory must be traversed to find the system function address. This address is used as the base for the search, reading a WORD at a time until the required bytes are found:

Since the system function call is already found for the purpose of the pivot, it could also be used to pop calc without having to perform a VirtualProtect call to use shellcode. However, it turns out that the system function does not execute when TabProcGrowth is not set, likely due to how the standard protected mode (implemented since IE8) operates, making it less useful in an exploit. A better command execution function is WinExec in kernel32. This means that two more gadgets are required in order to place the first argument (the command string pointer) in the rcx register and the second argument (the display option) in the rdx register.

For the first argument, a good selection for this is in the msvcrt.dll function _hypot. This function operates using the xmm registers to perform operations on double-precision floating-point values. One gadget that appears in this function is mulsd xmm0, xmm3; ret which performs a scalar multiplication operation on the two registers. The bytes that make up this instruction are F2 0F 59 C3. Luckily the bytes 59 C3 are the bytes for the instructions pop rcx; retn.

The second argument gadget can be found in the similarly named msvcrt.dll function _hypotf function in the instruction cvtps2pd xmm0, xmm3 which consists of the bytes 0F 5A C3. This can be used to construct the pop rdx gadget with the second two bytes (5A C3).

Creating the ROP chain requires some forethought. Since the WinExec function calls other functions, additional bytes of padding are required before the chain to ensure that there is enough space for their stack frames:

After executing, calc is popped. It's important to note that IE will crash after WinExec is run since no process continuation was implemented in this exploit:

Shellcode execution has been a gold standard for exploit development since the beginning of time, however mitigation's such as DEP have prevented shellcode execution from being as straight forward as a single jump. DEP marks areas of memory such as the stack and heap as only readable and writable. Since there is no execute permission, shellcode placed in these segments cannot be executed. One way to get past this in Windows is to use the VirtualProtect function, which changes the permissions of a memory page. In order to supply all 4 arguments in the function, values need to be placed in the registers rcx, rdx, r8, and r9. Finding gadgets for all of these registers that match the conditions mentioned in the previous section turns out to be particularly difficult, however there is a solution to using single gadgets: NtContinue. This is an undocumented function in ntdll.dll that performs a system call to fill registers with given values from a CONTEXT structure, meaning that all four required registers can be filled in a single call.

In the case of VirtualProtect, the following values need to be set in the CONTEXT structure:

• The lpAddress parameter will point to the shellcode in the heap.
• The dwSize parameter contains the size of the shellcode.
• The flNewProtect parameter contains the new permissions for the shellcode. The permission here should be PAGE_EXECUTE_READWRITE (0x00000040).
• The lpflOldProtect parameter should be a pointer to a writable area of memory.

In order to do this, the following fake CONTEXT structure can be constructed in JavaScript:

The ROP chain after the stack pivot is therefore:

A working exploit is great but there are more than just built-in exploit mitigation's that could be considered. While the above exploit methods will work on a standard system, they won't work on systems that have additional security features. In this section the Enhanced Mitigation Experience Toolkit (EMET) will be briefly discussed. EMET is an exploit mitigation system that injects itself into processes in order to identify and prevent suspicious behaviour. There are several included detection techniques that must be considered for this exploit:

• Stack Pivot Detection
• Export Address Table Access Filtering (EAF and EAF+)

A number of additional rules, such as Caller Checks and Simulated Execution Flows, would have made exploiting this vulnerability significantly harder however are only included for 32-bit programs.

Although the end-of-life date for this software was 2018, it's replacement (Windows Defender Exploit Guard) is only compatible with Windows 10. This means that EMET would be the only official exploit mitigation toolkit run on Windows 7 target systems.

Because there has already been a lot of brilliant research on disabling EMET entirely, this section will focus on individually bypassing the detection techniques listed above that affect the exploit.

Despite its age, Internet Explorer is very much alive and well. Although many might be put off by the idea of researching this particular browser due to the lower user base compared to modern browsers such as Edge, the fact that vulnerabilities are still being found today and that it's continuing to be targeted by malicious actors is evidence that more eyes should be on it. This post has layed some of the groundwork for research into JScript in order to enable the next round of researchers to quickly get to grips with the target and begin to find and exploit vulnerabilities of their own.