Cybersecurity Attacks – Red Team Strategies E-Book

Johann Rehberger

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 557

Veröffentlichungsjahr: 2020

Beschreibung

Develop your red team skills by learning essential foundational tactics, techniques, and procedures, and boost the overall security posture of your organization by leveraging the homefield advantage

Key Features

• Build, manage, and measure an offensive red team program
  
  


• Leverage the homefield advantage to stay ahead of your adversaries
  
  


• Understand core adversarial tactics and techniques, and protect pentesters and pentesting assets

Book Description

It's now more important than ever for organizations to be ready to detect and respond to security events and breaches. Preventive measures alone are not enough for dealing with adversaries. A well-rounded prevention, detection, and response program is required. This book will guide you through the stages of building a red team program, including strategies and homefield advantage opportunities to boost security.

The book starts by guiding you through establishing, managing, and measuring a red team program, including effective ways for sharing results and findings to raise awareness. Gradually, you'll learn about progressive operations such as cryptocurrency mining, focused privacy testing, targeting telemetry, and even blue team tooling. Later, you'll discover knowledge graphs and how to build them, then become well-versed with basic to advanced techniques related to hunting for credentials, and learn to automate Microsoft Office and browsers to your advantage. Finally, you'll get to grips with protecting assets using decoys, auditing, and alerting with examples for major operating systems.

By the end of this book, you'll have learned how to build, manage, and measure a red team program effectively and be well-versed with the fundamental operational techniques required to enhance your existing skills.

What you will learn

• Understand the risks associated with security breaches
  
  


• Implement strategies for building an effective penetration testing team
  
  


• Map out the homefield using knowledge graphs
  
  


• Hunt credentials using indexing and other practical techniques
  
  


• Gain blue team tooling insights to enhance your red team skills
  
  


• Communicate results and influence decision makers with appropriate data

Who this book is for

This is one of the few detailed cybersecurity books for penetration testers, cybersecurity analysts, security leaders and strategists, as well as red team members and chief information security officers (CISOs) looking to secure their organizations from adversaries. The program management part of this book will also be useful for beginners in the cybersecurity domain. To get the most out of this book, some penetration testing experience, and software engineering and debugging skills are necessary.

Leseprobe

Cybersecurity Attacks – Red Team Strategies

A practical guide to building a penetration testing program having homefield advantage

Johann Rehberger

BIRMINGHAM—MUMBAI

Cybersecurity Attacks – Red Team Strategies

Copyright © 2020 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Commissioning Editor: Vijin Boricha

Acquisition Editor: Meeta Rajani

Senior Editor: Arun Nadar

Content Development Editor: Pratik Andrade

Technical Editor: Prachi Sawant

Copy Editor: Safis Editing

Project Coordinator: Vaidehi Sawant

Proofreader: Safis Editing

Indexer: Rekha Nair

Production Designer: Jyoti Chauhan

First published: March 2020

Production reference: 1270320

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-83882-886-8

www.packt.com

To my parents, siblings, and anyone else close to me

– Johann Rehberger

Packt.com

Subscribe to our online digital library for full access to over 7,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.

Why subscribe?

Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionalsImprove your learning with Skill Plans built especially for youGet a free eBook or video every monthFully searchable for easy access to vital informationCopy and paste, print, and bookmark content

Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at packt.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.

At www.packt.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.

Contributors

About the author

Johann Rehberger has over fifteen years of experience in threat analysis, threat modeling, risk management, penetration testing, and red teaming. As part of his many years at Microsoft, Johann established a penetration test team in Azure Data and led the program as Principal Security Engineering Manager. Recently, he built out a red team at Uber and currently works as an independent security and software engineer. Johann is well versed in analysis, design, implementation, and testing of software systems. Additionally, he enjoys providing training and was an instructor for ethical hacking at the University of Washington. Johann contributed to the MITRE ATT&CK framework and holds a master's in computer security from the University of Liverpool.

Throughout my career, I learned from countless smart people that I want to thank. A lot of content in this book is inspired and built upon ideas of others, and there will be references and call-outs throughout. In case anyone is forgotten, I apologize.

Special thanks for help completing this project go to Farzan, Jon, Leopold, and Kristin.

Additionally, I want to thank MENACE and the other outstanding pen test teams I had the pleasure working with.

About the reviewers

Massimo Bozza is a passionate information security practitioner, researcher, speaker, and lecturer. He holds a master's in electronic engineering from University La Sapienza of Rome, with years of experience in penetration testing, vulnerability assessments, surveillance and monitoring solutions, embedded devices, and RF hacking. He is currently employed as a red team manager at one of the largest online fashion retail groups, shaping new strategies to fight and simulate cyber adversaries.

Christopher Cottrell has over ten years' experience in the cybersecurity field. His technical experience includes red team operations, hunt teaming, application security, and DevOps practices. He utilizes his experience as a red team adversary to strengthen the cybersecurity maturity of organizations while also bringing a unique perspective to executive decision-makers. He heads the red team and application security verticals at 2U, Inc. In this role, he leads red team campaigns that test and verify security controls that support business requirements. He ensures that application security practices secure critical code for 2U and uses his team to provide live and static assessments on applications. He is an advocate for cybersecurity as a trade skill and always looking for new and innovative ways to bring talent into the field. He is currently spearheading an initiative at 2U to provide a path into red teaming for those who have a great interest in the discipline but no direct pathway into the field. Christopher can be reached on Twitter @icebearfriend, or on LinkedIn.

Christopher Gibson is a Senior Manager in the Product Security team at Citrix, tasked with leading the internal Red Team. His areas of focus include security architecture, penetration testing, application security, incident response, digital forensics, and consulting with business units to reduce their cybersecurity risk. He holds the Offensive Security Certified Professional (OSCP) and the GIAC Exploit Researcher and Advanced Penetration Tester (GXPN) certifications among other security and IT certifications.

Packt is searching for authors like you

If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.

Table of Contents

Preface

Section 1: Embracing the Red

Chapter 1: Establishing an Offensive Security Program

Defining the mission – the devil's advocate4

Getting leadership support5

Convincing leadership with data5

