Cybersecurity Bootcamp — Phase 1, Week 2

OSI Model & TCP/IP — The Network Bible

THEORY Subnetting · CIDR · IP Addressing · Protocol Stack

WEEK 2 PROGRESS — DAY 8 OF 14

📡

Why this matters for hacking: Every attack is a network event. Every packet you send, capture, or forge has a home on the OSI stack. When you do an ARP spoof, you're attacking Layer 2. When you exploit a web app, you're working Layer 7. You cannot understand attack tools without understanding the layer they operate at.

// 8.1 — THE OSI MODEL

7-Layer Reference Model

OSI (Open Systems Interconnection) is a conceptual framework describing how data travels from an application on one computer to an application on another. Each layer has a specific job and talks to the layers directly above and below it.

The mnemonic: "Please Do Not Throw Sausage Pizza Away" → Physical, Data Link, Network, Transport, Session, Presentation, Application.

7
Application
HTTP, DNS, FTP, SMTP, SSH — what users interact with SQL Injection · XSS
6
Presentation
Encryption, encoding, compression — SSL/TLS lives here SSL Stripping
5
Session
Managing connections between apps — session tokens Session Hijack
4
Transport
TCP/UDP — ports, reliability, flow control SYN Flood · Port Scan
3
Network
IP addressing, routing — packets travel here IP Spoofing · ICMP Flood
2
Data Link
MAC addresses, frames, switches — LAN level ARP Poison · MAC Flood
1
Physical
Cables, wireless signals, hardware bits Cable Tap · Jamming

💡

Attack-mapping drill: When you learn any new attack, immediately ask: "What OSI layer does this operate at?" A port scanner probes Layer 4 (Transport). Wireshark captures at Layer 2. A phishing email exploits the human at Layer 8 (the joke layer not in OSI — the human layer). This mental habit will make you a better analyst.

// 8.2 — TCP/IP: THE REAL PROTOCOL STACK

TCP/IP vs OSI

While OSI is a theoretical model, TCP/IP is what the internet actually uses. It collapses the 7 OSI layers into 4. TCP/IP is what you'll interact with in Wireshark, nmap, and every exploit.

TCP/IP LAYER	OSI EQUIVALENT	KEY PROTOCOLS	SECURITY TOOLS OPERATING HERE
Application	Layers 5, 6, 7	HTTP, DNS, FTP, SSH, SMTP, DHCP	Burp Suite, sqlmap, curl, nikto
Transport	Layer 4	TCP, UDP	nmap (port scan), netcat, hping3
Internet	Layer 3	IP, ICMP, ARP	nmap (host discovery), ping, traceroute
Network Access	Layers 1, 2	Ethernet, Wi-Fi (802.11), MAC	Wireshark, aircrack-ng, arpspoof

// 8.3 — THE TCP THREE-WAY HANDSHAKE

How TCP Connections Are Established

Every TCP connection starts with a 3-way handshake. Understanding this is fundamental to understanding port scanning, SYN floods, and TCP session hijacking.

TCP HANDSHAKE — WHAT HAPPENS WHEN YOU CONNECT

CLIENT SERVER │ │ SYN ──────────────────────────────► │ "I want to connect; my seq# is 1000" │ │ │ ◄────────────────────────────── SYN-ACK "OK, my seq# is 5000, your ACK# is 1001" │ │ ACK ──────────────────────────────► │ "Got it. Your ACK# is 5001. Connection established!" │ │ ═══════════════ DATA FLOWS ════════════════ # ATTACK: SYN Flood (DoS at Layer 4) # Attacker sends thousands of SYN packets, never completes ACK # Server allocates resources waiting for ACKs → runs out of memory → crashes # ATTACK: Nmap SYN Scan (-sS) # Sends SYN → gets SYN-ACK (port open!) → sends RST (never completes handshake) # Faster and stealthier than a full connect scan

// 8.4 — IP ADDRESSING & SUBNETTING

IPv4 Addressing

An IPv4 address is 32 bits written as 4 octets (e.g., 192.168.1.100). The subnet mask defines which part is the network and which is the host. As a pentester, you must calculate subnets quickly — they define your target scope.

CLASS	RANGE	DEFAULT MASK	HOSTS	USE
A	1.0.0.0 – 126.0.0.0	/8 (255.0.0.0)	16,777,214	Large enterprises, ISPs
B	128.0.0.0 – 191.255.0.0	/16 (255.255.0.0)	65,534	Medium organizations
C	192.0.0.0 – 223.255.255.0	/24 (255.255.255.0)	254	Small networks — most common

Private vs Public IP Ranges (Critical for Recon)

RANGE	CIDR	PRIVATE/PUBLIC	YOU'LL SEE THIS IN...
10.0.0.0 – 10.255.255.255	/8	Private	Large internal networks, VPNs, data centers
172.16.0.0 – 172.31.255.255	/12	Private	Corporate networks
192.168.0.0 – 192.168.255.255	/16	Private	Home routers, small office, your lab
127.0.0.1	/8	Loopback	localhost — always refers to the machine itself
Everything else	—	Public	Routable on the internet — attackable from anywhere

🖥️ Interactive Subnet Calculator

// DAY 8 — QUIZ

