Cyber Research Wiki

Learning path: from HTTP and Burp to CVE reproduction, source review, and responsible disclosure.

Cybersecurity Learning Path

Do not try to learn every tool. Build one repeatable workflow, understand what the tool is doing, and add new tools only when they solve a specific problem.

How to use this path

Primary recommendation: begin with web application security and CVE patch analysis. They provide clear feedback and teach transferable concepts such as trust boundaries, input flow, authorization, validation, root cause, impact, and remediation.
  • Spend most of your time in labs, not watching videos.
  • Use Burp while completing PortSwigger labs rather than treating it as a separate course.
  • Repeat solved labs without the solution so the method becomes familiar.
  • Document why the vulnerability exists, not only the payload that solved the lab.
  • Keep offensive testing inside explicit scope and isolated lab environments.

Initial setup

Install now

  • Burp Suite Community Edition
  • Git
  • Python
  • Visual Studio Code
  • Chrome or Firefox with developer tools
  • A note system using Markdown

Lab environment

  • VMware Workstation, Hyper-V, or VirtualBox
  • A disposable Windows VM
  • A Linux VM such as Ubuntu or Kali
  • Snapshots before running unknown code
  • No personal passwords, tokens, browser profiles, or shared folders
  • NAT or host-only networking unless the lab requires otherwise
PoC safety: do not execute unknown GitHub code on your normal workstation. A repository labeled “PoC” can contain credential theft, loaders, miners, destructive commands, or unrelated malware.

12-week foundation plan

This is a sequence, not a deadline. Take longer where needed.

0 of 12 weeks marked complete
0%
DoneWeekFocus and objectiveYour notes
Week 1 HTTP and browser fundamentals
Methods, status codes, headers, cookies, sessions, JSON, DevTools Network tab, and basic curl.
Week 2 Burp fundamentals
Proxy history, scope, Repeater, Decoder, Comparer, and several simple Academy labs.
Week 3 Authentication
Login flows, password reset, MFA logic, session management, and account-recovery assumptions.
Week 4 Authorization and IDOR
Use multiple lab accounts and verify object-level and function-level authorization.
Week 5 Path traversal and file handling
Filesystem paths, upload validation, archive extraction, content types, and extension handling.
Week 6 Injection basics
SQL injection, command injection, template injection concepts, and safe lab verification.
Week 7 XSS and browser security
Contexts, encoding, CSP concepts, same-origin policy, CORS, and client-side data flow.
Week 8 SSRF and API testing
Server-side URL fetching, cloud metadata concepts, REST authorization, GraphQL, and API inventory.
Week 9 Business logic and race conditions
State transitions, limits, workflows, concurrency, and assumptions beyond payloads.
Week 10 CVE reproduction and patch diffing
Choose a small open-source CVE, compare versions, reproduce harmlessly, and explain the fix.
Week 11 Source review and variants
Trace inputs to sinks, search similar call sites, and write a simple Semgrep or CodeQL query.
Week 12 Reporting and disclosure
Write a professional report with impact, evidence, reproduction, remediation, scope, and timeline.

Specialization tracks

Finish the foundations, then choose one primary track and one supporting track. Web security plus CVE research is a strong first combination.

Web application security

  1. Learn HTTP and browser behavior.
  2. Become comfortable with Burp Proxy and Repeater.
  3. Finish apprentice-level authentication and access-control labs.
  4. Progress through injection, file handling, XSS, SSRF, and APIs.
  5. Study business logic, request smuggling, cache behavior, OAuth, and race conditions.
  6. Move into authorized bug-bounty or open-source application testing.

CVE and open-source vulnerability research

  1. Learn how to read NVD, CVE.org, GitHub advisories, vendor notices, and CISA KEV.
  2. Choose small Python, JavaScript, C#, Go, or Java projects.
  3. Compare the vulnerable and fixed releases.
  4. Reproduce the issue harmlessly in a disposable lab.
  5. Search the codebase for variants of the same missing check.
  6. Write a regression test, detection, or private report.

Network and Windows security

  1. Master TCP/IP, DNS, routing, TLS, and common enterprise protocols.
  2. Use Nmap to identify services and Wireshark to explain the actual traffic.
  3. Study Windows processes, services, tokens, authentication, and Sysinternals.
  4. Build an isolated Active Directory lab.
  5. Learn common identity attack paths through BloodHound and ATT&CK.
  6. Validate defensive logging and detections with Atomic Red Team.

