Lab 02 // CVE on the Command Line

01 // Briefing

From browser to terminal

So far every CVE you've handled has been through a web browser - NVD, MITRE ATT&CK, CISA. Browsers are fine for reading. The terminal is where the actual work happens. Today you start using it.

Your Kali box already has every tool you need. searchsploit is a local, offline-searchable copy of the Exploit-DB database - when you run searchsploit log4j, you get a list of every public exploit indexed against Log4j, with file paths to the actual code. No network round-trip. No login. Just answers.

You're going to run through searchsploit against three sets of CVEs: yesterday's case-study CVEs, the Activity 4 CVEs from the in-person session, and the 3-5 CVEs from your actor profile in Lab 01. Then you'll cross-reference everything against the CISA KEV catalogue from the terminal - no browser.

// Objectives

Build muscle memory with searchsploit - searching, reading, mirroring exploits.

Practice the Linux file-system workflow you'll use every day: cd, ls, mkdir, less.

Read three real exploits in three different languages. Understand what each one does at a high level.

Pull and parse the CISA KEV catalogue from the terminal. Cross-reference your actor's CVEs against it.

Produce a markdown report capturing your findings - written from the terminal, not pasted from a browser.

Reading exploit code is legal. Running it against systems you don't own and don't have written permission to test is illegal under the South African Cybercrimes Act 19 of 2020. Every command in this task is read-only or operates on your own machine. Keep it that way.

02 // Working set

Your CVE list for today

You'll work through three sets of CVEs. The first two are fixed - everyone in the cohort works on these. The third is your own - pulled directly from the actor profile you wrote in Lab 01.

// Set A · case studies

3 big ones

From the in-person session

CVE-2021-44228 · Log4Shell
CVE-2017-0144 · EternalBlue
CVE-2021-26855 · ProxyLogon

You already know what these do. Today you see what exploits exist for them.

Goal // build muscle memory on familiar ground

// Set B · Activity 4 CVEs

4 you researched

From the in-person Activity 4 lookup

CVE-2023-23397 · Outlook NTLM
CVE-2022-30190 · Follina
CVE-2021-34527 · PrintNightmare
CVE-2020-1472 · Zerologon

Different shapes - privilege escalation, RCE, domain takeover.

Goal // see how exploit availability varies by CVE type

// Set C · your actor's CVEs

From your Lab 01 profile

3-5 CVEs you identified in the actor profile work

Open your one-page actor profile. The "Known CVEs" section is your input here. You'll run each one through searchsploit and check KEV status - finishing the work you started in Lab 01.

If you didn't finish Lab 01: use the LockBit CISA advisory CVE list as your Set C (the hints in Lab 01 step 10 list them).

Goal // see your actor's tradecraft as data, not prose

03 // The work

Fourteen steps in the terminal

Open a terminal on your Kali box. Click each step to mark it done. The "Copy" buttons next to commands save you from typos - but read what you're typing before you run it. The flag is the lesson. The output is the test.

Work in a fresh directory. Run these first, before anything else:

$ mkdir -p ~/lab02-cve && cd ~/lab02-cve

$ pwd

// pwd should print /home/kali/lab02-cve (or your username instead of "kali"). Everything you do today lives in this folder.

A · searchsploit basics

Get the database fresh, then run searches on the case-study CVEs from yesterday.

Step 01

Update the local Exploit-DB database

searchsploit is offline, but the index goes stale. Update it once a week. Today is that week.

$ searchsploit -u

If it asks for sudo, give it sudo. The update can take 1-3 minutes - it's pulling the latest Exploit-DB index. If you get a "command not found", install it: sudo apt update && sudo apt install -y exploitdb.

Step 02

Run your first searches against the case-study CVEs

Three of the most famous CVEs of the past decade. The --cve flag tells searchsploit to match the CVE field specifically, not just the description.

$ searchsploit --cve 2021-44228

$ searchsploit --cve 2017-0144

$ searchsploit --cve 2021-26855

// roughly what you'll see------------------------------------------------------------------------------- ---------------------------------------------- Exploit Title | Path ------------------------------------------------------------------------------- ---------------------------------------------- Apache Log4j 2 - Remote Code Execution (RCE) | java/remote/50592.py Apache Log4j 2.14.1 - Information Disclosure | multiple/remote/50661.py ...

Step 03

Note the counts

For each of the three CVEs, write down how many exploits are listed. This is the first column of your deliverable table. Big difference between CVEs that have one exploit and CVEs that have twenty.

