Chapter 4: Attacks and Exploits

This is the chapter where the exam stops asking what you know and starts asking what you would do. Attacks

and Exploits is 35 percent of the PenTest+ exam, the largest domain, and it covers the widest ground: networks,

wireless, applications, cloud, people, passwords, tools, privilege escalation, and the new AI attack surface. The

exam does not test whether you can recite an attack name. It tests whether you can look at a scenario,

recognize the attack that fits it, predict what its output means, and choose the right next step or the right fix.

Every scenario in this chapter is an authorized engagement at CertCrack.com, run under written permission with

a defined scope, or an exercise on the reader's own lab systems. That framing is not decoration. Scope discipline

is part of what the exam tests: an attack that is valid inside scope is a finding, and the same attack outside scope

is an incident. When you read a technique here, read it with two questions in mind: what would this prove about

the target, and what would stop it?

1. Network attacks

Network attacks abuse trust that was built into old protocols. ARP, DNS, and DHCP were designed for networks

where every device was assumed friendly, so they accept answers without checking who sent them. An attacker

on the same network segment exploits that trust, and the exam tests these attacks heavily because they are the

foundation of man-in-the-middle positions: once traffic flows through the attacker, credentials, sessions, and

data follow.

1.1 ARP spoofing

Address Resolution Protocol maps IP addresses to MAC addresses on a local network. When a host needs to

send a packet to an IP address, it broadcasts an ARP request asking who has that address, and the owner replies

with its MAC address. ARP has no authentication, so any device can answer, and hosts cache the answers they

receive.

In ARP spoofing, the attacker sends forged ARP replies telling the victim that the attacker's MAC address belongs

to the gateway, and telling the gateway that the attacker's MAC address belongs to the victim. Both sides update

their ARP caches, and traffic between them now flows through the attacker, who can read, modify, or simply

forward it. On an authorized test at CertCrack.com, this is how a tester demonstrates that a flat office network

lets one compromised workstation intercept traffic from its neighbors.

Detection relies on watching for inconsistencies: ARP monitoring tools flag MAC addresses that change owners,

and duplicate ARP replies for the same address are a strong signal. The real fix is Dynamic ARP Inspection, which

checks ARP packets against the DHCP snooping binding table and drops replies that do not match a legitimate

IP-to-MAC mapping. Static ARP entries and port security help in small, stable environments but do not scale.

1.2 DNS spoofing and cache poisoning

DNS translates names to addresses, and resolvers cache answers to serve future queries faster. In DNS

spoofing, the attacker supplies a forged answer to a query, sending the victim to an attacker-controlled address

instead of the real one. In cache poisoning, the forged answer is accepted into a resolver's cache, so every client

using that resolver is redirected until the cached record expires.

The classic poisoning technique is a race: the attacker floods the resolver with forged responses to a query the

resolver is waiting on, hoping one arrives before the legitimate answer and matches the transaction ID and

source port. Modern resolvers randomize both, which makes the race much harder, but the attack still appears

on the exam because it explains why DNS integrity matters. The mitigations are DNSSEC, which

cryptographically signs DNS records so forged answers fail validation, and DNS over HTTPS or DNS over TLS,

which encrypt the query channel.

In an authorized test, DNS spoofing is usually demonstrated on a lab resolver, not on production infrastructure,

because poisoning a real resolver affects every user behind it. The exam's favorite scenario is a victim reaching a

convincing login page at the wrong address: the finding is the missing DNSSEC validation, and the fix is enabling

it.

1.3 DHCP spoofing

DHCP assigns addresses automatically, and clients accept the first offer they receive. A rogue DHCP server on

the segment can answer faster than the legitimate one, handing clients an address, a gateway, and DNS servers

of the attacker's choosing. From there the attacker controls name resolution and routing for every client that

accepted the offer, which is a clean path to traffic interception and credential capture.

A related technique is DHCP starvation, where the attacker floods the legitimate server with requests using fake

MAC addresses until its address pool is exhausted, leaving clients with no choice but the rogue server. The

mitigations are DHCP snooping, which builds a binding table of legitimate IP-to-MAC-to-port mappings and

drops DHCP offers from untrusted ports, and 802.1X authentication, which keeps unauthorized devices off the

segment entirely.

1.4 VLAN hopping and STP manipulation

Virtual LANs separate traffic on shared switches, but the separation is only as strong as the switch configuration.

VLAN hopping breaks it in two ways.

Double tagging exploits the native VLAN. The attacker sends a frame with two 802.1Q tags: an outer tag

matching the native VLAN and an inner tag matching the target VLAN. The first switch strips the outer tag

because the frame arrived on a native VLAN port, then forwards the frame, still carrying the inner tag, into the

target VLAN. This works only in one direction and only when the attacker sits on a native VLAN port, which is why

the mitigation is to move the native VLAN to an unused VLAN ID and never use VLAN 1 for real traffic.

Switch spoofing exploits the Dynamic Trunking Protocol. If a switch port is left in a mode that negotiates

trunking, the attacker can negotiate a trunk link and then receive traffic from all VLANs. The mitigation is to set

every access port to non-negotiating access mode and disable DTP outright.

Spanning Tree Protocol manipulation targets the switching topology itself. Switches elect a root bridge based on

the lowest bridge priority in bridge protocol data units. An attacker that sends BPDUs advertising a lower

priority becomes the root bridge, and traffic reroutes through the attacker's machine. The mitigations are BPDU

Guard, which disables a port the moment it receives a BPDU on an access port, and Root Guard, which blocks

superior BPDUs on ports that should never become root.

1.5 Kerberos attacks

Kerberos is the authentication protocol of Active Directory, and its ticket system is a rich target. A simplified view

is enough for the exam: a client requests a ticket-granting ticket from the Key Distribution Center, then uses it to

request service tickets for specific services, and each ticket is encrypted with a key derived from the account's

password hash. Attacks on this system all follow the same logic: get an encrypted ticket or hash, then work on it

offline, where no lockout or alerting applies.

