Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Windows Kernel Exploitation - Get a token and write Shellcode.pdf

Yavuz Han
November 10, 2019

Windows Kernel Exploitation - Get a token and write Shellcode.pdf

Presented at TTMO - https://twitter.com/__TTMO__

Yavuz Han

November 10, 2019

Other Decks in Research


  1. 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
  2. #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
  3. 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 :)
  4. 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.
  5. 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.
  6. 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.
  7. 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 :)
  8. Environments - Mac OS - as a Host system (it

    can be also Linux or Windows) - 2 VM Windows7x86 :
 ** Debugger : with windbg installed
 ** Debugee : Kernel debugging
  9. Setting up the Debugger - We need to install first

    Windows10 SDK (only Windbg) Type to enter a caption.
  10. 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
  11. 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
  12. 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.
  13. - Windows Host: **\\.\pipe\(any name) - Linux Host :

    name like a ‘serial’) Setting up the Serial Ports
  14. 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.
  15. - 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
  16. 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
  17. - 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
  18. Install HEVD Symbols on Debugger Machine - control all modules

    which one is installed
 - 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 

  19. - 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
  20. 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]
  21. 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!
  22. 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
  23. KPCR (Kernel Processor Control Region) - Within the Windows operating

    system, there is one KPCR per cpu in the system. ShellCode
  24. 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
  25. KTHREAD (Kernel Thread) - KTHREAD depends on ETHREAD data structure

    - KTHREAD is the first part of the
 ETHREAD data structure. ShellCode
  26. 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
  27. Compiling ShellCode - We can use NASM or YASM -

    We’ll need also HxD Editor ShellCode
  28. 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.