JS

Application Security Series

3 CHAPTERS33% DONE
Week 1~ 26 min read

Introduction to Ethical Hacking, Reconnaissance, Footprinting, Enumeration & Scanning

Application Security — Chapter 1 / Week 1

📊 View Presentation Slides

Introduction to Ethical Hacking, Reconnaissance, Footprinting, Enumeration & Scanning

1. Disclaimer

Application Security and VAPT involve techniques that can generate traffic, trigger security controls, expose sensitive information, or potentially affect systems.

All practical security testing must be performed only against:

  • Systems you own
  • Systems for which you have explicit written authorization
  • Intentionally vulnerable laboratory environments
  • Systems explicitly included in an organization's testing scope

Examples of suitable training environments include:

  • OWASP Juice Shop
  • DVWA
  • Metasploitable
  • WebGoat
  • Your own web application
  • Your own virtual machines

Never assume that a publicly accessible system is automatically available for testing.

For example:

text
Publicly accessible
        ≠
Authorized to test

A professional penetration tester works within:

text
Authorization
      ↓
Scope
      ↓
Rules of Engagement
      ↓
Testing
      ↓
Evidence
      ↓
Reporting
      ↓
Remediation
      ↓
Retesting

2. What Do People Think When They Hear "Hacker"?

When people hear the word hacker, they often imagine:

  • Someone sitting in a dark room
  • A black screen with green text
  • Extremely fast typing
  • Breaking into systems instantly
  • Stealing passwords
  • Hacking social-media accounts
  • Installing viruses
  • Stealing money

This is largely a Hollywood representation.

The reality is considerably more technical.

A hacker is fundamentally someone who understands how a technology, system, application, or process works and finds ways to manipulate it beyond its intended behavior.

For example, suppose an application is designed like this:

text
Username + Password
        ↓
Authentication
        ↓
Dashboard

A security researcher discovers that changing a particular request allows access to the dashboard without successfully authenticating.

The researcher has discovered a security weakness.

The important distinction is not simply the technique.

It is:

text
Technique + Authorization + Intent + Impact

The same technical knowledge can be used by:

  • A penetration tester
  • A security researcher
  • An application security engineer
  • A red team
  • A malicious attacker

Therefore:

SECURITY_ADVISORY

Hacking knowledge itself is not inherently malicious. How and where that knowledge is applied matters.

3. What Is Hacking?

A useful definition is:

SECURITY_ADVISORY

Hacking is the process of understanding a system and finding ways to make it behave differently from its intended design or security assumptions.

A hacker might investigate:

  • Applications
  • Networks
  • Operating systems
  • APIs
  • Authentication mechanisms
  • Cloud infrastructure
  • Identity systems
  • Databases
  • Hardware
  • AI/ML systems

For Application Security, the primary focus is:

text
Application
     ↓
Requests
     ↓
Processing
     ↓
Authentication
     ↓
Authorization
     ↓
Data
     ↓
Business Logic

The tester asks:

SECURITY_ADVISORY

"Can the application be made to do something it should not allow?"

4. Types of Hackers

The traditional classification divides hackers into three broad categories:

text
                 Hackers
                    |
        +-----------+-----------+
        |           |           |
     White Hat   Grey Hat    Black Hat

4.1 White Hat Hacker

A White Hat hacker is an authorized security professional.

Typical roles include:

  • Penetration Tester
  • VAPT Engineer
  • Application Security Engineer
  • Security Researcher
  • Red Team Operator
  • Security Consultant

The objective is generally defensive:

text
Find weakness
     ↓
Validate weakness
     ↓
Understand impact
     ↓
Report
     ↓
Fix

Example:

A company gives a penetration tester permission to assess:

text
https://app.example.com

from August 1 to August 15.

The tester performs reconnaissance and identifies a vulnerable API endpoint.

The tester documents:

  • Endpoint
  • Vulnerability
  • Reproduction steps
  • Impact
  • Evidence
  • Remediation

This is ethical security testing.

5. Grey Hat Hacker

A Grey Hat hacker generally falls between the traditional White Hat and Black Hat classifications.

A common example is:

text
Researcher discovers vulnerability
             ↓
Tests it without authorization
             ↓
Reports the vulnerability

The researcher may not have malicious intent.

However:

SECURITY_ADVISORY

Good intentions do not automatically make unauthorized security testing acceptable.