Kerberoasting targets service accounts. Any authenticated user can request a service ticket for any account that

has a service principal name, and that ticket is encrypted with the service account's password hash. The attacker

takes the ticket offline and cracks it at leisure. Service accounts are prime targets because they often have weak,

rarely changed passwords and the privileges of whatever service they run. The fix is long, random service

account passwords and, where possible, group Managed Service Accounts, which rotate their own passwords

automatically.

AS-REP roasting targets accounts with Kerberos pre-authentication disabled. For such an account, the attacker

can request an authentication response without any credentials, and the response contains data encrypted with

the account's password hash, which is again crackable offline. The fix is simple: require pre-authentication for

every account, and audit for accounts that have it disabled.

Golden and silver tickets are forgeries, and the difference between them is scope. A golden ticket is a forged

ticket-granting ticket, encrypted with the krbtgt account's hash, which grants access to anything in the domain

and can be given a validity of years. Obtaining the krbtgt hash requires domain-level compromise, which is why

a golden ticket is a sign of total compromise. A silver ticket is a forged service ticket, encrypted with one service

account's hash, which grants access to that one service only and never contacts the Key Distribution Center,

making it harder to detect. The exam loves this pair: golden means everything, silver means one service.

Delegation attacks abuse the feature that lets a service act on a user's behalf. With unconstrained delegation, a

service holds copies of users' tickets, so compromising that service lets an attacker steal a domain

administrator's ticket when an administrator connects to it. Constrained delegation limits a service to specific

target services, and resource-based constrained delegation lets the target resource decide who may delegate to

it, which an attacker with write permission on a computer object can abuse to add a machine they control. The

fix is to avoid unconstrained delegation entirely, prefer constrained delegation, and audit delegation settings as

part of every review.

Figure 14: Kerberos ticket attacks — Kerberoasting, AS-REP roasting, golden tickets, and silver tickets compared by what the attacker

needs and what each ticket grants (illustrated)

1.6 SMB relay and pass-the-hash

Windows networks authenticate with NTLM in many places, and two attacks exploit that without ever cracking a

password.

SMB relay starts with name resolution poisoning. A tool like Responder answers LLMNR, NBT-NS, or mDNS

queries for names that do not exist, and when a victim tries to reach a mistyped or unresolvable name, it

authenticates to the attacker instead. The attacker does not crack anything: it relays the victim's live

authentication attempt to a target server that has SMB signing disabled, and the target accepts it as if the victim

had connected directly. The result is a session on the target as the victim. The mitigations are SMB signing on

every host, Enhanced Protection for Authentication, and disabling LLMNR and NBT-NS where they are not

needed.

Pass-the-hash is simpler and does not need a victim to cooperate in the moment. If an attacker captures an

NTLM hash, from memory, from a captured challenge, or from a database, the attacker can present that hash

directly in a new authentication and be accepted, because NTLM authentication proves possession of the hash,

not knowledge of the password. The password is never cracked and never needed. The mitigations are

Credential Guard, which isolates secrets in virtualization-based security, LSA protection, and Local Administrator

Password Solution, which gives every host a unique local administrator password so one captured hash does not

work everywhere.

2. Wireless attacks

Wireless traffic is broadcast by nature, so every wireless attack starts from a fact the wired world does not share:

anyone in range can hear it. The attacks in this section differ in what they need from the attacker and what they

yield, and the exam tests those differences.

2.1 Evil twin and rogue APs

An evil twin is an access point that broadcasts the same network name as a legitimate one, usually with a

stronger signal, so nearby clients connect to it instead. Once connected, victims may be served a captive portal

asking for credentials, or their traffic may be intercepted and modified. The attack needs no cryptography to

break: it exploits the fact that clients trust a network name, and most clients will happily join a familiar name

with a stronger signal.

In an authorized test at CertCrack.com, an evil twin is demonstrated in an isolated area with the company's own

test SSID, and the finding is usually about client behavior: devices configured to auto-join known networks will

join the twin without any user action. Detection relies on wireless intrusion prevention systems that compare

observed access points against an authorized inventory and flag unknown radios using a known name. The fix is

a combination of client configuration (do not auto-join open networks), certificate-based enterprise

authentication, which lets clients verify the network instead of trusting its name, and monitoring for rogue

radios.

2.2 WPA2 and WPA3 weaknesses

WPA2 with a pre-shared key is only as strong as the key. An attacker who captures the four-way handshake can

take it offline and run dictionary or brute-force attacks against it, which is why short or predictable pre-shared

keys fall quickly. The KRACK attack showed that the handshake itself could be manipulated to reinstall keys, but

patched clients and access points have closed that hole, and the exam treats KRACK as a historical weakness

rather than a current technique.

The PMKID attack improved on handshake capture. The attacker requests the robust security network

information element from the access point, and the first message of the exchange contains a pairwise master

key identifier derived from the pre-shared key. That single value is enough for an offline cracking attempt, and

capturing it requires no client to be present and no full handshake to complete. The mitigation is the same as for

handshake attacks: a long, random pre-shared key, or better, enterprise authentication with individual

credentials.

WPA3 replaced the pre-shared key exchange with Simultaneous Authentication of Equals, which resists offline

dictionary attacks and provides forward secrecy. It is not invulnerable. Early implementations had Dragonblood

flaws in the password handling, and many networks run WPA3 in transition mode, accepting both WPA2 and

WPA3 clients, which lets an attacker force a downgrade to the weaker WPA2 exchange. The exam's point is

consistent: the protocol improved, but deployment choices can undo the improvement.

2.3 WPS and deauthentication

Wi-Fi Protected Setup was designed to make joining a network easy, and its PIN method made attacking it easy

instead. The eight-digit PIN contains a checksum digit, so only seven digits are unknown, and the access point

confirms the first half and the second half separately. That reduces the search from one hundred million

possibilities to about eleven thousand attempts, which an automated tool completes in hours unless the access

point locks out after failed attempts. The fix is to disable WPS PIN entirely; the push-button method does not

share this flaw.

