WEEK 8 · HARDENING · THREAT INTEL · CLOUD · PURPLE TEAM
// PHASE 4 — DEFENSIVE SECURITY → WEEK 8 OF 8 → BOOTCAMP COMPLETE

HARDEN.
HUNT.
GRADUATE.

The final week of the 2-month bootcamp. System hardening with CIS Benchmarks, network segmentation, zero-trust principles, threat intelligence and MITRE ATT&CK, malware analysis fundamentals, cloud security misconfigurations, purple team methodology, and the complete graduation capstone tying every skill together.

CIS Benchmarks Network Hardening MITRE ATT&CK Malware Analysis Cloud Security Purple Team Graduation Capstone
WEEK 8 — DAILY OUTLINE PHASE 4 · DAYS 50–56 · FINAL WEEK
DAY TOPIC WHAT YOU'LL LEARN KEY TOOLS
Day 50System HardeningCIS Benchmarks — the gold standard hardening framework. Linux hardening: disabling unnecessary services, SSH configuration (PasswordAuthentication no, PermitRootLogin no, AllowUsers), umask, PAM password policies, auditd, sysctl kernel parameters for network hardening. Windows hardening via Group Policy: LAPS, AppLocker, Windows Defender Credential Guard, PowerShell Constrained Language Mode, disabling legacy protocols (SMBv1, NTLM, WDigest).CIS-CAT, Lynis, Group Policy, LAPS
Day 51Network HardeningNetwork segmentation with VLANs — why flat networks are catastrophic for lateral movement. Zero-trust architecture principles: never trust, always verify, least-privilege access. Firewall rule ordering and default-deny posture. DNS sinkholing for C2 blocking. Network Access Control (NAC). Monitoring egress not just ingress — most organisations watch the front door but ignore the back. Intrusion prevention mode on Suricata.iptables, pfSense, VLAN, Suricata IPS
Day 52Threat IntelligenceMITRE ATT&CK framework in depth — 14 tactics, 200+ techniques, sub-techniques, and procedure examples. IOC (Indicator of Compromise) types: IPs, hashes, domains, mutexes, registry keys. IOA (Indicators of Attack): behavioural patterns. TI feeds: MISP, AlienVault OTX, VirusTotal, Shodan, AbuseIPDB. TTP-based hunting vs IOC-based hunting. Threat actor profiling and attribution. Building a detection gap analysis from ATT&CK Navigator.MISP, ATT&CK Navigator, OTX, MITRE
Day 53Malware Analysis BasicsStatic analysis: file type identification (file, strings), PE header analysis (sections, imports, exports), packer detection with PEiD/Detect-It-Easy, YARA rule writing. Dynamic analysis: sandbox execution in Any.run/Cuckoo, process creation monitoring (Procmon), network connection monitoring (Wireshark), registry change monitoring (Regshot). Identifying C2 beaconing patterns, persistence mechanisms, and data exfiltration in malware behaviour reports.strings, Detect-It-Easy, Cuckoo, Any.run, Procmon
Day 54Cloud SecurityAWS security misconfigurations that cause real breaches: public S3 buckets, overprivileged IAM roles, disabled CloudTrail, open security groups (0.0.0.0/0), exposed EC2 metadata endpoint, unencrypted RDS databases. AWS security tools: GuardDuty, Security Hub, CloudTrail, Config, IAM Access Analyzer. Securing Azure and GCP (parallel concepts). ScoutSuite for multi-cloud security auditing. The SSRF-to-metadata credential theft chain from an attacker's perspective (covered in Week 4) — now from the defender's side.AWS GuardDuty, ScoutSuite, Prowler, CloudTrail
Day 55Purple Team ExercisePurple team methodology: structured adversary simulation where red team executes attacks while blue team monitors and validates detections in real time. Building an ATT&CK-mapped test plan. Atomic Red Team — pre-built attack simulations mapped to ATT&CK techniques, executable with one command. Running 10 atomic tests covering initial access through exfiltration. Validating detection coverage: which attacks did the SIEM catch? Which slipped through? Gap analysis drives detection engineering priorities.Atomic Red Team, ATT&CK Navigator, Splunk
Day 56Graduation CapstoneComplete 2-month skill consolidation across all 4 phases. Full-spectrum assessment: the combined offensive + defensive skills map. Mock PNPT-style assessment: compromise a target network and write the full professional report. Certification path finalised. Career trajectory options (pentester, SOC analyst, red team, threat intelligence, cloud security, AppSec). What to do in months 3–12. Communities, continuing education, and staying sharp. Bootcamp complete.All tools across 8 weeks
50

SYSTEM HARDENING

THEORYLAB CIS Benchmarks · Linux Hardening · Windows Group Policy · LAPS · Credential Guard

WEEK 8 PROGRESS — DAY 50 OF 56
🛡️

Hardening is defence before the attacker arrives. Every privesc technique you learned in Week 5 — SUID binaries, sudo misconfigs, unquoted service paths, token impersonation — has a hardening countermeasure. Understanding the attack makes the defence obvious. Today you close the doors you spent Phase 3 walking through.

// 50.1 — CIS BENCHMARKS
THE GOLD STANDARD HARDENING FRAMEWORK

The Center for Internet Security (CIS) publishes detailed, consensus-based hardening guides for every major OS, application, and cloud platform — freely available at cisecurity.org. Each benchmark contains hundreds of specific configuration settings with rationale, remediation steps, and audit commands. CIS Level 1 = sensible baseline. CIS Level 2 = high-security environments.

