Security · Topic 15 of 23 · Part III — Pentesting in depth

Exploitation in practice

Reconnaissance candidates become demonstrated vulnerabilities — the defining transition of a pentest.

Aligned to PTES §5 (Exploitation), as exercised inside a pentest engagement.

Topic 15 · Exploitation

Demonstrated impact, not "I ran an exploit"

By the end of this topic you can:

Define exploitation and place it correctly within a pentest engagement.
Plan an exploitation attempt: assess feasibility, choose an approach, manage risk.
Use exploitation frameworks responsibly and understand what they do under the surface.
Distinguish CVE exploitation, misconfiguration, weak credentials, and design flaws.
Conduct online brute-force, credential spraying, and offline hash cracking.
Capture evidence sufficient to demonstrate impact without causing unnecessary harm.

What exploitation actually is

Leveraging an identified weakness to produce an effect the system was not intended to permit.

Possible effects

Read access the user was not authorized to
Write / modify access without authorization
Execution of code chosen by the tester
Authentication as a different principal
Privilege elevation within an existing context
Bypass of a protective control

The epistemic shift "Pattern present" (scanner flag) becomes "demonstrated impact" (exploitation). That shift is the deliverable of this phase.

Failure modes Crash, trigger with no observable effect, or real weakness that cannot be reproduced in this environment — all count as failures.

Vulnerability classes by exploit pattern

Class	Mechanism	Typical tooling
Known CVE	Public proof-of-concept; verify version, run exploit, demonstrate effect	Metasploit, ExploitDB, custom
Misconfiguration	Product fine; deployment wrong — default creds, open admin, debug mode, exposed secrets	Manual, Burp, scanners
Weak credentials	Credentials work; availability to tester is the weakness	Hydra, Medusa, Impacket
Authorization flaw	Auth OK; permission check missing — IDOR, broken access control, missing function checks	Burp, manual
Business-logic flaw	App works as intended; intent was flawed — race conditions, multi-step bypass, workflow assumptions	Manual, Burp
Supply-chain	Vulnerable dependency (Log4Shell-style); requires careful scoping of which code path is reachable	Dependency scanners, manual
Crypto misuse	ECB mode, predictable IV, padding oracle, weak RNG in tokens or session IDs	Manual, specialized scripts

Real engagements produce a mix. Reports listing only CVEs are usually shallow.

Planning an exploitation attempt

1Confirm the candidate — is the version actually vulnerable? Does the misconfiguration behave as expected?

2Confirm scope — does the engagement permit this class of action, especially RCE or availability impact?

3Choose the approach — lowest risk to target, clearest evidence, smallest data exposure footprint

4Read the exploit — public exploits sometimes contain hidden payloads or do far more than claimed

5Prepare a safety net — know how to detect damage; know who to call if it happens

6Plan evidence capture — screenshot or output before anything destructive

Executing safely

Least-impactful payload that demonstrates the finding — whoami is usually enough for RCE.
Avoid destructive actions — don't change data, don't delete, don't persist without explicit authorization.
Don't escalate further than needed without rechecking scope and authorization.
Don't exfiltrate data unnecessarily — schema plus one record proves SQL injection; the full table does not.
Watch for collateral effects — service crashes, account lockouts, log floods.
Communicate active operations — heads-up for noisy actions prevents false incident response.

Discipline The line between "demonstrated finding" and "production incident" is thin. Professional behaviour is what distinguishes a tester from someone who happens to know how to run Metasploit.

Exploitation frameworks

Tool	Primary use	Notes
Metasploit	Known-CVE verification; exploits, payloads (Meterpreter), post-exploitation	Signatures well-known to defenders; read module source before use on production
Impacket	Windows/AD protocol-level attacks — PTH, Kerberoasting, NTLM relay, DCSync, secretsdump	Essential for AD-focused work
Burp Suite	Web-application exploitation — repeater, intruder, Collaborator for OOB	Detail in Topic 17
sqlmap	Automated SQLi exploitation	Aggressive by default — high request volume; use carefully
Hydra / Medusa	Network-service brute-force	Can lock accounts; often out of scope
MSFvenom	Payload generation (Metasploit)	Reverse Shell Generator is a quick web-based alternative

Cobalt Strike / Sliver / Mythic / Havoc — C2 frameworks for red-team scope (Topic 12); mentioned for context only.

Credential exploitation

Default credentials

Systematic check: SSH, RDP, web admin panels, databases, IoT, network equipment
Sources: CIRT defaultpasswords, SecLists default-credentials
Often the fastest path on internal infrastructure

Online brute-force

Often out of scope: account lockout, rate limiting, audit logs, time cost
When in scope: prefer no-lockout services, weak policies, small targeted wordlists
Tools: Hydra, ffuf (HTTP forms), Medusa
Discipline: limit target set, monitor for lockouts, stop on detection

Credential spraying

One password (or tiny set) against many usernames — bypasses per-user lockout
Effective against M365 / Entra ID, AD logon, SSH without key-only enforcement
Real attackers use spraying as first contact; it is relatively stealthy
Think like the attacker first: OrgName+year, Season+year, "Password123"

Password reuse from breach dumps

Enumerate usernames → cross-reference breach dumps → test pairs
Higher signal-to-noise than arbitrary brute-force
Delete mapping immediately after testing — FADP/GDPR data-handling obligation

Hash cracking — fundamentals

How it works

Cryptographic hashes are non-invertible. The attacker guesses passwords, hashes each candidate, and compares to the target hash. No account lockout. No rate limiting. No logging to the target.