Deauthentication attacks exploit the fact that 802.11 management frames were historically unauthenticated.

The attacker sends forged deauthentication frames pretending to come from the access point, and clients

disconnect. The attacker is not breaking encryption: the goal is usually to force a client to reconnect so a

handshake can be captured, or simply to deny service. The 802.11w standard adds protected management

frames, which lets clients reject forged deauthentication frames, and that is the mitigation the exam expects.

2.4 Bluetooth and NFC

Bluetooth attacks exploit pairing and implementation flaws. Bluesnarfing steals data from a device over an

unauthenticated Bluetooth link. Bluejacking sends unsolicited messages to nearby devices, which is mostly an

annoyance but demonstrates reachability. BlueBorne was a set of remote code execution flaws in Bluetooth

stacks that needed no pairing at all. Bluetooth Low Energy added a Just Works pairing mode that provides no

man-in-the-middle protection, which is acceptable for a headset and unacceptable for a medical device or a door

lock. The mitigations are to disable Bluetooth when unused, use Secure Connections pairing with numeric

comparison where the device supports it, and keep device firmware patched.

Near-field communication works over centimeters, which feels safe, and that feeling is the vulnerability. NFC

traffic can be eavesdropped with a sensitive antenna from further away than the intended range, tags can be

cloned or reprogrammed, and relay attacks can forward a tap from a victim's card to a distant reader. Payment

systems add their own cryptography and tokenization on top of NFC, which is why a relayed payment tap is hard

to exploit in practice, but access badges and transit cards that rely on a static identifier are not. The mitigation is

to treat NFC identifiers as usernames, not passwords: the tap identifies, and something else must authenticate.

Figure 15: Wireless attacks compared — evil twin, PMKID capture, WPS brute force, deauthentication, Bluetooth, and NFC, by what the

attacker needs and what each attack yields (illustrated)

3. Application attacks

Web applications are the most common target in penetration testing because they are exposed by design: they

accept input from strangers and act on it. Almost every attack in this section follows one pattern: untrusted

input reaches a place where it is treated as code, a command, a query, or an identity, and the application does

what the input says instead of what the developer intended. The defenses follow one pattern too: treat input as

data, never as instructions, and check authorization at the object, not just at the login.

3.1 SQL injection

SQL injection happens when user input is concatenated into a database query instead of being passed as a

parameter. The database then executes the input as part of the query, and the attacker can read, modify, or

delete data the application was never meant to expose.

Union-based injection appends a second query whose results are displayed alongside the original, which is the

fastest way to extract data when the application shows query output. Error-based injection uses database error

messages to reveal structure and data. Blind injection applies when the application shows no output and no

errors: boolean-based blind injection asks the database a series of true-or-false questions, watching for a

change in the page, and each answer leaks one bit of information. Time-based blind injection asks the database

to delay its answer when a condition is true, so the attacker measures response times instead of reading output.

Out-of-band injection makes the database contact an attacker-controlled server, which is useful when the

application shows nothing at all and the database can reach the network.

Second-order injection is the variant the exam uses to test depth. The malicious input is stored safely the first

time, perhaps in a user profile or a comment, and executed later, when a different feature, such as an admin

report, builds a query from the stored value without parameterizing it. The injection point and the execution

point are in different features, which is why testers who only probe the obvious input fields miss it.

Testing an injection point, step by step:

1. Identify every place the application accepts input that reaches the database: search fields, login forms,

filters, sort parameters, and identifiers in URLs.

2. Submit a single quote and watch for a database error or a change in behavior, which suggests the input

reaches a query.

3. Determine the query structure by testing boolean conditions that should change the output, such as a

true condition and a false condition.

4. If output is visible, test union-based extraction. If no output is visible, switch to boolean-based or

time-based blind techniques.

5. Check whether the injected value is stored anywhere and executed later by another feature, which would

make the finding second-order.

6. Confirm the impact with a read-only proof, such as the database version or a row count, and stop before

modifying or deleting data outside the agreed scope.

The fix is parameterized queries, where input is sent separately from the query and can never be interpreted as

SQL. Input validation and web application firewalls are useful layers, but they are not substitutes: validation can

be bypassed, and a firewall is a filter in front of a vulnerable query, not a fix for it. Least-privilege database

accounts limit the damage when an injection succeeds, because an application account that can only read one

table cannot drop the database.

3.2 Cross-site scripting

Cross-site scripting happens when an application includes untrusted input in a page without encoding it, so the

victim's browser executes the input as script. The attacker never breaks into the server. The victim's own

browser does the work, running the attacker's code in the context of the trusted site, with access to its cookies,

session, and pages.

Reflected XSS arrives in a request, usually a link or a crafted URL, and is reflected back in the response

immediately. It needs the victim to click, which makes it a social engineering delivery as much as a technical

flaw. Stored XSS is persisted, in a comment, a profile field, or a forum post, and served to every user who views

the page, which makes it far more dangerous: one injection reaches many victims with no further action from

the attacker. DOM XSS never reaches the server at all. Client-side JavaScript takes input, from the URL fragment

or a page element, and writes it into the page unsafely, so server-side defenses never see it.

Figure 16: Reflected, stored, and DOM cross-site scripting data flows — where the payload enters, where it is stored, and where it executes

(illustrated)

The fixes are output encoding, which turns script characters into harmless text at the point where data enters a

page, and a Content Security Policy, which restricts which scripts a page may run. HttpOnly cookies keep session

cookies out of JavaScript's reach, which limits what a successful XSS can steal, but it does not fix the flaw: an

attacker who can run script in the page can still act as the victim within that page.

3.3 CSRF and clickjacking

Cross-site request forgery exploits the browser's habit of attaching credentials automatically. If a victim is

logged into a site, and visits an attacker-controlled page, that page can submit a request to the trusted site, and

the browser attaches the victim's session cookie without asking. The trusted site sees a legitimate session and

performs the action: a transfer, a password change, a settings update. The attacker never sees the response,

which is why CSRF is used for actions, not for data theft.

