Pentest Portfolio: 7 Ethical Hacking Projects to Showcase
Updated on November 03, 2025 7 minutes read
Breaking into cybersecurity in 2026 still comes down to proof. Employers want to see how you scope, test, and communicate risk—not just that you can run tools. A strong pentest portfolio turns curious recruiters into eager interviewers because it shows real reasoning, real evidence, and real impact.
In this guide, you’ll build seven practical projects that map to core skills, from Active Directory attack paths to cloud IAM misconfigurations. Each project includes what to do, what to show, and how to package results so your GitHub and resume tell a clear, job-ready story.
Why a Pentest Portfolio Still Wins in 2026
Hiring teams skim dozens of profiles per day. They stop when they see method, impact, and clarity. That means a clearly defined scope, a chained exploit or two, and a clean executive summary that a non-technical stakeholder can understand in minutes.
Keep your portfolio tight and readable. Use short paragraphs, sharply labeled screenshots, and 30–60 second demo clips. Show the before/after of each fix, and close with a simple remediation plan that proves you think like a consultant.
Project 1: Active Directory Attack–Defense Home Lab
Stand up a miniature enterprise with a Domain Controller, two Windows clients, and a Linux attack box. Intentionally introduce weak ACLs or unconstrained delegation, then walk an attacker’s path from foothold to domain privilege escalation—and document what the blue team would see.
Focus on the why behind each move. Capture Sysmon logs, Event Viewer traces, and a lightweight detection note explaining which telemetry confirmed the compromise. End with a one-page remediation plan that hardens identities, services, and delegation paths.
What to show: an attack path diagram, key command snippets, and a red/blue timeline. Outcome to highlight: how misconfigurations amplified risk and how your fixes reduced it. For mentorship while you build, see the Cybersecurity Bootcamp curriculum and support.
Project 2: Web App Pentest on a Realistic Target
Treat a purposely vulnerable app like a client engagement. Write a small rules-of-engagement document, then test for broken access control, injection, and authentication weaknesses. Chain a low-privilege auth bypass into an IDOR to reach sensitive data, and show the business impact plainly.
Explain each finding in two parts. First, a crisp technical summary with the request/response diffs and sanitized payloads. Second, a business translation that states who could be harmed, what could be lost, and how the fix changes the risk landscape.
What to show: short PoC GIFs, a final table of prioritized fixes, and secure-by-default settings. Bonus: Compare your remediation advice to practices you’ll learn in our Web Development Bootcamp so you can collaborate better with engineers.
Project 3: Wireless Security Assessment in a Controlled Lab
Build a safe wireless testbed with your own access point and client devices. Review WPA2/WPA3 configurations, attempt a controlled evil twin attack, and verify whether EAP settings or weak passwords create easy wins for attackers.
Your report should treat operational reality with care. Emphasize legal scope, consent, and safety controls. Provide a short “owner’s guide” that a small office could follow—strong passphrases, proper management of SSIDs, firmware updates, and guest networks separated from critical systems.
What to show: packet captures, annotated screenshots from your tools, and a clear checklist of mitigations. Goal: demonstrate you can find the issue, explain it simply, and help non-experts fix it without fear.
Project 4: Cloud IAM Misconfiguration and Storage Exposure
Spin up a minimal AWS or Azure account and intentionally misconfigure one storage bucket and a handful of IAM policies. Enumerate identities, find escalation paths, and demonstrate how least privilege prevents unintended access to sensitive objects.
Show the full arc from discovery to defense. Include the policy before/after, the minimal set of permissions required for the workload, and a small script that re-audits drift on a schedule. Keep the data fake but realistic, and avoid over-provisioning for convenience.
What to show: architecture and blast-radius diagrams, CLI traces, and a checklist for new projects. Outcome to highlight: You understand the shared-responsibility model and can coach teams toward safer defaults.
Project 5: Mobile App Traffic and API Security Review
Use a demo app you control to examine the mobile-to-API flow. Intercept traffic, assess token handling, and test rate limits and ID predictability. Validate certificate pinning and check whether sensitive data can be accessed by flipping object IDs.
Tell the story from a user’s perspective. What can an attacker do without credentials? What changes after login? Where do tokens live, and how long do they last? Tie each finding to a concrete developer action, such as stronger server-side checks or hardened storage.
What to show: request maps, token lifecycle diagrams, and rate-limit test results. Deliverable: an API risk register with severity, exploitability, and fix ETA so teams can make informed trade-offs.
Project 6: Containerized Stack Supply Chain and Runtime Hardening
Compose a tiny app with a front end, API, and database. Scan images for known CVEs, generate an SBOM, and then lock down runtime using seccomp or AppArmor profiles and read-only filesystems where possible. Attempt a lab-only container breakout and document what stops you.
Bridge Dev and Sec with empathy. Explain how to keep developer velocity high while still enforcing provenance and policy. Capture the exact diffs in your compose or Kubernetes manifests so reviewers can replicate the outcome quickly.
What to show: scan results with context, policy snippets, and a “from dev to prod” hardening checklist. Outcome: prove you can think like a builder and secure like an attacker.
Project 7: Reporting Masterclass From Finding to Board-Ready Story
Select two or three of your strongest findings and craft a polished reporting pack. Lead with an executive summary that states risk in plain language, follow with reproducible technical steps, and finish with a prioritization matrix and retest notes.
Respect the reader’s time. Keep the summary to one page, use consistent severity criteria, and show before-and-after evidence that makes progress obvious. Make your visuals readable on a laptop without zooming or guessing.
What to show: a tight packet of PDFs or markdown pages, a change log, and signed-off remediation steps. Goal: demonstrate communication skills that unlock trust, budget, and action.
How to Package Your Portfolio So It Gets Read
Structure your GitHub the way a consultant organizes an engagement. Use a top-level README that explains your focus and links to each project, then keep each project self-contained with scope, method, evidence, and report folders. Add a brief ethics note and remove any sensitive data.
Keep proof tight and visual. A short video beats a wall of text; a clean diagram beats a thousand words. Use consistent file names, alt text on images, and captions that make your evidence skimmable for busy reviewers.
For guided packaging, portfolio reviews, and mock interviews, check out our Cybersecurity Bootcamp. We’ll help you refine storytelling as much as technique so hiring managers remember your work.
A Practical 4–6 Week Plan
In Week 1, set up your AD lab, define the scope, and start logging early so “blue” evidence is rich. In Week 2, complete your AD attack path, draft remediation, and begin your web app test to keep momentum across domains.
In Week 3, polish the web report and tackle either wireless or mobile, depending on interest and job targets. In Week 4, run your cloud IAM lab and commit drift-audit scripts, then finish Weeks 5–6 with the container hardening project and your reporting masterclass pack.
Each week, publish a short update post and link it from your README. This cadence shows discipline, communicates progress, and gives recruiters a reason to check back.
What Recruiters Look For and How You’ll Prove It
They want method over tools: you explain why steps matter, not just which buttons you clicked. They want end-to-end thinking: you chain issues to business impact and propose fixes that actually reduce risk.
They also want communication: you can brief a developer at 10 a.m. and a director at 4 p.m., without changing the core message. Finally, they look for ethics: you only test what you own or have written permission to assess, and you respect safe, legal boundaries.
Your Next Step: Build With Structure, Get Hired Faster
If you’re serious about launching or switching into cybersecurity in 2026, build with coaching that compresses learning time and maximizes hiring signals. Compare schedules, financing, and career support in our Cybersecurity Bootcamp, or explore all Courses.
Build projects employers recognize. Tell a story they remember. Then turn that story into your first offer with Code Labs Academy by your side.