Cloud Penetration Testing E-Book

Kim Crawley

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 451

Veröffentlichungsjahr: 2023

Beschreibung

With AWS, Azure, and GCP gaining prominence, understanding their unique features, ecosystems, and penetration testing protocols has become an indispensable skill, which is precisely what this pentesting guide for cloud platforms will help you achieve. As you navigate through the chapters, you’ll explore the intricacies of cloud security testing and gain valuable insights into how pentesters evaluate cloud environments effectively.
In addition to its coverage of these cloud platforms, the book also guides you through modern methodologies for testing containerization technologies such as Docker and Kubernetes, which are fast becoming staples in the cloud ecosystem. Additionally, it places extended focus on penetration testing AWS, Azure, and GCP through serverless applications and specialized tools. These sections will equip you with the tactics and tools necessary to exploit vulnerabilities specific to serverless architecture, thus providing a more rounded skill set.
By the end of this cloud security book, you’ll not only have a comprehensive understanding of the standard approaches to cloud penetration testing but will also be proficient in identifying and mitigating vulnerabilities that are unique to cloud environments.

Leseprobe

Cloud Penetration Testing

Learn how to effectively pentest AWS, Azure, and GCP applications

Kim Crawley

Cloud Penetration Testing

Copyright © 2023 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.

Group Product Manager: Pavan Ramchandani

Publishing Product Manager: Neha Sharma

Book Project Manager: Uma Devi

Senior Editor: Sayali Pingale

Technical Editor: Arjun Varma

Copy Editor: Safis Editing

Proofreader: Safis Editing

Indexer: Subalakshmi Govindhan

Production Designer: Joshua Misquitta

Marketing Coordinators: Marylou De Mello and Shruthi Shetty

First published: November 2023

Production reference: 2211024

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK

ISBN 978-1-80324-848-6

www.packtpub.com

To my romantic partner, Jason “Schizoid” Smith. Thank you for your loving encouragement of me and for allowing my star to shine alongside yours, albeit in a different medium. Your loving support has helped my professional focus.

To the Smith and Kowatsch families, thank you for accepting me.

To my late father, Michael Crawley, thank you for nurturing my writing talent and interest in computers when my age was in the single digits.

To Ossington, Amelia, Indie, Insfjull, Luci, Annie Aurora, Etoile, Bronto, Leonard, and the rest of my animal family, thank you for the naps and cuddles.

To all of my social media followers on BlueSky, LinkedIn, and Mastodon, thank you for reading what I write!

Contributors

About the author

Kim Crawley is a thought leader in cybersecurity, from pentesting to defensive security, and from policy to cyber threat research. For nearly a decade, she has contributed her research and writing to the official corporate blogs of AT&T Cybersecurity, BlackBerry, Venafi, Sophos, CloudDefense, and many others. She has been an internal employee of both Hack The Box and IOActive, a leading cybersecurity research firm.

With the hacker mindset, she hacked her way into various information security subject matters. She co-authored one of the most popular guides to pentester careers on Amazon, The Pentester Blueprint, with Philip Wylie for Wiley Tech. She wrote an introductory guide to cybersecurity for business, 8 Steps to Better Security, which was also published by Wiley Tech. She also wrote Hacker Culture: A to Z for O’Reilly Media.

To demonstrate her knowledge of cybersecurity operations, she passed her CISSP exam in 2023. In her spare time, she loves playing Japanese RPGs and engaging in social justice advocacy. She’s always open to new writing, research, and security practitioner opportunities.

About the reviewers

Johnny Justice is an army veteran and cybersecurity professional, with over 23 years of experience. He is CEO and co-founder of ./Security, LLC, specializing in network penetration testing, digital forensics, and management. He spent 14 years conducting offensive cyberspace operations for the National Security Agency and US Cyber Command. He has developed cybersecurity courses for Mile2. He holds an MS in computer science education and a BS in information technology management. He is pursuing a Doctor of Science degree in cybersecurity and holds Offensive Security Certified Professional (OSCP) and GIAC Exploit Researcher and Advanced Penetration Tester (GXPN) qualifications. Apart from this book, he has reviewed the first edition of Hacker Culture: A to Z.

I would like to thank Kim for giving me the chance to review this book. A heartfelt thank you to the publication team and everyone at Packt Publishing for giving me this opportunity. Collaborating with you was a delightful experience.

To my wife, Mary, and our daughters, Diana and Gemma – your unwavering support means the world to me. The successes I achieve mirror the abundant love and backing you’ve always given me – I love you guys very much.

Shahrukh Iqbal Mirza, a seasoned cybersecurity professional with five years of experience, specializes in offensive security, particularly red teaming and penetration testing. Transitioning from petroleum engineering to information security for his master’s degree, Shahrukh discovered his passion. He’s an avid hacker, CTF player, and bug bounty hunter, and maintains a technical blog on Medium.

I’d like to thank my family, who understand the time and commitment it takes to research and test data that is constantly changing. Working and growing in this field would not be possible without the constant support and motivation from them. A huge shoutout to my wife for tolerating and standing by my side, despite my messed-up and workaholic schedule!

Zoe Braiterman is an IT security consultant, researcher and writer. She is passionate about open source; open knowledge sharing; education as a driver of innovation; and diversity, equity, and inclusion.

Table of Contents

Preface

Part 1: Today’s Cloud Networks and Their Security Implications

1

How Do Enterprises Utilize and Implement Cloud Networks?

Cloud networks today

Hybrid cloud, all-cloud, and multi-cloud networks

All-cloud networks

Hybrid cloud networks

Multi-cloud networks

Why an organization would have a multi-cloud network