The fixes are anti-CSRF tokens, unpredictable values tied to the session that an attacker page cannot read, and

SameSite cookie attributes, which tell the browser not to attach cookies to cross-site requests. Checking the

Origin or Referer header helps as a layer, but headers can be suppressed, so tokens remain the primary

defense.

Clickjacking is a user interface attack. The attacker loads the trusted site inside a transparent iframe and

overlays a tempting button, so the victim's click lands on the trusted site instead of on the attacker's page. The

victim performs a real action on a real site, believing they clicked something else. The fixes are the

X-Frame-Options header and the Content Security Policy frame-ancestors directive, both of which tell the

browser not to render the site inside a frame on another origin.

3.4 Server-side request forgery

Server-side request forgery turns the server into the attacker's proxy. Many applications fetch a URL the user

supplies: a profile picture, a document preview, a webhook, an image proxy. If the application does not restrict

which URLs it will fetch, the attacker can point it at internal addresses the attacker could never reach directly:

internal services, administration panels, and the cloud metadata endpoint at 169.254.169.254, which returns

temporary credentials for the server's own cloud role.

Testing for SSRF, step by step:

1. Find every feature where the application fetches a remote resource: image URLs, file imports, feed

readers, PDF generators, and webhook targets.

2. Supply a URL pointing at a server you control and confirm the application actually makes the request, by

watching for the incoming connection.

3. Point the same feature at internal addresses, starting with the cloud metadata endpoint and common

internal service ports, and observe what the application returns or how its timing changes.

4. Test the filters: try alternate encodings, decimal or hexadecimal IP forms, URL redirects, and DNS names

that resolve to internal addresses, because filters that only block one spelling will miss the others.

5. Report the reachable internal resource and the credential or data it exposed, and stop before using those

credentials beyond the agreed scope.

The fixes are an allowlist of permitted destinations, blocking requests to private and link-local address ranges

including the metadata endpoint, and validating the resolved address rather than the submitted string, so a

DNS name that resolves internally is still blocked.

Figure 17: SSRF request flow — attacker-supplied URL, server-side fetch, internal target, and returned response (illustrated)

3.5 IDOR and broken object-level authorization

Insecure direct object reference happens when an application uses a predictable identifier, such as a user

number, an invoice number, or a document ID in a URL, and fails to check whether the requesting user is

allowed to access that object. Changing the number changes the object, and the application serves it without

complaint. The API version of the same flaw is called broken object-level authorization, and it is the most

common API vulnerability in practice: an API endpoint accepts an object ID and returns or modifies the object

without verifying ownership.

The exam tests this flaw with scenarios that look like normal use: a user views their own order at /orders/1042,

changes the number to 1043, and sees another customer's order. The fix is authorization on every object access,

checking ownership or role for the specific object on every request, not just hiding the links to other users'

objects. Unpredictable identifiers, such as random UUIDs, raise the bar for guessing but are not authorization,

and the exam punishes answers that treat them as a fix.

3.6 Session fixation

Session fixation attacks the session itself rather than the credentials. The attacker obtains a valid session

identifier, perhaps by visiting the site and receiving one, and then tricks the victim into using it, through a

crafted link or a set cookie. When the victim logs in, the session becomes authenticated, but the identifier is the

one the attacker already knows, so the attacker can now use the same session and act as the victim.

The fix is to regenerate the session identifier at authentication: when a user logs in, or escalates privilege, the

application issues a fresh identifier and invalidates the old one. Session identifiers should also be long, random,

and transmitted only over secure channels, but those properties do not fix fixation on their own, because the

flaw is that the pre-login identifier survives login.

3.7 Insecure deserialization

Serialization converts an object into a format that can be stored or transmitted, and deserialization rebuilds the

object from that format. Insecure deserialization happens when an application deserializes data from an

untrusted source, and the deserialization process itself executes code, runs constructors, or triggers dangerous

methods based on the data's contents. Java, PHP, and Python pickles all have well-known gadget chains:

sequences of existing classes that, when deserialized together, produce remote code execution without any flaw

in the application's own code.

The fix is to never deserialize untrusted data. Where serialized data must cross a trust boundary, use a data-only

format such as JSON, enforce integrity with a signature, and restrict which classes may be deserialized. The

exam's scenario usually involves a serialized cookie or token: if the application trusts its contents, the attacker

crafts a payload that the deserializer turns into execution.

3.8 Local and remote file inclusion

File inclusion happens when an application builds a file path from user input without restricting it. In local file

inclusion, the attacker uses path traversal sequences to read files on the server, such as configuration files or

password files, or to include a local file whose contents are then executed or displayed. In remote file inclusion,

the application fetches a file from a URL the attacker supplies, and the attacker's code runs on the server.

Remote inclusion requires the application to allow URL includes, which modern configurations disable by

default, so local inclusion is the more common finding.

The fixes are an allowlist of permitted files, never building paths directly from input, disabling remote URL

includes, and storing uploaded or user-controlled files outside the web root so they cannot be executed as code

even if an attacker reaches them.

3.9 XML external entities

XML external entity injection abuses XML parsers that resolve external entities. An XML document can declare an

entity that references a local file or a URL, and a parser with external entities enabled will fetch and expand it.

The attacker reads local files, probes internal services in an SSRF-like pattern, or triggers a billion laughs attack,

where nested entity expansions multiply until the parser exhausts memory.

The fix is to disable document type definitions entirely where they are not needed, or at minimum to disable

external entities and parameter entities, and to use a parser configuration that rejects entity expansion. Modern

parsers often ship with safer defaults, so XXE findings usually trace to a legacy configuration or a developer who

re-enabled entities for a feature that needed them.

3.10 Mass assignment, LDAP injection, and file upload bypass

Mass assignment happens when an application binds request fields directly to an object without filtering which

fields may be set. An attacker who inspects a normal request, such as a profile update, adds a field the form

never showed, such as an administrator flag or an account balance, and the application saves it. The fix is an