Authorization is a fundamental part of professional security testing.

6. Black Hat Hacker

Black Hat hackers perform unauthorized or malicious activities.

Potential objectives include:

  • Financial gain
  • Credential theft
  • Data theft
  • Extortion
  • Espionage
  • Fraud
  • Disruption
  • Ransomware
  • Unauthorized access

A simplified attack chain might look like:

text
Reconnaissance
      ↓
Discovery
      ↓
Initial Access
      ↓
Privilege Escalation
      ↓
Persistence
      ↓
Data Access
      ↓
Impact

The important distinction is:

text
Authorized security testing
              vs
Unauthorized malicious activity

7. What Is Ethical Hacking?

Ethical hacking is:

SECURITY_ADVISORY

Authorized security testing performed to identify, validate, and help remediate security weaknesses.

Three concepts are especially important.

Authorization

You have permission.

Scope

You know what you are allowed to test.

Objective

You understand why the testing is being performed.

For example:

text
Allowed:
api.example.com

Not allowed:
production-database.example.com

Even if both belong to the same organization, the tester must respect the agreed scope.

8. Application Security

Application Security, commonly called AppSec, is the discipline of protecting applications throughout their lifecycle.

It includes:

  • Security requirements
  • Secure architecture
  • Threat modeling
  • Secure coding
  • Code review
  • Dependency security
  • Secrets management
  • Authentication
  • Authorization
  • API security
  • Security testing
  • Vulnerability management
  • Runtime protection
  • Security monitoring

Application Security should not begin when penetration testing starts.

A secure lifecycle looks like:

text
Requirements
     ↓
Architecture
     ↓
Design
     ↓
Development
     ↓
Security Testing
     ↓
Deployment
     ↓
Monitoring
     ↓
Maintenance

Security should be integrated throughout this lifecycle.

9. What Is VAPT?

VAPT stands for:

SECURITY_ADVISORY

Vulnerability Assessment and Penetration Testing.

It combines two related activities.

Vulnerability Assessment

The objective is to:

  • Discover vulnerabilities
  • Identify weaknesses
  • Classify vulnerabilities
  • Prioritize vulnerabilities

For example:

text
Application
     ↓
Security scanner
     ↓
Potential vulnerabilities
     ↓
Validation

Penetration Testing

Penetration testing goes further.

The tester attempts to validate whether a vulnerability is actually exploitable and determines its potential impact, while staying within the authorized scope.

Simplified:

text
Vulnerability
      ↓
Can it be reproduced?
      ↓
Can security impact be demonstrated?
      ↓
How serious is the impact?

10. Application Security vs VAPT

Application Security is much broader than VAPT.

Application SecurityVAPT
Secure architectureReconnaissance
Threat modelingEnumeration
Secure codingScanning
Code reviewVulnerability validation
Dependency managementControlled exploitation
Secrets managementReporting
Security requirementsRetesting
Security monitoringPrimarily assessment-focused

Think of VAPT as one component within the larger AppSec program.

text
                 Application Security
                         |
       +-----------------+----------------+
       |                 |                |
   Secure Design     Secure Code       Security Testing
                                          |
                                         VAPT

11. Traditional Phases of Hacking

A traditional penetration-testing model describes five phases:

text
1. Reconnaissance / Footprinting
             ↓
2. Scanning
             ↓
3. Gaining Access
             ↓
4. Maintaining Access
             ↓
5. Covering Tracks

Let's understand each.

12. Phase 1 — Reconnaissance / Footprinting

Reconnaissance is the process of collecting information about a target.

The objective is to understand the target before performing deeper testing.

Questions include:

  • What domains exist?
  • What subdomains exist?
  • What IP addresses are associated with the organization?
  • What technologies are being used?
  • Which services are exposed?
  • What web applications exist?
  • Is there a WAF?
  • Are there public repositories?
  • What public information exists?

The output of reconnaissance should be an attack-surface map.

13. Passive Reconnaissance

Passive reconnaissance attempts to collect information without directly interacting with the target infrastructure, where practical.

Examples:

  • Search engines
  • WHOIS/RDAP
  • Certificate Transparency logs
  • Public GitHub repositories
  • Public documentation
  • Public DNS information
  • Publicly available organizational information

Example:

text
Search Engine
      ↓
Publicly indexed information
      ↓
Security intelligence