The cloud migration process

Security responsibilities in the cloud

AWS

Azure

GCP

The difference between IaaS, PaaS, and SaaS

Summary

Further reading

2

How Are Cloud NetworksCyber Attacked?

Understanding penetration testing

External and internal attacks

External cyberattacks

Internal cyberattacks

Attacks on the confidentiality, integrity, and availability of cloud data

Confidentiality

Integrity

Availability

Understanding lateral movement in the cloud

Exploitation of remote services

Internal spearphishing

Lateral tool transfer

Remote service session hijacking

Software deployment tools

Tainted shared content

Zero-trust networks

Summary

Further reading

3

Key Concepts for Pentesting Today’s Cloud Networks

Cloud platform policies, benchmark checks, and services enumeration

Exposed services, permissions, and integrations

Exposed services

Permissions

Cloud integration

CVE, CVSS, and vulnerabilities

Vulnerabilities

The MITRE database

How do vulnerabilities get recorded in the CVE database?

Purple teaming and writing pentest reports

Purple teaming

Writing pentest reports

Summary

Further reading

Part 2:Pentesting AWS

4

Security Features in AWS

Introduction to AWS

Frequently used AWS SaaS features

AWS IaaS features

Compute services

Storage services

AWS PaaS features

AWS security controls and tools

Security controls

Security tools

Summary

Further reading

5

Pentesting AWS Features through Serverless Applications and Tools

Technical requirements

How to get an AWS network

Using AWS PowerShell and the AWS CLI

Bash commands

PowerShell commands

Exploring AWS-native security tools

AWS Security Hub

Amazon Inspector

Installing and preparing AWS pentesting tools

Prowler

Pacu

Cred Scanner

CloudFrunt

Redboto

Exploiting AWS applications

Prowler

Pacu

Summary

Further reading

6

Pentesting Containerized Applications in AWS

Technical requirements

How containerization works

How Docker works in AWS

Installing a Docker cluster in AWS with Amazon ECS

Deploying Docker with Docker Desktop

How Kubernetes works in AWS

Docker and Kubernetes pentesting techniques in AWS

Installation in Docker

Installation in Kubernetes

Summary

Further reading

Part 3:Pentesting Microsoft Azure

7

Security Features in Azure

Introduction to Azure

Frequently used Azure SaaS applications

Azure Maps

Azure Digital Twins

Azure Monitor

Microsoft Cost Management

Azure Advisor

Network Watcher

Azure IaaS applications

Azure Virtual Machines

Azure Kubernetes Service

Azure Container Instances

Azure Dedicated Host

Azure PaaS applications

Azure SQL Database

Web Apps

Mobile Apps

Azure Logic Apps

Azure Functions

Azure security controls and tools

Security controls

Security tools

Summary

Further reading

8

Pentesting Azure Features through Serverless Applications and Tools

Technical requirements

Setting up an Azure instance

Setting up an Azure account

Using Azure Cloud Shell and PowerShell

Azure native security tools

Microsoft Defender

Azure pentesting tools

Prowler

MFASweep

ScoutSuite

Exploiting Azure applications

Prowler

MFASweep

ScoutSuite

Summary

Further reading

9

Pentesting Containerized Applications in Azure

Technical requirements

How containerization works

How Docker works in Azure

How Kubernetes works in Azure

Docker and Kubernetes pentesting techniques in Azure

kube-hunter

kdigger

Summary

Further reading

Part 4:Pentesting GCP

10

Security Features in GCP

Introduction to GCP

Frequently used GCP SaaS applications

Google Workspace

Google App Engine

Cost Management

Google Cloud app

Google Marketing Platform

GCP IaaS services

Compute Engine

Cloud Storage

Shielded VMs

Sole-tenant nodes

GCP PaaS services

Cloud SDK

Cloud SQL

Cloud Run

GKE

Anthos

GCP security controls and tools

Security controls

Security tools

Summary

Further reading

11

Pentesting GCP Features through Serverless Applications and Tools

Technical requirements

GCP free tier

Launching a GCP network

Using GCP Cloud Shell

GCP native security tools

Exploring the GCP console

Installing GCP pentesting tools

Prowler

GCPBucketBrute

GCP Scanner

Exploiting GCP applications

Prowler

GCPBucketBrute

GCP Scanner

Summary

Further reading

12

Pentesting Containerized Applications in GCP

Technical requirements

How containerization works

VMs

Containers

How Docker works in GCP

How Kubernetes works in GCP

Docker and Kubernetes pentesting techniques in GCP

Deploying Docker

Deploying Kubernetes

Trivy

Summary

Further reading

13

Best Practices and Summary

Content review

Questions

Answers

Your cloud pentesting toolkit

Cloud and pentester certifications

Cloud

Pentesting

Pentesting contracts

Pentest reports

Summary

Further reading

Index

Why subscribe?

Other Books You May Enjoy

Packt is searching for authors like you

Share your thoughts

Download a free PDF copy of this book

Preface

Congratulations, dear reader! Over the past 15 years or so, there has been tremendous growth in the use of cloud platforms. Amazon’s AWS formally launched in 2006, and Microsoft Azure and Google Cloud Platform (GCP) soon followed in 2008. There are many cloud platforms out there, but AWS, Azure, and GCP are the most popular. AWS, Azure, and GCP empower companies, organizations, and enterprises to deploy networks that are more powerful and scalable than what was possible to do on their own premises. Many organizations even have more than one cloud platform in their networks.