// 50.2 — LINUX HARDENING CHECKLIST
SSH Hardening
PasswordAuthentication no
PermitRootLogin no
AllowUsers admin deploy
Protocol 2
MaxAuthTries 3
Key-based auth only. Root SSH = direct root shell if key leaked. Allowlist specific users only. Protocol 2 only — Protocol 1 has known vulnerabilities.
Disable Unnecessary Services
systemctl --type=service --state=running
systemctl disable telnet rsh rlogin
systemctl disable avahi-daemon cups
Every running service is attack surface. Telnet sends credentials in plaintext. avahi (mDNS) and cups (printing) rarely needed on servers.
SUID Audit
find / -perm -4000 -type f 2>/dev/null
chmod u-s /usr/bin/find
chmod u-s /usr/bin/python3
SUID on interpreters (python, perl, find, vim) = instant root via GTFOBins. Remove SUID from any binary that doesn't absolutely require it.
Kernel Hardening (sysctl)
net.ipv4.ip_forward = 0
net.ipv4.conf.all.rp_filter = 1
kernel.randomize_va_space = 2
kernel.dmesg_restrict = 1
Disable IP forwarding (not a router). Reverse path filtering defeats IP spoofing. ASLR (randomize_va_space=2) makes exploit memory addresses unpredictable.
auditd — Kernel Audit System
auditctl -w /etc/passwd -p wa -k identity
auditctl -w /etc/shadow -p wa -k identity
auditctl -a always,exit -F arch=b64 -S execve -k exec_log
Log every write to passwd/shadow (account creation). Log every command execution system-wide. SIEM ingests auditd logs — provides forensic trail even if bash_history is cleared.
File Permissions Audit
find / -writable -type f ! -path "/proc/*" 2>/dev/null
chmod 640 /etc/shadow
chmod 644 /etc/passwd
chattr +i /etc/passwd
World-writable files outside /tmp are almost always misconfigurations. Shadow must be readable only by root. chattr +i makes a file immutable even to root.
sudo Lockdown
visudo
# Remove: user ALL=(ALL) NOPASSWD: ALL
# Use specific commands only:
deploy ALL=/usr/bin/systemctl restart nginx
NOPASSWD: ALL is the most dangerous sudo configuration — equivalent to giving root access without a password. Grant only the minimum specific commands each user needs.
Lynis — Automated Audit
apt install lynis -y
lynis audit system
lynis audit system --quick
Lynis scores your system hardening 0-100. Lists every finding with remediation. Run before and after hardening to measure improvement. Free and open source.
// 50.3 — WINDOWS HARDENING VIA GROUP POLICY
WINDOWS HARDENING — CRITICAL CONFIGURATIONS
# ── DISABLE LEGACY PROTOCOLS (Week 5 attack prerequisites) ── # Disable SMBv1 (EternalBlue prerequisite): PS> Set-SmbServerConfiguration -EnableSMB1Protocol $false # Disable NTLM (Pass-the-Hash prerequisite): # GPO: Computer Config → Windows Settings → Security Settings → Local Policies → Security Options "Network Security: LAN Manager Authentication Level" → "Send NTLMv2 response only. Refuse LM & NTLM" # Disable WDigest (plaintext password storage — Mimikatz target): PS> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" -Name UseLogonCredential -Value 0 # ── WINDOWS DEFENDER CREDENTIAL GUARD ─────────────────────── # Isolates LSASS in a Hyper-V container — Mimikatz cannot read it # Requires UEFI + Virtualization-based Security (VBS) # GPO: Computer Config → Admin Templates → System → Device Guard "Turn On Virtualization Based Security" → Enabled "Credential Guard Configuration" → Enabled with UEFI lock # With Credential Guard enabled: sekurlsa::logonpasswords returns empty # This single control defeats Mimikatz LSASS dumping entirely # ── LAPS (Local Administrator Password Solution) ───────────── # Generates unique random passwords for the local Administrator account on each machine # Stored in AD, readable only by authorised users # Eliminates Pass-the-Hash lateral movement via shared local admin password PS> Install-Module LAPS -Force PS> Update-AdmPwdADSchema PS> Get-AdmPwdPassword -ComputerName WIN-WS01 ComputerName Password ExpirationTimestamp WIN-WS01 xK#9mP2!vQ8n 2024-02-15 10:00:00 # Each machine now has a different admin password — PtH spray fails # ── POWERSHELL CONSTRAINED LANGUAGE MODE ──────────────────── # Prevents PowerShell from running .NET calls, COM objects, reflection # Blocks most PowerShell-based post-exploitation techniques PS> [Environment]::SetEnvironmentVariable("__PSLockdownPolicy","4","Machine") # Or via GPO → PowerShell Execution Policy + AppLocker for PS scripts # ── APPLOCKER — WHITELIST WHAT CAN RUN ────────────────────── # GPO: Computer Config → Windows Settings → Security Settings → Application Control # Allow: C:\Windows\*, C:\Program Files\*, signed executables # Block: everything else — including scripts in user-writable paths # Blocks: mshta.exe, wscript.exe, cscript.exe (common LOLBins) # ── CHECK YOUR HARDENING WITH CIS-CAT ─────────────────────── # Download CIS-CAT Lite (free) from cisecurity.org # Scans Windows against CIS Benchmark, produces HTML report with score and findings
// DAY 50 — QUIZ
You harden a Windows domain and enable Credential Guard on all workstations. A red team subsequently runs Mimikatz sekurlsa::logonpasswords and gets empty results. They then run sekurlsa::wdigest — also empty. However, they find they can still Kerberoast service accounts and crack one password. Why does Credential Guard not prevent Kerberoasting?
A Credential Guard failed — it should also prevent Kerberoasting
B Credential Guard disables the Kerberos client, so Kerberoasting must have used a different protocol
C Credential Guard protects LSASS memory — Kerberoasting requests service tickets via normal Kerberos protocol calls on the DC, bypassing LSASS entirely
D Credential Guard only works on non-domain-joined machines
// DAY 50 — LAB
LAB TASKS
  • Run lynis audit system on your Kali VM. Note your score. Apply 5 hardening recommendations. Run again — measure improvement.
  • Harden your Metasploitable VM SSH: copy the key, disable password auth, re-test that Hydra SSH brute-force from Week 4 no longer works.
  • On your Windows lab VM: disable SMBv1, set WDigest to 0, run CIS-CAT Lite and review the report.
  • Configure LAPS in your AD lab. Verify each workstation has a unique local admin password.
  • Enable PowerShell Script Block Logging via GPO. Run a PowerShell download cradle. Check that it appears in Event ID 4104 logs.
