Ethical Hacking,
from foundations to advanced.

1.1 What ethical hacking actually is

Ethical hacking is the authorized practice of probing systems, networks, and applications the same way an attacker would, in order to discover weaknesses before a malicious actor does. The word that carries all the weight is authorized. An ethical hacker (also called a penetration tester or offensive security engineer) does exactly what a criminal does technically, but does it with written permission, inside an agreed scope, and produces a report that helps the owner fix the problems.

The value proposition is simple: it is far cheaper to pay a professional to find your weaknesses than to have a breach find them for you. Organizations hire ethical hackers to validate their defenses, satisfy regulators, protect customer data, and build confidence before shipping products.

1.2 The CIA triad — the goal of all security

Every control you will ever meet exists to protect one or more of three properties. This is the single most important model in the field.

Property	Meaning	Example attack against it
Confidentiality	Information is only seen by those authorized to see it	Data theft, eavesdropping, weak encryption
Integrity	Information is accurate and has not been tampered with	Altering a bank transaction, defacing a page, malware injection
Availability	Information and services are accessible when needed	Denial-of-service, ransomware, hardware sabotage

Two further goals are often added to extend the triad:

• Authenticity — you can trust that a message or user genuinely is who it claims to be (defeated by spoofing and impersonation).
• Non-repudiation — a party cannot credibly deny having performed an action (provided by digital signatures and reliable logging).

1.3 The vocabulary you must never mix up

Asset

Anything of value worth protecting — data, servers, a domain name, reputation, people.

Threat

A potential cause of harm: a hacker group, malware, a disgruntled employee, a flood.

Threat actor

The entity behind a threat (a person, group, or nation-state).

Vulnerability

A weakness that a threat can use — an unpatched service, a weak password, an untrained user.

Exploit

The specific technique or piece of code that takes advantage of a vulnerability.

Payload

The part of an attack that performs the intended action after the exploit succeeds (e.g. a remote shell).

Risk

The likelihood that a threat exploits a vulnerability, combined with the impact. Informally: Risk ≈ Threat × Vulnerability × Impact.

Zero-day

A vulnerability unknown to the vendor, for which no patch yet exists.

Attack surface

The total set of points where an attacker could try to enter or extract data.

1.4 Types of hackers and threat actors

• White hat — authorized, ethical professionals. This is you.
• Black hat — malicious attackers acting illegally for personal gain, disruption, or ideology.
• Grey hat — operate in between; may test systems without permission but without clear malice, often disclosing what they find. Still legally exposed.
• Script kiddie — unskilled actors who run others' tools without understanding them.
• Hacktivist — motivated by a political or social cause (e.g. defacements, leaks).
• State-sponsored / APT — well-funded, patient nation-state groups ("Advanced Persistent Threats") pursuing espionage or sabotage.
• Insider threat — an employee or contractor who misuses legitimate access, whether maliciously or by negligence.
• Cyber-terrorist / organized crime — motivated by fear or, most commonly today, by money (ransomware syndicates).

1.5 Classifying attacks

Attacks are grouped along a few axes:

• Passive vs. active. Passive attacks observe without altering (sniffing traffic, reconnaissance). Active attacks change or disrupt (modifying data, denial-of-service, brute forcing).
• Inside vs. outside. An outsider has no legitimate access; an insider already does.
• By target layer. Operating-system attacks, application-level attacks, misconfiguration attacks, and "shrink-wrap" attacks that abuse default settings in off-the-shelf software.

1.6 The five phases of a hack

Almost every intrusion — and every structured penetration test — follows the same lifecycle. Memorize this order; it structures the rest of the course.

#	Phase	Attacker goal
1	Reconnaissance	Gather information about the target (passive and active footprinting)
2	Scanning & Enumeration	Identify live hosts, open ports, services, and extract detailed lists (users, shares)
3	Gaining Access	Exploit a weakness to get a foothold
4	Maintaining Access	Establish persistence so the foothold survives (backdoors, scheduled tasks)
5	Clearing Tracks	Remove evidence to avoid detection (log tampering) — a defender studies this to build better detection

1.7 Cyber Kill Chain and MITRE ATT&CK

Two industry frameworks describe attacker behaviour in more detail:

• The Lockheed Martin Cyber Kill Chain breaks an intrusion into seven stages: reconnaissance → weaponization → delivery → exploitation → installation → command & control (C2) → actions on objectives. Its power for defenders is that breaking any single link stops the chain.
• MITRE ATT&CK is a continuously updated knowledge base of real-world adversary tactics (the "why", e.g. Privilege Escalation) and techniques (the "how", each with an ID like T1078). Blue teams use it to map their detection coverage; red teams use it to plan realistic emulation.

1.8 Defense-in-depth and security controls

Defense-in-depth means layering independent controls so that no single failure exposes everything — like a castle with a moat, walls, guards, and a locked keep. Controls are categorized two ways:

By function	By type
Preventive — stop an incident (firewall, MFA)	Administrative — policies, training, procedures
Detective — spot an incident (IDS, logs, SIEM)	Technical/logical — software and hardware controls
Corrective — limit damage and recover (backups, IR plan)	Physical — locks, cameras, guards, fences

Also worth knowing: deterrent controls (warning banners) and compensating controls (an alternative when the ideal control is impractical).

1.9 Where the ethical hacker fits

Security teams are often described by colour. Red teams attack. Blue teams defend, monitor, and respond. Purple teaming is the collaborative practice where red and blue share findings in real time so defenses improve faster. A well-rounded professional understands all three — you cannot defend an attack you do not understand, and you cannot responsibly attack without understanding the damage you could cause.

2.1 Why this module comes second, not last

Most beginners want to skip to the tools. Do not. The difference between a respected professional and a defendant is almost never technical skill — it is authorization and documentation. A single unauthorized scan of a system you do not own can be a criminal offence. Treat the legal framework as a load-bearing part of your craft.

2.2 The major computer-crime laws

Laws vary by country, but the pattern is consistent: accessing a computer system without authorization, or exceeding the access you were given, is illegal — usually regardless of whether you cause harm.

Jurisdiction	Key law	Core prohibition
United States	Computer Fraud and Abuse Act (CFAA)	Unauthorized access or exceeding authorized access to protected computers
United States	DMCA §1201	Circumventing technological protection measures (with security-research carve-outs)
United Kingdom	Computer Misuse Act 1990	Unauthorized access, unauthorized acts impairing operation, making/supplying hacking tools
European Union	GDPR + Directive 2013/40/EU	Data protection; criminalizing attacks against information systems
Bangladesh	Cyber Security Act (2023, replacing the Digital Security Act)	Illegal access, data interference, identity fraud, and related offences
India	Information Technology Act 2000 (§43, §66)	Unauthorized access, damage, and computer-related offences

Two universal principles emerge: (1) authorization is everything, and (2) possession or use of "hacking tools" can itself be restricted in some jurisdictions when intent to misuse is present. Know your local law and the law where the target resides.

2.3 Authorization, scope, and rules of engagement

A professional engagement is governed by paperwork before a single packet is sent. The essential documents:

• Authorization letter / "get out of jail" letter — a signed statement from the asset owner explicitly permitting the test, naming the tester, the targets, and the time window. Carry it during the engagement.
• Scope statement — precisely what is in and out of bounds: IP ranges, domains, applications, physical sites, and explicitly excluded systems (e.g. production databases, third-party services).
• Rules of Engagement (RoE) — how the test will be conducted: permitted techniques, prohibited actions (e.g. no denial-of-service, no social engineering of named individuals), testing hours, data-handling rules, and emergency contacts.
• Non-disclosure agreement (NDA) — protects the client's confidential information discovered during testing.
• Liability and indemnity clauses — allocate responsibility if something breaks.

2.4 Types of testing arrangement

Model	Tester knowledge	Simulates
Black box	No prior information	An external attacker with no inside knowledge
Grey box	Partial information / limited credentials	A user or partner with some access
White box	Full information, source code, architecture	A thorough internal review; most efficient coverage

You should also distinguish announced tests (the blue team knows) from unannounced ones (only leadership knows — useful for testing detection and response).

2.5 Vulnerability disclosure

When you find a serious flaw — especially in third-party software — how you tell the world matters ethically and legally.

• Responsible / coordinated disclosure — privately notify the vendor, give them reasonable time to fix (commonly 90 days), then disclose publicly. This is the professional norm.
• Full disclosure — publish immediately and completely. Pressures vendors but can arm attackers before a fix exists.
• Bug bounty programs — vendors invite testing under published rules and pay for valid findings (platforms like HackerOne and Bugcrowd). Staying inside the program's scope is what keeps it legal.

2.6 Compliance and standards that drive testing

Much security testing is required by law or contract. Know what each regime protects:

Framework	Applies to	Protects / requires
PCI DSS	Anyone handling payment cards	Cardholder data; mandates regular scans and pentests
GDPR	Personal data of EU residents	Privacy rights; breach notification within 72 hours
HIPAA	US healthcare data	Protected health information (PHI)
ISO/IEC 27001	Any organization	An information security management system (ISMS)
SOC 2	Service providers	Trust criteria: security, availability, confidentiality, etc.
NIST CSF / 800-53	US federal & widely adopted	A risk-based control framework