Advantages:

  • Less likely to trigger target alerts
  • Useful for initial intelligence gathering
  • Can reveal information before active testing begins

14. Active Reconnaissance

Active reconnaissance involves directly interacting with the target.

Examples:

  • DNS queries
  • HTTP requests
  • Port scans
  • Technology fingerprinting
  • Directory enumeration
  • Service enumeration

Example:

text
Security Tester
       ↓
HTTP Request
       ↓
Target
       ↓
HTTP Response

Because traffic is generated, active reconnaissance may be:

  • Logged
  • Detected
  • Rate-limited
  • Blocked
  • Alerted on

Therefore, authorization and scope are critical.

15. Understanding Domains

Suppose the organization has:

text
example.com

A domain may have many subdomains:

text
example.com
│
├── www.example.com
├── api.example.com
├── mail.example.com
├── dev.example.com
├── staging.example.com
├── admin.example.com
└── vpn.example.com

Each host may represent a different application or infrastructure component.

For example:

text
www.example.com
       ↓
Main website

api.example.com
       ↓
REST API

admin.example.com
       ↓
Administrative portal

dev.example.com
       ↓
Development environment

This is why subdomain enumeration is important.

16. Domain vs Subdomain

Consider:

text
api.example.com

Conceptually:

text
api        .       example       .       com
│                   │                     │
host             domain                  TLD

Examples:

text
www.example.com
api.example.com
mail.example.com
dev.example.com
staging.example.com

A security tester should not assume that every subdomain is equally secure.

Development and forgotten systems can sometimes have weaker security controls.

17. DNS — Domain Name System

DNS translates domain names into information used to locate network services.

Simplified:

text
www.example.com
       ↓
      DNS
       ↓
93.184.216.x

Without DNS, users would generally need to remember IP addresses instead of domain names.

18. Important DNS Record Types

A Record

Maps a hostname to an IPv4 address.

text
example.com → 93.184.216.x

Command:

bash
dig example.com A

AAAA Record

Maps a hostname to an IPv6 address.

bash
dig example.com AAAA

MX Record

Identifies mail servers.

bash
dig example.com MX

Example:

text
example.com
      ↓
Mail server
      ↓
mail.example.com

NS Record

Identifies authoritative name servers.

bash
dig example.com NS

TXT Record

Contains text associated with a DNS name.

It can be used for legitimate purposes such as:

  • SPF
  • Domain verification
  • Email-related configuration

Command:

bash
dig example.com TXT

CNAME Record

Provides an alias to another hostname.

Example:

text
api.example.com
       ↓
CNAME
       ↓
api.provider.example

SOA Record

Provides information about the authoritative DNS zone.

bash
dig example.com SOA

PTR Record

Used for reverse DNS.

bash
dig -x 93.184.216.x

19. DNS Enumeration Using dig

dig is one of the most useful DNS troubleshooting and enumeration tools.

Basic:

bash
dig example.com

A record:

bash
dig example.com A

AAAA:

bash
dig example.com AAAA

MX:

bash
dig example.com MX

NS:

bash
dig example.com NS

TXT:

bash
dig example.com TXT

SOA:

bash
dig example.com SOA

Reverse DNS:

bash
dig -x 93.184.216.x

The important principle is not memorizing commands.

Ask:

SECURITY_ADVISORY

What question am I trying to answer?

20. host

host is another DNS lookup utility.

bash
host example.com

MX:

bash
host -t MX example.com

NS:

bash
host -t NS example.com

A record:

bash
host -t A example.com

21. nslookup

Another common DNS tool is nslookup.

bash
nslookup example.com

Specific record:

bash
nslookup -type=MX example.com

TXT:

bash
nslookup -type=TXT example.com

22. WHOIS and RDAP

WHOIS traditionally provides registration information about domains and IP addresses.

Command:

bash
whois example.com

Depending on the registry and privacy settings, information may include:

  • Registrar
  • Creation date
  • Expiration date
  • Name servers
  • Domain status
  • Registry information

Modern domain-registration ecosystems increasingly use RDAP.

Privacy/proxy services can hide registrant information.

The purpose of this activity is to understand ownership and infrastructure context, not to identify private individuals.

23. IP Enumeration

Suppose:

bash
dig example.com A

returns:

text
93.184.216.x

You can investigate the IP:

bash
whois 93.184.216.x

Reverse DNS:

bash
dig -x 93.184.216.x

Conceptually:

text
Domain
  ↓