51

NETWORK HARDENING

THEORYLAB VLANs · Zero Trust · Firewall Rules · DNS Sinkholing · Egress Monitoring

WEEK 8 PROGRESS — DAY 51 OF 56
🔒

Most organisations focus entirely on perimeter defence — and attackers know it. Once inside (via phishing, VPN credential spray, or supply chain), a flat network means every machine can talk to every other machine. The lateral movement chain from Week 5 only worked because the network had no segmentation. Fix the network, and a beachhead stays a beachhead instead of becoming a domain compromise.

// 51.1 — NETWORK SEGMENTATION WITH VLANs
WHY FLAT NETWORKS ARE CATASTROPHIC

In a flat network, a compromised workstation can directly reach the Domain Controller, file servers, database servers, and every other workstation. The BloodHound attack path from Week 5 — helpdesk PC → workstation → DC — only existed because those systems were all on the same broadcast domain with no firewall between them.

NETWORK SEGMENTATION — VLAN DESIGN AND FIREWALL RULES
# Recommended VLAN architecture for enterprise: # # VLAN 10: User Workstations (192.168.10.0/24) # VLAN 20: Servers (192.168.20.0/24) # VLAN 30: Domain Controllers (192.168.30.0/24) ← most restricted # VLAN 40: Management (192.168.40.0/24) ← jump hosts only # VLAN 50: DMZ / Public-facing (192.168.50.0/24) # VLAN 60: IoT / Printers (192.168.60.0/24) ← completely isolated # ── FIREWALL RULES between VLANs (iptables / pfSense) ─────── # Allow workstations to reach only what they need: # iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.20.0/24 -p tcp --dport 443 -j ACCEPT # HTTPS to servers # iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.30.0/24 -p tcp --dport 88 -j ACCEPT # Kerberos to DC # iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.30.0/24 -p tcp --dport 389 -j ACCEPT # LDAP to DC # iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.30.0/24 -j DROP # block everything else to DC # CRITICAL: Block workstation-to-workstation SMB (eliminates PtH spread) # iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.10.0/24 -p tcp --dport 445 -j DROP # This single rule makes Pass-the-Hash lateral movement from one workstation to another impossible # ── ZERO TRUST PRINCIPLES ───────────────────────────────────── # 1. Never trust, always verify — even internal traffic requires authentication # 2. Least-privilege access — users access only what their role requires # 3. Assume breach — design as if the attacker is already inside # 4. Micro-segmentation — granular controls per-application, not per-VLAN # 5. Continuous validation — re-verify identity and device posture per request # ── DNS SINKHOLING — block C2 at DNS level ─────────────────── # Malware beacons by resolving C2 domains. If DNS returns your own IP for # known-malicious domains, the beacon goes to your controlled server instead. # You capture the beacon, identify infected hosts, and block them. # Pi-hole or Bind9 as internal DNS with blocklist: $ curl -L https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts >> /etc/hosts # Or add to BIND9 zone configuration: zone "known-c2-domain.com" { type master; file "/etc/bind/sinkhole.zone"; }; # sinkhole.zone: A record pointing to your SOC monitoring server # ── EGRESS MONITORING — watch what leaves ──────────────────── # Most orgs only monitor ingress. Attackers exfiltrate data OUTBOUND. # Log all outbound connections with destination, volume, and frequency: $ iptables -A FORWARD -o eth0 -j LOG --log-prefix "EGRESS: " --log-level 4 # Alert on: large data transfers to unknown IPs, DNS queries to new domains, # HTTPS to non-categorised destinations, regular interval connections (C2 beaconing)
// DAY 51 — QUIZ
After implementing VLANs, a workstation in VLAN 10 (Users) is compromised. The attacker tries to use CrackMapExec to spray credentials across the 192.168.10.0/24 subnet. Your firewall blocks workstation-to-workstation SMB on port 445. The attacker then tries WMI on port 135/DCOM. What additional firewall rule closes this lateral movement path, and what residual path might still exist?
A Block all outbound traffic from VLAN 10 — only allow established connections
B Block port 135 (DCOM) and 49152-65535 (dynamic RPC) workstation-to-workstation — residual risk includes pivot through the DC or any multi-homed management host
C Disable WMI entirely on the domain via Group Policy
D Deploy an IDS to detect the WMI attempts — no additional firewall rules needed
52

THREAT INTELLIGENCE

THEORYLAB MITRE ATT&CK · IOCs · IOAs · TI Feeds · ATT&CK Navigator · MISP

WEEK 8 PROGRESS — DAY 52 OF 56
🗺️

Threat intelligence tells you who is attacking, how they operate, and what to look for before they arrive. IOC-based intelligence (block this IP, this hash) is the lowest maturity — it's reactive and easily evaded. TTP-based intelligence (this threat actor uses these techniques) is what separates reactive defenders from proactive hunters who detect attacks at the first technique, not the tenth.

// 52.1 — MITRE ATT&CK FRAMEWORK
THE ADVERSARY BEHAVIOUR KNOWLEDGE BASE

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. Every technique you learned in this bootcamp has a corresponding ATT&CK ID. It's the common language between red teams, blue teams, threat intel, and tool vendors.

