THE JR PENTESTER FIELD GUIDE

MODULE 1
Recon, Intelligence & Documentation Tools

By Prince Obeng Akumanying

A beginner-friendly companion built alongside the TryHackMe Jr Penetration Tester path — written so that
someone with zero background can open any chapter and actually understand it.
 HOW TO USE THIS BOOK
Every chapter in this module follows the same shape, so you always know where to look: a one-line
analogy first (so the idea clicks before the jargon shows up), then what the tool actually is, why it matters on
a real pentest, how to actually use it, and a quick reference box you can glance at later without re-reading
the whole chapter.

This is written for a complete beginner. If a term hasn't been explained yet, treat that as a bug in the book,
not a gap in your knowledge.

WHAT'S IN MODULE 1
1. Shodan — the search engine for the internet's front doors
2. VirusTotal — the group chat of antivirus engines
3. CVE — the dictionary of known vulnerabilities
4. Exploit-DB — the phrasebook that turns the dictionary into action
5. man — the instruction booklet built into every tool
6. GitHub (for recon) — the messy, unofficial cousin of Exploit-DB
7. HTTP in Detail — the language every website secretly speaks
8. Basic CLI (Linux) — talking to the computer directly, no clicking required
9. Web Applications — what you're actually looking at when you test a website

Later modules will keep building on this one as new tools get covered — this is Module 1, not the whole book.

The Jr Pentester Field Guide - Module 1 Page 2

 CHAPTER 1

Shodan
The search engine that already scanned the internet before you asked it to.

Imagine Google, but instead of indexing webpages, it indexes devices — servers, routers, webcams,
industrial control systems, anything with a public IP address that answers when you knock. Shodan's
crawlers are already out there, 24/7, knocking on every port of every public device they can find, and
quietly writing down what answers back.

THE ANALOGY
Think of Shodan as a phonebook for the internet's front doors — except someone already walked
down every street, knocked on every door, and wrote down exactly what kind of lock each one
has, before you ever asked.

WHY IT MATTERS ON A PENTEST

You are not scanning the target yourself when you use Shodan — you are reading results from a scan that
already happened. That means zero traffic sent to the target during this step, which makes it one of the
safest, quietest ways to start recon. If you know a target is running a vulnerable software version, Shodan
can tell you instantly, without you ever touching their network.

HOW TO USE IT

apache 2.4.1 # find servers advertising this exact version

hostname:[Link] # scope results to one specific target
country:IE # restrict results to a country
port:22 # restrict results to a specific port
org:"Amazon Web Services" # scope to a hosting provider / org

WATCH OUT
Shodan's data can be stale — it shows what it saw on its last crawl, which might be days or weeks
old. A version banner shown here might already be patched. Treat Shodan as a starting point, not
a guarantee.
Searching Shodan is passive and legal. Actually connecting to or logging into something you
found there is not — only do that within an authorized, in-scope engagement.

The Jr Pentester Field Guide - Module 1 Page 3

 CHAPTER 2

VirusTotal
One upload, dozens of antivirus opinions, all at once.

VirusTotal takes a file, a URL, a domain, or an IP address and checks it against dozens of different
antivirus engines and threat-intelligence sources simultaneously, then hands you back a scorecard: how
many engines flagged it, which ones, and why.

THE ANALOGY
Instead of asking one doctor for a second opinion, VirusTotal is like asking seventy doctors at
once and getting a single report card back: '43 out of 70 think this is malicious.' You're not relying
on any single engine's judgment — you're seeing the consensus.

WHY IT MATTERS ON A PENTEST

Two big uses: first, checking whether a suspicious file, link, or attachment is known malware before you (or
a client) interacts with it. Second — and this matters more as you go further — checking whether a tool or
PoC exploit you're about to run has been flagged by anyone as malicious before you execute it on your
own machine.

HOW TO USE IT

1. Go to [Link]
2. Upload a file, or paste a URL / domain / IP / file hash
3. Read the detection ratio (e.g. 12/70 engines flagged it)
4. Check the 'Details' and 'Community' tabs for context, not just the raw n
umber

WATCH OUT
A low detection count doesn't mean something is safe — it can mean the threat is brand new and
antivirus signatures haven't caught up yet.
Never upload sensitive or confidential files to VirusTotal — anything you upload becomes visible
to other researchers and threat-intel platforms.

The Jr Pentester Field Guide - Module 1 Page 4

 CHAPTER 3

CVE
Common Vulnerabilities and Exposures — the dictionary of known bugs.

