 |
| Ethical Hacking |
🛡️ Ethical Hacking — Day 10
Reconnaissance Fundamentals: Passive & Active Information Gathering
⚠️ LEARNING PURPOSE ONLY: This tutorial is strictly for educational and defensive cybersecurity learning. Perform reconnaissance only on systems, domains, networks, applications, and infrastructure that you own or have explicit permission to assess. Passive does not automatically mean permitted—respect privacy, terms of service, and applicable laws.
Welcome to Day 10 of your Ethical Hacking Learning Series.
Over the last few days, you learned:
Day 6–7: Nmap
Day 8–9: Wireshark
Networking, TCP/IP, DNS, ARP, ports, and protocols
Today we're moving into one of the first phases of a professional security assessment:
🔎 Reconnaissance
Reconnaissance means collecting information about an authorized target before performing deeper security testing.
The goal isn't:
"How can I hack it?"
The goal is:
"What is the authorized environment, what is exposed, and what should be assessed?"
🎯 Day 10 Learning Objectives
Today you'll learn:
What reconnaissance means
Passive vs active reconnaissance
Attack surface
Domains and subdomains
DNS information
WHOIS/RDAP concepts
IP addresses
DNS records
HTTP headers
Technology identification
Metadata
Search-engine reconnaissance
Basic Linux tools
Windows PowerShell tools
macOS tools
Documentation
Scope control
Building a safe reconnaissance workflow
1. What Is Reconnaissance?
Imagine a company gives you permission to perform a security assessment.
Before testing vulnerabilities, you need to understand what you're assessing.
You might need to identify:
Company
↓
Authorized Domains
↓
Subdomains
↓
IP Addresses
↓
DNS
↓
Web Applications
↓
Technologies
↓
Services
↓
Attack Surface
This information helps you build an accurate assessment plan.
2. Attack Surface
The attack surface is the collection of potentially exposed systems, services, applications, interfaces, and entry points that could require security assessment.
For example:
Example Organization
│
├── Website
│
├── Web Application
│
├── API
│
├── Email Services
│
├── DNS
│
├── VPN
│
├── Cloud Services
│
└── Remote Access Services
A security professional first needs to understand what exists.
3. Passive vs Active Reconnaissance
This distinction is extremely important.
🟢 Passive Reconnaissance
You collect information without directly interacting with the target infrastructure in a probing/scanning manner.
Examples:
Public documentation
Search engines
Public DNS information
Public registration information
Public certificates
Public company information
Publicly available technology information
Conceptually:
Public Sources
↓
Information
↓
Analysis
4. Active Reconnaissance
Active reconnaissance involves interacting with the target infrastructure.
Examples include:
DNS queries
HTTP requests
Port scanning
Service enumeration
Network discovery
For example:
Your Computer
│
│ Request
▼
Authorized Target
│
│ Response
▼
Your Computer
Because this generates traffic against the target, authorization and scope are especially important.
5. Reconnaissance Workflow
A professional workflow can look like:
1. Authorization
↓
2. Define Scope
↓
3. Passive Recon
↓
4. DNS Information
↓
5. Asset Identification
↓
6. Limited Active Recon
↓
7. Technology Identification
↓
8. Documentation
↓
9. Security Assessment
Notice something important:
Authorization comes before reconnaissance.
6. Scope
Before testing a real organization, you should have a clearly defined scope.
For example:
IN SCOPE
example-company.com
app.example-company.com
api.example-company.com
And perhaps:
OUT OF SCOPE
mail.example-company.com
third-party.example.com
customer systems
employee devices
Never assume:
"If I discovered it, I'm allowed to test it."
Discovery does not equal authorization.
7. Domain Names
A domain may look like:
example-company.com
Subdomains may include:
www.example-company.com
app.example-company.com
api.example-company.com
portal.example-company.com
Conceptually:
example-company.com
│
├── www
├── app
├── api
└── portal
Each could represent a different application or service.
8. DNS Reconnaissance
DNS is one of the most important sources of infrastructure information.
Common DNS records include:
| Record | Purpose |
|---|---|
| A | IPv4 address |
| AAAA | IPv6 address |
| CNAME | Alias |
| MX | Mail server |
| NS | Name server |
| TXT | Text/policy information |
| SOA | Zone authority information |
You've already encountered these on Day 5 and Day 9.
Today we'll use them for reconnaissance.
🐧 Linux — DNS Recon
Check a domain:
dig example.com
Check an A record:
dig example.com A
Check an AAAA record:
dig example.com AAAA
Check MX:
dig example.com MX
Check NS:
dig example.com NS
Check TXT:
dig example.com TXT
🍎 macOS — DNS Recon
macOS can use the same dig commands:
dig example.com
dig example.com A
dig example.com MX
dig example.com NS
dig example.com TXT
🪟 Windows — DNS Recon
PowerShell:
nslookup example.com
Specific record types:
nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=NS example.com
nslookup -type=TXT example.com
🧪 Practical Lab 1 — DNS Recon
For today's introductory exercise, you can use:
example.com
or, preferably, a domain you own/control.
Linux/macOS
dig example.com A
dig example.com MX
dig example.com NS
dig example.com TXT
Windows
nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=NS example.com
nslookup -type=TXT example.com
Record:
A:
________________
MX:
________________
NS:
________________
TXT:
________________
⚠️ Learning Purpose Only: For real-world targets, perform these queries only where your assessment rules permit them. For the course, using your own domain is preferred.
9. Understanding DNS Results
Suppose:
example.com
A
→ 93.x.x.x
This tells us that the domain has an IPv4 address associated with it.
But don't conclude:
"This is the web server."
It could be:
CDN infrastructure
Load balancer
Reverse proxy
Cloud service
Hosting provider
DNS results need interpretation.
10. CNAME
Suppose you discover:
app.example.com
CNAME
→ something.provider.example
This tells you that the hostname is an alias.
Conceptually:
app.example.com
↓
CNAME
↓
provider-host.example
This can reveal information about infrastructure architecture.
11. MX Records
MX records indicate mail-exchange infrastructure.
For example:
dig example.com MX
You might see:
example.com
↓
MX
↓
mail.provider.example
This doesn't mean you've found a vulnerability.
It simply tells you:
Where email delivery for the domain is directed.
12. NS Records
NS records identify authoritative name servers.
dig example.com NS
Conceptually:
Domain
↓
Authoritative DNS
↓
Nameserver
This helps you understand the DNS architecture.
13. TXT Records
TXT records can contain various kinds of information.
A common use is email-security policy.
For example:
SPF
DKIM-related information
DMARC-related information
Domain verification
Other published text
Don't assume every TXT record has the same purpose.
14. WHOIS and RDAP
Domain registration information can sometimes provide information about a domain.
Historically, WHOIS has been widely used.
Modern registration systems increasingly use RDAP (Registration Data Access Protocol).
The information available to the public can be limited because of privacy protections and registry policies.
The important ethical-hacking concept is:
Use publicly available registration information to understand the asset—not to identify or harass individuals.
15. Check WHOIS Availability
On Linux/macOS, if the whois utility is installed:
whois example.com
Check whether it's installed:
which whois
On Windows, you can use an approved registration/RDAP service or browser-based public registry information.
For an actual engagement, follow the client's rules regarding external services.
16. IP Address Information
DNS can lead you to IP addresses.
For example:
dig example.com A
You may receive an address.
You can then inspect your own authorized environment using tools such as:
host example.com
or:
dig +short example.com
🐧 Linux
host example.com
dig +short example.com
🍎 macOS
host example.com
dig +short example.com
🪟 Windows
nslookup example.com
17. HTTP Reconnaissance
Now let's examine the web layer.
A web server responds to HTTP requests.
You can inspect basic response headers from an authorized web server.
🐧 Linux
curl -I https://example.com
🍎 macOS
curl -I https://example.com
🪟 Windows PowerShell
curl.exe -I https://example.com
Using curl.exe avoids confusion with PowerShell's historical curl alias behavior.
18. What Are HTTP Headers?
You might see headers such as:
HTTP/1.1 200 OK
Content-Type: text/html
Server: ...
Date: ...
Cache-Control: ...
Headers can provide information about:
Content type
Caching
Redirects
Security policies
Server behavior
However:
Don't treat the
Serverheader as guaranteed proof of the actual backend technology.
Headers can be hidden, modified, or generated by proxies/CDNs.
19. Security Headers
Some useful security-related headers include:
Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
These headers can provide clues about a site's security configuration.
For example:
curl -I https://example.com
Then inspect whether security-related headers are present.
🧪 Practical Lab 2 — HTTP Header Analysis
Use your own website or authorized lab.
Linux/macOS
curl -I https://YOUR-DOMAIN
Windows
curl.exe -I https://YOUR-DOMAIN
Record:
Status Code:
Content-Type:
Server:
Strict-Transport-Security:
Content-Security-Policy:
X-Content-Type-Options:
If a header isn't present, record:
Not observed
Don't immediately label a missing header as a vulnerability. Its importance depends on the application and context.
20. HTTP Status Codes
You'll frequently encounter:
| Status | Meaning |
|---|---|
| 200 | OK |
| 201 | Created |
| 301 | Permanent redirect |
| 302 | Temporary redirect |
| 400 | Bad Request |
| 401 | Authentication required/unauthorized |
| 403 | Forbidden |
| 404 | Not Found |
| 429 | Too Many Requests |
| 500 | Internal Server Error |
| 502 | Bad Gateway |
| 503 | Service Unavailable |
Understanding status codes is essential for web security testing.
21. Technology Identification
During reconnaissance, you may want to understand what technologies are publicly exposed.
Possible technologies include:
Web Server
Programming Language
Framework
CMS
JavaScript Libraries
CDN
Cloud Provider
Database technology
But remember:
Technology identification is an inference, not necessarily proof.
22. Browser Developer Tools
You don't always need specialized tools.
Open your browser's Developer Tools.
Look at:
Network
↓
Request
↓
Headers
↓
Response
You can inspect:
Request method
URL
Status code
Request headers
Response headers
Cookies
Content type
Timing
Only inspect sites and applications you're authorized to analyze.
23. Metadata
Metadata is information about information.
Examples:
Document author
Creation date
Software used
File properties
Image metadata
PDF metadata
Publicly exposed metadata can sometimes reveal unnecessary information.
From a defensive perspective:
Organizations should minimize sensitive metadata exposure.
24. File Metadata — Safe Local Exercise
Don't download random files from organizations and inspect them without permission.
Instead, create your own test file.
For example:
day10-test.txt
Then inspect its basic properties.
Linux/macOS
file day10-test.txt
stat day10-test.txt
Windows PowerShell
Get-Item day10-test.txt | Format-List *
This teaches the concept without touching somebody else's files.
25. Search Engine Reconnaissance
Search engines can expose publicly indexed information.
For an authorized organization, you might search publicly available information such as:
Company name
Official domain
Public documentation
Public job postings
Public technology documentation
The purpose is to understand:
What information is already publicly exposed?
⚠️ Search Operators
Search engines support advanced operators.
However, don't turn today's lesson into an exercise for finding exposed credentials or private information.
For this course, use search operators only to study your own organization/domain and publicly intended information.
Example:
site:your-domain.example
This can help identify pages indexed from your own domain.
26. Subdomains
One important reconnaissance objective is understanding your own domain's subdomains.
For example:
example.com
│
├── www.example.com
├── app.example.com
├── api.example.com
├── docs.example.com
└── status.example.com
For your own domain, you can investigate DNS records and your organization's documented asset inventory.
Don't blindly enumerate third-party infrastructure.
27. Certificate Transparency
TLS certificates can reveal publicly visible hostname information.
Certificate Transparency logs are designed to provide publicly auditable records of certificates.
For your own domain, they can help identify hostnames that have appeared in certificates.
Conceptually:
Certificate
↓
Hostname
↓
Potential asset
↓
Verify ownership
↓
Assess if authorized
Important:
A hostname appearing in a certificate does not automatically mean you're authorized to test it.
28. Reconnaissance Is About Verification
Suppose you discover:
api.example.com
Don't immediately scan it.
First ask:
Is it ours?
↓
Is it in scope?
↓
What is its purpose?
↓
Is testing permitted?
Then—and only then—perform authorized active testing.
29. Build an Asset Inventory
A professional security assessment should maintain documentation.
Create:
| Asset | Type | IP/Hostname | Source | In Scope? |
|---|---|---|---|---|
| example.com | Website | ______ | DNS | ✅ |
| app.example.com | Web App | ______ | DNS | ✅ |
| api.example.com | API | ______ | Documentation | ? |
| mail.example.com | ______ | MX | ❌ |
The ? is important.
It means:
Unknown — verify before testing.
30. Your First Reconnaissance Notebook
Create a directory:
Linux/macOS
mkdir day10-recon
cd day10-recon
Windows PowerShell
New-Item -ItemType Directory day10-recon
Set-Location day10-recon
Create a notes file.
Linux/macOS
touch recon-notes.txt
Windows
New-Item recon-notes.txt
🧪 Day 10 Main Practical Lab
For maximum safety, use:
Option A — Your own domain
YOUR-DOMAIN
Option B — A deliberately authorized cybersecurity lab
Option C — example.com for basic DNS/HTTP educational demonstrations
For active reconnaissance, prefer your own domain or lab.
Step 1 — DNS
Linux/macOS
dig YOUR-DOMAIN A
dig YOUR-DOMAIN AAAA
dig YOUR-DOMAIN MX
dig YOUR-DOMAIN NS
dig YOUR-DOMAIN TXT
Windows
nslookup -type=A YOUR-DOMAIN
nslookup -type=AAAA YOUR-DOMAIN
nslookup -type=MX YOUR-DOMAIN
nslookup -type=NS YOUR-DOMAIN
nslookup -type=TXT YOUR-DOMAIN
Step 2 — HTTP Headers
Linux/macOS
curl -I https://YOUR-DOMAIN
Windows
curl.exe -I https://YOUR-DOMAIN
Step 3 — DNS Summary
Linux/macOS
dig +short YOUR-DOMAIN
Windows
nslookup YOUR-DOMAIN
Step 4 — Record Your Findings
Create:
Domain:
____________________
IPv4:
____________________
IPv6:
____________________
Nameservers:
____________________
Mail Servers:
____________________
HTTP Status:
____________________
Server Header:
____________________
Security Headers:
____________________
Step 5 — Verify Scope
Before doing anything more active:
Is this asset mine?
↓
Is it authorized?
↓
Is it in scope?
↓
What testing is allowed?
If any answer is unclear:
STOP.
This is an important professional habit.
31. Passive vs Active — Comparison
| Passive Recon | Active Recon |
|---|---|
| Public information | Direct interaction |
| Search engines | HTTP requests |
| Public documentation | DNS queries |
| Public registration data | Port scanning |
| Public certificates | Service enumeration |
| Lower direct interaction | Generates target traffic |
| Still requires ethical/legal consideration | Requires clear authorization |
32. Reconnaissance → Nmap → Wireshark
You now have three important perspectives.
Reconnaissance
What assets exist?
Nmap
What services appear accessible?
Wireshark
What traffic is actually happening?
Together:
Authorized Security Assessment
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Recon Nmap Wireshark
│ │ │
Assets Services Packets
│ │ │
└──────────────┼──────────────┘
↓
Understanding
↓
Risk Analysis
🧠 Day 10 Security Mindset
When you discover something, don't immediately think:
"Can I exploit it?"
Instead ask:
Question 1
What is it?
Question 2
Who owns it?
Question 3
Is it in scope?
Question 4
Why is it exposed?
Question 5
What information does it reveal?
Question 6
Is the exposure necessary?
Question 7
How can it be secured?
This mindset will keep your learning focused on ethical and defensive cybersecurity.
📝 Day 10 Assignment
Answer these questions:
1.
What is reconnaissance?
2.
What is passive reconnaissance?
3.
What is active reconnaissance?
4.
Why is authorization important before active reconnaissance?
5.
What is an attack surface?
6.
What does an A record provide?
7.
What does an MX record provide?
8.
What does an NS record provide?
9.
What is a CNAME?
10.
What is the difference between WHOIS and RDAP conceptually?
11.
What can HTTP response headers tell you?
12.
Why shouldn't a Server header be treated as absolute proof of a backend technology?
13.
Why is an asset inventory important?
14.
If you discover a subdomain that isn't listed in your scope, what should you do?
15.
Why is reconnaissance not simply "finding things to hack"?
🏆 Day 10 Challenge
Choose your own domain or authorized lab.
Build a reconnaissance report:
╔══════════════════════════════╗
║ DAY 10 RECON REPORT ║
╚══════════════════════════════╝
Target:
____________________
Authorization:
____________________
Scope:
____________________
A Records:
____________________
AAAA Records:
____________________
MX Records:
____________________
NS Records:
____________________
TXT Records:
____________________
HTTP Status:
____________________
Security Headers:
____________________
Known Subdomains:
____________________
Technologies:
____________________
Potentially Exposed Assets:
____________________
Out-of-Scope Assets:
____________________
Then write a short conclusion:
"Based on my authorized reconnaissance, I identified ______ assets. The most important information exposed was ______. The main security improvement I would recommend is ______."
🔐 Day 10 Golden Rule
Remember this workflow:
┌──────────────────────┐
│ 1. GET PERMISSION │
└──────────┬───────────┘
↓
┌──────────────────────┐
│ 2. DEFINE SCOPE │
└──────────┬───────────┘
↓
┌──────────────────────┐
│ 3. RECON │
└──────────┬───────────┘
↓
┌──────────────────────┐
│ 4. VERIFY ASSETS │
└──────────┬───────────┘
↓
┌──────────────────────┐
│ 5. TEST │
└──────────┬───────────┘
↓
┌──────────────────────┐
│ 6. DOCUMENT │
└──────────┬───────────┘
↓
┌──────────────────────┐
│ 7. REMEDIATE │
└──────────┬───────────┘
↓
┌──────────────────────┐
│ 8. RETEST │
└──────────────────────┘
⚠️ Ethical Hacking Reminder
LEARNING PURPOSE ONLY: This lesson teaches reconnaissance for authorized cybersecurity assessments. Publicly accessible information is not automatically free to probe or exploit. Use active reconnaissance only when the target and activity are explicitly within your authorization and scope. Never search for, collect, or expose passwords, private data, personal information, or confidential documents.
Permission → Scope → Recon → Verify → Test → Document → Secure
✅ Day 10 Summary
Today you learned:
Reconnaissance
Passive reconnaissance
Active reconnaissance
Attack surface
Scope
Domains
Subdomains
DNS reconnaissance
A records
AAAA records
MX records
NS records
CNAME records
TXT records
WHOIS/RDAP concepts
IP discovery
HTTP headers
Security headers
Technology identification
Metadata
Search-engine reconnaissance
Certificate Transparency concepts
Asset inventories
Linux reconnaissance commands
Windows PowerShell reconnaissance commands
macOS reconnaissance commands
Reconnaissance documentation
🔐 Most Important Lesson
Reconnaissance isn't about collecting as much information as possible. It's about collecting the right information, within the right scope, and using it responsibly.
🔜 Day 11 — Web Application Fundamentals
Tomorrow we'll move from infrastructure reconnaissance to web application security.
We'll learn:
How websites work
Client vs server
HTTP methods
GET vs POST
HTTP headers
Cookies
Sessions
Authentication
Authorization
Status codes
Forms
Parameters
APIs
Browser Developer Tools
Burp Suite introduction
Safe web-security exercises using a deliberately vulnerable local lab
Linux, Windows & macOS practical setup
🔐 LEARN → RECON → ANALYZE → TEST AUTHORIZED SYSTEMS → SECURE.
No comments:
Post a Comment