Sign In Start Free Trial
Account

Add to playlist

Create a Playlist

Modal Close icon
You need to login to use this feature.
  • Hands-On Penetration Testing on Windows
  • Toc
  • feedback
Hands-On Penetration Testing on Windows

Hands-On Penetration Testing on Windows

By : Phil Bramwell
5 (3)
close
Hands-On Penetration Testing on Windows

Hands-On Penetration Testing on Windows

5 (3)
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 (19 chapters)
close

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

bookmark search playlist download font-size

Change the font size

margin-width

Change margin width

day-mode

Change background colour

Close icon Search
Country selected

Close icon Your notes and bookmarks

Delete Bookmark

Modal Close icon
Are you sure you want to delete it?
Cancel
Yes, Delete