Cloud networks are connected to the public internet, so naturally, they’re susceptible to a wide range of cyberattacks. With the growing popularity of cloud platforms and companies realizing that they need to secure their cloud networks for the sake of business success, people with cloud penetration testing skills are greatly needed in the international job market. By learning how to simulate cyberattacks in cloud platforms for the sake of security testing, your abilities will be desired, no matter where in the world you are.

Pentesting and red teaming in cloud platforms is fundamentally different from doing so in a company’s on-premises networks because Amazon, Microsoft, and Google own the infrastructure. There are rules and policies that you must abide by as a pentester beyond your organization’s own rules and policies. This book will teach you how to perform penetration tests and red team engagements in a cloud-native way.

Who this book is for

This book is for both experienced pentesters and people who are just starting to learn pentesting. If you have experience with traditional pentesting in on-premises networks, this book will teach you how pentesting with AWS, Azure, and GCP is a bit different. If you’re just starting to learn pentesting in general, this book is a great starting point because the cloud is the future of pentesting. Either way, you should be comfortable with computer networking and eager to refine your skills.

What this book covers

Chapter 1, How Do Enterprises Utilize and Implement Cloud Networks?, introduces AWS, Azure, and GCP, the difference between hybrid cloud, all-cloud, and multi-cloud networks, software-as-a-service, platform-as-a-service, and infrastructure-as-a-service, and the shared cybersecurity responsibilities between organizations and their cloud providers. Before you start pentesting in AWS, Azure, and GCP, it’s important to understand why and how enterprises use those cloud platforms.

Chapter 2, How Are Cloud Networks Cyber Attacked?, examines how cloud networks are susceptible to a wide range of cyberattacks. This chapter explains the various types of cyber attacks, both external and internal, and attacks that impact the confidentiality, integrity, and availability of computer data, based on the CIA Triad cybersecurity model. You will test the security of cloud networks, based on simulating some of the actions of cyber threat actors.

Chapter 3, Key Concepts for Pentesting Today’s Cloud Networks, covers the core concepts and procedures that are applicable to all cloud pentests. Before a pentest or red team engagement is conducted, security professionals must understand the state and scope of their pentest target. You should conduct a vulnerability assessment to find exposed services and integrations, and once a pentest is done, you need to share your findings effectively so that your client’s security posture can be improved accordingly.

Chapter 4, Security Features in AWS, explores the plethora of features, applications, and tools that are specific to AWS and their implications for pentesters. This chapter also covers AWS’s own security policies and security tools.

Chapter 5, Pentesting AWS Features through Serverless Applications and Tools, discusses the most relevant and effective security features and tools to conduct the most successful AWS pentest possible. There are a number of security controls, security features, and pentesting tools that are specific to AWS, both first-party and third-party.

Chapter 6, Pentesting Containerized Applications in AWS, dives into the specific technicalities of how Docker and Kubernetes are deployed and managed in AWS. Enterprises are increasingly deploying containerized applications within AWS to fully leverage the scalability of containerization for virtualization. You will then learn pentesting techniques that are unique to how those containerization platforms run in AWS.

Chapter 7, Security Features in Azure, explores the plethora of features, applications, and tools that are specific to Azure and their implications for pentesters. The chapter also covers Azure’s own security policies and security tools.

Chapter 8, Pentesting Azure Features through Serverless Applications and Tools, examines the most relevant and effective security features and tools to conduct the most successful Azure pentest possible. There are a number of security controls, security features, and pentesting tools that are specific to Azure, both first-party and third-party.

Chapter 9, Pentesting Containerized Applications in Azure, covers the specific technicalities of how Docker and Kubernetes are deployed and managed in Azure. Enterprises are increasingly deploying containerized applications within Azure to fully leverage the scalability of containerization for virtualization. You’ll also learn pentesting techniques that are unique to how those containerization platforms run in Azure.

Chapter 10, Security Features in GCP, dives into the plethora of features, applications, and tools that are specific to GCP and their implications for pentesters. This chapter also covers GCP’s own security policies and security tools.

Chapter 11, Pentesting GCP Features through Serverless Applications and Tools, examines the most relevant and effective security features and tools to conduct the most successful GCP pentest possible. There are a number of security controls, security features, and pentesting tools that are specific to GCP, both first-party and third-party.

Chapter 12, Pentesting Containerized Applications in GCP, covers the specific technicalities of how Docker and Kubernetes are deployed and managed in GCP. Enterprises are increasingly deploying containerized applications within GCP to fully leverage the scalability of containerization for virtualization. You’ll also learn pentesting techniques that are unique to how those containerization platforms run in GCP.

Chapter 13, Best Practices and Summary, reviews what you’ve learned after performing pentesting exercises in AWS, Azure, and GCP. This chapter also explains the work that you need to do before and after your pentests and red team engagements. Most importantly, you’ll need to define a scope for your engagements with the organization that you work for that abides by AWS, Azure, and GCP’s policies, sign legal documents that formalize your scope and responsibilities, and write a pentest report that will help the business leaders and defensive security team in your organization improve their network’s cybersecurity.

To get the most out of this book

You’ll need the following:

Software/hardware covered in the book

Operating system requirements

AWS web console at aws.amazon.com

Windows 7, 8, 10, or 11, macOS 11–14, or currently supported Linux distributions, with currently supported versions of the Safari, Edge, Chrome, Firefox, or Opera web browser

Microsoft Azure web console at azure.microsoft.com

Windows 7, 8, 10, or 11, macOS 11–14, or currently supported Linux distributions, with currently supported versions of the Safari, Edge, Chrome, Firefox, or Opera web browser

Google Cloud Platform web console at console.cloud.google.com

Windows 7, 8, 10, or 11, macOS 11–14, or currently supported Linux distributions, with currently supported versions of the Safari, Edge, Chrome, Firefox, or Opera web browser

