Windows Kernel Exploitation - Get a token and write Shellcode Yavuz Han 

Agendaa - #whomai - Why debugging Kernel?
 - Kernel Mode vs User mode
 - Last Windows Kernel vulnerabilities
 - Windows Kernel Debugging
 -> Setting up the our lab
 -> Setting up the Debugger -Symbol Path-
 -> Setting up the Debugee -> Setting up the Serial Ports
 -> Test and run
 - HackSys Extreme Vulnerable Windows Driver
 -> Setting up the HEVD
 -> Install HEVD symbols on Debugger Machine -> Get a Token with Kd - How can we write SHELLCODE?
 - Last Windows Kernel Vulnerabilities 

LET’S START 

#whoami Yavuz Han - Security Researcher
 - Twitter @yavuzwb
 - Website : manalysiz.com
 - Mail : [email protected] Interests 
 Reverse Engineering
 Malware Research
 Windows Kernel Exploitation
 Windows Internals, 
 Exploit Development 

Why debugging Kernel? - To better understand how works operating system - To better understand what’s happened when I got blue screen - To better understand how works a drivers (also analysis) - To better understand how works a Rootkits - It can be also just for a fun :) 

User Mode - When run any application, windows created process to application - Then process creating private virtual address for application - Other apps can not change this private virtual address space because it’s private. - So when program crash, it's effecting only one program. 

Kernel Mode - The Kernel have a full access to; CPU, Memory, Devicess - There is no any private virtual address space - All code running in kernel mode share a single virtual address space - That’s mean if some driver crash in kernel mode, the whole operating system crashes. 

Additional Notes Kernel Mode : Normally, drivers are executing in kernel modes but not all of drivers. Because some drivers are executing in user mode. We can call that is user mode drivers. User Mode : Virtual address space is limited. Because the goal is to prevent disruption of integrity. 

Question? What’s happen if some process in user mode, try to access to Kernel mode? - Normally, crash. Let’s think about malicious codes (with Dll) or some vulnerabilities? New boss in our system :) 

Windows Kernel Debugging Setting up to our lab 

Environments - Mac OS - as a Host system (it can be also Linux or Windows) - 2 VM Windows7x86 :
 ** Debugger : with windbg installed
 ** Debugee : Kernel debugging 

Setting up the Debugger - We need to install first Windows10 SDK (only Windbg) Type to enter a caption. 

Setting up the Debugger
 -Symbol Path- - We are going to Computer/Properties/ Advanced System Settings/Environment Variables - Create new User Variable :
 ** Variable Name = _NT_SYMBOL_PATH
 ** Variable value = SRV*C:\Symbols*https:// msdl.microsoft.com/download/symbols 

Setting up the Target - We’ll control this vm from the debugger vm. 
 - That’s why we will enable to control + First, opening CMD with Administrator :
 ** We’ll use a tool BCDEdit 
 (BCDEdit : command-line tool for managing Boot Configuration Data)
 
 + bcdedit /copy {current} /d "Debug me"
 ** First we copy the current settings into a new entry, title is “Debug me” ** It gives us in return a GUID of the new entry. We need to copy it and use to enable debugging on this entry
 + bcdedit /debug {GUID} on
 + bcdedit /dbgsettings - we’ll see settings 

Setting up the Target When we run target VM, we’ll see this screen 

Setting up the Serial Ports - We have to make a connection between with Debugger and Target - That’s why we’ll use Serial Port COM1:
 ** Configuration is very simple
 ** We just have to make sure that the debugger and the target have the same name set. 

No content

- Windows Host: **\\.\pipe\(any name) - Linux Host :
 **/tmp/(any name like a ‘serial’) Setting up the Serial Ports 

Test and Run - We’ll first run our debugger machine then openin Windbg with kernel mode - Second, we’ll run our target machine Type to enter a caption. 

HackSys Extreme Vulnerable Windows Driver 

- It’s created by Ashfaq Ansari - Purpose was help to learn and polish their exploitation skills at Kernel level for security researchers - HackSys Extreme Vulnerable Driver caters wide range of vulnerabilities ranging from simple Buffer Overflow to complex Use After Free, Uninitialized Variable and Pool Overflow. - This allows the researchers to explore the different exploitation techniques for every implemented vulnerabilities HackSys Extreme Vulnerable Windows Driver 

Vulnerabilities Implemented Type to enter a caption. 