Reverse engineering and exploit development

  1. Learn C, memory layout, x86-64 assembly, and operating-system fundamentals.
  2. Use small crackmes to learn static and dynamic analysis.
  3. Practice GDB/pwndbg on Linux and x64dbg/WinDbg on Windows.
  4. Study mitigations such as ASLR, DEP/NX, stack canaries, and CFG.
  5. Complete pwn.college or OpenSecurityTraining2 material.
  6. Only then move toward real patch diffing, fuzzing, and exploit reliability.

Detection engineering and threat research

  1. Learn Windows Event Logs, Sysmon, PowerShell logging, network telemetry, and EDR concepts.
  2. Map observed behavior to MITRE ATT&CK.
  3. Study Sigma and open detection repositories.
  4. Use public incident reports to identify required data sources.
  5. Validate expected telemetry with Atomic Red Team in a lab.
  6. Tune detections around context rather than matching isolated strings.

Cloud and identity security

  1. Learn IAM, OAuth/OIDC, SAML, tokens, roles, tenants, and service principals.
  2. Study one platform at a time: Entra/Microsoft 365, AWS, or Google Cloud.
  3. Build a small lab tenant or free-tier environment where permitted.
  4. Review platform-native logs and security recommendations.
  5. Practice secure configuration and detection before offensive validation.
  6. Progress to scoped cloud labs and public security research.

Repeatable vulnerability-research workflow

1. Select a manageable target

Prefer an active open-source project with a security policy, local deployment instructions, tests, and readable code.

2. Understand normal behavior

Install it locally and use its major workflows before testing security assumptions.

3. Map trust boundaries

Identify inputs, identities, roles, tenants, files, URLs, parsers, processes, databases, and other sensitive operations.

4. Choose one vulnerability class

For example: IDOR, path traversal, unsafe file extension, SSRF, missing authentication, command injection, or archive extraction.

5. Trace data flow

Follow attacker-controlled data from the entry point to the sensitive operation and list every validation step.

6. Prove impact minimally

Use the least destructive demonstration possible: access a test object, create a marker file, or trigger a controlled local callback.

7. Search for variants

Find other call sites, endpoints, file types, platforms, or code paths that use the same faulty assumption.

8. Report privately

Follow SECURITY.md or the vendor disclosure policy, provide clear evidence, and allow time for coordinated remediation.

Research notes template

CVE / project:
Repository and version:
Vulnerable version:
Fixed version:
Environment:

Entry point:
Attacker-controlled input:
Vulnerable function or component:
Sensitive operation:
Missing or incorrect security check:

Required conditions:
Observed result:
Security impact:
Harmless reproduction steps:

Patch or recommended fix:
Regression test:
Possible variants:
Detection opportunities:
References:

Community and source verification

Using forums well

  1. Search existing threads before asking.
  2. Explain the environment, expected result, observed result, and what you already tested.
  3. Sanitize domains, usernames, tokens, IP addresses, client names, and screenshots.
  4. Treat replies as leads to verify, not unquestionable authority.
  5. Return with the final fix so the thread becomes useful to others.

Verifying onion addresses

  1. Start from the operator's normal HTTPS website or signed announcement.
  2. Copy the entire 56-character v3 hostname rather than matching only the beginning.
  3. Avoid Tor2web gateways and anonymous link directories.
  4. Re-check the official source before entering credentials or submitting sensitive material.
  5. Keep Tor Browser updated and do not install random extensions.

Progress milestones

LevelYou should be able to do thisEvidence
FoundationExplain HTTP requests, cookies, sessions, DNS, TCP ports, and basic Linux/Windows process behavior.Personal notes plus simple packet and HTTP examples.
Web testerCapture a request, reproduce it in Repeater, alter inputs, compare responses, and explain the failed server-side assumption.Twenty or more completed Academy labs with write-ups.
CVE analystLocate the official advisory, affected versions, fix commit, PoC status, KEV status, EPSS, and root cause.Five complete CVE analysis reports.
Research beginnerReproduce a patched open-source vulnerability locally and search for a simple variant.A harmless reproduction and code-level root-cause explanation.
Independent researcherForm and test original hypotheses, prove impact, minimize risk, and submit a professional private report.A valid disclosure, accepted patch, or high-quality public lab write-up.