An nmap SYN scan sends a SYN packet and receives a SYN-ACK. It then immediately sends a RST. Which OSI layer is nmap operating at for port discovery, and why is this scan considered "stealthy"?

A Layer 7 — because it mimics normal application traffic

B Layer 4 — it never completes the TCP handshake so no full connection is logged

C Layer 3 — it uses raw IP packets

D Layer 2 — it uses Ethernet frames directly

Key Protocols & Their Weaknesses

THEORYLAB DNS · DHCP · ARP · HTTP/S · FTP · SMTP

WEEK 2 PROGRESS — DAY 9 OF 14

⚡

Attacker's mindset: Every protocol was designed for functionality, not security. Most were invented in the 1970s–90s when the internet was a trusted academic network. The security holes aren't bugs — they're architectural decisions that made sense at the time. Your job is to understand the design well enough to exploit the gaps.

// 9.1 — DNS: THE INTERNET'S PHONE BOOK

How DNS Resolution Works

DNS (Domain Name System) translates human-readable names like google.com into IP addresses like 142.250.80.46. It's hierarchical, distributed, and fundamentally unauthenticated — anyone on your network can lie to you about what IP a domain resolves to.

DNS RESOLUTION — STEP BY STEP

You type: https://bank.com in your browser Step 1: Browser checks its own DNS cache → not found Step 2: Ask OS resolver → checks /etc/hosts → not found Step 3: Ask your configured DNS server (e.g., 8.8.8.8) Step 4: DNS server checks its cache → not found Step 5: DNS server asks Root Server → "Go ask .com TLD servers" Step 6: Ask .com TLD server → "Go ask bank.com's authoritative NS" Step 7: Ask authoritative nameserver → "bank.com = 1.2.3.4" Step 8: Response cached, returned to browser → browser connects to 1.2.3.4 # ATTACK: DNS Spoofing / Cache Poisoning # Attacker poisons a DNS cache so bank.com → attacker's IP # Victim never knows — URL looks correct, but they're on a fake site # DNS Recon commands you'll use daily: $ nslookup bank.com $ dig bank.com ANY # Full DNS record dump $ dig +short MX bank.com # Mail servers (useful for phishing recon) $ dig -x 1.2.3.4 # Reverse DNS lookup $ host -t AXFR bank.com ns1.bank.com # Zone transfer attempt (often succeeds!)

🔥

DNS Zone Transfer Attack: If a DNS server is misconfigured to allow zone transfers (AXFR requests) from anyone, an attacker can dump the entire DNS zone — getting a full list of every subdomain, server, and internal hostname for a company. This is free recon gold. Always test: dig AXFR @ns1.target.com target.com

// 9.2 — ARP: THE LOCAL NETWORK LIAR

ARP — Address Resolution Protocol

ARP translates IP addresses to MAC addresses on a local network. "Who has IP 192.168.1.1? Tell me your MAC address so I can send frames to you." The critical flaw: ARP has no authentication. Any device can claim any IP. This is the foundation of Man-in-the-Middle attacks on local networks.

ARP POISONING ATTACK — HOW IT WORKS

LEGITIMATE SCENARIO: Victim (192.168.1.5) wants to reach Gateway (192.168.1.1) ARP Request: "Who has 192.168.1.1?" ARP Reply from router: "That's me! My MAC is AA:BB:CC:DD:EE:FF" ARP POISON ATTACK: Attacker sends fake ARP replies to BOTH victim and gateway: → To Victim: "192.168.1.1 is at MY MAC (attacker)" → To Gateway: "192.168.1.5 is at MY MAC (attacker)" Now ALL traffic flows: Victim → Attacker → Gateway Attacker is in the middle — can read, modify, or drop all packets # Execute ARP poison (on your lab only!): $ echo 1 > /proc/sys/net/ipv4/ip_forward # Enable IP forwarding (don't drop packets) $ arpspoof -i eth0 -t 192.168.56.101 192.168.56.1 # Poison victim $ arpspoof -i eth0 -t 192.168.56.1 192.168.56.101 # Poison gateway # Now run Wireshark — you see ALL victim's traffic # Check your ARP table: $ arp -n Address HWtype HWaddress Iface 192.168.56.1 ether 08:00:27:aa:bb:cc eth0 192.168.56.101 ether 08:00:27:dd:ee:ff eth0

// 9.3 — HTTP vs HTTPS

HTTP

TCP Port 80 · Plaintext

HyperText Transfer Protocol. All data — including passwords, cookies, form data — is sent in plaintext. Anyone on the same network can read every byte.

Attacks: Credential sniffing, session hijacking, content injection, MITM modification of pages in transit

HTTPS

TCP Port 443 · TLS Encrypted

HTTP over TLS. Data is encrypted end-to-end. Even if captured, encrypted traffic reveals only the destination IP, not content. Certificates prove server identity.

Attacks: SSL stripping (downgrade to HTTP), certificate spoofing with fake CA, TLS protocol vulnerabilities (BEAST, POODLE, Heartbleed)

FTP

TCP Port 21 (control) · 20 (data)

File Transfer Protocol. Credentials and data sent in plaintext. Anonymous FTP login (username: anonymous) is often enabled and exposes files publicly.

Attacks: Credential sniffing, anonymous login, FTP bounce attack, brute-force login

