Network Layer

Introduction

This guide covers the technical evaluation of network perimeters and internal segments. It explains how to discover open ports, fingerprint running services, test firewall rule enforcement, and assess SSL/TLS configurations. Beyond these core tasks, it shows how to extract intelligence from network findings to support deeper reconnaissance and social engineering pretexts – all while operating with minimal exposure.

Always obtain written, explicit authorisation before testing any system. Port scanning can trigger intrusion detection alerts and is illegal against systems you do not have permission to test.

Every open port is a potential entry point. The data you gather at this layer feeds directly into subsequent phases: from vulnerability mapping to credential attacks and phishing campaigns.

Port Scanning

Purpose of the Test

Identify which TCP and UDP ports are open, closed, or filtered. This tells you which services are reachable and which may be exploitable.

Impact

• Exposes unnecessary attack surface.
• Reveals services on non-standard ports that defenders might overlook.
• Forms the foundation for all subsequent network-based tests.

Expected Outcomes

Positive finding: Ports open that should not be (database ports on the internet, SSH with no rate‑limiting, admin interfaces on common ports). Clean result: Only documented, required ports are open; everything else is filtered or closed.

Ethical Considerations

• Use the lowest scan intensity that gets the job done.
• Only scan IP addresses explicitly listed in the scope.
• Schedule aggressive scans outside business hours.
• Hard stop: If a scan causes service degradation, stop immediately and notify the client.

Reconnaissance Value

Port scanning is more than a binary open/closed check. Look for:

• Responses from filtered ports – a mix of open and filtered often reveals firewall rule structure.
• Replies with IP IDs or TCP timestamps – can be used to calculate host uptime, infer patch cycles.
• TTL values in returned packets – different operating systems use different initial TTLs, helping you guess the OS.
• Ports open on only one IP in a range – likely test or forgotten systems that are high‑value targets.

What to capture for recon:

• All open ports with transport protocol (TCP/UDP).
• Service‑hint banners (SSH-2.0-OpenSSH_8.2 etc.).
• TTL, TCP window size, and IP ID patterns.
• Whether the host is behind a load balancer (multiple IPs presenting identical fingerprints).

Testing Flow

LLM ideation -> Human review -> Lightweight scan -> Targeted deep scan -> Document

Manual Testing Steps

1. Confirm IP ranges are in the signed scope document.
2. Start with a fast, low‑noise sweep: nmap -sS --top-ports 1000 -T3 -oN initial.txt TARGET
3. Follow with full TCP scan on discovered hosts: nmap -sS -p- -T3 -oN full_tcp.txt TARGET
4. UDP scan for key services: nmap -sU -p 53,67,68,161,500 TARGET
5. Save all output in multiple formats using -oA.
6. Document every open port with OS fingerprint hints.
7. Cross‑reference findings against the client’s documented architecture.

Stealth and Reducing Exposure

• Spread scans over time: instead of one 10‑minute blast, send probes in 30‑second bursts over hours.
• Use common source ports: --source-port 53 (DNS) or 443 (HTTPS) can bypass poorly configured firewall rules and look like legitimate traffic.
• Employ scan decoys: nmap -D RND:5 mixes real probes with spoofed IPs (use only with permission).
• Idle scan: nmap -sI zombie_host uses an innocent third party to measure port changes – nearly invisible but slow.
• Limit speed: -T2 (polite) or -T1 (sneaky) drastically reduce detection risk.
• Shuffle IP order: --randomize-hosts prevents sequential scanning that is easy to spot.

AI-Assisted Testing

Prompt Template — Scan Planning with Recon Focus

[ROLE] Senior network security engineer
[SCOPE] IP range: 10.0.0.0/24, engagement type: external pentest, time window: 8 hours
[TASK] Design a port scanning strategy that maximises information gathering while minimising detection.
  - Phase the scan from lightest to most intrusive.
  - Recommend timing and source port tricks to blend in.
  - Specify exactly which nmap options to extract OS and load‑balancer hints.
