Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Managed Detection & Response

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

Co-Managed SOC (SIEM)

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

Advisory & Diagnostics

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

Penetration Testing

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

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

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

Digital Forensics & Incident Response

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

Firewall & Technology Management

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

Offensive Security
Solutions to maximize your security ROI
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
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


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.


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.”:



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:



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*

Symbol search path is: SRV*C:\SymCache*
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.




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.   

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*”. This will make sure that all symbols downloaded go to the local path “C:\SymCache”.



Figure 4 - WinDBG Symbol Path




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

Fare Thee Well ModSecurity: End-of-Life and Last Commercial Rules Update for June 2024

A Fourteen-Year Journey Comes to an End In June 2010, Trustwave acquired Breach Security, which brought with it the popular Open-Source Web Application Firewall ModSecurity for Apache. At that time,...

Read More

Secure Access Service Edge: Another Multi-Tool for the SOC

Over the years, several security defense architectures have merged into a single solution. Endpoint detection tools can perform sophisticated detections and correlations that used to require a...

Read More

Search & Spoof: Abuse of Windows Search to Redirect to Malware

Trustwave SpiderLabs has detected a sophisticated malware campaign that leverages the Windows search functionality embedded in HTML code to deploy malware. We found the threat actors utilizing a...

Read More