Prowler

Supported in AWS, Azure, and GCP; the endpoint operating system is irrelevant

Pacu

Supported in AWS, the endpoint operating system is irrelevant

Cred Scanner

Supported in AWS, the endpoint operating system is irrelevant

CloudFrunt

Supported in AWS, the endpoint operating system is irrelevant

Redboto Python scripts

Supported in AWS, the endpoint operating system is irrelevant

Docker Desktop

Windows 7, 8, 10, or 11, macOS 11–14, or currently supported Linux distributions

ScoutSuite

Supported in AWS, Azure, and GCP; the endpoint operating system is irrelevant

MFASweep

Supported in Azure, the endpoint operating system is irrelevant

kube-hunter

Supported in all current versions of Kubernetes; the endpoint operating system is irrelevant

kdigger

Supported in all current versions of Kubernetes; the endpoint operating system is irrelevant

GCPBucketBrute

Supported in GCP, the endpoint operating system is irrelevant

GCP Scanner

Supported in GCP, the endpoint operating system is irrelevant

Code in Action

The Code in Action videos for this book can be viewed at https://bit.ly/3rWmFnS.

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

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: “Mount the downloaded WebStorm-10*.dmg disk image file as another disk in your system.”

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

pip install --upgrade pip pip install prowler

Bold: Indicates a new term, an important word, or words that you see on screen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “Select System info from the Administration panel.”

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, email us at [e-mail] and mention the book title in the subject of your message.

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 and fill in the form.

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 [e-mail] 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.

Share your thoughts

Once you’ve read Cloud Penetration Testing, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/9781803248486

2. Submit your proof of purchase

3. That’s it! We’ll send your free PDF and other benefits to your email directly

Part 1: Today’s Cloud Networks and Their Security Implications

Pentesters and red teams test the security of computer systems. In this book, the types of computer systems you will learn how to pentest are cloud applications and networks. Before you start testing something, you should understand what it is that you’re testing in the first place! So, in this part, we will learn all about the different types of cloud services and applications, why organizations use them, and how they’re configured and deployed. We will also learn about the basics of pentesting and red teams. This knowledge will set a foundation for everything else that you’ll learn in this book.

This section has the following chapters:

Chapter 1, How Do Enterprises Utilize and Implement Cloud Networks?Chapter 2, How Are Cloud Networks Cyber Attacked?Chapter 3, Key Concepts for Pentesting Today’s Cloud Networks

1

How Do Enterprises Utilize and Implement Cloud Networks?

Welcome, readers! Whether you’re already an experienced penetration tester or you’re new to cybersecurity, penetration testing cloud networks requires specialized knowledge. One of the key differences between penetration testing cloud networks and penetration testing on-premises networks and computer systems is that the organization you’re working for doesn’t own everything in its computing environment. When you conduct red team engagements in cloud networks, both the organization you work for and its cloud provider (whether that's Amazon Web Services (AWS), Azure, or Google Cloud Platform (GCP)) have needs that must be respected. The good news is if you master the skill of pentesting cloud networks, you may have a lucrative career ahead of you. Organizations use the cloud now more than ever, and demand for cloud services continues to grow.

Penetration testers simulate cyber attacks within a network with permission of its owner, in order to find security vulnerabilities that an attacker can discover. The company that hires you to penetration test (pentest) will have likely already performed vulnerability assessments and audits on their network. A lot of security vulnerabilities can be found through assessments and auditing. Pentesting is a hands-on review for finding additional security vulnerabilities that may have been missed.

A red team is a group within an organization that performs targeted pentests on a regular basis. Your company’s cybersecurity team may become aware of new cyber threats and advanced persistent threats (APTs) from the security operations center (SOC) or the broader cybersecurity community. The red team will be informed of particular emerging threats and be asked to simulate them. By doing that, the red team will discover vulnerabilities that the emerging attackers may exploit. Those discoveries are shared with the defensive security team, who will security harden their network accordingly before the threat strikes their organization. For instance, a new ransomware group may make news headlines. It’s the red team’s job to research how the new ransomware group operates. Then, the next step is for them to pretend to be that new ransomware group in their next red team engagement. The red team, the offensive security specialists, will probably be kept pretty busy year-round, because lots of new cyber attack groups and cyber threats emerge every year, every month, every week, and every day!

In this chapter, we’ll cover the following main topics:

Cloud networks todayHybrid cloud, all-cloud, and multi-cloud networksWhy an organization would have a multi-cloud networkThe cloud migration processSecurity responsibilities in the cloudThe difference between Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS)

Let’s get started!

Cloud networks today

To be able to effectively test your pentest target, you must first understand it. Cloud networks have been popular with the enterprise market ever since AWS took its current form in 2006. Microsoft Azure and GCP have been around since 2008. These three cloud platforms are the most frequently used by businesses and enterprises of all kinds, all around the world. Most enterprises use at least one cloud platform in their networks these days. Some enterprises even use multiple cloud platforms. So, what are cloud platforms, and why are they so popular? How do cloud platforms improve how companies do business over the internet?

In the 1990s, enterprises had to host their own data centers on their premises. Web hosting providers started to operate that decade, but they only offered web servers and email servers. That’s good for an organization’s website and email, but not for anything else. If companies needed to run their own, more complex applications and digital services, they needed to have their own server rooms and equipment.