[OUTPUT FORMAT]
  - Phased plan: phase name, nmap command, purpose, detection risk.
  - Additional recon data to collect from each phase.
  - Go/no-go criteria before advancing.
[CONSTRAINTS] Non-destructive only. Minimum intrusion. Avoid T5 timing.

AI Hard Stops for This Topic

• [NO] Never use -T5 (insane timing) – can crash services.
• [NO] Do not run exploit NSE scripts (--script=vuln) without explicit scope.
• [NO] Never scan IPs outside the authorised range.
• [YES] Default to -T3 and slow down if alerts appear.
• [YES] Use -oA for comprehensive output.

Tools Reference

Resources

• Nmap Reference Guide
• SANS Port Scanning Techniques

Service Version Detection

Purpose of the Test

Determine the exact software name and version listening on each open port. This links an open port to specific known vulnerabilities.

Impact

• Identifies software with published CVEs requiring immediate patching.
• Uncovers end‑of‑life products no longer supported.
• Reveals default configurations that have well‑known exploitation paths.

Expected Outcomes

Positive finding: Outdated versions with public CVEs, verbose banners, EOL software in production. Clean result: Services respond without revealing version details; software is current; EOL systems replaced.

Ethical Considerations

• Version probes can trigger IDS/IPS.
• Never exploit a CVE – only confirm detectability.
• Document each version with the exact evidence (banner text or probe response).
• Hard stop: If a critical CVSS ≥ 9.0 vulnerability is discovered, stop testing that service and escalate immediately.

Reconnaissance Value — Turning Versions into Intelligence

Version detection is the core of technical reconnaissance gathering. From each banner you can extract:

• Exact software and build number -> search for known CVEs and publicly reported bugs.
• Operating system hints (e.g., SSH banner like Ubuntu-2ubuntu0.2).
• Internal hostname or domain name often leaked in SMTP, MySQL, or HTTP error pages.
• Software patch levels – compare against vendor release notes to gauge how actively systems are maintained.

Where to search for more information on a target using these details:

• NVD (National Vulnerability Database) – map version to CVE.
• Exploit-DB – check for public proof‑of‑concept code.
• Shodan and Censys – see if the same service version is exposed elsewhere (passive recon, no direct contact).
• SSL Certificate Transparency logs – certificate Subject Alternative Names reveal related subdomains.
• Job postings – search for the discovered software stack, e.g., “Apache 2.4.29 engineer”, to learn about internal tools and upcoming migrations.
• Vendor security advisories – understand exploitability and patch history.

This collected data fuels vulnerability scoring, credential brute‑force attempts, and social engineering pretexts.

Testing Flow

LLM ideation -> Human review -> Version detection probes -> CVE research -> Document (no exploitation)

Manual Testing Steps

1. Run nmap -sV -p [ports] TARGET to get service fingerprints.
2. Manually grab banners: nc -v TARGET PORT or curl -v TARGET:PORT.
3. For HTTP, inspect Server header and default error pages.
4. For SSH, note the version string on connection.
5. For each service, search NVD and Exploit-DB.
6. Document CVE ID, CVSS, affected version range, and a safe detection method.
7. Do not attempt to exploit.

Active Recon — Probing Beyond the Banner

Once you have a version, you can actively gather more with non‑malicious probes:

• HTTP OPTIONS / TRACE – see what methods are enabled.
• SMTP VRFY/EXPN – can enumerate users on poorly configured mail servers.
• SNMP v1/v2c community strings – if you’ve discovered port 161, try public or private with snmpwalk.
• NTP readvar – reveals server version and sometimes internal IPs.

These techniques stay on the right side of “detection only” while significantly expanding your target picture.

Stealth and Reducing Exposure

• Banner grab with a full TCP handshake only – use nc or nmap with --version-intensity 2 to reduce probe noise.
• Limit concurrent connections – one banner at a time, with a few seconds delay, looks like normal user traffic.
• Mimic typical client user‑agents – with curl -A "Mozilla/5.0 ..." you avoid standing out as a scanner.
• Avoid aggressive versioning scripts – --script=banner alone is sufficient; large NSE scripts generate multiple requests that are easy to fingerprint.