DNS
  ↓
IP Address
  ↓
Network / Hosting
  ↓
Services

This helps build an infrastructure picture.

24. Subdomain Enumeration

Subdomain enumeration attempts to identify subdomains associated with a domain.

For example:

text
example.com
     |
     +-- www
     +-- api
     +-- dev
     +-- staging
     +-- admin
     +-- mail

Possible sources include:

  • DNS
  • Certificate Transparency
  • Search engines
  • Public datasets
  • Passive DNS
  • Public code repositories

25. Subfinder

Subfinder is a popular passive subdomain discovery tool.

Basic:

bash
subfinder -d example.com

Silent output:

bash
subfinder -d example.com -silent

Save output:

bash
subfinder -d example.com -silent -o subdomains.txt

Example output:

text
www.example.com
api.example.com
dev.example.com
staging.example.com

The output should be treated as potentially discovered assets, not automatically confirmed live systems.

26. Amass

OWASP Amass can also perform domain reconnaissance.

Passive enumeration:

bash
amass enum -passive -d example.com

Save results:

bash
amass enum -passive -d example.com -o amass.txt

A mature reconnaissance process can combine multiple sources:

text
Subfinder
    +
Amass
    +
Certificate Transparency
    +
Search Engines
    +
DNS
    ↓
Candidate Assets

Then the candidate list can be validated.

27. Certificate Transparency

Certificate Transparency, or CT, is designed to make publicly trusted TLS certificates auditable.

Public CT logs can sometimes reveal hostnames.

For example, a certificate associated with:

text
*.example.com

may help reveal:

text
api.example.com
dev.example.com
staging.example.com

A commonly used public interface is:

text
crt.sh

Searching for:

text
%.example.com

can reveal certificate-related hostnames.

This is a useful example of passive reconnaissance.

28. Live Host Discovery

Finding a subdomain does not necessarily mean that the host is currently serving an application.

For example:

text
dev.example.com

could:

  • Be online
  • Redirect elsewhere
  • Return 403
  • Return 404
  • Be inactive
  • Be behind a WAF
  • Use HTTPS only

Therefore we need validation.

29. httpx

ProjectDiscovery's httpx can help identify HTTP/HTTPS services.

Suppose:

text
subdomains.txt

contains:

text
api.example.com
dev.example.com
staging.example.com

Run:

bash
httpx -l subdomains.txt

You can gather additional information:

bash
httpx -l subdomains.txt -status-code -title -tech-detect

Conceptually:

text
Hostname
   ↓
HTTP/HTTPS request
   ↓
Status
   ↓
Title
   ↓
Technology

Example conceptual output:

text
https://api.example.com    200    API
https://dev.example.com    403    Development
https://staging.example.com 200   Staging

30. Technology Enumeration

Technology enumeration identifies technologies used by an application.

Possible technologies include:

text
Nginx
Apache
IIS
React
Angular
Vue
WordPress
PHP
Node.js
Django
Spring
Laravel

Why does this matter?

Because technology information helps define what should be investigated next.

For example:

text
Technology identified
        ↓
Version identified
        ↓
Security research
        ↓
Relevant testing

Technology fingerprinting should not be treated as absolute proof.

31. WhatWeb

WhatWeb is a technology fingerprinting tool.

Basic:

bash
whatweb https://example.com

More aggressive fingerprinting:

bash
whatweb -a 3 https://example.com

Potentially identified information:

text
Web server
Framework
CMS
JavaScript technologies
Libraries
Headers

32. HTTP Headers

HTTP headers can reveal useful information about application behavior and security controls.

Command:

bash
curl -I https://example.com

Example:

text
HTTP/2 200
server: nginx
content-type: text/html
strict-transport-security: ...
content-security-policy: ...
x-frame-options: ...

Important security headers include:

Content-Security-Policy

Helps control which resources a browser is allowed to load.

Strict-Transport-Security

Helps enforce HTTPS.

X-Frame-Options

Helps control framing behavior.

X-Content-Type-Options

Helps prevent certain MIME-sniffing behavior.

Referrer-Policy

Controls referrer information sent by browsers.

Permissions-Policy

Controls access to certain browser features.

33. WAF Detection

A WAF is a:

SECURITY_ADVISORY

Web Application Firewall.

Conceptually:

text
Client
   ↓
Internet
   ↓
WAF
   ↓
Application