allowlist of bindable fields for each endpoint, so unexpected fields are ignored rather than applied.

LDAP injection works like SQL injection against directory services. An application that builds an LDAP filter from

input without encoding it lets the attacker inject wildcards and operators, broadening a search to dump

directory entries or bypassing an authentication check that compares a filter result. The fix is parameterized

LDAP queries and proper encoding of special characters in filters.

File upload bypass defeats extension checks. Blacklists fail because attackers use double extensions, alternate

casing, trailing dots, or legacy null bytes to slip an executable past a filter that only blocks one spelling. MIME

type checks fail because the client supplies the MIME type. The fixes are an allowlist of permitted extensions,

renaming uploaded files to random names, verifying content rather than trusting the declared type, storing

uploads outside the web root, and scanning uploads before they are served.

4. Cloud attacks

Cloud attacks differ from network attacks in one fundamental way: the attacker rarely breaks in through a

firewall. Cloud resources are addressed by name, authenticated by keys and roles, and configured through APIs,

so the attacker breaks in through a misconfiguration, a leaked credential, or an over-permissive role. The exam

tests cloud attacks as configuration failures, and the finding is almost always something a human set wrong, not

something a vendor shipped broken.

4.1 Public buckets and exposed storage

Object storage is the most common cloud finding in penetration tests, because a single checkbox makes data

public. A bucket configured for public read exposes every object inside it to anyone who knows or guesses its

name, and bucket names are often predictable: company names, project names, and environment names.

Public write is worse, because it lets strangers add or replace content, turning a storage bucket into a malware

distribution point.

In an authorized test at CertCrack.com, a tester enumerates likely bucket names, checks their access policies,

and reports any that allow public access, along with the sensitivity of what is inside. The fix is to block public

access at the account level, apply least-privilege bucket policies, audit continuously for policy changes, and treat

any public bucket as an incident until its contents are reviewed. The exam's trap is the assumption that obscurity

protects a bucket: an unlisted bucket is still reachable by anyone who guesses its name, and guessing is

automated.

4.2 IAM privilege escalation

Identity and Access Management privilege escalation happens when a low-privileged identity holds permissions

that combine into high privilege. The classic chain is a role that can pass a role to a compute service and start

that service: an attacker with permission to create a virtual machine and attach an administrative role to it

simply creates a machine that runs with administrative privileges, then uses it. Other chains include permission

to modify a function's code combined with permission to invoke it, permission to read secrets combined with

permission to list them, and permission to update a policy combined with permission to attach it to oneself.

The exam tests this as a graph problem: no single permission looks dangerous, but the combination is. The fix is

least privilege enforced by design, permission boundaries that cap what any role can grant, and regular access

reviews that look for chains, not just individual permissions. Automated analyzers that map privilege escalation

paths are part of a mature cloud program, and the exam expects the tester to think in paths, not in isolated

permissions.

4.3 Instance metadata and exposed keys

The instance metadata service is a link-local endpoint, at 169.254.169.254, that cloud instances query for

information about themselves, including temporary credentials for the role attached to the instance. An SSRF

flaw in an application running on that instance turns into a cloud compromise: the attacker makes the

application query the metadata endpoint and return the credentials, then uses them from anywhere.

The first version of the metadata service answered any request, which made this attack trivial. The second

version requires a session token obtained with a PUT request and limits the token's network hop count, which

blocks most SSRF exploitation because the attacker's request cannot easily carry the token through. The exam

expects both facts: the metadata endpoint is the target, and the second version of the service is the mitigation,

alongside blocking metadata access at the network level for workloads that do not need it.

Exposed keys are the simpler cousin of this attack. Access keys committed to public repositories, embedded in

mobile applications, or pasted into support tickets are harvested automatically by scanners within minutes of

exposure. The fix is secrets management, automated scanning of repositories, and short-lived credentials that

expire before a leaked key can be used widely.

4.4 Snapshots and subdomain takeover

Snapshots are a quiet exfiltration path. A public or overly shared disk or database snapshot can be copied into

an attacker's own account, mounted, and read at leisure, including data that was never meant to leave the

organization. The finding is usually a snapshot shared with all accounts or with a specific account that should

not have it, and the fix is to audit snapshot sharing the way you audit bucket policies, because a snapshot is a

copy of the data with the same sensitivity as the original.

Subdomain takeover happens when a DNS record points at a service that no longer exists: a CNAME to a

deprovisioned cloud resource, a removed hosting account, or an expired platform subscription. The attacker

claims the abandoned name on that platform, and the organization's own DNS now sends visitors to the

attacker's content, which can host phishing pages or steal cookies from the parent domain. The fix is DNS

hygiene: inventory every record, remove records for deprovisioned services, and monitor for dangling

references as part of change management.

4.5 Kubernetes RBAC and container escape

Kubernetes access control is role-based, and its most dangerous misconfiguration is an over-privileged service

account. A workload that runs with a token able to list secrets, or a cluster role that grants administrative access,

gives anyone who compromises that workload the keys to the cluster. The exam tests the pattern: a pod's

service account token is mounted by default, and if the workload is compromised, the token is the attacker's

next step.

Container escape breaks out of the container to the host. The classic paths are a privileged container, which

removes almost all isolation; a host path mount that exposes the host filesystem inside the container; and a

mounted container runtime socket, which lets the container ask the runtime to start new privileged containers.

The fix is to run containers unprivileged, drop unnecessary Linux capabilities, deny host path mounts and socket

mounts by policy, and treat any escape path as a critical finding because the host usually holds every workload's

secrets.

4.6 CI/CD secrets

Continuous integration and deployment pipelines are attractive targets because they hold the credentials that

build and deploy everything. Secrets leak into pipelines through environment variables printed in logs,

credentials committed to build scripts, and overly broad tokens granted to the pipeline itself. An attacker who

can modify a pipeline, through a pull request to a repository that triggers builds, or who can read its logs, can

extract those secrets and then deploy, or steal, anything the pipeline can touch.

The fix is short-lived, scoped credentials for each pipeline job, secrets stored in a vault rather than in repository

