Password Cracking · Buffer Overflows · Social Engineering · SQLi · XSS · CSRF · Metasploit
Study with Practice Tests →Topic 3 covers the attacker's playbook once reconnaissance is complete: cracking credentials, overflowing buffers, manipulating humans, and exploiting web apps. Understanding these techniques is essential for both detection and response.
| Topic | Key Concepts |
|---|---|
| 1. Incident Handling Process | PICERL, chain of custody, IR team roles, MITRE ATT&CK, IOCs, threat intelligence |
| 2. Reconnaissance & Scanning | OSINT, Nmap, vulnerability scanning, passive vs active recon |
| 3. Exploitation & Web Attacks ← You are here | Password attacks, buffer overflows, social engineering, SQLi, XSS, CSRF, Metasploit |
| 4. Network Attacks & IDS | ARP poisoning, DoS/DDoS, packet analysis, IDS/IPS evasion, NetFlow |
| 5. Malware & Lateral Movement | Malware types, C2, persistence, Pass-the-Hash, YARA, memory forensics |
Six distinct attack methods: brute force (every combo), dictionary (wordlist), rainbow table (pre-computed hashes — beaten by salting), credential stuffing (reused breach data), spraying (one password, many accounts), and offline (cracking stolen hashes). Know which defense counters each.
Stack-based overflows overwrite the EIP/RIP (instruction pointer) to redirect execution. Process: fuzz → find offset → control EIP → point to shellcode. Defenses: ASLR (randomize addresses), DEP/NX (non-executable stack), Stack Canaries (detect overwrite). Safe functions (strncpy, snprintf) prevent the vulnerability.
Exploits human psychology rather than technical flaws. Key types: phishing (bulk email), spear phishing (targeted), whaling (executives), vishing (voice), BEC (fake CEO wire transfer), baiting (USB drop), pretexting (fabricated scenario), tailgating (physical access). Training + technical controls together.
User input is interpreted as SQL commands. Types: Classic (auth bypass), UNION (data extraction), Blind Boolean/Time-based (no output), Error-based (leak DB info). Primary defense: parameterized queries / prepared statements — not just input validation or a WAF.
Inject malicious JavaScript into pages. Stored (in DB, serves all visitors — most dangerous), Reflected (URL parameter, one victim at a time), DOM-based (no server, JavaScript reads attacker input). Impacts: session hijacking via cookie theft. Defense: output encoding + CSP + HTTPOnly cookies.
CSRF: forged request from victim's browser using their session cookies — defense: CSRF tokens + SameSite cookies. Also know: Command Injection, Path Traversal (../../etc/passwd), IDOR (change user_id), XXE (XML entities), SSRF (169.254.169.254 cloud metadata). All are injection/access-control failures.
The GCIH exam distinguishes best defenses from compensating controls. For SQLi: parameterized queries = primary (WAF = compensating). For XSS: output encoding = primary (CSP = defense-in-depth). For rainbow tables: salting = primary. Always pick the most direct technical fix.
These are frequently tested together. Remember: XSS exploits the user's trust in the site (injected script runs in their browser). CSRF exploits the site's trust in the user's authenticated browser (forged request sent with valid cookies). Different mechanisms, different defenses.
Password spraying tests one common password (e.g., "Summer2024!") across many accounts before moving to the next. This deliberately stays below account lockout thresholds. Detect by looking for the same source IP hitting many different accounts — not repeated failures on one account.
From online brute-forcing to offline hash cracking — know the attack spectrum, the tools, and which defense counters each method.
Try every possible character combination — slow but thorough, guaranteed to find password eventually. Defense: account lockout, rate limiting, long/complex passwords to make it computationally infeasible.
Use a curated wordlist (rockyou.txt has 14M passwords; SecLists collection). Faster than pure brute force — exploits the fact that people pick predictable passwords. Defense: enforce complexity and block known-bad passwords.
Use pre-computed hash → plaintext lookup tables. Trades storage for speed — instant results once table is built. Defeated entirely by salting (unique random value per password makes pre-computation impossible).
Take username/password pairs from breached databases and try them against other services — exploits password reuse. Effective because most users reuse passwords across sites. Defense: MFA defeats this; password managers encourage unique passwords.
Try one common password against many accounts before trying the next — deliberately stays below lockout thresholds. Detection: look for login failure spikes across many different accounts from the same source, not repeated failures on one account.
Crack hashes stolen from /etc/shadow (Linux) or NTDS.dit (Active Directory) — no lockout risk since you're not hitting a live service. GPU acceleration makes this extremely fast against weak hash algorithms.
Use a captured NTLM hash directly to authenticate without cracking it — the hash IS the credential in NTLM. No need to know the plaintext password. Covered in depth in Topic 5 (Lateral Movement).
-a 0 — dictionary mode-a 3 — brute force / mask mode-a 6 — hybrid (wordlist + mask)-m flagjohn --wordlist=rockyou.txt hashes.txt--format= flag to specify hash typehydra -l admin -P wordlist.txt ssh://target-m Values| Hash Algorithm | Hashcat -m | Use Case | Security Status |
|---|---|---|---|
| MD5 | 0 | Legacy; many systems still store these | Broken — fast to crack |
| SHA-1 | 100 | Git objects, older systems | Broken — fast to crack |
| NTLM | 1000 | Windows authentication hashes | Weak — no salt |
| bcrypt | 3200 | Password storage (correct choice) | Strong — slow, salted |
| WPA2 (PMKID) | 22000 | Wi-Fi handshake cracking | Depends on password strength |
Two very different attack vectors that share a common theme: exploiting design flaws. Buffer overflows abuse memory handling; social engineering abuses human psychology. Both appear on the GCIH exam.
When a program writes more data to a buffer than it can hold, the excess overwrites adjacent memory — including the saved return address (EIP/RIP) on the stack. By controlling that address, the attacker redirects execution to shellcode.
Send increasingly large inputs until the application crashes. The crash reveals that a buffer overflow exists. Tools: custom scripts, Boofuzz, Peach fuzzer.
Send a unique cyclic pattern (Metasploit's pattern_create) so you can calculate exactly how many bytes it takes to reach EIP. Use pattern_offset with the EIP value from the crash.
Send offset bytes of padding + 4 bytes that overwrite EIP with a controlled value. Confirm you can write an arbitrary address into EIP (e.g., 42424242 = "BBBB").
Insert a NOP sled (\x90\x90\x90...) before shellcode to increase landing probability. Point EIP to an address inside the sled. Shellcode slides down to execute. Generate with msfvenom.
| Protection | What It Does | Bypassed By |
|---|---|---|
| ASLR (Address Space Layout Randomization) | Randomizes base addresses of stack, heap, libraries on each run — prevents hardcoded addresses | Info leaks, brute force (32-bit), heap spraying |
| DEP / NX (Data Execution Prevention / No-Execute) | Marks stack and heap memory non-executable — shellcode placed there cannot run | Return-Oriented Programming (ROP) |
| Stack Canary | Places random value before return address; checks it before function returns — detects overwrite | Info leaks that reveal canary value, format string bugs |
| Safe Functions | strncpy (vs strcpy), snprintf (vs sprintf), fgets (vs gets) — bounds-checked variants | N/A — prevents the vulnerability at the source |
| RELRO / PIE | Makes GOT/PLT read-only; Position Independent Executables add ASLR to binary itself | Requires full ASLR bypass |
Overflows the heap (dynamic memory) rather than the stack. Corrupts heap metadata or function pointers. Harder to exploit than stack overflows but can lead to arbitrary code execution. Use-after-free is a related heap vulnerability where memory is accessed after being freed.
Core workflow: msfconsole → search [module] → use [path] → show options → set RHOSTS/LHOST/LPORT → exploit. Payloads: singles (self-contained), stagers (small loader), stages (meterpreter downloaded by stager). Auxiliary modules: no payload — used for scanning/enumeration.
Advanced in-memory payload. Communicates over encrypted channel. Key commands: hashdump (dump SAM hashes), migrate (move to another process), getsystem (privilege escalation), download/upload (file transfer), shell (drop to OS shell), sysinfo (target info).
| Technique | Method | Key Characteristic |
|---|---|---|
| Phishing | Bulk email with malicious links/attachments | Low targeting, high volume |
| Spear Phishing | Targeted email using personalized info (name, role, recent activity) | Higher success rate than generic phishing |
| Whaling | Spear phishing targeting executives (CEO, CFO, Board) | High-value targets; often precedes BEC |
| Vishing | Voice phishing — impersonating IT support, bank, IRS | Real-time psychological pressure |
| Smishing | SMS phishing with malicious links | Mobile users less suspicious of SMS |
| Pretexting | Fabricated scenario to establish trust (fake helpdesk, vendor, regulator) | Attacker creates a believable backstory first |
| BEC (Business Email Compromise) | Impersonate executive to authorize wire transfer or change payment details | Often follows whaling; financial impact |
| Baiting | USB drop attack — malware-laden USB left in parking lot or lobby | Exploits curiosity |
| Tailgating / Piggybacking | Physical access by following authorized person through a secured door | Physical security bypass; no technical skill needed |
SQL injection, XSS, CSRF, and related vulnerabilities are heavily tested in GCIH. Know the mechanism, the impact, and — critically — the correct primary defense for each.
User-supplied input is interpreted as SQL code because it is concatenated directly into a query string. The attacker breaks out of the data context and writes their own query logic.
| SQLi Type | Technique | How to Detect |
|---|---|---|
| Classic / Auth Bypass | ' OR '1'='1 in login field — makes WHERE clause always true | Successful login without valid credentials |
| UNION-based | ' UNION SELECT username,password FROM users-- — appends extra SELECT to return attacker-chosen data | Extra data returned in application response |
| Blind Boolean | AND 1=1 (normal response) vs AND 1=2 (different response) — infers data bit-by-bit | Behavioral differences with true/false conditions |
| Blind Time-based | '; WAITFOR DELAY '0:0:5'-- (MSSQL) or '; SELECT SLEEP(5)-- (MySQL) — measures response delay | Abnormal response times on certain inputs |
| Error-based | Force SQL errors that include database version, table names in error messages | Verbose error messages containing DB info in response |
| XSS Type | Mechanism | Persistence | Danger Level |
|---|---|---|---|
| Stored (Persistent) | Malicious script saved in database; served to every visitor of the affected page | Permanent until removed | Highest |
| Reflected (Non-persistent) | Script in URL parameter reflected back in response; victim must click attacker-crafted link | One-time per request | Medium |
| DOM-based | JavaScript reads attacker-controlled input (URL fragment, postMessage) and writes to DOM — no server involvement | One-time; client-side only | Medium-High |
document.cookie, send to attackerThe victim's browser is tricked into sending a forged request to a trusted site using the victim's existing authenticated session cookies. The server cannot distinguish the forged request from a legitimate one — both arrive with valid cookies.
Attacker hosts an image tag on a malicious site:
<img src="https://bank.com/transfer?to=attacker&amount=10000">
When the victim (who is logged into bank.com) visits the malicious page, their browser automatically sends the GET request with their bank cookies. The bank processes it as if the victim initiated it.
User input executed as an OS command. Attacker appends commands with ;, |, &&:
; ls -la or | cat /etc/passwd
Defense: Never pass user input to shell; use parameterized APIs; input whitelist
Escape web root using ../ sequences to read arbitrary files:
../../etc/passwd or ..%2F..%2Fetc%2Fshadow
Defense: Resolve canonical path, verify it starts with allowed base directory
Change a reference to access another user's resource:
/profile?user_id=123 → change to user_id=124
Defense: Server-side authorization check — verify caller owns requested resource
Malicious XML references an external entity to read local files or trigger SSRF:
<!ENTITY xxe SYSTEM "file:///etc/passwd">
Defense: Disable external entity processing in XML parser configuration
Make the server fetch internal resources the attacker cannot reach directly. Classic target:
http://169.254.169.254/latest/meta-data/
(AWS IMDSv1 instance metadata — leaks IAM credentials)
Defense: Allowlist outbound URLs; use IMDSv2 (requires session token); network segmentation
| OWASP Top 10 Category | Attacks Covered |
|---|---|
| A01 — Broken Access Control | IDOR, path traversal, CSRF |
| A03 — Injection | SQL injection, command injection, XXE |
| A07 — Identification & Auth Failures | Credential stuffing, brute force, session hijacking |
| A10 — Server-Side Request Forgery | SSRF (cloud metadata, internal services) |
| Cross-Cutting | XSS spans A03 (injection) and A07 (session) |
10 exam-style questions covering password attacks, buffer overflows, social engineering, and web vulnerabilities. Select your answer, then click Check to reveal the result.
Six high-retention mnemonics to lock in the most tested concepts from Topic 3. Use these for last-minute review before the exam.
Click any card to flip and reveal the answer. Use the Advisor below for guided topic deep-dives.
Click a card to flip it · Click again to flip back
Select a topic to see key exam points, common traps, and what to focus on.
Choose a category from the left to see focused exam guidance for that area.