A WAF may inspect HTTP requests and block or challenge suspicious traffic.

Examples include:

  • Cloudflare
  • AWS WAF
  • Akamai
  • Imperva
  • F5

WAF detection is useful because it tells the tester that an additional security control exists between the tester and application.

34. WAFW00F

WAFW00F is commonly used to fingerprint web application firewalls.

Command:

bash
wafw00f https://example.com

A result might indicate that a recognizable WAF is present.

However:

SECURITY_ADVISORY

WAF fingerprinting does not guarantee exactly how the WAF will behave against every request.

It is a technology identification step.

35. Search Engine Reconnaissance

Search engines can contain a surprising amount of publicly available information.

Examples:

text
site:example.com

This limits results to a particular domain.

Search for login pages:

text
site:example.com inurl:login

Search for administrative pages:

text
site:example.com inurl:admin

Search for PDFs:

text
site:example.com filetype:pdf

Search for text files:

text
site:example.com filetype:txt

Search for specific words:

text
site:example.com "staging"

36. Google Dorking

Google Dorking refers to using advanced search operators to find specific information indexed by search engines.

Common operators:

text
site:
inurl:
intitle:
filetype:

Examples:

text
site:example.com
text
site:example.com inurl:login
text
site:example.com filetype:pdf
text
site:example.com intitle:"login"

The security objective is to understand what information an organization has unintentionally exposed through public indexing.

37. GitHub Reconnaissance

Public code repositories can reveal useful information about an application's architecture.

Potential information includes:

  • API endpoints
  • Domain names
  • Subdomains
  • Frameworks
  • CI/CD configuration
  • Cloud resources
  • Infrastructure-as-code
  • Application structure
  • Development environments

For example, a repository might contain:

text
api.example.com
staging.example.com

This can help identify assets that were not obvious from the main website.

38. Secrets in Source Code

Developers must never commit:

text
Passwords
API keys
Cloud credentials
Private keys
Database credentials
Access tokens
Session secrets

For defensive secret detection, tools such as Gitleaks can be used.

Example:

bash
gitleaks detect

Important distinction:

text
Finding an exposed secret
          ≠
Using the secret

Security professionals should follow the authorization and disclosure requirements of the engagement.

39. Directory and File Enumeration

Web applications can expose many paths.

For example:

text
https://example.com/

/
├── index.html
├── login
├── admin
├── api
├── docs
├── uploads
└── static

Some of these paths may not appear in normal website navigation.

Directory enumeration attempts to identify accessible paths.

The goal is:

SECURITY_ADVISORY

Build an accurate map of the web application's exposed surface.

40. Gobuster

Gobuster can perform directory discovery against an authorized lab.

Example:

bash
gobuster dir \
-u http://192.168.56.101 \
-w /usr/share/wordlists/dirb/common.txt

Possible output:

text
/login
/admin
/api
/docs
/uploads

You can also test common extensions:

bash
gobuster dir \
-u http://192.168.56.101 \
-w /usr/share/wordlists/dirb/common.txt \
-x php,txt,html

The wordlist provides candidate names.

Conceptually:

text
Wordlist
   ↓
login
admin
api
docs
uploads
   ↓
HTTP requests
   ↓
Response analysis

41. FFUF

FFUF is another web fuzzing and discovery tool.

Example against a local lab:

bash
ffuf \
-u http://192.168.56.101/FUZZ \
-w /usr/share/wordlists/dirb/common.txt

The important component is:

text
FUZZ

FFUF replaces FUZZ with values from the wordlist.

Conceptually:

text
/FUZZ
 ↓
/admin
/login
/api
/docs
/test

The tester then analyzes:

  • HTTP status code
  • Response size
  • Redirects
  • Page content

42. Scanning

After reconnaissance, we move toward scanning.

Recon answers:

SECURITY_ADVISORY

What exists?

Scanning helps answer:

SECURITY_ADVISORY

What services are exposed?

A simplified process:

text
Reconnaissance
      ↓
Assets discovered
      ↓
Scanning
      ↓
Ports
      ↓
Services
      ↓
Versions

43. Understanding Ports

An IP address can be compared to a building.

text
IP Address = Building
Port = Door
Service = Application behind the door

Examples:

PortCommon Service
21FTP
22SSH
23Telnet
25SMTP
53DNS
80HTTP
110POP3
143IMAP
443HTTPS
3306MySQL
3389RDP
5432PostgreSQL
6379Redis
8080Common alternate HTTP
8443Common alternate HTTPS