Any network administrator with years of experience understands that enterprises can have rapidly changing computer networking needs. Bandwidth and data storage usage may double in a couple of months, and then halve in another couple of months. If their capacity needs quickly grow in a short period of time, lots of new server machines and networking infrastructure would have to be procured, and they would need a lot more physical space for them to occupy. If their capacity needs shrank quite a bit, a lot of expensive server machines, networking infrastructure, and physical space would have to go to waste. There are a lot of inconveniences, inefficiencies, and financial waste that are inevitable when a company deploys a large network on-premises.

The 21st century so far has brought useful advancements in computer networking technology. Tech giants such as Amazon, Microsoft, and Google have massive data centers all around the world. They began to utilize their massive computer networking infrastructure by offering it to third-party businesses and other entities. AWS launched in 2006, then Microsoft Azure and GCP followed in 2008. They made it easier and more frictionless than ever for businesses to deploy networks on their infrastructure.

Containerization is a way to implement operating system and hardware virtualization with load balancing to deploy applications through networks in a scalable and dynamic way that uses server machines more efficiently. When an operating system is virtualized, it runs like an application within another operating system with simulated hardware specifications. Load balancing distributes network traffic across multiple server machines, and it prevents server overload by improving application availability and responsiveness. Each container has operating system components and is part of an application. Containers run within a containerization orchestration platform and a host operating system or direct hypervisor. Because containers are self-sufficient virtualized entities, an application might use a large number of them at any given time, and any individual container might only live for a few days. Containers can be quickly launched and terminated according to what a cloud application needs as it operates continuously.

Docker emerged in 2013, and Kubernetes started to become popular in 2015. There are other containerization orchestration platforms, but Docker and Kubernetes are the ones you’ll see in cloud networks the most often. Those are the containerization orchestration platforms that are best supported by AWS, Azure, and GCP. As containerization became more common, it helped to encourage more enterprises to implement cloud platforms into their networks.

The DevOps approach has transformed the manner in which organizations roll out their applications. It’s a predominant method for developing applications intended for cloud deployments. By merging the development and operations (IT) teams, DevOps fosters continuous collaboration. The teams patch applications and deploy new features in small pieces, and very frequently. Instead of releasing version 1.5 of an application one year and version 1.6 the next, applications can be updated several times per month. DevOps complements agile application development, so applications are deployed more efficiently and responsively. It’s possible to use the DevOps methodology without the cloud, but the cloud makes it much more feasible. You will likely be pentesting DevOps applications at least at some point as a cloud pentester. And because of how frequently DevOps applications change, that’ll keep you very busy. DevSecOps is when security is implemented into DevOps, and you’ll quite possibly be a part of the Sec component of the process.

Ever since AWS, Azure, and GCP launched, they’ve constantly added new services and new features. If each cloud platform’s service list were a restaurant menu, it’d have a handful of dishes in 2009 and multiple pages of entrées by 2023. All of these new services and features have empowered organizations to do a greater variety of things with cloud platforms.

Amazon, Microsoft, and Google are responsible for maintaining their infrastructure and application programming interfaces (APIs) for their services. They’re responsible for running their data centers and managing the massive facilities all around the world in which they operate. That’s a lot of burden that enterprises no longer have to deal with when they use a cloud platform.

If an organization needs to double its data storage capacity and network bandwidth all of a sudden, all it has to do is ask Amazon, Microsoft, or Google, pay their fees, and it’ll have it almost immediately. If an organization’s networking needs are reduced, decreasing its data storage and bandwidth is just as easy. That’s what we call scalability. Cloud services dynamically and responsively scale according to an organization’s computing needs at any given time.

Combine AWS, Azure, and GCP’s massive infrastructure with containerization, and cloud networks can grow and evolve very quickly without an enterprise having to deal with the hassles of running their own data centers. Applications can grow, shrink, and rapidly change. The organization deploying an application has full control, while the cloud platform provider deals with all of the physical tedium.

Services such as Netflix, Steam, and Dropbox are responsive and powerful today because they leverage the potential of the cloud. And of course, lots of much smaller organizations in a wide variety of industries also use cloud platforms. The same AWS data center could have a famous video streaming service and a tax and accounting small business operating in the same facility, perhaps even on some of the same physical server machines.

So, that’s why cloud platforms are so popular these days. Businesses are now deeply committed to using cloud platforms, so you’ll be expected to understand them very well as a pentester on a red team. Cloud platforms are an essential business tool in the 21st century. Unfortunately, because cloud platforms operate through the internet, they’re subject to a wide variety of terrible cyber threats. Organizations need your talent and skill to think like a cyber attacker. Find the vulnerabilities an attacker will exploit so that your blue team (defensive security specialists) can security harden your cloud networks effectively.

As a red teamer, cyber threats will always keep you on your toes. You’ll always be busy. Heed the words of famous computer scientist and cybersecurity expert Bruce Schneier:

“Security is a process, not a product. Products provide some protection, but the only way to effectively do business in an insecure world is to put processes in place that recognize the inherent insecurity in the products.”

In the next section, we’ll examine the different kinds of cloud networks. How you pentest your organization’s cloud network will vary according to what sort of cloud network it is.

Hybrid cloud, all-cloud, and multi-cloud networks

Cloud networks can take a few different forms. Some organizations maintain their client machines (such as PCs and mobile devices) on their own premises and then run their backend servers completely on one particular cloud platform. It’s an all-cloud network on one platform such as AWS, Azure, or GCP.

Some organizations run some server machines on their own premises and run the rest of their network on one or multiple cloud platforms. That’s a hybrid cloud network—partly on-premises, partly in the cloud.

Some organizations deploy their networks through more than one cloud platform. They may have some parts of their network running on AWS and other parts on Azure, for example. That’s a multi-cloud network.

Let’s examine how these different ways to operate cloud networks work, and why organizations may choose one way over another.