Convincing leadership with actions and results6

Locating a red team in the organization chart6

The road ahead for offensive security 7

Building a new program from scratch7

Inheriting an existing program7

People – meeting the red team crew 8

Penetration testers and why they are so awesome!9

Offensive security engineering as a professional discipline9

Strategic red teamers10

Program management10

Attracting and retaining talent10

Diversity and inclusion12

Morale and team identity13

The reputation of the team14

Providing different services to the organization15

Security reviews and threat modeling support15

Security assessments16

Red team operations16

Purple team operations16

Tabletop exercises17

Research and development17

Predictive attack analysis and incident response support17

Additional responsibilities of the offensive program18

Security education and training18

Increasing the security IQ of the organization18

Gathering threat intelligence 18

Informing risk management groups and leadership18

Integrating with engineering processes19

I feel like I really know you – understanding the ethical aspects of red teaming19

Training and education of the offensive security team20

Policies – principles, rules, and standards21

Principles to guide and rules to follow21

Acting with purpose and being humble21

Penetration testing is representative and not comprehensive22

Pentesting is not a substitute for functional security testing22

Letting pen testers explore22

Informing risk management22

Rules of engagement23

Adjusting rules of engagement for operations24

Geographical and jurisdictional areas of operation24

Distribution of handout cards25

Real versus simulated versus emulated adversaries 25

Production versus non-production systems25

Avoiding becoming a pawn in political games26

Standard operating procedure26

Leveraging attack plans to track an operation27

Mission objective – what are we setting out to achieve or demonstrate?27

Stakeholders and their responsibilities28

Codenames29

Timelines and duration29

Understanding the risks of penetration testing and authorization29

Kick-off meeting30

Deliverables30

Notifying stakeholders30

Attack plan during execution – tracking progress during an operation31

Documenting activities33

Wrapping up an operation34

Overarching information sharing via dashboards38

Contacting the pen test team and requesting services 38

Modeling the adversary 38

Understanding external adversaries39

Considering insider threats39

Motivating factors39

Anatomy of a breach 40

Establishing a beachhead40

Achieving the mission objective41

Breaching web applications 41

Weak credentials42

Lack of integrity and confidentiality42

Cyber Kill Chain® by Lockheed Martin42

Anatomy of a cloud service disaster42

Modes of execution – surgical or carpet bombing44

Surgical44

Carpet bombing44

Environment and office space45

Open office versus closed office space45

Securing the physical environment 45

Assemble the best teams as needed45

Focusing on the task at hand46

Summary46

Questions46

Chapter 2: Managing an Offensive Security Team

Understanding the rhythm of the business and planning Red Team operations48

Planning cycles 48

Offsites49

Encouraging diverse ideas and avoiding groupthink50

Planning operations – focus on objectives50

Planning operations - focus on assets52

Planning operations - focus on vulnerabilities52

Planning operations – focus on attack tactics, techniques, and procedures53

Planning operations – focus on STRIDE53

Managing and assessing the team55

Regular 1:1s 55

Conveying bad news56

Celebrating success and having fun56

Management by walking around 56

Managing your leadership team57

Managing yourself57

Handling logistics, meetings, and staying on track58

Team meetings58

Working remotely59

Continuous penetration testing59

Continuous resource adjustment 59

Choosing your battles wisely60

Getting support from external vendor companies60

Growing as a team61

Enabling new hires quickly62

Excellence in everything62

Offensive security test readiness63

Building an attack lab63

Leading and inspiring the team 64

For the best results – let them loose!64

Leveraging homefield advantage65

Finding a common goal between red, blue, and engineering teams65

Getting caught! How to build a bridge67

Learning from each other to improve68

Threat hunting68

Growing the purple team so that it's more effective68

Offensive techniques and defensive countermeasures69

Surrendering those attack machines!69

Active defense, honeypots, and decoys70

Protecting the pen tester71

Performing continuous end-to-end test validation of the incident response pipeline71

Combatting the normalization of deviance72

Retaining a healthy adversarial view between red and blue teams72

Disrupting the purple team72

Summary73

Questions73

Chapter 3: Measuring an Offensive Security Program

Understanding the illusion of control76

The road to maturity77

Strategic red teaming across organizations 78

The risks of operating in cloak-and-dagger mode78

Tracking findings and incidents79

Repeatability84

Automating red teaming activities to help defenders85

Protecting information – securing red team findings86

Measuring red team persistence over time86

Tackling the fog of war 86

Threats – trees and graphs87

Building conceptual graphs manually88

Automating discovery and enabling exploration91

Defining metrics and KPIs 93

Tracking the basic internal team commitments93

Attack insight dashboards – exploring adversarial metrics93

Red team scores 95

Tracking the severity of findings and measuring risks 101

Moving beyond ordinal scores101

Using mean-time metrics102

Experimenting with Monte Carlo simulations103

Threat response matrix 107

Test Maturity Model integration (TMMi ®)and red teaming108

Level 2: Managed109

Level 3: Defined109

Level 4: Measured110

Level 5: Optimized110

Level 6: Illusion of control – the red team strikes back110

MITRE ATT&CK™ Matrix111

MITRE ATT&CK Navigator 111

Remembering what red teaming is about115

Summary115

Questions116

Chapter 4: Progressive Red Teaming Operations

Exploring varieties of cyber operational engagements118

Cryptocurrency mining119

Mining crytocurrency to demonstrate the financial impact – or when moon?121

Red teaming for privacy123

Getting started with privacy focused testing124

Sending a virtual bill to internal teams 126

Red teaming the red team127

Targeting the blue team 127

Leveraging the blue team's endpoint protection as C2128

Social media and targeted advertising129

Targeting telemetry collection to manipulate feature development129

Attacking artificial intelligence and machine learning130

Operation Vigilante – using the red teamto fix things131

Emulating real-world advanced persistent threats (APTs)132

Performing tabletop exercises 132

Involving the leadership team in exercises133

Summary134

Questions134

Section 2: Tactics and Techniques

Chapter 5: Situational Awareness – Mapping Out the Homefield Using Graph Databases