TA0001 · Initial Access
Phishing, Valid Accounts, Exploit Public App, Supply Chain
TA0002 · Execution
PowerShell, WMI, Scheduled Tasks, Command Shell
TA0003 · Persistence
Registry Run Keys, Scheduled Tasks, New Service, SSH Keys
TA0004 · Privilege Escalation
Token Impersonation, SUID, Sudo Abuse, DLL Hijacking
TA0005 · Defence Evasion
AMSI Bypass, Process Injection, Log Deletion, Obfuscation
TA0006 · Credential Access
LSASS Dump, Kerberoasting, AS-REP Roasting, Brute Force
TA0007 · Discovery
Network Scan, Account Enum, BloodHound, File Discovery
TA0008 · Lateral Movement
PtH, PtT, PSExec, WMI, WinRM, RDP
TA0009 · Collection
Data from Local System, Keylogging, Screen Capture
TA0010 · Exfiltration
C2 Channel, HTTPS, DNS Tunneling, Cloud Storage
TA0011 · Command & Control
HTTPS, DNS C2, Beaconing, Domain Fronting
TA0040 · Impact
Ransomware, Data Destruction, Service Stop, Defacement
// 52.2 — IOC vs IOA vs TTP
TYPEWHAT IT ISEXAMPLEEVASION DIFFICULTYMATURITY LEVEL
IOC — HashMD5/SHA256 of a known malicious file5f4dcc3b5aa765d61d8327deb882cf99Trivial — recompile, change one byteLevel 1 (Reactive)
IOC — IP/DomainKnown C2 server address203.0.113.50 / evil-c2.comEasy — new IP/domain in minutesLevel 1 (Reactive)
IOA — BehaviourSuspicious action pattern regardless of toolsAny process reading lsass.exe memoryHard — attacker must fundamentally change techniqueLevel 3 (Proactive)
TTP — TechniqueATT&CK-mapped technique with procedureT1003.001: OS Credential Dumping via LSASSVery Hard — must completely change attack approachLevel 4 (Strategic)
TTP — Actor ProfileFull actor profile: tools, infra, targets, motivationsAPT28: spear-phishing → Mimikatz → custom implantExtremely Hard — requires entire actor to retoolLevel 5 (Strategic)
// 52.3 — THREAT INTELLIGENCE FEEDS AND PLATFORMS
1
MISP
Malware Information Sharing Platform — open-source TI platform for sharing IOCs across organisations. Ingests and exports STIX/TAXII feeds. Used by government CERTs and financial sector ISACs. Self-hosted, free. Your primary TI aggregation platform.
2
AlienVault OTX
Open Threat Exchange — free community TI feeds with millions of IOCs. IP reputation, domain reputation, file hashes, and attack pattern feeds. API for SIEM integration. Good for enriching Splunk alerts with reputation data.
3
VirusTotal
Submit file hashes or URLs for multi-engine AV analysis. Reveals malware families, related samples, C2 infrastructure, and sandbox reports. API allows SIEM enrichment. Free tier: 4 lookups/min. Never submit sensitive files — they become public.
4
AbuseIPDB
Community IP reputation database. When Splunk alerts on a suspicious IP, query AbuseIPDB for its reputation score. 100% confidence = confirmed malicious. Integrate via API for automatic alert enrichment in your SIEM.
5
ATT&CK Navigator
Web tool (mitre-attack.github.io/attack-navigator) — colour-code the ATT&CK matrix to show which techniques you can detect (blue), which red team has tested (red), and detection gaps (white). Your detection gap analysis lives here.
6
CISA Advisories
US Cybersecurity and Infrastructure Security Agency publishes free, authoritative advisories for active threat campaigns, ransomware groups, and nation-state actor TTPs. Subscribe to cisa.gov/alerts-advisories — required reading for any defender.
// DAY 52 — QUIZ
Your SIEM is blocking C2 traffic based on an IP blocklist (IOC-based detection). An analyst reports that a known APT group that targeted your sector last month has changed its C2 infrastructure to new IPs and domains. Your IOC blocklist hasn't been updated yet. What fundamental limitation does this expose, and what approach would have caught the attack regardless of infrastructure changes?
A IOC blocklists need more feeds — purchase more threat intelligence subscriptions
B Block entire IP ranges for countries associated with the APT group
C IOC detection is inherently reactive — TTP-based behavioural detection would catch the same actor regardless of infrastructure because their techniques don\'t change when their IPs do
D Wait for updated IOC feeds after the next victim reports the new infrastructure
53

MALWARE ANALYSIS BASICS

THEORYLAB Static Analysis · Dynamic Analysis · Sandboxes · Behavioural Indicators · YARA

WEEK 8 PROGRESS — DAY 53 OF 56
🦠

Malware analysis answers: what does this thing actually do? When incident response finds a suspicious file, you need to know — is it malicious? What does it connect to? What data does it steal? What persistence does it install? You answer these questions through static analysis (inspect without running) and dynamic analysis (run in a controlled environment and observe). You never run suspicious files on production systems.