SMTP

TCP Port 25 / 587 / 465

Simple Mail Transfer Protocol. Sends email. The "From" field is completely unauthenticated — trivially spoofed. Open relays allow anyone to send email through your server.

Attacks: Email spoofing (phishing), open relay abuse, header injection, SMTP user enumeration (VRFY/EXPN)

DHCP

UDP Port 67/68

Auto-assigns IP addresses. When a device joins a network, it broadcasts "DHCP Discover" — whoever replies first with DHCP Offer wins. No authentication.

Attacks: Rogue DHCP server (attacker responds first, assigns own gateway → MITM entire network), DHCP starvation (exhaust IP pool with fake requests)

SSH

TCP Port 22 · Encrypted

Secure Shell. Encrypted terminal access. Replaced Telnet (plaintext). Key-based auth is far stronger than password-based. Configuration errors are the main weakness.

Attacks: Brute-force passwords, weak key algorithms, SSH tunneling (legitimate but used to bypass firewalls), exposed private keys in git repos

// DAY 9 — QUIZ

You're on the same Wi-Fi as a colleague who logs into an internal system over HTTP. Using Wireshark, you can see their username and password in plaintext. They then switch to HTTPS. What changes?

A Nothing — you can still read all their data with Wireshark

B Their packets disappear from Wireshark completely

C You can still capture packets and see the destination, but payload content is encrypted and unreadable

D HTTPS uses port 443 which is blocked by default network policies

// DAY 9 — LAB

Lab Tasks

Run dig google.com ANY — identify all record types (A, AAAA, MX, NS, TXT). What does each mean?
Try a zone transfer against zonetransfer.me — this is a deliberately vulnerable DNS server for learning: dig AXFR @nsztm1.digi.ninja zonetransfer.me
Check your ARP table: arp -n. Identify your gateway's MAC address.
Use curl to see HTTP headers: curl -I http://metasploitable.lab/ vs curl -I https://google.com
Connect to Metasploitable's FTP: ftp 192.168.56.101 — try username anonymous with any password. What files are exposed?

Wireshark — Packet Analysis Mastery

TOOLLAB Capture · Filter · HTTP · DNS · TCP Handshakes

WEEK 2 PROGRESS — DAY 10 OF 14

🦈

Wireshark is the world's most widely used network protocol analyzer. It captures every packet on a network interface and lets you dissect it layer by layer. Defenders use it to find attacks. Attackers use it during MITM to harvest credentials. Forensics teams use it to reconstruct incidents. You must be fluent.

// 10.1 — SIMULATED WIRESHARK CAPTURE

This is what a real Wireshark capture looks like during a typical browsing session. Click any row to understand what you're seeing.

📦 Wireshark — Capture: eth0 — 47 packets captured

No.	Time	Source	Destination	Protocol	Length	Info
1	0.000	192.168.1.100	Broadcast	ARP	42	Who has 192.168.1.1? Tell 192.168.1.100
2	0.001	192.168.1.1	192.168.1.100	ARP	42	192.168.1.1 is at 08:00:27:aa:bb:cc
3	0.012	192.168.1.100	8.8.8.8	DNS	73	Standard query 0x1a2b A bank.com
4	0.034	8.8.8.8	192.168.1.100	DNS	89	Standard query response A 1.2.3.4
5	0.041	192.168.1.100	1.2.3.4	TCP	66	52341 → 443 [SYN] Seq=0 Win=65535
6	0.052	1.2.3.4	192.168.1.100	TCP	66	443 → 52341 [SYN, ACK] Seq=0 Ack=1
7	0.053	192.168.1.100	1.2.3.4	TCP	54	52341 → 443 [ACK] Seq=1 Ack=1
8	0.054	192.168.1.100	1.2.3.4	TLSv1.3	320	Client Hello (SNI=bank.com)
9	0.071	1.2.3.4	192.168.1.100	TLSv1.3	1448	Server Hello, Certificate
12	0.120	192.168.1.100	10.0.0.5	HTTP	421	GET /login.php HTTP/1.1 (PLAINTEXT!)
14	0.145	192.168.1.100	10.0.0.5	HTTP	612	POST /login.php username=admin&password=hunter2
15	0.201	10.0.0.5	192.168.1.100	HTTP	890	HTTP/1.1 200 OK (text/html)

🚨

Look at rows 12 and 14: An HTTP POST request containing username=admin&password=hunter2 — fully readable in Wireshark. This is a real credential capture. Anyone on the same network segment running Wireshark would see this. This is why HTTP login forms are catastrophically insecure.

// 10.2 — WIRESHARK DISPLAY FILTERS (MEMORIZE THESE)

WIRESHARK FILTERS — THE ONES YOU'LL USE EVERY DAY

