Step 2 — ...

Validation

How to confirm success (file presence, flag, output match).

Common Pitfalls

• Pitfall 1 + fix.
• Pitfall 2 + fix.

Cleanup

• Revert snapshots.
• Remove credentials.
• Note what to keep for the report.

Deliverable

What the student submits (CSV, screenshot bundle, flag, report).

Grading Rubric

• 100% = ...
• 80% = ...
• Pass-fail criterion.

What's Next

Link to the next module's lab.

---

## Example 1 — AYSEC-101 Module 03: Network Scanning

```markdown
# Lab Manual — AYSEC-101 M03: Scan Metasploitable 2

## Lab Objective
Produce a complete service-and-version inventory of a vulnerable Linux target using Nmap + NSE.

## Prerequisites
- Metasploitable 2 VM running on `aysec-victims` host-only network.
- Kali VM on the same network with internet disabled.
- ~10 GB disk for output.

## Time Required
2 hours total.

## Lab Environment Setup
1. Boot Metasploitable 2; note its DHCP-assigned IP (typically 10.10.10.x).
2. From Kali, ping Metasploitable to confirm reachability.
3. `mkdir -p ~/aysec/01-engagements/metasploitable/recon`
4. `cd ~/aysec/01-engagements/metasploitable/recon`

## Step-by-Step

### Step 1 — Stage-1 Fast Scan

```bash
sudo nmap -sS -p- --min-rate=1000 -T4 -oA stage1 <ip>

Expected: ~25 open TCP ports identified within 2 minutes.

If sudo is needed but Kali doesn't prompt, your user isn't in the sudo group. Add with usermod -aG sudo $USER.

Step 2 — Stage-2 Service + Default Scripts

ports=$(grep ^[0-9] stage1.nmap | cut -d/ -f1 | tr '\n' ',' | sed 's/,$//')
sudo nmap -sV -sC -p $ports -oA stage2 <ip>

Verify in stage2.nmap that:

• Port 21 = vsftpd 2.3.4 (vulnerable backdoor).
• Port 22 = OpenSSH 4.7.
• Port 139/445 = Samba 3.x.
• Port 5900 = VNC.
• ~25 lines of service info.

Step 3 — UDP top-100

sudo nmap -sU --top-ports 100 -oA udp <ip>

UDP scans take 5-15 minutes.

Step 4 — Targeted NSE

For each interesting port, run targeted scripts:

nmap -p 21 --script "ftp-anon,ftp-syst" <ip>
nmap -p 23 --script "telnet-encryption" <ip>
nmap -p 445 --script "smb-os-discovery,smb-enum-shares,smb-enum-users" <ip>
nmap -p 3306 --script "mysql-info,mysql-empty-password" <ip>

Validation

• File stage2.nmap exists and contains "vsftpd 2.3.4".
• File udp.nmap exists.
• Targeted-NSE outputs identify at least 3 vulnerabilities.

Common Pitfalls

• Nmap host-discovery skipping the target. Add -Pn.
• Slow scan. Increase --min-rate to 5000.
• No SMB null session results. Confirm Metasploitable 2's smb.conf allows it (it should by default).

Cleanup

• Power down Metasploitable 2.
• Don't bridge it to a real network (it's vulnerable).

Deliverable

• stage1.nmap, stage2.nmap, udp.nmap.
• Markdown summary listing services + obvious vulnerabilities.

Grading Rubric

• 100%: Identified all 23+ services with versions, mapped 5+ vulnerabilities.
• 80%: Found 18+ services, mapped 3+ vulnerabilities.
• 60%: Stage-1 + Stage-2 scans completed.
• Fail: No scan output.

What's Next

AYSEC-101 M04 — turn this scan into a prioritized vulnerability inventory.

---

## Example 2 — AYSEC-102 Module 03: Splunk SPL

```markdown
# Lab Manual — AYSEC-102 M03: Boss of the SOC v3 — Investigation 1

## Lab Objective
Identify the initial-access vector + lateral-movement target in a simulated 7-day intrusion.

## Prerequisites
- Splunk Free / Enterprise installed.
- BOTSv3 indexed (download from github.com/splunk/botsv3).
- Web access to Splunk at http://localhost:8000.

## Time Required
3 hours.

## Step-by-Step

### Step 1 — Confirm Index

```spl
| metadata type=hosts index=botsv3