A CVE is not a tool you run — it's an ID number, like CVE-2021-44228, assigned to one specific, publicly
known vulnerability. The point of CVE is simple: make sure everyone — vendors, researchers, scanners,
Shodan, you — is talking about the exact same bug instead of five different names for it.

THE ANALOGY
CVE is a dictionary. Every entry has a name (the ID) and a definition (what the bug is and what it
affects) — but a dictionary doesn't teach you how to actually use the word in a sentence. That part
comes next, in the Exploit-DB chapter.

WHY IT MATTERS ON A PENTEST

Once you know a target's exact software and version — from Shodan, from a banner grab, from anywhere
— you look up its CVEs to find out what's actually broken about it, and how severe that break is. Each CVE
usually comes with a CVSS score (0-10) rating how serious it is, which helps you prioritize what to chase
first.

HOW TO USE IT

1. Get an exact software name + version (e.g. Apache 2.4.49)

2. Search a CVE database ([Link], [Link]) for that product/ver
sion
3. Read the CVSS score to gauge severity
4. Note the CVE ID (e.g. CVE-2021-41773) and take it to Exploit-DB / GitHub
next

WATCH OUT
A CVE existing doesn't automatically mean it's exploitable in your specific situation —
configuration, patch level, and environment all affect whether it actually applies.

The Jr Pentester Field Guide - Module 1 Page 5

 CHAPTER 4

Exploit-DB
Where the dictionary entry turns into something you can actually run.

Exploit-DB is a public, searchable archive of proof-of-concept (PoC) exploit code, submitted by researchers
and often cross-referenced directly to CVE IDs. Where a CVE tells you a bug exists, Exploit-DB is often
where you find someone's actual working (or attempted) code that demonstrates it.

THE ANALOGY
If CVE is the dictionary entry for a word, Exploit-DB is the phrasebook that shows you the word
actually spoken out loud, in a real sentence, doing something.

WHY IT MATTERS ON A PENTEST

This is usually the last stop in the recon-to-exploitation chain: Shodan finds the candidate, CVE tells you
what's wrong with it, Exploit-DB gives you (or shows you the shape of) the code to actually test it. Even
when a PoC doesn't work out of the box, reading it teaches you exactly how the vulnerability is triggered.

HOW TO USE IT

1. Go to [Link]
2. Search by CVE ID, product name, or version
3. Read the PoC code before running it, every time
4. Test only against machines you're authorized to test

WATCH OUT
A PoC on Exploit-DB is still code written by a stranger. Read it before you run it — understand
what it actually does, not just what it claims to do.
Some PoCs are unreliable, outdated, or need modification for your exact target — treat them as a
strong starting point, not a guaranteed working exploit.

The Jr Pentester Field Guide - Module 1 Page 6

 CHAPTER 5

man
The instruction booklet that ships inside every command-line tool.

man (short for "manual") is a built-in Linux command that opens the official documentation for another
command, right inside your terminal — no internet connection required. Every flag, every option, every bit
of behavior a tool has is usually documented in its man page.

THE ANALOGY
Every tool you install comes with its own instruction booklet already tucked inside the box. man is
just how you pull that booklet out and read it, instead of guessing at buttons or searching the
internet for someone else's summary.

WHY IT MATTERS ON A PENTEST

You will constantly forget a flag for a tool you use all the time. man is faster and more trustworthy than
searching online, and it works even when a target machine has no internet access — which many CTF and
lab machines deliberately don't.

HOW TO USE IT

man nmap # open the manual for the nmap tool

man man # yes, there is a manual for the manual command
/keyword # inside a man page, search for a keyword
q # quit out of the man page viewer

READING A MAN PAGE

● NAME — what the tool is, in one line
● SYNOPSIS — the exact command syntax
● DESCRIPTION — the full explanation
● OPTIONS — every flag, explained one by one
● EXAMPLES — sometimes included, real usage samples

The Jr Pentester Field Guide - Module 1 Page 7

 CHAPTER 6

GitHub (for recon)

The messy, unofficial cousin of Exploit-DB.

Researchers frequently publish PoC exploit code as a GitHub repository before, or instead of, ever
submitting it to Exploit-DB. So searching GitHub directly for a CVE number (CVE-2021-44228 exploit) often
turns up working code, deeper write-ups, or several competing implementations of the same exploit.

THE ANALOGY
If Exploit-DB is the curated, edited phrasebook, GitHub is the enormous pile of handwritten notes
other travelers left behind — some brilliant, some wrong, none of it checked by an editor before
you find it.