# ── PROTOCOL FILTERS ───────────────────────────────────────── http # Show only HTTP traffic dns # Show only DNS queries/responses tcp # TCP traffic only arp # ARP packets only tls # TLS/HTTPS traffic icmp # Ping traffic # ── IP FILTERS ─────────────────────────────────────────────── ip.addr == 192.168.56.101 # Any traffic to/from this IP ip.src == 192.168.56.100 # Traffic FROM this IP only ip.dst == 8.8.8.8 # Traffic TO this IP only !(ip.addr == 192.168.56.1) # Exclude gateway traffic # ── PORT FILTERS ───────────────────────────────────────────── tcp.port == 80 # HTTP tcp.port == 443 # HTTPS tcp.port == 22 # SSH tcp.dstport == 21 # FTP connections outbound # ── CONTENT FILTERS ────────────────────────────────────────── http.request.method == "POST" # Form submissions (login forms!) http contains "password" # Packets with "password" in payload dns.qry.name contains "bank" # DNS queries for bank-related domains http.response.code == 200 # Successful HTTP responses # ── TCP FLAG FILTERS ───────────────────────────────────────── tcp.flags.syn == 1 # SYN packets (connection attempts) tcp.flags.reset == 1 # RST packets (abrupt termination) tcp.flags == 0x002 # Only SYN (no ACK) — port scans! # ── COMBINED (most useful in real work) ────────────────────── http.request.method == "POST" and http contains "pass" ip.src == 192.168.56.101 and tcp.port == 80 dns and ip.src != 8.8.8.8 # DNS from unexpected servers

// 10.3 — READING A PACKET IN DETAIL

Anatomy of an HTTP GET Request Packet

When you click on a packet in Wireshark, you see all layers expanded. This is OSI made visible.

ETHERNET II

Layer 2

Src MAC: AA:BB:CC
Dst MAC: 08:00:27

IPv4

Layer 3

Src: 192.168.1.100
Dst: 10.0.0.5
TTL: 64

TCP

Layer 4

SrcPort: 52341
DstPort: 80
Flags: PSH ACK

HTTP

Layer 7

GET /login HTTP/1.1
Host: 10.0.0.5
Cookie: session=abc123

DATA

Payload

username=admin
&password=hunter2

// DAY 10 — LAB

Lab: Live Packet Capture on Your Kali VM

Open Wireshark on Kali. Start capture on eth0.
From the terminal: ping 192.168.56.101. In Wireshark, filter icmp. See the echo requests and replies.
Open a browser to http://192.168.56.101 (Metasploitable web). Filter http. Find the HTTP GET request. Expand all layers.
Filter tcp.flags == 0x002 while running nmap -sS 192.168.56.101 in another terminal. You'll see the SYN flood from nmap — this is what a port scan looks like on the wire.
Filter arp. What ARP requests do you see? Who is the network gateway?
Challenge: Download the sample PCAP file from https://wiki.wireshark.org/SampleCaptures — open it in Wireshark and answer: what protocols are present? What IPs are communicating?

Firewalls & IDS/IPS

THEORYLAB iptables · nftables · Snort · Detection Rules

WEEK 2 PROGRESS — DAY 11 OF 14

🧱

Attacker perspective + defender perspective: You need to understand firewalls both to build effective defenses and to bypass them during pentesting. A firewall that blocks port 80 outbound? Attacker tunnels C2 traffic over DNS or HTTPS. You must think both ways.

// 11.1 — FIREWALL TYPES

TYPE	WHAT IT INSPECTS	EXAMPLE	BYPASS TECHNIQUE
Packet Filter	IP, port, protocol headers only. Stateless — each packet judged independently.	Basic router ACLs, early iptables rules	Fragment packets to split headers across multiple packets
Stateful Firewall	Tracks connection state (SYN/ESTABLISHED/CLOSE). Knows if packet is part of legitimate session.	iptables with conntrack, Windows Firewall	Hijack existing established sessions, use allowed ports for tunneling
Application Firewall (WAF)	Inspects Layer 7 payload — can detect SQL injection patterns, XSS, malformed HTTP	ModSecurity, Cloudflare WAF, AWS WAF	Encoding bypass (URL encoding, Unicode, case variation), splitting payloads
NGFW (Next-Gen)	Deep packet inspection, application awareness, user identity, SSL inspection	Palo Alto, Fortinet, Check Point	Use legitimate applications (Teams, Slack) for C2; encrypt custom protocols

// 11.2 — iptables MASTERY

iptables — LINUX FIREWALL COMMANDS

# View current rules (the first thing you check on any system) $ iptables -L -n -v # -n = numeric (don't resolve DNS), -v = verbose $ iptables -L -n -v --line-numbers # with rule numbers for deletion # Three default chains: INPUT → Packets DESTINED for this machine OUTPUT → Packets ORIGINATING from this machine FORWARD → Packets PASSING THROUGH this machine (router) # ── ALLOW rules ────────────────────────────────────────────── $ iptables -A INPUT -p tcp --dport 22 -j ACCEPT # Allow SSH in $ iptables -A INPUT -p tcp --dport 80 -j ACCEPT # Allow HTTP in $ iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # ── BLOCK rules ────────────────────────────────────────────── $ iptables -A INPUT -s 10.0.0.5 -j DROP # Block specific attacker IP $ iptables -A INPUT -p tcp --dport 23 -j DROP # Block Telnet # ── DEFAULT POLICY (crucial for security) ──────────────────── $ iptables -P INPUT DROP # Default: DROP all incoming (whitelist approach) $ iptables -P OUTPUT ACCEPT # Default: allow all outgoing $ iptables -P FORWARD DROP # Default: don't route # ATTACKER RECON: Check iptables on a compromised machine # iptables rules tell you what's protected and what ports are open # They also tell you about network topology (FORWARD rules reveal routing) # Save and restore rules: $ iptables-save > /etc/iptables/rules.v4 $ iptables-restore < /etc/iptables/rules.v4