2.7 A professional code of ethics

Beyond the law, professionals hold themselves to a code. The recurring commitments:

1. Act only within authorization and scope.
2. Protect the confidentiality of everything you learn.
3. Do no unnecessary harm; avoid disrupting operations.
4. Report findings honestly and completely — never hide a failure or inflate a finding.
5. Do not misuse access for personal gain.
6. Disclose conflicts of interest.
7. Keep your skills and knowledge current.

3.1 The two models you must hold in your head

Networking is taught through layered models. Each layer talks only to the layers directly above and below it, which is exactly why attacks and defenses can be reasoned about layer by layer.

OSI layer	Name	Example protocols / units	Typical attacks here
7	Application	HTTP, DNS, SMTP, FTP	Injection, app logic abuse, phishing content
6	Presentation	TLS/SSL, encoding	Weak ciphers, certificate issues
5	Session	Sessions, RPC	Session hijacking
4	Transport	TCP, UDP (ports)	Port scanning, SYN floods
3	Network	IP, ICMP, routing	IP spoofing, routing attacks
2	Data link	Ethernet, ARP, MAC	ARP spoofing, MAC flooding
1	Physical	Cables, radio	Wiretapping, jamming

The TCP/IP model collapses these into four layers — Application, Transport, Internet, and Network Access — and is closer to how the internet actually works. A common mnemonic for OSI top-to-bottom is "All People Seem To Need Data Processing."

3.2 Addresses, ports, and the handshake

IP addresses identify hosts. IPv4 uses 32 bits (e.g. 192.168.1.10); IPv6 uses 128 bits to solve address exhaustion. Private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are not routable on the public internet and sit behind NAT.

Ports identify services on a host (0–65535). Well-known ports below 1024 include:

Port	Service	Port	Service
20/21	FTP	143	IMAP
22	SSH	443	HTTPS
23	Telnet (insecure)	445	SMB
25	SMTP	3306	MySQL
53	DNS	3389	RDP
80	HTTP	8080	HTTP-alt/proxy

TCP is connection-oriented and reliable; it opens a connection with the three-way handshake: the client sends SYN, the server replies SYN-ACK, the client answers ACK. Understanding this is essential because scanning and denial-of-service both manipulate it. UDP is connectionless and fast (used by DNS, VoIP, streaming) but offers no delivery guarantee.

3.3 The protocols attackers love, and why

DNS — the internet's phone book

DNS translates names (example.com) to IP addresses. It was designed in a trusting era, so classic weaknesses include DNS spoofing / cache poisoning (feeding a resolver false answers) and DNS tunneling (smuggling data inside DNS queries to bypass filtering). Record types worth knowing: A (IPv4), AAAA (IPv6), MX (mail), NS (name servers), CNAME (alias), TXT (arbitrary text, used for SPF/DKIM).

ARP — the local-network address resolver

ARP maps IP addresses to MAC (hardware) addresses on a local segment. It has no authentication, so ARP spoofing/poisoning lets an attacker on the same network claim to be the gateway and intercept traffic — the foundation of many man-in-the-middle attacks (covered in the sniffing module).

DHCP — automatic addressing

DHCP hands out IP configuration automatically (the DORA exchange: Discover, Offer, Request, Acknowledge). A rogue DHCP server can hand clients a malicious gateway or DNS server, redirecting their traffic.

HTTP and HTTPS

HTTP is the web's request/response protocol; it is plaintext, so anyone in the path can read it. HTTPS wraps HTTP in TLS, providing confidentiality (encryption), integrity, and server authentication via certificates. Key HTTP concepts for attackers: methods (GET, POST, PUT, DELETE), status codes (2xx success, 3xx redirect, 4xx client error, 5xx server error), headers, cookies, and sessions.

TLS — how the secure channel is built

TLS performs a handshake to agree on a cipher suite, authenticate the server via its certificate (signed by a trusted Certificate Authority), and derive session keys. Weaknesses arise from outdated protocol versions (SSLv3, early TLS), weak ciphers, and invalid or self-signed certificates — all things a tester checks.

3.4 Reading a packet like a defender

Security tools such as Wireshark let you inspect headers. The fields that matter most:

• Source and destination IP — who is talking to whom.
• Source and destination port — which services.
• TCP flags — SYN, ACK, FIN, RST, PSH, URG reveal connection state and scanning behaviour.
• TTL (Time To Live) — hop count; can hint at the operating system and network distance.
• Payload — the actual data (readable if unencrypted).

3.5 Network segmentation and the perimeter

Defenders divide networks to contain attackers:

• VLANs and subnets separate systems logically.
• DMZ (demilitarized zone) is a buffer subnet exposing public services (web, mail) while shielding the internal network.
• Firewalls filter traffic by rules; NAT hides internal addresses.
• Zero-trust architecture assumes no implicit trust based on network location — every request is authenticated and authorized.

4.1 Why reconnaissance decides the outcome

Reconnaissance (or footprinting) is the disciplined collection of information about a target before any intrusion attempt. The more an attacker knows — domains, IP ranges, technologies, employees, email formats — the more precisely they can aim, and the fewer noisy probes they need. For a defender, reconnaissance is a mirror: everything a tester can find, an adversary can too, so the goal is to minimize unnecessary exposure.

4.2 Passive vs. active reconnaissance

	Passive recon	Active recon
Definition	Gathering information without directly touching the target's systems	Directly interacting with the target (queries, probes)
Examples	Search engines, WHOIS, public records, social media	DNS zone transfer attempts, pinging, banner grabbing
Detectability	Very low — the target usually cannot tell	Higher — may appear in the target's logs

Professionals begin passively to build context, then move to active techniques only within scope. The two blur: querying a third-party WHOIS database is passive with respect to the target, even though you send a request somewhere.

4.3 Open-source intelligence (OSINT)

OSINT is information gathered from publicly available sources. It is astonishingly effective and entirely legal when it stays within public data. Sources include:

• Company websites — technologies, staff names, job postings (which leak the exact software and versions a company runs).
• Search engines and Google dorking — advanced operators such as site:, filetype:, intitle:, and inurl: to surface exposed documents, login pages, and directories.
• Social media and professional networks — org charts, reporting lines, technologies, and personal details useful for social engineering.
• Public code repositories — accidentally committed secrets, internal hostnames, and configuration.
• Certificate transparency logs — reveal subdomains through issued TLS certificates.
• Specialist search engines — services that index internet-connected devices and their exposed services (used to find exposed systems that should not be public).

4.4 WHOIS and DNS footprinting

WHOIS databases record domain registration details — registrar, creation/expiry dates, name servers, and (unless privacy-protected) registrant contacts. This maps ownership and can reveal related domains.

DNS interrogation extracts the target's naming structure:

• Record lookups for A, MX, NS, TXT, and CNAME records reveal servers, mail infrastructure, and third-party services.
• Reverse DNS maps IPs back to names.
• Subdomain discovery (via certificate logs, brute-forcing name lists, and public datasets) expands the attack surface map.
• Zone transfer (AXFR) — if a misconfigured name server allows it, an attacker can download the entire DNS zone at once. Properly configured servers restrict transfers to authorized secondaries; testing for this is a standard active check.

4.5 Infrastructure and network footprinting

• IP range and ASN discovery — identifying the blocks of addresses an organization owns.
• Traceroute — mapping the path (and intermediate devices) to a target, hinting at network topology and filtering points.
• Banner grabbing — reading the identifying text a service returns (e.g. a web server announcing its software and version), which points to known vulnerabilities. This is mildly active.
• Website mirroring and archive analysis — reviewing current and historical copies of a site to find old pages, comments in source, and forgotten endpoints.

4.6 The human layer

People are part of the attack surface. Email address formats (first.last@company.com) can be inferred and used for phishing or password attacks. Metadata embedded in published documents (author names, software versions, internal file paths, sometimes usernames) leaks internal detail. Data-breach compilations reveal which corporate emails have appeared in past leaks, guiding credential-based attacks. A tester checks all of this so the organization can understand and reduce its human exposure.

4.7 Organizing what you find

Reconnaissance output is only useful if it is organized. Professionals build an inventory: domains and subdomains, IP ranges, technologies and versions, employees and roles, email format, exposed documents, and third-party dependencies. This inventory drives the next phase — scanning — and becomes an appendix in the final report.

5.1 Scanning vs. enumeration

Scanning answers "what is alive and what is listening?" — it discovers live hosts, open ports, and running services. Enumeration goes deeper on what scanning found, actively extracting detailed information: user accounts, network shares, software versions, and configuration. Scanning is the second phase; enumeration is the bridge into gaining access.

5.2 Host discovery

Before scanning ports, you determine which hosts exist. Techniques include ICMP echo ("ping") sweeps, ARP discovery on local networks, and TCP/UDP probes to common ports. Because many networks block ICMP, testers combine methods. The output is a list of live IP addresses to examine further.

5.3 Port scanning and how it works

A port scanner sends crafted packets and infers each port's state from the response, exploiting the TCP handshake behaviour you learned earlier.