These are common associations, not guarantees.

A service can run on a non-standard port.

44. Nmap

Nmap stands for:

SECURITY_ADVISORY

Network Mapper.

It is widely used for network discovery and service enumeration.

Basic scan:

bash
nmap 192.168.56.101

Example:

text
PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   open     http
443/tcp  open     https

This tells us:

  • Port number
  • Whether it is open
  • Likely service

45. Specific Port Scanning

One port:

bash
nmap -p 80 192.168.56.101

Multiple ports:

bash
nmap -p 22,80,443 192.168.56.101

Port range:

bash
nmap -p 1-1000 192.168.56.101

All TCP ports:

bash
nmap -p- 192.168.56.101

Only perform broad scans against authorized targets.

46. Service Version Detection

Knowing that port 80 is open is useful.

Knowing what is actually running there is more useful.

Use:

bash
nmap -sV 192.168.56.101

Example:

text
PORT     STATE   SERVICE VERSION
22/tcp   open    ssh     OpenSSH
80/tcp   open    http    nginx
443/tcp  open    https   nginx

Now we have:

text
Port
 ↓
Service
 ↓
Version

Version information can help security teams identify outdated or unsupported software.

47. Nmap Default Scripts

Nmap has a scripting engine that can perform additional discovery and checks.

Default scripts:

bash
nmap -sC 192.168.56.101

Combine scripts with service detection:

bash
nmap -sC -sV 192.168.56.101

This is a useful general-purpose scan for an authorized lab.

48. Operating System Detection

Nmap can attempt OS fingerprinting.

bash
sudo nmap -O 192.168.56.101

The result is an inference based on network characteristics.

It may identify something like:

text
Linux
Windows
Network appliance

OS detection is not always accurate.

Therefore:

SECURITY_ADVISORY

Treat fingerprinting results as evidence, not absolute truth.

49. Saving Nmap Results

Security testing should be documented.

Normal output:

bash
nmap 192.168.56.101 -oN scan.txt

XML:

bash
nmap 192.168.56.101 -oX scan.xml

Multiple formats:

bash
nmap 192.168.56.101 -oA nmap_scan

This is useful for:

  • Reporting
  • Evidence
  • Comparing scans
  • Retesting
  • Automation

50. Complete Reconnaissance Workflow

A professional reconnaissance workflow can look like this:

text
                     TARGET
                        |
                        ↓
               Passive Recon
                        |
        +---------------+---------------+
        |               |               |
     Search          WHOIS/RDAP       CT Logs
     Engines
        |               |               |
        +---------------+---------------+
                        |
                        ↓
                 DNS Enumeration
                        |
                        ↓
              Subdomain Enumeration
                        |
                        ↓
                  IP Enumeration
                        |
                        ↓
                Live Host Discovery
                        |
                        ↓
              Technology Enumeration
                        |
                        ↓
                   WAF Detection
                        |
                        ↓
              Directory Enumeration
                        |
                        ↓
                  Port Scanning
                        |
                        ↓
                Service Enumeration
                        |
                        ↓
                 Attack Surface

51. Why Reconnaissance Matters

Imagine starting a penetration test without reconnaissance.

You might not know:

  • What applications exist
  • What APIs exist
  • What domains exist
  • What subdomains exist
  • Which systems are live
  • Which technologies are deployed
  • Which services are exposed

Reconnaissance gives structure to the assessment.

Instead of:

text
Random testing

you move toward:

text
Known attack surface
        ↓
Risk-based testing
        ↓
Focused security assessment

52. The Most Important Mindset

Do not teach students to memorize hundreds of Kali Linux commands.

Teach them to ask:

SECURITY_ADVISORY

What security question am I trying to answer?

For example:

dig

bash
dig example.com

Question:

SECURITY_ADVISORY

What DNS information does this domain expose?

subfinder

bash
subfinder -d example.com

Question:

SECURITY_ADVISORY

What subdomains can I discover?

httpx

bash
httpx -l subdomains.txt

Question:

SECURITY_ADVISORY

Which discovered hosts appear to expose HTTP/HTTPS?

whatweb

bash
whatweb https://example.com

Question:

SECURITY_ADVISORY

What technologies appear to be running?

wafw00f

bash
wafw00f https://example.com