AI-Assisted Testing

Prompt Template — Version to CVE Mapping and Recon Expansion

[ROLE] Vulnerability research assistant
[SERVICES] Port 22: OpenSSH 7.4, Port 80: Apache httpd 2.4.29, Port 3306: MySQL 5.7.22
[TASK] Map each service version to known CVEs (CVSS ≥ 6.0) and suggest additional recon steps.
  - For each CVE, provide a detection‑only method.
  - For each service, list non‑intrusive commands to extract more information (e.g., HTTP OPTIONS, MySQL error messages).
  - Identify which external data sources (crt.sh, Shodan) would be useful.
[OUTPUT FORMAT]
  - Table: Service | Version | CVE ID | CVSS | Description | Detection Method | Recon Commands
  - Prioritised list by severity and ease of detection.
[CONSTRAINTS] Detection methods only – no exploit code. No weaponised payloads.

AI Hard Stops for This Topic

• [NO] Do not attempt to exploit CVEs – detection and documentation only.
• [NO] Do not request or accept exploit code.
• [YES] Always verify version ranges before documenting a CVE.
• [YES] Use safe, banner‑level probes for confirmation.

Tools Reference

Resources

• NVD CVE Search
• Exploit-DB

Firewall Rule Testing

Purpose of the Test

Verify that firewall rules match the intended security policy. Rules drift over time; temporary openings become permanent exposures.

Impact

• Identifies open ports that should be blocked.
• Exposes management interfaces accessible from untrusted zones.
• Highlights inconsistencies between inbound and outbound filtering.

Expected Outcomes

Positive finding: Reachable ports that the firewall policy marks as blocked, management ports open from outside, inconsistent rule sets. Clean result: Only approved ports pass through; all others are filtered; management interfaces are IP‑restricted.

Ethical Considerations

• Authorisation must explicitly mention firewall testing.
• Evasion techniques (fragmentation, decoy scanning) require written permission.
• Never use firewall testing to reach out‑of‑scope systems.
• Hard stop: If a path to out‑of‑scope assets is found, stop and report.

Reconnaissance Value

Firewall behaviour itself reveals information:

• A port that is “filtered” versus “closed” tells you a firewall is present and what rules it applies.
• Responses from different source IPs (e.g., inside vs. outside the corporate network) map the perimeter.
• TCP flag combinations (SYN vs. ACK vs. FIN) that elicit responses disclose stateful inspection rules.
• ICMP filtering and TTL handling can differentiate network segments.

Use this data to build a diagram of the network perimeter and to identify the most promising ingress points.

Manual Testing Steps

1. Obtain the client’s documented firewall policy.
2. Probe ports that should be closed: nmap -p [closed-ports] --reason TARGET
3. Test common management ports: 22, 23, 3389, 5900, 8080, 8443, 9200.
4. Test common database ports: 3306, 5432, 1433, 27017, 6379.
5. Compare actual results with policy.
6. Document all gaps.

AI-Assisted Testing

Prompt Template — Firewall Gap Analysis

[ROLE] Network security analyst
[POLICY] Firewall policy document: [paste or describe the policy]
[SCAN RESULTS] Nmap output: [paste relevant scan output]
[TASK] Identify gaps between the firewall policy and actual scan results.
  - List ports that should be closed but appear open.
  - Identify highest‐risk gaps by service type.
  - Suggest remediation for each gap.
[OUTPUT FORMAT]
  - Gap table: Port | Expected State | Actual State | Risk | Remediation
  - Priority order by risk.
[CONSTRAINTS] Analysis only – no suggestions for exploiting gaps.

AI Hard Stops for This Topic

• [NO] Do not attempt to exploit firewall bypass techniques without explicit scope.
• [NO] Never scan hosts outside the authorised IP range.
• [YES] Document gaps only; do not attempt to leverage them without explicit authorisation.

Tools Reference

SSL-TLS Config

Purpose of the Test

Evaluate the security of encrypted connections. Weak cipher suites, outdated protocols, and poor certificate management can lead to man‑in‑the‑middle attacks.

Impact

