better projects replacements
This commit is contained in:
CarterPerez-dev
parent
e696b084a1
commit
261d5c2c16
61
README.md
61
README.md
|
|
@ -1,7 +1,7 @@
|
|||
<div align="center">
|
||||
<img width="260" height="260" alt="Kali-dragon-icon svg" src="https://github.com/user-attachments/assets/d911b71f-6ad9-45b7-9513-237f83377023" alt="Kali Linux Icon"/>
|
||||
<h1 align="center">Cybersecurity Projects 🐉</h1>
|
||||
<p align="center">60 Cybersecurity Projects, Certification Roadmaps & Resources</p>
|
||||
<p align="center">67 Cybersecurity Projects, Certification Roadmaps & Resources</p>
|
||||
</div>
|
||||
|
||||
<div align="center">
|
||||
|
|
@ -10,7 +10,7 @@
|
|||
<img src="https://img.shields.io/github/issues/CarterPerez-dev/Cybersecurity-Projects" alt="issues"/>
|
||||
<img src="https://img.shields.io/github/license/CarterPerez-dev/Cybersecurity-Projects" alt="license"/>
|
||||
<br/>
|
||||
<img src="https://img.shields.io/badge/Cybersecurity-60_Projects-darkblue" alt="projects"/>
|
||||
<img src="https://img.shields.io/badge/Cybersecurity-67_Projects-darkblue" alt="projects"/>
|
||||
<img src="https://img.shields.io/badge/Security-Learning_Resources-darkred" alt="resources"/>
|
||||
</div>
|
||||
|
||||
|
|
@ -25,7 +25,7 @@
|
|||
<h2 align="center"><strong>View Complete Projects:</strong></h2>
|
||||
<div align="center">
|
||||
<a href="https://github.com/CarterPerez-dev/Cybersecurity-Projects/tree/main/PROJECTS">
|
||||
<img src="https://img.shields.io/badge/Full_Source_Code-18/60-blue?style=for-the-badge&logo=github" alt="Projects"/>
|
||||
<img src="https://img.shields.io/badge/Full_Source_Code-18/67-blue?style=for-the-badge&logo=github" alt="Projects"/>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
|
|
@ -36,7 +36,7 @@
|
|||
## Quick Navigation
|
||||
|
||||
### [Projects](#projects)
|
||||
60 hands-on cybersecurity projects with full source code, from beginner to advanced level.
|
||||
67 hands-on cybersecurity projects with full source code, from beginner to advanced level.
|
||||
|
||||
### [Certification Roadmaps](./ROADMAPS/README.md)
|
||||
10 structured career paths with certification guides for SOC Analyst, Pentester, Security Engineer, and more.
|
||||
|
|
@ -60,44 +60,48 @@ Tools, courses, certifications, communities, and frameworks for cybersecurity pr
|
|||
| **[Metadata Scrubber Tool](./PROJECTS/beginner/metadata-scrubber-tool)**<br>Remove EXIF and privacy metadata [@Heritage-XioN](https://github.com/Heritage-XioN) |    | EXIF data • Privacy protection • Batch processing<br>[Source Code](./PROJECTS/beginner/metadata-scrubber-tool) \| [Docs](./PROJECTS/beginner/metadata-scrubber-tool/learn) |
|
||||
| **[Network Traffic Analyzer](./PROJECTS/beginner/network-traffic-analyzer)**<br>Capture and analyze packets |     | Packet capture • Protocol analysis • Traffic visualization<br>[Source (C++)](./PROJECTS/beginner/network-traffic-analyzer/cpp) \| [Docs (C++)](./PROJECTS/beginner/network-traffic-analyzer/cpp/learn) \| [Source (Python)](./PROJECTS/beginner/network-traffic-analyzer/python) \| [Docs (Python)](./PROJECTS/beginner/network-traffic-analyzer/python/learn) |
|
||||
| **[Hash Cracker](./PROJECTS/beginner/hash-cracker)**<br>Dictionary and brute-force cracking |    | Hash algorithms • Dictionary attacks • Password security<br>[Source Code](./PROJECTS/beginner/hash-cracker) \| [Docs](./PROJECTS/beginner/hash-cracker/learn) |
|
||||
| **[Steganography Tool](./SYNOPSES/beginner/Steganography.Tool.md)**<br>Hide messages in images |    | LSB steganography • Image manipulation • Data hiding<br>[Learn More](./SYNOPSES/beginner/Steganography.Tool.md) |
|
||||
| **[MAC Address Spoofer](./SYNOPSES/beginner/MAC.Address.Spoofer.md)**<br>Change network interface MAC |    | Network interfaces • MAC addresses • Vendor lookup<br>[Learn More](./SYNOPSES/beginner/MAC.Address.Spoofer.md) |
|
||||
| **[File Integrity Monitor](./SYNOPSES/beginner/File.Integrity.Monitor.md)**<br>Monitor directories with checksums |    | Cryptographic hashing • File monitoring • Alert systems<br>[Learn More](./SYNOPSES/beginner/File.Integrity.Monitor.md) |
|
||||
| **[Steganography Multi-Tool](./SYNOPSES/beginner/Steganography.Multi.Tool.md)**<br>Hide data in images, audio, QR, PDFs, text |    | Multi-format steganography • Zero-width Unicode • Audio LSB • QR exploitation<br>[Learn More](./SYNOPSES/beginner/Steganography.Multi.Tool.md) |
|
||||
| **[Ghost on the Wire](./SYNOPSES/beginner/Ghost.On.The.Wire.md)**<br>L2 attack & defense: MAC spoofing + ARP detection |    | ARP protocol • MAC spoofing • MITM detection • L2 trust mapping<br>[Learn More](./SYNOPSES/beginner/Ghost.On.The.Wire.md) |
|
||||
| **[Canary Token Generator](./SYNOPSES/beginner/Canary.Token.Generator.md)**<br>Self-hosted honeytokens that alert on access |    | Deception defense • Honeytokens • Webhook alerting • Intrusion detection<br>[Learn More](./SYNOPSES/beginner/Canary.Token.Generator.md) |
|
||||
| **[Security News Scraper](./SYNOPSES/beginner/Security.News.Scraper.md)**<br>Aggregate cybersecurity news |    | Web scraping • CVE parsing • Database storage<br>[Learn More](./SYNOPSES/beginner/Security.News.Scraper.md) |
|
||||
| **[Phishing URL Detector](./SYNOPSES/beginner/Phishing.URL.Detector.md)**<br>Analyze URLs for phishing |    | URL analysis • Typosquatting detection • Safe browsing APIs<br>[Learn More](./SYNOPSES/beginner/Phishing.URL.Detector.md) |
|
||||
| **[Phishing Domain Generator & Quishing Scanner](./SYNOPSES/beginner/Phishing.Domain.Generator.And.Quishing.Scanner.md)**<br>Typosquat generation + QR phishing detection |    | Homoglyph attacks • Typosquatting • QR code analysis • Domain intelligence<br>[Learn More](./SYNOPSES/beginner/Phishing.Domain.Generator.And.Quishing.Scanner.md) |
|
||||
| **[SSH Brute Force Detector](./SYNOPSES/beginner/SSH.Brute.Force.Detector.md)**<br>Monitor and block SSH attacks |    | Log parsing • Attack detection • Firewall automation<br>[Learn More](./SYNOPSES/beginner/SSH.Brute.Force.Detector.md) |
|
||||
| **[Simple C2 Beacon](./PROJECTS/beginner/c2-beacon)**<br>Command and Control beacon/server |      | C2 architecture • MITRE ATT&CK • WebSocket protocol • XOR encoding<br>[Source Code](./PROJECTS/beginner/c2-beacon) \| [Docs](./PROJECTS/beginner/c2-beacon/learn) |
|
||||
| **[Base64 Encoder/Decoder](./SYNOPSES/beginner/Base64.Encoder.Decoder.md)**<br>Multi-format encoding tool |    | Base64/32 encoding • URL encoding • Auto-detection<br>[Source Code](./PROJECTS/beginner/base64-tool) \| [Docs](./PROJECTS/beginner/base64-tool/learn) |
|
||||
| **[Firewall Log Parser](./SYNOPSES/beginner/Firewall.Log.Parser.md)**<br>Parse and visualize logs |    | Log parsing • Pattern recognition • Data visualization<br>[Learn More](./SYNOPSES/beginner/Firewall.Log.Parser.md) |
|
||||
| **[ARP Spoofing Detector](./SYNOPSES/beginner/ARP.Spoofing.Detector.md)**<br>Detect ARP attacks |    | ARP protocol • MAC tracking • MITM detection<br>[Learn More](./SYNOPSES/beginner/ARP.Spoofing.Detector.md) |
|
||||
| **[Windows Registry Monitor](./SYNOPSES/beginner/Windows.Registry.Monitor.md)**<br>Track registry changes |    | Windows registry • Persistence detection • System monitoring<br>[Learn More](./SYNOPSES/beginner/Windows.Registry.Monitor.md) |
|
||||
| **[Ransomware Simulator](./SYNOPSES/beginner/Ransomware.Simulator.md)**<br>Educational encryption demo |    | File encryption • Ransomware behavior • Ethical testing<br>[Learn More](./SYNOPSES/beginner/Ransomware.Simulator.md) |
|
||||
| **[Linux CIS Hardening Auditor](./SYNOPSES/beginner/Linux.CIS.Hardening.Auditor.md)**<br>CIS benchmark compliance checker |    | CIS benchmarks • System hardening • Compliance scoring • Shell scripting<br>[Learn More](./SYNOPSES/beginner/Linux.CIS.Hardening.Auditor.md) |
|
||||
| **[Systemd Persistence Scanner](./SYNOPSES/beginner/Systemd.Persistence.Scanner.md)**<br>Hunt Linux persistence mechanisms |    | Persistence techniques • Systemd internals • Cron analysis • Threat hunting<br>[Learn More](./SYNOPSES/beginner/Systemd.Persistence.Scanner.md) |
|
||||
| **[Linux eBPF Security Tracer](./SYNOPSES/beginner/Linux.eBPF.Security.Tracer.md)**<br>Real-time syscall tracing with eBPF |     | eBPF programs • Syscall tracing • BCC framework • Security observability<br>[Learn More](./SYNOPSES/beginner/Linux.eBPF.Security.Tracer.md) |
|
||||
| **[Trojan Application Builder](./SYNOPSES/beginner/Trojan.Application.Builder.md)**<br>Educational malware lifecycle demo |    | Trojan anatomy • Data exfiltration • File encryption • Attack lifecycle<br>[Learn More](./SYNOPSES/beginner/Trojan.Application.Builder.md) |
|
||||
| **[DNS Sinkhole](./SYNOPSES/beginner/DNS.Sinkhole.md)**<br>Pi-hole-style malware domain blocker |    | DNS protocol • Blocklist management • Query logging • Network defense<br>[Learn More](./SYNOPSES/beginner/DNS.Sinkhole.md) |
|
||||
| **[Firewall Rule Engine](./SYNOPSES/beginner/Vlang.Firewall.Rule.Engine.md)**<br>Parse and validate iptables/nftables rules |    | Firewall internals • Rule parsing • iptables/nftables • V language<br>[Learn More](./SYNOPSES/beginner/Vlang.Firewall.Rule.Engine.md) |
|
||||
| **[LLM Prompt Injection Firewall](./SYNOPSES/beginner/LLM.Prompt.Injection.Firewall.md)**<br>Detect and block prompt injection attacks |    | AI security • Prompt injection • Input sanitization • LLM defense<br>[Learn More](./SYNOPSES/beginner/LLM.Prompt.Injection.Firewall.md) |
|
||||
|
||||
## Intermediate Projects
|
||||
|
||||
| Project | Info | What You'll Learn |
|
||||
|---------|------|-------------------|
|
||||
| **[Reverse Shell Handler](./SYNOPSES/intermediate/Reverse.Shell.Handler.md)**<br>Multi-client shell server |    | Socket programming • Command execution • File transfer<br>[Learn More](./SYNOPSES/intermediate/Reverse.Shell.Handler.md) |
|
||||
| **[Payload Obfuscation Engine](./SYNOPSES/intermediate/Payload.Obfuscation.Engine.md)**<br>Multi-layer payload obfuscation toolkit |    | Obfuscation techniques • Polymorphism • AV evasion • Signature detection<br>[Learn More](./SYNOPSES/intermediate/Payload.Obfuscation.Engine.md) |
|
||||
| **[SIEM Dashboard](./SYNOPSES/intermediate/SIEM.Dashboard.md)**<br>Log aggregation with correlation |     | SIEM concepts • Log correlation • Full-stack development<br>[Source Code](./PROJECTS/intermediate/siem-dashboard) \| [Docs](./PROJECTS/intermediate/siem-dashboard/learn) |
|
||||
| **[Threat Intelligence Aggregator](./SYNOPSES/intermediate/Threat.Intelligence.Aggregator.md)**<br>Collect and enrich IOCs |    | Threat feeds • IOC enrichment • API integration<br>[Learn More](./SYNOPSES/intermediate/Threat.Intelligence.Aggregator.md) |
|
||||
| **[OAuth Token Analyzer](./SYNOPSES/intermediate/OAuth.Token.Analyzer.md)**<br>Decode and validate JWT |    | JWT tokens • OAuth vulnerabilities • Signature validation<br>[Learn More](./SYNOPSES/intermediate/OAuth.Token.Analyzer.md) |
|
||||
| **[Web Vulnerability Scanner](./SYNOPSES/intermediate/Web.Vulnerability.Scanner.md)**<br>Automated XSS, SQLi, CSRF testing |    | Web vulnerabilities • Async scanning • Plugin architecture<br>[Learn More](./SYNOPSES/intermediate/Web.Vulnerability.Scanner.md) |
|
||||
| **[Token Abuse Playground](./SYNOPSES/intermediate/Token.Abuse.Playground.md)**<br>15+ token vulnerabilities to exploit and fix |     | JWT exploitation • OAuth attacks • Session security • Token forensics<br>[Learn More](./SYNOPSES/intermediate/Token.Abuse.Playground.md) |
|
||||
| **[Supply Chain Attack Simulator](./SYNOPSES/intermediate/Supply.Chain.Attack.Simulator.md)**<br>Fake PyPI package dependency confusion demo |    | Supply chain attacks • Dependency confusion • Package security • PyPI internals<br>[Learn More](./SYNOPSES/intermediate/Supply.Chain.Attack.Simulator.md) |
|
||||
| **[DDoS Mitigation Tool](./SYNOPSES/intermediate/DDoS.Mitigation.Tool.md)**<br>Detect traffic spikes |    | DDoS detection • Rate limiting • Anomaly detection<br>[Learn More](./SYNOPSES/intermediate/DDoS.Mitigation.Tool.md) |
|
||||
| **[Secrets Scanner](./PROJECTS/intermediate/secrets-scanner)**<br>Scan codebases and git history for leaked secrets |    | Secret detection • Shannon entropy • HIBP k-anonymity • SARIF output<br>[Source Code](./PROJECTS/intermediate/secrets-scanner) \| [Docs](./PROJECTS/intermediate/secrets-scanner/learn) |
|
||||
| **[API Security Scanner](./PROJECTS/intermediate/api-security-scanner)**<br>Enterprise API vulnerability scanner |      | OWASP API Top 10 • ML fuzzing • GraphQL/SOAP testing<br>[Source Code](./PROJECTS/intermediate/api-security-scanner) \| [Docs](./PROJECTS/intermediate/api-security-scanner/learn) |
|
||||
| **[Wireless Deauth Detector](./SYNOPSES/intermediate/Wireless.Deauth.Detector.md)**<br>Monitor WiFi deauth attacks |    | Wireless security • Packet sniffing • Attack detection<br>[Learn More](./SYNOPSES/intermediate/Wireless.Deauth.Detector.md) |
|
||||
| **[Active Directory Enumeration](./SYNOPSES/intermediate/Active.Directory.Enumeration.md)**<br>Enumerate AD infrastructure |    | LDAP queries • AD structure • Privilege analysis<br>[Learn More](./SYNOPSES/intermediate/Active.Directory.Enumeration.md) |
|
||||
| **[Credential Harvester](./SYNOPSES/intermediate/Nim.Credential.Harvester.md)**<br>Post-exploitation credential collection |    | Credential extraction • Browser forensics • Red team tooling • Nim language<br>[Learn More](./SYNOPSES/intermediate/Nim.Credential.Harvester.md) |
|
||||
| **[Binary Analysis Tool](./SYNOPSES/intermediate/Binary.Analysis.Tool.md)**<br>Disassemble and analyze executables |    | Binary analysis • String extraction • Malware detection<br>[Learn More](./SYNOPSES/intermediate/Binary.Analysis.Tool.md) |
|
||||
| **[Network Intrusion Prevention](./SYNOPSES/intermediate/Network.Intrusion.Prevention.md)**<br>Real-time packet inspection |    | IPS concepts • Snort rules • Firewall integration<br>[Learn More](./SYNOPSES/intermediate/Network.Intrusion.Prevention.md) |
|
||||
| **[Password Policy Auditor](./SYNOPSES/intermediate/Password.Policy.Auditor.md)**<br>Audit password policies |    | Password security • Policy compliance • Weak password detection<br>[Learn More](./SYNOPSES/intermediate/Password.Policy.Auditor.md) |
|
||||
| **[Cloud Asset Inventory](./SYNOPSES/intermediate/Cloud.Asset.Inventory.md)**<br>Discover cloud resources |     | Cloud APIs • Asset discovery • Cost tracking<br>[Learn More](./SYNOPSES/intermediate/Cloud.Asset.Inventory.md) |
|
||||
| **[OSINT Reconnaissance Framework](./SYNOPSES/intermediate/OSINT.Reconnaissance.Framework.md)**<br>Aggregate public intelligence |    | OSINT techniques • Data aggregation • Target profiling<br>[Learn More](./SYNOPSES/intermediate/OSINT.Reconnaissance.Framework.md) |
|
||||
| **[SSL/TLS Certificate Scanner](./SYNOPSES/intermediate/SSL.TLS.Certificate.Scanner.md)**<br>Scan for SSL misconfigurations |    | TLS/SSL protocols • Certificate validation • Cipher analysis<br>[Learn More](./SYNOPSES/intermediate/SSL.TLS.Certificate.Scanner.md) |
|
||||
| **[Chaos Engineering Security Tool](./SYNOPSES/intermediate/Chaos.Engineering.Security.Tool.md)**<br>Inject security failures to test resilience |    | Chaos engineering • Security resilience • Credential spraying • Auth testing<br>[Learn More](./SYNOPSES/intermediate/Chaos.Engineering.Security.Tool.md) |
|
||||
| **[Credential Rotation Enforcer](./SYNOPSES/intermediate/Credential.Rotation.Enforcer.md)**<br>Track and enforce credential rotation policies |    | Credential hygiene • Secret rotation • Compliance dashboards • API integration<br>[Learn More](./SYNOPSES/intermediate/Credential.Rotation.Enforcer.md) |
|
||||
| **[Race Condition Exploiter](./SYNOPSES/intermediate/Race.Condition.Exploiter.md)**<br>TOCTOU race condition attack & defense lab |     | TOCTOU attacks • Double-spend bugs • Concurrent exploitation • Race visualization<br>[Learn More](./SYNOPSES/intermediate/Race.Condition.Exploiter.md) |
|
||||
| **[Self-Hosted Shodan Clone](./SYNOPSES/intermediate/Self.Hosted.Shodan.Clone.md)**<br>Internet-connected device search engine |     | Service fingerprinting • Network scanning • OSINT • Search engine design<br>[Learn More](./SYNOPSES/intermediate/Self.Hosted.Shodan.Clone.md) |
|
||||
| **[JA3/JA4 TLS Fingerprinting Tool](./SYNOPSES/intermediate/JA3.JA4.TLS.Fingerprinting.Tool.md)**<br>Fingerprint TLS clients by handshake |    | TLS handshake analysis • JA3/JA4 hashing • Bot detection • Malware C2 identification<br>[Learn More](./SYNOPSES/intermediate/JA3.JA4.TLS.Fingerprinting.Tool.md) |
|
||||
| **[Mobile App Security Analyzer](./SYNOPSES/intermediate/Mobile.App.Security.Analyzer.md)**<br>Decompile and analyze mobile apps |    | APK/IPA analysis • Reverse engineering • OWASP Mobile<br>[Learn More](./SYNOPSES/intermediate/Mobile.App.Security.Analyzer.md) |
|
||||
| **[Backup Integrity Checker](./SYNOPSES/intermediate/Backup.Integrity.Checker.md)**<br>Verify backup integrity |    | Backup validation • Restoration testing • Checksum verification<br>[Learn More](./SYNOPSES/intermediate/Backup.Integrity.Checker.md) |
|
||||
| **[Web Application Firewall](./SYNOPSES/intermediate/Web.Application.Firewall.md)**<br>Reverse proxy with filtering |    | WAF concepts • Request filtering • Attack blocking<br>[Learn More](./SYNOPSES/intermediate/Web.Application.Firewall.md) |
|
||||
| **[Privilege Escalation Finder](./SYNOPSES/intermediate/Privilege.Escalation.Finder.md)**<br>Identify privilege escalation |    | Privilege escalation • SUID binaries • Weak permissions<br>[Learn More](./SYNOPSES/intermediate/Privilege.Escalation.Finder.md) |
|
||||
| **[Network Baseline Monitor](./SYNOPSES/intermediate/Network.Baseline.Monitor.md)**<br>Monitor network behavior |    | Baseline analysis • Anomaly detection • Traffic patterns<br>[Learn More](./SYNOPSES/intermediate/Network.Baseline.Monitor.md) |
|
||||
| **[DLP Scanner](./SYNOPSES/intermediate/DLP.Scanner.md)**<br>Data Loss Prevention for files, DBs, and traffic |    | PII detection • GDPR/HIPAA compliance • Pattern matching • Data classification<br>[Learn More](./SYNOPSES/intermediate/DLP.Scanner.md) |
|
||||
| **[Lua/Nginx Edge Backend](./SYNOPSES/intermediate/Lua.Nginx.Edge.Backend.md)**<br>Full CRUD backend via Lua in Nginx |     | Edge computing • OpenResty • Lua scripting • WAF • JWT at the edge<br>[Learn More](./SYNOPSES/intermediate/Lua.Nginx.Edge.Backend.md) |
|
||||
| **[Privesc Playground](./SYNOPSES/intermediate/Privesc.Playground.md)**<br>20+ privilege escalation paths to exploit |    | SUID exploitation • Sudo abuse • Cron hijacking • GTFOBins • Capability abuse<br>[Learn More](./SYNOPSES/intermediate/Privesc.Playground.md) |
|
||||
| **[SBOM Generator & Vulnerability Matcher](./SYNOPSES/intermediate/SBOM.Generator.md)**<br>Software Bill of Materials with CVE matching |    | SPDX/CycloneDX formats • Dependency analysis • CVE databases • EO 14028 compliance<br>[Learn More](./SYNOPSES/intermediate/SBOM.Generator.md) |
|
||||
| **[Subdomain Takeover Scanner](./SYNOPSES/intermediate/Subdomain.Takeover.Scanner.md)**<br>Detect dangling DNS records |    | DNS enumeration • CNAME analysis • Cloud resource claiming • Bug bounty<br>[Learn More](./SYNOPSES/intermediate/Subdomain.Takeover.Scanner.md) |
|
||||
| **[GraphQL Security Tester](./SYNOPSES/intermediate/GraphQL.Security.Tester.md)**<br>Automated GraphQL vulnerability testing |    | Introspection attacks • Query depth DoS • Authorization bypass • Batching abuse<br>[Learn More](./SYNOPSES/intermediate/GraphQL.Security.Tester.md) |
|
||||
| **[Docker Security Audit](./PROJECTS/intermediate/docker-security-audit)**<br>CIS Docker Benchmark scanner |     | CIS benchmarks • Container security • Multiple output formats<br>[Source Code](./PROJECTS/intermediate/docker-security-audit) \| [Docs](./PROJECTS/intermediate/docker-security-audit/learn) |
|
||||
|
||||
## Advanced Projects
|
||||
|
|
@ -109,7 +113,7 @@ Tools, courses, certifications, communities, and frameworks for cybersecurity pr
|
|||
| **[Exploit Development Framework](./SYNOPSES/advanced/Exploit.Development.Framework.md)**<br>Modular exploitation framework |    | Exploit development • Payload generation • Plugin architecture<br>[Learn More](./SYNOPSES/advanced/Exploit.Development.Framework.md) |
|
||||
| **[AI Threat Detection](./PROJECTS/advanced/ai-threat-detection)**<br>ML-powered nginx threat detection |      | ML ensemble (AE + RF + IF) • ONNX inference • Real-time detection<br>[Source Code](./PROJECTS/advanced/ai-threat-detection) |
|
||||
| **[Bug Bounty Platform](./PROJECTS/advanced/bug-bounty-platform)**<br>Full vulnerability disclosure platform |      | Full-stack development • CVSS scoring • Workflow automation<br>[Source Code](./PROJECTS/advanced/bug-bounty-platform) \| [Docs](./PROJECTS/advanced/bug-bounty-platform/learn) |
|
||||
| **[Cloud Security Posture Management](./SYNOPSES/advanced/Cloud.Security.Posture.Management.md)**<br>Multi-cloud misconfiguration scanner |      | Cloud security • CIS benchmarks • Multi-cloud APIs<br>[Learn More](./SYNOPSES/advanced/Cloud.Security.Posture.Management.md) |
|
||||
| **[Cloud Security Compliance Dashboard](./SYNOPSES/advanced/Cloud.Security.Compliance.Dashboard.md)**<br>Multi-cloud compliance with CIS, SOC2, HIPAA |      | CIS benchmarks • SOC2/HIPAA compliance • Cost-security optimization • Drift detection<br>[Learn More](./SYNOPSES/advanced/Cloud.Security.Compliance.Dashboard.md) |
|
||||
| **[Malware Analysis Platform](./SYNOPSES/advanced/Malware.Analysis.Platform.md)**<br>Automated sandbox analysis |     | Malware analysis • Sandboxing • YARA rules • IOC extraction<br>[Learn More](./SYNOPSES/advanced/Malware.Analysis.Platform.md) |
|
||||
| **[Quantum Resistant Encryption](./SYNOPSES/advanced/Quantum.Resistant.Encryption.md)**<br>Post-quantum cryptography |    | Post-quantum algorithms • Hybrid encryption • Kyber/Dilithium<br>[Learn More](./SYNOPSES/advanced/Quantum.Resistant.Encryption.md) |
|
||||
| **[Zero Day Vulnerability Scanner](./SYNOPSES/advanced/Zero.Day.Vulnerability.Scanner.md)**<br>Coverage-guided fuzzing |     | Fuzzing • Vulnerability research • Crash triage<br>[Learn More](./SYNOPSES/advanced/Zero.Day.Vulnerability.Scanner.md) |
|
||||
|
|
@ -121,6 +125,9 @@ Tools, courses, certifications, communities, and frameworks for cybersecurity pr
|
|||
| **[Hardware Security Module Emulator](./SYNOPSES/advanced/Hardware.Security.Module.Emulator.md)**<br>Software HSM with PKCS#11 |    | HSM concepts • PKCS#11 interface • Cryptographic operations<br>[Learn More](./SYNOPSES/advanced/Hardware.Security.Module.Emulator.md) |
|
||||
| **[Network Covert Channel](./SYNOPSES/advanced/Network.Covert.Channel.md)**<br>Data exfiltration techniques |    | Covert channels • Data exfiltration • Steganography<br>[Learn More](./SYNOPSES/advanced/Network.Covert.Channel.md) |
|
||||
| **[Automated Penetration Testing](./SYNOPSES/advanced/Automated.Penetration.Testing.md)**<br>Full pentest automation |    | Pentest automation • Recon to exploitation • Report generation<br>[Learn More](./SYNOPSES/advanced/Automated.Penetration.Testing.md) |
|
||||
| **[Haskell Reverse Proxy](./PROJECTS/advanced/haskell-reverse-proxy)**<br>Functional reverse proxy with security middleware |    | Functional programming • Reverse proxy design • Security middleware • Haskell<br>[Source Code](./PROJECTS/advanced/haskell-reverse-proxy) |
|
||||
| **["Monitor the Situation" Dashboard](./SYNOPSES/advanced/Monitor.The.Situation.Dashboard.md)**<br>Real-time cyber threat situational awareness |     | Threat intelligence • CVE tracking • MITRE ATT&CK • OSINT • Real-time dashboards<br>[Learn More](./SYNOPSES/advanced/Monitor.The.Situation.Dashboard.md) |
|
||||
| **[Honeypot Network](./SYNOPSES/advanced/Honeypot.Network.md)**<br>Multi-service honeypot deployment & analysis |    | Honeypot deployment • Attacker behavior analysis • IOC extraction • MITRE mapping<br>[Learn More](./SYNOPSES/advanced/Honeypot.Network.md) |
|
||||
| **[Supply Chain Security Analyzer](./SYNOPSES/advanced/Supply.Chain.Security.Analyzer.md)**<br>Dependency vulnerability analysis |    | Supply chain security • Dependency analysis • Malicious packages<br>[Learn More](./SYNOPSES/advanced/Supply.Chain.Security.Analyzer.md) |
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -0,0 +1,42 @@
|
|||
# Cloud Security Compliance Dashboard
|
||||
|
||||
## Overview
|
||||
Build a multi-cloud security compliance platform in Go with a React dashboard that scans AWS, Azure, and GCP for misconfigurations, checks resources against CIS benchmarks, SOC2, HIPAA, and PCI-DSS frameworks, and presents results through executive dashboards with compliance scoring, trend tracking, and cost-security optimization. The platform includes automated remediation recommendations with Terraform snippets, continuous monitoring with drift detection, and reporting suitable for both technical teams and C-level executives. This project teaches enterprise cloud security assessment at scale and demonstrates the architecture behind commercial CSPM platforms like Prisma Cloud and Wiz.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Design the multi-cloud assessment architecture** with a plugin-based scanner system where each cloud provider has its own assessment module implementing a common interface. Build a Go service that orchestrates scans across providers, normalizes findings into a unified format, and stores results in PostgreSQL. Design the data model to support historical tracking, trend analysis, and multi-account/multi-project scanning.
|
||||
|
||||
2. **Implement AWS assessment using the AWS SDK for Go** scanning for misconfigurations across core services: S3 buckets (public access, encryption, logging), IAM policies (overly permissive roles, unused credentials, MFA enforcement), EC2 security groups (unrestricted inbound, unused rules), RDS instances (public accessibility, encryption, backup retention), CloudTrail (enabled, log validation, multi-region), VPC (flow logs, default security groups), and Lambda (excessive permissions, VPC configuration). Map each check to specific CIS benchmark controls.
|
||||
|
||||
3. **Build Azure and GCP assessment modules** following the same pattern: Azure checks for Storage Account exposure, RBAC role assignments, Network Security Groups, Key Vault policies, and Azure AD configurations. GCP checks for Cloud Storage IAM bindings, Compute Engine firewalls, Cloud SQL encryption, IAM custom roles, and Audit Log configuration. Implement provider-specific authentication handling and API rate limiting.
|
||||
|
||||
4. **Create the compliance framework mapping engine** that maps cloud configurations to multiple compliance frameworks simultaneously: CIS benchmarks (200+ controls per provider), SOC2 Trust Service Criteria, HIPAA Security Rule requirements, and PCI-DSS controls. Compute compliance scores as percentages per framework, per provider, and per resource category. Support multiple compliance profiles (strict for production, relaxed for development).
|
||||
|
||||
5. **Build cost-security optimization analysis** that correlates cloud billing data with security findings: identify resources that are both expensive AND insecure (high-cost EC2 instances with public security groups), find security improvements that also reduce cost (eliminating unused public IPs, right-sizing over-provisioned resources), and calculate the cost-of-risk for each finding.
|
||||
|
||||
6. **Implement the React dashboard** with executive views showing overall compliance posture across all clouds, drill-down by provider/region/service, trend charts showing compliance improvement or degradation over time, a geographic map of resources and their security status, and a risk-prioritized finding list with remediation effort estimates. Include role-based views for executives (high-level scores) and engineers (specific findings with fix commands).
|
||||
|
||||
7. **Add automated remediation recommendations** that generate actionable fixes for each finding: Terraform code snippets that remediate the misconfiguration, CLI commands for immediate manual fixes, and infrastructure-as-code templates for preventive controls. Implement an approval workflow where security teams review recommendations before execution, and track remediation status through to completion.
|
||||
|
||||
8. **Build continuous monitoring and drift detection** that re-scans on a configurable schedule (hourly, daily), detects configuration drift from the last known-good state, alerts on new findings via webhooks (Slack, PagerDuty), and generates compliance trend reports showing improvement velocity. Compare live state against Terraform state files to detect unauthorized manual changes.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Multi-cloud security assessment architecture
|
||||
- CIS benchmark framework implementation
|
||||
- SOC2, HIPAA, PCI-DSS compliance requirements
|
||||
- Cloud provider SDKs and API rate limiting
|
||||
- Compliance scoring and trend analysis
|
||||
- Cost-security optimization correlation
|
||||
- Infrastructure-as-code remediation
|
||||
- Continuous monitoring and drift detection
|
||||
|
||||
## Deliverables
|
||||
- Multi-cloud scanner (AWS, Azure, GCP)
|
||||
- CIS benchmark compliance checking (200+ controls)
|
||||
- SOC2, HIPAA, PCI-DSS framework mapping
|
||||
- Cost-security optimization analysis
|
||||
- React executive dashboard with drill-downs
|
||||
- Automated remediation with Terraform snippets
|
||||
- Continuous monitoring with drift detection
|
||||
- Webhook alerting and trend reporting
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
# Cloud Security Posture Management (CSPM)
|
||||
|
||||
## Overview
|
||||
Build a cloud security tool scanning AWS, Azure, and GCP for misconfigurations including public S3 buckets, overly permissive IAM roles, and unencrypted storage, implementing CIS benchmark compliance checking and generating executive dashboards. This project teaches cloud security assessment, compliance frameworks, and demonstrates enterprise CSPM platforms like Dome9 and Prisma Cloud.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand cloud misconfigurations and CSPM concepts** by learning common cloud security errors: public S3 buckets exposing data, overly permissive IAM policies granting unnecessary access, unencrypted storage violating compliance requirements, security groups allowing unrestricted inbound traffic, and CloudTrail logging disabled preventing audit trails. Study CIS benchmarks defining best practices for cloud security: AWS CIS benchmark contains 200+ controls, Azure benchmark covers 139 recommendations, GCP benchmark specifies 122 recommendations. Understand CSPM systems continuously monitor cloud environments detecting misconfigurations and compliance violations.
|
||||
|
||||
2. **Implement AWS assessment using boto3** scanning for misconfigurations: enumerate S3 buckets checking public access settings (ACLs, bucket policies), examine IAM policies identifying overly permissive roles (wildcard actions, resource permissions), audit security groups checking for unrestricted (0.0.0.0/0) inbound rules, verify encryption configurations (KMS for data at rest, TLS for data in transit), check CloudTrail logging enabled with log file integrity validation, audit VPC flow logs and VPC endpoints. Build assessment engine checking each resource category systematically.
|
||||
|
||||
3. **Create Azure assessment using Azure SDK** analyzing Azure misconfigurations: examine Storage Accounts checking for public access and encryption, audit Managed Identities and RBAC role assignments identifying excessive permissions, check Network Security Groups and Application Security Groups for open ports, verify databases are encrypted and auditing enabled, check Key Vault access policies, audit subscription-level security settings. Implement similar systematic assessment across Azure resource types.
|
||||
|
||||
4. **Build GCP assessment using Google Cloud SDK** scanning GCP for issues: examine Cloud Storage buckets checking IAM bindings for public access, audit IAM roles and custom roles for overly permissive permissions, check Compute Engine firewalls for unrestricted access, verify encryption settings on databases and storage, check Cloud Audit Logs are enabled and retention appropriate. Implement service-specific assessment for each GCP offering.
|
||||
|
||||
5. **Implement CIS benchmark compliance checking** mapping cloud configurations to CIS requirements: for each CIS control, determine what cloud configuration audit is needed, implement automated checking, and map findings to specific controls. Compute compliance score: percentage of controls passed. Build multiple baseline profiles (strict for regulated industries, moderate for general business, development for non-production) allowing different compliance levels for different environments.
|
||||
|
||||
6. **Create risk scoring and prioritization** combining multiple findings into comprehensive risk assessment: score each finding based on severity (critical/high/medium/low), exploitability, and business impact. Identify high-risk patterns: multiple misconfigurations in same area, sensitive resources with excessive permissions, or known attack vectors. Prioritize remediation recommendations based on risk scores: address critical findings immediately, schedule medium findings for next sprint.
|
||||
|
||||
7. **Build executive dashboards and reporting** creating visibility into cloud security posture: show overall compliance percentage, break down by cloud provider and resource type, display trend data showing improvement/degradation over time, create geographic maps showing misconfigurations by region. Generate detailed reports for technical teams listing specific misconfigurations with remediation steps. Build executive summaries showing risk scores and compliance metrics suitable for C-level and board presentations.
|
||||
|
||||
8. **Implement automated remediation recommendations and workflow** providing actionable fixes: for each misconfiguration, generate recommended changes (Terraform code snippets, CloudFormation templates, or step-by-step instructions). Implement approval workflow where security team reviews recommendations before implementation, then automate remediation through infrastructure-as-code tooling. Create continuous scanning: re-assess on schedule (hourly, daily) detecting configuration drift and new misconfigurations. Compare your CSPM to commercial solutions (Dome9, Prisma Cloud, CloudMapper), discuss limitations (requires significant API permissions, covers configuration but not behavior, needs to complement other security tools), and explain integration into broader cloud security strategies.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Cloud provider APIs and SDKs
|
||||
- Cloud misconfigurations and risks
|
||||
- CIS benchmark framework
|
||||
- IAM policy analysis
|
||||
- Network security assessment
|
||||
- Encryption validation
|
||||
- Compliance scoring and reporting
|
||||
- Risk prioritization methodology
|
||||
- Automated remediation
|
||||
- Multi-cloud assessment
|
||||
|
||||
## Deliverables
|
||||
- AWS configuration assessment
|
||||
- Azure configuration assessment
|
||||
- GCP configuration assessment
|
||||
- CIS benchmark compliance checking
|
||||
- IAM policy analysis and scoring
|
||||
- Network security configuration audit
|
||||
- Encryption validation across services
|
||||
- Risk scoring and prioritization
|
||||
- Executive dashboards
|
||||
- Technical remediation reports
|
||||
- Automated remediation workflows
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
# Honeypot Network
|
||||
|
||||
## Overview
|
||||
Build a network of realistic honeypots in Go that simulate SSH, HTTP, FTP, SMB, MySQL, and Redis services, capturing and analyzing attacker behavior in detail. The system logs all interactions including commands executed, files uploaded, credentials attempted, and lateral movement attempts, then fingerprints attacker tools and techniques, maps activity to the MITRE ATT&CK framework, and generates IOCs (indicators of compromise) from captured sessions. A web dashboard provides real-time visibility into attacker activity, geographic distribution, and TTP analysis. This project teaches deception technology, attacker tradecraft analysis, and the architecture behind commercial honeypot platforms like T-Pot and Cowrie.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Design the honeypot network architecture** with each service type implemented as an independent Go module sharing a common logging and analysis backend. Build a central event bus that collects interaction data from all honeypots, normalizes events into a unified schema (timestamp, source IP, service type, action, payload), and stores them in PostgreSQL with Elasticsearch for full-text search. Design the system for easy deployment of multiple honeypot instances across different network segments.
|
||||
|
||||
2. **Implement the SSH honeypot** as the highest-value sensor, emulating an OpenSSH server that accepts any credential combination while logging all attempts. After authentication, provide a realistic-looking shell environment with a fake filesystem, common commands (ls, cat, wget, curl, whoami, uname), and simulated system responses. Record full session transcripts including every command entered, files downloaded, and lateral movement attempts (ssh to other hosts).
|
||||
|
||||
3. **Build the HTTP honeypot** presenting vulnerable-looking web applications: a fake WordPress admin panel, phpMyAdmin interface, exposed API endpoints, and common web shell paths. Log all requests with full headers, POST bodies, and uploaded files. Detect and classify automated scanning tools (Nikto, Nmap NSE scripts, SQLmap) by their request patterns and user-agent strings.
|
||||
|
||||
4. **Create service-specific honeypots for FTP, SMB, MySQL, and Redis** each emulating enough protocol to engage attackers. FTP: accept anonymous and credential logins, log file upload/download attempts. SMB: respond to share enumeration, log authentication attempts and EternalBlue-style exploit attempts. MySQL: accept connections, log queries and credential attempts. Redis: respond to INFO and CONFIG commands, detect cryptominer deployment attempts (a common Redis attack pattern).
|
||||
|
||||
5. **Build the attacker fingerprinting engine** that correlates activity across all honeypot types to build attacker profiles: group interactions by source IP and session timing, identify tools used (Metasploit, Cobalt Strike, custom scripts) by behavioral signatures, classify attacker sophistication (automated scanner vs manual attacker vs APT), and track attacker progression through the kill chain (reconnaissance, exploitation, post-exploitation, lateral movement).
|
||||
|
||||
6. **Implement MITRE ATT&CK mapping** that automatically classifies each observed technique: credential brute force (T1110), command and scripting interpreter (T1059), ingress tool transfer (T1105), account discovery (T1087), and more. Build a heat map showing which ATT&CK techniques are most commonly observed, trending techniques over time, and technique chains (which techniques are commonly used together).
|
||||
|
||||
7. **Create the IOC extraction and export system** that generates actionable threat intelligence from honeypot data: extract IP addresses, domains, file hashes (of uploaded malware), SSH keys, credential lists, and command patterns. Export in STIX/TAXII format for integration with threat intelligence platforms, generate YARA rules from captured malware samples, and produce blocklists for firewall integration.
|
||||
|
||||
8. **Build the web dashboard** showing real-time attack activity: a world map with active attacker locations, per-service interaction graphs, top attacker IPs with profile cards, ATT&CK heat map, credential wordcloud from attempted passwords, timeline of notable sessions (manual attackers, novel techniques), and IOC feeds. Include a session replay feature that plays back SSH sessions command-by-command for analysis.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Honeypot design and protocol emulation
|
||||
- Network service protocols (SSH, HTTP, FTP, SMB, MySQL, Redis)
|
||||
- Attacker behavior analysis and profiling
|
||||
- MITRE ATT&CK framework mapping
|
||||
- IOC extraction and STIX/TAXII export
|
||||
- Go concurrent service architecture
|
||||
- Threat intelligence generation
|
||||
- Deception technology deployment
|
||||
|
||||
## Deliverables
|
||||
- Six service honeypots (SSH, HTTP, FTP, SMB, MySQL, Redis)
|
||||
- Central event collection and analysis backend
|
||||
- Attacker fingerprinting and session correlation
|
||||
- MITRE ATT&CK automatic technique mapping
|
||||
- IOC extraction with STIX/TAXII and YARA export
|
||||
- Web dashboard with real-time attack visualization
|
||||
- SSH session replay for manual analysis
|
||||
- Blocklist generation for defensive integration
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
# "Monitor the Situation" Dashboard
|
||||
|
||||
## Overview
|
||||
Build a comprehensive cybersecurity situational awareness platform in Python with a React frontend that aggregates real-time threat intelligence from multiple sources into a single operational dashboard. The platform features a global threat map with IP geolocation from threat feeds, a CVE velocity tracker showing newly published vulnerabilities with CVSS scoring, a threat actor leaderboard tracking APT groups mapped to MITRE ATT&CK, an exploit availability monitor tracking weaponization timelines, social media threat intelligence aggregation, and infrastructure health correlation. Inspired by the "monitor the situation" meme but built as a genuinely useful security operations tool pulling from NVD, MITRE, GreyNoise, AbuseIPDB, Shodan, and social feeds.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Design the data aggregation architecture** with a Python backend using FastAPI that orchestrates data collection from multiple threat intelligence APIs on different schedules. Build an async task system (Celery or APScheduler) that polls each data source at appropriate intervals (CVEs every 15 minutes, threat feeds hourly, social media every 5 minutes), normalizes data into a unified schema, and stores it in PostgreSQL with TimescaleDB for time-series analytics. Design the API layer to serve real-time and historical data to the React frontend via REST and WebSocket.
|
||||
|
||||
2. **Build the global threat map** by ingesting data from threat intelligence feeds (GreyNoise, AbuseIPDB, AlienVault OTX) and geolocating attacking IPs using MaxMind GeoIP2. Render an interactive world map in React using a mapping library showing real-time attack origins, destination concentrations, attack type classification (scanning, brute force, exploitation), and animated connection lines between source and target regions. Aggregate by country, ASN, and threat category.
|
||||
|
||||
3. **Implement the CVE velocity tracker** pulling from the NVD API (National Vulnerability Database) with real-time monitoring for new CVE publications. Display CVEs with CVSS 3.1 scoring, severity badges, affected technologies, and trending indicators. Build analytics showing publication velocity (CVEs per day/week), severity distribution trends, most targeted technology stacks, and highlight critical CVEs (CVSS 9.0+) with special alerts. Include EPSS (Exploit Prediction Scoring System) data to predict which CVEs will be exploited.
|
||||
|
||||
4. **Create the threat actor leaderboard** using MITRE ATT&CK data and open threat intelligence to track known APT groups. Display each group's attributed campaigns, targeted sectors and geographies, TTPs (Tactics, Techniques, and Procedures) mapped to ATT&CK, and activity recency. Build a ranking system based on recent campaign frequency, target diversity, and technique sophistication. Link to detailed group profiles with IOCs.
|
||||
|
||||
5. **Build the exploit availability monitor** that tracks the lifecycle from CVE publication to weaponized exploit. Monitor sources including GitHub (PoC repositories), Exploit-DB, Metasploit module additions, and nuclei template releases. Calculate and display time-to-exploit metrics: average days from CVE to first PoC, from PoC to weaponized exploit, and from exploit to mass scanning. Alert when critical CVEs get weaponized.
|
||||
|
||||
6. **Implement social media threat intelligence** by aggregating security researcher posts from Twitter/X API (or Mastodon) and RSS feeds from security blogs. Use keyword filtering and NLP to surface posts about new vulnerabilities, active exploitation, zero-days, and incident reports. Often these posts break news hours before official feeds. Display in a real-time feed with source credibility scoring.
|
||||
|
||||
7. **Build the React dashboard frontend** with a SOC-style layout designed for large displays: the global threat map as the centerpiece, CVE velocity charts and critical alerts along the top, threat actor activity and exploit availability panels on the sides, and the social media feed as a scrolling ticker. Implement dark mode (essential for SOC environments), configurable refresh intervals, customizable panel layouts, and full-screen presentation mode.
|
||||
|
||||
8. **Add infrastructure correlation and alerting** where users can input their own technology stack (languages, frameworks, cloud providers, specific product versions) and the dashboard correlates global threats against their exposure. Highlight when a new CVE affects their stack, when an exploit drops for a vulnerability in their infrastructure, or when threat actors targeting their sector become active. Send alerts via Slack, Discord, PagerDuty, or email.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Threat intelligence aggregation and normalization
|
||||
- CVE lifecycle and CVSS scoring
|
||||
- MITRE ATT&CK framework and threat actor tracking
|
||||
- Exploit prediction and weaponization tracking
|
||||
- IP geolocation and attack visualization
|
||||
- Real-time data streaming with WebSockets
|
||||
- Time-series analytics and trend detection
|
||||
- SOC dashboard design and operational workflows
|
||||
|
||||
## Deliverables
|
||||
- FastAPI backend with async data collection
|
||||
- Global threat map with real-time IP geolocation
|
||||
- CVE velocity tracker with EPSS scoring
|
||||
- Threat actor leaderboard with ATT&CK mapping
|
||||
- Exploit availability monitor with weaponization timelines
|
||||
- Social media threat intelligence feed
|
||||
- React SOC-style dashboard with configurable panels
|
||||
- Infrastructure correlation and personalized alerting
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
# ARP Spoofing Detector
|
||||
|
||||
## Overview
|
||||
Build a network security tool that monitors Address Resolution Protocol (ARP) traffic to detect spoofing attacks where attackers forge ARP messages to intercept network traffic. This project teaches layer 2 network attacks, ARP protocol mechanics, and demonstrates fundamental network intrusion detection techniques.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand ARP protocol and spoofing attacks** by learning that ARP (Address Resolution Protocol) maps IP addresses to MAC addresses on local networks, and that ARP spoofing (also called ARP poisoning) involves sending forged ARP messages claiming an attacker's MAC address is associated with legitimate IPs. Study attack mechanics: when a victim trusts the forged ARP, it sends traffic destined for a legitimate IP to the attacker instead, enabling man-in-the-middle (MITM) attacks, session hijacking, and network disruption.
|
||||
|
||||
2. **Implement ARP packet capture** using `scapy` to sniff network traffic and filter for ARP packets specifically. Extract relevant information from each ARP packet: source MAC address, source IP, destination MAC address, destination IP, and operation type (request vs. reply). Understand that detecting ARP spoofing requires analyzing patterns rather than individual packets since ARP is legitimate protocol with normal variation.
|
||||
|
||||
3. **Build MAC-to-IP mapping database** that tracks the relationship between IP addresses and their legitimate MAC addresses on the network. Create a baseline of known-good mappings through active ARP scanning or passive observation over time, storing these mappings with timestamps and confidence levels. Use this database as reference to detect when a single IP suddenly claims to come from a different MAC address.
|
||||
|
||||
4. **Implement duplicate IP detection** by identifying when the same IP address is claimed by multiple different MAC addresses within a suspicious time window. Legitimate cases exist (like DHCP reassignment or IP changes), but rapid duplicates indicate spoofing. Implement heuristics distinguishing normal IP transitions (gradual, expected) from suspicious patterns (sudden, frequent changes, many IPs from one MAC).
|
||||
|
||||
5. **Create MAC address change detection** by monitoring when a previously known MAC-to-IP association changes, flagging unexpected transitions as suspicious. Track the source of the mapping change (was it a unicast ARP reply to this specific host, or broadcast to whole network?) and the frequency (legitimate changes happen infrequently while spoofing may generate many changes quickly).
|
||||
|
||||
6. **Add gratuitous ARP analysis** recognizing that legitimate hosts send gratuitous ARPs when joining networks or recovering from network issues, but attackers abuse this to poison ARP caches. Detect suspicious patterns: numerous gratuitous ARPs from single MAC, gratuitous ARPs announcing IPs the sender shouldn't legitimately possess, or targeted gratuitous ARPs after network changes.
|
||||
|
||||
7. **Implement alerting and logging** that notifies administrators when potential ARP spoofing is detected, including evidence (affected IPs, MAC addresses, ARP messages seen). Log all ARP traffic to files for forensic analysis, storing complete packet captures and statistical summaries enabling incident investigation and proving attacks occurred to stakeholders.
|
||||
|
||||
8. **Build comprehensive documentation** explaining ARP protocol mechanics and spoofing attack techniques, discussing detection methodology and limitations (cannot detect application-layer spoofing), and providing deployment guidance. Compare your detector to other tools (Arpwatch, Arpalert), discuss integration with network infrastructure (DHCP snooping, DAI - Dynamic ARP Inspection), and explain how ARP spoofing detection fits into broader network security monitoring strategies.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- ARP protocol and layer 2 networking
|
||||
- Man-in-the-middle attack techniques
|
||||
- Packet capture and analysis
|
||||
- Pattern recognition for attack detection
|
||||
- Statistical analysis of network behavior
|
||||
- Network intrusion detection systems
|
||||
|
||||
## Deliverables
|
||||
- Live ARP packet capture and analysis
|
||||
- MAC-to-IP mapping database and tracking
|
||||
- Duplicate IP detection
|
||||
- Suspicious MAC-to-IP association identification
|
||||
- Gratuitous ARP pattern analysis
|
||||
- Alerting and comprehensive logging
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Canary Token Generator
|
||||
|
||||
## Overview
|
||||
Build a self-hosted honeytoken system in Go that generates fake credentials (AWS keys, database connection strings, API keys), tripwire documents, and trackable URLs that alert you via webhook when accessed. When an attacker finds and uses these planted tokens, you get an immediate notification with details about who accessed them and from where. This project teaches deception-based defense, a technique used by major security teams to detect breaches that bypass traditional monitoring.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand honeytoken concepts** by studying how security teams plant fake credentials, documents, and URLs throughout their infrastructure as tripwires. When an attacker accesses a honeytoken, it proves a breach occurred because no legitimate user would ever touch them. Research Thinkst Canary Tokens, AWS honey credentials, and how organizations like Netflix use honeytokens in their security programs.
|
||||
|
||||
2. **Build a lightweight HTTP server in Go** that serves as the canary token backend. This server generates unique tokens, tracks them in an embedded database (SQLite or BoltDB), and handles incoming callbacks when tokens are triggered. Each token gets a unique identifier and callback URL that phones home when accessed.
|
||||
|
||||
3. **Implement credential token types** including fake AWS access keys (matching the AKIA format), database connection strings with embedded tracking, API keys that resolve to your monitoring endpoint, SSH private keys, and .env files containing trackable secrets. Each generated credential must look realistic enough that an attacker would attempt to use it.
|
||||
|
||||
4. **Create document and file tokens** such as PDF files with embedded tracking pixels, Word documents with external resource references, Excel files that phone home on open, and text files with unique identifiers. When opened, these files make a callback to your server revealing the opener's IP address, user agent, and timestamp.
|
||||
|
||||
5. **Build URL-based tokens** that generate unique tracking URLs disguised as internal admin panels, forgotten API endpoints, or sensitive-looking resources. Implement redirect tokens (redirect to a legitimate page after logging the access), DNS tokens (detect DNS resolution of unique hostnames), and email tokens (unique email addresses that trigger on receive).
|
||||
|
||||
6. **Implement the alerting system** with webhook support (Slack, Discord, generic HTTP), email notifications, and a simple web dashboard showing all triggered tokens with details: source IP, geolocation, user agent, timestamp, and which token was triggered. Include severity levels based on token type.
|
||||
|
||||
7. **Create deployment tooling** with scripts that scatter tokens across a filesystem, inject them into common locations attackers search (environment variables, config files, cloud credential directories), and a cleanup utility to remove all deployed tokens. Include Docker support for the monitoring server.
|
||||
|
||||
8. **Write documentation** explaining the theory of deception-based defense, how to strategically place tokens for maximum detection coverage, integration with incident response workflows, and comparison to commercial canary token services.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Deception-based defense strategies
|
||||
- HTTP server development in Go
|
||||
- Credential format specifications (AWS, API keys)
|
||||
- Webhook integration and alerting
|
||||
- IP geolocation and request forensics
|
||||
- Embedded database management
|
||||
- Token deployment automation
|
||||
|
||||
## Deliverables
|
||||
- Canary token generation server in Go
|
||||
- Multiple token types (credentials, documents, URLs, DNS)
|
||||
- Real-time alerting via webhooks and email
|
||||
- Web dashboard for monitoring triggered tokens
|
||||
- Deployment scripts for scattering tokens
|
||||
- Token cleanup and management utilities
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# DNS Sinkhole
|
||||
|
||||
## Overview
|
||||
Build a Pi-hole-style DNS sinkhole in Go that acts as a custom DNS server blocking malware domains, ad trackers, and known C2 (command and control) servers using community-maintained blocklists. The tool features blocklist management with automatic updates, query logging with analytics, whitelist/blacklist configuration, and a live web dashboard showing blocked queries, top blocked domains, and query statistics. This project teaches DNS protocol internals, network-level defense, and how DNS filtering protects entire networks at the resolution layer.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand DNS resolution and sinkhole concepts** by studying how DNS resolves domain names to IP addresses, how recursive and authoritative DNS servers work, and how a sinkhole intercepts DNS queries to return false results for blocked domains. Research Pi-hole's architecture, the DNS protocol (RFC 1035), and common blocklist formats (hosts file, domain list, ABP filter syntax).
|
||||
|
||||
2. **Implement a DNS server in Go** using a DNS library that listens on port 53 (UDP and TCP), parses incoming DNS queries, and responds with either legitimate answers (forwarded to upstream resolvers like 1.1.1.1 or 8.8.8.8) or sinkhole responses (0.0.0.0 or NXDOMAIN) for blocked domains. Handle common record types: A, AAAA, CNAME, MX, and TXT.
|
||||
|
||||
3. **Build the blocklist engine** that downloads and parses community blocklists (Steven Black's unified hosts, various malware domain lists, ad server lists, C2 domain lists) into an efficient in-memory data structure (trie or hash map) for fast O(1) lookups. Implement automatic blocklist updates on a configurable schedule, deduplication across multiple lists, and wildcard domain blocking.
|
||||
|
||||
4. **Add whitelist and custom blacklist support** allowing users to override blocklist decisions: whitelist domains that are incorrectly blocked (false positives), add custom blacklist entries for domains not in community lists, and support regex-based rules for flexible matching. Store configuration in a simple YAML or TOML file.
|
||||
|
||||
5. **Implement query logging and analytics** that records every DNS query with timestamp, source IP, queried domain, response type (blocked/allowed/cached), and upstream response time. Store logs in SQLite for querying. Calculate statistics: total queries, percentage blocked, top queried domains, top blocked domains, queries per client, and queries over time.
|
||||
|
||||
6. **Build a web dashboard** using Go's net/http with embedded static files that displays real-time query statistics, a live query log, top blocked/allowed domains charts, per-client statistics, and blocklist management (enable/disable lists, force updates, view block counts per list). Include a search function to check if a specific domain would be blocked and by which list.
|
||||
|
||||
7. **Add caching and performance optimization** with a DNS response cache that stores upstream answers with proper TTL handling, reducing latency and upstream query volume. Implement concurrent query processing, connection pooling to upstream resolvers, and benchmark the system to ensure it can handle household-level query volume without noticeable latency.
|
||||
|
||||
8. **Create deployment documentation** with setup instructions for configuring the sinkhole as a network's primary DNS server (router DHCP settings), Docker deployment option, systemd service configuration, and Raspberry Pi-specific instructions. Include troubleshooting guides for common issues like DNS loops and broken website functionality.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- DNS protocol and resolution process
|
||||
- DNS sinkhole and filtering concepts
|
||||
- Efficient data structures for domain lookup
|
||||
- Community blocklist ecosystems
|
||||
- Go HTTP server and web dashboard development
|
||||
- DNS caching and TTL management
|
||||
- Network-level defense strategies
|
||||
|
||||
## Deliverables
|
||||
- DNS server in Go with sinkhole capability
|
||||
- Community blocklist downloading and parsing
|
||||
- Whitelist/blacklist with regex support
|
||||
- Query logging with SQLite storage
|
||||
- Web dashboard with real-time statistics
|
||||
- DNS response caching with TTL
|
||||
- Docker and systemd deployment support
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
# File Integrity Monitor
|
||||
|
||||
## Overview
|
||||
Build a security tool that monitors specified directories for unauthorized file changes by computing and tracking checksums of files, alerting on modifications, additions, or deletions with timestamped logs. This project teaches cryptographic hashing, file system monitoring, and demonstrates core concepts used in enterprise security tools for detecting system compromise.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Implement checksum calculation functionality** using MD5 or SHA256 algorithms to generate fixed-length fingerprints of file contents—use the `hashlib` library to compute hashes efficiently, supporting both small files loaded entirely into memory and large files processed in chunks. Create a baseline snapshot of files in monitored directories by computing and storing checksums with associated metadata (filename, path, file size, modification time, timestamp of calculation).
|
||||
|
||||
2. **Build a persistent database** to store baseline checksums and monitored file information—use SQLite for simplicity or JSON files for portability, storing records of each file's name, path, size, and hash value. Structure the database to support multiple monitoring sessions and historical tracking so you can generate reports showing changes over time and identify patterns of tampering.
|
||||
|
||||
3. **Create a baseline snapshot command** that scans specified directories (recursively or non-recursively based on configuration), computes checksums for all files, and stores them in the database as the reference state. Include filtering capabilities to exclude certain file types, paths, or sizes, allowing users to focus monitoring on critical system files rather than monitoring entire directories including temporary or log files.
|
||||
|
||||
4. **Implement continuous monitoring** using file system watchers (Python's `watchdog` library) or periodic rescanning to detect when files change. Compare newly computed checksums against the stored baseline, tracking three types of events: modified files (checksum changed), new files (not in baseline), and deleted files (in baseline but no longer exist). Log each event with precise timestamps for forensic analysis.
|
||||
|
||||
5. **Add alerting capabilities** to notify administrators when suspicious changes are detected, supporting multiple alert channels (write to log file, email alerts, webhook notifications, system notifications). Implement alert severity levels distinguishing between critical files (immediate alert) and less important files (batch alerts), allowing administrators to tune notification frequency and avoid alert fatigue.
|
||||
|
||||
6. **Create reporting functionality** generating detailed logs and reports showing all detected changes with timestamps, file paths, before-and-after file sizes, and calculated checksums. Include summary statistics (total files monitored, changes detected, false positives if any) and provide export options (CSV, JSON, PDF) suitable for compliance documentation and forensic investigations.
|
||||
|
||||
7. **Build configuration management** allowing users to specify monitored directories, file filters, checksum algorithms, monitoring frequency, database location, and alert settings through configuration files. Include command-line arguments for common operations (create baseline, run monitor, generate report) making the tool convenient for both interactive and automated/scheduled use.
|
||||
|
||||
8. **Create comprehensive documentation** explaining file integrity monitoring concepts, discussing use cases (detecting system compromise, compliance monitoring, configuration drift detection), and providing deployment examples. Explain limitations (monitoring adds overhead, doesn't prevent modifications, only detects them), compare your tool to enterprise solutions like Tripwire or AIDE, and include guidance on responding to detected changes (isolating systems, analyzing logs, involving incident response).
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Cryptographic hash functions and checksums
|
||||
- File system operations and monitoring
|
||||
- Database design and persistence
|
||||
- Event logging and alerting systems
|
||||
- Compliance and forensic investigation
|
||||
|
||||
## Deliverables
|
||||
- Baseline checksum snapshot creation
|
||||
- Continuous file monitoring with change detection
|
||||
- SQLite or JSON database for checksum storage
|
||||
- Multi-channel alerting (logs, email, webhooks)
|
||||
- Detailed reporting with export formats
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
# Simple Firewall Log Parser
|
||||
|
||||
## Overview
|
||||
Build a tool that parses firewall logs from iptables, UFW, or pfSense to generate security reports on blocked connections, identify top attacking IPs, reveal most targeted ports, and visualize attack patterns. This project teaches log analysis, attack pattern recognition, and provides practical insights into network security incidents.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand firewall log formats** across different platforms—iptables logs typically appear in syslog with format "iptables: IN= OUT= SRC= DST= PROTO= SPT= DPT=", UFW uses similar formats with additional descriptors, and pfSense logs in a structured format with timestamp, rule, and traffic details. Research the specific format for each firewall type, document the fields available, and create parsing templates that extract source IP, destination IP, port numbers, protocol types, and action taken (ACCEPT/DROP).
|
||||
|
||||
2. **Implement robust log file parsing** by reading firewall log files and extracting key information using regular expressions or structured parsing libraries. Handle variations in log formatting, incomplete entries, and corrupted lines gracefully, implementing error handling that continues processing even when encountering malformed data. Support multiple log file formats through pluggable parsers or conditional logic.
|
||||
|
||||
3. **Create connection analysis functions** that aggregate blocked connections by source IP to identify the most active attackers, track which ports are most frequently targeted to reveal attack focus, and calculate attack frequency over time periods. Identify patterns like port scanning (attempts on many different ports from single source) vs. focused attacks (repeated attempts on specific ports/services).
|
||||
|
||||
4. **Build IP geolocation and reputation lookup** by integrating with APIs or local databases to identify where attacking IPs are located geographically and whether they're known malicious sources. Add context about ISP, hosting provider, and known threat intelligence about each attacking IP, helping analysts understand attack sources and patterns.
|
||||
|
||||
5. **Implement protocol and service analysis** by mapping target ports to common services (port 22 = SSH, 80 = HTTP, 443 = HTTPS, 3306 = MySQL, etc.) and analyzing protocol distribution to understand what services are being targeted. Identify unusual protocol combinations or suspicious port selections that might indicate specific attack types or reconnaissance.
|
||||
|
||||
6. **Create timeline and temporal analysis** showing when attacks occur (time of day, day of week, trending patterns), identifying whether attacks are persistent, escalating, or sporadic. Build heatmaps showing attack intensity over time and detect anomalies like sudden spikes in firewall blocks that might indicate coordinated attacks.
|
||||
|
||||
7. **Generate comprehensive reports** in multiple formats (HTML dashboards, PDF reports, JSON data) showing top attacking IPs ranked by frequency, most targeted ports with attack counts, geographic distribution of attackers, and timeline visualizations. Include summary statistics (total blocked connections, unique attackers, ports targeted) and highlight the most critical findings for executive visibility.
|
||||
|
||||
8. **Build comprehensive documentation** explaining firewall log analysis concepts, providing examples of parsed logs, and discussing how this analysis fits into incident response and security operations workflows. Include guidance on interpreting results (distinguishing research traffic from actual attacks), discussing legitimate reasons for blocks, and providing recommendations for response actions (blocking IPs, alerting administrators, investigating incidents).
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Firewall configuration and log formats
|
||||
- Regular expressions and text parsing
|
||||
- Data aggregation and statistical analysis
|
||||
- IP geolocation and threat intelligence
|
||||
- Timeline analysis and temporal patterns
|
||||
- Security event investigation
|
||||
|
||||
## Deliverables
|
||||
- Multi-format firewall log parser (iptables, UFW, pfSense)
|
||||
- Blocked connection analysis and aggregation
|
||||
- Top attacking IPs and targeted ports identification
|
||||
- Temporal analysis and attack pattern detection
|
||||
- IP reputation and geolocation lookup
|
||||
- Multi-format reporting and dashboards
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Ghost on the Wire
|
||||
|
||||
## Overview
|
||||
Build a Layer 2 attack and defense toolkit using Python and Scapy that combines MAC address spoofing, ARP cache poisoning, ARP spoof detection, and a real-time network trust map into a single tool. This project teaches the fundamentals of Layer 2 networking, how man-in-the-middle attacks work at the data link layer, and how to detect and defend against them—covering both the red team and blue team perspectives in one project.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand Layer 2 networking fundamentals** by studying how MAC addresses identify devices on a local network, how ARP (Address Resolution Protocol) maps IP addresses to MAC addresses, and why ARP has no authentication mechanism—any device can claim to be any IP address. Research the ARP cache, gratuitous ARP packets, and how switches forward frames based on MAC addresses.
|
||||
|
||||
2. **Implement MAC address spoofing** that changes your network interface's MAC address programmatically. Include vendor OUI (Organizationally Unique Identifier) lookup so you can impersonate specific device manufacturers, random MAC generation for anonymity, and MAC address restoration to the original hardware address. Handle interface down/up cycling required for MAC changes on Linux.
|
||||
|
||||
3. **Build ARP cache poisoning functionality** using Scapy to craft and send forged ARP reply packets that associate your MAC address with another device's IP address—the core of a man-in-the-middle attack at Layer 2. Implement continuous ARP poisoning (targets' ARP caches expire and need re-poisoning), bidirectional poisoning for full MITM position, and IP forwarding to maintain network connectivity for the victim.
|
||||
|
||||
4. **Create real-time ARP spoof detection** that monitors the network for signs of ARP poisoning: duplicate IP-to-MAC mappings, rapid ARP reply floods, MAC addresses that change unexpectedly, and gratuitous ARP packets from suspicious sources. Build a baseline of known device-to-MAC associations and alert when deviations occur.
|
||||
|
||||
5. **Develop a Layer 2 trust map** that continuously scans the local network and maintains a real-time map of all devices: their IP addresses, MAC addresses, vendor identification (via OUI), first-seen and last-seen timestamps, and a trust score based on behavioral consistency. Flag devices exhibiting spoofing behavior or whose MAC addresses don't match expected vendors.
|
||||
|
||||
6. **Build a TUI (terminal user interface) dashboard** using a library like Rich or Textual that displays the network trust map in real-time, shows active ARP poisoning attempts (both yours and detected external ones), highlights suspicious devices, and provides a command interface for switching between offensive and defensive modes.
|
||||
|
||||
7. **Add network reconnaissance capabilities** including passive host discovery (listening for ARP broadcasts), active ARP scanning to enumerate all devices on a subnet, OS fingerprinting based on ARP timing characteristics, and switch/router detection via MAC address table analysis.
|
||||
|
||||
8. **Create documentation covering both offensive and defensive perspectives** with legal warnings about unauthorized network attacks, explanation of how enterprise NAC (Network Access Control) prevents these attacks, detection techniques used by commercial IDS/IPS systems, and comparison to tools like arpspoof, ettercap, and Bettercap.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- ARP protocol mechanics and vulnerabilities
|
||||
- MAC address structure and OUI vendor identification
|
||||
- Man-in-the-middle attacks at Layer 2
|
||||
- Scapy packet crafting and network interaction
|
||||
- ARP spoof detection techniques
|
||||
- Network trust modeling
|
||||
- TUI dashboard development
|
||||
|
||||
## Deliverables
|
||||
- MAC address spoofer with vendor OUI lookup
|
||||
- ARP cache poisoner with bidirectional MITM
|
||||
- Real-time ARP spoof detection engine
|
||||
- Layer 2 network trust map with scoring
|
||||
- TUI dashboard with offensive/defensive modes
|
||||
- Passive and active network reconnaissance
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# LLM Prompt Injection Firewall
|
||||
|
||||
## Overview
|
||||
Build a middleware layer in Python that sits between users and LLM APIs to detect and block prompt injection attacks, jailbreak attempts, and data extraction techniques before they reach the model. The firewall uses pattern matching, input sanitization, and heuristic analysis to classify threat levels in user inputs, maintaining a test suite of known injection techniques and a scoring system for risk assessment. This is the most modern cybersecurity project possible—as LLMs become infrastructure, securing them is the new application security.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Study prompt injection attack taxonomy** by researching the major categories: direct injection (overriding system prompts with "ignore previous instructions"), indirect injection (hidden instructions in retrieved documents), jailbreaking (DAN, roleplay-based bypasses), data extraction (getting the model to reveal system prompts or training data), and encoding-based attacks (base64, ROT13, leetspeak to bypass filters). Build a comprehensive test suite of 50+ known techniques.
|
||||
|
||||
2. **Implement the HTTP proxy middleware** that intercepts API calls to LLM providers (OpenAI, Anthropic, etc.), inspects the user message content before forwarding, applies detection rules, and either allows, modifies, or blocks the request based on threat assessment. Return informative error messages when requests are blocked, explaining what was detected without revealing detection specifics.
|
||||
|
||||
3. **Build pattern-based detection** using regular expressions and string matching for known injection patterns: "ignore previous instructions," "you are now," "pretend you are," system prompt extraction attempts, encoding indicators (base64 strings, hex sequences), and role-switching language. Weight patterns by specificity—exact known jailbreak phrases score higher than generic suspicious language.
|
||||
|
||||
4. **Implement heuristic analysis** beyond simple pattern matching: measure input entropy (encoded payloads have unusual character distributions), detect language switching (injection attempts often switch between natural language and instruction language), identify nested instruction formats (XML tags, markdown formatting used to confuse prompt boundaries), and flag unusual input length distributions.
|
||||
|
||||
5. **Add input sanitization capabilities** that can optionally modify rather than block suspicious inputs: strip potential injection delimiters, escape special formatting characters, truncate excessively long inputs, and normalize Unicode to prevent homoglyph-based bypasses. Allow configuration of whether to block, sanitize, or log-only for each threat category.
|
||||
|
||||
6. **Build the scoring and decision engine** that combines all detection signals into a composite threat score (0-100) with configurable thresholds for allow, warn, and block actions. Log all decisions with full details for security review. Implement learning mode that logs everything but blocks nothing, useful for tuning thresholds before enforcement.
|
||||
|
||||
7. **Create an admin dashboard** (simple Flask/FastAPI web UI) showing real-time request flow, blocked requests with reasons, threat score distribution, most common attack patterns seen, and false positive review queue where admins can mark blocked requests as legitimate to improve detection.
|
||||
|
||||
8. **Write documentation** covering the prompt injection threat landscape, OWASP Top 10 for LLMs, defense-in-depth strategies (this firewall is one layer, not the only defense), comparison to commercial solutions (Rebuff, LLM Guard), and guidance on tuning detection thresholds for different risk tolerances.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Prompt injection attack techniques and taxonomy
|
||||
- LLM security and OWASP Top 10 for LLMs
|
||||
- HTTP proxy and middleware design
|
||||
- Pattern matching and heuristic analysis
|
||||
- Input sanitization and normalization
|
||||
- Risk scoring and decision engines
|
||||
- Security logging and monitoring
|
||||
|
||||
## Deliverables
|
||||
- HTTP proxy middleware for LLM API interception
|
||||
- Pattern-based injection detection engine
|
||||
- Heuristic analysis (entropy, language switching, nesting)
|
||||
- Input sanitization with configurable modes
|
||||
- Composite threat scoring with tunable thresholds
|
||||
- Admin dashboard for monitoring and tuning
|
||||
- Test suite of 50+ known injection techniques
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Linux CIS Hardening Auditor
|
||||
|
||||
## Overview
|
||||
Build a comprehensive CIS (Center for Internet Security) benchmark compliance checker written entirely in Bash that audits a Linux system against Level 1 and Level 2 security benchmarks. The tool checks SSH configuration, firewall rules, file permissions, user accounts, kernel parameters, running services, and filesystem mounts, generating a scored compliance report with pass/fail/warn results for each control. This project teaches system hardening, compliance frameworks, and advanced Bash scripting through real security assessment.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Study the CIS benchmark structure** by reviewing the CIS Benchmark for your target distribution (Debian/Ubuntu). Understand the control categories: initial setup (filesystem, updates, boot), services (inetd, special purpose, service clients), network configuration (network parameters, firewall, wireless), logging and auditing (configure logging, ensure auditing), access/authentication (cron, SSH, PAM, user accounts), and system maintenance (file permissions, user settings).
|
||||
|
||||
2. **Build the audit framework** as a modular Bash script with a consistent check pattern: each control is a function that tests a specific configuration, returns pass/fail/warn/skip with evidence, and logs the result. Implement color-coded terminal output, a scoring engine that tracks compliance percentage, and structured output (JSON) for programmatic consumption.
|
||||
|
||||
3. **Implement filesystem and boot checks** verifying: separate partitions for /tmp, /var, /var/log with noexec/nosuid mount options, sticky bit on world-writable directories, disabled automounting, GPG-verified package repositories, AIDE or similar file integrity monitoring configured, and bootloader password protection.
|
||||
|
||||
4. **Add service and network auditing** checking: unnecessary services disabled (avahi, cups, DHCP, LDAP, NFS, DNS, FTP, HTTP, IMAP, Samba, squid, SNMP, rsync), network parameters hardened (IP forwarding disabled, ICMP redirects rejected, suspicious packet logging, TCP SYN cookies, IPv6 router advertisements), and firewall (iptables/nftables) rules ensuring default deny policy.
|
||||
|
||||
5. **Implement access control and authentication checks** for: cron job permissions, SSH hardening (Protocol 2, MaxAuthTries, PermitRootLogin, PermitEmptyPasswords, X11Forwarding, AllowUsers/Groups, cipher suites, MACs, key exchange algorithms), PAM configuration (password quality, failed login lockout, password reuse), password policy (maxdays, mindays, warndays, inactive), and root account restrictions.
|
||||
|
||||
6. **Build logging and audit checks** verifying: rsyslog or journald configured with appropriate retention, auditd installed and running with rules for privileged commands, file access monitoring, user/group changes, and system administration actions. Check log file permissions prevent unauthorized access.
|
||||
|
||||
7. **Create the compliance report generator** that produces a summary showing overall compliance score (percentage), score per category, individual control results with evidence, remediation commands for failed controls, and comparison against previous audit runs (if a baseline exists). Output formats: terminal (colored), JSON, and HTML.
|
||||
|
||||
8. **Write documentation** explaining CIS benchmark levels (Level 1 vs Level 2), how to interpret results, remediation priorities, and how to establish a baseline and track compliance over time. Include guidance on which controls may need exceptions in specific environments and how to document those exceptions.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- CIS benchmark framework and control categories
|
||||
- Linux system hardening best practices
|
||||
- SSH, PAM, and authentication security
|
||||
- Firewall configuration and network hardening
|
||||
- Audit logging and monitoring
|
||||
- Advanced Bash scripting patterns
|
||||
- Compliance reporting and scoring
|
||||
|
||||
## Deliverables
|
||||
- Modular Bash audit framework
|
||||
- 100+ CIS benchmark control checks
|
||||
- Filesystem, network, service, and access auditing
|
||||
- Scored compliance report (terminal, JSON, HTML)
|
||||
- Remediation command suggestions
|
||||
- Baseline comparison capability
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Linux eBPF Security Tracer
|
||||
|
||||
## Overview
|
||||
Build a real-time security monitoring tool using eBPF (extended Berkeley Packet Filter) with Python and C that traces system calls, detects suspicious process behavior, monitors file integrity, and tracks network connections at the kernel level. Using the BCC (BPF Compiler Collection) framework, this project attaches eBPF programs to kernel events to provide deep observability without modifying the kernel or installing kernel modules. This teaches the most modern Linux security observability technology used by tools like Falco, Cilium, and Tetragon.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand eBPF fundamentals** by learning how eBPF programs run sandboxed inside the Linux kernel, triggered by events like system calls, function entries, and network events. Unlike kernel modules, eBPF programs are verified for safety before loading and cannot crash the kernel. Study the BCC framework which lets you write eBPF programs in C and control them from Python.
|
||||
|
||||
2. **Implement system call tracing** by attaching eBPF kprobes to security-relevant syscalls: execve (process execution), open/openat (file access), connect (network connections), ptrace (process debugging/injection), and clone/fork (process creation). Capture the calling process, arguments, return values, and timestamps for each traced syscall.
|
||||
|
||||
3. **Build process execution monitoring** that logs every new process spawned on the system with its full command line, parent process, user ID, and working directory. Detect suspicious patterns: processes spawned by web servers (potential RCE), shells spawned by non-interactive services, and processes attempting to delete themselves after execution.
|
||||
|
||||
4. **Implement file access monitoring** by tracing open/openat/unlink syscalls for sensitive paths: /etc/passwd, /etc/shadow, SSH keys, cron directories, and systemd unit paths. Alert when unexpected processes access these files, detecting potential credential theft, persistence installation, or configuration tampering.
|
||||
|
||||
5. **Add network connection tracking** by tracing connect() and accept() syscalls to log all outbound and inbound connections with source/destination IPs, ports, and the process responsible. Flag connections to known-bad IP ranges, unusual ports, or connections from processes that shouldn't be making network requests (like cron or systemd-resolved connecting to non-DNS ports).
|
||||
|
||||
6. **Create privilege escalation detection** by monitoring setuid/setgid syscalls, capability changes, and transitions from unprivileged to privileged execution. Detect when processes gain unexpected privileges, when SUID binaries are executed, or when capabilities are added to running processes.
|
||||
|
||||
7. **Build a TUI dashboard** using Rich or similar library that displays live security events in a scrolling log, maintains counters for different event types, highlights critical alerts, and allows filtering by event type, process name, or severity. Include a summary panel showing the most active processes, most accessed sensitive files, and most frequent network destinations.
|
||||
|
||||
8. **Write documentation** explaining eBPF architecture, how the BCC framework bridges kernel C and Python userspace, performance considerations for production use, and comparison to other monitoring approaches (auditd, inotify, strace). Include guidance on which syscalls to trace for different threat models.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- eBPF program architecture and safety model
|
||||
- BCC framework for kernel tracing
|
||||
- System call interface and security implications
|
||||
- Process execution and privilege monitoring
|
||||
- File access auditing at the kernel level
|
||||
- Network connection tracking
|
||||
- Real-time event processing and alerting
|
||||
|
||||
## Deliverables
|
||||
- eBPF programs for syscall tracing (C)
|
||||
- Python control plane with BCC integration
|
||||
- Process execution and privilege escalation detection
|
||||
- File access monitoring for sensitive paths
|
||||
- Network connection tracking and alerting
|
||||
- TUI dashboard with live security events
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
# MAC Address Spoofer
|
||||
|
||||
## Overview
|
||||
Create a tool that changes network interface MAC addresses on Linux and Windows systems to test network configuration, improve privacy, or avoid network-based access controls. This project teaches network interface manipulation, platform-specific system administration, and demonstrates why network security can't rely solely on MAC address filtering.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand MAC addresses and network interfaces** by learning that Media Access Control (MAC) addresses are hardware identifiers assigned to network interface cards (NICs) on the data link layer. MAC addresses are typically 48 bits represented as six hexadecimal pairs (e.g., 00:1A:2B:3C:4D:5E), and each manufacturer is assigned a specific prefix—MAC addresses are local to the network and not routable on the internet like IP addresses.
|
||||
|
||||
2. **Research platform-specific techniques** for changing MAC addresses: on Linux, network interfaces are typically managed through `ifconfig`, `ip`, or network manager tools; on Windows, registry modifications or driver-level changes may be necessary. Understand that MAC spoofing requires administrator/root privileges and that different Linux distributions and Windows versions have different methods requiring careful implementation.
|
||||
|
||||
3. **Implement Linux MAC address modification** using subprocess calls to `ip link set` or `ifconfig` commands to change the MAC address. First disable the network interface, apply the new MAC address, then re-enable it. Handle different interface naming conventions (eth0, wlan0, enp0s3, etc.) and gracefully report errors if the interface doesn't exist or operations fail.
|
||||
|
||||
4. **Add Windows MAC address modification** support by modifying registry keys or using WMI (Windows Management Instrumentation) to update network adapter settings. Document Windows-specific limitations and compatibility issues across different Windows versions, and note when administrator elevation is required.
|
||||
|
||||
5. **Create MAC address validation** to ensure user-provided addresses are properly formatted and theoretically valid. Verify correct hexadecimal formatting, ensure the address is 48 bits (six octets), optionally validate that the address doesn't conflict with reserved ranges, and handle unicast vs. multicast address requirements.
|
||||
|
||||
6. **Implement automatic backup and restoration** by storing the original MAC address before modification so users can easily revert to factory settings. Create functions to restore the original address, and include a restore-on-exit feature that automatically reverts MAC addresses if the program is interrupted (via signal handlers or try/finally blocks).
|
||||
|
||||
7. **Add realistic MAC address generation** by optionally generating new MAC addresses that match real manufacturer prefixes (OUI - Organizationally Unique Identifier). Parse a database of known manufacturer prefixes and generate convincing MAC addresses that won't raise suspicion if logged—this teaches data realism in security testing scenarios.
|
||||
|
||||
8. **Build comprehensive documentation** explaining how MAC addresses work, discussing legitimate use cases (testing network behavior, privacy on local networks, testing MAC filtering), and including warnings about network policy violations if performed on corporate networks. Provide platform-specific usage examples, explain MAC address limitations for security (MAC filtering is easily spoofed), and discuss how proper network security uses stronger authentication methods beyond MAC addresses.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- MAC address format and purpose
|
||||
- Network interface management
|
||||
- Platform-specific system administration
|
||||
- Subprocess execution and error handling
|
||||
- Privilege requirements and security implications
|
||||
- OUI database and manufacturer prefixes
|
||||
|
||||
## Deliverables
|
||||
- Linux and Windows MAC address modification support
|
||||
- Original MAC address backup and restoration
|
||||
- MAC address validation and formatting
|
||||
- Realistic MAC address generation with manufacturer prefixes
|
||||
- Comprehensive error handling and permission checking
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Phishing Domain Generator & Quishing Scanner
|
||||
|
||||
## Overview
|
||||
Build a dual-purpose phishing detection tool that generates every possible typosquat variant of a legitimate domain (homoglyphs, bit-flips, keyboard adjacency, TLD swaps) and checks which variants are actually registered, combined with a QR code phishing ("quishing") scanner that analyzes QR codes for malicious destinations. This project covers both traditional domain-based phishing and the rapidly growing QR phishing vector that exploded in 2024-2025.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand domain-based phishing techniques** including typosquatting (gooogle.com), homoglyph attacks (using Cyrillic characters that look identical to Latin—аpple.com vs apple.com), bit-flipping (domains reachable via single-bit DNS errors), keyboard adjacency substitution (gmai.com), TLD variations (.com vs .co), and subdomain abuse (apple.com.evil.com). Research IDN homograph attacks and how browsers handle internationalized domain names.
|
||||
|
||||
2. **Build the domain variant generator** that takes a legitimate domain and produces every possible typosquat permutation: character omission, character repetition, character swap, adjacent keyboard substitution, homoglyph replacement (with a comprehensive Unicode confusable database), bit-flip variants, TLD swaps across common TLDs, and hyphenation variants. This can produce thousands of candidates for a single domain.
|
||||
|
||||
3. **Implement registration checking** that tests which generated domain variants are actually registered using DNS resolution, WHOIS lookups, and certificate transparency log searches. Rate-limit queries to avoid being blocked, implement concurrent lookups for speed, and cache results. Flag registered domains with risk scoring based on how visually similar they are to the legitimate domain.
|
||||
|
||||
4. **Add domain intelligence enrichment** for registered typosquats: WHOIS registration date (recently registered domains are more suspicious), hosting provider, SSL certificate details, website content similarity comparison, and presence in known phishing databases (PhishTank, OpenPhish). Generate a threat report ranking discovered typosquats by risk level.
|
||||
|
||||
5. **Build the QR code phishing scanner** that decodes QR codes from images or camera input and analyzes the embedded URL for phishing indicators: domain reputation, URL shortener detection and expansion, redirect chain following, homoglyph detection in the destination domain, and comparison against known phishing databases. Implement batch scanning for analyzing multiple QR codes from photos of public spaces.
|
||||
|
||||
6. **Create QR code generation for testing** that produces QR codes demonstrating various quishing techniques: URL shortener obfuscation, redirect chains, data URI abuse, and Unicode tricks. These test QR codes help security teams understand what malicious QR codes look like and train employees to be suspicious.
|
||||
|
||||
7. **Build a CLI interface with reporting** that supports single-domain analysis, batch domain monitoring, QR image scanning, and generates reports in multiple formats (JSON, HTML, CSV) showing all discovered threats with evidence and risk scores. Include a watch mode that periodically re-checks domains for new registrations.
|
||||
|
||||
8. **Document real-world phishing campaigns** that used these techniques, including the 2023 Microsoft QR phishing campaign, homoglyph attacks against cryptocurrency exchanges, and typosquatting campaigns targeting npm/PyPI package names. Explain defensive measures including DMARC, browser IDN policies, and QR code verification best practices.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Domain name system and typosquatting techniques
|
||||
- Unicode homoglyph and IDN attacks
|
||||
- QR code structure and error correction
|
||||
- DNS resolution and WHOIS queries
|
||||
- Phishing detection and threat intelligence APIs
|
||||
- Certificate transparency logs
|
||||
- Batch processing and concurrent I/O
|
||||
|
||||
## Deliverables
|
||||
- Comprehensive typosquat domain variant generator
|
||||
- Registration checker with DNS/WHOIS/CT lookups
|
||||
- Domain intelligence enrichment and risk scoring
|
||||
- QR code phishing scanner with URL analysis
|
||||
- Test QR code generator for security awareness
|
||||
- CLI with reporting (JSON, HTML, CSV)
|
||||
- Watch mode for continuous monitoring
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
# Phishing URL Detector
|
||||
|
||||
## Overview
|
||||
Build a tool that analyzes URLs for common phishing indicators like suspicious TLDs, typosquatting patterns, URL shorteners, and checks against safe browsing APIs to calculate a risk score. This project teaches URL analysis, API integration, threat intelligence, and demonstrates techniques for identifying phishing attacks before users click malicious links.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Learn URL structure and phishing indicators** by understanding that phishing URLs often use suspicious top-level domains (TLDs), homograph attacks (lookalike characters: rn vs m), subdomain manipulation (legitimate-looking subdomains hiding malicious hosts), and URL shorteners hiding actual destinations. Study common phishing patterns like using IP addresses instead of domain names, unusual ports, and excessive URL length—create a reference database of known phishing techniques.
|
||||
|
||||
2. **Implement URL parsing and validation** using Python's `urllib.parse` to break URLs into components (scheme, netloc, path, query, fragment), validating proper formatting and extracting the actual destination if shorteners are involved. Build logic to detect encoded characters, unusual character combinations, and structural anomalies that might indicate obfuscation or evasion techniques.
|
||||
|
||||
3. **Create a TLD and domain reputation checker** that maintains or accesses a database of suspicious top-level domains and newly registered domains known for phishing. Check whether the domain was recently registered (domains aged less than 6 months are higher risk) and whether it's registered with anonymized WHOIS information (privacy service registration is common in phishing domains).
|
||||
|
||||
4. **Implement typosquatting detection** by comparing the domain name against popular legitimate domains using string similarity algorithms (Levenshtein distance, fuzzy matching). Identify common misspellings and near-homographs (0 for O, 1 for l, rn for m) that could fool users into visiting malicious sites resembling legitimate services they know.
|
||||
|
||||
5. **Integrate with safe browsing APIs** like Google Safe Browsing or other threat intelligence services to check whether URLs are known to be malicious or phishing targets. These services maintain lists of known bad URLs accumulated through user reports and automated scanning—implement API calls with proper error handling for rate limiting and service unavailability.
|
||||
|
||||
6. **Build domain-based checks** extracting and analyzing the domain name and subdomain structure: verify that the domain is registered to a legitimate organization, check for suspicious subdomains (e.g., www-secure-verify-account.badphishing.com mimicking legitimate verification URLs), and flag unusual port numbers or protocols.
|
||||
|
||||
7. **Create a risk scoring algorithm** that combines multiple detection methods into a comprehensive risk score (0-100) synthesizing results from TLD checks, registrar reputation, safe browsing API results, typosquatting detection, and structural analysis. Categorize URLs as safe (green), suspicious (yellow), or dangerous (red) with explanations of which factors contributed to the risk assessment, enabling users to understand the reasoning.
|
||||
|
||||
8. **Build a command-line and/or web interface** accepting individual URLs or bulk URL lists for analysis, generating detailed reports showing risk scores, identified indicators, recommended actions, and educational information. Create comprehensive documentation explaining phishing indicators, providing examples of legitimate vs. suspicious URLs, and including guidance on what to do if a phishing URL is detected (reporting mechanisms, secure notification of users).
|
||||
|
||||
## Key Concepts to Learn
|
||||
- URL structure and parsing
|
||||
- Phishing techniques and evasion methods
|
||||
- API integration and threat intelligence
|
||||
- String similarity and pattern matching
|
||||
- Risk scoring and algorithm design
|
||||
- Bulk analysis and reporting
|
||||
|
||||
## Deliverables
|
||||
- URL structure analysis and validation
|
||||
- Phishing indicator detection (TLD, typosquatting, suspicious patterns)
|
||||
- Safe Browsing API integration
|
||||
- Domain reputation and WHOIS analysis
|
||||
- Risk scoring algorithm (0-100)
|
||||
- Bulk URL analysis with detailed reporting
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
# Simple Ransomware Simulator
|
||||
|
||||
## Overview
|
||||
Build an educational tool that safely demonstrates file encryption without causing actual damage, allowing security professionals to understand ransomware mechanics, test backup/recovery procedures, and train staff on ransomware awareness. This project teaches encryption implementation, secure file handling, and demonstrates ransomware attack workflows for defensive purposes.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Establish ethical boundaries and safety mechanisms** by creating a tool that works only on specifically designated test directories and cannot propagate to system files or other critical locations. Build in extensive warnings, confirmations, and ability to run in dry-run mode showing what would be encrypted without actually modifying files. Implement audit logging capturing every action for accountability and post-simulation analysis.
|
||||
|
||||
2. **Implement encryption using Python's cryptography library** (specifically `cryptography.fernet` or `cryptography.hazmat.primitives.ciphers`) to encrypt test files with strong symmetric encryption. Generate and store encryption keys in a controlled location, implement proper key management, and ensure encryption is genuinely strong (not simulated/weak encryption). Test encryption/decryption on sample files to verify the mechanism works correctly.
|
||||
|
||||
3. **Create isolated test environment setup** that prepares a designated directory structure for simulation: creates subdirectories with various file types (documents, images, databases), populates with realistic test data that looks like sensitive information, and establishes baseline file hashes for verification. Include instructions for users to test their backup/recovery procedures using this controlled test environment.
|
||||
|
||||
4. **Build file encryption logic** that recursively traverses the test directory structure, encrypts each file using the generated key, and optionally renames files to include encryption extension (e.g., .encrypted) mimicking real ransomware. Implement proper error handling so that if encryption fails on any file, the simulator can be stopped and rolled back, preventing accidental damage from bugs.
|
||||
|
||||
5. **Implement decryption capability** allowing authorized users to recover encrypted test files when the exercise is complete. Create a decryption utility requiring the encryption key, providing straightforward recovery process. Use this as educational moment: explain that real ransomware victims either pay ransoms (often ineffective) or lose data, while this controlled simulation provides recovery automatically.
|
||||
|
||||
6. **Add educational content and ransom note simulation** creating a text file that displays during/after encryption explaining how ransomware works, what just happened in the simulation, what recovery procedures should be followed, and key takeaways about prevention (backups, updates, email security). Make educational content the focus rather than ransom demands—this emphasizes defensive goals.
|
||||
|
||||
7. **Create comprehensive reporting and analysis tools** generating reports on what was encrypted, which files were affected, encryption statistics, time elapsed, and recovery verification. Build dashboards showing encryption progress, recovery status, and lessons learned from the simulation exercise, suitable for post-exercise debriefs with security teams.
|
||||
|
||||
8. **Build extensive documentation** emphasizing that this tool is for educational and authorized testing only—never use on systems without explicit permission from system owners. Include detailed setup instructions, disaster recovery procedures, staff training guidelines showing how to use the simulator for ransomware awareness training, and legal warnings about unauthorized testing. Compare to real ransomware techniques, discuss actual ransomware examples and their impact, and explain how understanding ransomware mechanics improves defense strategies.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Symmetric encryption and key management
|
||||
- File system operations and directory traversal
|
||||
- Safe simulation practices and rollback capability
|
||||
- Educational security demonstrations
|
||||
- Backup and disaster recovery testing
|
||||
- Incident response and recovery procedures
|
||||
|
||||
## Deliverables
|
||||
- Controlled test environment setup
|
||||
- File encryption with strong symmetric algorithms
|
||||
- File decryption and recovery capability
|
||||
- Encryption progress tracking and reporting
|
||||
- Educational content and ransom notes
|
||||
- Comprehensive audit logging and analysis
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Steganography Multi-Tool
|
||||
|
||||
## Overview
|
||||
Build a multi-format steganography toolkit that hides secret data across six different media types: images (LSB encoding), audio files (WAV/FLAC sample manipulation), QR codes (error correction exploitation), PDFs (whitespace and invisible text layers), plaintext (zero-width Unicode characters), and git commits (timestamp and whitespace encoding). This project teaches data encoding across diverse file formats and demonstrates that covert communication extends far beyond hiding text in pictures.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Implement image steganography as the foundation** using PIL/Pillow to manipulate pixel data with least significant bit encoding. Support PNG and BMP formats (lossless compression preserves hidden data). Build a capacity calculator showing maximum payload size per image, and include AES encryption of the payload before embedding so extraction without the key yields only noise.
|
||||
|
||||
2. **Add audio steganography support** for WAV and FLAC files by encoding data in the least significant bits of audio samples. Audio files contain far more data capacity than images—a 30-second WAV at 44.1kHz stereo holds millions of samples. Implement sample-level LSB replacement while maintaining audio quality imperceptible to human ears, and verify the output file plays identically to the original.
|
||||
|
||||
3. **Build QR code steganography** by exploiting QR error correction redundancy. QR codes use Reed-Solomon error correction allowing up to 30% data damage at the highest level—embed hidden data in the error correction bits so the QR still scans to its original URL but carries a secret payload extractable by your tool.
|
||||
|
||||
4. **Implement zero-width Unicode text steganography** using invisible characters (zero-width space U+200B, zero-width non-joiner U+200C, zero-width joiner U+200D) embedded between visible characters. The output looks like normal text in Discord, Slack, or any messaging platform, but contains a hidden binary message encoded in the pattern of invisible characters.
|
||||
|
||||
5. **Add PDF steganography** using multiple techniques: whitespace encoding between words (varying space width imperceptibly), invisible text layers with font size zero or matching background color, and metadata field manipulation. Support both hiding data in existing PDFs and extracting hidden data from suspicious documents.
|
||||
|
||||
6. **Create git commit steganography** that encodes messages in commit metadata: manipulate author timestamps (encoding bits in the seconds field), insert specific whitespace patterns in commit messages, or use author name variations. Build both an encoder that creates commits with hidden messages and a decoder that extracts them from repository history.
|
||||
|
||||
7. **Build a unified CLI interface** with subcommands for each format (encode/decode per type), automatic format detection for decoding, a universal encryption layer that wraps all formats, and batch processing support. Include a capacity report showing how much data each input file can hold and recommend the optimal format for a given payload size.
|
||||
|
||||
8. **Create comprehensive documentation** covering the theory behind each steganography technique, detection methods (steganalysis) for each format, real-world use cases of steganography in espionage and whistleblowing, and the limitations of each approach. Include examples demonstrating that the modified files are perceptually identical to originals.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Least significant bit manipulation across media types
|
||||
- Audio sample encoding and WAV/FLAC file structure
|
||||
- QR code error correction and Reed-Solomon codes
|
||||
- Unicode invisible characters and text encoding
|
||||
- PDF internal structure and manipulation
|
||||
- Symmetric encryption integration (AES)
|
||||
- File format parsing and binary I/O
|
||||
|
||||
## Deliverables
|
||||
- Image steganography encoder/decoder (PNG, BMP)
|
||||
- Audio steganography for WAV/FLAC files
|
||||
- QR code payload embedding via error correction
|
||||
- Zero-width Unicode text steganography
|
||||
- PDF steganography with multiple techniques
|
||||
- Git commit metadata encoding
|
||||
- Unified CLI with encryption and batch processing
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
# Steganography Tool
|
||||
|
||||
## Overview
|
||||
Create a tool that hides secret messages inside image files using least significant bit (LSB) steganography, allowing covert communication through seemingly innocent images. This project teaches data encoding techniques, image file formats, and demonstrates how information can be secretly embedded and extracted from digital media.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand LSB steganography principles** by learning that each pixel in an image is represented by color values (typically 0-255 for each RGB channel), and the least significant bit is the rightmost bit in the binary representation—changing it minimally affects the visible image but can encode data. For example, if a red channel value is 255 (binary: 11111111), changing the LSB to create 254 (binary: 11111110) is imperceptible to human eyes.
|
||||
|
||||
2. **Research image file formats** (PNG and BMP are ideal for LSB steganography because they're lossless—JPEG compression would destroy your hidden message). Understand how pixel data is stored in these formats: BMP stores pixel data directly, PNG uses compression but preserves data, and JPEG uses lossy compression making it unsuitable. Implement library support for reading and writing these formats using `Pillow`.
|
||||
|
||||
3. **Implement message encoding functionality** that converts your secret message to binary, then hides those bits in the LSB of image pixels. Process pixels sequentially (typically left-to-right, top-to-bottom), replace the LSB of each color channel with message bits, and reconstruct the modified image with the hidden data embedded. Include a capacity calculator showing how much data can fit in a given image.
|
||||
|
||||
4. **Build message extraction capability** that reverses the encoding process—read the LSB from each pixel in sequence and reconstruct the original binary message. Implement length encoding (store the message length in the first few pixels) so the decoder knows when to stop reading and can properly handle variable-length messages.
|
||||
|
||||
5. **Add password protection** by encrypting the secret message before encoding it into the image—use symmetric encryption like AES to encrypt the plaintext message, then encode the encrypted bytes using LSB steganography. This provides two layers of security: even if someone extracts the hidden data, they can't read it without the password.
|
||||
|
||||
6. **Support both PNG and BMP formats** by implementing format-specific handling in your library interactions. Add automatic format detection for input images and let users specify output format—include guidance on which formats are appropriate for steganography and warnings about using lossy compression formats.
|
||||
|
||||
7. **Create a clean command-line interface** with options for encoding (input image, message text, output filename, optional password) and decoding (steganographic image, optional password). Implement verbose mode showing encoding/decoding progress, capacity information, and data verification to ensure the hidden message was correctly embedded and extracted.
|
||||
|
||||
8. **Build comprehensive documentation** explaining the steganography concept, discussing LSB technique limitations and detection methods (steganalysis), providing examples of encoding/decoding images, and explaining practical use cases (covert communication in restricted environments). Include warnings about legal implications of hidden communications, discuss how steganography differs from encryption, and note that LSB steganography is trivial to detect with proper tools but effective for basic covert communication.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Least significant bit (LSB) concept and manipulation
|
||||
- Image file formats and pixel data representation
|
||||
- Data encoding and binary operations
|
||||
- File I/O and image manipulation libraries
|
||||
- Encryption integration for enhanced security
|
||||
- Steganography detection and limitations
|
||||
|
||||
## Deliverables
|
||||
- LSB steganography encoder/decoder
|
||||
- Support for PNG and BMP image formats
|
||||
- Password protection with encryption
|
||||
- Capacity calculation and verification
|
||||
- Command-line interface with encoding/decoding modes
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Systemd Persistence Scanner
|
||||
|
||||
## Overview
|
||||
Build a Linux persistence mechanism hunter in Go that scans every known location where attackers plant backdoors to survive reboots: cron jobs, systemd services and timers, shell RC files, SSH authorized_keys, LD_PRELOAD hijacking, kernel modules, udev rules, at jobs, XDG autostart entries, init.d scripts, and MOTD scripts. The tool compiles to a single portable binary that can be dropped onto any Linux system for immediate threat hunting. This project teaches post-compromise forensics and the dozens of ways attackers maintain access to compromised systems.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Research Linux persistence mechanisms** by studying how attackers maintain access after initial compromise. Each mechanism represents a different autorun location: cron executes on schedule, systemd services start at boot, shell RC files execute on login, authorized_keys allows passwordless SSH, LD_PRELOAD injects code into every process, kernel modules load at boot with root privileges, and udev rules trigger on hardware events.
|
||||
|
||||
2. **Implement cron job scanning** by parsing all cron locations: user crontabs (/var/spool/cron/), system crontab (/etc/crontab), cron directories (/etc/cron.d/, /etc/cron.daily/, /etc/cron.hourly/, /etc/cron.weekly/, /etc/cron.monthly/), and anacron jobs. Flag suspicious entries: base64-encoded commands, curl/wget piped to shell, reverse shell patterns, and references to world-writable directories.
|
||||
|
||||
3. **Build systemd service and timer scanning** that enumerates all systemd unit files across standard paths (/etc/systemd/system/, /usr/lib/systemd/system/, ~/.config/systemd/user/), identifies non-package-managed units (not owned by any installed package), and flags suspicious ExecStart commands, unusual After/Wants dependencies, and timer units with frequent triggers.
|
||||
|
||||
4. **Scan shell initialization files** including /etc/profile, /etc/profile.d/*, ~/.bashrc, ~/.bash_profile, ~/.zshrc, ~/.profile, and /etc/bash.bashrc for injected commands. Detect obfuscated payloads, encoded strings, network connections, file downloads, and commands that don't match typical shell configuration patterns.
|
||||
|
||||
5. **Check SSH configuration and keys** by scanning authorized_keys files for all users, detecting keys with forced commands (command= option), identifying keys added recently, checking for SSH config modifications (authorized_keys path changes, PermitRootLogin modifications), and scanning for SSH backdoors in /etc/ssh/sshd_config.
|
||||
|
||||
6. **Implement advanced persistence checks** including: LD_PRELOAD entries in /etc/ld.so.preload and environment variables, kernel module enumeration compared against package manager (unsigned/unknown modules), udev rules in /etc/udev/rules.d/ with RUN commands, at job queue inspection, XDG autostart entries, init.d scripts, and MOTD/update-motd.d scripts that execute on login.
|
||||
|
||||
7. **Build risk scoring and output formatting** where each finding gets a severity score based on the persistence technique, obfuscation level, and whether it matches known attack patterns. Output results with color-coded terminal display, JSON for programmatic consumption, and a summary showing total findings by severity with recommended investigation priority.
|
||||
|
||||
8. **Add baseline comparison mode** that saves a snapshot of all persistence mechanisms on a known-clean system, then on subsequent runs highlights only differences from baseline. This dramatically reduces noise on systems with many legitimate cron jobs and services, focusing attention on newly added persistence.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Linux persistence mechanisms (MITRE ATT&CK Persistence)
|
||||
- Systemd unit file structure and management
|
||||
- Cron job configuration and scheduling
|
||||
- SSH key authentication and configuration
|
||||
- LD_PRELOAD and library injection
|
||||
- Go cross-compilation for portable binaries
|
||||
- Threat hunting and forensic analysis
|
||||
|
||||
## Deliverables
|
||||
- Single compiled Go binary for portability
|
||||
- Scanning for 12+ persistence mechanism types
|
||||
- Suspicious pattern detection with risk scoring
|
||||
- Color-coded terminal output and JSON export
|
||||
- Baseline snapshot and comparison mode
|
||||
- Package manager verification for installed files
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Trojan Application Builder
|
||||
|
||||
## Overview
|
||||
Build an educational malware lifecycle demonstration in Python that creates a convincing-looking application (a fake game launcher with AI-generated artwork) which secretly exfiltrates data from a dummy database and simulates file encryption. The project includes a small FastAPI backend with fake user data as the victim environment, demonstrating the complete attack chain from social engineering through data exfiltration to ransomware-style encryption—all in a self-contained, clearly-educational sandbox. This project teaches malware anatomy, social engineering, and defensive awareness.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Build the victim environment** using FastAPI with a SQLite database containing fake user data (generated names, emails, hashed passwords, payment tokens). This simulates a real application's backend that the trojan will target. Include a simple web interface showing the "legitimate" application is running with its database of users.
|
||||
|
||||
2. **Create the trojan application** as a Python GUI program using tkinter or PyQt that presents itself as a game launcher with an attractive interface (use AI-generated artwork for the splash screen). The application should look and feel legitimate—include fake loading bars, menu options, and a "Play" button that appears functional.
|
||||
|
||||
3. **Implement data exfiltration capabilities** that activate alongside the visible GUI: scan for database files (SQLite, PostgreSQL connection strings in environment variables), extract credentials from common locations (.env files, config files, browser password stores in the demo environment), and package the stolen data for transmission.
|
||||
|
||||
4. **Add simulated file encryption** demonstrating ransomware behavior: enumerate files in a designated sandbox directory (never touch real user files), encrypt them using AES with a generated key, rename files with a custom extension, and generate a ransom note. Implement a decryption mode that restores files using the key, demonstrating the full ransomware lifecycle.
|
||||
|
||||
5. **Build the command and control callback** where the trojan sends exfiltrated data and encryption keys to a local listener (simulating C2 communication). Implement basic encoding of the exfiltration payload, periodic heartbeat messages, and command reception. Keep all traffic local—never connect to external servers.
|
||||
|
||||
6. **Create detection and analysis tooling** that accompanies the trojan: a process monitor showing what the trojan is actually doing (file access, network connections, database queries), a network capture showing C2 traffic patterns, and a behavioral analysis report documenting each malicious action with timestamps.
|
||||
|
||||
7. **Implement defensive countermeasures demonstration** showing how each stage of the attack could be detected or prevented: endpoint detection for suspicious file access patterns, network monitoring for C2 callback patterns, database access auditing, and file integrity monitoring that catches the encryption stage.
|
||||
|
||||
8. **Write extensive ethical documentation** with prominent warnings that this is educational only, never to be deployed against real systems. Cover the legal framework around malware development (CFAA, Computer Misuse Act), the ethics of security research, and how understanding malware anatomy helps defenders build better detection.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Trojan horse malware anatomy and behavior
|
||||
- Social engineering and deceptive interfaces
|
||||
- Data exfiltration techniques and patterns
|
||||
- File encryption and ransomware mechanics
|
||||
- Command and control communication
|
||||
- Behavioral malware analysis
|
||||
- Endpoint detection and response concepts
|
||||
|
||||
## Deliverables
|
||||
- Fake game launcher GUI with trojan capabilities
|
||||
- FastAPI victim environment with dummy database
|
||||
- Data exfiltration and credential harvesting
|
||||
- Sandbox file encryption with decryption mode
|
||||
- Local C2 server and callback mechanism
|
||||
- Detection and analysis companion tooling
|
||||
- Comprehensive ethical usage documentation
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Firewall Rule Engine
|
||||
|
||||
## Overview
|
||||
Build a firewall rule parser, generator, and validator written in V (Vlang) that reads existing iptables and nftables rulesets, detects conflicts and redundancies, validates rule syntax, suggests optimizations, and generates hardened rulesets. This project introduces V—an extremely new compiled language with C-like performance and Python-like simplicity—while teaching the internals of Linux firewall configuration, rule evaluation order, and network filtering logic.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Learn V language fundamentals and firewall concepts** by working through V's documentation (simple syntax, compiles to C, no null, no undefined behavior) while studying iptables and nftables rule structure. Understand chains (INPUT, OUTPUT, FORWARD), tables (filter, nat, mangle), targets (ACCEPT, DROP, REJECT, LOG), and match criteria (source/destination IP, port, protocol, interface, state).
|
||||
|
||||
2. **Build the iptables rule parser** that reads iptables-save output format and parses each rule into a structured representation: table, chain, protocol, source/destination addresses and ports, match extensions (state, conntrack, multiport, limit), target action, and any logging options. Handle all common match modules and special syntax (negation with !, ranges, CIDR notation).
|
||||
|
||||
3. **Add nftables rule parsing** for the modern Linux firewall format, handling nftables list ruleset output with its different syntax: table and chain declarations, rule expressions with matches and statements, sets and maps, and verdict statements (accept, drop, reject, queue, continue). Map nftables concepts to the same internal representation used for iptables.
|
||||
|
||||
4. **Implement conflict detection** that identifies problematic rule combinations: rules that can never match because an earlier rule handles all their traffic (shadowed rules), rules with contradictory criteria, duplicate rules, and rules that together create unintended allow/deny behavior. For each detected conflict, explain which rules conflict and why.
|
||||
|
||||
5. **Build the rule optimizer** that suggests improvements: consolidate multiple rules into multiport matches, replace individual IP rules with CIDR ranges where possible, reorder rules to put high-traffic matches first (performance optimization), remove redundant rules that are subsets of other rules, and suggest rate limiting for exposed services.
|
||||
|
||||
6. **Create the hardened ruleset generator** that produces a security-focused ruleset following best practices: default deny policy, explicit allow only for required services, loopback traffic allowed, established/related connections tracked, ICMP rate limited, logging for dropped packets, and anti-spoofing rules. Output in both iptables-restore and nftables format.
|
||||
|
||||
7. **Build an interactive CLI** with commands for loading rulesets from files or live system, displaying rules in a human-readable table format, running conflict analysis, generating optimization suggestions, exporting hardened rulesets, and diffing two rulesets to show changes. Include colored output highlighting issues by severity.
|
||||
|
||||
8. **Write documentation** covering iptables vs nftables comparison, rule evaluation order and why it matters for security, common firewall misconfigurations that lead to breaches, and how to test firewall rules safely. Include V language learning notes explaining the language choice and experience.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Linux firewall architecture (netfilter, iptables, nftables)
|
||||
- Rule evaluation order and chain traversal
|
||||
- Network filtering criteria and match modules
|
||||
- Conflict detection algorithms
|
||||
- V language (Vlang) compilation and syntax
|
||||
- CLI application design
|
||||
- Firewall hardening best practices
|
||||
|
||||
## Deliverables
|
||||
- iptables-save format parser
|
||||
- nftables ruleset parser
|
||||
- Conflict and redundancy detection engine
|
||||
- Rule optimization suggestions
|
||||
- Hardened ruleset generator (iptables + nftables formats)
|
||||
- Interactive CLI with colored output and diffing
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
# Windows Registry Change Monitor
|
||||
|
||||
## Overview
|
||||
Build a Windows security tool that monitors critical registry keys for unauthorized modifications, focusing on common persistence locations used by malware like Run keys, Services, and Scheduled Tasks. This project teaches Windows system administration, malware persistence mechanisms, and demonstrates host-based threat detection techniques.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand Windows Registry structure and persistence mechanisms** by learning that the Registry is Windows' configuration database organized in hives (HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, etc.) with subkeys and values. Study how malware achieves persistence: Run/RunOnce keys (HKLM/HKCU\Software\Microsoft\Windows\CurrentVersion\Run) execute programs at startup, Services keys enable malware to run as system services, Scheduled Tasks hide in Task Scheduler, and many other locations offer persistence opportunities. Create a comprehensive list of high-risk registry locations.
|
||||
|
||||
2. **Install Windows Registry monitoring library** using `python-registry` or `pywin32` to programmatically access and monitor the Windows Registry. Learn how to enumerate Registry keys, read values, and handle Registry permissions—understand that monitoring may require administrator privileges and that accessing certain Registry hives might need special handling.
|
||||
|
||||
3. **Implement Registry snapshot creation** by taking a baseline of critical registry keys and their values, storing this in a database or JSON file. Include all values under high-risk keys like HKLM\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\System\CurrentControlSet\Services, and similar locations. Create a comprehensive inventory of existing legitimate persistence mechanisms to distinguish them from suspicious additions.
|
||||
|
||||
4. **Build continuous monitoring** that periodically reads the current Registry state and compares it against the baseline, detecting three types of changes: new registry values added (potential malware persistence), modified values (altered commands or locations), and deleted values (attempted cleanup or legitimate removal). Track timestamps and implement change detection that runs at configurable intervals (continuous polling, scheduled checks).
|
||||
|
||||
5. **Implement change tracking and analysis** by creating records for each detected modification including timestamp, registry path, previous value, new value, value type, and change type. Build analysis logic that distinguishes between legitimate changes (software updates, user configuration changes, administrator actions) and suspicious changes (new .exe files in Run keys, suspicious scheduled tasks, service additions).
|
||||
|
||||
6. **Create alerting and logging** that generates alerts when suspicious Registry modifications are detected, including detailed change information and recommendations for investigation. Log all changes to a secure location with immutable timestamps, create audit trails showing who accessed Registry monitoring, and provide capabilities to export logs for compliance documentation or incident investigation.
|
||||
|
||||
7. **Add remediation capabilities** allowing administrators to quickly revert suspicious Registry changes by restoring values to previous states. Implement whitelist/blacklist functionality where known-good Registry modifications can be approved and excluded from alerts, preventing alert fatigue while focusing on truly suspicious changes. Include rollback functionality with safeguards preventing accidental deletion of critical Registry values.
|
||||
|
||||
8. **Build comprehensive documentation** explaining Registry persistence mechanisms and how malware achieves persistence through Registry modifications, discussing detection methodology and limitations (Registry monitoring adds system overhead, sophisticated malware may hide changes). Provide setup instructions, examples of legitimate vs. suspicious Registry changes, and integration guidance with Windows Event Log monitoring and incident response procedures. Compare your tool to enterprise solutions and discuss Registry-level protections available in Windows security features.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Windows Registry structure and organization
|
||||
- Malware persistence mechanisms
|
||||
- Registry access and enumeration
|
||||
- Change detection and baseline comparison
|
||||
- Alerting and logging systems
|
||||
- Incident response and remediation
|
||||
|
||||
## Deliverables
|
||||
- Registry snapshot and baseline creation
|
||||
- Continuous Registry monitoring
|
||||
- Change detection for additions, modifications, deletions
|
||||
- Suspicious pattern analysis and detection
|
||||
- Alerting with detailed change information
|
||||
- Remediation and rollback capabilities
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
# Active Directory Enumeration Tool
|
||||
|
||||
## Overview
|
||||
Build a comprehensive tool that enumerates Active Directory users, groups, computers, and permission structures via LDAP queries, identifying privileged accounts, stale accounts, and misconfigurations. This project teaches directory services, LDAP protocol, and demonstrates reconnaissance techniques used in enterprise penetration testing and security assessments.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand Active Directory structure and LDAP protocol** by learning that Active Directory stores enterprise identity and security information in hierarchical structure: domains (forests) contain organizational units (OUs), users, groups, and computers. LDAP is the protocol querying AD: connect to domain controller on port 389 (LDAP) or 636 (LDAPS), authenticate with domain credentials, and execute search queries returning objects matching specified criteria. Study LDAP Distinguished Names (DN) format, common object classes (user, group, computer), and useful attributes (userAccountControl flags, lastLogon timestamps, memberOf groups).
|
||||
|
||||
2. **Implement LDAP connection and authentication** using `ldap3` Python library to connect to Active Directory domain controller. Build functions that bind to LDAP with provided credentials, handle both simple and NTLM authentication, and gracefully manage connection failures. Implement domain controller discovery using DNS queries (SRV records) to automatically locate AD infrastructure without manual configuration.
|
||||
|
||||
3. **Build user enumeration functionality** querying all users in directory, extracting attributes including username, display name, email, last logon timestamp, password last set, account status (enabled/disabled), and User Account Control (UAC) flags. Identify privileged users (members of Domain Admins, Enterprise Admins, Schema Admins groups), detect service accounts (likely to have long-standing passwords), and flag suspicious accounts (never logged in, password never expires, disabled accounts that should be cleaned up).
|
||||
|
||||
4. **Create group enumeration and membership analysis** extracting all groups in directory and analyzing membership: identify security groups vs. distribution groups, determine nested group membership (groups containing other groups), find users with unusual group membership, and detect groups with excessive members (often misconfigured). Create dependency graphs showing group hierarchies and membership relationships for permission analysis.
|
||||
|
||||
5. **Implement computer enumeration** discovering all domain-joined computers, their operating systems, last logon times, and DNS names. Identify stale computers (not logged in for 90+ days, good cleanup candidates), detect operating system patterns (count of Windows 10 vs. Windows 7, outdated OSes), and flag computers with potentially risky configurations (those without required security patches, unusual hostnames).
|
||||
|
||||
6. **Build permission and privilege analysis** determining effective permissions for users/groups over organizational units and resources. Analyze privileged group memberships identifying who can perform administrative actions, trace delegation of authority (who delegated what permissions to whom), and identify privilege accumulation (users with more privileges than their role requires). Create permission matrices showing which users can access which resources.
|
||||
|
||||
7. **Add stale account and misconfiguration detection** identifying security risks: accounts not logged in for 90+ days (should be disabled), accounts with passwords set to never expire (contrary to security policy), disabled accounts still present (should be deleted), groups with empty membership (should be removed), and orphaned accounts (belonging to deleted departments). Create remediation recommendations for each finding.
|
||||
|
||||
8. **Build comprehensive reporting with visualization** generating reports showing AD structure, user/group statistics, identified risks, and privilege distributions. Create domain trust visualizations showing forest structure and trust relationships, group membership trees showing hierarchies, and access control matrices. Export findings in formats suitable for security assessments (HTML reports, CSV data exports, JSON for tool integration). Include documentation explaining AD concepts, common misconfigurations, remediation steps, and comparison to commercial AD security tools (BloodHound, Adalanche).
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Active Directory structure and organization
|
||||
- LDAP protocol and query syntax
|
||||
- DN (Distinguished Names) and object attributes
|
||||
- Group membership and nested groups
|
||||
- User Account Control (UAC) flags
|
||||
- Permission analysis and delegation
|
||||
- Security risk identification
|
||||
- Data visualization and reporting
|
||||
|
||||
## Deliverables
|
||||
- LDAP connection and authentication
|
||||
- User enumeration with privilege identification
|
||||
- Group enumeration and membership analysis
|
||||
- Computer enumeration and OS detection
|
||||
- Permission and privilege analysis
|
||||
- Stale account and misconfiguration detection
|
||||
- Visual domain structure and trust diagrams
|
||||
- Comprehensive security assessment reporting
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
# Automated Backup Integrity Checker
|
||||
|
||||
## Overview
|
||||
Build a backup validation system that verifies backup files haven't corrupted using checksums, automatically tests restoration processes, and alerts administrators if backups fail validation or haven't run recently. This project teaches backup strategies, data integrity verification, and demonstrates disaster recovery testing practices critical for business continuity.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand backup strategies, failure modes, and validation importance** by learning that backups are useless if they're corrupted or unrestorable, so validation is critical business practice. Study backup types: full backups (complete copy), incremental backups (changes since last backup), and differential backups (changes since last full backup). Research backup failure modes: file corruption during transfer, bitrot in storage, incomplete backups, encryption key loss, and wrong backup formats. Understand validation concepts: checksums verify data integrity, restoration testing ensures backups actually restore correctly, retention policies ensure appropriate history.
|
||||
|
||||
2. **Implement backup discovery and cataloging** by scanning backup storage locations (local drives, NAS, cloud storage) to discover backup files: identify backup sets, extract metadata (backup timestamp, size, source system, backup type), and organize by system/application. Build database tracking all known backups with metadata, last successful backup timestamp, and validation status. Support multiple backup formats and locations: file-based backups, database dumps, VM snapshots, cloud provider native backups.
|
||||
|
||||
3. **Build checksum validation** computing and verifying checksums for all backup files: calculate SHA256 hashes of backup files and compare against stored checksums from backup creation time, detecting any file corruption. Implement re-hashing on periodic basis (weekly/monthly) to detect bitrot occurring even in untouched storage. Log validation results including pass/fail status, timestamp, and hash values. Implement parallel/distributed hashing for large backup files improving performance.
|
||||
|
||||
4. **Create automated restoration testing** that periodically restores backups to isolated test environments verifying they're genuinely restorable: select backup candidates (rotate which systems get tested), restore to temporary systems, verify restored data is correct and accessible, then destroy test instances. Document restoration duration as part of RTO (Recovery Time Objective) validation. Automate entire testing workflow: backup selection, environment provisioning, restoration execution, validation, environment cleanup.
|
||||
|
||||
5. **Implement backup freshness monitoring** tracking whether backups are running on schedule: alert when backup timestamp falls outside expected window (daily backup missing for 26+ hours), identify systems not backed up recently, and track backup frequency trends. Calculate backup staleness indicating how old the most recent backup is and warning when backup data becomes too stale to be useful for recovery.
|
||||
|
||||
6. **Build alert and escalation mechanisms** for backup failures: immediate alerts for failed backups (high priority), validation failures (corruption detected), missed backup windows (restore may not be available), and restoration test failures (backups might not actually restore). Implement graduated escalation: first alert to backup administrators, escalate to incident management if not resolved within timeframe.
|
||||
|
||||
7. **Create validation reporting and dashboards** displaying backup status: show all backup systems, last successful backup timestamp, validation status (pass/fail/pending), and restoration test results. Include backup inventory with retention compliance (backups retained according to policy), trending showing backup success rates over time, and RTO metrics from restoration testing. Generate executive reports showing backup program health and compliance with recovery objectives.
|
||||
|
||||
8. **Build comprehensive documentation** explaining backup and recovery concepts, validation methodologies, and disaster recovery testing procedures. Discuss limitations (automated testing may not catch all issues, restoration testing requires resources and time), compare to commercial backup software and disaster recovery testing platforms. Provide incident response procedures for when backup problems detected (verification, escalation, remediation). Include templates for business continuity planning, RTO/RPO (Recovery Point Objective) definition, and backup strategy documentation. Explain integration with broader disaster recovery and business continuity programs.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Backup architectures and strategies
|
||||
- Checksum computation and verification
|
||||
- Bitrot detection and storage durability
|
||||
- Automated restoration testing
|
||||
- RTO/RPO calculation and monitoring
|
||||
- Alert management and escalation
|
||||
- Data integrity verification
|
||||
- Disaster recovery testing
|
||||
|
||||
## Deliverables
|
||||
- Backup file discovery and cataloging
|
||||
- Checksum computation and validation
|
||||
- Bitrot detection through periodic re-validation
|
||||
- Automated restoration testing
|
||||
- Restoration success/failure validation
|
||||
- Backup freshness monitoring
|
||||
- Alert system for backup failures
|
||||
- Compliance tracking against retention policies
|
||||
- Reporting and dashboard interfaces
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Chaos Engineering Security Tool
|
||||
|
||||
## Overview
|
||||
Build a security-focused chaos engineering platform in Go that injects controlled security failures into running infrastructure to test whether defensive controls survive real-world disruptions. Traditional chaos engineering tests availability, but this tool tests security resilience by simulating certificate expiry, DNS manipulation, credential rotation during active sessions, firewall rule changes, and authentication service downtime. This project teaches the intersection of reliability engineering and security engineering, revealing hidden dependencies and single points of failure that only appear under stress.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the Go project and experiment framework** Create a Go module with an experiment-based architecture inspired by the Chaos Toolkit specification. Define an Experiment interface with Hypothesis, Inject, Verify, and Rollback methods. Each experiment declares a steady-state hypothesis (what should remain true during the failure), injects the failure, verifies whether the hypothesis held, and cleans up. Build a CLI using cobra with subcommands for each experiment type. Implement a safety system that requires explicit confirmation before injection and automatically triggers rollback after a configurable timeout.
|
||||
|
||||
2. **Build the TLS and certificate chaos experiments** Implement three certificate-related experiments: simulate certificate expiry by deploying a self-signed cert with a past expiration date to a test Nginx instance, simulate certificate revocation by adding a certificate serial to a local CRL and testing whether clients check revocation status, and simulate a CA compromise by replacing the trusted CA certificate with a different one mid-connection. Each experiment tests whether the application properly validates certificates, rejects expired or revoked certs, and surfaces clear error messages rather than silently falling back to insecure connections.
|
||||
|
||||
3. **Create DNS manipulation experiments** Build experiments that simulate DNS-layer disruptions: redirect a service hostname to a different IP, introduce DNS resolution delays of 5 to 30 seconds, return NXDOMAIN for authentication service domains, and modify DNS cache entries for certificate validation endpoints like OCSP responders. Use a local CoreDNS instance that you can programmatically reconfigure. Verify whether applications detect the manipulation, fall back gracefully, or silently connect to incorrect endpoints.
|
||||
|
||||
4. **Implement credential rotation chaos** Build experiments that test credential rotation resilience: rotate a database password while the application has active connections, expire all active JWT tokens simultaneously by simulating a signing key rotation, revoke an API key that a service is actively using, and rotate TLS client certificates during mutual TLS sessions. The hypothesis for each is that the application should detect the credential failure, obtain new credentials, and recover without data loss or extended downtime. Measure recovery time and whether any requests were served with stale credentials.
|
||||
|
||||
5. **Build firewall and network security experiments** Create experiments that modify network security controls: drop all traffic to a specific port simulating firewall misconfiguration, block outbound connections to authentication providers, introduce packet corruption on encrypted channels, and restrict network to allow only specific IP ranges. Use iptables or nftables commands executed via Go os/exec. Each experiment should verify that the application fails closed (denies access) rather than fails open (allows unauthenticated access) when security infrastructure is disrupted.
|
||||
|
||||
6. **Implement authentication service chaos** Build experiments specifically targeting authentication flows: shut down the OAuth provider while users have active sessions, introduce latency into LDAP or AD responses causing timeouts, return malformed responses from the token validation endpoint, and exhaust the authentication service connection pool. Test whether the application caches authentication decisions and for how long, whether it queues or rejects requests during auth outages, and whether it exposes any authentication bypass when the auth service is unavailable.
|
||||
|
||||
7. **Create the observation and measurement system** Build a real-time observation system that collects metrics during experiments: application response codes, authentication success and failure rates, error log entries, certificate validation outcomes, and network connection states. Use Prometheus client libraries to expose metrics and create pre-built Grafana dashboards that visualize security posture during chaos injection. Generate post-experiment reports that show the timeline of injection, impact, detection, and recovery with specific timestamps.
|
||||
|
||||
8. **Build the experiment orchestrator and CI integration** Create an orchestrator that can run multiple experiments in sequence or parallel with configurable blast radius (single service, single host, entire environment). Implement a plan mode that shows what would happen without injecting anything. Build a GitHub Actions integration that runs security chaos experiments as part of the CI/CD pipeline, failing the build if any experiment causes a security regression like failing open. Include Docker Compose files that set up a complete test environment with sample services, an auth provider, DNS, and TLS termination.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Chaos engineering principles applied to security controls
|
||||
- TLS certificate lifecycle and validation chain mechanics
|
||||
- DNS security and the impact of DNS manipulation on authentication
|
||||
- Credential rotation strategies and graceful degradation
|
||||
- Fail-closed vs fail-open behavior in security systems
|
||||
- Network security control dependencies and single points of failure
|
||||
- Observability and measurement during security incidents
|
||||
- Security testing integration in CI/CD pipelines
|
||||
|
||||
## Deliverables
|
||||
- Go CLI tool with pluggable experiment framework and safety controls
|
||||
- Four experiment categories: TLS, DNS, credentials, firewall, and authentication
|
||||
- Real-time observation system with Prometheus metrics and Grafana dashboards
|
||||
- Post-experiment reports with timeline visualization
|
||||
- Experiment orchestrator with blast radius control and plan mode
|
||||
- GitHub Actions integration for CI/CD security chaos testing
|
||||
- Docker Compose test environment with sample services
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
# Cloud Asset Inventory Tool
|
||||
|
||||
## Overview
|
||||
Build a multi-cloud inventory management tool that automatically discovers and catalogs all resources across AWS, Azure, and GCP, tracks changes over time, identifies untagged resources, and calculates infrastructure costs. This project teaches cloud platform APIs, infrastructure-as-code principles, and demonstrates tools used for cloud security and cost management.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand cloud provider APIs and authentication** by researching AWS SDK (boto3), Azure SDK, and Google Cloud SDK for programmatic resource discovery. Learn authentication methods: AWS IAM roles/credentials, Azure service principals, GCP service accounts. Set up appropriate permissions allowing read-only access to resource inventory without modification rights. Understand API rate limiting and implement backoff strategies preventing throttling.
|
||||
|
||||
2. **Implement AWS resource discovery** using boto3 to enumerate EC2 instances, S3 buckets, RDS databases, Lambda functions, security groups, VPCs, and other infrastructure components. Extract metadata: resource IDs, types, creation timestamps, tags, configuration details, and costs. Build recursive discovery following relationships (instances belong to VPCs, security groups protect instances, EBS volumes attach to instances) creating complete infrastructure graph.
|
||||
|
||||
3. **Create Azure resource enumeration** using Azure SDK to discover virtual machines, storage accounts, databases, app services, and other managed resources. Extract similar metadata as AWS implementation, handle Azure's hierarchical structure (subscriptions, resource groups, resources), and maintain consistency in data model. Support both Azure Resource Manager (ARM) and classic resources if applicable to target environments.
|
||||
|
||||
4. **Build GCP resource discovery** querying Google Cloud APIs to enumerate Compute Engine instances, Cloud Storage buckets, Cloud SQL databases, App Engine services, and Kubernetes clusters. Maintain consistent data model across all three cloud providers enabling unified inventory interface. Handle GCP's project-based organization and service-specific discovery patterns.
|
||||
|
||||
5. **Implement change tracking and versioning** storing snapshots of infrastructure at different points in time, detecting what changed between snapshots (new resources created, existing resources modified, resources deleted). Build timeline showing infrastructure evolution, enable before-and-after comparison of configurations, and identify drift from baseline (resources created outside change management processes).
|
||||
|
||||
6. **Create tagging and metadata analysis** identifying resources missing required tags (standard tags for cost allocation, ownership, project association), detecting inconsistent tagging across resources, and analyzing tag coverage (what percentage of resources have all required tags). Flag untagged resources for cleanup and implement recommendations for tagging consistency improving cost allocation and resource management.
|
||||
|
||||
7. **Build cost analysis and reporting** extracting cost information from each cloud provider's billing APIs: calculate total infrastructure spending, allocate costs to individual resources, identify cost trends (spending increasing or decreasing), and project future costs based on current usage patterns. Identify cost optimization opportunities (unused resources, oversized instances, cheaper alternative configurations). Generate cost allocation reports enabling chargeback and budget management.
|
||||
|
||||
8. **Build comprehensive reporting and dashboards** with multi-format export: create inventory reports (CSV, JSON) showing all discovered resources with details, build dashboards visualizing resource distribution across clouds, display cost breakdown by service type/cloud provider, and generate change reports showing infrastructure modifications. Implement alerting on significant changes (major resource creation/deletion) or cost anomalies. Compare your tool to commercial solutions (Zesty, CloudMapper, Forseti) and discuss limitations (API permissions affect visibility, real-time accuracy depends on API polling frequency).
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Cloud provider APIs and SDKs
|
||||
- IAM and authentication across cloud platforms
|
||||
- Infrastructure discovery and enumeration
|
||||
- Resource metadata and relationships
|
||||
- Change tracking and versioning
|
||||
- Tagging strategies and compliance
|
||||
- Cost analysis and optimization
|
||||
- Multi-cloud unified management
|
||||
- Infrastructure-as-code concepts
|
||||
|
||||
## Deliverables
|
||||
- AWS resource discovery and enumeration
|
||||
- Azure resource discovery and enumeration
|
||||
- GCP resource discovery and enumeration
|
||||
- Unified inventory data model
|
||||
- Change tracking with snapshots
|
||||
- Tagging compliance analysis
|
||||
- Cost tracking and allocation
|
||||
- Multi-cloud dashboards and reports
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Credential Rotation Enforcer
|
||||
|
||||
## Overview
|
||||
Build a credential lifecycle management platform in Python that tracks, monitors, and enforces rotation policies across all types of secrets in your infrastructure: API keys, database passwords, TLS certificates, SSH keys, and OAuth tokens. This project teaches the operational security discipline of credential hygiene, which is one of the most impactful yet neglected areas of security engineering. You will build a system that answers the question every security team dreads: "When was this credential last rotated, and who has access to it?"
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the Python project and credential registry** Initialize a Python project using `uv` with FastAPI for the API layer and SQLAlchemy for the database (PostgreSQL). Design a credential registry schema that tracks: credential type, owning service, creation date, last rotation date, rotation policy (max age in days), rotation method (manual or automated), current status (active, stale, expired, compromised), and an audit trail of all changes. Build CRUD API endpoints for registering and managing credentials. Never store the actual secret values — only metadata, hashes for verification, and rotation timestamps.
|
||||
|
||||
2. **Build the policy engine** Create a flexible policy engine that defines rotation requirements per credential type: API keys must rotate every 90 days, database passwords every 60 days, TLS certificates 30 days before expiry, SSH keys every 180 days, and OAuth client secrets every 120 days. Policies should be configurable via YAML files. Implement a policy evaluator that runs on a schedule (using APScheduler) and flags any credential that violates its rotation policy. Support policy exceptions with documented justification and expiry dates so teams can request temporary extensions.
|
||||
|
||||
3. **Implement automated rotation for AWS IAM keys** Build an auto-rotation module for AWS IAM access keys using `boto3`. The rotation process should: create a new access key for the IAM user, update the credential in the consuming service (via a configurable webhook or direct API call), verify the new key works by making a test API call, deactivate the old key, wait a configurable grace period, then delete the old key. Implement a rollback mechanism that reactivates the old key if verification fails. Log every step with timestamps for the audit trail. This module serves as the template for other auto-rotation implementations.
|
||||
|
||||
4. **Add auto-rotation for PostgreSQL passwords** Build a rotation module that connects to PostgreSQL as a superuser, generates a cryptographically strong new password, executes `ALTER ROLE ... PASSWORD ...`, updates the consuming application's configuration (via environment variable injection, Kubernetes secret update, or webhook callback), and verifies the new password works. Handle the tricky case where active database connections using the old password must be allowed to finish gracefully. Implement connection testing that waits for the application to start using the new credential before marking rotation complete.
|
||||
|
||||
5. **Build TLS certificate monitoring and renewal** Implement a certificate monitor that scans configured endpoints, parses the X.509 certificate, extracts the expiration date, and calculates days until expiry. Integrate with Let's Encrypt via the ACME protocol (using a library like `acme`) to automatically renew certificates when they are within the policy window. For non-Let's Encrypt certificates, generate CSRs and notify administrators. Track the full certificate chain, including intermediate certificates, and alert if any certificate in the chain is approaching expiry.
|
||||
|
||||
6. **Create the alerting and notification system** Build a multi-channel alerting system that sends notifications via webhook (Slack, Discord, Teams), email (via SMTP), and PagerDuty integration for critical alerts. Implement escalation levels: warning (credential approaching rotation deadline), critical (credential past deadline), and emergency (credential potentially compromised). Include snooze functionality so alerts can be temporarily silenced with a justification. Build alert deduplication to prevent notification fatigue — batch related alerts into a single daily digest except for emergency-level items.
|
||||
|
||||
7. **Build the compliance reporting dashboard** Create a FastAPI-served web dashboard (or JSON API for frontend integration) that provides: an overview of all credentials with their rotation status (color-coded), a compliance scorecard showing percentage of credentials meeting policy, a timeline view of upcoming rotations for the next 30/60/90 days, historical audit trails for any credential, and exportable reports in PDF and CSV format. Implement compliance report templates for SOC 2, ISO 27001, and PCI-DSS that map your rotation data to specific control requirements.
|
||||
|
||||
8. **Add discovery scanning and integration testing** Build a credential discovery module that scans infrastructure for unregistered credentials: AWS IAM keys not in the registry, PostgreSQL roles with passwords, TLS certificates on running services, and SSH authorized keys on hosts. Flag any discovered credential that is not tracked in the registry as "unmanaged" and alert the team. Write integration tests using Docker Compose that spin up PostgreSQL, a mock AWS endpoint (LocalStack), and the full application, then test the complete rotation lifecycle: register, monitor, auto-rotate, verify, and report.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Credential lifecycle management and rotation best practices
|
||||
- AWS IAM key rotation with zero-downtime strategies
|
||||
- PostgreSQL credential management and connection handling
|
||||
- X.509 certificate chain validation and ACME protocol
|
||||
- Compliance frameworks (SOC 2, ISO 27001, PCI-DSS) credential requirements
|
||||
- Alerting design: escalation levels, deduplication, and notification fatigue
|
||||
- Audit trail design for security operations
|
||||
- Infrastructure scanning and credential discovery
|
||||
|
||||
## Deliverables
|
||||
- FastAPI application with credential registry and policy engine
|
||||
- Auto-rotation modules for AWS IAM keys, PostgreSQL passwords, and TLS certificates
|
||||
- Multi-channel alerting system with escalation and deduplication
|
||||
- Compliance reporting dashboard with SOC 2 and PCI-DSS templates
|
||||
- Credential discovery scanner for unmanaged secrets
|
||||
- Docker Compose integration test environment with full lifecycle testing
|
||||
- YAML-based policy configuration with exception management
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# DLP Scanner
|
||||
|
||||
## Overview
|
||||
Build a Data Loss Prevention scanner in Python that detects sensitive data across filesystems, databases, and network traffic by matching patterns for PII, financial data, healthcare records, API keys, and custom-defined secrets. This project teaches how enterprise DLP systems work under the hood — the same pattern matching, contextual analysis, and classification logic used by tools like Symantec DLP, Microsoft Purview, and open-source alternatives. You will generate compliance reports mapped to GDPR, HIPAA, and PCI-DSS requirements, making this tool practical for real security audits.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the Python project and scanner architecture** Initialize a Python project with `uv` and design a modular scanner architecture with three input adapters (filesystem, database, network), a shared detection engine, and multiple output formatters (JSON, CSV, PDF). Define a `ScanTarget` abstract class that each adapter implements, providing a `stream_content()` method that yields chunks of text with source metadata (file path, table name, packet info). This abstraction lets the same detection engine work across all data sources. Use `pydantic` for configuration models and scan result structures.
|
||||
|
||||
2. **Build the pattern detection engine** Implement a multi-strategy detection engine that combines regex matching, checksum validation, and contextual analysis. For regex, build patterns for: Social Security numbers (with and without dashes, validated against known invalid ranges), credit card numbers (Visa, Mastercard, Amex, Discover with Luhn checksum validation), phone numbers (US and international formats), email addresses, dates of birth, and passport numbers. For API keys, build patterns matching known formats: AWS access keys (AKIA prefix), GitHub tokens (ghp_ prefix), Stripe keys (sk_live_ prefix), and generic high-entropy strings. Each pattern should have a confidence score reflecting how likely the match is a true positive.
|
||||
|
||||
3. **Implement the filesystem scanner** Build a filesystem adapter that recursively scans directories while respecting exclusion patterns (skip `.git`, `node_modules`, `__pycache__`, binary files). Support common file formats: plain text, CSV, JSON, XML, YAML, PDF (using `pdfminer`), Word documents (using `python-docx`), Excel spreadsheets (using `openpyxl`), and compressed archives (zip, tar.gz). For each file, extract text content, run it through the detection engine, and record findings with the exact file path, line number, column position, and a redacted preview of the match. Implement parallel scanning using `concurrent.futures` to handle large directory trees efficiently.
|
||||
|
||||
4. **Build the database scanner** Create a database adapter that connects to PostgreSQL, MySQL, and SQLite databases, enumerates all tables and columns, samples data from each column (configurable sample size, default 1000 rows), and runs the detection engine on sampled values. Implement column-level classification: if more than a configurable threshold of sampled values match a pattern, classify the entire column as containing that data type. Generate a data map showing which tables and columns contain sensitive data and what type. Support connection via connection string or environment variable. Handle large databases by scanning in batches to avoid memory issues.
|
||||
|
||||
5. **Implement the network traffic scanner** Build a network adapter using `scapy` that captures live traffic or reads PCAP files and extracts text content from unencrypted protocols: HTTP request/response bodies, SMTP email content, FTP commands and data transfers, and DNS query names. Run extracted content through the detection engine to identify sensitive data in transit. Flag any sensitive data found in unencrypted traffic as a critical finding since it indicates data exposure. For encrypted traffic, note the protocol and destination but do not attempt decryption — the finding here is confirming that sensitive data paths are encrypted.
|
||||
|
||||
6. **Build the contextual analysis and false positive reduction system** Implement contextual analysis that examines the surrounding text to improve classification accuracy. A nine-digit number near the word "SSN" or "Social Security" has higher confidence than one in isolation. A sixteen-digit number in a test file containing "4111111111111111" is likely test data, not a real card number. Build a false positive suppression system: maintain an allowlist of known test values, known safe file paths, and patterns that appear in code comments or documentation. Support user feedback where a finding can be marked as false positive and the system remembers it for future scans.
|
||||
|
||||
7. **Create compliance report generators** Build report generators for three compliance frameworks: GDPR (identify personal data processing locations, data subject categories, and cross-border data flows), HIPAA (detect PHI including patient names near medical record numbers, diagnosis codes, and prescription information), and PCI-DSS (locate cardholder data environments and verify they are within defined CDE boundaries). Each report maps findings to specific regulation articles or requirements (e.g., GDPR Article 30 records of processing, PCI-DSS Requirement 3 stored cardholder data). Output reports in PDF with executive summary, detailed findings, and remediation recommendations.
|
||||
|
||||
8. **Add scheduling, alerting, and integration testing** Implement a scan scheduler that runs periodic scans (daily, weekly) and tracks changes over time: new sensitive data found, previously found data remediated, and trend lines showing data exposure over weeks. Send alerts via webhook when critical findings are detected (credit card numbers in logs, SSNs in publicly accessible directories). Write integration tests using Docker Compose that set up PostgreSQL with planted sensitive data, a filesystem with test documents containing known patterns, and verify the scanner finds all planted data with the correct classification. Measure false positive and false negative rates against the test dataset.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Regular expression design for sensitive data pattern matching
|
||||
- Luhn checksum and other data validation algorithms
|
||||
- Data classification methodology and confidence scoring
|
||||
- False positive reduction through contextual analysis
|
||||
- GDPR, HIPAA, and PCI-DSS data protection requirements
|
||||
- Network traffic analysis for data loss detection
|
||||
- Compliance reporting and audit trail generation
|
||||
- Scheduled scanning and trend analysis for security posture tracking
|
||||
|
||||
## Deliverables
|
||||
- Python DLP scanner with filesystem, database, and network adapters
|
||||
- Pattern detection engine with 15+ sensitive data patterns and validation
|
||||
- Contextual analysis system with false positive reduction
|
||||
- Compliance report generators for GDPR, HIPAA, and PCI-DSS
|
||||
- Scan scheduler with trend tracking and webhook alerting
|
||||
- Docker Compose integration test suite with planted sensitive data
|
||||
- PDF report output with executive summary and remediation guidance
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
# GraphQL Security Tester
|
||||
|
||||
## Overview
|
||||
Build an automated security testing tool in Python for GraphQL APIs that discovers and exploits common GraphQL-specific vulnerabilities: introspection exposure, query depth and complexity attacks, authorization bypass, field suggestion abuse, batching attacks, and mutation injection. You will also build an intentionally vulnerable GraphQL server to test against, creating a complete offensive and defensive learning environment. GraphQL's flexible query language introduces unique attack surfaces that traditional web application scanners miss entirely, making specialized tooling essential for modern API security.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the project and build the vulnerable GraphQL server** Initialize a Python project with `uv` and create an intentionally vulnerable GraphQL API using `strawberry-graphql` with FastAPI. Design a schema for a multi-tenant application with users, organizations, projects, and secrets. Deliberately introduce vulnerabilities: leave introspection enabled in production mode, implement no query depth limits, use sequential integer IDs (enabling enumeration), implement authorization checks at the resolver level but inconsistently (some resolvers skip checks), and expose sensitive fields that should be filtered based on user role. Seed the database with test data across multiple tenants so authorization bypass is demonstrable.
|
||||
|
||||
2. **Build the introspection analysis module** Implement a module that sends the standard GraphQL introspection query (`__schema`) and parses the complete schema: all types, fields, arguments, mutations, subscriptions, and their relationships. Build a schema analyzer that automatically identifies security-relevant findings: fields named password, secret, token, or key; mutations that modify user roles or permissions; types that expose internal identifiers; deprecated fields that might have weaker security controls; and input types that accept file uploads. Generate a visual schema map in DOT format (for Graphviz) and a structured JSON report of all findings.
|
||||
|
||||
3. **Implement query depth and complexity attacks** Build a module that generates deeply nested queries to test for denial-of-service vulnerabilities. Start with the schema analysis to find circular relationships (e.g., User has Projects, Project has Members who are Users), then automatically generate queries that exploit these cycles to create exponential query complexity. Implement configurable depth (10, 20, 50, 100 levels) and breadth (number of fields per level). Measure server response time and memory usage to determine when the server becomes degraded. Also implement field duplication attacks (requesting the same expensive field thousands of times via aliases) and fragment spread attacks.
|
||||
|
||||
4. **Build the authorization bypass testing module** Implement systematic authorization testing: for each query and mutation in the schema, send requests with no authentication, with a low-privilege user token, and with a token for a different tenant. Compare responses to detect authorization failures — if a low-privilege user can access a field that returns data for another tenant, that is an IDOR (Insecure Direct Object Reference). Build an automated IDOR scanner that iterates through sequential and UUID-based identifiers on every field that accepts an ID argument. Test for horizontal privilege escalation (accessing another user's data at the same privilege level) and vertical escalation (accessing admin-only fields as a regular user).
|
||||
|
||||
5. **Implement batching and mutation injection attacks** Build a module that exploits GraphQL batching (sending arrays of queries in a single request) to amplify attacks: send 1000 login attempts in a single HTTP request to bypass rate limiting, batch multiple mutations to test for transaction isolation issues, and use batched queries to enumerate valid identifiers. Implement mutation injection testing: for mutations that accept complex input types, test each field for injection vulnerabilities by inserting SQL injection payloads, NoSQL injection operators, and command injection strings. Track which payloads trigger error messages that reveal internal implementation details.
|
||||
|
||||
6. **Build the field suggestion and information disclosure module** Implement a module that exploits GraphQL's helpful error messages. When you query a non-existent field, many GraphQL servers suggest similar valid field names in the error response. Use this to enumerate the schema even when introspection is disabled: start with common field names (id, name, email, password, role, admin), extract suggestions from error messages, and recursively probe suggested fields to reconstruct the schema. Also test for verbose error messages that leak stack traces, database query details, or internal service URLs. Build a schema reconstruction engine that maps the discovered fields into a partial schema.
|
||||
|
||||
7. **Create the subscription abuse testing module** Implement testing for GraphQL subscription vulnerabilities: connect to the WebSocket endpoint and subscribe to events across tenant boundaries (can User A receive events for User B's data?), subscribe to an excessive number of channels simultaneously (resource exhaustion), and test whether subscription authentication is validated on connection and on each event delivery. Also test for subscription injection — whether subscription filter arguments are vulnerable to the same injection attacks as queries. Measure WebSocket connection limits and server resource consumption under subscription load.
|
||||
|
||||
8. **Build the reporting engine and CI integration** Create a comprehensive reporting engine that aggregates findings from all modules into a unified security report. Categorize findings by severity (critical, high, medium, low, informational) using a scoring system aligned with OWASP API Security Top 10. Generate reports in JSON (for automation), HTML (for stakeholders with interactive severity filtering), and SARIF (for GitHub code scanning integration). Build a CI/CD mode that runs a configurable subset of tests and returns a non-zero exit code if findings above a severity threshold are detected. Include a `--baseline` mode that compares current results against a previous scan and only reports new findings.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- GraphQL schema structure and introspection mechanics
|
||||
- Query depth and complexity as denial-of-service vectors
|
||||
- Authorization models in GraphQL: field-level, type-level, and resolver-level
|
||||
- IDOR vulnerabilities in GraphQL through ID enumeration
|
||||
- Batching attacks for rate limit bypass and brute force amplification
|
||||
- Schema reconstruction when introspection is disabled
|
||||
- WebSocket security for GraphQL subscriptions
|
||||
- OWASP API Security Top 10 mapping for GraphQL-specific issues
|
||||
|
||||
## Deliverables
|
||||
- Python security testing CLI for GraphQL APIs
|
||||
- Intentionally vulnerable GraphQL server with multi-tenant data
|
||||
- Introspection analyzer with visual schema mapping
|
||||
- Query depth/complexity attack generator with DoS measurement
|
||||
- Authorization bypass scanner with IDOR detection
|
||||
- Batching and mutation injection testing modules
|
||||
- Schema reconstruction engine via field suggestion exploitation
|
||||
- Unified reporting in JSON, HTML, and SARIF formats with CI integration
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# JA3/JA4 TLS Fingerprinting Tool
|
||||
|
||||
## Overview
|
||||
Build a TLS client fingerprinting tool in Rust that identifies and classifies clients by their TLS handshake parameters — cipher suites, extensions, supported groups, and signature algorithms. Implement both the legacy JA3 algorithm and the modern JA4+ fingerprinting standard to generate unique client fingerprints without decrypting traffic. This project teaches how TLS metadata leaks client identity information even over encrypted connections, how security teams use fingerprinting to detect automated tools and malicious software, and why this technique is one of the most powerful passive network analysis methods available today.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the Rust project and packet capture foundation** Create a new Rust project with `cargo` and add dependencies for packet capture (`pcap` crate), TLS parsing (`tls-parser`), and async runtime (`tokio`). Build a packet capture module that can read from a live network interface or a PCAP file. Implement a BPF filter for TCP port 443 (and configurable additional ports) to capture only TLS-relevant traffic. Parse the Ethernet, IP, and TCP layers to extract the TCP stream, then reassemble TCP segments to reconstruct complete TLS handshake messages. Handle fragmented ClientHello messages that span multiple TCP segments.
|
||||
|
||||
2. **Implement the JA3 fingerprinting algorithm** Parse TLS ClientHello messages and extract the five fields used by JA3: TLS version, cipher suites (as a comma-separated list of decimal values), extensions (as a comma-separated list of type numbers), elliptic curves (supported groups), and elliptic curve point formats. Concatenate these fields with commas and generate an MD5 hash to produce the JA3 fingerprint. Implement the GREASE filtering step (remove GREASE values from cipher suites and extensions as they are randomized padding). Verify your implementation against known JA3 fingerprint databases to confirm correctness.
|
||||
|
||||
3. **Implement the JA4+ fingerprinting suite** Build the modern JA4 fingerprint which improves on JA3 by including: the TLS version, SNI presence, number of cipher suites, number of extensions, ALPN first value, and sorted cipher suite and extension values (sorting eliminates ordering-based evasion). Also implement JA4S (server fingerprint from ServerHello), JA4H (HTTP client fingerprint from request headers), and JA4X (X.509 certificate fingerprint). The JA4 format uses a human-readable prefix section followed by a truncated SHA256 hash, making fingerprints partially interpretable without a lookup database.
|
||||
|
||||
4. **Build the fingerprint database and matching engine** Create a SQLite-backed fingerprint database that stores known fingerprints with metadata: client name (Chrome, Firefox, curl, Python requests), version, operating system, and classification (legitimate browser, automation tool, known malware family). Pre-populate the database with fingerprints from public sources (ja3er.com, Salesforce JA3 repository, FoxIO JA4 database). Implement a matching engine that compares observed fingerprints against the database and returns the best match with a confidence score. Support fuzzy matching for partial fingerprint matches where some fields differ.
|
||||
|
||||
5. **Create the real-time analysis pipeline** Build a real-time processing pipeline that captures packets, extracts TLS handshakes, generates fingerprints, matches against the database, and outputs results with sub-second latency. Implement a ringbuffer for packet processing to handle high-throughput networks without dropping packets. Add statistical tracking: fingerprint frequency distribution, new (previously unseen) fingerprints, and fingerprint diversity per source IP. Use Rust's type system and ownership model to ensure zero-copy packet processing where possible for performance.
|
||||
|
||||
6. **Implement anomaly detection and threat identification** Build detection rules that flag suspicious fingerprint patterns: a client claiming to be Chrome but presenting a non-Chrome JA3/JA4 fingerprint (user agent spoofing), the same source IP presenting different fingerprints across connections (rotating tools), fingerprints matching known malware families or command-and-control frameworks, and TLS clients using unusual cipher suites or extension combinations. Implement an alert system that logs anomalies with the source IP, timestamp, expected vs observed fingerprint, and the detection rule that triggered.
|
||||
|
||||
7. **Build the web dashboard and API** Create an HTTP API using `axum` or `actix-web` that exposes: real-time fingerprint observations as a Server-Sent Events stream, a search endpoint for querying the fingerprint database, statistics on fingerprint distribution and trends over time, and an alert feed of detected anomalies. Build a simple web dashboard (serve static HTML/JS) that visualizes fingerprint distribution as a pie chart, shows a live stream of observed fingerprints, and highlights anomalies. Include CSV and JSON export for integration with SIEM systems.
|
||||
|
||||
8. **Add PCAP analysis mode and write comprehensive tests** Implement a batch analysis mode that processes PCAP files and generates a complete fingerprint report: all unique fingerprints observed, their frequency, matched identities, and any anomalies. This is essential for forensic analysis of captured traffic. Write comprehensive tests using known PCAP samples with pre-calculated fingerprints to verify your JA3 and JA4 implementations are correct. Benchmark the tool's throughput (target: 10,000+ fingerprints per second on commodity hardware). Document the privacy implications of TLS fingerprinting and how clients can mitigate it.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- TLS handshake protocol and ClientHello message structure
|
||||
- JA3 and JA4+ fingerprinting algorithm specifications
|
||||
- Passive network analysis without traffic decryption
|
||||
- Packet capture, BPF filtering, and TCP stream reassembly
|
||||
- Fingerprint databases and fuzzy matching techniques
|
||||
- Anomaly detection through TLS metadata analysis
|
||||
- Rust systems programming for high-performance network tools
|
||||
- Privacy implications of TLS fingerprinting
|
||||
|
||||
## Deliverables
|
||||
- Rust binary for live capture and PCAP file analysis
|
||||
- JA3 and JA4+ fingerprint generation with GREASE filtering
|
||||
- SQLite fingerprint database pre-populated with known signatures
|
||||
- Real-time analysis pipeline with anomaly detection rules
|
||||
- Web dashboard with live fingerprint stream and statistics
|
||||
- HTTP API for SIEM integration with SSE and JSON/CSV export
|
||||
- Comprehensive test suite verified against known PCAP samples
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Lua Nginx Edge Backend
|
||||
|
||||
## Overview
|
||||
Build a complete CRUD application backend running entirely through Lua embedded in Nginx using OpenResty, with zero traditional application servers. Authentication with JWT validation, rate limiting, request validation, database queries via PostgreSQL, response caching, and input filtering all happen at the Nginx edge layer in Lua. This project teaches the power of edge computing for API backends and why companies like Cloudflare, Kong, and Amazon CloudFront invest heavily in edge logic. You will learn that the boundary between "web server" and "application server" is artificial — Nginx with Lua can be both.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the OpenResty environment and project structure** Install OpenResty (the Nginx + LuaJIT bundle) and configure the project directory structure with separate directories for Lua modules, Nginx configuration, database migrations, and tests. Configure `nginx.conf` to load Lua modules from your project directory using `lua_package_path`. Set up a development workflow where Nginx reloads configuration on file changes (use `openresty -s reload` triggered by a file watcher). Create a base `init_by_lua_block` that loads shared configuration and initializes connection pools. Verify the setup by serving a simple JSON response from a `content_by_lua_block`.
|
||||
|
||||
2. **Implement PostgreSQL database access via pgmoon** Install and configure `pgmoon` (the pure Lua PostgreSQL driver) to connect to PostgreSQL from within Nginx. Implement connection pooling using `ngx.socket.tcp` keepalive to reuse database connections across requests. Build a database access module that provides parameterized query execution (preventing SQL injection), result parsing into Lua tables, and transaction support. Create database migrations for a sample application schema: users table, resources table (the CRUD target), and an audit log table. Test connection pooling by verifying that connections are reused and the pool size stays bounded under load.
|
||||
|
||||
3. **Build the CRUD API endpoints** Implement full CRUD operations for a resource entity: `POST /api/resources` (create), `GET /api/resources` (list with pagination), `GET /api/resources/:id` (read single), `PUT /api/resources/:id` (update), and `DELETE /api/resources/:id` (delete). Use `content_by_lua_block` in each Nginx location block to handle the request. Parse request bodies with `cjson`, validate input parameters, execute database queries via pgmoon, and return JSON responses with appropriate HTTP status codes. Implement pagination using cursor-based pagination (more efficient than OFFSET for large datasets). Handle errors gracefully with structured error responses.
|
||||
|
||||
4. **Implement JWT authentication at the edge** Build a JWT validation module in Lua that runs in `access_by_lua_block` before any request reaches the content handler. Parse the Authorization header, decode the JWT (using `lua-resty-jwt` or implement from scratch with `lua-resty-string` for HMAC-SHA256), validate the signature, check expiration and issuer claims, and extract the user identity. Store the authenticated user in `ngx.ctx` so content handlers can access it. Implement token refresh endpoints and build a user registration/login flow that issues JWTs. Reject unauthenticated requests with 401 and unauthorized requests with 403.
|
||||
|
||||
5. **Add rate limiting and request throttling** Implement rate limiting using `lua-resty-limit-traffic` with three strategies: per-IP rate limiting (using `ngx.shared.DICT` for shared memory across Nginx workers), per-user rate limiting (based on the authenticated JWT subject), and per-endpoint rate limiting (different limits for read vs write operations). Configure the shared memory zones in `nginx.conf`. Return proper 429 responses with `Retry-After` headers. Implement a sliding window algorithm rather than fixed windows to prevent burst abuse at window boundaries. Add rate limit headers to all responses (`X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`).
|
||||
|
||||
6. **Build input validation and security filtering** Create a request validation module that runs in `access_by_lua_block` to validate all incoming data before it reaches the content handler. Implement JSON schema validation for request bodies, URL parameter type checking and range validation, and header validation. Build an input filtering layer that detects and blocks SQL injection attempts, XSS payloads, path traversal sequences, and oversized request bodies. Use `ngx.re.match` with PCRE patterns for efficient regex matching. Log all blocked requests to a separate security log file with the blocked payload and the rule that triggered.
|
||||
|
||||
7. **Implement response caching and performance optimization** Build a caching layer using `lua-resty-lrucache` for in-worker caching and `ngx.shared.DICT` for cross-worker caching. Cache GET responses with configurable TTLs per endpoint. Implement cache invalidation on write operations (POST, PUT, DELETE should invalidate related cache entries). Add ETag support: generate ETags from response content hashes and handle `If-None-Match` headers to return 304 Not Modified when appropriate. Implement response compression with `gzip` for JSON responses. Benchmark the application with and without caching using `wrk` to measure the performance improvement.
|
||||
|
||||
8. **Add logging, monitoring, and deployment packaging** Implement structured JSON logging in `log_by_lua_block` that records: request method, path, status code, response time, authenticated user, rate limit state, cache hit/miss, and database query count. Send logs to stdout for container deployment compatibility. Build a `/healthz` endpoint that checks database connectivity and returns service status. Create a Docker Compose setup with OpenResty and PostgreSQL. Write a comprehensive test suite using `Test::Nginx` (the OpenResty test framework) or `curl`-based integration tests that verify all CRUD operations, authentication flows, rate limiting behavior, and cache correctness.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- OpenResty architecture and Nginx Lua module phases
|
||||
- Edge computing for API backends and the web server/app server convergence
|
||||
- Connection pooling and shared memory in Nginx worker processes
|
||||
- JWT authentication implementation at the edge layer
|
||||
- Rate limiting algorithms: sliding window vs fixed window vs token bucket
|
||||
- Input validation and security filtering at the edge
|
||||
- Response caching strategies and cache invalidation patterns
|
||||
- Lua programming patterns for high-performance request handling
|
||||
|
||||
## Deliverables
|
||||
- OpenResty-based CRUD API with zero application servers
|
||||
- PostgreSQL integration via pgmoon with connection pooling
|
||||
- JWT authentication module running in Nginx access phase
|
||||
- Three-strategy rate limiting system with shared memory
|
||||
- Input validation and security filtering middleware
|
||||
- Response caching with ETag support and cache invalidation
|
||||
- Docker Compose deployment with structured JSON logging
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
# Network Baseline Monitor
|
||||
|
||||
## Overview
|
||||
Build a network monitoring system that establishes normal traffic behavior baselines through packet analysis, detects deviations indicating potential compromises or attacks, and generates anomaly reports. This project teaches statistical analysis, network behavior modeling, and demonstrates anomaly detection techniques used in network security operations centers.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand network behavior modeling and anomaly detection principles** by learning that normal networks have relatively consistent patterns: traffic volume varies by time of day and day of week, specific services communicate on expected ports, particular traffic directions dominate, and protocol distributions remain relatively stable. Anomalies deviate from these patterns indicating potential incidents (compromised systems sending unusual traffic, reconnaissance scanning, data exfiltration, malware communications). Study baseline establishment: requires minimum collection period (weeks/months) capturing seasonal variations, filtering known anomalies from baseline, and establishing statistical models (mean, standard deviation, percentiles) for each metric.
|
||||
|
||||
2. **Implement network traffic collection and aggregation** using packet sniffing (scapy) or NetFlow/sFlow collection to gather network data: capture or receive traffic statistics, aggregate by protocol, source/destination IP, port, and time window (per-minute, per-hour). Build efficient storage: raw packet capture is too voluminous, statistical aggregation reduces data to manageable sizes. Create time-series database (InfluxDB, Prometheus, or custom) storing traffic statistics with timestamps enabling historical analysis and comparison.
|
||||
|
||||
3. **Build baseline establishment workflow** capturing normal network behavior: collect traffic statistics over extended period (minimum 2-4 weeks, ideally 3-6 months capturing seasonal patterns), compute statistics for each metric (traffic volume by protocol, top talkers, port usage, geographic distribution), and store baseline profiles. Implement multiple baseline profiles: hourly baselines (expect different traffic 9am vs. 2am), daily baselines (weekdays different from weekends), and seasonal baselines (holiday traffic patterns differ from normal).
|
||||
|
||||
4. **Create statistical anomaly detection** comparing current traffic against baselines: for each metric, compute current values and compare to baseline distribution using statistical methods (z-score detection: flag if current value >3 standard deviations from mean, moving average detection: compare against recent historical average, IQR method: flag values beyond interquartile range). Combine multiple signals into composite anomaly score (weighted combination of individual metric anomalies).
|
||||
|
||||
5. **Implement traffic pattern analysis** identifying specific anomalies beyond statistical deviations: detect port scanning (connection attempts to many ports from single source), data exfiltration (unusual volume to external IPs, especially to new/suspicious destinations), command-and-control communication (periodic connections to known malicious IPs, suspicious beaconing patterns), and lateral movement (unusual east-west traffic within network). Build pattern matching rules for known attack signatures.
|
||||
|
||||
6. **Create alert and escalation logic** triggering notifications when anomalies detected: graduated alerting (low anomaly score = log only, medium = alert analysts, high = auto-escalate), contextual alerts (alert if same IP repeatedly triggers alerts indicating persistence), and alert correlation (multiple simultaneous anomalies suggest coordinated incident vs. isolated event). Implement alert suppression preventing fatigue from repeated same anomalies.
|
||||
|
||||
7. **Build dashboards and visualization tools** displaying network behavior and anomalies: show baseline vs. current traffic metrics side-by-side for comparison, display anomaly timeline highlighting when deviations occurred, create geographic maps showing traffic origins/destinations, build protocol distribution comparisons. Provide drill-down capabilities: click on anomaly to view related traffic, analyze specific flows in detail, investigate source/destination systems.
|
||||
|
||||
8. **Build comprehensive documentation** explaining baseline establishment methodology, anomaly detection techniques, and investigation procedures. Discuss limitations (baselines require time to establish, new legitimate services may appear similar to attacks, encrypted traffic limits visibility into content), compare to commercial network security platforms (network behavioral analysis appliances, managed detection and response services). Provide incident investigation procedures: when anomaly detected, what analysis steps to take, how to determine if legitimate or malicious, integration with incident response workflows. Include examples of detected anomalies in real-world incidents demonstrating value of baseline monitoring.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Network traffic collection and aggregation
|
||||
- Time-series data storage
|
||||
- Statistical modeling and baselines
|
||||
- Anomaly detection algorithms
|
||||
- Z-score and IQR methods
|
||||
- Pattern recognition and signatures
|
||||
- Alert correlation and escalation
|
||||
- Network behavior analysis
|
||||
|
||||
## Deliverables
|
||||
- NetFlow/sFlow or packet-based collection
|
||||
- Traffic aggregation and statistics
|
||||
- Baseline establishment workflow
|
||||
- Multi-temporal baselines (hourly, daily, seasonal)
|
||||
- Z-score and moving average anomaly detection
|
||||
- Pattern-based detection for specific attacks
|
||||
- Alert generation and escalation
|
||||
- Correlation engine for multi-signal detection
|
||||
- Interactive dashboards and visualizations
|
||||
- Drill-down and investigation capabilities
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
# Network Intrusion Prevention System
|
||||
|
||||
## Overview
|
||||
Build a real-time network security system that inspects packet payloads using Snort rules or custom signatures to detect and automatically block malicious traffic. This project teaches network intrusion detection methodology, signature-based threat detection, and demonstrates core functionality of enterprise IPS/IDS systems protecting networks.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand intrusion detection vs. prevention and signature-based detection** by learning that IDS (Intrusion Detection System) passively monitors traffic and alerts on suspicious patterns, while IPS (Intrusion Prevention System) actively blocks malicious traffic. Study signature-based detection: patterns matching known malicious activity (Snort rules define signatures), compared to anomaly-based detection (deviations from normal behavior). Research Snort rule format: rules contain action (alert, drop), protocol filter (TCP, UDP), source/destination IP and port, and payload patterns using content modifiers.
|
||||
|
||||
2. **Implement packet capture and inspection** using `scapy` or `pyshark` to capture live network traffic, extract packet payloads, and analyze them against detection signatures. Build packet filtering logic: capture on specific interfaces, optionally filter by protocol or port to reduce processing overhead, and implement efficient payload extraction. Handle packet fragmentation and reassembly ensuring inspection works on reassembled streams rather than individual fragments that might evade detection.
|
||||
|
||||
3. **Build Snort rule parsing and matching** by implementing a parser that reads Snort rule format files and extracts detection patterns: identify protocol, direction, source/destination, and payload content/modifiers. Implement pattern matching logic checking packet payloads against rule content specifications (exact string match, regular expressions, hex patterns). Support common modifiers (nocase for case-insensitive matching, distance/offset for relative positioning, isdataat for checking data existence).
|
||||
|
||||
4. **Create custom signature development** allowing security teams to define additional detection signatures beyond standard Snort rules. Implement signature definition format (simple JSON or YAML) specifying protocol, port, payload pattern, and metadata. Support pattern types: exact strings, regular expressions, byte patterns (hexadecimal), and behavioral signatures (protocol state violations, malformed headers). Build rule testing capability allowing validation on traffic samples before deployment.
|
||||
|
||||
5. **Implement packet blocking and firewall integration** that actively prevents malicious traffic when detected: drop packets at network interface level using `netfilter` (Linux) or equivalent Windows mechanisms, add dynamic firewall rules blocking attacker IPs, or redirect traffic to monitoring/logging system. Implement safeguards preventing false positives from causing excessive blocking: graduated response (alert first, then block on repeated matches), whitelist exceptions for legitimate traffic, and manual override mechanisms.
|
||||
|
||||
6. **Build alert generation and logging** that triggers alerts when malicious packets detected, including packet details (source/destination, protocol, payload), matched rule, and severity classification. Log all matching packets for forensic analysis, maintain statistics on detected threats (which rules trigger most frequently, top attacking IPs, targeted services). Implement alert aggregation preventing notification fatigue from repeated matches of same attack.
|
||||
|
||||
7. **Create management dashboards and rule management** displaying real-time detection statistics, active blocking rules, and historical trends of detected attacks. Implement rule management: enable/disable specific rules, create custom rules through UI, and import/export rule sets. Provide rule recommendation feature suggesting which rules are effective based on threat landscape and network-specific activity.
|
||||
|
||||
8. **Build comprehensive documentation** explaining IDS/IPS concepts, Snort rule format and examples, and deployment best practices for your system. Discuss detection limitations (signatures only detect known attack patterns, novel attacks bypass signature detection necessitating anomaly detection), compare your implementation to production IPS systems (Snort, Suricata, commercial products), and explain how IPS fits into defense-in-depth strategy. Include rule tuning guidance, false positive management, and incident response workflows triggered by IPS alerts.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- IDS/IPS architecture and deployment
|
||||
- Packet reassembly and inspection
|
||||
- Snort rule format and parsing
|
||||
- Signature-based threat detection
|
||||
- Pattern matching algorithms
|
||||
- Firewall integration and blocking
|
||||
- Alert aggregation and management
|
||||
- Rule tuning and optimization
|
||||
|
||||
## Deliverables
|
||||
- Real-time packet capture and inspection
|
||||
- Snort rule parser and matcher
|
||||
- Custom signature development framework
|
||||
- Packet blocking with firewall integration
|
||||
- Alert generation and logging
|
||||
- Detection statistics and trending
|
||||
- Rule management and deployment
|
||||
- Dashboard with real-time metrics
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Nim Credential Harvester
|
||||
|
||||
## Overview
|
||||
Build a credential hygiene auditing tool in Nim that scans a Linux system for improperly stored secrets and generates a security posture report. Nim is increasingly adopted by security professionals because it compiles to small, dependency-free native binaries. This project teaches where applications and users commonly store credentials on Linux systems, why those default storage locations are insecure, and how penetration testers identify exposed secrets during authorized engagements. You will build the same type of reconnaissance tool used in professional security assessments while learning a language valued in the offensive security community.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the Nim development environment and project structure** Install Nim and Nimble, then create a project with a modular architecture where each audit target is a separate module implementing a common `Auditor` interface with a `scan()` method returning `seq[Finding]`. Define shared types for `Finding` (path, category, severity, description) and `AuditReport`. Configure static linking with `--passL:-static` for a zero-dependency binary. Set up cross-compilation targets for x86_64 and aarch64 Linux. The single-binary, no-dependency deployment model is why Nim appeals to security practitioners.
|
||||
|
||||
2. **Build the browser credential store auditor** Implement detection of credential databases in Firefox and Chromium browsers. Locate Firefox profile directories via `profiles.ini` and check for `logins.json` and `cookies.sqlite`. Find Chromium `Login Data` and `Cookies` SQLite databases. Report the number of stored entries, last modification time, and file permissions for each database found. Flag databases with world-readable or group-readable permissions as critical findings. The audit focuses on storage hygiene and access control posture.
|
||||
|
||||
3. **Implement SSH key and configuration auditing** Scan `~/.ssh/` for private keys (RSA, Ed25519, ECDSA, and non-standard filenames), configuration files, `known_hosts`, and `authorized_keys`. Inspect private key file headers to determine if they are passphrase-protected (encrypted PEM headers vs unencrypted). Flag unprotected private keys as high severity. Check file permissions against SSH best practices (private keys should be 600, the `.ssh` directory should be 700). Parse `~/.ssh/config` to enumerate configured hosts and identify entries using password authentication or disabled host key checking.
|
||||
|
||||
4. **Build the cloud provider configuration auditor** Scan standard locations for cloud provider configurations: AWS (`~/.aws/credentials`, `~/.aws/config`), GCP (`~/.config/gcloud/`), Azure (`~/.azure/`), and Kubernetes (`~/.kube/config`). For each discovered file, check permissions, parse the configuration to count the number of configured profiles or contexts, and identify whether credentials appear to be long-lived static keys versus short-lived session tokens. Flag any cloud credential file with permissions broader than owner-only. Report whether MFA or SSO configurations are present.
|
||||
|
||||
5. **Implement secrets-in-history detection** Read shell history files (`.bash_history`, `.zsh_history`, `.fish_history`) and apply pattern matching to identify commands that may have included inline secrets: environment variable exports containing words like KEY, SECRET, TOKEN, or PASSWORD, database connection strings with embedded credentials, and HTTP requests with authorization headers. Report the file, approximate line region, and a redacted preview for each match. Also scan for `.env` files in the home directory tree and report their locations, sizes, and permissions.
|
||||
|
||||
6. **Build the risk scoring and report generator** Assign each finding a severity score based on credential type sensitivity, access protection level, and exposure scope. Aggregate findings into a structured report with sections per category, an executive summary with an overall security posture rating (A through F), and specific remediation steps for each finding type (how to add SSH key passphrases, fix file permissions, migrate to credential managers, enable MFA). Output the report in JSON for tooling integration and as a formatted ANSI terminal display for human review.
|
||||
|
||||
7. **Add operational safety and output handling** Implement a `--dry-run` mode that lists which paths would be examined without reading content. Add `--scope` flags to limit auditing to specific categories. Build output encryption using AES-256-GCM with a passphrase-derived key so the audit report itself does not become a security liability. Implement an access log that records every filesystem path examined during the scan. Add `--exclude` patterns for paths that should be skipped. These features make the tool suitable for use during authorized professional assessments.
|
||||
|
||||
8. **Create a test environment and document usage** Build a Docker-based test environment that populates a container with mock credential files in all scanned locations: sample SSH keys (both protected and unprotected), dummy cloud configuration files, browser database stubs, and planted history entries. Run the auditor inside the container and verify it identifies all planted findings with correct severity ratings. Write documentation covering the tool's purpose, legal requirements for credential auditing, integration with penetration testing methodologies, and a comparison of findings against CIS Benchmark recommendations.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Linux credential storage locations across browsers, SSH, cloud tools, and shells
|
||||
- File permission models and their security implications on Linux
|
||||
- Nim programming language fundamentals and static compilation
|
||||
- Why Nim is adopted in the offensive security community
|
||||
- Credential hygiene assessment methodology
|
||||
- Risk scoring frameworks for security findings
|
||||
- CIS Benchmark alignment for credential storage
|
||||
- Ethical and legal requirements for security assessment tools
|
||||
|
||||
## Deliverables
|
||||
- Statically-linked Nim binary with modular auditing architecture
|
||||
- Five audit modules: browser, SSH/GPG, cloud providers, shell history, environment
|
||||
- Risk scoring engine with severity categorization and remediation guidance
|
||||
- Encrypted report output in JSON and formatted terminal display
|
||||
- Docker-based test environment with comprehensive mock credentials
|
||||
- Access logging for all filesystem operations during scans
|
||||
- Documentation covering authorized usage, legal requirements, and CIS alignment
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
# OAuth Token Analyzer
|
||||
|
||||
## Overview
|
||||
Create a tool that decodes JWT (JSON Web Tokens) used in OAuth implementations, validates cryptographic signatures, checks for common vulnerabilities like algorithm confusion and expired tokens, and displays token claims. This project teaches authentication security, JWT mechanics, and demonstrates analysis techniques for OAuth/OpenID Connect implementations.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand JWT structure and components** by learning that JWTs consist of three Base64-encoded parts separated by periods: header (specifies algorithm), payload (contains claims about the subject), and signature (cryptographic proof of authenticity). Study common JWT algorithms (HS256 for HMAC-SHA256 using symmetric keys, RS256 for RSA signatures using public/private keys) and understand how each works. Learn what claims typically appear in tokens (sub for subject/user ID, exp for expiration, iat for issued-at time, aud for audience, etc.).
|
||||
|
||||
2. **Implement JWT decoding functionality** using the `PyJWT` library to parse JWT tokens, extract header and payload components, and decode them from Base64 to readable JSON. Display the structured token information including algorithm used, all claims present, and token metadata like expiration time. Handle edge cases like malformed tokens and provide clear error messages when decoding fails.
|
||||
|
||||
3. **Build signature validation capabilities** that verify JWT signatures using various algorithms: for HS256 tokens, validate HMAC signatures by computing expected signature with provided key; for RS256/ES256 tokens, validate signatures using public key certificates. Allow users to provide keys/certificates or test common weak secrets (common patterns like "secret", "password", application names). Report whether signatures are valid or indicate tampering/forgery.
|
||||
|
||||
4. **Implement algorithm confusion detection** identifying the dangerous vulnerability where attackers can bypass signature verification by changing the algorithm field: detect when HS256 (symmetric) tokens could be confused with RS256 (asymmetric) algorithms, flag tokens using "none" algorithm (no signature required, highly dangerous), and identify algorithm downgrades. Explain the security implications of each detected vulnerability.
|
||||
|
||||
5. **Create expiration and timing analysis** checking whether tokens are currently valid or have expired, calculating remaining validity period, and flagging tokens with unusual timing (expiration far in future suggesting weak security, very short expiration suggesting session tokens). Display issued-at time, expiration time, and calculated age of tokens for temporal analysis.
|
||||
|
||||
6. **Build claims analysis and inspection** that displays all claims contained in token payload, identifies common claims (user ID, roles, permissions, email address), and flags suspicious claims. Detect privilege escalation attempts (roles or permissions beyond what user should have), check for sensitive information stored in token (passwords, API keys—never store these in tokens), and validate claim values are reasonable.
|
||||
|
||||
7. **Implement batch analysis and logging** accepting multiple tokens for analysis, supporting token import from files, and generating reports showing vulnerabilities across analyzed tokens. Create a database tracking analyzed tokens with their vulnerabilities, allowing tracking of token patterns and identifying systematic security issues. Export findings in formats suitable for security teams and developers.
|
||||
|
||||
8. **Build comprehensive documentation** explaining JWT concepts, discussing common OAuth/OIDC vulnerabilities, and providing examples of vulnerable vs. secure token implementations. Include guidance on detecting compromised tokens, handling token leakage, and implementing proper key management. Compare your tool to online JWT debuggers (jwt.io), discuss limitations (cannot validate without key material), and explain where JWT analysis fits into OAuth security assessment workflows during penetration testing and security audits.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- JWT structure and components
|
||||
- Cryptographic signature validation
|
||||
- Algorithm confusion and security vulnerabilities
|
||||
- HMAC and RSA signature algorithms
|
||||
- Claim analysis and token inspection
|
||||
- Expiration and timing validation
|
||||
- OAuth/OIDC security concepts
|
||||
|
||||
## Deliverables
|
||||
- JWT decoding and parsing
|
||||
- Multiple algorithm signature validation
|
||||
- Algorithm confusion detection
|
||||
- Expiration and timing analysis
|
||||
- Claims inspection and anomaly detection
|
||||
- Batch analysis and reporting
|
||||
- Vulnerable token identification
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
# OSINT Reconnaissance Framework
|
||||
|
||||
## Overview
|
||||
Build an Open Source Intelligence (OSINT) framework that aggregates publicly available information about targets from multiple sources including WHOIS, DNS, social media, breach databases, and search engines, automating reconnaissance for penetration testing and threat analysis. This project teaches information gathering techniques, API integration, and demonstrates tools used for threat intelligence and reconnaissance.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand OSINT techniques and information sources** by learning that OSINT collects intelligence exclusively from public sources (no hacking required): WHOIS provides domain/IP registration information and contact details, DNS queries reveal infrastructure, social media contains employee information and organizational structure, breach databases (HaveIBeenPwned, Breachbase) show compromised credentials, search engines and cached pages archive historical information, GitHub reveals infrastructure details and secrets in code. Study reconnaissance workflows: starting with target organization, discovering employee information, identifying infrastructure, finding application URLs, and collecting all information into profiles.
|
||||
|
||||
2. **Implement WHOIS and domain information collection** using `whois` library and APIs to query domain registration details: registrant information (name, organization, address, email, phone), nameservers, creation/expiration dates, and registrar details. Build IP WHOIS queries determining IP ownership and ISP details. Extract metadata indicating hosting providers, DNS services, and organizational information from WHOIS records.
|
||||
|
||||
3. **Build DNS reconnaissance functionality** querying multiple DNS record types (A, AAAA, MX, TXT, NS, CNAME, SOT) to map organizational infrastructure. Implement DNS enumeration discovering subdomains through zone transfers (if misconfigured), brute-force enumeration trying common subdomain names, and analyzing DNS propagation. Extract information about email servers (MX records), organizational domains (TXT records with DMARC/SPF), and hosting infrastructure.
|
||||
|
||||
4. **Create social media and people search integration** extracting information about target employees from LinkedIn, GitHub, Twitter, and other platforms. Build APIs to search for employees, extract employment history, skills, and organizational structure. Query GitHub for code repositories revealing infrastructure details, architecture information, and sometimes accidentally committed secrets. Parse public profiles extracting email addresses, phone numbers, and organizational information.
|
||||
|
||||
5. **Implement breach database queries** checking whether email addresses or usernames appear in known breaches using APIs like HaveIBeenPwned, Breachbase, or others. Retrieve compromised data associated with targets: leaked passwords (useful for credential stuffing attacks), personal information (dates of birth, phone numbers useful for social engineering), and behavioral information. Maintain local copies of popular breach databases for offline searching.
|
||||
|
||||
6. **Build search engine and cached data collection** using Google Custom Search API, Shodan API, and other search services to discover web-accessible resources: find email addresses through Google search, discover subdomain information via search engines, use Shodan to find services running on non-standard ports, and retrieve historical data from Internet Archive's Wayback Machine. Extract information about previously published pages revealing infrastructure changes over time.
|
||||
|
||||
7. **Create unified target profile generation** aggregating information from all sources into comprehensive dossier: compile employee information with social media profiles and organizational roles, correlate different identities (same person with multiple usernames), build infrastructure map showing hosting providers and services, identify email patterns and potential additional addresses. Generate timeline showing organizational changes and infrastructure modifications.
|
||||
|
||||
8. **Build comprehensive reporting with visualization** displaying collected intelligence organized by category: company/organizational structure with employee hierarchy, infrastructure diagram showing discovered services and hosting, timeline of discovered information and changes, breach information associated with employees, and risk assessment based on information exposure. Create mind maps visualizing relationships between discovered entities, generate exportable reports for penetration testing documentation, and provide raw data exports for analysis tools. Compare to commercial OSINT frameworks (Maltego, SpiderFoot, TheHarvester) and discuss limitations (information availability varies, privacy concerns, legal considerations around data use).
|
||||
|
||||
## Key Concepts to Learn
|
||||
- OSINT techniques and information sources
|
||||
- WHOIS and DNS reconnaissance
|
||||
- Social media scraping and aggregation
|
||||
- Breach database integration
|
||||
- Search engine and archive querying
|
||||
- Data correlation and entity linking
|
||||
- Target profiling methodology
|
||||
- Visualization and reporting
|
||||
|
||||
## Deliverables
|
||||
- WHOIS and domain information gathering
|
||||
- DNS reconnaissance and enumeration
|
||||
- Social media intelligence gathering
|
||||
- Breach database integration
|
||||
- Search engine reconnaissance
|
||||
- Internet Archive (Wayback Machine) querying
|
||||
- Unified target profile generation
|
||||
- Relationship mapping and visualization
|
||||
- Comprehensive OSINT reports
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
# Password Policy Auditor
|
||||
|
||||
## Overview
|
||||
Build a tool that audits Active Directory and local password policies against security best practices, tests for weak password implementations, and generates compliance reports identifying policy violations. This project teaches password security concepts, policy analysis, and demonstrates compliance assessment techniques used in security audits.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand password security best practices and policy standards** by learning NIST guidelines (minimum 12 characters, no composition requirements, avoid periodic changes unless compromised), CIS benchmarks, and regulatory standards (HIPAA, PCI-DSS, SOC 2). Study password policy components: minimum length requirements, complexity requirements (uppercase, lowercase, numbers, symbols), password age (how old password can be), password history (prevent reuse), account lockout policies (lock after N failed attempts). Understand trade-offs: complex requirements improve security but reduce usability and increase password reuse.
|
||||
|
||||
2. **Implement Active Directory policy extraction** using LDAP queries to retrieve password policy settings from Domain, Default Domain Policy GPO (Group Policy Object). Extract policy parameters: password minimum length, complexity requirement, maximum age, minimum age, history count, lockout threshold, and lockout duration. Build functions that query multiple domains if forest contains multiple domains, and handle policies applied to specific OUs that override domain defaults.
|
||||
|
||||
3. **Create local system policy analysis** for Windows systems, reading password policy settings from Security Policy or Registry: extract local account policies, user rights assignments, and audit policy settings. Build Linux policy analysis querying PAM (Pluggable Authentication Modules) configuration and checking password aging settings (/etc/login.defs, /etc/pam.d files). Support multiple operating systems through abstracted policy readers.
|
||||
|
||||
4. **Build policy evaluation and scoring** against best practices and regulatory requirements: compare extracted policies against known good baselines, identify gaps (minimum length too short, no lockout policy, password history too low), and calculate compliance score. Implement configurable evaluation criteria allowing different security levels (strict for financial institutions, moderate for general business, basic for non-critical systems). Generate findings with severity levels indicating which policy gaps present greatest risk.
|
||||
|
||||
5. **Implement password strength testing** attempting to crack user passwords: identify accounts with weak/default passwords (common patterns like "Password123!", admin credentials, company names), test password against wordlists and patterns. Build password strength calculator estimating entropy of each password and determining whether it meets minimum strength requirements. Test policy compliance of all user passwords (do they meet minimum length, complexity requirements?).
|
||||
|
||||
6. **Create policy violation detection** identifying which users violate password policies: accounts with passwords older than policy maximum age (should have changed password), accounts with identical or similar passwords suggesting weak history implementation (users changing passwords in ways that avoid history), accounts with never-expiring passwords. Build user reports showing each policy violation with user details and recommendations.
|
||||
|
||||
7. **Implement remediation recommendations and reporting** generating detailed compliance reports showing policy audit results, identified gaps, vulnerable passwords, and remediation steps. Provide recommendations for policy improvements (increase minimum length to 14 characters, implement account lockout after 5 failed attempts), create action items for administrative remediation, and calculate compliance percentage. Support different report formats for different audiences (executive summary with compliance score, detailed technical report with all findings).
|
||||
|
||||
8. **Build comprehensive documentation** explaining password policy concepts and security rationale, providing benchmarks and regulatory requirements comparison, and including deployment guidance. Discuss limitations (password policy is one component of identity security, also need multi-factor authentication, secure password reset procedures, user training), compare to commercial compliance auditing tools, and explain how password auditing fits into broader identity and access management (IAM) assessments. Include examples of policy audit reports and remediation workflows.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Password security standards (NIST, CIS, regulatory)
|
||||
- Active Directory and local policy structures
|
||||
- Policy extraction and parsing
|
||||
- Password strength assessment
|
||||
- Compliance scoring and evaluation
|
||||
- Remediation recommendation generation
|
||||
- Audit reporting and documentation
|
||||
- Multi-OS policy analysis
|
||||
|
||||
## Deliverables
|
||||
- Active Directory password policy extraction
|
||||
- Local system policy analysis (Windows, Linux)
|
||||
- Policy evaluation against best practices
|
||||
- Password strength testing
|
||||
- Policy violation identification
|
||||
- User compliance reporting
|
||||
- Remediation recommendations
|
||||
- Comprehensive audit reports
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Payload Obfuscation Engine
|
||||
|
||||
## Overview
|
||||
Build a multi-layered payload obfuscation engine in Go that transforms shellcode and executables through encoding, encryption, polymorphism, and structural manipulation to evade signature-based detection. This project teaches the fundamental cat-and-mouse game between malware authors and antivirus vendors by demonstrating how static signatures are defeated and why behavioral analysis became necessary. You will implement the same obfuscation techniques found in real-world frameworks like Veil, Shikata Ga Nai, and Cobalt Strike's artifact kit, then validate your output against YARA rules to measure evasion effectiveness.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the Go project and define the obfuscation pipeline architecture** Create a new Go module with a pipeline-based architecture where each obfuscation technique is a stage that accepts bytes in and produces bytes out. Define an interface like `Obfuscator` with an `Apply([]byte) ([]byte, error)` method so stages can be chained arbitrarily. Set up a CLI using `cobra` that accepts an input payload file, a list of obfuscation stages to apply (in order), and an output path. Include a `--rounds` flag to apply the full pipeline multiple times. This composable design mirrors how real obfuscation frameworks operate.
|
||||
|
||||
2. **Implement encoding-based obfuscation stages** Build three encoding stages: Base64 encoding with a custom alphabet (not the standard one, making signature matching harder), XOR encoding with a randomly generated key that is prepended to the output, and AES-256-CBC encryption where the key is derived from a passphrase via PBKDF2. Each stage must embed a corresponding decoder stub so the payload can self-extract at runtime. For XOR, generate a new random key on every run so the output is never the same twice. Test each encoder independently by verifying round-trip encode/decode produces the original payload.
|
||||
|
||||
3. **Build the polymorphic instruction rewriter** Create a stage that disassembles x86-64 instructions (use the `golang.org/x/arch/x86/x86asm` package), identifies equivalent instruction substitutions (e.g., `mov eax, 0` becomes `xor eax, eax`, `add eax, 1` becomes `inc eax`, `push rbx; pop rax` replaces `mov rax, rbx`), and randomly applies them. Maintain a substitution table of at least 15 instruction equivalences. The rewriter should produce functionally identical code that looks completely different to a signature scanner. Log every substitution made so you can verify correctness.
|
||||
|
||||
4. **Add dead code insertion and string obfuscation** Implement a dead code insertion stage that adds NOP sleds, do-nothing instruction sequences (e.g., `push rax; pop rax`), opaque predicates (conditional jumps that always take the same path), and junk function calls that return immediately. Build a separate string obfuscation stage that finds ASCII string literals in the payload, splits them into chunks, and reconstructs them at runtime through concatenation. This defeats static string matching, which is one of the simplest and most common detection methods.
|
||||
|
||||
5. **Implement control flow flattening** Build a control flow flattening stage that replaces sequential basic blocks with a dispatcher loop. The dispatcher uses a state variable to determine which block to execute next, turning a linear control flow graph into a switch-case structure. This makes static analysis extremely difficult because the execution order is no longer visible in the binary structure. Use a randomly shuffled block ordering so each run produces a different arrangement.
|
||||
|
||||
6. **Create a YARA rule test suite** Write a collection of 15-20 YARA rules that detect common payload signatures: known shellcode byte sequences, suspicious API import patterns (VirtualAlloc, CreateRemoteThread), common encoder stubs, high entropy sections, and string indicators. Build a test harness that runs each obfuscated payload against the full YARA ruleset using `go-yara` bindings and reports which rules matched. Track the detection rate before and after each obfuscation stage to measure effectiveness.
|
||||
|
||||
7. **Build the analysis and reporting system** Create a reporting module that analyzes each obfuscated output and generates metrics: Shannon entropy per section, file size delta, number of instruction substitutions made, YARA detection rate, and a diff visualization showing what changed between the original and obfuscated versions. Output reports in both JSON (for automation) and a formatted terminal table (for human review). Include a `--benchmark` mode that runs all possible stage combinations and ranks them by evasion effectiveness.
|
||||
|
||||
8. **Add an HTTP API and integrate everything** Wrap the obfuscation engine in a lightweight HTTP API using `net/http` so it can be called programmatically. Accept multipart file uploads with a JSON configuration specifying which stages to apply. Return the obfuscated payload and the analysis report. Write integration tests that verify the full pipeline: upload a test payload, apply all stages, run YARA detection, and assert the detection rate dropped below a threshold. Document the ethical and legal boundaries of this tool clearly in the project README.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Encoding vs encryption vs obfuscation and when each applies
|
||||
- Polymorphic and metamorphic code generation techniques
|
||||
- x86-64 instruction semantics and equivalent substitutions
|
||||
- Control flow flattening and opaque predicates
|
||||
- YARA rule writing and signature-based detection mechanics
|
||||
- Shannon entropy analysis as a detection heuristic
|
||||
- The arms race between evasion techniques and detection engines
|
||||
- Ethical boundaries of offensive security tooling
|
||||
|
||||
## Deliverables
|
||||
- Go CLI tool with pluggable obfuscation pipeline
|
||||
- Five obfuscation stages: encoding, encryption, polymorphism, dead code, control flow flattening
|
||||
- YARA rule test suite with 15-20 detection rules
|
||||
- Analysis and reporting system with entropy and detection metrics
|
||||
- HTTP API for programmatic access
|
||||
- Integration tests proving evasion effectiveness
|
||||
- Documentation covering ethical use and legal considerations
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
# Privesc Playground
|
||||
|
||||
## Overview
|
||||
Build an intentionally vulnerable Linux environment in Python with 20+ privilege escalation paths that students can discover and exploit in a safe, isolated setting. This project covers the most common real-world privilege escalation vectors found during penetration tests: SUID binaries, sudo misconfigurations, cron job exploitation, writable PATH directories, Docker socket access, capability abuse, and more. You will learn how Linux permission models work at a deep level, why small misconfigurations compound into full system compromise, and how to detect these weaknesses with automated scanning tools like linPEAS and GTFOBins.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the base environment and container infrastructure** Create a Docker-based lab environment using Python scripts to orchestrate container creation and configuration. Build a base Debian image with common utilities installed (vim, gcc, python3, netcat, curl, wget). Design a user hierarchy: root, a service account, a standard user, and a restricted user. The Python orchestration layer should accept a configuration file (YAML) listing which vulnerability modules to enable, allowing students to customize the difficulty. Build a reset mechanism that destroys and recreates the container to its initial state in under 10 seconds.
|
||||
|
||||
2. **Implement SUID and SGID binary vulnerabilities** Create six SUID/SGID-based escalation paths: a custom SUID binary that calls `system()` with a user-controlled argument, a SUID copy of `find` (which can execute commands via `-exec`), a SUID Python interpreter, a SGID binary that writes to a group-writable sensitive file, a SUID binary vulnerable to shared library injection (writable LD_LIBRARY_PATH or RPATH), and a SUID binary that reads files without dropping privileges (allowing /etc/shadow access). For each, write the vulnerable C program, compile it, and set the SUID bit during container setup.
|
||||
|
||||
3. **Build sudo misconfiguration vulnerabilities** Configure five sudo-based escalation paths in `/etc/sudoers`: sudo access to `vim` (which allows shell escape), sudo access to `less` with NOPASSWD (shell escape via `!sh`), sudo access to `tar` (command execution via `--checkpoint-action`), sudo access to a custom script that uses unsanitized environment variables, and a wildcard sudo rule (`/opt/scripts/*.sh`) that allows path traversal. Each misconfiguration mirrors real findings from production penetration tests. The Python setup script should modify `/etc/sudoers` programmatically using `visudo` validation.
|
||||
|
||||
4. **Implement cron job and scheduled task vulnerabilities** Create four cron-based escalation paths: a root cron job that executes a world-writable script, a cron job that runs with wildcard expansion in a user-writable directory (tar wildcard injection), a cron job that sources a world-writable environment file, and a systemd timer that runs a script from a PATH directory writable by the standard user. Set up the cron jobs during container initialization and create a monitoring page that shows students when cron jobs last ran and what they produced, so they can verify their exploits worked.
|
||||
|
||||
5. **Build path and environment variable exploitation** Create four environment-based escalation paths: a root-owned script that calls a binary by name without full path (allowing PATH hijacking), a service that loads a shared library from a user-writable directory, a Python script running as root that imports from a writable `PYTHONPATH`, and a Perl script vulnerable to `@INC` manipulation. Each vulnerability teaches the principle that privilege escalation often comes from controlling the environment in which privileged code executes, not from bugs in the privileged code itself.
|
||||
|
||||
6. **Implement container and capability-based escalation** Create three container/capability escalation paths: expose the Docker socket (`/var/run/docker.sock`) to the standard user (allowing container escape to host), grant the `CAP_DAC_READ_SEARCH` capability to a binary (allowing reading any file regardless of permissions), and grant `CAP_SETUID` to a custom binary (allowing UID changes). Also create a scenario where the container runs with `--privileged` flag, allowing mount of the host filesystem. Each scenario should include a brief indicator in the environment that hints at the vulnerability without giving away the exploit.
|
||||
|
||||
7. **Build the automated scanning and hint system** Create a Python-based scanning tool that students can run to enumerate potential escalation vectors — a simplified version of linPEAS. The scanner should check: SUID/SGID binaries and cross-reference against GTFOBins, sudo permissions, writable cron scripts, writable PATH directories, Docker socket access, Linux capabilities on binaries, and world-writable sensitive files. For each finding, provide a risk rating and a hint that points toward the exploitation technique without fully revealing it. Include a `--solution` flag that shows the complete exploit for each vector.
|
||||
|
||||
8. **Create a progress tracking system and lab guides** Build a progress tracker where each escalation path has a flag (a unique string stored in a file only readable by root or in a specific location). When a student achieves escalation, they submit the flag via a lightweight web API running in the container. Track which flags have been captured and display progress. Write guided lab documentation for each vulnerability category with: the concept explanation, how to discover the vulnerability, exploitation steps, the underlying Linux mechanism being abused, and the fix (what the administrator should have done differently). Package everything with a single `docker compose up` command.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Linux file permission model: SUID, SGID, sticky bit, and capabilities
|
||||
- Sudo configuration syntax and common misconfiguration patterns
|
||||
- Cron job security and the risks of wildcard expansion
|
||||
- PATH hijacking and environment variable manipulation
|
||||
- Container security: Docker socket exposure and privileged mode risks
|
||||
- GTFOBins and living-off-the-land binary exploitation
|
||||
- Privilege escalation enumeration methodology
|
||||
- Defense hardening: how to prevent each escalation vector
|
||||
|
||||
## Deliverables
|
||||
- Docker-based vulnerable Linux environment with 20+ escalation paths
|
||||
- Python orchestration layer with YAML-based vulnerability selection
|
||||
- Six SUID/SGID vulnerabilities with compiled C binaries
|
||||
- Five sudo misconfiguration scenarios
|
||||
- Four cron job and four environment variable exploitation paths
|
||||
- Container escape and capability abuse scenarios
|
||||
- Automated scanning tool with GTFOBins cross-reference
|
||||
- Flag-based progress tracking system with guided lab documentation
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
# Privilege Escalation Path Finder
|
||||
|
||||
## Overview
|
||||
Build an analysis tool that examines Windows and Linux systems for privilege escalation vectors including SUID binaries, weak permissions, kernel exploits, and misconfigured services. This project teaches system hardening assessment, privilege escalation methodology, and demonstrates post-exploitation analysis techniques used in penetration testing.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand privilege escalation concepts and attack vectors** by learning that escalation converts limited user access to system/root access, enabling attackers to fully compromise systems. Study common vectors: SUID/SGID binaries (execute with elevated privileges), capabilities-based permissions (granular privilege delegation), weak file/directory permissions (overwrite critical files), kernel vulnerabilities (patches fix known exploits), misconfigurations (services running as root accepting user input), Sudo/sudoers misconfigurations (users can run privileged commands without passwords), and DLL hijacking. Research public exploit databases (Exploit-DB, CVE Details) tracking known escalation exploits.
|
||||
|
||||
2. **Implement SUID/SGID binary enumeration on Linux** by scanning filesystem for binaries with setuid/setgid bits set, extracting: file path, owner (should be restricted user, typically root), permissions, and file type. Use `find` command or direct system calls to identify all SUID/SGID binaries. Cross-reference discovered binaries against known vulnerable binaries database (certain versions of sudo, su, etc. have known escalation exploits). Analyze binary functionality: binaries accepting user input have escalation potential.
|
||||
|
||||
3. **Build file and directory permission analysis** examining permission structure for vulnerabilities: identify world-writable directories in critical paths (/tmp is expected, but /etc shouldn't be), world-readable files containing sensitive information (shadow files, SSH keys, configuration files), and misconfigured home directories. Build permission matrices showing which users/groups have access to which resources. Highlight permission mismatches (file readable by all when it should be restricted, directories writable by unprivileged users).
|
||||
|
||||
4. **Create kernel vulnerability scanning** identifying vulnerable kernel versions susceptible to known exploits: extract current kernel version, cross-reference against CVE databases, identify applicable exploits (DirtyCOW, PwnKit, Polkit vulnerabilities). Recommend patches and kernel updates. Handle multiple Linux distributions with different kernel versioning schemes.
|
||||
|
||||
5. **Implement service configuration analysis** examining running services for escalation opportunities: identify services running as root, analyze service configurations checking for accepted user input, identify common vulnerable services (Apache with mod_cgi, database services accepting client connections). Check init scripts and systemd service files for vulnerabilities (scripts with weak permissions allowing modification, environment variable injection opportunities).
|
||||
|
||||
6. **Build capability and sudo analysis** on Linux systems: extract capabilities set on binaries (granular privilege delegation), identify sudo configurations allowing specific users to run privileged commands. Parse sudoers files detecting misconfigurations (users with NOPASSWD tags, wildcards allowing excessive command execution, weak command restrictions). Analyze which commands users can elevate and their potential for escalation.
|
||||
|
||||
7. **Create Windows privilege escalation scanning** examining Windows systems for escalation vectors: identify services running as system/admin, analyze service permissions checking for weak DACLs (users can modify service executables), examine registry permissions for escalation opportunities, identify scheduled tasks running with elevated privileges that users can modify. Check for weak permissions on critical directories (Windows, System32, Program Files).
|
||||
|
||||
8. **Build comprehensive reporting with attack path analysis** generating reports showing discovered escalation vectors, creating attack paths (initial access → escalation vector → system compromise), and assigning severity scores. Provide proof-of-concept showing how each vector could be exploited, include remediation recommendations (patch vulnerable binaries, fix permission issues, implement least-privilege). Create executive summary highlighting critical escalation paths, compare to security benchmarks, and explain how escalation testing fits into penetration testing and system hardening assessments. Include documentation of escalation methodology, discussion of detection evasion, and incident response implications.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Privilege escalation vectors and techniques
|
||||
- SUID/SGID binaries and capabilities
|
||||
- File and directory permissions
|
||||
- Kernel vulnerabilities and CVEs
|
||||
- Service configuration analysis
|
||||
- Sudo and sudoers security
|
||||
- Windows service and registry analysis
|
||||
- Attack path identification
|
||||
|
||||
## Deliverables
|
||||
- SUID/SGID binary enumeration
|
||||
- File and directory permission analysis
|
||||
- Kernel vulnerability identification
|
||||
- Service configuration auditing
|
||||
- Capability analysis (Linux)
|
||||
- Sudoers configuration analysis
|
||||
- Windows privilege escalation vectors
|
||||
- Attack path visualization
|
||||
- Comprehensive escalation reporting
|
||||
- Proof-of-concept demonstrations
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Race Condition Exploiter
|
||||
|
||||
## Overview
|
||||
Build a fullstack application using FastAPI and React that demonstrates, detects, and exploits TOCTOU (Time of Check to Time of Use) race conditions in web applications. You will create an intentionally vulnerable e-commerce platform with double-spend vulnerabilities, coupon reuse bugs, and concurrent session abuse, then build an exploitation harness that sends parallel requests to trigger the race windows. This project teaches one of the most underexplored vulnerability classes in web security — race conditions are present in nearly every application that handles concurrent state mutations but are rarely tested because they require specialized tooling.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the fullstack project with a vulnerable e-commerce backend** Initialize a FastAPI backend with PostgreSQL and a React frontend. Build a simple e-commerce platform with user accounts, wallet balances, a product catalog, discount coupons, and an order system. Deliberately implement the purchase flow with a classic TOCTOU vulnerability: check the wallet balance in one query, then deduct it in a separate query without any locking or transaction isolation. Use SQLAlchemy with the default isolation level. Build a React storefront where users can browse products, apply coupons, and make purchases.
|
||||
|
||||
2. **Implement five distinct race condition vulnerabilities** Create five vulnerable endpoints: a double-spend on wallet transfers (check balance then deduct in separate operations), single-use coupon reuse (check if coupon is used then mark as used in separate steps), inventory oversell (check stock count then decrement without locking), concurrent account creation with the same email (check uniqueness then insert), and simultaneous password reset token consumption (check token validity then invalidate). Each vulnerability should be reachable through the normal React UI flow, making them realistic.
|
||||
|
||||
3. **Build the race condition exploitation harness** Create a Python-based exploitation tool that sends precisely timed concurrent HTTP requests to trigger race windows. Implement multiple concurrency strategies: `asyncio` with `aiohttp` for async parallelism, `threading` with `requests` for thread-based parallelism, and raw socket-level request pipelining for the tightest timing. Add a `--threads` flag to control concurrency level and a `--delay` flag to introduce microsecond-level offsets between requests. Implement HTTP/2 connection reuse to eliminate connection setup variance. The harness should report success/failure for each attempt and calculate the exploitation success rate over multiple runs.
|
||||
|
||||
4. **Create a real-time visualization dashboard** Build a React dashboard that visualizes race conditions as they happen. Use WebSocket connections from FastAPI to stream events. Show a timeline where each concurrent request is a horizontal bar, with the check operation and use operation marked as distinct phases. Color-code successful exploits (where two requests both passed the check) versus failed attempts. Display the database state in real-time: wallet balances, coupon usage counts, and inventory levels. This makes the race window visually tangible, which is critical for understanding the vulnerability class.
|
||||
|
||||
5. **Implement detection mechanisms** Build three race condition detection approaches: a middleware-based detector that logs all concurrent requests to the same endpoint with the same resource identifier and flags groups that arrive within a configurable time window, a database trigger approach that detects when a balance goes negative or a coupon usage count exceeds one, and a request fingerprinting system that identifies suspiciously identical requests arriving in bursts. Each detector should feed events into the WebSocket dashboard with explanations of what was detected.
|
||||
|
||||
6. **Build the fix implementation with toggleable patches** For each vulnerability, implement the proper fix using database-level controls: `SELECT ... FOR UPDATE` row-level locking, serializable transaction isolation, unique constraints with proper error handling, atomic compare-and-swap operations using `UPDATE ... WHERE balance >= amount`, and optimistic concurrency control with version columns. Make each fix toggleable via a feature flag API endpoint so users can switch between vulnerable and patched modes from the React UI and observe how the exploitation harness results change.
|
||||
|
||||
7. **Add a benchmarking and analysis mode** Create a benchmarking system that runs the exploitation harness against each vulnerability with and without fixes applied, across different concurrency levels (2, 5, 10, 25, 50 concurrent requests), and measures: exploitation success rate, average response time, database deadlock frequency, and throughput impact of the locking mechanisms. Generate comparative charts showing the tradeoff between security and performance. This teaches that fixing race conditions always has a performance cost, and the right fix depends on the acceptable tradeoff.
|
||||
|
||||
8. **Write comprehensive labs and package with Docker Compose** Create seven guided lab exercises, one for each vulnerability plus two focused on detection and fixing. Each lab includes the learning objective, setup steps, exploitation instructions, expected output, fix implementation, and verification. Package everything in Docker Compose with FastAPI, PostgreSQL, Redis (for distributed locking examples), and the React frontend. Include a `reset` endpoint that restores the database to its initial state so labs can be repeated. Write a reference guide explaining race condition theory, the happens-before relationship, and why application-level locking is insufficient.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- TOCTOU (Time of Check to Time of Use) vulnerability mechanics
|
||||
- Database transaction isolation levels and their security implications
|
||||
- Row-level locking with SELECT FOR UPDATE and advisory locks
|
||||
- Optimistic vs pessimistic concurrency control strategies
|
||||
- HTTP/2 connection multiplexing for precise timing attacks
|
||||
- Race condition detection through request pattern analysis
|
||||
- The performance-security tradeoff in concurrency control
|
||||
- Distributed locking patterns for microservice architectures
|
||||
|
||||
## Deliverables
|
||||
- FastAPI e-commerce backend with five race condition vulnerabilities
|
||||
- React frontend with storefront and real-time visualization dashboard
|
||||
- Python exploitation harness with multiple concurrency strategies
|
||||
- Three detection mechanisms with WebSocket-fed dashboard integration
|
||||
- Toggleable fix system with five database-level remediation patterns
|
||||
- Benchmarking system comparing exploitation rates across configurations
|
||||
- Seven guided lab exercises with Docker Compose packaging
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
# Reverse Shell Handler
|
||||
|
||||
## Overview
|
||||
Build a server application that listens for incoming reverse shell connections from compromised systems, enabling remote command execution, file transfer, and multi-client session management. This project teaches socket programming, command execution, and demonstrates core concepts used in penetration testing and post-exploitation frameworks like Metasploit.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand reverse shells and their mechanics** by learning that a reverse shell connects from the target system back to the attacker's server rather than the attacker connecting to the target. When established, the reverse shell provides interactive command execution as if you're logged into the remote system. Research common reverse shell payloads, understand why they're valuable in penetration testing (bypass firewalls that block inbound connections), and recognize that this powerful tool must only be used on authorized systems with explicit permission.
|
||||
|
||||
2. **Implement a socket server** using Python's `socket` library to listen on a specified port for incoming reverse shell connections. Create a listener that accepts multiple concurrent connections using threading or asyncio, assigns unique session IDs to each connection, and maintains a list of active sessions. Handle connection errors gracefully and implement logging that tracks all connections with timestamps and source information.
|
||||
|
||||
3. **Build command execution and sending logic** that takes user input from the attacker's CLI, sends commands to connected reverse shells, and receives and displays command output. Implement proper encoding/decoding for transmitting data over sockets, handle long-running commands that may produce large output, and manage shell interaction (stdin/stdout/stderr). Add session selection allowing the attacker to target specific compromised systems.
|
||||
|
||||
4. **Create file upload and download capabilities** allowing the attacker to transfer files to/from compromised systems—implement methods to read local files and send them to targets, and receive files from targets and save them locally. Add progress indicators for large file transfers and implement checksum verification ensuring file integrity. Handle path traversal safely and validate file operations don't access unauthorized locations.
|
||||
|
||||
5. **Develop multi-client session management** by maintaining a database of active sessions showing source IP, connection time, last activity, and target system information. Implement session switching, reconnection handling for dropped connections, and session persistence across temporary network interruptions. Create session history allowing review of all commands executed in each session for post-engagement documentation.
|
||||
|
||||
6. **Add advanced shell interaction features** like environment variable management (set PATH, USER, HOME on target systems), working directory tracking (cd command handling), shell history retrieval, and process manipulation (list processes, kill processes). Implement command aliases and shortcuts for commonly used attack commands, and add history functionality allowing review of previous commands.
|
||||
|
||||
7. **Build a CLI interface using `cmd2` or similar library** that provides a user-friendly command prompt with help documentation, tab completion, and easy session switching. Create commands for connecting to specific shells, sending commands, uploading/downloading files, listing sessions, and disconnecting. Implement aliases and macro support enabling complex multi-step attacks to be automated.
|
||||
|
||||
8. **Create comprehensive documentation emphasizing this tool is for authorized penetration testing only** with legal warnings about unauthorized system access. Provide setup instructions, usage examples showing common post-exploitation workflows, and discussion of detection evasion techniques and blue team countermeasures. Compare your implementation to commercial frameworks like Metasploit, discuss how reverse shells fit into broader attack chains, and include examples of legitimate penetration testing scenarios where this tool would be appropriate.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Socket programming and network communication
|
||||
- Multi-client server architecture with threading
|
||||
- Command execution and process management
|
||||
- File transfer protocols and verification
|
||||
- Session management and persistence
|
||||
- CLI design and user interaction
|
||||
|
||||
## Deliverables
|
||||
- Multi-client reverse shell listener
|
||||
- Command execution and output handling
|
||||
- File upload/download with verification
|
||||
- Session management with history tracking
|
||||
- Advanced shell interaction features
|
||||
- User-friendly CLI interface
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
# SBOM Generator
|
||||
|
||||
## Overview
|
||||
Build a Software Bill of Materials generator in Go that scans project directories, identifies dependencies from multiple ecosystems, resolves transitive dependency trees, and produces SBOM documents in both SPDX and CycloneDX formats. The tool cross-references discovered packages against CVE databases (NVD, OSV) to generate vulnerability reports alongside the SBOM. This project is directly relevant to US Executive Order 14028 on improving the nation's cybersecurity, which mandates SBOM production for all software sold to the federal government, making this a marketable real-world skill.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the Go project and parser framework** Create a Go module with a plugin-style architecture where each package ecosystem has its own parser implementing a common `DependencyParser` interface with `Detect(dir string) bool` and `Parse(dir string) ([]Package, error)` methods. Define shared types: `Package` (name, version, ecosystem, license, checksums), `DependencyTree` (package with resolved transitive dependencies), and `Vulnerability` (CVE ID, severity, affected versions, fix version). Build a CLI using `cobra` with subcommands for scanning, generating SBOMs, and checking vulnerabilities. The plugin architecture makes it easy to add new ecosystem support.
|
||||
|
||||
2. **Build dependency parsers for major ecosystems** Implement parsers for five ecosystems: Python (`requirements.txt`, `pyproject.toml`, `Pipfile.lock`, `uv.lock`), Go (`go.mod`, `go.sum`), Node.js (`package.json`, `package-lock.json`, `pnpm-lock.yaml`), Rust (`Cargo.toml`, `Cargo.lock`), and Java (`pom.xml`, `build.gradle`). Each parser should extract direct dependencies with version constraints from manifest files and exact resolved versions from lockfiles when available. Handle version constraint syntax for each ecosystem (semver ranges, tilde, caret, wildcards). Prioritize lockfile data over manifest data since lockfiles contain the actual resolved versions.
|
||||
|
||||
3. **Implement transitive dependency resolution** For each ecosystem, resolve the full transitive dependency tree. For ecosystems with lockfiles (Go, Node, Rust), parse the lockfile which already contains the complete resolution. For ecosystems without lockfiles, query the package registry API to resolve transitive dependencies: PyPI JSON API for Python, npm registry for Node, crates.io for Rust. Build a dependency graph data structure that tracks direct vs transitive relationships, depth level, and whether multiple versions of the same package exist (dependency conflicts). Implement cycle detection to handle circular dependencies gracefully.
|
||||
|
||||
4. **Add license detection and package metadata enrichment** For each discovered package, determine its license by checking: the lockfile (some include license data), the package registry API (most registries return license information), and local source files (scan for LICENSE, COPYING, and SPDX headers in source). Map license strings to SPDX license identifiers using the SPDX license list. Enrich package metadata with: download URL, package homepage, maintainer information, and content checksums (SHA-256). Flag packages with no detectable license, packages with copyleft licenses in proprietary projects, and packages with known problematic licenses.
|
||||
|
||||
5. **Generate SPDX format SBOMs** Implement SPDX 2.3 document generation in both JSON and tag-value formats. Map your internal data structures to SPDX concepts: each package becomes an `SPDXPackage` with SPDXID, name, version, download location, checksums, license, and supplier. Represent dependency relationships using SPDX `Relationship` elements (DEPENDS_ON, BUILD_TOOL_OF, DEV_DEPENDENCY_OF). Include document-level metadata: creator tool identification, creation timestamp, document namespace, and data license (CC0-1.0). Validate generated documents against the SPDX JSON schema to ensure compliance.
|
||||
|
||||
6. **Generate CycloneDX format SBOMs** Implement CycloneDX 1.5 document generation in JSON format. Map packages to CycloneDX `component` objects with type (library, framework, application), name, version, purl (Package URL), licenses, and hashes. Represent the dependency tree using CycloneDX `dependencies` objects that link each component to its direct dependencies. Include `metadata` with tool identification, component being described, and manufacture date. Validate generated documents against the CycloneDX JSON schema. Implement both the flat component list and the hierarchical dependency tree representation.
|
||||
|
||||
7. **Build the vulnerability scanner** Integrate with two vulnerability databases: the NVD (National Vulnerability Database) via its REST API and OSV (Open Source Vulnerabilities) via its API. For each package in the SBOM, query both databases for known CVEs affecting the detected version. Match using CPE identifiers for NVD and Package URLs for OSV. For each vulnerability found, record the CVE ID, CVSS score, severity rating, affected version range, fixed version (if available), and a brief description. Generate a vulnerability report sorted by severity that can be included as a VEX (Vulnerability Exploitability Exchange) document alongside the SBOM.
|
||||
|
||||
8. **Add CI/CD integration and policy enforcement** Build a `--check` mode that evaluates the SBOM against configurable policies and returns a non-zero exit code if violations are found. Policies include: no dependencies with critical CVEs, no dependencies with unknown licenses, no dependencies older than a configurable age threshold, and maximum allowed dependency tree depth. Implement GitHub Actions and GitLab CI configuration templates that run the SBOM generator on every PR and block merging if policy violations are detected. Write integration tests that scan known project fixtures and verify the generated SBOMs contain the expected packages, relationships, and vulnerability matches.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Software Bill of Materials purpose and regulatory requirements (EO 14028)
|
||||
- SPDX and CycloneDX specification structures and differences
|
||||
- Package manager dependency resolution across ecosystems
|
||||
- Transitive dependency trees and supply chain depth
|
||||
- License compliance detection and SPDX identifiers
|
||||
- CVE databases (NVD, OSV) and vulnerability matching via CPE and PURL
|
||||
- VEX documents for vulnerability communication
|
||||
- CI/CD integration for automated supply chain security
|
||||
|
||||
## Deliverables
|
||||
- Go CLI tool with pluggable ecosystem parsers
|
||||
- Five ecosystem parsers: Python, Go, Node.js, Rust, Java
|
||||
- Transitive dependency resolution with graph visualization
|
||||
- SPDX 2.3 and CycloneDX 1.5 document generation with schema validation
|
||||
- Vulnerability scanner integrating NVD and OSV databases
|
||||
- Policy enforcement engine with configurable rules
|
||||
- CI/CD templates for GitHub Actions and GitLab CI
|
||||
- Integration tests with known project fixtures
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
# SSL/TLS Certificate Scanner
|
||||
|
||||
## Overview
|
||||
Build a comprehensive SSL/TLS security scanner that identifies certificate misconfigurations including expired certificates, weak ciphers, missing HSTS headers, and Heartbleed vulnerabilities. This project teaches cryptographic certificate validation, TLS protocol analysis, and demonstrates techniques for assessing HTTPS implementations.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand SSL/TLS certificates and common vulnerabilities** by learning certificate structure (X.509 format), key components (subject, issuer, validity dates, public key), and chain of trust. Study certificate validation process: certificate must be signed by trusted Certificate Authority, must not be expired, domain name must match certificate CN or SAN (Subject Alternative Name), and key size should meet minimum requirements (2048-bit RSA, 256-bit ECC). Research vulnerabilities: expired certificates (easy to miss), self-signed certificates (no trusted CA), misconfigured SNI (Server Name Indication), weak ciphers (SSL 2.0, RC4), missing HSTS headers, and protocol vulnerabilities like Heartbleed.
|
||||
|
||||
2. **Implement certificate retrieval and parsing** using Python's `ssl` library and `cryptography` library to connect to target domains, retrieve SSL certificates, and parse X.509 certificate structure. Extract certificate details: subject CN and SANs (domains covered), issuer, validity dates (not-before, not-after), public key algorithm and size, signature algorithm, and certificate extensions (OCSP Stapling, Authority Info Access). Build certificate chain extraction retrieving all certificates from root to subject.
|
||||
|
||||
3. **Build certificate validation checking** verifying certificates meet security standards: check expiration (flag certificates expiring within 30/60/90 days for proactive renewal), verify domain names match (check CN and all SANs), validate certificate chain (all issuers up to root should be trusted), check public key strength (minimum 2048-bit RSA or 256-bit ECC), and verify signature algorithms are secure (SHA256+ signatures, not MD5 or SHA1). Flag certificates with unusual characteristics (self-signed, issued by untrusted CA, key reuse across multiple certificates).
|
||||
|
||||
4. **Implement TLS configuration scanning** analyzing TLS protocol negotiation and cipher selection: check supported SSL/TLS versions (flag SSL 2.0 and 3.0 as deprecated, TLS 1.0/1.1 as outdated, TLS 1.2 as minimum acceptable), test cipher suite support identifying weak ciphers (export-grade, null encryption, DES/RC4), and analyze cipher order preferences (server should prefer strongest ciphers). Use tools like OpenSSL or custom socket connections to test protocol versions and ciphers.
|
||||
|
||||
5. **Create vulnerability scanning for known TLS issues** testing for specific vulnerabilities: Heartbleed (CVE-2014-0160) affecting OpenSSL, POODLE (downgrade to SSL 3.0), CCS Injection, FREAK (forced weak key exchange), Logjam (weak Diffie-Hellman), and other known attacks. Implement tests for each vulnerability indicating whether target is vulnerable and recommended fixes.
|
||||
|
||||
6. **Build HTTP security header analysis** checking for security-related headers that should accompany HTTPS: HSTS (HTTP Strict-Transport-Security, enforces HTTPS), X-Content-Type-Options (prevents MIME sniffing), X-Frame-Options (prevents clickjacking), Content-Security-Policy, and others. Flag missing headers that would improve security, analyze header configuration for mismatches (HSTS missing or too short, CSP too permissive).
|
||||
|
||||
7. **Create comprehensive scanning and reporting** generating reports showing certificate details, validation results, TLS configuration analysis, vulnerability test results, and recommendations. Implement batch scanning for multiple domains, tracking changes over time (certificates renewed, cipher suites updated, vulnerabilities remediated). Build dashboards showing certificate inventory across organization, expiration timeline for proactive renewal, vulnerability summary, and compliance with security standards (CIS benchmarks, PCI-DSS, etc.).
|
||||
|
||||
8. **Build comprehensive documentation** explaining SSL/TLS concepts, certificate validation requirements, and common misconfigurations. Provide remediation guidance (renew expiring certificates, upgrade TLS versions, remove weak ciphers, add security headers), discuss limitations (your scanner tests configuration, automated testing has limits, manual analysis may reveal additional issues), and compare to commercial tools (Qualys SSL Labs, Nessus, OpenVAS). Include best practices for certificate management (automatic renewal, monitoring, testing), discuss organizational certificate policies, and explain integration into DevOps pipelines.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- X.509 certificate structure and validation
|
||||
- SSL/TLS protocol versions and security
|
||||
- Cipher suites and cryptographic algorithms
|
||||
- Certificate chain of trust
|
||||
- Known TLS vulnerabilities
|
||||
- HTTP security headers
|
||||
- HTTPS best practices
|
||||
- Certificate lifecycle management
|
||||
|
||||
## Deliverables
|
||||
- Certificate retrieval and X.509 parsing
|
||||
- Expiration checking and domain validation
|
||||
- TLS version and cipher suite analysis
|
||||
- Vulnerability testing (Heartbleed, POODLE, etc.)
|
||||
- HTTP security header analysis
|
||||
- Multi-domain batch scanning
|
||||
- Certificate inventory and timeline tracking
|
||||
- Remediation recommendations and reporting
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
# Self-Hosted Shodan Clone
|
||||
|
||||
## Overview
|
||||
Build your own internet-connected device search engine using Go for the scanning backend and React for the web interface. This project replicates the core functionality of Shodan and Censys by scanning IP ranges, fingerprinting running services, detecting software versions, and storing results in a searchable database. You will learn how service fingerprinting actually works at the protocol level, why exposed services are one of the most common attack surfaces, and how security teams use asset discovery to maintain visibility over their infrastructure. Scan only networks you own or have explicit authorization to scan.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the Go project and scanning architecture** Create a Go module with a worker-pool architecture for concurrent scanning. Use goroutines and channels to manage a configurable number of scanning workers (default 100). Implement a rate limiter using `golang.org/x/time/rate` to cap packets per second and avoid overwhelming networks. Design the scan target system to accept CIDR ranges, individual IPs, and exclusion lists. Store results in PostgreSQL with a schema optimized for search: separate tables for hosts, ports, services, and banners with full-text search indexes. Build a CLI using `cobra` with subcommands for scanning, querying, and managing the database.
|
||||
|
||||
2. **Build the TCP port scanner** Implement a SYN-based port scanner using raw sockets (via `gopacket`) for speed, with a TCP connect fallback for environments where raw sockets are not available. Scan the top 1000 most common ports by default, with an option to scan all 65535. Implement service detection based on port number as a first pass (port 22 is likely SSH, port 443 is likely HTTPS), but do not rely on it — the next step adds protocol-level fingerprinting. Handle scan timeouts, retransmissions, and rate limiting. Track scan progress and estimated time remaining. Store raw scan results (IP, port, state, response time) in the database immediately.
|
||||
|
||||
3. **Implement protocol-level service fingerprinting** Build protocol handlers for the most common services: HTTP/HTTPS (send a GET request, parse response headers for Server, X-Powered-By, and technology indicators), SSH (parse the banner for software version and supported algorithms), FTP (read the welcome banner), SMTP (read the 220 greeting), MySQL/PostgreSQL (initiate a connection handshake and read the server version), Redis (send INFO command), and MongoDB (send a serverStatus command). Each handler should extract the software name, version, and any configuration details visible in the response. Implement TLS certificate parsing for any TLS-enabled service to extract subject, issuer, expiration, and SANs.
|
||||
|
||||
4. **Add technology detection and CPE matching** Build a technology detection engine inspired by Wappalyzer. For HTTP services, analyze response headers, HTML content, JavaScript filenames, cookies, and meta tags to identify frameworks (React, Django, WordPress, Express), web servers (Nginx, Apache, Caddy), and platforms (AWS, Cloudflare, Akamai). Map detected software to CPE (Common Platform Enumeration) identifiers so you can cross-reference with vulnerability databases. Implement signature matching using a JSON-based rules file that is easy to extend with new technology signatures.
|
||||
|
||||
5. **Build the search and query engine** Implement a search query language similar to Shodan's: `port:22 country:US`, `product:nginx version:1.18`, `ssl.cert.issuer:LetsEncrypt`, `os:Linux`. Parse queries into PostgreSQL WHERE clauses using a simple recursive descent parser. Support boolean operators (AND, OR, NOT), quoted exact strings, and range queries for ports and dates. Implement faceted search that returns aggregated counts by port, service, technology, and ASN. Optimize query performance with PostgreSQL indexes, materialized views for common aggregations, and result caching in Redis.
|
||||
|
||||
6. **Create the React web interface** Build a responsive React frontend with: a search bar supporting the full query language with autocomplete suggestions, a results list showing IP address, open ports, detected services, and technology tags for each host, a detail view for individual hosts showing all ports, banners, TLS certificates, and scan history over time, and a dashboard with aggregate statistics (top ports, top services, newest hosts discovered). Implement result export in JSON and CSV formats. Add a map visualization using Leaflet that plots host locations based on GeoIP data.
|
||||
|
||||
7. **Implement continuous scanning and change detection** Build a scheduler that re-scans known hosts on a configurable interval (daily, weekly) and detects changes: new ports opened, ports closed, service version changes, TLS certificate renewals, and new technologies detected. Store the complete scan history for each host so users can see how a service changed over time. Implement alerting via webhook when significant changes are detected (a new port opens, a service version changes to one with known vulnerabilities, a TLS certificate expires). This transforms the tool from a point-in-time scanner into a continuous monitoring platform.
|
||||
|
||||
8. **Add vulnerability correlation and write documentation** Cross-reference detected software versions against the NVD (National Vulnerability Database) CVE feed. For each identified service version, query for known CVEs and display them alongside the scan results with severity ratings. Implement a vulnerability dashboard showing the most critical findings across all scanned hosts. Write thorough documentation covering: legal requirements for network scanning (only scan what you own), responsible use policies, deployment architecture, and how to extend the tool with new protocol fingerprinters. Package everything with Docker Compose.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Network scanning techniques and rate limiting strategies
|
||||
- Protocol-level service fingerprinting across TCP services
|
||||
- TLS certificate parsing and analysis
|
||||
- Technology detection via response analysis and signature matching
|
||||
- Search query language design and query optimization
|
||||
- Continuous monitoring and change detection patterns
|
||||
- CPE identifiers and CVE correlation for vulnerability assessment
|
||||
- Legal and ethical boundaries of network scanning
|
||||
|
||||
## Deliverables
|
||||
- Go scanning backend with concurrent worker pool and rate limiting
|
||||
- Protocol fingerprinters for HTTP, SSH, FTP, SMTP, and database services
|
||||
- Technology detection engine with extensible signature rules
|
||||
- PostgreSQL search engine with custom query language
|
||||
- React web UI with search, host detail, dashboard, and map views
|
||||
- Continuous scanning scheduler with change detection and alerting
|
||||
- Vulnerability correlation against NVD CVE database
|
||||
- Docker Compose deployment with complete documentation
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
# Subdomain Takeover Scanner
|
||||
|
||||
## Overview
|
||||
Build a subdomain takeover detection tool in Go that enumerates subdomains via certificate transparency logs and DNS brute force, then checks each for dangling DNS records pointing to unclaimed cloud resources. Subdomain takeover is one of the most common findings in bug bounty programs because companies frequently decommission services without cleaning up DNS records, leaving CNAME entries pointing to S3 buckets, GitHub Pages, Heroku apps, and other cloud resources that anyone can claim. This project teaches DNS mechanics, cloud service provisioning patterns, and one of the most practical and rewarding areas of bug bounty hunting.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the Go project and subdomain enumeration** Create a Go module with a pipeline architecture: enumerate, resolve, fingerprint, and check. Build two subdomain enumeration methods: certificate transparency log querying (using crt.sh and Censys CT APIs to find all certificates issued for a domain and its subdomains) and DNS brute force (iterating through a wordlist of common subdomain names and querying DNS). Merge results from both methods and deduplicate. Use goroutines with a worker pool for concurrent DNS resolution. Implement the CLI using `cobra` with flags for target domain, wordlist path, concurrency level, and output format.
|
||||
|
||||
2. **Build the DNS resolution and record analysis engine** For each discovered subdomain, perform comprehensive DNS resolution: query for A, AAAA, CNAME, MX, TXT, and NS records. The critical record for takeover detection is the CNAME — if a subdomain has a CNAME pointing to an external service, it is a potential takeover candidate. Build a DNS client using `miekg/dns` for low-level control over DNS queries. Implement DNS caching to avoid redundant lookups. Handle DNS wildcards (detect if the parent domain returns results for any subdomain) to filter out false positives. Store all DNS records in a structured format for analysis.
|
||||
|
||||
3. **Implement cloud service fingerprinting** Build fingerprint modules for the most commonly affected cloud services: AWS S3 (CNAME to `*.s3.amazonaws.com` returning "NoSuchBucket"), GitHub Pages (CNAME to `*.github.io` returning 404 with GitHub's error page), Heroku (CNAME to `*.herokuapp.com` returning "No such app"), Azure (CNAME to `*.azurewebsites.net`, `*.cloudapp.net`, `*.trafficmanager.net`), Netlify (CNAME to `*.netlify.app`), Shopify (CNAME to `shops.myshopify.com`), and Fastly (CNAME to `*.fastly.net`). Each fingerprint module should resolve the CNAME target, make an HTTP request, and check the response for indicators that the resource is unclaimed.
|
||||
|
||||
4. **Build the HTTP-based takeover verification** For each potential takeover candidate identified by DNS analysis, perform HTTP verification: connect to the subdomain, follow redirects, and analyze the response status code, headers, and body content. Match response content against known takeover signatures: specific error pages (S3's XML error, GitHub's 404, Heroku's "no such app"), specific HTTP status codes, and specific response headers. Implement both HTTP and HTTPS checks since some services behave differently. Build a confidence scoring system: high confidence (service returns a definitive unclaimed response), medium (service returns a generic error that might indicate other issues), low (DNS points to the service but HTTP check is inconclusive).
|
||||
|
||||
5. **Add advanced enumeration techniques** Implement additional subdomain discovery methods: zone transfer attempts (AXFR query — rarely works but free to try), DNS record permutation (prepend/append common words to known subdomains: dev-, staging-, -api, -admin), search engine dorking via API (site:*.target.com), and Wayback Machine historical URL mining for subdomains. Build an integration layer that combines results from all enumeration sources with deduplication and source tracking. The more subdomains you enumerate, the higher the chance of finding a takeover.
|
||||
|
||||
6. **Implement notification and proof-of-concept generation** When a likely takeover is detected, generate a proof-of-concept report for each finding: the subdomain, the CNAME target, the cloud service identified, the HTTP response evidence, and step-by-step instructions for claiming the resource (e.g., "Create an S3 bucket named X in region Y"). Implement notification via webhook (Slack, Discord) for real-time alerting during long scans. For verified high-confidence findings, generate a markdown report suitable for bug bounty submission with all required evidence. Include a disclaimer about responsible disclosure and only claiming resources on domains you own.
|
||||
|
||||
7. **Build continuous monitoring mode** Implement a monitoring mode that periodically re-checks known subdomains for new takeover opportunities. Store scan history in SQLite and detect changes: a subdomain that was previously safe now has a dangling CNAME (perhaps the service was decommissioned), or a previously vulnerable subdomain has been fixed. Implement differential reporting that shows only changes since the last scan. Add a watch mode for specific high-value domains that checks more frequently. This is how bug bounty hunters maintain ongoing coverage of their target scope.
|
||||
|
||||
8. **Add output formatting and integration testing** Implement multiple output formats: JSON (for toolchain integration), CSV (for spreadsheets), markdown (for reports), and a formatted terminal table with color-coded severity. Build a comprehensive test suite using mock DNS responses and mock HTTP servers that simulate each cloud service's takeover-vulnerable response. Test edge cases: wildcard DNS domains, CNAME chains (CNAME pointing to another CNAME), services that intermittently return error pages, and rate-limited DNS resolvers. Document the tool's usage, legal considerations (only scan domains you have authorization to test), and how to responsibly disclose takeover vulnerabilities.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- DNS record types and CNAME resolution mechanics
|
||||
- Certificate transparency logs and their role in subdomain discovery
|
||||
- Cloud service provisioning and resource claiming patterns
|
||||
- Subdomain takeover vulnerability mechanics across cloud providers
|
||||
- Bug bounty methodology and responsible disclosure practices
|
||||
- DNS brute force techniques and wordlist optimization
|
||||
- Continuous security monitoring and change detection
|
||||
- Proof-of-concept documentation for vulnerability reports
|
||||
|
||||
## Deliverables
|
||||
- Go CLI tool with concurrent subdomain enumeration pipeline
|
||||
- Certificate transparency and DNS brute force enumeration modules
|
||||
- Cloud service fingerprinting for seven major providers
|
||||
- HTTP-based takeover verification with confidence scoring
|
||||
- Continuous monitoring mode with change detection and alerting
|
||||
- Proof-of-concept report generator for bug bounty submissions
|
||||
- Comprehensive test suite with mock DNS and HTTP responses
|
||||
- Documentation covering legal requirements and responsible disclosure
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Supply Chain Attack Simulator
|
||||
|
||||
## Overview
|
||||
Build an educational supply chain attack demonstration in Python that illustrates the dependency confusion attack vector by creating a fake package, a vulnerable application that installs it, and a monitoring system that captures the exfiltration attempt. This project teaches one of the most impactful modern attack vectors — the same technique that earned Alex Birsan $130,000+ in bug bounties from Apple, Microsoft, and PayPal in 2021. You will understand how package managers resolve dependencies, why internal package names are dangerous, and how to defend against these attacks with namespace reservation, hash pinning, and scoped registries. Nothing is published to any real registry.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the local PyPI server and project structure** Install and configure `pypiserver` as a local private package registry running on localhost. Create three separate project directories: the demonstration package, the target FastAPI application, and the monitoring server that captures exfiltration attempts. Configure `uv` to resolve packages from your local registry first (simulating a company's internal registry), then fall back to the real PyPI. This local-only setup ensures nothing is ever published to a real registry while accurately simulating the attack vector.
|
||||
|
||||
2. **Build the demonstration package** Create a Python package with a name that mimics an internal corporate library (e.g., `internal-auth-utils`). In its `setup.py`, add a post-install hook that executes during installation. The hook should collect non-sensitive system metadata: hostname, username, Python version, installed packages, and the current working directory. Instead of sending data to the internet, send it to your local monitoring server via HTTP POST to localhost. Use a high version number (99.0.0) to win version resolution over any legitimate internal package. Publish this package to your local pypiserver.
|
||||
|
||||
3. **Create the target FastAPI application** Build a small FastAPI application with a `pyproject.toml` that lists `internal-auth-utils` as a dependency. Add a `.env` file with fake database credentials and API keys for demonstration purposes. When you run `uv sync`, the demonstration package should install from the local registry because it has a higher version number than any internal version, and its post-install hook should fire automatically. Document exactly what happens at each step of the dependency resolution process to make the mechanics clear.
|
||||
|
||||
4. **Build the monitoring dashboard** Create a simple FastAPI server that listens for the POST requests from the demonstration package. Display received data in a formatted dashboard: which metadata was collected, from which host, at what time, and how. Store all captured data in a SQLite database for later analysis. Add a timeline view that shows the sequence of events from package installation to data collection. This makes the impact of dependency confusion viscerally clear.
|
||||
|
||||
5. **Implement detection and alerting mechanisms** Build three detection approaches: a pre-install hook that checks package hashes against a known-good lockfile and alerts on mismatches, a network monitor using `scapy` that flags unexpected outbound HTTP connections during package installation, and a filesystem monitor using `watchdog` that detects when install scripts access sensitive directories. Each detection method should produce clear alerts explaining what was detected and why it is suspicious.
|
||||
|
||||
6. **Create the defense implementation module** Build working implementations of every major defense: lockfile pinning with hash verification (demonstrate how `uv lock` prevents the attack), namespace reservation on PyPI (show the registration process), scoped registry configuration (route internal package names to the private registry only), package signing verification, and a policy-as-code tool that scans `pyproject.toml` files for packages that match internal naming conventions but resolve to public registries. Each defense should be testable against the attack scenario.
|
||||
|
||||
7. **Build the interactive demonstration runner** Create a CLI tool that orchestrates the entire demonstration end-to-end: starts the local PyPI server, publishes the demonstration package, installs the target application, captures the metadata collection, then runs each detection mechanism and shows what caught the attack. Include a `--narrated` mode that pauses between steps and prints explanations of what is happening and why. This makes the tool usable for live demonstrations and training sessions.
|
||||
|
||||
8. **Write the comprehensive analysis and documentation** Generate an automated report comparing the attack vector against each defense mechanism in a matrix format: which defenses would have prevented the attack at which stage. Include a section on real-world incidents (event-stream, ua-parser-js, colors.js) with analysis of how they relate to the demonstrated techniques. Add a section on responsible disclosure practices and the ethical boundaries of supply chain security research.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Package manager dependency resolution algorithms and version precedence
|
||||
- Dependency confusion and typosquatting attack vectors
|
||||
- Post-install hook execution and its security implications
|
||||
- Lockfile pinning, hash verification, and reproducible builds
|
||||
- Network and filesystem monitoring for anomaly detection
|
||||
- Supply chain security frameworks (SLSA, SSDF)
|
||||
- Responsible disclosure and ethical boundaries of security research
|
||||
- Real-world supply chain incidents and their root causes
|
||||
|
||||
## Deliverables
|
||||
- Local PyPI server configuration with demonstration package
|
||||
- Target FastAPI application demonstrating dependency confusion
|
||||
- Monitoring dashboard with timeline visualization
|
||||
- Three detection mechanisms (hash checking, network monitoring, filesystem monitoring)
|
||||
- Five defense implementations with testable configurations
|
||||
- Interactive CLI demonstration runner with narrated mode
|
||||
- Analysis report comparing attack surface against defense matrix
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
# Threat Intelligence Aggregator
|
||||
|
||||
## Overview
|
||||
Build a threat intelligence platform that aggregates Indicators of Compromise (IOCs) from multiple threat feeds including AbuseIPDB, VirusTotal, and AlienVault OTX, enriches data with geolocation and WHOIS information, and provides a searchable database for threat investigation. This project teaches threat intelligence fundamentals, API integration, data enrichment, and demonstrates tools used by security analysts for threat research.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand Indicators of Compromise (IOCs) and threat feeds** by learning that IOCs include IP addresses, domain names, file hashes, URLs, and email addresses known to be malicious based on security research and incident investigations. Research existing threat intelligence sources: AbuseIPDB aggregates reports of malicious IPs, VirusTotal analyzes suspicious files and URLs, AlienVault OTX provides open-source threat intelligence, and commercial feeds offer curated data. Set up API accounts and obtain API keys for accessing these services.
|
||||
|
||||
2. **Implement threat feed API clients** that query each threat intelligence source for information about specific IOCs—create functions that check an IP against AbuseIPDB's reputation database, query VirusTotal for file/URL analysis results, and search AlienVault OTX for IOCs. Handle API rate limiting by implementing request queuing and backoff strategies, cache results to minimize API calls, and gracefully handle service outages or errors.
|
||||
|
||||
3. **Build a deduplication engine** that ingests IOCs from multiple sources and identifies duplicates to avoid storing redundant data and prevent confusion. Create a database schema that tracks which IOC came from which source, allowing analysts to understand confidence (IOCs reported by multiple independent sources are more trustworthy) and historical tracking (when was this IOC first detected, is it still active).
|
||||
|
||||
4. **Implement data enrichment** by augmenting IOCs with additional context: perform geolocation lookups determining which country an IP is located in, query WHOIS databases for domain/IP registration information and owner details, cross-reference with DNS data showing domain history, and analyze certificate information for HTTPS endpoints. Store enrichment data linked to original IOCs enabling rich threat analysis.
|
||||
|
||||
5. **Create a threat scoring algorithm** that combines data from multiple sources into a composite risk/threat score, incorporating factors like number of source reports, severity of incidents associated with IOC, recency of reports, and geolocation context. Implement confidence levels distinguishing between high-confidence IOCs reported by many independent sources versus low-confidence reports from single sources that may be false positives.
|
||||
|
||||
6. **Build a searchable database** allowing analysts to query IOCs by various criteria: search for specific IP addresses, domain names, or file hashes; filter by threat type, country, date range, or threat actor; view historical data showing when IOC was first detected and current status. Implement full-text search across stored descriptions and threat intelligence summaries.
|
||||
|
||||
7. **Create visualization and reporting tools** displaying IOC distributions by type/country, threat timelines showing when new IOCs were discovered, and geographic heatmaps showing threat concentration. Build export capabilities allowing analysts to download IOC lists for import into other security tools (firewalls, IDS/IPS, endpoint protection), and generate threat reports highlighting emerging threats and threat actor activity.
|
||||
|
||||
8. **Build comprehensive documentation** explaining threat intelligence concepts, providing API integration examples for common threat feeds, and discussing how threat intelligence fits into security operations. Compare your platform to commercial alternatives (PassiveTotal, Shodan, Recorded Future), discuss confidence scoring methodologies and handling false positives, and provide examples of using threat intelligence for incident response and threat hunting. Include legal considerations around using threat data and privacy implications of storing IOCs.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Threat intelligence sources and feeds
|
||||
- API integration and rate limiting
|
||||
- Data deduplication and normalization
|
||||
- Geolocation and WHOIS lookup
|
||||
- Confidence scoring and risk assessment
|
||||
- Database design for threat data
|
||||
- Visualization and reporting
|
||||
|
||||
## Deliverables
|
||||
- API clients for AbuseIPDB, VirusTotal, AlienVault OTX
|
||||
- Deduplication and normalization engine
|
||||
- Data enrichment with geolocation and WHOIS
|
||||
- Threat scoring and confidence algorithms
|
||||
- Searchable IOC database
|
||||
- Multi-source reporting and analysis
|
||||
- Geographic visualization and heatmaps
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Token Abuse Playground
|
||||
|
||||
## Overview
|
||||
Build an intentionally vulnerable fullstack application using FastAPI and React that contains 15+ distinct token-based authentication and session management vulnerabilities, each with a guided exploit walkthrough and corresponding fix. This project teaches the mechanics of token-based authentication failures that appear consistently in OWASP Top 10 findings and real-world bug bounty reports. You will implement JWTs, session cookies, API keys, and OAuth flows, then systematically break each one to understand why specific implementation choices lead to exploitable vulnerabilities.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
1. **Set up the fullstack project with a vulnerable authentication system** Initialize a FastAPI backend with a React frontend. The backend should implement three authentication mechanisms simultaneously: JWT bearer tokens, session cookies, and API keys. Use PostgreSQL for user storage and Redis for session management. Deliberately configure each mechanism with specific weaknesses: accept the JWT `none` algorithm, use a symmetric secret that is also used elsewhere, set overly long session expiry, and store API keys in plain text. Build a basic user registration and login flow so you have working authentication to attack.
|
||||
|
||||
2. **Implement JWT-specific vulnerabilities** Create five JWT attack scenarios: the `none` algorithm bypass (accept tokens with `alg: none` and no signature), RS256-to-HS256 key confusion (verify RS256 tokens using the public key as an HMAC secret), weak signing secrets vulnerable to brute force (use a dictionary word), missing expiration validation (accept tokens without `exp` claim), and JWT injection via `kid` header parameter manipulation (SQL injection through the key ID lookup). Each vulnerability should be isolated to its own API endpoint group so students can focus on one at a time.
|
||||
|
||||
3. **Build session and cookie vulnerabilities** Implement five session-based attack scenarios: session fixation (accept session IDs provided by the client before authentication), weak session ID generation (use sequential integers or predictable timestamps), missing cookie security flags (no HttpOnly, no Secure, no SameSite), session token in URL parameters (leaking via Referer header), and session persistence after password change (old sessions remain valid). Create a session inspector page in the React frontend that visualizes the current session state and cookie attributes.
|
||||
|
||||
4. **Add API key and OAuth vulnerabilities** Build five more vulnerability scenarios: API key leakage in client-side JavaScript (embed keys in React bundle), CSRF on the token refresh endpoint (no CSRF protection on POST /refresh), OAuth open redirect manipulation (insufficient redirect_uri validation), token scope escalation (modify the scope claim in a token and the server accepts it), and bearer token leakage via verbose error messages (include the token in 500 error responses). For the OAuth flow, implement a minimal OAuth2 authorization server within the project.
|
||||
|
||||
5. **Create the guided exploit walkthrough system** Build a challenge-and-response system in the React frontend. Each vulnerability gets a dedicated page with: a description of the vulnerability class, the specific endpoint(s) to attack, hints that can be revealed progressively, an input field to submit the exploit (e.g., a forged token), and server-side validation that confirms successful exploitation. Use a progress tracker stored in localStorage so students can see which vulnerabilities they have completed.
|
||||
|
||||
6. **Build the fix verification system** For each vulnerability, implement a "patched" version of the same endpoint behind a feature flag. Create a comparison view in the React UI that shows the vulnerable code alongside the fixed code with explanations of what changed and why. Build automated tests that verify each fix actually prevents the exploit: the test should succeed against the vulnerable endpoint and fail against the patched one. This teaches both offense and defense simultaneously.
|
||||
|
||||
7. **Implement the monitoring and detection dashboard** Build a real-time dashboard in React that shows authentication events as they happen: login attempts, token validations, session creations, and detected attack patterns. Use WebSocket connections from FastAPI to push events. Implement basic detection rules that flag suspicious activity: multiple failed JWT signature validations, session fixation attempts, and unusual token refresh patterns. This teaches students what these attacks look like from the defender's perspective.
|
||||
|
||||
8. **Add a scoring system and wrap up with documentation** Implement a scoring system that awards points based on vulnerability severity (CVSS-aligned) and tracks time to exploit. Create a leaderboard page. Write comprehensive setup documentation including a Docker Compose configuration that launches the entire stack with one command. Include a reference guide mapping each vulnerability to its CWE number, OWASP category, and real-world CVEs where this exact bug was found in production software.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- JWT structure, signing algorithms, and common implementation mistakes
|
||||
- Session management lifecycle and cookie security attributes
|
||||
- OAuth 2.0 authorization flows and redirect validation
|
||||
- CSRF attack mechanics on authentication endpoints
|
||||
- The difference between authentication, authorization, and session management
|
||||
- How token-based attacks appear in monitoring and detection systems
|
||||
- OWASP Top 10 authentication failure patterns
|
||||
- Defense-in-depth for token-based authentication
|
||||
|
||||
## Deliverables
|
||||
- FastAPI backend with 15+ intentional token vulnerabilities
|
||||
- React frontend with guided exploit walkthrough and hints
|
||||
- Fix verification system with side-by-side vulnerable and patched code
|
||||
- Real-time attack monitoring dashboard via WebSocket
|
||||
- Docker Compose configuration for one-command deployment
|
||||
- Automated test suite verifying both exploits and fixes
|
||||
- Reference guide mapping vulnerabilities to CWE and OWASP categories
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
# Web Application Firewall (WAF)
|
||||
|
||||
## Overview
|
||||
Build a reverse proxy WAF that filters HTTP requests for malicious patterns including SQL injection and XSS attacks, maintains configurable whitelist/blacklist rules, and logs all security events. This project teaches HTTP protocol analysis, web attack signatures, and demonstrates techniques used in commercial WAF solutions protecting web applications.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand Web Application Firewall concepts and deployment models** by learning WAF operates at application layer (layer 7) analyzing HTTP requests/responses for attacks rather than network-layer firewalls. Study common WAF deployment modes: inline (reverse proxy between clients and backend servers), out-of-band (mirrored traffic for analysis), or cloud-based (SaaS model). Research attack signatures: SQL injection payloads, XSS vectors, path traversal attempts, file inclusion attacks, command injection, and HTTP protocol violations. Understand false positive challenges: legitimate requests may match attack patterns.
|
||||
|
||||
2. **Implement reverse proxy functionality** using `twisted` or similar frameworks to act as proxy intercepting HTTP traffic: accept incoming requests on specified port, forward to backend application server(s), and return responses to clients. Implement connection pooling, request/response buffering, timeout handling, and backend server health checking ensuring proxy remains transparent to legitimate traffic. Support HTTPS inspection (terminate SSL at proxy, decrypt requests, inspect, then re-encrypt to backend).
|
||||
|
||||
3. **Build request inspection and pattern matching** analyzing HTTP requests for indicators of attacks: extract HTTP method, URL path and parameters, headers, request body content, and file uploads. Implement pattern matching engine: exact string matching for known attack signatures, regular expression matching for more complex patterns, and entity decoding (URL decoding, HTML entity decoding, Base64 decoding) ensuring encoded attacks are still detected.
|
||||
|
||||
4. **Create SQL injection detection** implementing signatures that match common SQLi attack patterns: SQL keywords in parameters (SELECT, INSERT, UPDATE, DELETE, DROP, UNION, OR), comment syntax (-- ; /* */), and time-based SQLi indicators (SLEEP, BENCHMARK functions). Build database-agnostic detection covering MySQL, PostgreSQL, MSSQL, and Oracle syntax. Implement learned pattern detection: monitor queries to backend database (if accessible), learn normal query patterns, and flag anomalies.
|
||||
|
||||
5. **Implement XSS detection** identifying script injection attempts: detect HTML/JavaScript tags in parameters (script, iframe, event handlers), encoded variations (entity encoding, unicode, hex encoding), and context-aware XSS (stored in database or cookies). Implement output encoding ensuring that even if XSS payload passes through, it's encoded before browser interprets it.
|
||||
|
||||
6. **Build configurable rules and policies** allowing security teams to define custom rules: create rule definition format (JSON or custom syntax) specifying patterns, actions (block, alert, challenge), exception handling, and metadata. Implement rule management interface enabling creation/modification/deployment without code changes. Support multiple rule sets: base rules (always active), strict rules (aggressive protection, more false positives), custom rules (organization-specific).
|
||||
|
||||
7. **Create whitelist/blacklist and exception handling** allowing legitimate traffic bypassing filters: whitelist specific IPs/users exempt from certain checks, bypass rules for known-good patterns, create geofencing (allow only requests from expected geographic locations). Implement gradual response: first alert, then rate-limit, then block on repeated violations. Build exception workflows where users can request rule exceptions with justification.
|
||||
|
||||
8. **Build logging, monitoring, and response capabilities** recording all security events: log every blocked request with full details (timestamp, source IP, attack type detected, matched signature), maintain statistics on attack trends, and provide alerting for significant events. Create dashboards showing blocked attacks, top attack patterns, and attacker IPs. Implement incident response triggers: automated IP blocking after N violations, notifications to security team, and integration with external incident management systems. Compare to commercial WAFs (ModSecurity, Cloudflare, AWS WAF) discussing capabilities and limitations (WAF complements but doesn't replace application security, false positives require tuning, sophisticated attacks may bypass WAF).
|
||||
|
||||
## Key Concepts to Learn
|
||||
- HTTP protocol and request structure
|
||||
- SQL injection and XSS attack patterns
|
||||
- Reverse proxy architecture
|
||||
- Request inspection and pattern matching
|
||||
- Entity decoding and encoding
|
||||
- Rule-based security filtering
|
||||
- Exception handling and whitelisting
|
||||
- Logging and incident response
|
||||
|
||||
## Deliverables
|
||||
- Reverse proxy implementation
|
||||
- HTTP request/response interception
|
||||
- SQL injection detection and blocking
|
||||
- XSS detection and prevention
|
||||
- Path traversal and file inclusion detection
|
||||
- HTTP protocol violation detection
|
||||
- Configurable rule engine
|
||||
- Whitelist/blacklist functionality
|
||||
- Attack logging and statistics
|
||||
- Security event alerting
|
||||
- Admin dashboard and reporting
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
# Web Application Vulnerability Scanner
|
||||
|
||||
## Overview
|
||||
Build an asynchronous web vulnerability scanner that crawls websites and tests for common flaws including XSS (Cross-Site Scripting), SQLi (SQL Injection), and CSRF (Cross-Site Request Forgery) using a modular plugin architecture. This project teaches web security testing, application penetration testing, and demonstrates automated vulnerability detection techniques.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
|
||||
1. **Understand common web vulnerabilities** by studying OWASP Top 10: XSS allows injecting malicious scripts executing in victim browsers, SQLi exploits unsanitized SQL queries to access/manipulate databases, CSRF tricks users into performing unintended actions on authenticated sites. Learn testing methodologies for each: XSS testing requires injecting payloads and checking for reflection without encoding, SQLi testing involves database error detection and time-based blind SQLi, CSRF requires identifying state-changing requests lacking token validation. Research existing web scanners (Burp Suite, OWASP ZAP) to understand industry approaches.
|
||||
|
||||
2. **Implement asynchronous web crawling** using `httpx` and `asyncio` to efficiently discover all accessible URLs on target website. Build a crawler that respects robots.txt, avoids infinitely deep crawling, deduplicates URLs, and stores discovered paths in a database. Extract links from HTML pages, follow redirects appropriately, and build a site map representing all discovered endpoints available for testing.
|
||||
|
||||
3. **Design a plugin architecture** for vulnerability tests where each test is implemented as a separate module with standardized interface: plugins receive a URL/request and return findings. Create base plugin classes providing common functionality (sending requests, parsing responses, detecting vulnerabilities), then implement concrete plugins for specific vulnerability types. This modularity allows easy addition of new tests without modifying core scanner logic.
|
||||
|
||||
4. **Build XSS detection module** that injects test payloads (simple tags like `<script>alert(1)</script>`, event handlers, etc.) into GET/POST parameters and headers, then analyzes responses for reflection without encoding. Implement both reflected XSS detection (payload echoed in response) and check for stored XSS by analyzing form submissions. Use browser automation tools if needed for JavaScript-based XSS, but start with static analysis.
|
||||
|
||||
5. **Implement SQLi detection module** that injects SQL syntax characters and common payloads (single quotes, UNION queries, time delays) into parameters, analyzing responses for SQL errors or suspicious behavior. Implement multiple SQLi detection techniques: error-based (look for SQL error messages), blind time-based (inject delays and measure response time), and UNION-based (inject UNION statements and detect data extraction). Build payloads that work across different database systems (MySQL, PostgreSQL, MSSQL, Oracle).
|
||||
|
||||
6. **Create CSRF detection module** that identifies state-changing requests (POST, PUT, DELETE operations) lacking proper CSRF tokens. Check whether requests include CSRF tokens in hidden form fields or request headers, verify tokens are validated server-side (test by resubmitting with modified/missing tokens), and flag endpoints without protection. Analyze token generation patterns looking for predictable or missing randomization.
|
||||
|
||||
7. **Build result aggregation, severity scoring, and reporting** that collects findings from all plugins, deduplicates results, assigns severity levels based on vulnerability type and exploitability, and generates comprehensive reports. Create HTML/PDF reports showing vulnerabilities, affected endpoints, proof-of-concept demonstrations, and remediation recommendations. Include detailed evidence for each finding allowing developers to understand and fix issues.
|
||||
|
||||
8. **Build comprehensive documentation** explaining web security testing concepts, providing scanner usage examples, and discussing automated testing limitations (some vulnerabilities require human analysis, false positives are possible). Compare your scanner to commercial tools and discuss advantages of building custom scanners for specific applications. Include ethical guidelines emphasizing that vulnerability scanning requires authorization, provide responsible disclosure guidance for found vulnerabilities, and explain how automated scanning fits into broader application security programs.
|
||||
|
||||
## Key Concepts to Learn
|
||||
- Web vulnerability types (XSS, SQLi, CSRF)
|
||||
- Asynchronous HTTP requests and crawling
|
||||
- Plugin architecture and modularity
|
||||
- Payload generation and injection techniques
|
||||
- Response analysis and vulnerability detection
|
||||
- Severity scoring and reporting
|
||||
- Ethical web security testing
|
||||
|
||||
## Deliverables
|
||||
- Asynchronous web crawler with deduplication
|
||||
- Modular plugin-based testing architecture
|
||||
- XSS detection (reflected and stored)
|
||||
- SQLi detection (error-based, blind, UNION)
|
||||
- CSRF detection and validation checking
|
||||
- Result aggregation and severity scoring
|
||||
- HTML/PDF reporting with remediation advice
|
||||
Loading…
Reference in New Issue