Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Windows Debugging & Exploiting Part 1 - Environment Setup

Introduction

In this blog series, I will try to set some base knowledge for Windows system debugging & exploitation and present how to setup an environment for remote kernel debugging. This environment will be useful for learning Windows internals and indispensable for our future posts about its exploitation. About Windows internals, I really recommend the training from Pavel Yosifovich on Pluralsight that will expand your familiarity with the system if you are new to the topic.

Windows exploitation is certainly not an easy subject to learn since there are not many Windows challenges available. When you look at current CTFs for example, you will find only a few basic/introductory write-ups covering Windows protections and memory allocations, but I will try to write about the subject in future posts.

This series will be part of my studies too, so hopefully, this will help everyone in the same situation!

The Environment

For this environment, you will need a debugger, a couple of VMs and curiosity!

WinDBG is a debugger developed by Microsoft and we will need it for debugging user and kernel space. There are other options, but WinDBG is definitely the best tool for our endeavor, so let’s get it started!

We will also need two VMs for our lab. One will be utilized as the debugger machine and the other will act as a target system. In this case, we will proceed with a Windows 10 x64 for debugging -- this is chosen because of WinDBG Preview availability on the OS. As a target we will use Windows 7 x64, since it has fewer protections than Windows 10 and will make our life easier while we are studying. By the way, it is possible to enable a local kernel debugging but this doesn't allow the researcher to debug “live” like breakpoint functions on drivers, etc.

Target Machine

You will need to enable the debugging mode on this Windows machine, as it is not enabled by default. You can use an elevated prompt command (cmd.exe) and the “bcdedit” utility for this. In our case, we will configure our target machine to use a serial connection for debugging as follows:

C:\Windows\system32>bcdedit /dbgsettings serial debugport:1 baudrate:115200
The operation completed successfully.

C:\Windows\system32>bcdedit /debug on
The operation completed successfully.

If we were working with both Windows 10, we could enable the debug option with network settings. However, Windows 7 does not have this option, so we will use the serial connection.

Connection

Now that we've setup the debugger to use a serial connection we now need to add and configure a serial port for each machine. In my case, I am using the VMWare Workstation but this configuration can replicated on any VM vendor as VirtualBox. On Windows 7, you set “The end is the server.”:

 

Image001

Figure 1 - Virtual Machine settings from Windows 7

 

On Windows 10, you set the “The end is the client.”:

 

Configuring-win10Figure 2 - Virtual Machine settings from Windows 10

 

Debugger Machine

After the target machine is set with debug mode and both machines with a serial connection configured, we can now proceed with setting up WinDBG.

Open the WinDBG Preview, Go to "Attach to kernel", select "COM" and use this configuration below:

 

Com1-windbg

Figure 3 - WinDBG Preview COM Configuration on the Debugger Machine

 

This is tricky, this port name is not related to the name we gave to our port connection on the VMWare settings. This is actually the port on the device manager. Basically, if you did not have any port before this new one, you should only have one serial port, so you will use “com1”, however, if any other was there already, you will use “com2”, “com3”, etc.

 

Start Debugging

After the OK, you will connect to the target machine:

Microsoft (R) Windows Debugger Version 10.0.19494.1001 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\com1
Waiting to reconnect...
Connected to Windows 7 7601 x64 target at (Fri Oct 18 10:50:26.300 2019 (UTC - 3:00)), ptr64 TRUE
Kernel Debugger connection established.

************* Path validation summary **************
Response                         Time (ms) Location
Deferred SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols

Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (1 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17514.amd64fre.win7sp1_rtm.101119-1850
Machine Name:
Kernel base = 0xfffff800`02a01000 PsLoadedModuleList = 0xfffff800`02c46e90
Debug session time: Fri Oct 18 10:38:56.797 2019 (UTC - 3:00)
System Uptime: 0 days 0:04:03.716
Break instruction exception - code 80000003 (first chance)

*******************************************************
You are seeing this message because you pressed either

CTRL+C (if you run console kernel debugger) or,             
CTRL+BREAK (if you run GUI kernel debugger),

on your debugger machine's keyboard.

 

THIS IS NOT A BUG OR A SYSTEM CRASH

 

If you did not intend to break into the debugger, press the "g" key, then press the "Enter" key now. This message might immediately reappear. If it does, press "g" and "Enter" again.   
*******************************************************

nt!RtlpBreakWithStatusInstruction+0x1:
fffff800`02a79491 c3              ret


And we are good to go!

As you should note, there is a configuration regarding “Symbols”.  Symbols are basically the name given to the functions on user API and kernel files. This is extremely helpful. If you don’t have the symbols for NTDLL.dll for example, you see a function being called as ntdll!7fff’73049342 (random address) and that does not give any extra information about what is being executed.  However, if you have the symbols you will see what the function name is, for example: ntdll!RtlUserThreadStart. That can save some time helping identify what is actually happening in our code.

Microsoft provides a public repository for most if not all Windows versions. Vendors can also provide the PDB files for their applications as well, which is a really nice initiative. It is necessary to configure the server on the debugger and then the symbol files will be downloaded to your local computer. On WinDBG Preview, go to the Menu, Settings and set the Symbol path as “SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols”. This will make sure that all symbols downloaded go to the local path “C:\SymCache”.

 

Symbols

Figure 4 - WinDBG Symbol Path

 

 

Conclusion

Now we have the environment setup for our tests. In the next part, I’ll write about WinDBG functionalities to get familiar with debugging on Windows systems. I will then move on with some internals, application and kernel exploitation. If you have any doubts or comments, let me know! Hopefully, by the end of this series, you will have a new tool in your security arsenal. 

Latest SpiderLabs Blogs

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More