// 11.3 — IDS vs IPS: DETECTION VS PREVENTION

IDS — Intrusion Detection System

🔍 Detects & Alerts

Monitors network/system activity and generates alerts when suspicious patterns are detected. Does NOT block — it only watches and reports. Like a security camera.

Examples: Snort (detection mode), Zeek/Bro, OSSEC

IPS — Intrusion Prevention System

🛡️ Detects & Blocks

Sits inline in the network traffic path. Detects AND actively drops/blocks malicious packets in real-time. Like a security guard who can also tackle intruders.

Examples: Snort (inline mode), Suricata, Fail2ban

// 11.4 — SNORT RULES (How Detection Works)

SNORT RULE ANATOMY

# RULE STRUCTURE: # action proto src_ip src_port direction dst_ip dst_port (options) alert tcp any any -> any 22 (msg:"SSH Brute Force Attempt"; threshold: type both, track by_src, count 5, seconds 60; sid:1000001;) Breaking this down: alert → generate an alert (IDS) or block (IPS) tcp → TCP protocol any any → from any source IP and port -> → direction (→ means to destination) any 22 → to any IP, port 22 (SSH) msg: → human-readable alert message threshold: → only alert if 5+ attempts in 60 seconds (reduce noise) sid: → unique rule identifier # More example rules: alert tcp any any -> any 80 (msg:"SQL Injection Attempt"; content:"1=1"; http_uri; sid:1000002;) alert icmp any any -> any any (msg:"Ping Sweep Detected"; threshold: type both, track by_src, count 10, seconds 5; sid:1000003;) alert tcp any any -> any any (msg:"Nmap SYN Scan"; flags:S; threshold: type both, track by_src, count 20, seconds 5; sid:1000004;) # KEY INSIGHT: Attackers who know these rules can craft attacks # that evade them — different encoding, slower scanning, fragmented packets # This is why "defense in depth" matters — no single control stops everything

// DAY 11 — QUIZ

A company blocks all outbound traffic except port 443 (HTTPS). An attacker has compromised an internal machine. How would they most likely establish a C2 (command and control) channel out?

A Use port 80 HTTP — it\'s the standard web port

B Use Metasploit\'s default port 4444

C Tunnel C2 traffic over HTTPS (port 443) — it\'s allowed and encrypted

D Use DNS tunneling over UDP port 53

Cryptography Fundamentals

THEORY Symmetric · Asymmetric · Hashing · TLS/SSL · PKI

WEEK 2 PROGRESS — DAY 12 OF 14

🔐

Why cryptography matters for hackers: You'll crack password hashes with hashcat. You'll bypass TLS misconfiguration. You'll forge JWT tokens. You'll exploit weak random number generators. All of these require understanding what cryptography is supposed to do — so you can recognize when it fails.

// 12.1 — SYMMETRIC ENCRYPTION

One Key, Two Operations

Symmetric encryption uses the same key to both encrypt and decrypt. It's fast, efficient, and used for bulk data encryption. The problem: how do you securely share the key?

ALGORITHM	KEY SIZE	STATUS	ATTACK / NOTES
AES-256	256-bit	SECURE ✓	Gold standard. Used in TLS, disk encryption, VPNs. Brute-force: computationally infeasible.
AES-128	128-bit	SECURE ✓	Still secure. Faster than AES-256. Most web TLS uses this.
DES	56-bit	BROKEN ✗	Cracked in 22 hours in 1998. Never use. Still found in legacy systems.
3DES	112-bit effective	DEPRECATED	Vulnerable to SWEET32 attack. Being phased out. Still in some enterprise.
RC4	Variable	BROKEN ✗	Used to be in WEP Wi-Fi (crackable in minutes). Forbidden in TLS since 2015.

// 12.2 — ASYMMETRIC ENCRYPTION (PUBLIC KEY)

Two Keys — The Key Exchange Solution

Asymmetric encryption uses a key pair: a public key (shareable with everyone) and a private key (never shared). What one key encrypts, only the other can decrypt. This solves the key-exchange problem.

HOW ASYMMETRIC CRYPTO WORKS IN PRACTICE

SCENARIO 1: Secure Message to You Alice wants to send you a secret message. You give Alice your PUBLIC KEY (safe to share with anyone). Alice encrypts the message with YOUR PUBLIC KEY. Only YOUR PRIVATE KEY can decrypt it. → Even Alice can't decrypt it after encrypting. SCENARIO 2: Digital Signature (Proving Identity) You sign a document with YOUR PRIVATE KEY. Anyone with YOUR PUBLIC KEY can verify the signature. → Proves the document came from you (only you have the private key). → Used in code signing, TLS certificates, email (S/MIME, PGP). RSA → Most common. Key sizes: 2048 (minimum), 4096 (recommended). Slow. ECDSA → Elliptic curve. Smaller keys, same strength. Used in modern TLS, Bitcoin. Ed25519 → Modern elliptic curve. Very fast. Used in SSH keys (preferred over RSA). # ATTACK: If the private key is exposed, game over. # Common mistakes: # - Committing private keys to GitHub (automated scanners find these in minutes) # - Storing private keys without passphrase protection # - Using weak keys (RSA-512 cracked; RSA-1024 factored)