Scan type	How it works	Notes
TCP connect	Completes the full three-way handshake	Reliable but noisy; logged by the target
SYN (half-open)	Sends SYN, reads SYN-ACK, then RST without completing	Faster and quieter; the classic default
UDP scan	Sends UDP packets; open ports often stay silent, closed ones return ICMP errors	Slow and less certain; important for DNS, SNMP, etc.
FIN / NULL / Xmas	Send unusual flag combinations to elicit differing responses	Can slip past simple filters; behaviour varies by OS
ACK scan	Sends ACK to map firewall rules	Reveals filtered vs. unfiltered, not open vs. closed

Reading the results

State	Meaning
Open	A service is actively listening and accepting connections
Closed	The host is reachable but no service is listening on that port
Filtered	A firewall or filter is blocking the probe; state cannot be determined

5.4 Service and version detection

Knowing a port is open is not enough; you need to know what is listening and its version. Service/version detection probes the port and analyses the response to identify the software (e.g. a particular web server or database) and its version. This is critical because vulnerabilities are version-specific — a known flaw in version 1.2 may be patched in 1.3.

5.5 Operating-system fingerprinting

OS fingerprinting guesses the target's operating system by observing subtle differences in how its network stack behaves — default TTL values, TCP window sizes, and responses to unusual packets.

• Active fingerprinting sends crafted probes and analyses responses (more accurate, more detectable).
• Passive fingerprinting observes existing traffic without sending anything (stealthier, less precise).

5.6 Enumeration — reading the labels

Enumeration actively queries services to extract useful lists. Common targets:

Service / protocol	What enumeration can reveal
SMB / NetBIOS (139/445)	Shared folders, user and group names, policies
SNMP (161)	Device details, running processes, network configuration — especially with default community strings like "public"
LDAP / Active Directory (389)	Users, groups, organizational structure
SMTP (25)	Valid email accounts via commands like VRFY/EXPN
DNS (53)	Hostnames and infrastructure (including via zone transfer)
Web (80/443)	Directories, files, technologies, and application structure

The result of enumeration is often a list of valid usernames, exposed shares, and specific software versions — precisely the raw material for the next phase.

5.7 Stealth and scan hygiene

Scanning is active and noisy by nature. Attackers try to evade detection by slowing scans, randomizing timing and source ports, fragmenting packets, or routing through intermediaries. Defenders detect scanning through intrusion-detection signatures and traffic anomalies. As an ethical tester you must scan only within your authorized window and scope, and note that aggressive scanning can itself disrupt fragile systems (some devices crash when scanned) — a reason RoE often constrains scan intensity.

6.1 Assessment vs. penetration test

A vulnerability assessment systematically identifies, classifies, and prioritizes weaknesses across systems — usually broad, automated, and without exploitation. A penetration test is narrower and deeper: it exploits selected weaknesses to prove real-world impact. Think of the assessment as the wide inventory of every unlocked door, and the pentest as picking a few locks to demonstrate what a burglar could actually reach.

	Vulnerability assessment	Penetration test
Breadth	Wide — many systems	Narrow — chosen targets
Depth	Identifies, rarely exploits	Exploits to prove impact
Automation	Largely automated scanners	Heavily manual and creative
Output	Prioritized list of findings	Attack narrative + proof of exploitation

6.2 The vulnerability management lifecycle

Vulnerability management is a continuous cycle, not a one-time scan:

1. Discover / asset inventory — you cannot protect what you do not know you have.
2. Assess / scan — identify vulnerabilities across the inventory.
3. Prioritize — rank by severity, exploitability, exposure, and business impact.
4. Remediate — patch, reconfigure, or apply compensating controls.
5. Verify / re-scan — confirm the fix actually worked.
6. Report and repeat — track metrics and feed lessons back in.

6.3 The standards that make findings comparable

Identifier	Full name	What it does
CVE	Common Vulnerabilities and Exposures	A unique ID for a specific publicly known vulnerability (e.g. CVE-2021-44228)
CVSS	Common Vulnerability Scoring System	A 0.0–10.0 severity score based on exploitability and impact metrics
CWE	Common Weakness Enumeration	A catalogue of weakness types (e.g. CWE-79 cross-site scripting)
CPE	Common Platform Enumeration	A standard naming scheme for products and versions
NVD	National Vulnerability Database	The U.S. government repository that enriches CVEs with CVSS, CPE, and references

6.4 Types of scanning

• Unauthenticated (black-box) scans probe from the outside with no credentials — they see what an external attacker sees but miss internal detail.
• Authenticated (credentialed) scans log in to check patch levels and configuration from the inside — far more accurate and thorough.
• Network scans examine hosts and services across the network.
• Host / agent-based scans run on the endpoint for deep local visibility.
• Web application scans crawl and test websites for application flaws.
• Database scans check database configuration, permissions, and known flaws.

Common enterprise scanners include Nessus, OpenVAS, Qualys, and Rapid7 Nexpose/InsightVM. They compare discovered software and configuration against large vulnerability databases and produce ranked findings.

6.5 False positives and false negatives

No scanner is perfect:

• A false positive reports a vulnerability that is not really exploitable — wastes remediation effort and erodes trust in the tool.
• A false negative misses a real vulnerability — the dangerous one, because you believe you are safe when you are not.

This is why skilled humans validate scanner output. Automated tools find the obvious; manual verification separates real risk from noise and catches what tools miss (especially business-logic flaws).

6.6 Prioritization: turning a list into a plan

A raw scan can return thousands of findings. You cannot fix everything at once, so prioritize by combining:

• Severity (CVSS as a baseline).
• Exploitability — does a working exploit exist? Is it being used in the wild? (Catalogues of known-exploited vulnerabilities help here.)
• Exposure — is the asset internet-facing or internal?
• Business impact — how critical is the asset and its data?
• Compensating controls — is the risk already partly mitigated?

The output is a risk-ranked remediation queue with owners and deadlines — managed exactly like audit findings.

6.7 Remediation and patch management

Fixes take several forms: patching (applying vendor updates), reconfiguration (hardening settings, disabling features), compensating controls (e.g. a virtual patch at a web application firewall when a real patch is not yet possible), and occasionally risk acceptance (formally documented when the cost of fixing exceeds the risk). A mature patch management process tests patches, schedules them, and tracks coverage — because unpatched known vulnerabilities are the single most common breach cause.

7.1 The gaining-access phase

After scanning and enumeration reveal services, versions, and accounts, the attacker attempts to obtain a foothold. Access is usually gained by one of a few broad routes: exploiting a software vulnerability, abusing weak or stolen credentials, tricking a user (social engineering), or leveraging a misconfiguration. Credential-based attacks are by far the most common in the real world, which is why authentication is the centre of gravity for both attackers and defenders.

7.2 How passwords are stored — and why it matters

Good systems never store passwords in plaintext. Instead they store a hash — a one-way cryptographic transformation. When you log in, the system hashes what you typed and compares it to the stored hash. Two properties make hashing safe when done well:

• Salting — a unique random value added to each password before hashing, so identical passwords produce different hashes and precomputed attack tables become useless.
• Slow, adaptive hashing — using algorithms deliberately designed to be computationally expensive (such as bcrypt, scrypt, Argon2, or PBKDF2) so that testing many guesses is slow. Fast general-purpose hashes (like plain MD5 or SHA-1) are inappropriate for passwords because they can be tested billions of times per second.

7.3 Password-attack categories (conceptual)

Attack	Idea	Primary defense
Dictionary attack	Try likely words and common passwords	Ban common/breached passwords; require length
Brute force	Try every possible combination	Long passphrases; slow hashing; lockouts
Rainbow tables	Use precomputed hash lookups	Per-user salting
Credential stuffing	Reuse username/password pairs leaked from other breaches	Unique passwords; MFA; breached-credential checks
Password spraying	Try one common password against many accounts to avoid lockout	MFA; anomaly detection; ban common passwords

Offline cracking (against a stolen hash file) is limited only by computing power and hash strength; online guessing (against a live login) is limited by rate limits and lockouts. This is exactly why where the hashes live, and how strong the algorithm is, matters so much.

7.4 Multi-factor authentication — the single biggest win

Multi-factor authentication (MFA) requires more than one category of proof: something you know (password), something you have (a phone, token, or passkey), or something you are (biometrics). Even a perfectly cracked password is far less useful when a second factor is required. Phishing-resistant factors (hardware security keys and passkeys based on the FIDO2/WebAuthn standards) also defeat many real-time phishing attacks that can intercept one-time codes.

7.5 Privilege escalation

A foothold is often low-privilege — a standard user account, not an administrator. Privilege escalation is the move from limited access to greater control.

• Vertical escalation — gaining higher privileges than you have (user → administrator/root). This is what turns a minor foothold into full compromise.
• Horizontal escalation — accessing another account at the same privilege level (one user's data → another user's data), common in web applications with weak access control.

Common root causes (conceptually) include unpatched local vulnerabilities, misconfigured permissions, excessive rights granted to services, stored credentials, and weak separation of duties. Defenders counter with the principle of least privilege — every account and process gets only the access it truly needs.

7.6 Credential reuse inside a network