Understanding attack and knowledge graphs138

Graph database basics139

Nodes or vertices140

Relationships or edges141

Properties or values141

Labels141

Building the homefield graph using Neo4j142

Exploring the Neo4j browser148

Creating and querying information150

Creating a node151

Retrieving a node151

Creating relationships between nodes155

Indexing to improve performance158

Deleting an object158

Alternative ways to query graph databases 159

Summary160

Questions160

Chapter 6: Building a Comprehensive Knowledge Graph

Technical requirements162

Case study – the fictional Shadow Bunny corporation162

Employees and assets163

Building out the graph164

Creation of computer nodes168

Adding relationships to reflect the administrators of machines169

Configuring the query editor to allow multi-statement queries171

Who uses which computer?173

Mapping out the cloud! 176

Importing cloud assets 180

Creating an AWS IAM user180

Leveraging AWS client tools to export data185

Loading CSV data into the graph database192

Loading CSV data and creating nodes and relationships195

Grouping data197

Adding more data to the knowledge graph198

Active Directory198

Blue team and IT data sources198

Cloud assets199

OSINT, threat intel, and vulnerability information199

Address books and internal directory systems200

Discovering the unknown and port scanning200

Augmenting an existing graph or building one from scratch?200

Summary201

Questions201

Chapter 7: Hunting for Credentials

Technical requirements204

Clear text credentials and how to find them204

Looking for common patterns to identify credentials205

Retrieving stored Wi-Fi passwords on Windows213

Tooling for automated credential discovery215

Leveraging indexing techniques to find credentials216

Using Sourcegraph to find secrets more efficiently 216

Searching for credentials using built-in OS file indexing224

Indexing code and documents using Apache Lucene and Scour231

Hunting for ciphertext and hashes233

Hunting for ciphertext233

Hunting for hashes234

Summary242

Questions243

Chapter 8: Advanced Credential Hunting

Technical requirements246

Understanding the Pass the Cookie technique247

Credentials in process memory248

Walkthrough of using ProcDump for Windows248

Understanding Mimikittenz251

Dumping process memory on Linux252

Debugging processes and pivoting on macOS using LLDB255

Using Mimikatz offline258

Abusing logging and tracing to steal credentials and access tokens259

Tracing the WinINet provider261

Decrypting TLS traffic using TLS key logging265

Searching log files for credentials and access tokens272

Looking for sensitive information in command-line arguments 277

Using Task Manager and WMI on Windows to look at command-line arguments278

Windows Credential Manager and macOS Keychain 279

Understanding and using Windows Credential Manager280

Looking at the macOS Keychain284

Using optical character recognition to find sensitive information in images285

Exploiting the default credentials of local admin accounts 287

Phishing attacks and credential dialog spoofing 288

Spoofing a credential prompt using osascript on macOS288

Spoofing a credential prompt via zenity on Linux290

Spoofing a credential prompt with PowerShell on Windows291

Credential dialog spoofing with JavaScript and HTML on the web292

Using transparent relay proxies for phishing292

Performing password spray attacks295

Leveraging PowerShell to perform password spraying295

Performing password spraying from macOS or Linux (bash implementation)297

Summary299

Questions300

Chapter 9: Powerful Automation

Technical requirements302

Understanding COM automation on Windows302

Using COM automation for red teaming purposes303

Achieving objectives by automating Microsoft Office 307

Automating sending emails via Outlook307

Automating Microsoft Excel using COM309

Searching through Office documents using COM automation312

Windows PowerShell scripts for searching Office documents315

Automating and remote controlling web browsers as an adversarial technique320

Leveraging Internet Explorer during post-exploitation320

Automating and remote controlling Google Chrome326

Using Chrome remote debugging to spy on users!332

Exploring Selenium for browser automation 336

Exfiltrating information via the browser347

Summary348

Questions348

Chapter 10: Protecting the Pen Tester

Technical requirements350

Locking down your machines (shields up)350

Limiting the attack surface on Windows352

Becoming stealthy on macOS and limiting the attack surface355

Configuring the Uncomplicated Firewall on Ubuntu 364

Locking down SSH access366

Considering Bluetooth threats366

Keeping an eye on the administrators of your machines367

Using a custom hosts file to send unwanted traffic into a sinkhole369

Keeping a low profile on Office Delve, GSuites, and Facebook for Work370

Securely deleting files and encrypting hard drives370

Improving documentation with custom Hacker Shell prompts371

Customizing Bash shell prompts371

Customizing PowerShell prompts372

Improving cmd.exe prompts373

Automatically logging commands 373

Using Terminal multiplexers and exploring shell alternatives374

Monitoring and alerting for logins and login attempts378

Receiving notifications for logins on Linux by leveraging PAM378

Notification alerts for logins on macOS387

Alerting for logins on Windows388

Summary394

Questions395

Chapter 11: Traps, Deceptions, and Honeypots

Technical requirements398

Actively defending pen testing assets 398

Understanding and using Windows Audit ACLs399

Configuring a file to be audited by Windows using SACLs399

Triggering an audit event and changing the Windows Audit Policy403

Notifications for file audit events on Windows406

Sending notifications via email on Windows408

Creating a Scheduled Task to launch the Sentinel monitor409

Building a Homefield Sentinel – a basic Windows Service for defending hosts415

Installing Visual Studio Community Edition and scaffolding a Windows Service415

Adding basic functionality to the scaffold416

Adding logging functionality to the service422

Leveraging a configuration file to adjust settings 423

Adding an installer to the service424

Uninstalling the Homefield Sentinel service 429

Monitoring access to honeypot files on Linux430

Creating a honeypot RSA key file430

Using inotifywait to gain basic information about access to a file431

Leveraging auditd to help protect pen test machines432

Notifications using event dispatching and custom audisp plugins437

Alerting for suspicious file access on macOS 439

Leveraging fs_usage for quick and simple file access monitoring439

Creating a LaunchDaemon to monitor access to decoy files440

Observing the audit event stream of OpenBSM443

Configuring OpenBSM for auditing read access to decoy files444

Summary447

Questions448

Chapter 12: Blue Team Tactics for the Red Team