Setting up to the HEVD Debugger VM
 
 - Visual Studio (2012 version) - Windbg with Symbols Target (Debugee) VM
 
 - Visual Studio (2015 Community Edition)
 - DebugView
 - HackSys Extreme Vulnerable Driver (HEVD) + Kaynak Kodlar - OSR Driver Loader 

- We’ll do first enable to DebugStrings
 kd>ed nt!Kd_DEFAULT_MASK 8
 kd>ed nt!Kd_IHVDRIVER_MASK 8 kd>g - Second, we’ll instal HEVD with OSRLoader software - Then we’ll do install HEVD on Windbg - Lastly, we’ll install exploit files on Debugee VM
 *Do not forget compile the source codes Setting up to the HEVD 

No content

Install HEVD Symbols on Debugger Machine - control all modules which one is installed
 kd>lm
 - Find HEVD
 - Then we’ll see ‘HEVD.pdb file not found’ error - We’ll create 
 C:\Projects\hevd\build\driver\vulnerable\x86\HEVD\HEVD.pdp - Create driver Folder for driver files
 C:\Projects\hevd\driver\hevd\all driver files - Additional notes: Do not forget to build exploit files 
 
 

- First, we’ll listening all the processes. 
 - Second, we’ll get token for system and cmd - Lastly, we’ll copied the Token of System to into cmd. - So we’ll see result Get a TOKEN with Kd 

Get a TOKEN with Kd - kd>!dml_proc —> to see running processes - kd>!process [our target] - kd>dt _EPROCESS —> to get TOKEN offset - kd>dt nt!_TOKEN [EPROCESS address] 

No content

Get a TOKEN with Kd 

Get a TOKEN with Kd 

How can we write SHELLCODE? 

ShellCode What will we do here? 1- Find the data structure of the system process 2- Get TOKEN for this process 3- Put in the “Token” field of the target process 4- Save the system from crash! 

1- First, find the beginning of the PROCESS structure Because in OS architecture, almost every process is defined in EPROCESS structure. 2- If we want review running processes in the system, we need access to any place where transactions are held. 3- That’s why we will check KPCR (Kernel Processor Control Region) ShellCode 

Our strategy : KPCR—>KPRCB—>KHREAD—>KAPC_STATE—>EPROCESS ShellCode 

KPCR (Kernel Processor Control Region) - Within the Windows operating system, there is one KPCR per cpu in the system. ShellCode 

KPRCB (Kernel Processor Control Block) - We can learn about the kernel processor control block. So it will give us the location of the KTHREAD structure for the thread that the processor runs. ShellCode 

To access KTHREAD data structure; PrcbData (Ox120) + CurrentThread (0x004) = 0x124 ShellCode 

KTHREAD (Kernel Thread) - KTHREAD depends on ETHREAD data structure
 - KTHREAD is the first part of the
 ETHREAD data structure. ShellCode 

KAPC_STATE - Each thread keeps track of the process that it is associated with. It keeps track of this in the KAPC_STATE structure. - This is good for us since we’re trying to get to the process so we can find it’s token. ShellCode 

To access KPROCESS data structure ApcState (0x040) + Process (0x010) = 0x050 ShellCode 

GetCurrentProcess - We will get the address of the current running process. ShellCode 

EPROCESS 
 - We’ll get UniqueProcessId, ActiveProcessLinks ve Token offset in EPROCESS structure ShellCode 

Lets check TOKEN ShellCode 

No content

Compiling ShellCode - We can use NASM or YASM - We’ll need also HxD Editor ShellCode 

1- https://github.com/hacksysteam 2- https://docs.microsoft.com/en-us/windows- hardware/drivers/debugger/ 3- https://ring0.info/ 4- Google :)) HackSys Extreme Vulnerable Windows Driver 

Last Windows Kernel Vulnerabilities CVE-2019-0859 is is a use-after-free issue in the Windows kernel that allows local privilege escalation (LPE). It’s being used in advanced persistent threat (APT) campaigns, the researchers said, targeting 64-bit versions of Windows (from Windows 7 to older builds of Windows 10). CVE-2018-8611 is a zero-day vulnerability in ntoskrnl.exe. Type to enter a caption. Type to enter a caption. 

THANK YOU - Twitter @yavuzwb
 - Website : manalysiz.com
 - Mail : [email protected]