Question:

SECURITY_ADVISORY

Is there an identifiable WAF?

gobuster

bash
gobuster dir -u http://TARGET -w WORDLIST

Question:

SECURITY_ADVISORY

What web paths are exposed?

nmap

bash
nmap -sV TARGET

Question:

SECURITY_ADVISORY

What network services are exposed and what versions appear to be running?

This is the mindset of a security engineer.

53. Week 1 Practical Lab

Use:

text
Kali Linux
     |
     ↓
Authorized Lab
     |
     ├── OWASP Juice Shop
     ├── DVWA
     ├── Metasploitable
     └── Your own application

Exercise 1 — DNS

bash
dig TARGET

Then:

bash
dig TARGET A
dig TARGET MX
dig TARGET NS
dig TARGET TXT

Students should document:

text
A records:
MX records:
NS records:
TXT records:

54. Exercise 2 — Subdomain Discovery

bash
subfinder -d TARGET -silent -o subdomains.txt

Students should identify:

text
Number of discovered subdomains:
Interesting hosts:
Development hosts:
Staging hosts:
API hosts:

55. Exercise 3 — HTTP Discovery

bash
httpx -l subdomains.txt \
-status-code \
-title \
-tech-detect

Create an inventory:

text
Host              Status      Title       Technology
-----------------------------------------------------
api.example.com   200         API         nginx
dev.example.com   403         Forbidden   Apache
www.example.com   200         Home        Cloudflare

56. Exercise 4 — Technology Identification

bash
whatweb https://TARGET

Record:

text
Web server:
Framework:
CMS:
Programming technology:
JavaScript technology:
Other findings:

57. Exercise 5 — HTTP Headers

bash
curl -I https://TARGET

Check whether the application returns:

text
Content-Security-Policy
Strict-Transport-Security
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Permissions-Policy

Do not immediately call the absence of a header a vulnerability.

First understand:

  • Application architecture
  • Browser behavior
  • Context
  • Whether the control is applicable
  • Business impact

58. Exercise 6 — WAF Detection

bash
wafw00f https://TARGET

Record:

text
WAF detected:
Technology:
Evidence:
Confidence:

59. Exercise 7 — Directory Enumeration

Against a lab:

bash
gobuster dir \
-u http://192.168.56.101 \
-w /usr/share/wordlists/dirb/common.txt

Students should record:

text
Path
Status
Interesting?
Authentication required?
Potential security significance?

60. Exercise 8 — Nmap

Basic:

bash
nmap TARGET

All TCP ports:

bash
nmap -p- TARGET

Service detection:

bash
nmap -sV TARGET

Default scripts:

bash
nmap -sC TARGET

Combined:

bash
nmap -sC -sV TARGET

Save:

bash
nmap -sC -sV TARGET -oA week1_scan

Students should document:

text
Open ports:
Services:
Versions:
Potentially unnecessary exposure:
Interesting services:

61. Week 1 Recon Report Template

Students should finish the week with a small reconnaissance report.

Target

text
Target:
Scope:
Testing dates:
Tester:
Authorization:

Domain Information

text
Primary domain:
Registrar:
Name servers:
Mail servers:

DNS

text
A:
AAAA:
MX:
NS:
TXT:

Subdomains

text
Subdomain:
IP:
Status:
Technology:

Web Applications

text
URL:
Status:
Title:
Technology:
WAF:

Directory Discovery

text
Path:
Status:
Authentication:
Notes:

Network Services

text
Port:
Protocol:
Service:
Version:
Notes:

Attack Surface Summary

text
Total domains:
Total subdomains:
Live web hosts:
Technologies:
Open ports:
Interesting services:

62. Important Questions Students Should Ask

During reconnaissance, students should continuously ask:

Asset questions

  • What assets exist?
  • Which assets are internet-facing?
  • Which assets are internal?
  • Which assets appear forgotten?

DNS questions

  • What DNS records exist?
  • What IP addresses are associated with the target?
  • Are there interesting subdomains?
  • Are there development or staging hosts?

Web questions

  • What applications exist?
  • What technologies are being used?
  • Is authentication present?
  • Is a WAF present?
  • What HTTP headers are returned?

Network questions

  • Which ports are open?
  • What services are running?
  • What versions are detected?
  • Are unnecessary services exposed?

63. Common Beginner Mistakes

Mistake 1 — Running tools without understanding them