// 53.1 — STATIC vs DYNAMIC ANALYSIS
Static Analysis
Dynamic Analysis
Sandbox Reports
YARA Hunting
STATIC ANALYSIS — INSPECT WITHOUT EXECUTING
# ── STEP 1: Identify file type (never trust the extension) ──── $ file suspicious_file.pdf suspicious_file.pdf: PE32+ executable (GUI) x86-64, for MS Windows ← NOT a PDF! # ── STEP 2: Hash the file (for TI lookup and tracking) ──────── $ sha256sum suspicious_file.pdf a3f4b2c1d5e6... → paste into VirusTotal / MalwareBazaar # ── STEP 3: Extract printable strings ───────────────────────── $ strings suspicious_file.pdf | grep -E "http|cmd|powershell|HKCU|registry|\.exe" http://203.0.113.50/beacon ← C2 URL hardcoded in binary cmd.exe /c whoami ← command execution SOFTWARE\Microsoft\Windows\CurrentVersion\Run ← persistence registry key C:\Users\Public\payload.exe ← dropper path # ── STEP 4: PE Header Analysis (Windows executables) ────────── $ python3 -c "import pefile; pe=pefile.PE('suspicious_file.pdf'); print(pe.dump_info())" # OR use Detect-It-Easy (GUI tool): # Sections: .text (code), .data, .rsrc (resources) — unusual sections = packed/encrypted # Imports: which Windows API calls does it use? VirtualAlloc, WriteProcessMemory, CreateRemoteThread ← process injection imports! WSAStartup, connect, send, recv ← network communication RegCreateKeyEx, RegSetValueEx ← registry persistence # ── STEP 5: Packer detection ────────────────────────────────── # If strings output is mostly garbage → file is packed/encrypted # Packed binaries decompress themselves in memory at runtime # DiE (Detect-It-Easy) identifies: UPX, MPRESS, Themida, VMProtect $ die suspicious_file.pdf UPX 3.96 → can unpack: upx -d suspicious_file.pdf
DYNAMIC ANALYSIS — CONTROLLED EXECUTION AND OBSERVATION
# CRITICAL: Dynamic analysis MUST happen in an isolated VM with: # - No internet access (or fake internet via INetSim/FakeNet) # - Snapshots BEFORE execution (restore after) # - No shared folders to host machine # - Network monitoring tools running BEFORE execution # ── SETUP (on isolated Windows VM) ────────────────────────── # 1. Start Wireshark (capture all traffic) # 2. Start Procmon (Sysinternals — process, file, registry monitor) # 3. Run Regshot BEFORE execution (baseline registry snapshot) # 4. Note running processes: tasklist /v > before.txt # 5. Execute the malware sample # 6. Wait 2-5 minutes for full execution # 7. Run Regshot AGAIN → compare (shows all registry changes) # 8. tasklist /v > after.txt → diff (shows new processes) # ── WHAT TO LOOK FOR ───────────────────────────────────────── Procmon: file writes to C:\Users\Public\ C:\Windows\Temp\ or AppData Procmon: process spawning cmd.exe, powershell.exe from unexpected parent Regshot: new Run key = persistence; new service = persistence Wireshark: DNS queries to unusual domains (DGA = Domain Generation Algorithm) Wireshark: regular interval connections to external IP = C2 beaconing Wireshark: HTTPS to non-CDN IPs at odd hours = encrypted C2 # ── INetSim: fake internet for dynamic analysis ─────────────── $ sudo apt install inetsim -y && sudo inetsim # Simulates: HTTP, HTTPS, FTP, DNS, SMTP — malware connects to fake servers # Prevents real C2 communication while allowing behavioural observation # Logs all connections: cat /var/log/inetsim/service.log
AUTOMATED SANDBOX ANALYSIS — ANY.RUN AND CUCKOO
# ── ANY.RUN (app.any.run) — interactive online sandbox ──────── # Upload file or URL → choose OS and browser → watch execution live # Free tier: public results (others can see your submission) # Shows: process tree, network connections, registry changes, IOCs # Reading an Any.run report: # Process tree → parent-child relationships reveal injection # Network tab → C2 IPs, domains, protocols, timing # Registry → persistence keys created # Files → dropped payloads, exfiltrated data # Threats → ATT&CK technique mappings auto-detected # ── CUCKOO SANDBOX — self-hosted (no data leaves your org) ─── $ pip install cuckoo --break-system-packages $ cuckoo init && cuckoo web # Submit via API: $ curl -F file=@suspicious_file.exe http://localhost:8090/tasks/create/file $ curl http://localhost:8090/tasks/report/1 # JSON report # ── KEY REPORT SECTIONS ────────────────────────────────────── signatures: Matched behavioural signatures (Cuckoo + community rules) network: All DNS queries, HTTP requests, TCP connections with timing processes: Full process tree with command lines files: All files created/modified/deleted registry: All registry operations iocs: Extracted IP, domain, URL, hash IOCs strings: Decoded strings from memory (post-unpacking)
YARA HUNTING — PROACTIVE MALWARE DETECTION
# After analysing a malware sample, write a YARA rule to find similar samples # across your environment BEFORE they execute # Example: after finding a Cobalt Strike beacon with these strings: rule CobaltStrike_Beacon_Indicators { meta: description = "Detects Cobalt Strike Beacon based on characteristic strings" author = "IR Team" date = "2024-01-15" strings: $cs1 = "ReflectiveLoader" ascii $cs2 = "%s (admin)" ascii $cs3 = "beacon.dll" ascii nocase $cs4 = { 68 65 61 72 74 62 65 61 74 } // "heartbeat" in hex $pipe1 = "\\\\.\\pipe\\msagent_" wide $pipe2 = "\\\\.\\pipe\\status_" wide condition: (2 of ($cs*)) or (1 of ($pipe*)) } # Proactive scan across your environment: $ yara -r cobalt_strike.yar C:\Users\ C:\Windows\Temp\ C:\ProgramData\ # Hunt across memory dumps from multiple machines: $ for dump in /ir/memory_dumps/*.dmp; do yara -r all_rules.yar "$dump" && echo "$dump"; done # Download 5,000+ community YARA rules: $ git clone https://github.com/Yara-Rules/rules && git clone https://github.com/Neo23x0/signature-base
// DAY 53 — QUIZ
During static analysis of a suspicious PE file, strings output is almost entirely garbage — short bursts of readable text surrounded by encrypted/compressed data. What does this indicate and what is your next step?
A The file is corrupted — discard it and request the original
B The file is legitimate — commercial software commonly uses compression
C The file is packed/encrypted — use Detect-It-Easy to identify the packer, unpack if possible (UPX -d), otherwise move to dynamic analysis and dump process memory after execution
D The file uses encrypted C2 communications — the garbage is network traffic embedded in the binary
54

CLOUD SECURITY

THEORYLAB AWS Misconfigurations · IAM · CloudTrail · GuardDuty · ScoutSuite · Azure/GCP

