Authorized Hands-On Labs — DedSec Project

Scope rule: Every exercise is for systems you own, localhost, isolated VMs/containers, or deliberately vulnerable training applications. Never point the exercises at third-party systems without explicit authorization.

Lab 1 — Local attack-surface inventory

nmap -sT -sV 127.0.0.1

For each listening service, document owner/process, purpose, bind address, authentication, and whether it is required.

Lab 2 — Packet capture of your own traffic

Capture a small amount of traffic generated by your own machine. Identify DNS, TCP handshakes, TLS sessions, and local broadcast/multicast traffic. Do not capture networks where you are not authorized to inspect other users' traffic.

Lab 3 — Web application security

Run OWASP Juice Shop or WebGoat locally. Choose one beginner lesson and focus on the control failure, evidence, and secure design change.

Lab 4 — Authorization unit tests

Create a toy app with User A and User B, each owning one object. Write automated tests proving cross-user reads/writes are denied.

Lab 5 — Secure password storage

Use sample passwords that are not real credentials. Compare a fast general-purpose hash with a password-specific KDF conceptually and measure why deliberate cost slows guessing.

Lab 6 — TLS inspection

Inspect TLS on a service you operate or a public test endpoint intended for inspection. Record certificate SANs, issuer, validity, negotiated protocol, and cipher.

Lab 7 — Detection validation

Generate a benign failed login to a local test account, locate the log event, and write a simple rule/query for repeated failures with reasonable noise control.

Lab 8 — Incident timeline

Create a synthetic sequence: test-account creation, login, file creation, privilege change, and account removal. Build a timeline from local logs.

Lab 9 — Container hardening

Run a local container, then use a non-root user, reduce capabilities, and use a read-only filesystem where possible. Document the minimum permissions needed.

Lab 10 — LLM tool-boundary exercise

Build a toy assistant with a harmless calculator tool. Feed it untrusted text that requests an unexpected tool call, then add an allow-list and explicit approval layer.

Lab report template

Record objective, environment, scope/authorization, steps, evidence, result, security lesson, remediation/control change, and retest result.

Building a safe lab environment

A good lab is intentionally isolated, easy to reset, and clearly distinguishable from production. Prefer localhost, private virtual networks, disposable VMs/containers, and deliberately vulnerable training applications. Use synthetic names, addresses, tokens, and documents rather than copied production data.

Lab safety checklist

• Use private/local addresses and verify the target before running a command.
• Disable bridged networking unless the exercise requires it and you understand the exposure.
• Take snapshots or keep rebuild scripts so damaged systems can be restored.
• Never reuse real passwords, API keys, customer records, or production tokens.
• Keep vulnerable training services inaccessible from the public internet.
• Stop if an exercise reaches a system that is not part of the lab.
• Capture notes and evidence as though writing a professional assessment.

Lab 11 — Asset inventory from local evidence

Create three local services or containers with different ports and owners. Build an inventory containing hostname/container name, IP/bind address, port, protocol, process, owner, purpose, authentication requirement, and data classification. Then stop one service and verify that the inventory and scan results both change.

Learning goal: distinguish discovery from asset ownership. A scanner can tell you that something is reachable; it cannot tell you whether the service is approved or important.

Lab 12 — Vulnerability prioritization tabletop

Create five fictional findings with different conditions: a critical CVSS issue on an isolated test host, a medium authorization issue on a public production API, an outdated library that is not reachable, a weak admin MFA policy, and a missing log source on a critical server. Rank them using technical severity plus business context. Explain why your order differs from sorting by score alone.

Learning goal: practice risk reasoning without exploiting anything.

Lab 13 — Web security headers and TLS

Run a local HTTPS-capable development server or an intentionally configured test service. Inspect its certificate, redirect behavior, cookie flags, and relevant security headers. Change one configuration at a time and document the effect.

Learning goal: connect configuration to observable client behavior.

Lab 14 — Input validation unit tests

Write a tiny local function or web endpoint that accepts a username, age, or filename. Define allowed types, length, character policy, and failure behavior. Add automated tests for empty input, oversized input, unexpected Unicode, wrong type, and path separators. Keep every test local and non-destructive.

Learning goal: understand validation as a positive contract rather than a blacklist of “bad strings.”

Lab 15 — Access-control matrix

Create two users and three resources in a toy application. Define a matrix for read, update, delete, and admin operations. Implement or mock policy checks and write both positive and negative tests.

Learning goal: prove that authorization decisions are based on identity, action, and resource rather than UI state or object IDs.

Lab 16 — API rate and quota design

Use a local API endpoint that performs a harmless expensive action such as generating a large synthetic report. Add a per-user quota and a maximum request size. Confirm that normal use succeeds and excessive synthetic requests are rejected predictably without crashing the service.

Learning goal: resource-consumption protection and graceful failure.

Lab 17 — Secret scanning in a toy repository