Understanding centralized monitoring solutions that blue teams leverage450

Using osquery to gain insights and protect pen testing assets451

Installing osquery on Ubuntu452

Understanding the basics of osquery453

Using osquery to monitor access to decoy files458

Leveraging Filebeat, Elasticsearch, and Kibana 462

Running Elasticsearch using Docker463

Installing Kibana to analyze log files466

Configuring Filebeat to send logs to Elasticsearch469

Alerting using Watcher473

Summary473

Questions474

Assessments

Another Book You May Enjoy

Leave a review - let other readers know what you think484

Preface

An organization must be ready to detect and respond effectively to security events and breaches. Preventive measures alone are not enough in dealing with adversaries. An organization needs to create a well-rounded prevention, detection, and response program.

Security is not a feature that can be added to a system without significant delay and cost.

When it comes to software, it sometimes feels like security engineers are trying to help bolt wings onto an airplane while it's already on the runway and speeding up to take off. At times there are even passengers on the plane already, while on the side we have a few security warriors running along to help magically bolt on wings to avoid disaster.

This book is for all those security warriors and wizards that help secure the world and make sure that the plane takes off, flies, and lands safely and soundly.

As part of this book I will discuss penetration testing, red teaming, and offensive security at large and how to establish such a program within your organization. I do so by providing examples for what worked and what didn't work in my career and what things you might be able to avoid in the first place to get started and be effective fast.

One of the largest purple team operations I had the opportunity to lead had more than three dozen active participants who were hacking, scanning, stealing credentials, hunting, analyzing, forensicating, learning, and most importantly, having fun along the way while significantly positively impacting the company's culture and security posture.

My goal is for organizations that have not yet been exposed to the idea of compromising themselves to benefit from this book by leveraging the benefit of homefield advantage to stay ahead of real-world adversaries.

Mature organizations and security engineers hopefully see similar patterns in their areas.

The first part of this book, titled Embracing the Red, dives into the details, learning, and organizational challenges of how to build, manage, and measure an internal offensive security program. The second part of the book is entirely dedicated to the Tactics and Techniques that a penetration test team should be aware of and leveraging.

Hopefully, the program management parts of this book will support red teamers, pen testers, analysts, defenders, security leaders, and the security community to build strong, collaborative, and effective offensive security programs. Equally, the second part of the book provides insights with practical examples on how the reader can apply homefield advantage in technical terms.

The challenges in front of the security community and the industry are tremendous. The amount of information that needs protection, the amount of data stored in the cloud, the privacy concerns, the threats artificial intelligence holds, and the easy manipulation of the masses via social media are a reflection of how much work is ahead of us.

Having had the chance to interact, work with, and learn from so many security professionals, however, I'm confident that if we work together to share our understanding of the threats, mitigations, and risks, we will continue to rise and meet these challenges.

A note about terminology

This book uses common terms, such as alternative analysis, offensive security, red teaming, penetration testing, purple teaming, adversary emulation, and similar ones throughout. It is understood that opinions on what some of these terms mean differ between nations, sectors, organizations, and individuals.

I was introduced to the term of alternative analysis by attending the red team training session Becoming Odysseus, by Dr. Mark Mateski. Mark has been a thought leader in the red-teaming community for over two decades. The training provided great insights and introduced me to the broader definition of red teaming that exists outside the tech industry. In the broader setting, red teaming is meant to highlight any form of alternative analysis and enable people to see something from an adversary or competitor's perspective.