files, log masking for secret values, and approval gates for pipeline changes that touch production. The exam's

scenario usually involves a secret found in a repository or a pipeline log: the finding is the exposure, and the

remediation is rotation plus moving the secret into managed storage.

Figure 18: Cloud attack chain — from an exposed key or public bucket through IAM privilege escalation to data access, showing where

each control breaks the chain (illustrated)

5. Social engineering

Social engineering attacks people instead of systems, and the exam treats them as a distinct skill: recognizing

the psychological lever, the channel, and the control that stops it. Technical defenses matter less here than

process and training, because the attacker is not exploiting code but trust, urgency, and habit.

5.1 Phishing variants

Spear phishing targets a specific person or team with a message tailored from public information: a project

name, a colleague's name, a recent event. The tailoring is what defeats generic filters and generic suspicion,

because the message looks like it belongs. Whaling is spear phishing aimed at executives, where the payoff is a

wire transfer authorization or access to sensitive strategy, and the message is crafted to match executive

communication style.

Smishing moves the same technique to text messages, where short links and caller ID trust make verification

harder. Vishing moves it to voice calls, where a confident caller impersonating IT support or a vendor can talk a

victim through disabling a control or reading out a code. Quishing hides the malicious link inside a QR code,

which defeats the habit of hovering over links to inspect them, because the destination is invisible until scanned.

Business email compromise is the most expensive variant: the attacker impersonates a trusted party, often a

supplier or an executive, and convinces finance to change payment details or release funds. The defense for all

of these is verification through a separate channel: call the known number, not the number in the message, and

treat any payment change or credential request as untrusted until confirmed out of band.

5.2 Pretexting, baiting, and tailgating

Pretexting builds a false scenario and a false identity to extract information: a caller claiming to be from the help

desk needs a password reset, a visitor claiming to be an auditor needs a tour of the server room, an email

claiming to be from a vendor needs a configuration file. The scenario is designed to make the request feel

routine, so the victim complies without verifying.

Baiting offers something desirable that carries a payload: a USB drive left in a parking lot labeled as salary data,

a free download that installs malware, a gift card survey that harvests credentials. The curiosity or greed the bait

exploits is the point, and the defense is a policy that treats found media as hostile and a technical control that

blocks unapproved removable devices.

Tailgating is physical: following an authorized person through a secured door, often while carrying something

bulky or pretending to be on a phone call, so the door is held open out of politeness. The defense is procedural,

not technical: badge-in and badge-out for every person, turnstiles or mantraps where the risk justifies them, and

a culture where challenging an unfamiliar face is expected rather than rude.

5.3 MFA fatigue and deepfake vishing

Multifactor authentication fatigue, also called push bombing, attacks the human behind the second factor. The

attacker, who already has the victim's password, triggers repeated authentication prompts, sometimes dozens

in a night, hoping the victim eventually approves one just to stop the noise, or mistakes it for a legitimate

request. The defenses are number matching, which forces the user to enter a number shown on the login

screen instead of tapping approve, and phishing-resistant factors such as hardware security keys, which cannot

be approved by accident.

Deepfake vishing adds synthetic media to the voice channel. An attacker clones a manager's voice from a few

seconds of public audio and calls an employee with an urgent, plausible request. The defense is the same as for

every impersonation: verify through a separate channel before acting, and treat urgency itself as a warning sign,

because manufactured urgency is how the attacker suppresses verification.

6. Password attacks

Password attacks are the oldest family in this chapter and still one of the most productive, because passwords

remain the weakest credential most organizations issue. The attacks differ in how they avoid detection and in

whether they need a captured hash, and the exam tests those differences relentlessly.

6.1 Spraying, stuffing, and guessing

Password spraying tries a small number of common passwords against many accounts: one password across

the whole directory, then the next. It avoids account lockout because no single account sees many failures, and

it succeeds because in any large directory, someone is using a seasonal password or a company name.

Credential stuffing is the opposite shape: it takes username and password pairs stolen from one breach and

tries them against another service, exploiting password reuse. Brute force tries every possibility in a space,

which only works for short or weak passwords, and dictionary attacks try wordlists, which work against

human-chosen passwords.

The exam tests the distinction by describing the shape of the attack. Many accounts, few passwords, no

lockouts: spraying. Stolen pairs from another breach, tried verbatim: stuffing. The mitigations differ too.

Spraying is defeated by multifactor authentication, which makes a guessed password insufficient, and by lockout

policies tuned to distributed attempts, such as throttling by source. Stuffing is defeated by breach monitoring

that forces resets for credentials found in leaks, and by password managers that make reuse unnecessary.

6.2 Cracking: masks, rules, hybrids, and rainbow tables

Once an attacker holds password hashes, the attack moves offline, where speed is everything and no lockout

applies. A mask attack encodes known structure: if the policy requires eight characters ending in two digits, the

mask describes exactly that shape and the attack only tries candidates that fit. A rule-based attack takes a

wordlist and applies mutations: capitalization, digit appends, common substitutions, and year suffixes, which

mirrors how people actually choose passwords. A hybrid attack combines the two, appending a mask to each

dictionary word.

Rainbow tables are precomputed chains of hashes and candidate passwords, trading storage for speed: look up

a hash, walk the chain, recover the password without computing every candidate. They only work against

unsalted hashes, because a salt changes the hash of every password uniquely. Salting appends a unique

random value to each password before hashing, so two users with the same password have different hashes,

and a precomputed table is useless: the attacker must attack each hash separately. Modern password storage

goes further with slow, memory-hard hashing functions, which make each guess expensive and blunt even

GPU-accelerated cracking.

6.3 LSASS, NTDS.dit, and cracking tools

On Windows, the Local Security Authority Subsystem Service holds credentials in memory for logged-on users,

and dumping it is one of the most valuable steps in a Windows engagement. A tool like Mimikatz reads LSASS

memory and recovers plaintext passwords, hashes, and Kerberos tickets for active sessions. The NTDS.dit file is

