Book Image

Hands-On Penetration Testing on Windows

By : Phil Bramwell
Book Image

Hands-On Penetration Testing on Windows

By: Phil Bramwell

Overview of this book

Windows has always been the go-to platform for users around the globe to perform administration and ad hoc tasks, in settings that range from small offices to global enterprises, and this massive footprint makes securing Windows a unique challenge. This book will enable you to distinguish yourself to your clients. In this book, you'll learn advanced techniques to attack Windows environments from the indispensable toolkit that is Kali Linux. We'll work through core network hacking concepts and advanced Windows exploitation techniques, such as stack and heap overflows, precision heap spraying, and kernel exploitation, using coding principles that allow you to leverage powerful Python scripts and shellcode. We'll wrap up with post-exploitation strategies that enable you to go deeper and keep your access. Finally, we'll introduce kernel hacking fundamentals and fuzzing testing, so you can discover vulnerabilities and write custom exploits. By the end of this book, you'll be well-versed in identifying vulnerabilities within the Windows OS and developing the desired solutions for them.
Table of Contents (25 chapters)
Title Page
Dedication
Packt Upsell
Contributors
Preface
Index

Getting hands-on with the return-to-PLT attack


I say this about a lot of topics, but the Procedure Linkage Table (PLT) and the Global Offset Table (GOT) are subjects that deserve their own book. But we'll try to run through a crash course to understand how we're going to get around memory space randomization. Our executable is not a position-independent executable thanks to our -no-pie compilation configuration, so the actual location of global structures in the program wasn't known at compile time. The GOT is literally a table of addresses used by the executable during runtime to convert PIE addresses to absolute ones. At runtime, our executable needs its shared libraries; these are loaded and linked by the dynamic linker during the bootstrapping process. This is when the GOT is updated.

Since the addresses are dynamically linked at runtime, the compiler doesn't really know if the addresses in our non-position-independent code will be resolved from the GOT. So with the -no-pie specification...