Once inside, attackers often move laterally using credentials or authentication material harvested from one machine to access others. Techniques such as pass-the-hash (reusing a captured password hash to authenticate without knowing the plaintext) illustrate why isolating administrative credentials and segmenting networks matter. Defenders limit this with unique local admin passwords, tiered administration, network segmentation, and monitoring for unusual authentication patterns.

7.7 Persistence and anti-forensics — through a defender's eyes

To keep access, attackers establish persistence — mechanisms that survive reboots and logouts, such as scheduled tasks, new accounts, or modified startup items. To avoid detection they may attempt anti-forensics: clearing or tampering with logs and timestamps. You study these not to perform them but to detect them: unexpected new accounts, unusual scheduled tasks, and — crucially — gaps or inconsistencies in logs are classic indicators of compromise. This is why sending logs to a separate, tamper-resistant system (a SIEM) is a core defensive control.

8.1 The malware family tree

Malware ("malicious software") is any program designed to harm, exploit, or gain unauthorized control. The families differ mainly in how they spread and what they do.

Type	Distinguishing behaviour
Virus	Attaches to a legitimate file/program and spreads when that host is executed by a user
Worm	Self-replicating; spreads across networks on its own, without user action
Trojan	Disguised as legitimate software; tricks the user into running it, then acts maliciously
Remote Access Trojan (RAT)	A trojan that gives the attacker remote control of the machine
Ransomware	Encrypts (and often exfiltrates) data, demanding payment for recovery
Rootkit	Hides its presence deep in the system to maintain stealthy, privileged access
Bootkit	A rootkit that infects boot components to load before the OS
Spyware	Secretly gathers information about the user
Keylogger	Records keystrokes to steal credentials and data
Adware	Displays unwanted ads; often bundles other unwanted behaviour
Logic bomb	Dormant code that triggers on a condition (a date, an event)
Botnet client	Enrolls the machine into a network of bots controlled via C2 for DDoS, spam, mining
Cryptominer	Hijacks resources to mine cryptocurrency for the attacker
Fileless malware	Runs in memory using legitimate system tools, leaving little on disk

8.2 How malware gets in

• Phishing attachments and links — still the number-one delivery method.
• Drive-by downloads — compromised or malicious websites exploiting the browser.
• Malicious or pirated software — trojanized installers and cracks.
• Removable media — infected USB drives (including "lost" USBs left to be found).
• Software supply chain — tampering with a trusted update or dependency so many victims are infected at once.
• Exploiting unpatched services — how network worms spread.
• Malvertising — malicious code delivered through ad networks.

8.3 The lifecycle of a modern intrusion

Sophisticated malware rarely does everything at once. A common pattern: an initial dropper/loader gains a foothold, establishes command and control (C2) to receive instructions, escalates privileges, moves laterally, and only then deploys the final payload (data theft, encryption). Understanding these stages lets defenders detect an attack in progress rather than only after the damage.

8.4 How malware evades detection

Attackers work hard to avoid signatures:

• Polymorphic malware changes its code with each infection while keeping the same behaviour.
• Metamorphic malware rewrites itself more completely.
• Packers and encryption obscure the code until it runs.
• Living off the land abuses built-in, trusted tools so activity blends in.
• Sandbox evasion — the malware detects it is being analysed and stays dormant.

This is why signature-only defenses are no longer enough and behaviour-based detection is essential.

8.5 Malware analysis — the defensive discipline

Analysts study captured malware to understand and defend against it. Two complementary approaches:

• Static analysis examines the file without running it — inspecting strings, structure, and code. Safe but can be thwarted by obfuscation.
• Dynamic analysis runs the sample in an isolated, instrumented environment (a sandbox) and observes its behaviour — files created, network connections made, registry changes. More revealing but must be strictly contained.

The output feeds indicators of compromise (IOCs): file hashes, malicious domains/IPs, filenames, registry keys, and behavioural patterns that defenders use to hunt for and block the threat everywhere.

8.6 Defenses that actually work today

Modern endpoint protection has moved beyond classic antivirus:

• EDR (Endpoint Detection and Response) monitors endpoint behaviour, detects suspicious activity, and enables investigation and response.
• XDR extends this correlation across endpoints, network, email, and cloud.
• Application allowlisting permits only approved programs to run.
• Email and web filtering block the most common delivery channels.
• Patching removes the vulnerabilities worms and exploit kits rely on.
• Least privilege and network segmentation limit how far malware can spread.
• Reliable, tested, offline/immutable backups are the definitive answer to ransomware.

9.1 What sniffing is

Packet sniffing is capturing network traffic as it passes a point on the network. It is a double-edged tool: network engineers and defenders use it constantly to troubleshoot and detect threats, while attackers use it to steal unencrypted data (credentials, session tokens, messages). The tool most associated with legitimate packet analysis is Wireshark; the command-line equivalent is tcpdump.

A network interface normally ignores traffic not addressed to it. Putting it in promiscuous mode makes it accept all frames it can see — the prerequisite for sniffing.

9.2 Passive vs. active sniffing

	Passive sniffing	Active sniffing
Environment	Shared media (legacy hubs) where all traffic reaches every port	Switched networks that send traffic only to the intended port
Method	Simply listen	Manipulate the network (e.g. ARP poisoning, MAC flooding) to redirect traffic to the attacker
Detectability	Very hard to detect	Generates anomalies that can be detected

Because modern networks use switches (which forward frames only to the relevant port), attackers must actively trick the network to see traffic that is not theirs — which is where the next techniques come in.

9.3 The MITM enablers

ARP poisoning (spoofing)

Recall that ARP has no authentication. An attacker on the same segment sends forged ARP replies so that victims associate the attacker's MAC with the gateway's IP (and vice versa). Traffic between the victim and the gateway then flows through the attacker — a classic man-in-the-middle position that enables interception and modification.

MAC flooding

A switch keeps a table mapping MAC addresses to ports. Flooding it with many fake MAC addresses can overflow the table, causing some switches to "fail open" and broadcast traffic to all ports — effectively turning a switched network into a shared one the attacker can sniff.

DNS spoofing / cache poisoning

By supplying false DNS answers, an attacker makes a victim's browser resolve a legitimate name to a malicious IP, silently redirecting them to an attacker-controlled server. Combined with a MITM position, this is powerful.

Rogue DHCP and rogue access points

A rogue DHCP server hands victims a malicious gateway/DNS; a rogue or "evil twin" wireless access point lures victims into connecting through the attacker. Both establish the interception position (wireless is covered further in its own module).

9.4 The role of encryption — and SSL stripping

Here is the crucial point: a MITM position is far less valuable when the traffic is properly encrypted. If a victim uses HTTPS, the attacker in the middle sees only ciphertext. This is why attackers try SSL stripping — downgrading a victim's connection from HTTPS to HTTP by intercepting the initial request, so data flows in plaintext. The defense is HTTP Strict Transport Security (HSTS), which tells browsers to only ever use HTTPS for a site, plus preloading and modern browser behaviour that resists downgrades. Certificate warnings also matter: a MITM that tries to present its own certificate for a site should trigger a browser warning — which is exactly why users must never click through certificate errors.

9.5 Legitimate packet analysis

Do not lose sight of the defensive side: the same capture skills let blue teams detect intrusions, investigate incidents, baseline normal traffic, and troubleshoot performance. Network detection and response (NDR) tools and intrusion-detection systems are, at heart, automated large-scale packet analysis.

10.1 Why the human is the target

Social engineering is the art of manipulating people into performing actions or divulging information that compromises security. It bypasses technology entirely: why spend weeks defeating a firewall when a convincing phone call can get someone to reset a password for you? Attackers target humans because people are helpful, busy, trusting, and susceptible to authority and urgency — and because no patch fixes human nature. This is why security awareness is a control in its own right.

10.2 The psychology attackers exploit

Effective social engineering leans on well-documented principles of influence:

Principle	How it is abused
Authority	Impersonating a boss, IT, police, or a vendor to command compliance
Urgency / scarcity	"Act now or your account is suspended" — rushing people past their judgment
Social proof	"Everyone in your team already did this"
Reciprocity	Offering a small favour to create a sense of obligation
Liking / familiarity	Building rapport or impersonating a known colleague
Commitment / consistency	Getting a small "yes" that leads to bigger ones
Fear	Threats of consequences, legal action, or exposure

The common thread: they short-circuit deliberate thinking and trigger an automatic response.

10.3 The catalogue of social-engineering attacks

Digital

• Phishing — mass fraudulent messages (usually email) tricking recipients into clicking, entering credentials, or opening malware.
• Spear phishing — targeted phishing tailored to a specific person using researched detail.
• Whaling — spear phishing aimed at senior executives ("big fish").
• Business Email Compromise (BEC) — impersonating an executive or vendor to authorize fraudulent payments or data release; one of the costliest attacks in existence.
• Vishing — voice phishing over the phone.
• Smishing — phishing via SMS/text.
• Watering hole — compromising a website the target group is known to visit, infecting them there.
• Quishing — malicious QR codes that lead to phishing sites.

Pretext and physical