Create a local Git repository and add a fake token such as DEMO_TOKEN_DO_NOT_USE_12345. Configure a secret-scanning pattern or pre-commit check that catches the marker. Remove it from the current file and discuss why rotating a real exposed secret would still be required even after deleting it from the latest commit.

Learning goal: prevention, history, and credential lifecycle.

Lab 18 — SBOM and dependency inventory

Create a small application with a few harmless dependencies. Generate a dependency list or SBOM using an ecosystem-appropriate tool, record package versions, and identify which are direct versus transitive. Simulate an advisory by marking one package “needs review” and document how you would find deployments containing it.

Learning goal: software supply-chain traceability.

Lab 19 — Identity lifecycle simulation

Create a fictional employee account and document joiner, role-change, and leaver events. During the “mover” stage, remove one old permission before adding the new one. During “leaver,” disable sign-in, revoke active sessions, remove group membership, and record which logs prove completion.

Learning goal: identity security is a lifecycle, not only login.

Lab 20 — Detection rule validation

Generate a benign sequence such as five failed logins to a local test account followed by one successful login. Build a query or simple script that detects the pattern. Repeat with normal background activity and tune the rule so expected noise does not trigger unnecessarily.

Learning goal: detection requires both positive and negative test cases.

Lab 21 — Incident evidence timeline

Prepare synthetic log lines from an application, identity provider, and host with timestamps in different timezones. Normalize them into one timeline and label each entry as fact, inference, or unanswered question.

Learning goal: evidence quality and temporal reasoning.

Lab 22 — Backup recovery tabletop

Create a disposable directory with sample files, archive it, delete or corrupt one copy, and restore from the backup. Record recovery time, missing data, integrity checks, and the credentials required for restoration.

Learning goal: a backup strategy is only proven by recovery.

Lab 23 — Cloud IAM policy review without a cloud account

Create a fictional JSON-like policy containing an overly broad wildcard permission and a second policy containing only the actions required by a mock backup job. Compare the blast radius conceptually and write a least-privilege review checklist.

Learning goal: reason about permissions without interacting with a real provider.

Lab 24 — Container image minimization

Build two local images for the same static application: one with a broad development base and one with a minimal runtime base. Compare package count, image size, running user, writable paths, and exposed ports. Do not attempt escape techniques.

Learning goal: reduce unnecessary runtime surface.

Lab 25 — Kubernetes admission policy

In a local cluster, create a deliberately non-compliant manifest that requests a privileged container or runs as root. Configure a local policy mechanism to reject it, then correct the manifest and verify successful deployment.

Learning goal: prevent dangerous configuration before runtime.

Lab 26 — Mobile application review with an emulator

Use a deliberately vulnerable or self-written app in an emulator. Review requested permissions, exported components, local storage, network-security configuration, and backend authorization assumptions. Record findings and remediations without attacking third-party apps or accounts.

Learning goal: separate client hardening from server-side trust.

Lab 27 — Phishing-awareness design tabletop

Draft a fictional internal training scenario using a non-routable example domain and no real credential collection. Define the learning objective, employee notification/consent requirements, metrics that do not shame individuals, support process for reports, and follow-up education.

Learning goal: build human-security exercises ethically and safely.

Lab 28 — Logging completeness test

For a toy application, define five security-relevant actions: login, failed login, password change, privilege change, and data export. Trigger each action and verify the log contains actor, action, target, outcome, and timestamp without storing passwords or session tokens.

Learning goal: test logging as an application requirement.

Lab 29 — RAG authorization test

Create a tiny local retrieval system with two sets of synthetic documents tagged tenant=A and tenant=B. Query as Tenant A and verify that retrieval filters prevent Tenant B documents from entering model context. Add negative automated tests.

Learning goal: enforce authorization before model generation.

Lab 30 — Security report and retest

Pick any earlier lab result and write a complete finding: title, scope, condition, sanitized evidence, impact, remediation, and retest criteria. Apply the fix, retest, and mark the finding fixed or partially fixed with evidence.

Learning goal: turn technical observations into actionable security work.

Suggested lab progression

Foundation: 1, 2, 7, 8, 11, 21 Application security: 3, 4, 14, 15, 16, 30 Identity/defense: 7, 8, 19, 20, 21, 28 Cloud-native/DevSecOps: 9, 17, 18, 23, 24, 25 Mobile/AI: 10, 26, 29, 30

Lab evidence template

Lab:
Date/time/timezone:
Environment:
Authorization/scope:
Objective:
Preconditions:
Actions performed:
Expected result:
Observed result:
Evidence location:
Security lesson:
Remediation/control change:
Retest result:
Cleanup completed:

A completed lab should end in a known state. Stop test services, remove synthetic accounts and temporary permissions, delete fake secrets, and preserve only the notes needed for learning.

Guided study workflow

Before you begin

Complete the prerequisites named by each selected lab.

Practice task

Complete labs progressively. For every lab use the template in LAB-GUIDE.md and include before/after evidence plus cleanup.

Continue with

Recommended next modules: 45 and the domain-specific module for each lab.