All-cloud networks

An all-cloud network is when an enterprise only has client devices on its premises, and the rest of its network is all on cloud services. Call it entirely cloud, cloud-first, cloud-only, or something else. Whether termed as fully cloud-based, cloud-first, cloud-only, or any other name, this shift away from on-premises backend systems is an emerging industry trend. For the sake of clarity, the backend functions of a network are everything that has to run as a server. That includes databases, web servers, email servers, authentication system servers, and any computer networking function that would typically run in a data center rather than inside someone’s office. Those sorts of needs can theoretically all be run from cloud services, whereas people’s phones, tablets, and PCs (client devices) serve as frontend devices when they’re connected to the network. If I had to physically enter a data center in order to check my email on my phone, I’d find that to be very inconvenient!

Research firm Gartner refers to a cloud-first strategy where enterprises prioritize using cloud platforms. A cloud-first strategy doesn’t necessarily mean that an enterprise has an all-cloud network. An enterprise with a cloud-first strategy may have a lot of legacy technology, or services that otherwise predate the popularization of cloud services from the mid-2000s onward. However, any new function or service is deployed on the cloud, and older services and applications are migrated to the cloud as much as possible.

In November 2021, Gartner said that 85% of organizations will embrace a cloud-first principle by 2025. It also believes that 95% of new digital workloads will be deployed on cloud-native platforms (https://www.gartner.com/en/newsroom/press-releases/2021-11-10-gartner-says-cloud-will-be-the-centerpiece-of-new-digital-experiences). So, if you’re learning to pentest cloud networks, you’re getting into a lucrative line of work!

Hybrid cloud networks

A hybrid cloud network is partly on the cloud and partly on-premises. At least some actual backend server operations must be on the enterprise’s premises and connected to a cloud network in order for it to be a hybrid cloud network. If an organization has an on-premises network and a cloud network that aren’t connected in any way, the organization has two separate networks, not one hybrid network.

Why would an organization choose to have a hybrid cloud network? There can be multiple reasons.

They may have a legacy on-premises network, but they’ve needed to integrate some SaaS or PaaS components that are exclusive to AWS, Azure, or GCP. Maybe they need GCP for Looker business data analytics, Azure for Azure DevOps to support Microsoft ecosystem APIs, or AWS for AWS Lambda hassle-free code execution. All three cloud platforms have services that are unique to their ecosystems, and they may serve a specific business need.

Some other organizations believe that maintaining a hybrid cloud network is effective redundancy. Uptime is the most important metric when it comes to operating any sort of network. Redundancy is an effective way to reduce operational downtime. For instance, if a server has a technical problem that puts it out of service, an identical server elsewhere can ensure that its functions keep running. An enterprise may find that having some network infrastructure that it physically controls is good for redundancy. Of course, it cannot physically control cloud servers; it can only physically control the servers that are on its premises. The same applies to networking infrastructure. Cloud providers give organizations a lot of control over the parts of their networks that run on cloud infrastructure, but they cannot allow an organization’s network administrators to walk into one of their cloud data centers and physically turn a server machine off and on again. Other reasons why an organization may prefer to maintain a hybrid network are disaster recovery (DR) or regulatory compliance. There may be details in its DR procedures or in the regulations it needs to comply with that require it to have physical access to some of its network.

Some organizations may have service-level agreements (SLAs) with vendors that predate their usage of cloud services. An SLA is a legal agreement between a vendor and a client that outlines the services the client expects to receive, the services the vendor agrees to deliver, and the metrics they’ll use to measure performance. A vendor can be anything from a cloud platform (such as AWS) or any other sort of IT service (such as Slack or Cloudflare). Old SLAs can sometimes make cloud migration tricky. So, some enterprises may wait until their older contracts expire before going all-cloud. In the meantime, they may find a compromise where they maintain their on-premises infrastructure for a period of time while they implement cloud services into their network.

If an organization has a hybrid cloud, it’ll likely keep its more sensitive or critical data operations on-premises. Sensitive data and systems can include things such as public key infrastructure (PKI), critical databases, and highly sensitive financial or medical data that organizations must keep on their premises in order to be regulatory compliant.

Multi-cloud networks

In a multi-cloud network, more than one cloud provider is implemented into an enterprise’s network. For example, it could have AWS and GCP, or a combination of AWS and Azure, or AWS, Azure, and GCP combined. A multi-cloud network may also be a hybrid cloud network if the enterprise also has an on-premises component. Either way, the parts of their network on different cloud platforms have to be connected in some way. Otherwise, they have multiple networks. When you conduct red team engagements for your organization, the reasons for their cloud strategy matter. It’ll help you understand how it uses its cloud network, which will help you understand how cyber threats may impact the organization. Those are the sort of cyber threats you should be simulating in your pentesting. So, let’s examine why many organizations choose to have multi-cloud networks.

Why an organization would have a multi-cloud network

As I’ve mentioned, AWS, Azure, and GCP each have some services that are unique to each of them. A business may find that the combination of PaaS and SaaS applications that best serve its operational needs are all on different cloud platforms. An enterprise could have Azure OpenAI Service for automated customer service, Amazon GameLift to host its online video game servers, and a payment gateway on GCP to process customer credit card transactions.

Michael Warrilow, VP Analyst at Gartner, says this:

“Most organizations adopt a multi-cloud strategy out of a desire to avoid vendor lock-in or to take advantage of best-of-breed solutions. We expect that most large organizations will continue to willfully pursue this approach.”

According to a survey Gartner conducted in 2019, 81% of their respondents are working with two or more providers. That was at least a few years ago. Gartner foretasted an increase in worldwide end-user spending on public cloud services to grow from $490.3 billion in 2022 to $591.8 billion in 2023. Maybe multi-cloud networks are an even larger market segment now. This is important to acknowledge because you may be pentesting some of these services.

You should also understand the difference between public clouds and private clouds.

Up until this point, all of my mentions of the cloud have referred to public clouds. Using AWS, Azure, and GCP usually refers to public cloud usage. A public cloud is a cloud network that shares physical servers and other infrastructure with other users, customers, and clientele.

A lot of consumer internet services are driven by public clouds. Listening to Spotify, watching YouTube, uploading personal files to Dropbox, conducting meetings over Zoom, buying games from Steam, and engaging in multiplayer gameplay—these are all common ways that consumers use public cloud-driven applications. And they might not even know it! Businesses often use public cloud services in similar ways—collaborating on documents with Google Docs, conversations over Slack, and meetings through Microsoft Teams.

The majority of business usage of AWS, Azure, and GCP is also public cloud. Private cloud services on third-party infrastructure (AWS, Azure, GCP) are often more expensive. If a company signs up for services such as AWS CodeArtifact for package management, or Computer Vision on Azure for image and video analysis, those are public cloud services. Any service with a free trial period is probably a public cloud service.

Private cloud services can take two forms. They can be on a company’s own premises. Some enterprises have replicated the cloud computing model on their own infrastructure. Alternatively, AWS, Azure, and GCP do offer some private cloud services. For example, AWS offers Amazon Virtual Private Cloud (Amazon VPC).

There are advantages and use cases for both public cloud and private cloud services.

Public cloud services are often a great choice for enterprises because they don’t require capital expenditures; their accountants can budget it as an operational expenditure. From the business end, they’re not paying for products; they’re paying for services. There can be taxation and legal benefits to making a service an operational expenditure rather than a capital expenditure. Public cloud services are usually more scalable because there are no dedicated physical or virtual server machines involved. Enterprises can efficiently use as much or as little space as they need at any given time as long as they’re willing to pay the service fees. Public cloud services also involve less overhead for a business because a third party is responsible for maintaining the infrastructure.

One of the main reasons why an organization may require private cloud services is cybersecurity. As with having any other sort of on-premises component in other types of hybrid cloud networks, regulatory compliance may mandate private instead of public cloud usage. Because an enterprise has exclusive use of a private cloud, it can maintain more control and implement stricter security measures. The regulations it may need to comply with are even more likely to apply to sensitive financial or medical data. For instance, using a private cloud rather than a public cloud may be necessary for the Health Insurance Portability and Accountability Act (HIPAA) (a set of medical data regulations in the United States), or Sarbanes–Oxley (a set of financial data regulations in the United States) compliance in some situations. Also, as with non-cloud on-premises network usage, an organization may choose to deploy the cloud computing model on its own infrastructure for its DR needs.

A hybrid cloud network may have a non-cloud on-premises component, a cloud on-premises component, or a private cloud on a third-party infrastructure component. If a private cloud is on third-party infrastructure through AWS, Azure, or GCP, it’ll need to connect to the client machines on an enterprise’s premises through private networking—often through some sort of virtual private network (VPN).

The organization you work for may be in the cloud migration process. How your organization migrates to the cloud will impact its security posture! So, we need to better understand cloud migration and how complex it can be.

The cloud migration process

Cloud migration is when an organization moves its data and services from its on-premises infrastructure to a cloud provider. With the rapid growth of the cloud market over the past 15 or 20 years, a large number of enterprises have engaged in the cloud migration process. But cloud migration isn’t simple, and it can be done incorrectly or ineffectively.

All enterprises must plan carefully in order to migrate to the cloud effectively. Depending on the situation and their needs, they may prefer to migrate to the cloud in stages over the course of months or years rather than do it all at once.

When planning a cloud migration strategy, organizations should understand the problems that can occur with cloud migration so that they can be avoided.

An enterprise’s services may experience downtime during the cloud migration process. Depending on how it migrates to the cloud, some of its servers may have to go completely offline for a period of time. The enterprise’s customers may be very unhappy if the services they receive are interrupted, especially if they spend a lot of money on them. In the cloud migration process, an enterprise’s supply chain must be considered as well as its customer base. An enterprise may have to either plan and prepare for the consequences of downtime, or carefully fine-tune its cloud migration strategy so that there’s no downtime at all.

Interoperability may be a problem. The enterprise’s applications run on its own infrastructure and may not be fully compatible with its cloud service without some tweaks or adjustments. Interoperability is less likely to be a problem if the cloud service it’s migrating to is IaaS. But some applications require implementation with PaaS or SaaS. Interoperability issues must be carefully accounted for when designing a cloud migration strategy.

Crucial data could be lost in the cloud migration process. It could become subject to a data breach or become unavailable. Privileged access management and encryption are security measures that can be used in the cloud migration process to avoid that problem. It’s also important to completely inventory data, applications, and workloads that are being migrated to the cloud. You can’t secure what you can’t see!

Employees who are used to managing data and workloads on-premises may not be familiar with how the details of their tasks may change once they are migrated to the cloud. An enterprise may need to assign new roles in the organization according to the specifics of its cloud infrastructure and implementation. Employees also need training on all of the applicable new technologies they’ll be working with during and after cloud migration.

So, those are some of the more common problems that can occur during the cloud migration process. Those problems are avoidable with careful preparation and planning. Enterprises migrate to the cloud for many good reasons. Let’s examine why.

Cloud networks offer enterprises operational agility. They make it more feasible for employees to work from home and work while they’re traveling. The COVID pandemic has sparked ongoing effects. Scientific research from various entities around the world has shown that many millions of people have left the workforce worldwide due to early death and long-term disability from long COVID. Employees have found better safety and productivity by working from home instead of having to work on-site. Smart employers want to keep their workers healthy and productive and understand the benefits of protecting them from airborne disease. Facilitating working from home with cloud migration is an effective strategy.

The major cloud platforms have security controls that, if used properly, can make remote access to corporate networks more secure from cyber attacks. Cloud adoption and supporting remote work is the 21st-century way of doing business, and companies that don’t understand that are losing crucial talent.

Cloud migration can help reduce capital expenditures and related burdens. Companies don’t have to pay for additional real estate to provide spaces to run their own massive data centers. Amazon, Google, and Microsoft have many of the largest data centers on Earth, on all populated continents. From India to Japan, from the United States to Indonesia, from France to South Africa, many people and employers work within 1,000 kilometers of an AWS, GCP, or Azure data center. But even employers who are 5,000 kilometers from their nearest cloud platform data center still enjoy fast data transfer and minimal latency. Plus, all three cloud providers add new data centers to more parts of the globe each and every year. For many companies, replacing their own on-premises data centers with the flexibility and agility of operating in the cloud is an obvious choice. The reduction in capital expenditures also measurably improves their bottom line.

Even though some companies want to keep some of their network on their premises to facilitate DR (because they’ll have physical access to some of their infrastructure), other companies cite DR as a reason to migrate to the cloud. This shows how complex and nuanced many of these practicalities of operating enterprise networks can be in the real world. AWS, Azure, and GCP all have DR tools and advise companies on how to use them effectively. The massive capacity of their data centers makes it easier and more affordable for companies to maintain backups of petabytes’ and exabytes’ worth of data. The cloud platforms also offer useful tools for organizations to periodically test the viability of their backups, and also to store different types of snapshots. If an organization keeps none of its backend on its premises, its data can be kept safer if its premises are hit by a flood, fire, or earthquake. Amazon, Google, and Microsoft also build redundancy and resiliency into their own networks. They have systems in place for operation if a disaster strikes one of their international data centers. Plus, their physical security is hardened beyond what most organizations can afford to do themselves for their own premises.

So, let’s look at the cloud migration process. It’s a little bit different for each organization that does it because the nature of their data assets and business operations is unique. But here’s where there’s usually some commonality.

IBM recommends the following steps for every organization’s cloud migration checklist:

First, organizations should inventory their workloads. A workload is any database, application, containerization system, or service that operates in their network. Determine each workload’s size, complexity, and whether or not it’s in production.Research each cloud platform and its applications and services carefully. AWS, Azure, and GCP each offer hundreds of unique services. An organization may need different services on different platforms. The most suitable service should be selected for each workload, and that may result in a need for a multi-cloud network.With services and cloud providers selected, the next step is to conduct a cost assessment.Next, a team should be assigned to execute the migration. There should be people with advanced computer networking and network security skills on that team. The goals of migration should be communicated to the team.Determine how much of the migration will be handled internally, and how much by the cloud provider. All three major cloud providers offer cloud migration services, and organizations should verify what they entail.Prioritize which workloads should be migrated first. There will likely be a period when workloads are mirrored on the on-premises network so that the migration process incurs minimal network downtime.A plan should be prepared that schedules the migration process and outlines the roadmap. The full migration process could take months or a couple of years according to each company’s specific needs and realities.Determine whether there are already cloud services in the enterprise network, and whether or not they should be substituted with other cloud services or augmented into larger cloud workloads. For instance, why should a company keep using Dropbox when their Azure services include Microsoft Teams support or their GCP services include Google Drive integration?Company stakeholders should be informed of what to expect during and after the cloud migration process. The company’s entire supply chain should be included if this impacts them in any way!Key performance indicators (KPIs) should be established for the cloud migration process—for example, “50% of our database traffic should occur in our Amazon EC2 instances.”Progress should be verified and accessed with the cloud migration team periodically. Finally, during and after the process—test, review, and make adjustments when needed.

As a cloud pentester, the few months after the cloud migration process has finished would be an excellent time for a pentest. The common wisdom in our industry is that pentests should be conducted when major changes are made to networks, as change can create new security vulnerabilities. That’s not the only time that pentests and red team engagements should be conducted, but it’s certainly a time when conducting a pentest is crucial.

Understanding security responsibilities in the cloud will directly affect your everyday work as a cloud pentester! You must understand what you’re allowed to do, what you’re forbidden to do, and why. Let’s examine the security responsibilities and the shared responsibility model.

Security responsibilities in the cloud

As a cloud pentester, it’s important for you to understand how the shared responsibility model works in the cloud. The two entities involved are the organization that’s using cloud services, and the cloud provider. When you conduct red team engagements, the organization is the entity you report to, whether you’re an employee or a third-party contractor.

Overall, the organization and the cloud provider have shared security responsibilities. This is often called the shared responsibility model. However, cloud security controls and responsibilities are divided between the two entities.

It’s important for you to understand what the cloud provider is responsible for and what the organization you’re working for is responsible for. At the beginning of each pentest or red team engagement, you will sign a contract that outlines the scope of the pentests and what you’re allowed and not allowed to do. You absolutely must abide by the contract and only pentest within your assigned scope. When you pentest a cloud network, you’re not just simulating cyber attacks in your employer’s environment. You’re also simulating cyber attacks within AWS, Azure, or GCP’s infrastructure. The cloud providers have their own rules for what you’re allowed and not allowed to do. If you’ve pentested on-premises networks before, you may find that your scope and permissions are more limited when pentesting a cloud environment.