WEEK 8 PROGRESS — DAY 54 OF 56
☁️

Cloud misconfigurations have caused more major breaches in the last five years than any other single vulnerability class. Capital One (2019, 100M records), Microsoft Exchange Online (2023), Twitter (2020) — all cloud misconfigs. The attacker's toolset from Week 4 (SSRF → EC2 metadata → IAM credentials → S3 data) is the most common cloud attack chain. Today you learn to defend it.

// 54.1 — TOP CLOUD MISCONFIGURATIONS
Public S3 Bucket
CRITICAL · Exposed to entire internet
S3 buckets set to public allow anyone to list and download files. Backup archives, database dumps, and code repositories are commonly found this way via Shodan/GrayhatWarfare.
Fix: Block Public Access at account level (S3 → Block Public Access → Enable all). Audit: aws s3api list-buckets + get-bucket-acl for each.
Overprivileged IAM Roles
CRITICAL · *, *, * = full account access
IAM policies using Action: "*" and Resource: "*" grant an EC2 instance (or attacker who compromises it) full access to all AWS services. SSRF → metadata → these credentials = complete account takeover.
Fix: Least-privilege IAM. Use IAM Access Analyzer to identify overpermissive policies. Enforce permission boundaries. Use SCPs in AWS Organizations.
CloudTrail Disabled
HIGH · No visibility into API calls
CloudTrail logs every AWS API call — who did what, when, from where. Disabling it (or attackers disabling it) leaves you blind. Many organisations never enable it in non-production accounts.
Fix: Enable CloudTrail in all regions, all accounts. Enable log file validation (detects tampering). Ship logs to separate S3 bucket with separate account permissions.
Open Security Groups
HIGH · 0.0.0.0/0 on sensitive ports
Security groups allowing 0.0.0.0/0 (any IP) inbound on ports 22 (SSH), 3389 (RDP), 3306 (MySQL), 5432 (PostgreSQL) expose those services to the entire internet. Shodan indexes these in hours.
Fix: Source restrict SSH/RDP to VPN/bastion IPs only. Databases should never be publicly accessible — use VPC private subnets. Use AWS Config rule: restricted-ssh.
EC2 Metadata Endpoint Exposed
CRITICAL · SSRF → Full account compromise
169.254.169.254 returns IAM role credentials for any process on the instance. SSRF in a web app lets an attacker retrieve these credentials and operate as the EC2 role from anywhere.
Fix: Enable IMDSv2 (requires session token — SSRF with single HTTP requests can't retrieve it). aws ec2 modify-instance-metadata-options --http-tokens required. Block at WAF.
Exposed Kubernetes API
CRITICAL · Unauthenticated cluster access
Kubernetes API server exposed publicly with anonymous auth enabled allows full cluster control — deploy pods, read secrets, exfiltrate data, and use the cluster for cryptomining or as C2 infrastructure.
Fix: Never expose the k8s API publicly. Require authentication. Use RBAC with least-privilege. Audit with kube-bench (CIS Kubernetes Benchmark tool).
// 54.2 — AWS SECURITY AUDITING WITH SCOUTSUITE AND PROWLER
CLOUD SECURITY AUDITING TOOLS
# ── SCOUTSUITE — Multi-cloud security auditing ──────────────── $ pip3 install scoutsuite --break-system-packages $ scout aws --profile default # Uses ~/.aws/credentials # Generates HTML report at scoutsuite-report/scoutsuite_results.html # Covers: IAM, S3, EC2, RDS, Lambda, CloudTrail, CloudWatch, VPC, Route53 # Findings colour-coded: Red (danger) → Orange (warning) → Yellow (info) # ── PROWLER — AWS/GCP/Azure security checks (600+ rules) ────── $ pip3 install prowler --break-system-packages $ prowler aws --output-formats html json # Maps findings to CIS AWS Benchmark, MITRE ATT&CK, SOC2, ISO27001, GDPR # ── MANUAL AWS SECURITY CHECKS ─────────────────────────────── # Find public S3 buckets: $ aws s3api list-buckets --query 'Buckets[].Name' | xargs -I{} aws s3api get-bucket-acl --bucket {} 2>/dev/null | grep -i "AllUsers\|AuthenticatedUsers" # Check IAM users with console access and no MFA: $ aws iam generate-credential-report && aws iam get-credential-report --query 'Content' --output text | base64 -d | grep ",false," | cut -d, -f1 # Find open security groups: $ aws ec2 describe-security-groups --query "SecurityGroups[?contains(IpPermissions[].IpRanges[].CidrIp,'0.0.0.0/0')].{Name:GroupName,ID:GroupId}" # Enable GuardDuty (real-time threat detection): $ aws guardduty create-detector --enable --finding-publishing-frequency FIFTEEN_MINUTES # GuardDuty analyses CloudTrail, VPC Flow Logs, DNS logs for: # Cryptocurrency mining, credential compromise, backdoor activity, # unusual API calls, reconnaissance, data exfiltration # Enable IMDSv2 on all EC2 instances (blocks SSRF credential theft): $ aws ec2 describe-instances --query "Reservations[].Instances[].InstanceId" | xargs -I{} aws ec2 modify-instance-metadata-options --instance-id {} --http-tokens required --http-endpoint enabled
// DAY 54 — QUIZ
ScoutSuite finds an EC2 instance running a web application that has: (1) an IAM role with s3:* on *, (2) IMDSv1 enabled, and (3) a security group allowing 0.0.0.0/0 on port 443. During a pentest you found an SSRF vulnerability in the web app. Describe the complete exploitation chain and prioritise the three misconfigurations by remediation urgency.
A Prioritise the open security group first — close port 443 immediately
B Fix the IAM role first, the other two are acceptable configurations
C Chain: SSRF → IMDSv1 metadata credential theft → AWS keys used externally → all S3 data exfiltrated. Priority: (1) IMDSv2 now (breaks the chain with one command), (2) scope IAM to least-privilege, (3) fix SSRF in app code
D All three are equally urgent — fix simultaneously
55

PURPLE TEAM EXERCISE

TOOLLAB Atomic Red Team · ATT&CK Navigator · Detection Gap Analysis · Attack-Detect-Verify Loop

WEEK 8 PROGRESS — DAY 55 OF 56
🟣

Purple team is the highest-value security exercise most organisations never run. Red team attacks. Blue team defends. They debrief separately, write reports, and two months later the blue team still doesn't know which of their detections actually fire. Purple team collapses this — red and blue work together in real time: attack a technique → immediately verify whether the SIEM caught it → fix the detection if it didn't → move to the next technique. Every gap closed in real time.

// 55.1 — THE PURPLE TEAM LOOP
1
RED TEAM
Select an ATT&CK technique (e.g. T1003.001 — LSASS Memory Dump). Execute it using Atomic Red Team or manually. Document the exact command, timestamp, and affected host.
2
BLUE TEAM
Check Splunk/SIEM in real time — within 5 minutes of execution. Did an alert fire? Was the event logged? At what fidelity (just the event, or full context with process tree)?
3
BLUE TEAM
If no alert fired: investigate WHY. Missing log source? Detection rule too narrow? Insufficient logging verbosity? Write the detection now, during the session, not in a backlog.
4
RED TEAM
Re-execute the same technique with minor variations (different process, different account, different timing). Does the new detection rule still fire? Is it robust or easily bypassed?
5
BLUE TEAM
Update ATT&CK Navigator: mark T1003.001 as "Detected" (blue). Move to the next technique. Build a real, tested, coverage map — not a theoretical one.
6
RED TEAM
After covering all planned techniques: report the detection gap percentage. "We tested 30 techniques — 18 detected (60%), 12 slipped through." This drives the security roadmap priorities.
// 55.2 — ATOMIC RED TEAM
PRE-BUILT ATTACK SIMULATIONS FOR EVERY ATT&CK TECHNIQUE

Atomic Red Team (github.com/redcanaryco/atomic-red-team) is a library of small, focused attack simulations mapped to MITRE ATT&CK techniques — one "atomic test" per technique. Run them in your environment to test detections without needing a full red team. Free, open-source, maintained by Red Canary.

ATOMIC RED TEAM — SETUP AND EXECUTION
# Install Invoke-AtomicRedTeam (PowerShell) on Windows test machine: PS> Install-Module -Name invoke-atomicredteam,powershell-yaml -Scope CurrentUser PS> IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing); Install-AtomicRedTeam -getAtomics # ── RUN ATOMIC TESTS ───────────────────────────────────────── # T1003.001 — LSASS Memory Dump (Mimikatz equivalent): PS> Invoke-AtomicTest T1003.001 [*] Executing test: Dump LSASS.exe Memory using ProcDump [*] Done executing test # Immediately check Splunk: EventCode=10, TargetImage=lsass.exe # T1059.001 — PowerShell Execution (encoded command): PS> Invoke-AtomicTest T1059.001 # T1053.005 — Scheduled Task Creation (persistence): PS> Invoke-AtomicTest T1053.005 # Check Splunk: EventCode=4698 # T1558.003 — Kerberoasting: PS> Invoke-AtomicTest T1558.003 # Check Splunk: EventCode=4769, Ticket_Encryption_Type=0x17 # Run cleanup after each test (remove artifacts): PS> Invoke-AtomicTest T1003.001 -Cleanup # List all available tests for a technique: PS> Invoke-AtomicTest T1003.001 -ShowDetails # Run all tests for a tactic and log results: PS> $results = Invoke-AtomicTest T1003.001,T1059.001,T1053.005,T1558.003 -LoggingModule Attire-ExecutionLogger # Results map directly to ATT&CK Navigator for coverage visualisation
// 55.3 — DETECTION GAP ANALYSIS WITH ATT&CK NAVIGATOR
VISUALISE YOUR COVERAGE

After running Atomic tests, colour the ATT&CK Navigator matrix to show your real detection posture. This turns abstract "we have a SIEM" into "we detect 18 of 30 tested techniques across these 6 tactics, with gaps in Defence Evasion and Lateral Movement."

  • Green (Detected + Alerted): Technique tested, SIEM fired correct alert, analyst would have been notified
  • Yellow (Logged but no alert): Event is in logs but no rule triggers — manual hunting could find it, but no real-time detection
  • Red (No visibility): Technique executed, nothing logged anywhere — complete blind spot
  • Blue (Mitigated): Hardening control prevents the technique from being possible (e.g. Credential Guard prevents LSASS dumping)
  • White (Not tested): Technique not yet in your test plan — schedule next purple team session
// DAY 55 — QUIZ
After a purple team session, your ATT&CK Navigator shows: Credential Access tactic — 2 of 8 techniques detected. Discovery tactic — 7 of 8 detected. What does this gap analysis tell you about your detection priorities for the next quarter?
A Focus on Discovery — you're almost at 100% and just need one more rule
B Split resources 50/50 between both tactics
C Prioritise Credential Access — 25% coverage on the tactic that directly enables lateral movement and DA compromise is the most critical security gap
D Replace your SIEM — the tool is clearly insufficient if it only catches 25% of Credential Access techniques
56

GRADUATION CAPSTONE

CAPSTONE 2-Month Complete Review · Full-Spectrum Skill Map · Career Paths · What's Next

BOOTCAMP — 56 DAYS — COMPLETE ✓✓✓
2-MONTH BOOTCAMP COMPLETE

56 days. 4 phases. Beginner to professional-ready cybersecurity practitioner — both offensive and defensive. Every major attack technique. Every core defensive control. You built a home lab, compromised real machines, wrote detection rules, performed forensics on memory dumps, and hardened systems against your own attacks.

56
DAYS
4
PHASES
200+
CONCEPTS
80+
TOOLS
40+
ATT&CK TECHNIQUES
LABS LEFT TO DO
// 56.1 — COMPLETE 4-PHASE SKILL MAP
Linux Fundamentals & ScriptingPhase 1
Networking & Protocol AnalysisPhase 1
Nmap & Web EnumerationPhase 2
Burp Suite & Web ExploitationPhase 2
Metasploit & PayloadsPhase 2
SQL Injection & XSSPhase 2
Linux & Windows Privilege EscalationPhase 3
Active Directory AttacksPhase 3
Mimikatz & Lateral MovementPhase 3
AV Evasion & C2 FrameworksPhase 3
SIEM & Log AnalysisPhase 4
Detection Engineering & SigmaPhase 4
Incident Response & ForensicsPhase 4
Cloud Security (AWS)Phase 4
Threat Intelligence & ATT&CKPhase 4
Report Writing & CommunicationAll
// 56.2 — CAREER PATHS FROM THIS BOOTCAMP
CAREER PATHWHAT YOU DORELEVANT PHASESFIRST CERT TARGETTYPICAL ENTRY SALARY
Penetration TesterAuthorised hacking of client systems to find vulnerabilities before attackers do. Web apps, networks, AD, mobile.Phases 1–3 primarilyeJPT → PNPT → OSCP$70k–$100k
SOC Analyst (L1/L2)Monitor SIEM alerts, triage incidents, investigate anomalies, escalate confirmed incidents to IR team.Phase 4 primarilySecurity+ → BTL1$55k–$80k
Red Team OperatorAdvanced long-term simulated attacks against mature targets. Custom implants, AD attacks, evasion. Senior role.Phases 2–3 deeplyPNPT → OSCP → CRTO$100k–$150k
Threat Intelligence AnalystTrack threat actors, map TTPs, produce intelligence reports, brief executives on risk landscape.Phase 4 Day 52Security+ → CEH → GCTI$75k–$110k
Cloud Security EngineerSecure AWS/Azure/GCP environments. IAM, misconfig remediation, cloud-native detection, CSPM tooling.Phase 4 Day 54AWS Security Specialty → CCSP$100k–$140k
Bug Bounty HunterIndependent. Find vulnerabilities in companies' public programmes. Web app focused. Income varies wildly.Phases 2–3 web focusNo cert needed — portfolio matters$0–$300k+ (highly variable)
Detection EngineerBuild and maintain the rules, queries, and logic in the SIEM. Turn ATT&CK techniques into detection coverage.Phase 4 Days 45, 55Security+ → Splunk Core Certified → BTL1$85k–$120k
// 56.3 — THE FINAL GRADUATION LABS
CAPSTONE LAB — MOCK PNPT ASSESSMENT

This is your graduation exam. Give yourself 5 days, as if it were a real client engagement. No walkthroughs. Everything from memory.

  • Scope: Your home AD lab — one Windows domain with DC, two workstations, one web server. Start from zero credentials on a Kali VM.
  • Day 1: Full recon and enumeration. Document everything. No exploitation yet.
  • Day 2: Initial access and foothold. Web app exploitation, phishing simulation, or credential spray.
  • Day 3: Privilege escalation, post-exploitation, credential harvesting, lateral movement.
  • Day 4: Domain Admin. DCSync. Demonstrate full impact. Establish persistence.
  • Day 5: Write the full professional report. Executive summary, all findings with CVSS, remediation roadmap. This is what you'd deliver to a real client.
CAPSTONE LAB 2 — FULL DEFENSIVE REVIEW
  • Apply CIS Level 1 hardening to your Windows lab. Run Lynis on your Linux systems. Document the before/after scores.
  • Set up Splunk with Sysmon on the Windows lab. Run the 10 Atomic Red Team tests from Day 55. Which ones fired alerts? Build rules for the ones that didn't.
  • Write a Sigma rule for one technique that didn't have coverage. Convert it to SPL. Verify it fires on the next Atomic test run.
  • Run ScoutSuite against a free-tier AWS account. Fix the top 3 critical findings. Document the remediation steps.
  • Take a memory dump of a Volatility exercise VM (available at github.com/volatilityfoundation/volatility/wiki/Memory-Samples). Answer: what malware is present, what persistence does it use, what C2 does it connect to?
// 56.4 — FINAL WEEK 8 QUIZ
Your organisation suffers a breach. Post-incident investigation finds: (1) attackers entered via a phishing email, (2) escalated via unquoted service path, (3) ran Kerberoasting undetected, (4) achieved DA and ran DCSync, (5) exfiltrated 50GB via HTTPS over 3 days. For each of the 5 steps, name one control that would have prevented or detected it.
A Better antivirus would have stopped all 5 steps
B Firewall rules would have prevented most of these steps
C Each step has a specific control: (1) Email gateway + DMARC, (2) Hardening automation + vuln scanning, (3) 4769 detection + AES enforcement, (4) DCSync rights monitoring, (5) DLP + egress volume anomaly detection
D Regular penetration testing would have found and prevented all 5 attack vectors
// YOUR PATH FORWARD
🎓

What you have now that you didn't have 56 days ago: A mental model of how attackers think. A home lab you can hack and defend. 80+ tools you've actually used. The ability to read a CVE and understand its impact. The vocabulary to communicate risk to both executives and engineers. A foundation that took most security professionals 2–3 years to build through scattered self-study.

What comes next is practice. Do one HackTheBox machine per week. Submit one bug bounty report per month. Read one CISA advisory per week. Build one new detection rule per week. In 6 months, take the PNPT. In 12 months, take the OSCP. In 24 months, you are a professional. The field is yours.

PHASE 4 COMPLETE · WEEK 8 OF 8 · BOOTCAMP COMPLETE · 56 DAYS · BEGINNER → PROFESSIONAL CYBERSECURITY PRACTITIONER