the Active Directory database itself, holding every domain account's hash, and obtaining it, through a volume

shadow copy or a DCSync replication request, gives the attacker the whole directory to crack offline. The

mitigations are Credential Guard, which isolates LSASS secrets, Protected Users group membership for sensitive

accounts, and monitoring for the access patterns these dumps produce.

Running a password attack workflow, step by step:

1. Obtain hashes only within scope: from a lab system you own, or from data the engagement rules explicitly

authorize you to collect.

2. Identify the hash type, because the cracking tool needs to know the algorithm before it can try

candidates.

3. Start with a wordlist and rules, which crack human-chosen passwords fastest, before spending time on

brute force.

4. Apply masks only when the password policy gives you structure, such as required length and character

classes.

5. Measure progress and stop conditions: a crack that yields a few accounts is usually enough to prove the

finding, and continuing to crack the whole database adds risk without adding proof.

6. Report the weak passwords as a class, with the policy change that fixes them, rather than listing every

cracked password in full.

Hashcat is the standard GPU-accelerated cracker, and its speed is why offline attacks are so dangerous: billions

of guesses per second against fast hashes, far fewer against slow ones. John the Ripper is the CPU-oriented

counterpart with broad format support. Hydra is different in kind: it attacks live services over the network,

guessing passwords against logins, which makes it slow, noisy, and subject to lockout. The exam's distinction is

clean: Hashcat and John work offline on captured hashes, Hydra works online against live logins.

Figure 19: Password attack workflow — from hash capture through hash identification, wordlist and rule attacks, to cracked credential

and policy fix (illustrated)

7. Exploitation tools

Tools do not make findings, but the exam expects fluency with the tools that produce them, and with what each

tool's output means. This section covers the tools by role, not by manual page.

7.1 Metasploit

Metasploit organizes exploitation into modules. Exploit modules deliver a vulnerability trigger. Auxiliary modules

perform supporting tasks such as scanning and enumeration without exploitation. Post modules run after

access is gained, gathering credentials, escalating privilege, or pivoting. Payload modules are the code that runs

on the target after the exploit succeeds, and encoder modules disguise payloads from detection.

Payloads come in three shapes. Singles are self-contained and run in one step. Stagers are small initial payloads

that connect back and fetch a larger stage. Stages are the larger payloads that do the real work, and

Meterpreter is the most capable of them: an in-memory, extensible agent that supports file operations,

credential access, network pivoting, and post-exploitation modules without writing to disk. The choice between a

bind shell, which listens on the target and waits for the attacker to connect, and a reverse shell, which connects

back to the attacker, usually turns on egress filtering: a reverse shell succeeds where outbound connections are

allowed, and a bind shell fails where inbound connections are blocked.

7.2 Burp Suite

Burp Suite is the standard web application testing proxy, and the exam tests its components by role. The Proxy

intercepts traffic between the browser and the application, letting the tester read and modify requests before

they are sent. The Repeater takes a single captured request and lets the tester modify and resend it repeatedly,

observing how each change affects the response, which is the core of manual injection testing. The Intruder

automates that process across a list of values, fuzzing parameters, enumerating identifiers, and testing injection

payloads at scale. The Sequencer analyzes the randomness of session tokens, testing whether tokens are

predictable enough to forge. The Scanner, available in the paid Professional edition, automates vulnerability

detection across a site. The free Community edition includes the Proxy, Repeater, and a rate-limited Intruder,

which is enough for learning and for most manual testing.

7.3 Responder, sqlmap, Mimikatz, BloodHound, and Impacket

Responder poisons name resolution on Windows networks, answering LLMNR, NBT-NS, and mDNS queries for

names that do not exist, and capturing the NTLMv2 hashes of hosts that authenticate to it. Those hashes can be

cracked offline or, with a relay tool, forwarded to a target with SMB signing disabled. sqlmap automates SQL

injection detection and exploitation: it fingerprints the database, enumerates schemas and tables, and extracts

data, and its tamper scripts modify payloads to evade filters. It is a confirmation and exploitation tool, not a

substitute for understanding the injection, and the exam treats its output the same way it treats manual

findings.

Mimikatz extracts credentials from Windows memory and the directory: logon passwords and hashes from

LSASS, tickets from Kerberos, and, with the right access, a DCSync replication that yields every domain hash.

BloodHound maps Active Directory as a graph, showing attack paths: which users can reach domain

administrator through group memberships, delegation, and session patterns, and which accounts are

Kerberoastable or hold sessions on sensitive machines. Its collector, SharpHound, gathers the data, and the

graph answers the question the exam asks most often about Active Directory: what is the shortest path to the

target, and which link in it should be cut first.

Impacket is a Python library of network protocol tools that reimplements Windows protocols, and its scripts

appear constantly in engagements: secretsdump for credential extraction, psexec and wmiexec for remote

execution, GetNPUsers for AS-REP roasting, and GetUserSPNs for Kerberoasting. The exam does not test

Impacket's command syntax in depth, but it does test recognition: when a scenario describes a Python tool

dumping credentials remotely or requesting service tickets, the tool family is Impacket, and the defense is the

same as for the underlying protocol abuse.

8. Privilege escalation

Initial access is rarely the goal. The goal is the privilege needed to reach the objective, and privilege escalation is

the bridge between a foothold and a finding. The exam tests escalation as a checklist of misconfigurations, and

the fastest way to work through it is to ask, in order: what runs with higher privilege, what can I write to, and

what trusts me that it should not?

8.1 Windows vectors

On Windows, services are the richest target. An unquoted service path lets an attacker place an executable

where the service manager will run it with system privileges, because a path with spaces and no quotes is

resolved by trying each space-separated prefix in turn. Weak service permissions let an attacker reconfigure a

service to run their own binary. AlwaysInstallElevated, a pair of registry settings that lets any user install MSI

packages with system privileges, is a finding whenever it is enabled. Token impersonation attacks, the Potato

family, abuse the way Windows services handle authentication tokens to elevate from a service account to