Identifying hash types

Visual pattern	Likely type
32 hex chars	MD5 / MD4
40 hex chars	SHA-1
64 hex chars	SHA-256
$1$ / $6$	Unix crypt (MD5 / SHA-512)
$2a$ / $2b$	bcrypt (work factor embedded)
`$argon2`	Argon2
32 hex, colon-separated	Windows LM:NTLM

Tools: hashid, hash-identifier. Misidentifying the type produces zero results.

Hash strength spectrum

Weak MD5 unsalted, MySQL OLD_PASSWORD — minutes to hours with GPU
Moderate bcrypt (low rounds), salted SHA-256 — hours to days
Strong Argon2, PBKDF2 high-iteration — weeks or infeasible

Independent finding A weak hash algorithm (MD5, unsalted SHA-1) is a reportable vulnerability in itself — regardless of whether any password actually cracks.

Hash cracking — strategies & tools

Dictionary attack — rockyou.txt, SecLists password lists. Fast; only covers passwords in the list. ~10–20% of real passwords.
Rule-based attack — dictionary + transformations (capitalize, append digits, @→a, reverse, special-char append). Raises coverage to ~50–80%.
Mask attack — brute-force with known constraints. ?u?l?l?l?l?l?s?d matches 8-char policy (upper + 5 lower + special + digit). Feasible on GPU for typical enterprise policies.
Hybrid attack — dictionary base with mask appended/prepended. Effective for org passwords: CompanyName + ?d?d?s.
Brute-force — last resort; practical only for small keyspaces (<8 chars, 4-digit PINs).

Workflow: identify type → dictionary → rules → mask / hybrid → brute-force.

Tools

hashcat — GPU-accelerated, hundreds of hash types, standard for professional work
John the Ripper — CPU-portable, smaller learning curve

100 B+/s

MD5 guesses/sec on RTX 4090

Wordlist quality > raw GPU speed. Domain-specific wordlists and rules typically outperform brute-force.

Pass-the-Hash and Pass-the-Ticket

Pass-the-Hash (PtH)

NTLM authentication accepts the hash directly as proof of identity — no plaintext needed. Once a hash is obtained (LSASS dump, registry, NTDS.dit), authenticate as that user against SMB, WMI, and other NTLM-accepting protocols.

Mitigated by SMB signing and NLA on RDP — but still viable against many protocols.

Pass-the-Ticket (PtT)

Steal a Kerberos TGT from memory and replay it to request service tickets for other resources without re-authenticating.

Overpass-the-Hash

Use the NTLM hash to request a Kerberos TGT, then use the ticket for further auth. Windows-specific.

Strategic implication PtH makes cracking unnecessary for Windows/AD lateral movement. Obtain the hash; move laterally. Plaintext recovery is optional.

Tooling Impacket suite: psexec.py, wmiexec.py, smbexec.py, secretsdump.py implement all major variants.

Strategy: try PtH first on AD NTLM hashes. If blocked by NLA or SMB signing, then crack for plaintext.

Initial access patterns & evidence

Common foothold patterns

Known vulnerability in an exposed service
Default or weak credentials on an exposed service
Misconfigured public-facing application (admin interface, debug mode)
Insecure deserialization in an exposed endpoint
File upload bypass leading to web shell
SQL injection — authentication bypass or data extraction
Phishing-derived credentials (when SE is in scope)

A reportable finding includes

Pre-state

System configuration, observable as follows

Action

Exact request / payload / command sent

Effect

Response / output / artefact observed

Interpretation

What the effect means in terms of impact

Time-stamped, reproducible, with the exact command — not paraphrased.

"I got a shell" is half a finding. Impact is the finding.

When exploitation should not happen

The exploit risks production stability — memory-corruption exploits have a non-trivial crash rate on fragile targets. Document and stop.
The exploit would expose third-party data the client has not authorized access to.
Authorization is unclear for the depth the exploit would reach.
The finding can be reported without exploitation — observed unauthenticated administrative access is sufficient evidence in most cases.
You do not understand the consequences — do not run something whose effects are unknown on a production target.

Professional legitimacy A report stating "vulnerability X is present; exploitation was not attempted because of Y; remediation is Z" is credible, as long as the reasoning is clear.

Check — production service, risky exploit

Scenario

A Metasploit module against a production service has, in your experience, a ~10% chance of crashing the service. What considerations weigh for or against using it?

Reveal answer

Against: production-stability risk, possible customer impact, possible scope dispute. For: demonstrates real impact if the engagement requires it; the same vulnerability would crash under a real attack. Middle path: request a maintenance-window run; demonstrate on a staging copy; document with a less-risky proof (read access only, not RCE). Default rule: when in doubt, propose the safer option to the client and let them choose explicitly — document that decision in the engagement record.

What you take home

Exploitation = leveraging a weakness to produce a demonstrated unauthorized effect.
CVE-based exploitation is one class among many; misconfiguration and authorization flaws often dominate real reports.
Plan before pulling the trigger: confirm candidate, confirm scope, read the exploit source.
Use the least-impactful payload that proves the finding — production safety is not optional.
Credential attacks (spraying, reuse, hash cracking) often outperform traditional exploits.
On AD engagements, try Pass-the-Hash before spending time cracking.
A defensible decision not to exploit is a professional outcome, not a failure.

Next: Topic 16 — Privilege escalation. Initial foothold achieved; now raise the stakes.

END · TOPIC 15

Demonstrated impact.

Before next session: read the source of a Metasploit module — understand what it actually does.