A KEY IDEA: THE POC OFTEN *IS* THE EXPLOIT

For a lot of CVEs, there's no separate "theory document" and "weapon" — the proof-of-concept code
someone uploads to prove a bug is real is functionally a working exploit. That's part of why disclosure
timing matters so much in security: the moment a working PoC lands on GitHub, the vulnerability effectively
becomes usable by anyone, not just the researcher who found it.

HOW TO USE IT

site:[Link] CVE-2021-44228 # search engine query

CVE-2021-41773 exploit github # direct GitHub/general search

WATCH OUT — THIS ONE MATTERS MORE THAN THE OTHERS

Unlike Exploit-DB, nobody curates GitHub. Repos can be broken, outdated, or deliberately
malicious — including exploits secretly modified to backdoor whoever runs them (this genuinely
happens, sometimes targeting other attackers/researchers specifically).
Rule of thumb: read the code line by line before running it, ideally inside an isolated VM, and
never blind-execute a random PoC on anything that matters.

The Jr Pentester Field Guide - Module 1 Page 8

 CHAPTER 7

HTTP in Detail
The language every website secretly speaks to your browser.

HTTP (HyperText Transfer Protocol) is the set of rules your browser and a web server use to talk to each
other. Every time you load a page, click a link, or submit a form, your browser sends an HTTP request, and
the server sends back an HTTP response. Everything you'll ever do to a website during a pentest happens
inside this conversation.

THE ANALOGY
Think of HTTP as a very strict postal system. Every letter (request) has to be written in a specific
format — a return address, a subject line, a body — or the post office (server) won't process it.
The reply (response) follows the same strict format back.

THE SHAPE OF A REQUEST

GET /directory?id=101 HTTP/1.1

Host: [Link]
Cookie: session=active; user_role=student
User-Agent: Mozilla/5.0 ...
(body goes here, if any — usually empty on a GET)

● Method — what you want to do: GET (fetch), POST (submit/create), PUT (replace), DELETE (remove),
and a few others.

● Path — which resource on the server you're asking for.

● Headers — metadata about the request: who you are, what cookies you're carrying, what kind of
response you'll accept.

● Body — the actual data being sent, common on POST requests (e.g. a submitted username and
password).

THE SHAPE OF A RESPONSE

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session=active; Path=/
...(the actual page content)...

STATUS CODES WORTH KNOWING COLD

The Jr Pentester Field Guide - Module 1 Page 9

 ● 200 OK — worked fine.
● 301 / 302 — redirect, go look somewhere else.
● 401 Unauthorized — you need to log in.
● 403 Forbidden — server knows who you are, still says no.
● 404 Not Found — nothing lives at that path.
● 500 Internal Server Error — the server itself broke, often useful as an accidental clue during testing.

WHY IT MATTERS ON A PENTEST

Almost every classic web vulnerability is really just "the server trusted something in the request that it
shouldn't have." IDOR is trusting a URL parameter blindly. A cookie-tampering bypass is trusting a header
the client controls. Once you can read a raw request and response fluently, most web vulnerabilities
become a lot less mysterious — you're just asking, at each step, "what is this server choosing to believe,
and can I make it believe something false?"

WATCH OUT
Plain HTTP sends everything in the clear — anyone on the same network can read it. HTTPS
wraps the same conversation in encryption (TLS) so it can't be read in transit, but the
request/response structure underneath is identical.
Tools like Burp Suite or your browser's dev tools (Network tab) let you see this raw conversation
directly — get comfortable reading it there before you ever run an automated scanner.

The Jr Pentester Field Guide - Module 1 Page 10

 CHAPTER 8

Basic CLI (Linux)

Talking to the computer directly, instead of clicking icons.

The command line (CLI) is a text-only way of controlling a computer: you type an instruction, press Enter,
and the computer does exactly that — nothing more, nothing hidden behind a menu. Almost every
pentesting tool you'll ever use is run from a Linux terminal, so comfort here is not optional — it's the
foundation everything else sits on.

THE ANALOGY
A graphical interface is like ordering from a restaurant menu with pictures — convenient, but
limited to what's shown. The command line is like walking into the kitchen and telling the chef
exactly what you want, ingredient by ingredient. More power, more precision, and yes — more
ways to mess up if you're not careful.

NAVIGATION

pwd # print working directory (where am I right now?)

ls -la # list everything in the current folder, including hidde
n files
cd /path/to/dir # change directory
cd .. # go up one directory