You should see ~100 hosts.

Step 2 — Phishing Question Hunt

The story starts with a phishing email. Pivot:

index=botsv3 sourcetype=ms:o365:management:office365:audit
| search Operation="MailItemsAccessed"
| stats count by UserId

Look for the user with the most-accessed mail items.

Step 3 — Pivot to Endpoint

That user's username goes into:

index=botsv3 sourcetype=XmlWinEventLog:Security
| search User="<username>"
EventCode IN (4624,4625,4634,4672)
| sort _time

Trace logon flow. Note any 4624 with LogonType=10 (RDP).

Step 4 — Process Tree

index=botsv3 sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
EventCode=1
host="<host>"
| sort _time

Look for Office → PowerShell → suspicious child.

Validation

Submit answers to BOTSv3 questions 100, 101, 102 (initial-access, lateral, persistence).

Common Pitfalls

• "_time" fields differ across sourcetypes; use eval _time = strptime(...) if needed.
• Some BOTSv3 fields are in CIM-format; install the CIM add-on if dashboards are blank.

Deliverable

• A 3-page write-up: hypothesis, queries, findings, IOCs, ATT&CK mapping.

Grading Rubric

• 100%: Correct answers to 5+ BOTSv3 questions, with documented queries.
• 80%: 3 correct, 1 close.
• Pass: 1 correct + clear methodology.

---

## Example 3 — AYSEC-103 M02: Windows MFT Forensics

```markdown
# Lab Manual — AYSEC-103 M02: Parse Real $MFT

## Lab Objective
Extract a $MFT, parse with MFTECmd, and produce a one-page finding doc.

## Prerequisites
- A forensic image (Digital Corpora M57, or your own).
- Eric Zimmerman's tools.
- Excel / pandas.

## Time Required
2 hours.

## Step-by-Step

### Step 1 — Extract $MFT

If you have a live drive, FTK Imager → Export Files → Volume → root → $MFT.

If you have a raw image:

```bash
# On Linux
sudo mmls disk.img
sudo fls -r -o <offset> disk.img > files.txt
sudo icat -o <offset> disk.img <inode-of-$MFT> > MFT.bin

Step 2 — Parse with MFTECmd

MFTECmd.exe -f MFT.bin --csv ./out --csvf mft.csv

Expect ~30,000 rows for a small disk.

Step 3 — Triage

In Excel / pandas:

• Sort by SI.Created descending.
• Filter to \Users\<user>\AppData\Roaming\ ending in .exe.
• Identify any rows where SI.Modified < FN.Modified (timestomp candidates).
• Grep for known-suspicious filenames.

Step 4 — Write Findings

For each suspicious file:

• Path
• Hashes if recoverable
• Timestamps + timestomp evidence
• Link to attacker hypothesis

Validation

Doc contains 3+ documented findings or a justified "no significant findings."

Deliverable

1-page Markdown findings doc.

---

## Example 4 — AYSEC-104 M05: ISO 27001 Annex A SoA