Bad approach:

text
Run Nmap
Run Gobuster
Run Nikto
Run everything

Better:

text
Question
   ↓
Tool
   ↓
Evidence
   ↓
Interpretation

Mistake 2 — Assuming every finding is a vulnerability

For example:

text
Port 22 is open

does not automatically mean:

text
Vulnerability

It means:

text
SSH service is exposed

You need context.

Mistake 3 — Treating technology detection as certainty

If WhatWeb reports:

text
Apache

that is evidence of fingerprinting, not absolute proof of every backend component.

Validate findings.

Mistake 4 — Scanning without authorization

Never use:

text
"Let's scan it because it is public."

Instead:

text
Is it in scope?
       ↓
Do I have authorization?
       ↓
What testing is permitted?

Mistake 5 — Ignoring documentation

A professional tester records:

text
Command
Time
Target
Result
Evidence
Interpretation

This makes the assessment reproducible.

64. Week 1 Command Cheat Sheet

DNS

bash
dig example.com
dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com NS
dig example.com TXT
dig example.com SOA
dig -x IP

DNS Alternatives

bash
host example.com
host -t MX example.com

nslookup example.com
nslookup -type=MX example.com

WHOIS

bash
whois example.com

Subdomains

bash
subfinder -d example.com
subfinder -d example.com -silent -o subdomains.txt
amass enum -passive -d example.com

HTTP

bash
httpx -l subdomains.txt
httpx -l subdomains.txt -status-code -title -tech-detect

Technology

bash
whatweb https://example.com

HTTP Headers

bash
curl -I https://example.com

WAF

bash
wafw00f https://example.com

Directory Enumeration

bash
gobuster dir -u http://TARGET -w WORDLIST
bash
ffuf -u http://TARGET/FUZZ -w WORDLIST

Nmap

bash
nmap TARGET
nmap -p 80 TARGET
nmap -p 22,80,443 TARGET
nmap -p 1-1000 TARGET
nmap -p- TARGET
nmap -sV TARGET
nmap -sC TARGET
nmap -sC -sV TARGET
sudo nmap -O TARGET
nmap TARGET -oN scan.txt
nmap TARGET -oA scan

65. Final Mental Model

The entire chapter can be remembered using this model:

text
                    TARGET
                       |
                       ↓
               RECONNAISSANCE
                       |
              What exists?
                       ↓
                 ENUMERATION
                       |
            What can I discover?
                       ↓
                   SCANNING
                       |
           What is exposed?
                       ↓
                IDENTIFICATION
                       |
         What technologies/services?
                       ↓
                ATTACK SURFACE
                       |
                       ↓
             VULNERABILITY TESTING
                       |
                       ↓
                 VALIDATION
                       |
                       ↓
                    IMPACT
                       |
                       ↓
                   REPORTING
                       |
                       ↓
                 REMEDIATION

The key principle is:

SECURITY_ADVISORY

Reconnaissance is not about "hacking the target." It is about building an accurate understanding of the target's attack surface.

And the most important professional mindset is:

SECURITY_ADVISORY

Every command should answer a question, every finding should be validated, and every action should remain within authorization and scope.

66. What Students Should Know After Week 1

By the end of Week 1, a student should be able to explain:

Fundamentals

  • What hacking means
  • White Hat vs Grey Hat vs Black Hat
  • Ethical hacking
  • Application Security
  • VAPT
  • Difference between vulnerability assessment and penetration testing

Reconnaissance

  • Passive reconnaissance
  • Active reconnaissance
  • Domain enumeration
  • Subdomain enumeration
  • DNS enumeration
  • IP enumeration
  • WHOIS/RDAP
  • Certificate Transparency
  • Search-engine reconnaissance
  • GitHub reconnaissance

Web Enumeration

  • HTTP headers
  • Technology fingerprinting
  • WAF detection
  • Directory enumeration
  • File enumeration
  • Live-host discovery

Network Scanning

  • IP addresses
  • Ports
  • Services
  • Port states
  • Nmap
  • Service/version detection
  • OS fingerprinting
  • Nmap scripts
  • Saving scan results

Professional Practice

Most importantly, students should understand:

text
Authorization
      +
Scope
      +
Methodology
      +
Evidence
      +
Risk Analysis
      +
Reporting

That is the foundation of professional Application Security and VAPT.

Janmejaya Swain's Blog — Security Research & Logs