// 12.3 — HASHING: ONE-WAY FUNCTIONS

Hashing — Not Encryption

A hash function takes input of any size and produces a fixed-length output (digest). It's one-way — you cannot reverse a hash to get the original. This is how passwords are stored: the database stores the hash, never the plaintext.

HASHING IN ACTION — AND CRACKING IT

# Generate hashes of the same password: $ echo -n "password123" | md5sum 482c811da5d5b4bc6d497ffa98491e38 ← MD5 (BROKEN — DO NOT USE) $ echo -n "password123" | sha1sum cbfdac6008f9cab4083784cbd1874f76618d2a97 ← SHA1 (deprecated) $ echo -n "password123" | sha256sum ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f ← SHA-256 (OK for data) # For PASSWORDS, use these (they're slow on purpose): bcrypt → $2b$12$... (work factor = 2^12 = 4096 iterations) Argon2id → Best modern choice. Used by password managers. scrypt → Memory-hard. Resists GPU cracking. PBKDF2 → Used by WPA2, iOS, many web frameworks. # CRACKING: Hashcat — GPU-accelerated hash cracking $ hashcat -m 0 hash.txt rockyou.txt # -m 0 = MD5 $ hashcat -m 1000 ntlm.txt rockyou.txt # -m 1000 = NTLM (Windows) $ hashcat -m 3200 bcrypt.txt rockyou.txt # -m 3200 = bcrypt (SLOW) $ hashcat -m 0 hash.txt -a 3 ?a?a?a?a?a?a # Brute-force all 6-char combos Cracking speed comparison on a single RTX 4090: MD5: 164,000,000,000 hashes/sec → 8-char password cracked in seconds NTLM: 289,000,000,000 hashes/sec → Even faster bcrypt: 184,000 hashes/sec → 8-char password: years to crack

// 12.4 — TLS/SSL & PKI

How HTTPS Actually Works

TLS (Transport Layer Security) combines asymmetric and symmetric encryption. Asymmetric is used to securely exchange a symmetric session key. Then symmetric (AES) handles the bulk data. This is the TLS Handshake.

TLS 1.3 HANDSHAKE (SIMPLIFIED)

1. Client Hello → "I support TLS 1.3, here are my cipher suites, here's my random value" 2. Server Hello → "OK, we'll use TLS_AES_256_GCM_SHA384, here's my certificate" 3. Certificate → Server sends its TLS certificate (signed by a trusted CA) 4. Client verifies → Is certificate signed by a CA I trust? Has it expired? Does CN match hostname? 5. Key Exchange → Client and server compute shared session key (Diffie-Hellman) 6. Encrypted Data → All subsequent data encrypted with AES using the shared key # INSPECT a site's certificate: $ openssl s_client -connect bank.com:443 -showcerts $ curl -vI https://bank.com 2>&1 | grep -A5 "SSL" # Common TLS vulnerabilities to look for: # - Expired certificates (causes warnings, sometimes accepted anyway) # - Self-signed certs (no CA verification → trivially MITM'd) # - Old TLS versions (TLS 1.0/1.1 → vulnerable to BEAST, POODLE) # - Weak cipher suites (RC4, DES, export-grade) # - HSTS not set (allows SSL stripping attack)

// DAY 12 — QUIZ

A database breach exposes 10 million passwords stored as MD5 hashes. An attacker has a GPU cluster. Why are MD5 password hashes considered catastrophically weak, even though MD5 is a one-way function?

A MD5 can be mathematically reversed to recover the original password

B MD5 is too fast — GPUs can compute billions of MD5 hashes per second making brute-force and rainbow tables trivial

C MD5 doesn\'t use a salt so all identical passwords have identical hashes

D MD5 only produces 32-bit hashes which are too short

OSINT — Open Source Intelligence

TOOLLAB theHarvester · Shodan · Google Dorks · Maltego

WEEK 2 PROGRESS — DAY 13 OF 14

🔎

OSINT = Hacking without touching the target. Before sending a single packet to a target network, elite pentesters and real attackers spend hours or days gathering intelligence from public sources. This is called passive reconnaissance. Zero network traffic to the target. Zero detection risk. Maximum intelligence.

// 13.1 — THE OSINT FRAMEWORK

Google Dorks

Search Engine Intelligence

Using advanced Google search operators to find information Google has indexed about a target — including sensitive files, login pages, and exposed data.

Free · Passive · Powerful

theHarvester

Email & Subdomain Harvesting

Automated tool that scrapes search engines, LinkedIn, Shodan, and other sources to find email addresses, employee names, subdomains, and IP addresses for a target domain.

Built into Kali · Fast · Automated

Shodan

Search Engine for Devices

Indexes internet-connected devices — servers, cameras, routers, industrial control systems — by banner and service. Find exposed services without scanning yourself.

shodan.io · API access · Powerful filters

Maltego

Visual OSINT & Link Analysis

Graphically maps relationships between people, organizations, domains, IPs, emails. Transforms data through APIs to reveal connections. Used by law enforcement and red teams.