```markdown
# Lab Manual — AYSEC-104 M05: Build Acme SaaS's SoA

## Lab Objective
Produce a complete Statement of Applicability for Acme SaaS covering all 93 Annex A controls.

## Prerequisites
- ISO/IEC 27001:2022 (purchased copy or via your employer).
- Spreadsheet template (provided in `templates/soa-template.xlsx`).
- Module 04 outputs: ISMS scope + risk assessment.

## Time Required
4–6 hours.

## Step-by-Step

### Step 1 — Open Template

The provided template has 93 rows (one per A.5 / A.6 / A.7 / A.8 control). Columns:
- Control number
- Title
- Applicable (Yes / No)
- Justification (free text)
- Implementation status (Implemented / Partial / Planned / Not Implemented)
- Reference (link to policy / system / evidence)
- Owner
- Last review date

### Step 2 — Decide Applicability

For each control, decide if it applies to Acme SaaS (cloud-native, 60-person, US+EU customers):

- **Always-applicable**: most A.5 + most A.8.
- **Likely NA**: A.7.13 (equipment maintenance — no on-prem hardware), A.7.4 (physical security monitoring — small office, may rely on landlord), A.5.32 (intellectual property rights — depends on what they create).

For NA, give a justification (auditors will probe).

### Step 3 — Implementation Status

For each Applicable control, choose:

- Implemented: ready for audit; evidence exists.
- Partial: in progress; some evidence.
- Planned: agreed to do, not started.
- Not Implemented: gap.

### Step 4 — Reference

Link each Implemented / Partial to:

- Policy doc (e.g., Information Security Policy v3).
- System / setting (e.g., Okta MFA enforced).
- Evidence (audit log, cert, training record).

## Validation
- All 93 controls have a row.
- All NA have a justification.
- All Applicable have an implementation status.
- 70%+ are at least Partial.

## Deliverable
`soa-acme-saas.xlsx` with all 93 rows complete.

## Grading Rubric
- 100%: All rows complete, all NA justified, 70%+ implemented.
- 80%: All rows; some justifications thin.
- Fail: <50 rows complete.

Example 5 — AYSEC-105 M02: Multi-Cloud IAM

# Lab Manual — AYSEC-105 M02: Build a Multi-Cloud IAM Pattern

## Lab Objective
Set up federated SSO + Workload Identity Federation across AWS, Azure, GCP free-tier accounts.

## Prerequisites
- AWS Free Tier, Azure Free, GCP Free Trial accounts.
- A GitHub repo for OIDC source.

## Time Required
4 hours.

## Step-by-Step

### Step 1 — AWS IAM Identity Center

1. Enable IAM Identity Center in `us-east-1`.
2. Create permission set "ReadOnlyDevs" using AWS managed policy `ReadOnlyAccess`.
3. Add yourself; assign permission set to your AWS account.
4. Test SSO login.

### Step 2 — AWS OIDC for GitHub Actions

1. Create OIDC provider for `token.actions.githubusercontent.com` (thumbprint shown in AWS docs).
2. Create role with `sts:AssumeRoleWithWebIdentity` allowed for your GitHub repo:

"Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:*" } }

3. In GitHub Actions, use `aws-actions/configure-aws-credentials` with the role ARN.

### Step 3 — Azure Conditional Access + PIM

1. Configure Conditional Access requiring MFA from outside your country.
2. Enable PIM for Global Admin role.
3. Test elevation: request, then perform.

### Step 4 — GCP Workload Identity Federation

1. Create a Workload Identity Pool.
2. Add a provider (OIDC) for GitHub.
3. Create a service account with `roles/storage.objectViewer`.
4. Grant the GitHub identity binding to that SA.
5. From GitHub Actions, authenticate via WIF.

## Validation
Three GitHub Actions workflows pull from AWS S3, Azure Blob, GCS — each authenticating without long-lived secrets.

## Deliverable
The three workflow YAMLs; redacted screenshots.

## Common Pitfalls
- AWS thumbprint changes — use the official AWS-managed pre-trusted cert chain.
- GCP WIF requires a "subject" mapping; misconfigured = 401.
- Azure CA "block legacy auth" requires app updates first.

Example 6 — AYSEC-106 M04: Username Enumeration via Burp Intruder

# Lab Manual — AYSEC-106 M04: PortSwigger "Username enumeration via different responses"

## Lab Objective
Use Burp Intruder to detect a usernames-leak via response-length differential.

## Prerequisites
- PortSwigger account.
- Burp Suite Community.

## Time Required
30 minutes.

## Step-by-Step

### Step 1 — Open the Lab

`Authentication → Username enumeration via different responses` (Apprentice).

Click "Access the lab."

### Step 2 — Capture login

In Burp:
1. Set Proxy to intercept.
2. Submit any creds in the lab.
3. Capture the POST request.

### Step 3 — Send to Intruder

Right-click → Send to Intruder.

### Step 4 — Configure

- Attack type: Sniper.
- Mark the username value as the only payload position.
- Payloads → Simple list → load the lab's "Candidate usernames" list (provided).

### Step 5 — Run

Start attack.

In the result table, sort by Length. Identify the row whose length differs from the rest. That's the valid username.

### Step 6 — Now Brute Force the Password

Repeat with the discovered username and the lab's password wordlist.

### Step 7 — Login

Use the recovered credentials.

## Validation
Lab marks "Solved" when you log in.

## Common Pitfalls
- Length differential may be subtle (1–2 bytes). Sort carefully.
- If Burp Intruder is rate-limited (Community), wait or use BrowserStorm with delay.

## Deliverable
A screenshot of the "Solved" status + the recovered username/password.

Example 7 — AYSEC-201 M03: Phishing Campaign Setup

# Lab Manual — AYSEC-201 M03: Configure GoPhish

## Lab Objective
Stand up a phishing campaign in your lab — domain, email, landing page, payload tracking.

## Prerequisites
- VPS ($5/mo).
- Domain (cheap, e.g. .xyz).
- GoPhish installed.

## Time Required
3 hours.

## Step-by-Step

### Step 1 — Domain & DNS

- Register domain.
- Set MX → your VPS.
- Add SPF, DKIM, DMARC.

### Step 2 — Mail Server

- Install Postfix.
- Configure DKIM signing.
- Test with mail-tester.com — aim for 9/10.

### Step 3 — Install GoPhish

```bash
wget https://github.com/gophish/gophish/releases/download/v0.12.x/gophish-v0.12.x-linux-64bit.zip
unzip; cd gophish
./gophish