• Pretexting — inventing a believable scenario/identity to extract information.
• Baiting — leaving infected media (e.g. a labelled USB) for a curious victim to use.
• Quid pro quo — offering a service (e.g. fake IT help) in exchange for access or information.
• Tailgating / piggybacking — following an authorized person through a secure door.
• Shoulder surfing — observing screens/keypads to steal information.
• Dumpster diving — retrieving sensitive information from discarded materials.

10.4 Anatomy of a phishing attack

1. Reconnaissance — research the target and pretext (often from OSINT).
2. Lure — a message engineered to trigger urgency or authority.
3. Hook — a link to a convincing fake site, a malicious attachment, or a request for action.
4. Harvest / payload — captured credentials, executed malware, or an authorized fraudulent action.
5. Exploitation — using what was gained to progress the attack.

Red flags a trained user learns to spot: mismatched or look-alike sender domains, urgency and threats, unexpected attachments, links whose real destination differs from the visible text, generic greetings, requests to bypass normal procedures, and requests for credentials, MFA codes, or payment changes.

10.5 Defenses — the human firewall plus technology

Because the target is human, defense is part culture, part technology:

• Security awareness training and realistic phishing simulations that teach recognition without blame.
• Verification procedures — call back on a known-good number, use a second channel, and require dual authorization for payments and sensitive changes. A simple "I'll call you back on the number in our directory" defeats most impersonation.
• Multi-factor authentication so a stolen password alone is not enough.
• Email authentication — SPF (authorizes sending servers), DKIM (cryptographically signs mail), and DMARC (tells receivers how to handle failures and enables reporting) together make domain spoofing much harder.
• Least privilege and payment controls so a single tricked employee cannot cause catastrophic loss.
• A blame-free reporting culture — the faster people report, the faster you contain. Punishing victims guarantees silence.

11.1 The goal: deny availability

A Denial-of-Service (DoS) attack aims to make a system, service, or network unavailable to its legitimate users — the third pillar of the CIA triad. It does not steal or alter data; it prevents access. A Distributed Denial-of-Service (DDoS) attack does the same thing from many sources at once, which makes it vastly more powerful and much harder to block, because you cannot simply block one IP address.

11.2 Botnets: the engine of DDoS

Most large DDoS attacks are launched from botnets — networks of compromised devices (computers, servers, and increasingly poorly-secured IoT gadgets like cameras and routers) controlled by an attacker through command-and-control. The owners of these devices usually have no idea they are participating. Because the traffic comes from thousands or millions of real, distributed devices, it blends in and is difficult to filter.

11.3 The three families of attack

Family	Targets	Idea	Examples
Volumetric	Bandwidth	Saturate the network pipe with sheer traffic volume (measured in bits/sec)	UDP flood, ICMP flood, amplification attacks
Protocol	Server/infrastructure resources	Exhaust connection tables or state (measured in packets/sec)	SYN flood, fragmentation attacks
Application layer	The application itself (Layer 7)	Exhaust server processing with seemingly legitimate requests (measured in requests/sec)	HTTP flood, Slowloris

Volumetric — filling the pipe

These simply overwhelm available bandwidth. A UDP flood sends huge volumes of UDP packets; an ICMP (ping) flood does the same with ping traffic. The most efficient volumetric attacks use amplification.

Protocol — exhausting state

Recall the SYN flood from the networking module: by sending many SYN packets and never completing the handshake, the attacker fills the server's table of half-open connections so it can accept no more. These attacks are efficient because a small amount of attacker effort ties up disproportionate server resources.

Application layer — the quiet killer

Layer-7 attacks are dangerous because each request looks legitimate, so they are hard to distinguish from real users and can be effective at relatively low traffic volumes. An HTTP flood hammers expensive pages (like search) with many requests; Slowloris keeps many connections open by sending partial requests very slowly, exhausting the server's connection pool with minimal bandwidth.

11.4 Amplification and reflection — force multipliers

The most powerful volumetric attacks combine two tricks:

• Reflection — the attacker spoofs the victim's IP as the source, sends requests to third-party servers, and those servers send their responses to the victim.
• Amplification — the attacker chooses requests whose responses are far larger than the request (a high "amplification factor"). Services historically abused include DNS, NTP, and memcached; a small spoofed query can generate a response tens or hundreds of times larger, all aimed at the victim.

11.5 Business impact

Downtime is expensive: lost revenue, broken SLAs, reputational damage, and support costs. DDoS is also used as a smokescreen — flooding the front door while a quieter intrusion happens elsewhere — and as extortion ("ransom DDoS," where attackers demand payment to stop or not start an attack). For any organization whose availability matters (banking, e-commerce, SaaS), DDoS resilience is a board-level concern.

11.6 Defenses — layered and largely upstream

You cannot absorb a large DDoS on a single server; mitigation happens across layers and, crucially, upstream of your infrastructure:

• Rate limiting and connection limits to blunt floods and slow attacks.
• DDoS scrubbing services and CDNs that absorb and filter attack traffic across a massive distributed network before it reaches you.
• Anycast — announcing the same IP from many locations so attack traffic is spread and localized.
• Upstream/ISP mitigation and blackholing — dropping attack traffic at the provider level; remotely triggered black hole routing sends the targeted traffic to nowhere.
• Over-provisioning and autoscaling to absorb spikes.
• Web Application Firewalls and behaviour analysis for Layer-7 attacks.
• Traffic baselining and an incident response/runbook so the team reacts fast.

12.1 Why sessions exist and why they are targets

HTTP is stateless — each request is independent, so the server needs a way to remember that you already proved who you are. After login, the server issues a session identifier (usually stored in a cookie) or a token; your browser sends it with every subsequent request, and the server treats you as authenticated. This means the session identifier is as good as your password for the duration of the session. Session hijacking is the theft or forgery of this identifier so the attacker is treated as you — often bypassing even strong passwords and, in some cases, MFA.

12.2 How sessions are hijacked

Method	How it works
Sniffing	Capturing the session token from unencrypted traffic (why HTTPS everywhere matters)
Cross-site scripting (XSS)	Injecting script that reads and exfiltrates the session cookie from the victim's browser
Session fixation	Forcing a victim to use a session ID the attacker already knows, then hijacking after login
Session prediction	Guessing weak, sequential, or non-random session IDs
Man-in-the-middle	Intercepting the session in transit (see the sniffing module)
Token theft from storage	Stealing tokens stored insecurely (e.g. accessible to scripts) on the client

12.3 Cookies and their security attributes

Most session identifiers live in cookies, and cookies have attributes that dramatically affect their safety:

• HttpOnly — the cookie cannot be read by JavaScript, which blocks XSS from stealing it. Essential for session cookies.
• Secure — the cookie is only sent over HTTPS, preventing it from leaking over plaintext.
• SameSite — controls whether the cookie is sent on cross-site requests (Strict, Lax, or None), a key defense against cross-site request forgery.
• Domain / Path / Expiry — scope and lifetime; shorter lifetimes reduce the window of risk.

12.4 Session fixation, explained

In a fixation attack, the attacker first obtains a valid (but unauthenticated) session ID, then tricks the victim into logging in using that same ID — for example via a crafted link that sets it. Because the server does not issue a fresh ID at login, the attacker already knows the now-authenticated session ID and can use it. The fix is simple and mandatory: always regenerate the session identifier upon successful authentication (and on privilege changes).

12.5 Token-based authentication

Modern applications and APIs often use tokens instead of server-side sessions. A common format is the JSON Web Token (JWT), a self-contained, signed token carrying claims (who the user is, what they can do, when it expires). Benefits include statelessness and scalability; risks include tokens that are stored insecurely, not expired promptly, or accepted without proper signature verification. Whatever the mechanism, the principle is identical: whoever holds a valid token is treated as the user, so protecting and expiring tokens is critical.

12.6 The broader category: broken authentication

Session and token flaws sit inside the wider problem of broken authentication and session management — one of the most impactful web risk categories. It includes weak password policies, missing MFA, credential stuffing exposure, insecure password recovery, exposed session IDs (e.g. in URLs), and sessions that never time out. Fixing it is less about a single control and more about disciplined identity engineering.

12.7 Defenses

• Encrypt everything (HTTPS/HSTS) so tokens cannot be sniffed.
• Generate long, random session IDs to defeat prediction.
• Set HttpOnly, Secure, and SameSite on session cookies.
• Regenerate the session ID on login and privilege change to defeat fixation.
• Enforce idle and absolute timeouts, and invalidate sessions on logout server-side.
• Bind sessions to context where feasible (and re-authenticate for sensitive actions).
• Prevent XSS (covered in the web module), since XSS defeats many session protections.
• Expire and properly validate tokens; verify signatures; keep secrets safe.

13.1 Why web apps dominate

Web applications are exposed to the entire internet, handle valuable data, and are updated frequently by teams under deadline pressure — a perfect storm for vulnerabilities. Testing them combines automated scanning with heavy manual work using an intercepting proxy that lets a tester view and modify the requests between browser and server. The best-known tools are Burp Suite and OWASP ZAP (ZAP is free and open-source). The reference framework for web risks is the OWASP Top 10, maintained by the Open Worldwide Application Security Project.

13.2 The OWASP Top 10 (2021 edition)