Community Edition: free · Requires registration

WHOIS / DNS Records

Domain Registration Intelligence

WHOIS reveals domain registrant info (often redacted now, but historically gold). DNS records (A, MX, NS, TXT, SPF, DKIM) reveal infrastructure and email security posture.

whois · dig · dnsdumpster.com

LinkedIn / Social Media

Human Intelligence

Employee names, roles, tech stacks mentioned in job postings, GitHub repos with leaked credentials, executive email format patterns for spear-phishing.

Free · High value · Phishing setup

// 13.2 — GOOGLE DORKS MASTERCLASS

GOOGLE DORKING — FIND WHAT SHOULDN'T BE PUBLIC

# ── SITE OPERATORS ─────────────────────────────────────────── site:target.com # All indexed pages for target.com site:target.com filetype:pdf # PDFs on target.com (often contain metadata) site:target.com inurl:admin # Admin pages on target.com site:target.com inurl:login # Login portals # ── FILE TYPE HUNTING ───────────────────────────────────────── filetype:sql site:target.com # SQL database files (critical!) filetype:env site:target.com # .env files with API keys/DB passwords filetype:log site:target.com # Log files (usernames, errors, paths) filetype:xls site:target.com "password" # Excel files containing "password" filetype:bak site:target.com # Backup files often left exposed # ── CREDENTIAL HUNTING ─────────────────────────────────────── "target.com" "password" filetype:txt intext:"password" site:target.com site:pastebin.com "target.com" "password" # Pastes with leaked credentials site:github.com "target.com" password # GitHub code leaks # ── SENSITIVE PAGES ────────────────────────────────────────── intitle:"Index of" site:target.com # Open directory listings intitle:"phpMyAdmin" site:target.com # Exposed phpMyAdmin inurl:".git" site:target.com # Exposed .git directories (source code leak!) inurl:"/wp-admin" site:target.com # WordPress admin pages # Comprehensive Google Dork database: exploit-db.com/google-hacking-database # (GHDB — thousands of pre-built dorks categorized by vulnerability type)

// 13.3 — theHarvester IN ACTION

theHarvester — EMAIL & SUBDOMAIN HARVESTING

$ theHarvester -d targetcorp.com -b all -l 500 # -d = domain to search # -b = data sources (all = use everything available) # -l = limit results to 500 ******************************************************************* * _ _ _ * * | |_| |__ ___ /\ /\__ _ _ ____ _____ ___| |_ ___ _ __ * * | __| '_ \ / _ \ / /_/ / _` | '__\ \ / / _ \/ __| __/ _ \ '__|* * | |_| | | | __/ / __ / (_| | | \ V / __/\__ \ || __/ | * * \__|_| |_|\___| \/ /_/ \__,_|_| \_/ \___||___/\__\___|_| * [*] Target: targetcorp.com [*] Searching Google... [*] Searching LinkedIn... [*] Searching Shodan... Emails found: -------------- j.smith@targetcorp.com admin@targetcorp.com cto@targetcorp.com hr@targetcorp.com support@targetcorp.com Hosts found: ------------- mail.targetcorp.com:203.0.113.10 vpn.targetcorp.com:203.0.113.25 dev.targetcorp.com:10.0.0.50 ← INTERNAL IP leaked! Dev server staging.targetcorp.com:203.0.113.30 ← Staging server — often less hardened jenkins.targetcorp.com:203.0.113.35 ← CI/CD server — frequent attack target # What to do with this: # Emails → phishing targets, username format discovery # Subdomains → expanded attack surface (test each one separately!) # Internal IPs in DNS → network architecture leakage # Special servers (VPN, Jenkins, dev) → high-value targets

// 13.4 — SHODAN: THE INTERNET'S MOST DANGEROUS SEARCH ENGINE

SHODAN QUERIES

# Search at shodan.io — requires free account org:"Target Corporation" # Find all IPs registered to an organization hostname:"targetcorp.com" # All Shodan-indexed hosts for the domain net:"203.0.113.0/24" # All devices in an IP range # Finding specific vulnerable services: product:"Apache httpd" version:"2.2" # Old Apache versions (EOL) product:"Microsoft IIS" version:"6.0" # IIS 6.0 = WebDAV RCE vulnerability "default password" port:23 # Telnet with default passwords port:3389 country:US # All US RDP servers (exposed RDP!) "220" "230 Login successful" port:21 # FTP with anonymous login enabled has_screenshot:true port:5900 # VNC with screenshots visible! # Real Shodan finds (yes, these actually exist): # Industrial control systems with no password # Medical devices accessible from internet # Traffic cameras with admin/admin # Nuclear facility SCADA systems # This is why "security by obscurity" fails

// DAY 13 — LAB

Lab: OSINT on a Legitimate Target

⚠️

Ethics: Only perform OSINT on companies that have bug bounty programs authorizing this, or domains you own. The exercises below use public infrastructure and are fully legal.

Run theHarvester on bugcrowd.com: theHarvester -d bugcrowd.com -b google,bing -l 100
Google Dork: Search site:github.com "bugcrowd.com" password — what comes up?
DNS dump: dig bugcrowd.com ANY + dnsdumpster.com — map all subdomains
WHOIS: whois bugcrowd.com — who registered it? When? What nameservers?
Shodan (free account): Search hostname:bugcrowd.com — what services are indexed?
Check Wayback Machine (web.archive.org) — what did their site look like 5 years ago?