Step 4 — Configure

• Sending profile (your mail server).
• Landing page (your design or pre-built template).
• Email template.
• Targets list (yourself + colleagues, with permission).

Step 5 — Test Send

• Send to yourself first.
• Verify deliverability, link click tracking, credential capture.

Step 6 — Production-style send

Send to your test group. Monitor:

• Click rate.
• Credential entry rate.
• Time-on-page.

Validation

GoPhish dashboard shows tracking; mail-tester score ≥ 9.

Cleanup

Burn the domain after the lab. Don't reuse.

Deliverable

Screenshot of tracking dashboard + redacted target list.

Common Pitfalls

• Mail blocked by Gmail/Outlook — most-common SPF/DKIM/DMARC issues.
• Landing page flagged by browsers — domain too new, not categorized.

---

## Example 8 — AYSEC-202 M03: Crackme

```markdown
# Lab Manual — AYSEC-202 M03: Solve a Beginner Crackme

## Lab Objective
Recover or bypass a password check in a small Linux ELF.

## Prerequisites
- Linux VM with `gdb`, `pwndbg`, `Ghidra`.

## Time Required
1 hour.

## Step-by-Step

### Step 1 — Get the Crackme

Download a "Beginner" Linux crackme from https://crackmes.one.

### Step 2 — Static

```bash
file crackme
strings crackme | grep -i "password\|pass\|key"

If a password string is in the binary, that's your easy-mode answer. Otherwise, move on.

Step 3 — Ghidra

Open in Ghidra → auto-analyze → find main.

Find the password-check function. Look for strcmp or equivalent. Note where the comparison happens.

Step 4 — Dynamic with GDB

gdb ./crackme
(gdb) break *<address-of-strcmp>
(gdb) run
(gdb) info registers     # rdi/rsi point at the strings
(gdb) x/s $rdi

If your password is at one register and the expected is at the other, you've recovered the password.

Step 5 — Verify

./crackme
> <recovered password>
"Correct!"

Validation

The crackme prints the success message.

Deliverable

A 1-paragraph writeup with the password and how you found it.

Common Pitfalls

• ASLR may shift addresses. Use breakpoints by symbol or by relative offset.
• Some crackmes deliberately encrypt the password; static recovery insufficient.

---

## Using This Template at Scale

For all 159 AYSEC modules, generate a lab manual using the template + a domain expert's input. Each manual takes 1–4 hours to write well. Build them gradually as students request.

Crowdsource: invite advanced students to write lab manuals for modules they've completed — review and merge.

Once 50% of modules have lab manuals, AYSEC has the most complete free-to-use cybersecurity lab curriculum publicly available.