LOOKING AT FILES

cat [Link] # print a file's full contents to the screen

less [Link] # scroll through a file page by page
head [Link] # show the first 10 lines
tail -f [Link] # follow a file live as new lines get added (great for
watching logs)

SEARCHING & FILTERING

grep 'admin' [Link] # find every line containing 'admin'

grep -r 'password' ./ # search recursively through every file in a
folder
find / -name '*.conf' # find files by name across the whole system

The Jr Pentester Field Guide - Module 1 Page 11

 PERMISSIONS & PRIVILEGE

whoami # who am I logged in as?

chmod +x [Link] # make a file executable
sudo # run a command as an administrator (superuser)

PROCESSES & NETWORK

ps aux # list every running process

ss -tulpn # list open ports and what's listening on them
curl -i [Link] # send an HTTP request and see the raw respon
se

WHY IT MATTERS ON A PENTEST

Nearly every tool in this book — Shodan's API, exploit scripts from Exploit-DB or GitHub, even reading a
man page — assumes you're comfortable in a terminal. It's also how you'll interact with most target and
attack machines directly, especially over SSH.

WATCH OUT
The terminal will do exactly what you tell it, including destructive things, with no confirmation
dialog. A command like rm -rf / (delete everything, forcibly, recursively, starting from the root) is
catastrophic and there's no undo — always read a command fully before pressing Enter,
especially anything involving rm, sudo, or a script you copied from somewhere else.

The Jr Pentester Field Guide - Module 1 Page 12

 CHAPTER 9

Web Applications
What you're actually looking at when you test a website.

A web application is any website that does more than show static text — it takes input from you, stores or
looks up data, and gives back a personalized response. Your own Accra High Student Registry portal is a
perfect example: a login form, a search box, and data that changes depending on who's asking and what
they ask for.

THE ANALOGY
A static website is a printed poster — the same for everyone who looks at it. A web application is
more like a bank teller: it asks who you are, checks your identity, looks something up specifically
for you, and hands back an answer built just for that request.

THE TWO HALVES OF EVERY WEB APP

● Front-end (client-side) — the HTML, CSS, and JavaScript that runs inside your browser. You can
view and even edit this yourself using browser dev tools — but editing it only changes what you see, it
doesn't change what's actually stored on the server.

● Back-end (server-side) — the code and database running on the server, which you never see directly.
This is where real authentication checks, data storage, and business logic are supposed to live — and
where most serious vulnerabilities actually hide.

COMMON MOVING PARTS YOU'LL KEEP SEEING

● Sessions & cookies — how a web app remembers you're logged in between page loads, since HTTP
itself has no memory of its own (this is exactly the mechanism a weak cookie-trust bug abuses).

● Forms & parameters — anywhere a user can send data to the server (a login box, a search field, a
URL parameter like ?id=101). Every one of these is a place the server has to decide whether to trust
what it's given.

● A database — where the actual data lives (student records, user accounts, etc.), usually queried
behind the scenes by the back-end in response to what you asked for.

WHY IT MATTERS ON A PENTEST

The golden rule of almost all web application security: never trust the client. Anything happening in the
browser — a cookie's value, a hidden form field, even what the page displays to you — was, at some point,
sent by the client and can be changed by the client. A secure web app re-checks everything that matters on
the server side, every time. Nearly every vulnerability class you'll study next (IDOR, broken auth, injection,
and more) is really just some version of "the server trusted the client when it shouldn't have."

The Jr Pentester Field Guide - Module 1 Page 13

 WATCH OUT
Just because a button is missing, a field is disabled, or an option isn't shown to you in the
browser, doesn't mean the underlying server-side action is actually blocked. Always test the
request directly (with curl, Burp, or similar) rather than only trusting what the interface shows you.

The Jr Pentester Field Guide - Module 1 Page 14

 End of Module 1. The full picture you now have: HTTP is the language every request and response
speaks, the CLI is how you actually operate the tools involved, and a web application is the thing being
tested — built from a client half you can see and a server half that's supposed to check everything the client
can't be trusted to check. On top of that foundation sits the recon chain: Shodan finds a candidate → CVE
tells you what's wrong with it → Exploit-DB or GitHub gets you code to test it → man keeps every tool along
the way usable without leaving the terminal → VirusTotal checks anything suspicious before you trust it.
Module 2 will keep building on this as new tools and topics get added.

The Jr Pentester Field Guide - Module 1 Page 15