You can count rows with searchsploit --cve 2021-44228 | wc -l - but subtract the header and footer rows (about 4). Or just eyeball it. Either's fine.

Step 04

Search by name, not CVE

Sometimes you don't have a CVE - just a product name. Try this - same vulnerability, different angle:

$ searchsploit log4j

$ searchsploit eternalblue

Note in your report: does name-based search return the same results, more, or fewer than CVE-based search? Why might that be?

B · Reading exploits

Open three real exploits in less. Read them. Write down what each one does. You won't understand every line - that's fine. You're building shape recognition.

Step 05

Open a Log4Shell exploit

Pick any Python exploit from the Log4Shell results (Step 02). Note its EDB-ID from the path - for example, java/remote/50592.py → EDB-ID is 50592. Then open it:

$ searchsploit -x 50592

The file opens in less. Navigate with arrows or Page Down / Page Up. Press q to quit. Press /word + Enter to search within the file. Read the comment block at the top. That's where the author tells you what the exploit does.

Step 06

Open an EternalBlue exploit

Pick a different language this time - there are Python, Ruby, and C exploits for EternalBlue. Pick the Ruby one (Metasploit module) if you can find it, or any non-Python option.

$ searchsploit -x <EDB-ID>

Replace <EDB-ID> with the actual number, no angle brackets. For example: searchsploit -x 42315. Metasploit modules end in .rb. C exploits end in .c. Python exploits end in .py.

Step 07

Open a ProxyLogon exploit

Same drill - different exploit, different shape. For each of the three you've now read, write down (in your report):
· The EDB-ID
· The language
· The author (from the header comment)
· One sentence on what the exploit does
· One technical detail you noticed (a specific function call, a hardcoded URL, a request pattern - anything that caught your eye)

C · Your actor's CVEs

Now run the same drill against the CVEs from your Lab 01 actor profile. This is where Lab 01 and Lab 02 connect.

Step 08

Take your actor's CVE list and run searchsploit on each

From your Lab 01 profile, the "Known CVEs" section. For each one (typically 3-5):

$ searchsploit --cve <YEAR-NUMBER>

Record: CVE ID, exploit count, top exploit's EDB-ID, top exploit's language.

Step 09

Mirror one of your actor's exploits to your working directory

The -m flag copies an exploit by EDB-ID to your current folder. Pick the most interesting one from Step 08:

$ cd ~/lab02-cve

$ searchsploit -m <EDB-ID>

$ ls -la

Paste the output of ls -la into your report. The file should be there with timestamp and permissions.

Step 10

Pattern observation

Look at the pattern across all your actor's CVEs. Do they cluster around a specific product family (Fortinet, Microsoft, VMware)? A specific weakness type (RCE, authentication bypass, deserialisation)? A specific year range? Write one paragraph on what the pattern tells you about your actor's preferences.

Most actors have favourites. LockBit hits VPN appliances (Fortinet, F5) because they're internet-exposed. APT29 prefers identity systems (Microsoft Entra/Azure AD, on-prem AD) because identity = persistence. Your "pattern paragraph" is the first piece of actual analysis you've produced - it's small but it matters.

Step 11

No exploits found?

If any of your actor's CVEs return zero results from searchsploit, don't ignore it. Note it down. Then think: does that mean the CVE is unimportant? Or does it mean public exploits don't exist and the actor used private tooling? (For nation-state actors, usually the second.) Write a one-line note for each "zero result" CVE in your report.

D · KEV cross-reference

CISA's Known Exploited Vulnerabilities catalogue is the most operationally useful CVE list in existence. Pull it once, search it offline.

Step 12

Download the CISA KEV catalogue as JSON

CISA publishes the catalogue at a stable URL in both CSV and JSON. Pull it once with curl, then you have it locally - no need to hammer their server.

$ cd ~/lab02-cve

$ curl -o kev.json https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

$ ls -lh kev.json

The file should be a few MB. If curl complains about SSL, add -k - but only as a last resort and only for this specific known-good URL.

Step 13

Check each of your CVEs against KEV with grep

grep searches a file for a pattern. The pattern here is just the CVE ID. If grep finds a match, the CVE is on the KEV list - being actively exploited in the wild. If grep returns nothing, it isn't.

$ grep "CVE-2021-44228" kev.json

$ grep "CVE-2017-0144" kev.json

Now do the same for every CVE in Sets A, B, and C (from your actor profile). For each: on KEV (yes/no).