system. DLL hijacking places a malicious library where an application loads it from, and stored credentials, in the

Credential Manager, in registry values, in Group Policy Preferences files with their famously reversible

cPassword encryption, and in unattended installation files, hand the attacker credentials directly. Scheduled

tasks running as system with writable scripts or binaries complete the picture.

8.2 Linux vectors

On Linux, the checklist starts with SUID binaries: programs that run with the owner's privileges, usually root, and

whose behavior the attacker can abuse, often through documented escape features catalogued in resources like

GTFOBins. Sudo misconfigurations come next: a user allowed to run any command without a password, a user

allowed to run an editor or a copy tool that can read or write arbitrary files, or a wildcard in a sudo rule that

expands further than intended. Writable cron scripts and writable system files, especially /etc/passwd and

/etc/shadow, give direct paths to root. Kernel exploits are the last resort, noisy and risky, and the exam treats

them as the answer only when no configuration flaw is present. Other vectors include Linux capabilities granted

to binaries, NFS shares exported with no_root_squash, which lets a remote root user write as root, and Docker

group membership, which is effectively root because any member can mount the host filesystem into a

container.

Figure 20: Common Windows and Linux privilege escalation paths — services, tokens, and stored credentials on Windows; SUID, sudo,

cron, and capabilities on Linux (illustrated)

9. The AI attack surface

AI systems introduce attacks that do not fit the older categories, because the vulnerability is the model's

willingness to follow instructions from data it was never meant to trust. The exam includes this surface because

penetration testers are increasingly asked to assess AI features, and the attacks are cheap to attempt.

Direct prompt injection puts malicious instructions in the user's own input: the user, or the tester acting as the

user, tells the model to ignore its instructions, reveal its system prompt, or perform an action it should refuse.

Indirect prompt injection hides the instructions in data the model processes: a web page it summarizes, a

document it reads, an email it triages, or the output of a tool it called. The model cannot distinguish instructions

from data in its context, so it follows the injected instructions as if they came from the user. The defense is to

treat model input as untrusted, to separate system instructions from user data structurally where the platform

supports it, and to validate and constrain what the model is allowed to do, rather than trusting it to refuse.

Jailbreaking is the craft of bypassing a model's safety constraints: roleplay that reframes a refused request as

fiction, encoding that disguises it, or multi-turn conversations that erode a refusal step by step. Training data

extraction exploits memorization: models trained on data containing secrets, personal information, or

credentials can sometimes be coaxed into reproducing it, which is why training data governance and output

filtering matter. Model evasion attacks the model's perception: adversarial inputs, such as subtly altered images

or text, that cause misclassification while looking normal to a human, which matters for fraud detection, content

moderation, and biometric systems.

Shadow AI is the governance side of the same problem: employees using unsanctioned AI tools, pasting source

code, customer data, or strategy documents into public models, where the data leaves organizational control

and may enter future training sets. Tool-calling abuse targets AI agents that can act: an injected instruction in

tool output tricks the agent into calling a tool it should not, with arguments that exfiltrate data or perform an

action, such as sending a message or deleting a record. The defense is the same principle that runs through this

entire chapter: least privilege for the agent's tools, confirmation for consequential actions, and validation of tool

output before it becomes the agent's next instruction.

Chapter check

1. During an authorized test at CertCrack.com, a tester requests service tickets for every account with a service

principal name and cracks one ticket offline, recovering a service account password. No account lockouts occur.

Which attack is this?

A. AS-REP roasting

B. Kerberoasting

C. A golden ticket attack

D. SMB relay

2. An attacker captures a single value from a WPA2 access point without any client being connected, then cracks

the network's pre-shared key offline. Which technique did the attacker use?

A. A KRACK attack

B. A deauthentication attack

C. A WPS PIN brute-force attack

D. A PMKID capture

3. A tester enters malicious input into a user profile field. The input is stored safely and causes no effect. Weeks

later, an administrative report builds a database query from the stored value without parameterizing it, and the

input executes. Which attack is this?

A. Second-order SQL injection

B. Stored cross-site scripting

C. Reflected cross-site scripting

D. Server-side request forgery

4. A web application fetches a URL supplied by the user to generate a preview. A tester supplies the cloud

metadata address and receives the application's temporary cloud credentials in the response. Which flaw is this?

A. XML external entity injection

B. Local file inclusion

C. Server-side request forgery

D. Insecure deserialization

5. A tester discovers a database snapshot shared publicly by CertCrack.com. The tester copies it into a personal

cloud account and mounts it. What does this finding demonstrate?

A. A broken access control in the web application

B. A Kerberos delegation flaw

C. A weak database password

D. Snapshot sharing exposing data outside the organization

6. An attacker who already holds a victim's password triggers dozens of authentication prompts overnight, and

the victim eventually approves one to stop the noise. Which attack is this?

A. MFA fatigue

B. Credential stuffing

C. Password spraying

D. Session fixation

7. A tester tries three common passwords against every account in a directory, with no account locked out.

Which attack is this?

A. A brute-force attack

B. Credential stuffing

C. Password spraying

D. A dictionary attack

8. During an authorized test at CertCrack.com, a tester on a Linux host finds a SUID binary that can be abused to

run commands as root. Which resource best documents how that binary can be abused?

A. The sudoers file

B. GTFOBins

C. The BloodHound graph

D. The NTDS.dit database

Answer key: 1. B - 2. D - 3. A - 4. C - 5. D - 6. A - 7. C - 8. B

Attack Toolkit: The Named Tools of Domain 4

Domain 4 is where the objectives become a tool catalogue: nearly every objective in this domain names the tools it tests. This toolkit section walks them in the objectives' own groupings — host and Active Directory, cloud, wireless, social engineering, specialized systems, scripting and simulation, and the web. The definitions are short on purpose; the comparison tables carry the distinctions the exam actually grades.

Host and Active Directory tools

Cloud and container attack tools

Wireless tools

Social-engineering tools

Specialized-systems tools

Scripting and simulation tools

Web and authentication tools