Loading learning content...
Reconnaissance is the first phase of nearly every cyber attack. Before exploitation comes intelligence gathering—attackers scan your ports, map your network, probe your vulnerabilities, and research your organization. Detection and prevention of reconnaissance provides the earliest possible warning and the opportunity to disrupt attacks before they progress.
Unlike attack detection, which focuses on exploitation attempts, reconnaissance detection catches adversaries during their planning phase. This is both easier (reconnaissance is inherently noisy) and harder (legitimate security scanning looks identical to malicious reconnaissance) than you might expect.
This page provides comprehensive coverage of detecting and preventing reconnaissance: the technologies, techniques, and strategies that give defenders visibility into early-stage attack preparation.
By mastering this page, you will: (1) Understand the principles of reconnaissance detection, (2) Implement network-based and host-based detection strategies, (3) Deploy deception technologies effectively, (4) Apply preventive controls that limit reconnaissance success, and (5) Design detection and prevention programs that balance security with operational needs.
Detecting reconnaissance is inherently challenging. Unlike attacks that produce immediate effects (failed logins, malware execution), reconnaissance activities look similar to legitimate network traffic.
The fundamental tension:
These are technically identical. A SYN scan from your security team looks exactly like a SYN scan from an adversary. This creates two paths:
Detection strategy requirements:
| Requirement | Why It Matters |
|---|---|
| Baseline understanding | Know normal traffic to spot anomalies |
| Authorized scanning whitelist | Distinguish internal scans from attacks |
| Multi-source correlation | Single events mean nothing; patterns matter |
| Response integration | Detection without response is just observation |
| False positive tolerance | Too many alerts lead to alert fatigue |
Port scans happen constantly on internet-facing systems—often thousands per day from bots, researchers, and attackers alike. Alerting on every scan causes analyst fatigue and buried real threats. Effective detection focuses on significant, targeted, or unusual reconnaissance.
Network-based detection examines traffic flows to identify reconnaissance patterns. This provides visibility regardless of endpoint security.
Detection technologies:
| Technology | What It Sees | Reconnaissance Detection Capability |
|---|---|---|
| Firewall Logs | Blocked connections, allowed traffic summaries | Connection attempts to blocked ports, rate anomalies |
| IDS/IPS Signatures | Packet payloads matching known patterns | Known scan tools (nmap fingerprints), exploit attempts |
| NetFlow/IPFIX | Connection metadata (source, dest, bytes, duration) | Scan patterns, unusual port access, timing analysis |
| Network TAP/SPAN | Full packet capture | Deep analysis, payload inspection, anomaly detection |
| DNS Monitoring | DNS queries and responses | Subdomain enumeration, domain reconnaissance |
| Proxy Logs | HTTP/HTTPS requests | Web enumeration, directory brute forcing |
IDS/IPS signatures for reconnaissance:
Intrusion detection systems maintain signatures for common reconnaissance activity:
# Snort/Suricata signature examples
# Detect nmap TCP SYN scan
alert tcp any any -> $HOME_NET any (
msg:"SCAN nmap SYN scan";
flags:S,12;
threshold:type both, track by_src, count 20, seconds 5;
sid:10001;
rev:1;
)
# Detect nmap version detection
alert tcp any any -> $HOME_NET any (
msg:"SCAN nmap version detection";
content:"|00 00 00 00 00|"; depth:5;
sid:10002;
rev:1;
)
# Detect high port access rate (likely scan)
alert tcp any any -> $HOME_NET any (
msg:"SCAN high port rate";
flags:S;
threshold:type both, track by_src, count 100, seconds 60;
sid:10003;
rev:1;
)
NetFlow excels at detecting scans at scale. Look for: high distinct destination ports from single source, many unique destinations in short time, connection durations of 0-1 seconds (probes without data), and high RST or ICMP unreachable rates.
Host-based detection monitors individual systems for signs of reconnaissance attempts. This catches activity that might not cross network detection points.
Host-based detection sources:
123456789101112131415161718192021
# Linux: Monitor connections with iptables loggingiptables -A INPUT -j LOG --log-prefix "INCOMING: " --log-level 7 # Watch live connections (detect scan timing)watch -n 0.5 'ss -tn | grep ESTAB' # Audit failed authenticationgrep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn # Web server reconnaissance detection (Apache/Nginx)# Look for: # - Sequential requests to paths like /admin, /login, /wp-admin# - 404/403 bursts from single IP# - Unusual User-Agents (sqlmap, nikto, dirbuster) # Example log analysisgrep " 404 " access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20 # Windows Event Log - Security (failed logins)# Event ID 4625 (failed logon)# Event ID 4648 (explicit credential use)Endpoint Detection and Response (EDR):
Modern EDR solutions detect reconnaissance at the endpoint level:
| Detection | Behavior Monitored |
|---|---|
| Network discovery | Running ipconfig, arp, netstat, ping sweeps |
| Account enumeration | Queries to domain controllers for users |
| Internal scanning | Port scanning from inside the network |
| Defense evasion | Attempts to disable logging or monitoring |
Detecting internal reconnaissance (after initial access) is often more valuable than detecting external scanning. An attacker running nmap from inside your network is far more concerning than one probing from the internet—they're already past your perimeter.
Deception is one of the most effective reconnaissance detection strategies. By deploying fake assets that have no legitimate purpose, any interaction becomes a high-fidelity alert.
The principle:
Legitimate users and systems never interact with honeypots. Attackers conducting reconnaissance inevitably probe them. This creates nearly zero false positives.
| Type | Description | Detection Value |
|---|---|---|
| Honeypot | Fake vulnerable system | High-fidelity alert on any interaction |
| Honeynet | Network of honeypots | Extensive attack intelligence |
| Honey Token | Fake credential or document | Alerts when accessed/used |
| Honey Port | Listening port with no service | Detects port scans that touch it |
| Honey Service | Fake service returning controlled data | Tracks attacker interaction |
| Honey DNS | Fake DNS records | Detects DNS enumeration |
Implementation strategies:
Low-interaction honeypots:
# Simple port listener that logs connections
nc -nlvk 22 | while read line; do
echo "$(date) HONEYPOT: $line" >> /var/log/honeypot.log
done
# Honeyd - emulate multiple systems
honeyd -d -p nmap.prints -f honeyd.conf
High-interaction honeypots:
Honey tokens:
# Fake AWS credentials in code repository
AWS_ACCESS_KEY_ID=AKIA_HONEYCREDS_DETECT
AWS_SECRET_ACCESS_KEY=FAKE_KEY_TRIGGERS_ALERT
# Fake documents with tracking
Confidential_Merger_Plans.pdf (contains web beacon)
# Fake internal URLs in robots.txt
Disallow: /super-secret-admin-panel/
Place honeypots where attackers would naturally look: (1) Unused IP addresses in real subnets, (2) Common service ports (22, 80, 443, 3389), (3) Attractive hostnames (admin, backup, finance), (4) Near high-value systems. Any touch becomes a critical alert.
While complete prevention of reconnaissance is impossible, defense-in-depth controls can significantly limit what attackers learn and make reconnaissance more detectable.
Network-level prevention:
1234567891011121314151617181920212223242526
# iptables: Rate limit new connections (slow scanning)iptables -A INPUT -p tcp --syn -m limit --limit 10/minute --limit-burst 20 -j ACCEPTiptables -A INPUT -p tcp --syn -j DROP # iptables: Log and drop suspicious port probesiptables -A INPUT -p tcp -m multiport --dports 23,135,445,3389 \ -j LOG --log-prefix "SUSPICIOUS_PORT: "iptables -A INPUT -p tcp -m multiport --dports 23,135,445,3389 -j DROP # SSH: Customize banner (hide version)# In /etc/ssh/sshd_config:# DebianBanner no# Banner /etc/ssh/custom_banner # Nginx: Hide versionserver_tokens off; # Apache: Hide versionServerTokens ProdServerSignature Off # Fail2Ban: Block after failed attempts[sshd]enabled = truemaxretry = 3bantime = 3600Stealth vs. Reject filtering:
| Approach | Closed Port Response | Attacker Perception |
|---|---|---|
| Standard | TCP RST or ICMP unreachable | Port exists but nothing listening |
| Stealth (DROP) | No response | Port state unknown, scan timeout required |
| Reject (REJECT) | ICMP admin prohibited | Port filtered by firewall |
Tradeoff: Stealth filtering slows attackers (they must wait for timeout) but may cause issues for legitimate connections debugging problems.
Hiding version banners and dropping packets are defensive layers, not solutions. A determined attacker with time will fingerprint services through behavior. Prevention controls buy time and raise the bar—they don't eliminate the need for patching and proper security.
DNS and web assets are prime reconnaissance targets. Specific controls minimize information leakage from these vectors.
DNS security controls:
| Threat | Control | Implementation |
|---|---|---|
| Zone transfers | Restrict AXFR | Allow only to legitimate secondaries |
| DNS enumeration | Rate limiting | Response Rate Limiting (RRL) |
| Internal resolutions | Split DNS | Separate internal/external views |
| Subdomain discovery | Certificate management | Don't include internal names in public certs |
| ANY queries (recon) | Block ANY | Many servers now refuse ANY queries |
123456789101112131415161718192021222324
# BIND: Restrict zone transferszone "example.com" { type master; file "example.com.zone"; allow-transfer { 10.0.0.2; 10.0.0.3; }; # Only specific secondaries}; # BIND: Enable Response Rate Limitingoptions { rate-limit { responses-per-second 10; window 5; };}; # BIND: Split DNS (internal vs external)view "internal" { match-clients { 10.0.0.0/8; }; zone "example.com" { file "example.com.internal"; };};view "external" { match-clients { any; }; zone "example.com" { file "example.com.external"; };};Web application prevention:
| Attack Vector | Prevention Measure |
|---|---|
| Directory enumeration | Consistent 404 responses (no info leak) |
| Path discovery | Block common scanner paths, monitor for patterns |
| Error messages | Generic errors, no stack traces in production |
| robots.txt abuse | Don't list sensitive paths (attackers check it first) |
| Source code comments | Strip comments from production code |
| HTTP headers | Remove X-Powered-By, Server version headers |
| Technology fingerprinting | Customize default pages, error pages |
robots.txt tells search engines what NOT to index—but attackers read it as a map of interesting paths. Don't list sensitive directories; instead protect them with authentication regardless of whether they're in robots.txt.
Signature-based detection catches known tools but misses novel or customized reconnaissance. Behavioral detection identifies anomalies that suggest reconnaissance regardless of specific tools used.
Behavioral indicators of reconnaissance:
Machine learning approaches:
ML-based detection learns normal behavior and flags deviations:
| Technique | What It Learns | What It Detects |
|---|---|---|
| Clustering | Groups of similar traffic patterns | Outliers that don't fit normal clusters |
| Time series analysis | Normal traffic rhythms | Unusual spikes or patterns |
| Graph analysis | Normal communication relationships | New or unusual connections |
| Statistical modeling | Baseline distributions | Statistically improbable events |
Implementation considerations:
SIEM platforms enable multi-source detection rules: 'Alert when source IP hits >50 unique ports across >5 hosts within 5 minutes AND is not in authorized scanner list.' These correlation rules catch reconnaissance that individual logs miss.
Detection without response is merely observation. Effective reconnaissance defense integrates detection with automated and manual response capabilities.
Response spectrum:
| Response Level | Action | When to Use |
|---|---|---|
| Observe | Log and monitor only | Low-confidence detections, background noise |
| Alert | Notify security team | Suspicious but requires investigation |
| Throttle | Rate-limit the source | Slow down reconnaissance without blocking |
| Block (temporary) | Short-term IP block | High-confidence malicious scanning |
| Block (permanent) | Long-term IP block | Known attacker infrastructure |
| Engage deception | Redirect to honeypot | Learn about attacker techniques |
Automated response (SOAR):
Security Orchestration, Automation, and Response platforms automate reconnaissance response:
Playbook: Reconnaissance Response
TRIGGER: IDS alert "SCAN" category
WHEN: Source IP != authorized_scanners
STEPS:
1. Enrich: Get source IP reputation, geolocation, ASN
2. Validate: Check for false positive indicators
3. IF reputation == malicious OR scan rate > threshold:
- Block at perimeter firewall (1 hour)
- Create monitoring filter
- Alert SOC if blocking
4. IF unknown IP with significant volume:
- Add to watchlist
- Create case for analyst review
- Capture packets for analysis
5. Log all decisions and actions
Graduated response:
Not all reconnaissance deserves the same response:
Automated blocking can cause denial of service if attackers spoof legitimate IPs or if detection has false positives. Always include: short initial block duration, alerting for human review, exclusion lists for critical partners, and rate limits on how many IPs can be auto-blocked.
Effective reconnaissance detection requires a coordinated program, not just tools. Here's how to build comprehensive detection capabilities.
Program components:
Maturity progression:
| Level | Capabilities | Focus |
|---|---|---|
| Initial | Basic firewall logging, IDS signatures | Getting visibility |
| Developing | Centralized logging, SIEM, basic correlation | Connecting the dots |
| Defined | Deception, behavioral rules, documented procedures | Systematic detection |
| Managed | Metrics-driven improvement, tuned detection | Reducing noise, improving coverage |
| Optimizing | Threat intel integration, automated response, purple teaming | Staying ahead |
Regularly test your detection with internal red team exercises. Have your team conduct realistic reconnaissance and verify: Does detection fire? How quickly? Does response work? This validates your program works in practice, not just theory.
Detecting and preventing reconnaissance provides early warning of attacks and reduces the intelligence adversaries can gather. Let's consolidate the key concepts:
Module Complete:
You've now mastered Network Reconnaissance comprehensively—from the attacker techniques of port scanning, network mapping, vulnerability scanning, and information gathering, to the defensive strategies of detection and prevention. You understand both sides of the reconnaissance battle.
This knowledge enables you to:
Congratulations! You've completed the Network Reconnaissance module. You now possess comprehensive knowledge of how reconnaissance is conducted and how it can be detected and prevented. This foundation enables effective security assessment, attack anticipation, and defense design. Apply this knowledge ethically and responsibly.