If grep returns multiple lines (the CVE appears in several JSON fields), that's still a yes. If it returns nothing, the CVE isn't on KEV. If you want a cleaner one-liner, try grep -c "CVE-2021-44228" kev.json - that counts matches; 0 means not on KEV, anything > 0 means yes.

Step 14

Write your report

Open nano (or any editor) and write the deliverable - see Section 4 below for the exact format. Save it as report.md in your ~/lab02-cve folder.

$ cd ~/lab02-cve && nano report.md

nano shortcuts: Ctrl+O save, Ctrl+X exit, Ctrl+K cut line, Ctrl+U paste. That's all you need.

04 // Deliverable

What to hand in

report.md - terminal-written findings Due // Day 6

A single Markdown file saved as ~/lab02-cve/report.md. Written in nano (or vim if you're feeling fancy). The report has four sections:

1. Header. Your name, date, and which actor you profiled in Lab 01 (so the reviewer has context).

2. Searchsploit findings table. All CVEs from Sets A, B, and C - one row each. Columns: CVE · description · exploit count · top EDB-ID · language · on KEV (yes/no).

3. Exploit readings. Three short paragraphs - one per exploit you read in Block B. EDB-ID, language, author, what it does, one technical detail you noticed.

4. Pattern paragraph + reflection. From Step 10 - what does the CVE pattern tell you about your actor? Plus one short paragraph (3-5 sentences) reflecting on the difference between reading about CVEs and handling them in the terminal.

Drop the finished file into the shared submissions folder as UGLabs / Lab 02 Submissions / [your-name]-cli-report.md. Don't convert to PDF or Word - leave it as markdown. That's the format we use for internal analyst notes.

05 // How it's marked

What good looks like

Reviewed by Sudo with verbal feedback before Lab 03 deploys. The lens for this one is different from Lab 01 - less about research quality, more about whether you actually did the terminal work and understood what you were seeing.

30%

Completeness of the findings table. Every CVE from Sets A, B, and C, with every column filled. "Not found" is a valid value - empty cells aren't.

25%

Quality of the exploit readings. Three exploits, three different languages where possible. Each reading should show you actually read the file - that means real specifics (a function name, a URL, a request structure), not generic "the script exploits the vulnerability" filler.

20%

KEV cross-reference accuracy. Did you check every CVE? Are the yes/no calls correct? Did you note any surprises (e.g. a CVSS 9.8 that isn't on KEV, or a CVSS 6 that is)?

15%

The pattern paragraph. Did you spot the cluster? "These are all Microsoft RCE vulns" or "all VPN appliance bugs" or "all 2021-2022, all CVSS 9+" - any real observation about the shape of your actor's preferences earns this.

10%

Terminal discipline. Report written in nano/vim, saved as markdown, in the right folder, with the right filename. Small things, but they show you can follow a workflow.

06 // Cheat sheet

Commands to remember

You'll use these every week from now on. Print this section out if it helps. Two weeks of using these commands and they'll be in your fingers.

Command	What it does
`searchsploit -u`	Update the local Exploit-DB index. Run weekly.
`searchsploit <term>`	Search by keyword (product name, CVE, anything).
`searchsploit --cve YEAR-NUM`	Search by CVE specifically. Most accurate for CVE work.
`searchsploit -x <EDB-ID>`	Open an exploit in less. Read-only.
`searchsploit -m <EDB-ID>`	Copy an exploit to your current directory.
`curl -o file URL`	Download a URL to a file. Quiet, scriptable, reliable.
`grep "pattern" file`	Search a file for matching lines.
`grep -c "pattern" file`	Count matches instead of printing them.
`less file`	Open a file in a pager. q to quit, /word to search.
`nano file`	Edit a file in the simplest terminal editor on Kali.
`pwd · ls -la · cd · mkdir`	Where am I · what's here · go there · make a folder.

// Reference links (open in browser)

exploit-db.com - Exploit-DB online. The same database searchsploit queries locally.

cisa.gov/known-exploited-vulnerabilities-catalog - KEV catalogue (HTML version).

nvd.nist.gov - for cross-checking CVE details on any surprises.

github.com/offensive-security/exploitdb - the source repository for the database. Useful to know exists.

Everything you ran today is local or read-only. If you find yourself about to run an exploit against an address that isn't 127.0.0.1, your own lab VM, or an explicitly authorised CTF target - stop. Ask. Always. The cost of getting this wrong is criminal liability, not just a stern conversation.