#	Category	In plain terms
A01	Broken Access Control	Users can act outside their permissions (view/edit others' data, reach admin functions)
A02	Cryptographic Failures	Sensitive data not properly protected (weak or missing encryption, exposed data)
A03	Injection	Untrusted input is interpreted as a command (SQL, OS, LDAP) — includes XSS
A04	Insecure Design	Flaws baked into the architecture, not just the code
A05	Security Misconfiguration	Insecure defaults, unnecessary features, verbose errors, missing hardening
A06	Vulnerable & Outdated Components	Using libraries/frameworks with known vulnerabilities
A07	Identification & Authentication Failures	Weak login, session, and credential handling
A08	Software & Data Integrity Failures	Trusting unverified updates, plugins, or data (incl. insecure deserialization)
A09	Security Logging & Monitoring Failures	Not detecting or responding to attacks due to poor logging
A10	Server-Side Request Forgery (SSRF)	Tricking the server into making requests to unintended destinations

13.3 Cross-site scripting (XSS)

XSS is an injection flaw where an attacker gets their script to run in another user's browser in the context of a trusted site. It can steal session cookies, capture keystrokes, and manipulate the page. Three types:

• Stored (persistent) XSS — the malicious script is saved on the server (e.g. in a comment) and served to every visitor. Most dangerous.
• Reflected XSS — the script is reflected off the server from a crafted request/link and runs for the victim who follows it.
• DOM-based XSS — the flaw is entirely in client-side JavaScript that unsafely handles input.

The defense is rigorous output encoding/escaping (so input is displayed as data, never executed as code), input validation, and a Content Security Policy (CSP) that restricts what scripts a page may run.

13.4 Cross-site request forgery (CSRF)

CSRF tricks a logged-in victim's browser into sending an unwanted authenticated request (e.g. transfer funds, change email) to a site where they are authenticated, by luring them to a malicious page that fires the request. Because the browser automatically attaches the victim's cookies, the request looks legitimate. Defenses: anti-CSRF tokens (unpredictable per-request tokens the attacker cannot guess), the SameSite cookie attribute, and re-authentication for sensitive actions.

13.5 A few more you must recognize

• SSRF — the app fetches a URL the attacker controls, letting them reach internal systems (including cloud metadata services) the attacker could not otherwise touch. Defenses: strict allowlists, blocking internal ranges, and validating destinations.
• Insecure deserialization — untrusted serialized data is turned back into objects unsafely, potentially leading to code execution. Defense: avoid deserializing untrusted data, use integrity checks.
• Security misconfiguration — default credentials, directory listing enabled, verbose error messages that leak internals, unnecessary services. Defense: hardening baselines and least functionality.
• Vulnerable components — outdated libraries with known CVEs. Defense: software composition analysis and prompt updates.

13.6 Secure development is the real fix

Testing finds flaws late; secure development prevents them. Key practices: validate and encode all input/output, use safe APIs (parameterized queries, safe templating), enforce access control server-side on every request, keep dependencies current, apply security requirements and threat modelling in design, and integrate security testing (SAST, DAST, dependency scanning) into the development pipeline (often called DevSecOps or "shifting left").

14.1 The root cause of all injection

Injection happens when an application takes untrusted input and mixes it directly into a command that an interpreter executes — a SQL query, an operating-system command, an LDAP filter, and so on. The interpreter cannot tell the difference between the developer's intended code and the attacker's injected input, so it executes both. Every injection defense boils down to keeping data and code strictly separate.

14.2 SQL injection, mechanically

SQL injection (SQLi) targets the database layer. It occurs when user input is concatenated into a SQL statement instead of being safely parameterized. Imagine a login query built by string concatenation:

-- UNSAFE: user input concatenated directly into the query
SELECT * FROM users WHERE username = '[input]' AND password = '[input]';

If the application places raw input where [input] is, an attacker can supply input containing SQL syntax — the textbook illustration being a value like ' OR '1'='1 — which changes the query's logic so the condition is always true, potentially bypassing the intended check. The point for a defender is not the specific string; it is the class of mistake: the input was treated as code. As soon as the query is parameterized (next section), that same input is treated as a literal value that will simply never match, and the attack fails.

14.3 The shapes SQL injection takes

Category	How results come back
In-band — error-based	The database's error messages leak information the attacker uses
In-band — union-based	Results of an injected query are combined into the application's normal output
Blind — boolean-based	No data is returned directly; the attacker infers information from true/false differences in responses
Blind — time-based	The attacker infers information from deliberate time delays in responses
Out-of-band	Data is exfiltrated through a separate channel (e.g. a DNS request) when direct output is unavailable

"Blind" injection is important to understand because applications that hide error messages are not automatically safe — attackers can still extract data indirectly. Automated tools exist (a well-known one is sqlmap) precisely because these techniques are systematic.

14.4 Why it matters so much

The database usually holds the crown jewels. A successful SQL injection can lead to reading or modifying sensitive data (customer records, credentials), authentication bypass, and — depending on database privileges and configuration — much broader compromise. Because databases are so central, injection has caused some of the largest breaches in history, which is why it sits in the OWASP Top 10 and why the defenses are non-negotiable.

14.5 Other injection families

• OS command injection — untrusted input reaches a system shell, letting an attacker run operating-system commands. Defense: avoid shelling out with user input; use safe APIs and strict allowlists.
• LDAP injection — manipulating directory queries.
• XML External Entity (XXE) — abusing insecure XML parsers to read files or reach internal systems. Defense: disable external entity processing.
• NoSQL injection — the same idea against non-relational databases.
• Server-side template injection (SSTI) — injecting into a template engine, sometimes leading to code execution.

They differ in the interpreter targeted, but the cause and cure are the same: keep untrusted data out of executed commands.

14.6 The definitive defenses

1. Parameterized queries / prepared statements — the single most important defense. The query structure is defined first with placeholders; user input is then bound strictly as data and can never change the query's logic. This eliminates SQL injection when used consistently.
2. Use an ORM or safe query API that parameterizes by default (still verify raw queries).
3. Input validation / allowlisting — accept only expected formats (defense in depth, not a substitute for parameterization).
4. Least-privilege database accounts — the application's database user should have only the permissions it needs, limiting damage if injection occurs.
5. Stored procedures written safely (they are not automatically safe if they build dynamic SQL from input).
6. Web Application Firewall — a useful additional layer that can block common patterns, but never a replacement for fixing the code.
7. Suppress detailed database errors in production to reduce information leakage.

15.1 Wireless fundamentals

Wi-Fi broadcasts data over radio, which means anyone within range can receive the signal — the physical boundary that protects wired networks is gone. A network is identified by its SSID (the name), and clients associate with an access point (AP). Because the medium is open to anyone nearby, encryption of the wireless link is essential, and the history of Wi-Fi security is largely the story of encryption schemes being broken and replaced.

15.2 The evolution of Wi-Fi security

Standard	Status	Notes
WEP	Broken — do not use	Fundamentally flawed; can be cracked quickly. Its weaknesses drove the entire redesign.
WPA	Deprecated	An interim fix over WEP; also outdated.
WPA2	Widely used; aging	Strong when configured with a robust passphrase, but vulnerable to offline attacks on captured handshakes with weak passphrases (and to the KRACK protocol weakness).
WPA3	Current best practice	Adds stronger protection (SAE handshake resistant to offline guessing) and better defaults. Use where supported.

15.3 Common wireless attacks (conceptual)

• Handshake capture and offline cracking — with WPA2-Personal, an attacker can capture the authentication handshake and then attempt to guess the passphrase offline. This is only feasible if the passphrase is weak — a long, random passphrase makes it impractical, and WPA3's design resists it.
• Evil twin / rogue access point — the attacker sets up a look-alike AP with the same SSID to lure clients into connecting through them, enabling interception. A subset is the captive-portal credential-harvesting page.
• Deauthentication attacks — sending forged deauth frames to knock clients off, often to force a reconnection (and capture the handshake) or to push them toward an evil twin. Protected Management Frames (802.11w) mitigate this.
• WPS weaknesses — Wi-Fi Protected Setup's PIN method has known flaws that can be brute-forced; it should be disabled.
• Jamming — flooding the radio spectrum to deny service (an availability attack).

15.4 Bluetooth and other short-range risks

Bluetooth and similar short-range technologies have their own history of issues — historically labelled things like bluejacking (sending unsolicited messages), bluesnarfing (unauthorized data access), and various pairing and implementation flaws. The general lessons transfer: keep devices non-discoverable when not pairing, keep firmware updated, use current protocol versions, and be cautious about auto-connecting devices. The proliferation of wireless IoT expands this attack surface considerably.

15.5 Why wireless needs extra design care

Wireless blurs the network perimeter, so defenders must think about signal reach (does your Wi-Fi flood the street?), guest isolation, and the risk of employees connecting corporate devices to untrusted networks. Wireless should be treated as an untrusted segment: authenticate strongly, segment it from sensitive systems, and monitor for rogue APs.

16.1 Mobile security

Modern smartphones are hardened by design: apps run in sandboxes, are code-signed, and request granular permissions, and official app stores perform review. Yet risk remains, concentrated in a few areas captured by the OWASP Mobile Top 10 themes:

• Insecure data storage — sensitive data saved unprotected on the device.
• Insecure communication — traffic sent without proper TLS (or with certificate validation disabled).
• Weak authentication/authorization and poor session handling.
• Insufficient cryptography — weak or misused algorithms.
• Reverse engineering and tampering — apps analysed or modified to extract secrets or bypass checks.
• Insecure/excessive permissions and risky third-party libraries.

Jailbreaking (iOS) / rooting (Android) removes the platform's built-in protections, expanding the attack surface. Sideloading apps from outside official stores bypasses review and is a common malware route. In organizations, Mobile Device Management (MDM) enforces policies, separates work and personal data, and enables remote wipe.

16.2 The Internet of Things (IoT)

IoT devices — cameras, sensors, smart home gear, medical and industrial devices — are notoriously insecure for structural reasons:

• Weak or default credentials that users never change.
• Infrequent or absent security updates, and long device lifespans that outlast vendor support.
• Limited compute that constrains strong security.
• Exposed services and insecure companion apps/cloud APIs.
• Physical accessibility in many deployments.

The consequences are real: insecure IoT devices are conscripted into massive botnets (a well-known example enrolled hundreds of thousands of cameras and routers to launch record DDoS attacks), used as footholds into networks, and — for medical or industrial devices — can carry safety implications. The OWASP IoT Top 10 highlights weak passwords, insecure network services, insecure update mechanisms, and lack of secure defaults among the leading issues.

16.3 Operational Technology (OT), ICS, and SCADA

Operational technology is the hardware and software that monitors and controls physical processes — power grids, water treatment, manufacturing lines, pipelines. It includes Industrial Control Systems (ICS), SCADA (Supervisory Control and Data Acquisition) systems, and PLCs (Programmable Logic Controllers). Security here is different in a fundamental way:

	IT priority	OT priority
Top concern	Confidentiality (protect data)	Safety and availability (keep the physical process running safely)
Downtime	Often tolerable for patching	Can be dangerous or hugely costly — patching is hard
Systems	Frequently updated	Often legacy, long-lived, sometimes decades old

In OT, a security failure can cause physical harm — flooding, blackouts, explosions — so safety outranks the usual CIA ordering. Historically OT relied on isolation ("air gaps") and obscurity, but increasing connectivity (and the convergence of IT and OT) has exposed these systems. Frameworks like the Purdue model describe segmentation levels between enterprise IT and control processes, and specialized guidance (and standards such as IEC 62443) govern OT security.

16.4 Defenses across all three

• Mobile — encrypt device data, enforce TLS with certificate validation, use MDM, restrict sideloading/rooting on managed devices, minimize permissions, and vet third-party code.
• IoT — change default credentials, segment IoT onto isolated networks, disable unnecessary services, keep firmware updated, and choose vendors with a real security track record.
• OT — segment rigorously (IT/OT separation), apply strict access control and monitoring, use OT-aware security tools, plan patching carefully around safety, and follow OT-specific frameworks.

17.1 The service models

Model	You get	Examples
IaaS (Infrastructure as a Service)	Virtual machines, storage, networking — you manage the OS and up	Cloud compute and storage services
PaaS (Platform as a Service)	A managed platform to deploy apps — the provider handles the OS/runtime	Managed app platforms and databases
SaaS (Software as a Service)	A finished application delivered over the internet	Web-based email, CRM, collaboration suites

17.2 The shared responsibility model — the concept that trips everyone up

In the cloud, security is split between the provider and the customer, and exactly where the line falls depends on the service model. The provider secures the cloud infrastructure ("security of the cloud"); the customer secures what they put in it — their data, configurations, access control, and (for IaaS) operating systems and applications ("security in the cloud"). The most common cause of cloud breaches is a customer misunderstanding this line and leaving something they were responsible for exposed.

17.3 The most common cloud breaches

• Misconfiguration — publicly exposed storage buckets, over-permissive network rules, and databases open to the internet. This is the number-one cause and it is almost always the customer's mistake.
• Weak identity and access management (IAM) — over-privileged accounts, no MFA, and unused credentials. In the cloud, a leaked key can grant sweeping access.
• Exposed secrets — API keys and credentials committed to code repositories or embedded in apps.
• Insecure APIs — cloud is API-driven, and poorly secured APIs are a prime target.
• Insufficient logging/monitoring — cloud activity that is never reviewed.

17.4 Identity is the new perimeter

In traditional networks, the firewall was the perimeter. In the cloud, resources are reached over the internet via APIs authenticated by identity, so who can do what becomes the primary control. This is why cloud security obsesses over IAM: enforce least privilege, require MFA (especially for administrative and root accounts), avoid long-lived static keys in favour of short-lived credentials and roles, and continuously review permissions. A single over-privileged, exposed credential can compromise an entire environment.

17.5 Containers and orchestration

Containers (popularized by Docker) package an application with its dependencies into a lightweight, portable unit that shares the host operating system kernel. Kubernetes orchestrates containers at scale. Security considerations:

• Image security — containers built from vulnerable or untrusted base images inherit their flaws; scan images and use trusted, minimal bases.
• Secrets management — do not bake credentials into images; use a secrets manager.
• Least privilege — avoid running containers as root and drop unnecessary capabilities; a container escape is far worse when it starts privileged.
• Isolation — containers share the host kernel, so isolation is weaker than full virtual machines; kernel vulnerabilities can enable escape.
• Orchestration hardening — Kubernetes has many components and defaults that need securing (network policies, RBAC, restricting the API server).

17.6 Serverless and beyond

Serverless functions run code on demand without managing servers; the provider handles infrastructure. This shrinks some responsibilities but introduces new ones — function permissions, event-source security, and dependency risks. Across all cloud-native patterns, the recurring lessons are the same: least-privilege identity, correct configuration, secrets hygiene, and thorough logging.

17.7 Cloud defenses

• Cloud Security Posture Management (CSPM) tools continuously detect misconfigurations.
• Strong IAM — least privilege, MFA, short-lived credentials, no unused keys.
• Encryption of data at rest and in transit, with sound key management.
• Network controls — private networking, security groups, and not exposing services unnecessarily.
• Comprehensive logging and monitoring of the cloud control plane, with alerting.
• Infrastructure as Code with security scanning so misconfigurations are caught before deployment.

18.1 What cryptography provides

Cryptography is the science of protecting information using mathematics. Properly applied, it delivers four goals — you have met them before as extensions of the CIA triad:

Goal	Guarantee	Primary tool
Confidentiality	Only authorized parties can read the data	Encryption
Integrity	The data has not been altered	Hashing, MACs
Authentication	The parties are who they claim to be	Digital signatures, certificates
Non-repudiation	A party cannot deny having sent something	Digital signatures

18.2 Symmetric encryption

Symmetric cryptography uses the same secret key to encrypt and decrypt. It is fast and ideal for bulk data. The modern standard is AES (Advanced Encryption Standard), widely used with strong key sizes. The challenge is key distribution: both parties need the same secret key, and getting it to them securely is hard — which is exactly the problem asymmetric cryptography solves.

A note on modes: block ciphers like AES process fixed-size blocks and must be used in a secure mode of operation. Authenticated modes (such as GCM) provide both confidentiality and integrity together and are preferred; older modes used incorrectly (like ECB) leak patterns and should be avoided.

18.3 Asymmetric (public-key) encryption

Asymmetric cryptography uses a mathematically linked key pair: a public key that can be shared freely and a private key that is kept secret. What one key locks, only the other can unlock. This enables two powerful patterns:

• Encryption — anyone can encrypt to you using your public key; only your private key can decrypt. This solves key distribution.
• Digital signatures — you sign with your private key; anyone can verify with your public key, proving it came from you and was not altered.

Common algorithms include RSA (based on the difficulty of factoring large numbers), Elliptic Curve Cryptography (ECC) (similar strength with much smaller keys, so it is efficient), and Diffie–Hellman (DH) (a method for two parties to agree a shared secret over an insecure channel). Asymmetric operations are slower than symmetric, so in practice systems combine them.

18.4 Hashing, MACs, and signatures

• Hash functions (e.g. the SHA-2 and SHA-3 families) take any input and produce a fixed-size, unique-looking digest. They are one-way (you cannot reverse them) and collision-resistant (hard to find two inputs with the same hash). They verify integrity: if the data changes, the hash changes. Note MD5 and SHA-1 are broken for security use.
• MAC / HMAC — a hash combined with a secret key, proving both integrity and that the message came from someone holding the key.
• Digital signature — a hash of the message encrypted with the sender's private key. Verifying with the public key proves integrity, authentication, and non-repudiation at once.

18.5 Public Key Infrastructure (PKI) and certificates

Public-key cryptography has one gap: how do you know a public key really belongs to the party you think? If an attacker can substitute their own public key, they can impersonate anyone. PKI solves this with digital certificates and Certificate Authorities (CAs):

• A certificate binds an identity (e.g. a website domain) to a public key.
• A trusted Certificate Authority verifies the identity and digitally signs the certificate, vouching for it.
• Your browser/OS ships with a list of trusted root CAs. It trusts certificates that chain up to one of them — the chain of trust.

When you connect to an HTTPS site, it presents its certificate; your browser checks the CA's signature, the validity dates, and that the certificate matches the domain. If everything checks out, trust is established without you and the website ever having met. If it fails, you see the certificate warning that (as earlier modules stressed) you must never blindly bypass. Certificates can also be revoked (via CRLs or OCSP) if a private key is compromised.

18.6 Attacks and best practices

Cryptography fails in practice mostly through implementation and key management, not broken math:

• Weak or outdated algorithms (WEP, DES, MD5, SHA-1) — use current standards.
• Poor key management — hardcoded keys, keys stored with the data, keys never rotated. Protect keys (hardware security modules where warranted), rotate them, and separate them from data.
• Weak randomness — predictable keys/IVs from poor random number generation.
• Man-in-the-middle on unauthenticated exchanges — why authentication (certificates) matters.
• Reusing nonces/IVs or using insecure modes.

19.1 Firewalls — the traffic gatekeeper

A firewall controls traffic between networks based on rules, forming a boundary between trusted and untrusted zones. They have evolved considerably:

Type	Inspects
Packet-filtering	Individual packets by IP, port, and protocol (no memory of connections)
Stateful inspection	Tracks connection state, allowing return traffic for established sessions
Proxy / application gateway	Terminates and inspects traffic at the application layer on behalf of clients
Next-Generation Firewall (NGFW)	Adds deep packet inspection, application awareness, and integrated intrusion prevention
Web Application Firewall (WAF)	Specifically filters HTTP(S) to protect web apps from attacks like injection and XSS

A firewall is necessary but not sufficient: it controls what may connect, but well-formed malicious traffic on allowed ports (e.g. an attack over HTTPS) can pass through, which is why detection layers are needed behind it.

19.2 IDS vs. IPS

Intrusion detection and prevention systems watch traffic (or hosts) for signs of attack:

• IDS (Intrusion Detection System) — detects and alerts on suspicious activity. It is passive: it warns but does not block, so it does not risk dropping legitimate traffic.
• IPS (Intrusion Prevention System) — sits inline and can actively block detected attacks in real time. More protective, but a false positive can disrupt legitimate traffic.

By placement, they are either network-based (NIDS/NIPS) — monitoring network traffic at a chokepoint — or host-based (HIDS/HIPS) — monitoring activity on an individual system (files, processes, logs).

19.3 Detection methods

Method	How it decides	Trade-off
Signature-based	Matches traffic against a database of known attack patterns	Accurate for known threats; blind to brand-new (zero-day) attacks
Anomaly-based	Learns a baseline of "normal" and flags deviations	Can catch novel attacks; produces more false positives

Mature defenses combine both, increasingly augmented by machine learning and threat-intelligence feeds.

19.4 How attackers try to evade detection (conceptual)

Understanding these makes you configure detection better:

• Fragmentation — splitting an attack across packets hoping the sensor does not reassemble them the way the target does. Defense: sensors that fully reassemble traffic.
• Encryption / tunneling — hiding malicious traffic inside encrypted or allowed channels (e.g. DNS or HTTPS tunneling). Defense: TLS inspection where appropriate, DNS monitoring, egress filtering.
• Timing / "low and slow" — acting slowly to stay under thresholds. Defense: long-window behavioural analytics.
• Obfuscation / encoding — disguising payloads to dodge signatures. Defense: normalization and behaviour-based detection.
• Living off the land — using legitimate tools so activity blends in. Defense: behavioural baselining and correlation.

The recurring lesson: signatures alone are evadable, so defense in depth plus behavioural detection and good logging is essential.

19.5 Honeypots and honeynets — deception

A honeypot is a decoy system deliberately deployed to attract attackers. Because no legitimate user should ever touch it, any interaction is inherently suspicious — making honeypots excellent, low-false-positive detectors and a way to study attacker behaviour. A honeynet is a whole network of honeypots. Related decoys (honey tokens, honey credentials) are fake data planted so that its use signals a breach. Deception flips the economics: the attacker cannot easily tell real from fake, and touching the fake gives them away.

19.6 SIEM and the SOC — tying it together

Individual tools produce floods of events. A SIEM (Security Information and Event Management) platform aggregates logs and alerts from across the environment (firewalls, IDS/IPS, endpoints, servers, cloud), correlates them to spot patterns no single device would see, and drives alerting and investigation. A SOC (Security Operations Center) is the team and process that monitors the SIEM, triages alerts, hunts for threats, and responds to incidents around the clock. Together they turn scattered signals into detection and response — the operational heart of a mature defense.

20.1 Methodologies and standards

Professional testing is structured, not ad hoc. Several frameworks guide it:

• PTES (Penetration Testing Execution Standard) — a widely referenced end-to-end methodology.
• OSSTMM (Open Source Security Testing Methodology Manual) — a rigorous, metrics-driven approach.
• NIST SP 800-115 — the U.S. government's technical guide to security testing.
• OWASP Testing Guide / Web Security Testing Guide — the reference for web application testing.
• MITRE ATT&CK — a knowledge base of adversary tactics and techniques used to plan and map testing.

These bring consistency, completeness, and a shared language, so results are repeatable and comparable.

20.2 The penetration-testing lifecycle

Whatever the framework, a professional engagement follows the same arc — and you will recognize the middle stages as the phases taught throughout this course, now wrapped in the professional scaffolding of authorization and reporting:

1. Pre-engagement — the most important non-technical step. Define scope, goals, and constraints; agree the rules of engagement; and obtain written authorization. Nothing technical begins without this.
2. Reconnaissance / intelligence gathering — collect information about the target (passive and active).
3. Scanning & enumeration — map hosts, services, and potential weaknesses.
4. Vulnerability analysis — identify and validate exploitable weaknesses.
5. Exploitation — attempt to gain access, confirming which weaknesses are real and their impact (within scope).
6. Post-exploitation — assess the depth of access: what data is reachable, whether privileges can be escalated, and whether the tester can pivot to other systems. This demonstrates true business impact.
7. Reporting — document everything and deliver actionable findings.
8. Remediation support & retest — help fix the issues and verify the fixes work.

20.3 The report — the real deliverable

Clients do not pay for access; they pay for a report that helps them get more secure. A strong report has:

• Executive summary — the business-level picture and overall risk, written for non-technical leadership.
• Methodology & scope — what was tested and how.
• Findings — each with a clear description, risk rating (severity + likelihood, often CVSS-based), evidence/proof of concept, and business impact.
• Remediation guidance — specific, prioritized, actionable steps to fix each issue.
• Conclusion — strategic recommendations and positive notes on what was done well.

Two things separate a good tester from a great one: prioritization (helping the client fix what matters most first) and clear communication (findings a developer can act on and an executive can understand). A brilliant technical finding that no one can understand or act on has little value.

20.4 Careers in ethical hacking

Security offers many paths, and skills transfer across them:

• Penetration Tester / Red Teamer — simulates attacks (red team engagements are broader, stealthier, goal-driven adversary simulations).
• Security Analyst / SOC Analyst (Blue Team) — monitors, detects, and responds.
• Security Engineer / Architect — builds and hardens secure systems.
• Application Security Engineer — secures software and the development pipeline.
• Incident Responder / Threat Hunter / Forensics — investigates and contains attacks.
• GRC / Auditor — governance, risk, and compliance (a natural bridge for those from audit and finance backgrounds).
• Purple Team — blends offensive and defensive to improve detection.

20.5 Certifications — a practical map

Level	Certifications	Focus
Foundational	CompTIA Security+, Network+	Core security and networking concepts
Intermediate / hands-on	CompTIA PenTest+, eLearnSecurity eJPT, CEH	Practical testing skills and broad coverage
Advanced / practical	OSCP (PEN-200), GIAC GPEN/GWAPT	Rigorous, hands-on exploitation (OSCP is famously demanding)
Management / governance	CISSP, CISM, CISA	Security leadership, management, and audit

Certifications open doors, but demonstrated skill matters more. Practical, hands-on certs (like OSCP) are especially respected because they require actually compromising machines under exam conditions.

20.6 Build a home lab — learn by doing safely

You cannot become skilled by reading alone, and you must never practise on systems you do not own or lack permission to test. The solution is a home lab:

• Virtualization — run isolated virtual machines on your own computer (e.g. with VirtualBox or VMware) on a host-only network so nothing leaks out.
• Attacker VM — a security-focused Linux distribution loaded with tools.
• Deliberately vulnerable targets — practice machines and apps built for learning, such as Metasploitable, the OWASP-related vulnerable web apps (DVWA, Juice Shop, bWAPP), and downloadable vulnerable VMs.
• Online legal platforms — hands-on labs like TryHackMe, Hack The Box, and PortSwigger's Web Security Academy provide guided, legal targets and challenges.

20.7 Course wrap-up

You have travelled from the CIA triad and the law, through networking, reconnaissance, scanning, system and web attacks, malware, social engineering, wireless, mobile, IoT, OT, cloud, cryptography, and defensive operations, to the professional lifecycle that ties it together. The consistent themes: understand attacks in order to defend, always operate ethically and with authorization, apply defense in depth, and never stop learning. Use these skills to protect people and organizations — that is what makes hacking ethical.