The Center of Advanced Red Teaming at the University at Albany (https://www.albany.edu/sites/default/files/2019-11/CART%20Definition.pdf) proposes the following definition for red teaming: Any activities involving the simulation of adversary decisions or behaviors, where outputs are measured and utilized for the purpose of informing or improving defensive capabilities.

In the tech and cybersecurity industry, it is common to use red teaming to refer to breach operations to measure and improve the incident response process.

When pen testing at a small company, red teaming and even tasks such as threat modeling might be done by the same team, and some activities are outsourced. By contrast, a large organization might have multiple pen test teams focused on different objectives and tasks such as application security assessments, penetration testing, red teaming, and adversary emulation, and so each might be done by differently specialized groups of individuals.

A large red team might further split up responsibilities within the team, such as having dedicated tool development engineers, program managers, operators, or a breach team (Team A) versus an objective team (Team B), and so forth.

This book will use terms such as pen tester and red teamer at times interchangeably depending on the context of the discussion and topic, and hopefully, this will not lead to confusion on the part of the reader. I realized it's impractical to attempt to define a strict ruleset on what some of the terms mean generically, given the variation of opinion throughout the field.

Who this book is for

This book is meant for pen testers, cybersecurity analysts, security leaders, and strategists, as well as red team members and CISOs looking to make their organizations more secure from adversaries.

To get the most out of the technical part of the book, some penetration testing experience, as well as software engineering and debugging skills, is necessary. The program management part is suited for beginners.

What this book covers?

Section 1: Embracing the Red

Chapter 1, Establishing an Offensive Security Program, covers the reasoning on why an internal red program is important; how it benefits the organization; how to start building out the program, including defining mission, rules, operating procedures; and how to model the adversary.

Chapter 2, Managing an Offensive Security Team, discusses how to establish the rhythm of the business for the offensive security team, and how to manage people and processes and explore opportunities for leveraging the homefield advantage and purple teaming.

Chapter 3, Measuring an Offensive Security Program, dives into details on how to present and measure the progress and maturity of the program. This includes topics such as bug and issue tracking, using the MIRE ATT&CK matrix, attack graphs, and Monte Carlo simulations. The chapter also discusses the illusion of control that many organizations face, which red teams at times fall for as well.

Chapter 4, Progressive Red Teaming Operations, covers interesting and at times unusual ideas for operations, many of which the author has performed. This includes mining cryptocurrency, targeting privacy testing, targeting telemetry and social media, as well as operations that target other red teams.

Section 2: Tactics and Techniques

Chapter 5, Situational Awareness-Mapping Out the Homefield Using Graph Databases, covers the basics of graph databases and how they can aid knowledge discovery.

Chapter 6, Building a Comprehensive Knowledge Graph, explores a fictional corporation and how to map out its on-premises and cloud assets from scratch using Neo4J. This includes learning about the basics of a graph database, how to create nodes and relations, and how to write queries. Furthermore, we will cover how to load JSON and/or CSV data (for example, from an nmap scan) into a graph.

Chapter 7, Hunting for Credentials, covers the basics of credential hunting and how to use indexing techniques to find credentials at scale. This covers built-in operating system indexing as well as tools such as Sourcegraph and Scour.

Chapter 8, Advanced Credential Hunting, covers hunting for credentials in process memory, abusing logging and tracing, learning about pass the cookie and spoofing credential prompts on various operating systems, and password spray attacks that every organization should perform regularly.

Chapter 9, Powerful Automation, covers the details of COM automation on Windows with practical examples on how an adversary might trick users. A large part of this chapter is also dedicated to automating browsers during post-exploitation to steal cookies or remotely take control of a browser.

Chapter 10, Protecting the Pen Tester, focuses entirely on how pen testers and red teamers should protect their assets and machines. This includes improving pen test documentation and logging, as well as practical ideas to lock down machines. We will cover aspects across major operating systems.

Chapter 11, Traps, Deceptions, and Honeypots, shows how, as part of a good red-team strategy, the red team must protect their own assets and monitor for malicious access. This chapter is dedicated to building out a solid monitoring and deception strategy across major operating systems to trick adversaries that might attack your red teams.

Chapter 12, Blue Team Tactics for the Red Team, covers blue team tooling that red teamers should know about to use themselves (for instance, osquery, Elastic Stack, and Kibana) and also to understand the capabilities and gaps of the blue team tooling to better help improve it.

To get the most out of this book 

The first part of the book does not require software or tools. What is needed is an open mind to learn about the importance of penetration testing and red teaming, and why and how to establish and grow an offensive security program within your organization. The examples to do with creating attack team dashboards and performing Monte Carlo simulations were created using Microsoft Office.

The second part will dive into a wider set of programs, tools, scripts, and code for Windows, Linux, and macOS. To follow along with every example in the book, all three major desktop operating systems are required. Some examples focus on one platform, but the reader will be able to get the same results (although with possibly slightly different workflows and steps) using any other operating system that supports the software. Some tools and software are very specific and not available on all platforms.

The second part of the book is not for beginners, as tools/scripts might need debugging and research for you to take full advantage of them and ensure that they work for your scenarios. Always do your own research before using something during a red-team operation or in a production setting.

The following table shows the majority of the tools and software that we will cover, discuss, or leverage throughout the book:

If you are using the digital version of this book, we advise you to type the code yourself or access the code via the GitHub repository (link available in the next section). Doing so will help you avoid any potential errors related to copy/pasting of code.

Regarding the versions of the software, the current version as of publication will suffice to follow along, and as stated the technical part of this book will require knowledge in troubleshooting and debugging skills.

Download the example code files

You can download the example code files for this book from your account at www.packt.com. If you purchased this book elsewhere, you can visit www.packtpub.com/support and register to have the files emailed directly to you.

You can download the code files by following these steps:

Log in or register at www.packt.com. Select the Support tab. Click on Code Downloads. Enter the name of the book in the Search box and follow the onscreen instructions.

Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:

WinRAR/7-Zip for Windows Zipeg/iZip/UnRarX for Mac 7-Zip/PeaZip for Linux

The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Cybersecurity-Attacks-Red-Team-Strategies. In case there's an update to the code, it will be updated on the existing GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Download the color images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it from https://static.packt-cdn.com/downloads/9781838828868_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "In PowerShell, this is achieved with Select-String."

A block of code is set as follows:

catch (Exception e)

{

     log.WriteLine(

       " Error during startup: " + e.ToString());

Any command-line input or output is written as follows:

Get-ChildItem -Recurse | Select-String password

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "In order to submit the page, we need to click the Create New Paste button."

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Reviews

Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!

For more information about Packt, please visit packt.com.

Disclaimer

The information within this book is intended to be used only in an ethical manner. Do not use any information from the book if you do not have written permission from the owner of the equipment. If you perform illegal actions, you are likely to be arrested and prosecuted to the full extent of the law. Packt Publishing or the author do not take any responsibility if you misuse any of the information contained within the book. The information herein must only be used while testing environments with proper written authorizations from appropriate persons responsible.

Section 1: Embracing the Red

An organization must be ready to detect and respond to security events and breaches effectively. Preventive measures alone are not enough to deal with adversaries. An organization needs to create a well-rounded prevention, detection, and response program.

Establishing an offensive security program can help improve the security posture of your organization and identify weaknesses in prevention, detection, and response to security incidents.

In the first part of this book, we will discuss establishing, managing, and measuring an internal offensive security program. This part is en titled Embracing the Red to highlight the importance of having dedicated testing efforts in place and building and encouraging a culture of transparency when it comes to identifying and discussing security challenges and weaknesses within an organization. We will dive into details, learnings, and organizational challenges on how to build, manage, and measure an internal offensive security program.

One of the benefits an internal offensive security team can provide compared to a real-world adversary is that of Homefield Advantage and the collaboration between all stakeholders to demonstrate the immediate benefits of improving the security posture of the organization.

Furthermore, we will explore progressive red team operations, such as crypto jacking, dedicated operations to identify privacy violation, pen testing the pen testers, and much more.

This part comprises the following chapters:

Chapter 1, Establishing an Offensive Security Program Chapter 2, Managing an Offensive Security TeamChapter 3, Measuring an Offensive Security Program Chapter 4, Progressive Red Teaming Operations

Chapter 1: Establishing an Offensive Security Program

Establishing an offensive security program within an organization might seem a challenging task compared to just compromising its assets, but it is one of the most exciting tasks to perform as a penetration tester, lead, or manager. Being there to actively design a strategy for changing the security culture of an entire organization is a great opportunity, and it is rewarding and a lot of fun.

As a leader and manager of an offensive security team, it is critical to set clear principles and a vision and rules for the team. This chapter will discuss the aspects to consider and provide some ideas about how to build a strong foundation.

The following topics will be covered in this chapter:

Defining a practical mission for a cyber-operational red team programFinding support among and influencing leadership to establish a red team programStrategies on where in the organization the red team should be situatedThe importance of building an offensive security roadmapUnderstanding the unique skills required for the job, as well as how to attract and retain adversarial engineers and thinkersOffering different red teaming services to your organizationEstablishing principles, rules, and standard operating procedures to mature the programModeling the adversary and understanding the anatomy of a breachConsiderations for open versus closed office spaces and how it impacts security and team culture

Defining the mission – the devil's advocate

At a high level, one of the best ways to look at a red team is to consider it the devil's advocate. The vision is to ensure alternative views are considered and that stakeholders are held accountable. The program is there to provide reality checks at times of forming a consensus. This is done by demonstrating not just the theoretical but the real-world impact of exploiting weaknesses and informing the organization's risk management process and leadership.

In many ways, an offensive program fulfills a security testing function within the organization, a sometimes rare but much-needed function in the modern world of software engineering, full-stack development, and DevOps.

To run an effective internal offensive security program, a simple yet inspiring mission to help communicate the purpose and motivate the team is important. The mission should be about what is being done, there is no reason to dive into how something will be achieved. A mission along the lines of emulating adversarial behavior and finding and exploiting vulnerabilities for defensive purposes is a good starting point.

Highlighting the defensive aspect is important because the goal of a mature red team should be to improve the security posture of the organization and drive cultural change. The red team's main purpose is to help the organization to understand weaknesses, highlight them, and help them to improve and measure those improvements over time. Finding and exploiting an issue by itself does not automatically lead to change. This is the first big pitfall of an offensive program that struggles to help the organization improve. To achieve cultural change and improve the security posture of an organization, a red team needs some form of measurement and a way to communicate KPIs to the organization and management so that informed investments can be made. We will discuss a set of ideas about how to achieve this in Chapter 3, Measuring an Offensive Security Program.

As stated, an important aspect of an offensive security team is to drive cultural change, so including a mission goal related to improving the security posture and the security culture of the organization is also a good idea.

Here are a few points on what your mission might contain:

Devil's advocateEmulate adversaries for defensive purposesMeasure, communicate, and improve the security of the organizationIncrease the security IQ of the organizationBreak the norm and challenge the effectiveness of the organizationProvide alternative analyses and "think evil"Challenge everything!

A good tactic that can resonate with leadership and management is to reflect your organization's core values in the mission statement as well.

Getting leadership support

To run a successful red team program, it is critical to have active leadership support.

One of the big benefits of an offensive security program and red teaming generally is that they are there to keep everyone honest. Trust but verify. The support of the Chief Security Officer (CSO) is probably easy to get, but the support must be beyond that; it must include the other executive levels of the organization as well. This can't be stressed enough; if you do not have executive buy-in, the effectiveness and outcomes of the program will be limited. Getting long term buy-in might be achieved by using various strategies, including providing data and providing actual breach results, explaining how they impact the organization.

Convincing leadership with data

When looking at data, it is useful to look at the competitive landscape and analyze recent breaches that have occurred in the industry, and the associated impact they have had on organizations. This might include data such as the following:

Gather evidence related to the cost and impact of breaches in your industry.Gather data around past breaches of your organization.Gather evidence of other security incidents in your organization.If your organization has been through penetration testing or red teaming exercises in the past (for example, for compliance reasons), try to get hold of past findings and results and look at the business impact of the findings to support and encourage further investment.If you already have a bug bounty program, results and findings can further highlight that investment is necessary.

Convincing leadership with actions and results

Another approach is to propose a lightweight offensive penetration test to explore if more investments would be useful for the organization. This could be a simple case study, something along the lines of searching the intranet and source code for cleartext passwords. Subsequently, perform risk analysis on the havoc a malicious insider might cause with access to widely available passwords. This could be done internally, or one of the many great security consulting organizations could be hired to highlight potential issues.

Locating a red team in the organization chart

Initially, I would not spend too much time thinking about where in the organization the offensive security team should be located. If you are just starting out, it's most likely that only one full-time person is tasked with offensive security work. The more critical part at that stage is to get executive sign-off and support to perform offensive testing and deliver results. The bias should be toward action at first and to demonstrate a positive impact. In some organizations, the program is entirely outsourced, and only logistics are driven internally, although typically the desire to build an internal team will grow.

A typical organization structure will probably put the offensive security team in either the defense and response part of the company or as a function of a Security Assurance team. I have also seen offensive security teams being put in legal and compliance areas of companies. A lot of this depends on the size and structure of the organization, as well as the size of the offensive security team itself.

A great place, and personally my favorite, is a staffing function that informs leadership (for example, the vice president, CEO, or CISO) as an independent group. This allows for great autonomy and provides leadership direct, unfiltered input into the state of security.

In most cases, however, the team will be buried somewhere deeper down in the organization chart, and that is okay. I don't like it when a penetration test team reports to a defensive team (for instance the blue team lead), as that might provide the wrong impression of its core purpose. The offensive security team is an adversarial team with the goal of helping the organization, but its behavior and actions must maintain a level of independence and freedom.

The road ahead for offensive security

When it comes to successfully managing an offensive security program, it's critical to define an overall roadmap that acts as a foundation and guidance going forward. Think of a high-level plan for the next two or three years. Most likely the program will grow organically if the initial investments are fruitful and the return on investment is made visible. This is what I have observed across different organizations that have implemented an internal offensive security program. In the beginning, start out small, and one or two years later it grows into an actual team of full-time employees. Overall, there are possibly two options initially. One is to build a program and a team from scratch, and the other one is to use already existing resources that can be leveraged.

Building a new program from scratch

If you are starting out from scratch it might seem rather intimidating, but it's also a great opportunity. The most likely scenario in this case is that you will have a one-person show initially, and by demonstrating its value and business impact, the team will start growing organically. It might also be the case that you entirely depend on external expertise initially, so you must hire vendors to fulfill the mission.

Inheriting an existing program

If you are taking over an existing team or are going through a reorganization in your organization that establishes or consolidates teams, there are some other unique challenges that you will face. I hope that many of the things highlighted about people and program management when it comes to offensive security engineering will help you as well.

To set a roadmap, it's important to first understand the maturity of an already existing program and team. Here are some questions to ask when taking over an existing team:

Are the processes and documents in place already?Are the rules of engagement and standard operating procedures defined?Are there any test plans?What is the size of the team?Are the findings tracked and reviewed?Are the stakeholders and responsibilities clearly defined?

If you are just starting out, defining and creating some of these guidelines and rules is an important step since most likely your organization does not allow any form of offensive testing or intrusion. It can be the opposite: it's a terminable offense in many companies to compromise other machines or gain access to certain assets. Go off and read your employer's employee handbook. In order to make sure you have all the basics covered, this chapter describes some guiding principles and documents that you need to think of. Hopefully some of the content is useful and will help you enable penetration testing in your organization. Make sure to review any such documents and planned activities with legal counsel and other key stakeholders in your organization before engaging in penetration testing.

If you are inheriting an existing team, look at the capability maturity model for testing and how you can apply something similar for penetration testing and red teaming. This is described in more detail later in the book, when we talk about measuring the program.

In the following chapters, we will go over some of the basics to help bootstrap a program and have a basic roadmap in place. So, let's get to it.

People – meeting the red team crew

The most important component of implementing a successful offensive security program is retaining and hiring the right people that can fulfill its mission. Whether you are only starting out with a single penetration tester or you've inherited a larger team of already established offensive security engineers, it is the individuals who make the difference. Shaping the program by retaining and hiring the right people is of the utmost importance.

Penetration testers and why they are so awesome!

Throughout my career, I have always thought that testers are awesome. That's why I personally always liked the term "penetration tester" a lot, because it does highlight the testing aspect. This is not necessarily an opinion everyone shares. I have had the pleasure of working with and meeting some of the smartest individuals in the fields of security and offensive security. Many of them are professional testers, consultants, researchers, engineers, or penetration testers that have worked for large corporations with up to 100,000 employees, as well as smaller companies and security enthusiasts and students.

The one thing that always stands out among security engineers is the passion for security they project. They often have an idealistic drive to make the world a better place, as well as the passion to find issues and break systems. If someone is happy when they can break something and are excited to share the news, it's a good sign the person is on the right track to becoming a penetration tester.

The breaker mentality and a curiosity about how things work under the covers are greatly needed, especially in a time when organizations have moved away from employing dedicated test teams. The penetration tester is here as the spearhead to help keep an organization honest about the quality of what is being produced.

In many organizations, they are the last dedicated testers that remain. And the results they uncover are often not pretty, but much needed. On top of that, they are skilled, smart, creative, unique, and typically very fun to work with.

Offensive security engineering as a professional discipline

Some organization do not distinguish software engineering from security engineering. In the grand scheme of things, it all falls under the umbrella of general software engineering, and this, dear reader, is a big mistake. It is important to highlight the unique and distinct skillset of security engineers, especially those working in the offensive field. And what better way is there to appreciate their unique skillset than by calling them what they are, or even better, letting them pick their own title? Devil's Advocate, Security Engineer, Pen Tester, Red Teamer, Offensive Security Engineer, Adversarial Engineer, Security Ninja – why not?

This goes along the same lines as ensuring that the compensation for security engineers is evaluated in a distinct fashion from those of software engineers and developers. Reach out to your HR department to get an understanding of how your organization sees the roles of security engineers. Is there any precedent for offensive security engineers already present?

Strategic red teamers

Red teams, as well as penetration testing in general, is a technical and sometimes very tactical role. A way to grow is to embrace more strategic and analytical objectives and tactics – keep that in mind when building out the team. As soon as a certain level of maturity is reached, your organization will benefit from exercises that cannot be put into a box and are beyond typical network assessments, for instance. The red team will evolve into a group that always pushes the boundaries – at that point, there are no handbooks or playbooks to follow, besides a rough framework, and even that should be challenged.

Important Note

A red team that has never been tested and assessed by another red team is most likely not a mature red team.

There's more later in the chapter about maturing the offensive security program and the illusion of control.

Program management

Depending on the size of the red team and the complexity of the program, it might make sense to add program management resources to the team. The program management team can focus on maintaining the rhythm of the business by running regular sync and triage meetings. This is especially helpful when the program matures and collaboration with other stakeholders across the organization is necessary, including driving the rhythm of the business, as well as helping to integrate with risk management processes.

Attracting and retaining talent

Many organizations do already possess some ad hoc security testing capabilities, often performed by individuals who work on threat modeling jumping in to help with some hands-on testing.

Being a devil's advocate is something that might appear intrinsic and unlearnable or unteachable. Great pen testers ask a lot of questions. They always have a (some times annoying) but, what if? mentality. It's a very healthy attitude, especially for well-established organizations with long traditions of following the process, which might have been optimized and matured into a groupthink mentality.

When interviewing candidates for offensive security roles, stop asking unrelated or unnecessarily difficult coding questions – it's counterproductive. You are most likely not looking for a system engineer that can carve out the fastest and most memory-efficient solution to move subtrees around and sort nodes while keeping the tree perfectly balanced at the same time. Just stop it. If you focus on this, you will not find the person you need.

It's certainly okay to dive into coding questions that explore the candidate's basic coding skills. Unfortunately, in my experience, some organizations treat hiring offensive security engineers along the same lines as hiring a software developer. The skillset you are looking for is very different. Of course, finding a security engineer who is an outstanding coder and program manager at the same time would be amazing, but if you are only looking for coding and algorithmic skills you might miss the best candidates.

Some good questions should always be around problem-solving and how to break things. Let them break something they might not even be familiar with. The likely outcome of interviewing an outstanding candidate is that they will find a new or different way to break something.

Developing a consistent way of asking questions, so you can compare the candidates well, is also something to think of before starting the interview process. For technical issues, I found it good to ask two kinds of technical questions, one that the candidate chooses themselves basically, and one where the candidate does not know the answer or admits weakness in the area.

Trust me, you want to have someone on the team who can admit Oh, I do not know this., and goes off and figures it out. The candidate who can't admit not knowing something could be a liability during critical moments, and the team could be blindsided because they make stuff up rather than pointing out that they do not know the answer. You are the leader of the program and you own it. A failure of the team is the leader's fault and not the fault of an individual team member – always remember that. That's why hiring and retaining the right people is critical.

Besides having technical understanding, great communication skills to explain vulnerabilities and describe the business impact of issues can help tremendously to resolve issues quickly. Ideally, the communication style involves conveying interesting stories to get stakeholders engaged.

One area to probe during an interview is ethical questions. Bring up a scenario that requires a penetration tester to make an ethical decision. Let's say the pen tester is tasked with compromising an HR or internal employee feedback and rewards system. The objective is to gain access and demonstrate if data exfiltration is possible and if detection is in place. How would the candidate approach this? Would they exfiltrate their own record, exfiltrate the records of others, or propose to exfiltrate dummy records, or would they have any other ideas? See if the candidate acts according to the values you want to see in your program, team, and organization.

The best way to find good candidates is via referrals, in my opinion, so make sure that you are well connected with the industry. Attend conferences and ask around to see which candidates might be interested in your business.

Diversity and inclusion

The 2017 Global Information Security Workforce Study set out to report on the current state of women in cybersecurity. One of the key takeaways is that women make up 11% of the global information security workforce. If that sounds low, well, that's because it is. And 11% is the same percentage as it was in 2013, which means the situation has not changed over the last few years.

The details of the report can be found here: https://blog.isc2.org/isc2_blog/2017/03/results-women-in-cybersecurity.html.

The lack of diversity becomes apparent when walking through the halls of some security conferences. Since security conferences are critical for networking and recruiting, a welcoming atmosphere for women will go a long way.

To add to that, the Global Information Security Workforce Study highlights that, for non-managerial positions, the pay gap has widened from 4% to 6% and that women disproportionally fill lower-level positions, not senior, director, or executive roles.

What does this mean for penetration testing and red teaming?

To build a strong and successful offensive security program and to promote alternative analysis, having a diverse set of opinions, ideas, and viewpoints is a natural component of success. Your program is missing alternative viewpoints and adversarial tactics due to the lack of insights from female security experts.

Management must identify, support, and value women with high potential by providing opportunities for training, mentorship, and leadership. Additionally, it's desirable that your organization forms or participates in external online groups and in-person meetups focusing on women in security.

And if you are in a meeting and see there are a few women sitting off to the side, maybe it's because they feel like they don't have a voice. Anyone can invite and encourage them to sit at the table. The point is that all the small things make a difference.

Morale and team identity

It's all about the team. A big part of the success of a penetration testing team is morale and identity. Having a neat name for the team will help build that identity. And I don't mean calling it something like <Company here> Red Team or <Organization> Red Team. Pen testers are creative individuals, so come up with something fun that represents who you are and what you are setting out to do! Naturally, this develops by itself over the course of a few operations together.

At one point in my career, I formed a team and decided to give it a rather menacing name. It seemed a good idea and the name had naturally evolved via some previous tooling that had been built. So, I created a nice red logo with a yellow font. I spent many hours the night before building the slide deck to convey the idea of an internal offensive security team to my leadership. I basically went through the steps we are discussing in this book. From my point of view, it seemed like a pretty neat slide deck.

The actual presentation, though, went not as smoothly and did not progress beyond the first slide for a long time. Unfortunately, one member of the leadership team did not like the name of the team or its logo. I vividly remember how the director looked at the slide and then lowered his face and put his hand on his forehead. He felt that the name of the offensive team and its logo were too menacing and didn't want them to be used. The other directors were very supportive, however, and there was a leadership change soon after that, and things went the way I had planned.

From that point onward, all the work, operations, tools, and projects the offensive team worked on were given fun and sometimes cute names, such as bunny, squirrel, and things along those lines. It was especially entertaining and positive for the team's morale to see notifications and alerts highlighting the discovery of bunnies in the environment and things along those lines.

The pattern for picking code names prevailed, and the underlying background story of how we got there became a binding element for the team's identity. And there was no shortage for good names for tools and operations going forward.

One different aspect to consider when it comes to morale and team identity is the impact that purple teaming (close collaboration between red, blue, and engineering teams) can have if done incorrectly. It can threaten the team's identity and the morale of the red team significantly. We will discuss this more in Chapter 3, Measuring an Offensive Security Program, but it's important to maintain a healthy adversarial view and not only do purple teaming.

The reputation of the team

As a manager, considering the reputation of the team across the organization is critical. If it's correctly formed and led, the outcomes of an offensive security team are very visible across the organization. And it's up to the team to use this visibility and acquired power to inform the right stakeholders to drive the correct change and improvements across the organization.

An arrogant attitude does not help in the long run. It is in fact toxic. It's one of the earlier maturity stages of a red teamer. An immature red team, for instance, might become defensive when getting caught during an operation. For a manager, observing how the team handles "being caught" during an operation helps to gauge the maturity of team members and the program. By observing the interactions between the red team and the blue team when unexpected detections occur, a lot of learning can be done.

The more seasoned red teamer will embrace a detection and provide praise to the finder. Additionally, the seasoned red teamer will try to understand how it happened and try to achieve positive outcomes and improvements. With the knowledge of the product engineers or the blue team, even more effective attacks or variations could possibly be carried out that need mitigation. No one by themselves knows everything, and the viewpoints of others could lead to even more discoveries!

Showing signs of arrogance and ego is an attitude that's not uncommon among us red teamers. When dealing with strong egos, additional management and coaching will be needed to ensure the skill and power of the individual can be leveraged to their fullest potential by having the most impact.

The most successful pen testers I have encountered are humble yet assertive and provide alternative views to surprise and educate people without being arrogant or a know-it-all.

Providing different services to the organization

A useful way to look at an offensive security program is that it is providing services to the organization. If the reader is familiar with red teams that focus on business processes or other aspects of an organization, this topic is primarily focused on the cybersecurity angle.