• Weak ciphers allow traffic decryption.
• Expired or self‑signed certificates break trust chains.
• TLS 1.0/1.1 have known protocol weaknesses (POODLE, BEAST).
• Missing HSTS allows downgrade attacks.

Expected Outcomes

Positive finding: TLS 1.0/1.1 enabled, weak ciphers (RC4, DES, 3DES), expired certificates, missing HSTS. Clean result: TLS 1.2+ only, strong ciphers (AES‑GCM, ChaCha20), HSTS with long max‑age, valid certificate chain, OCSP stapling.

Reconnaissance Value

SSL/TLS scans are a goldmine for passive and active reconnaissance:

• Certificate Subject Alternative Names (SANs) reveal subdomains and sometimes internal hostnames – use crt.sh to find every certificate ever issued for an organisation.
• Certificate Issuer tells you which CA is trusted; phishing campaigns can spoof that CA if internal PKI trust is weak.
• Server key size and algorithm imply the age of the infrastructure (older keys = less maintained).
• HTTP Strict Transport Security (HSTS) absence can be leveraged in social engineering to serve a look‑alike HTTP site.

All of this can be gathered without sending a single suspicious packet: use SSL Labs or OpenSSL s_client from a legitimate‑looking VPS. The information then feeds directly into:

• Phishing infrastructure: spin up a look‑alike site with the correct TLS certificate attributes.
• User targeting: know what authentication portal (e.g., Outlook Web Access on a particular version) to imitate.

Manual Testing Steps

1. Run testssl.sh https://example.com
2. Check for TLS 1.0/1.1, weak ciphers, certificate errors.
3. Verify HSTS with curl -I https://example.com | grep -i strict
4. Extract SANs and issuer details.
5. Use SSL Labs for a comprehensive graded report (internet‑facing services only).

AI-Assisted Testing

Prompt Template — TLS Finding Documentation and Recon Expansion

[ROLE] Security analyst
[TESTSSL OUTPUT] [paste testssl.sh output]
[TASK] Parse this TLS scan output and produce a finding summary.
  - Identify all security weaknesses.
  - Extract all Subject Alternative Names and suggest how they could be used for further reconnaissance (no attacking).
  - Provide remediation recommendations with specific configuration examples.
[OUTPUT FORMAT]
  - Finding per weakness: Title | CVSS | Description | Evidence | Remediation
  - List of discovered SANs with context.
[CONSTRAINTS] Analysis and remediation only – no attack instructions.

AI Hard Stops for This Topic

• [NO] Never attempt active MitM attacks against TLS traffic.
• [NO] Do not test TLS on services outside the authorised scope.
• [YES] testssl.sh and SSL Labs are passive/non‑destructive tools.
• [YES] Document cipher suites with specific evidence from scan output.

Tools Reference

Network Social Engineering

The data collected during network testing can dramatically improve the realism and success rate of phishing campaigns and pretext calls. This section describes how to use technical findings to craft believable scenarios – always within the boundaries of the engagement and with explicit client authorisation.

Who to Target in an Organisation

Network information helps you identify the most valuable human targets:

• IT and system administrators – exposed remote management services (SSH, RDP, iDRAC) or outdated server software hint at the systems they maintain. A phishing email about an urgent patch for their exact version is highly convincing.
• Help desk personnel – often have password reset privileges. A call referencing internal server names (gleaned from SMTP banners or certificate SANs) adds legitimacy.
• Finance and HR staff – if you discover a dedicated payroll or expense system (e.g., port 8443 with a specific Oracle PeopleSoft banner), you know exactly which department to impersonate.
• Senior management – rarely targeted, but if their executive assistant’s email system (e.g., Zimbra) is identified, a CEO‑fraud email becomes easier.

Always follow the client’s social‑engineering scope; these suggestions are only for authorised engagements.

How to Create Realistic Phishing Emails

Use technical details from network scanning to increase credibility:

• Spoof an internal service alert: if you identified a Microsoft Exchange server version via HTTP banner, craft an email that looks like a quota warning from that specific Exchange build.
• Reference discovered hostnames: an email that says “We are upgrading dc01.internal.corp.com” will pass many user’s sniff test if that hostname is real.
• Mimic SSL certificate errors: if a site has an expired certificate, send a notification about an impending expiry with a link to a fake IT portal.
• Capitalise on known vulnerable software: if you found Apache 2.4.29 with a critical CVE, send a mandatory “security patch” installation link (pointing to a controlled landing page).
• Use the correct email server banner: SMTP banners disclose the exact mail server software (e.g., Postfix 3.1.0). Customise phishing headers and mail format to match.

Phishing email structure:

1. Subject: Legitimate‑sounding, based on the technology discovered (e.g., “Action required: Update your mailbox password for Exchange 2019”).
2. From: Spoof or use a look‑alike domain; if the SMTP server allows open relay (check during testing), you may even use the real server.
3. Body: Include specific technical terms (server names, software versions) and a call to action (click link, enter credentials).
4. Landing page: Cloned from the real authentication portal, with a valid‑looking TLS certificate (if possible) and the same visual design.

Integrating with AI

Use AI assistants to generate phishing templates that incorporate the exact technical details you gathered. Example prompt:

[ROLE] Social‑engineering campaign designer
[DETAILS] Server: Exchange 2016 CU19 (from HTTP banner), internal hostname: mail.internal, SSL certificate expired, company name: Acme Corp
[TASK] Create a phishing email targeting IT staff to capture their credentials on a cloned OWA portal.
  - The email should appear to be from the internal IT team about a required SSL certificate update.
  - Include plausible technical language that matches the real environment.
  - Provide the complete email body, subject line, and suggested landing page elements.
[OUTPUT FORMAT] Subject line, email body, HTML template for landing page.
[CONSTRAINTS] For authorised tests only. Do not include actual exploit code.

Ethical note: All social engineering must be authorised in writing. Never phish individuals without explicit consent from the organisation.

Network OPSEC

Entire engagements can be compromised if the tester’s activities are flagged early. Minimising your digital footprint during network testing is essential.

Network‑Level Stealth

• Staging infrastructure: Use dedicated VPS or cloud instances with no prior association to you. Change source IPs between phases.
• Rate limit scans: --scan-delay 1s or --max-parallelism 1 ensures probes trickle in rather than flood.
• Use common protocols as cover: DNS requests (port 53) from your source are rarely blocked; tunnel probes through them if you have the capability.
• Leverage legitimate‑looking traffic: For web services, use a normal browser automation tool (like Puppeteer) to fetch banners instead of raw nmap probes – the traffic is indistinguishable from a regular user.
• Avoid default nmap fingerprints: Customise the TCP window size, TTL, and options in nmap (--ip-options), though this requires deep knowledge.
• Test from multiple vantage points: An external scan from a residential IP looks different from a cloud provider; use various exit nodes to mimic different attacker profiles.

Reducing Exposure on Service Version Detection

• Use the lowest version intensity that still yields useful data: --version-intensity 2 or --version-light.
• Do not use the full vulnerability NSE library; stick to banner and http-headers.
• Obtain version information from public sources first (Shodan, Censys) – you might not need to probe at all.

Data Handling and OPSEC

• Store scan data encrypted on the testing machine.
• Minimise logging on your own tools; ensure your VPS provider does not retain logs.
• Delete artefacts after the engagement, unless the contract requires retention.

AI-Assisted OPSEC Prompts

[ROLE] OPSEC specialist for penetration testing
[ENGAGEMENT] External network test, client expects IDS monitoring, target IP: 192.168.1.0/24
[TASK] Design a scanning approach that minimises detection probability.
  - Recommend exact nmap flags, timing, and source‑port tricks.
  - Suggest a schedule (days, times) and IP rotation strategy.
  - What to do if an alert is triggered.
[OUTPUT FORMAT] Step‑by‑step plan with OPSEC rationale for each step.
[CONSTRAINTS] Non‑destructive only. Must stay within authorised IPs.

Resources

• testssl.sh
• SSL Labs Server Test
• Mozilla SSL Configuration Generator