Review, TryHackMe & Week 2 CTF

LAB Full Week Consolidation · Networking CTF · Phase 1 Complete

WEEK 2 PROGRESS — COMPLETE ✓ — PHASE 1 COMPLETE ✓

🏆

Phase 1 Complete! You've covered 14 days of foundational cybersecurity — from the CIA Triad to live packet analysis to OSINT. Phase 2 starts Monday with enumeration, Nmap mastery, and web application reconnaissance. Today is about solidifying everything.

// 14.1 — WEEK 2 KNOWLEDGE REVIEW

TOPIC	KEY SKILL GAINED	ATTACK RELEVANCE
OSI + TCP/IP	Map any attack to its protocol layer; read TCP flags	Understand what every tool does and why
TCP Handshake	Read SYN/ACK/RST in Wireshark; explain SYN flood	nmap scans, DoS attacks, session hijacking
Subnetting/CIDR	Calculate network/broadcast/host ranges	Define scope, find live hosts, pivot targeting
DNS	dig, nslookup, zone transfers, record types	DNS poisoning, zone transfer data leaks, OSINT
ARP	Explain/execute ARP poisoning in lab	MITM on local network, credential capture
HTTP vs HTTPS	Capture and read HTTP credentials in Wireshark	Credential sniffing, MITM, SSL stripping
Wireshark	Display filters, packet dissection, follow streams	Traffic analysis, incident response, forensics
Firewalls/IDS	Read/write iptables rules; understand Snort syntax	Bypassing defenses, building detections
Cryptography	Symmetric/asymmetric/hashing — when each is used	Password cracking, TLS attacks, JWT forgery
OSINT	Google dorks, theHarvester, Shodan queries	Passive recon — zero-detection target profiling

// 14.2 — FINAL WEEK 2 QUIZ

You run theHarvester on a target and discover the subdomain jenkins.targetcorp.com. Why is a Jenkins server specifically interesting to an attacker?

A Jenkins is a web server that typically runs on port 80 with weak defaults

B Jenkins is a CI/CD server with access to source code, deployment credentials, and code execution capabilities

C Jenkins is an email server that often has weak spam filtering

D Jenkins stores all user passwords in a plaintext database

A Wireshark filter shows: tcp.flags == 0x002 with thousands of packets from 192.168.1.50 to 192.168.1.100 targeting sequential ports (21, 22, 23, 25...). What is happening, and how would a Snort IDS catch it?

A A DDoS attack from 192.168.1.50

B A port scan (nmap -sS) — SYN-only packets to sequential ports from one source; Snort catches it by counting SYN packets per source over time

C An ARP poisoning attack using TCP SYN packets

D A SYN flood DoS attack against sequential ports

// 14.3 — PHASE 1 FINAL LABS

TryHackMe Rooms — Complete This Week

Introductory Networking — OSI, TCP/IP, subnetting walkthrough with exercises
Network Services — SMB, Telnet, FTP, NFS enumeration and exploitation
Wireshark: The Basics — Official Wireshark room with real PCAP challenges
Pre-Security: How the Web Works — HTTP, DNS, web fundamentals

Networking CTF Challenges — PicoCTF

Packets Primer — Analyze a PCAP and find the flag in plaintext traffic
Wireshark doo dooo do doo — Filter and extract data from captured traffic
Wireshark twoo twooo two twoo — Intermediate PCAP analysis
m00nwalk — Decode data hidden in network traffic

Phase 1 Capstone: Full Recon on Metasploitable

Passive: WHOIS, DNS dig, Shodan search for your Metasploitable IP
Active: Run your Python port scanner + nmap -sV against it
Capture: Wireshark running while you browse http://192.168.56.101 — find HTTP credentials
Document: Write a one-page recon report: what you found, how, and what it means for an attacker
ARP: Execute ARP poisoning in your lab (Kali → Metasploitable). Verify in Wireshark you see the target's traffic.

// PHASE 2 PREVIEW

What's Coming in Phase 2 (Week 3–4)

Week 3 — Enumeration & Scanning

Nmap deep dive — every scan type, NSE scripts
Web recon: Gobuster, ffuf, subdomain brute-force
Vulnerability scanning: OpenVAS / Nessus
Active Directory recon: BloodHound, enum4linux
Burp Suite setup and intercepting first requests

Week 4 — First Exploits

Metasploit Framework — your first real exploit
SQL Injection — manual + automated (sqlmap)
XSS, CSRF, SSRF — web vulnerabilities deep dive
Password attacks: Hashcat, John, credential stuffing
First HackTheBox machine — full walkthrough

✅

Phase 1 Complete — Week 2 Checklist: Before moving to Phase 2, verify you can: (1) explain the OSI model and map attacks to layers, (2) read Wireshark filters and dissect packets, (3) explain how ARP poisoning works and execute it in your lab, (4) crack an MD5 hash with hashcat using rockyou.txt, (5) run a full OSINT profile on a target domain using theHarvester + Google dorks + Shodan, and (6) write iptables rules to allow/block specific traffic.