The Printer That Stopped the Shipping Line

Stop the scan immediately. Do not retry the printer, power-cycle it, or send it any further traffic; that could deepen the outage or destroy the evidence needed to explain it.

Notify the client point of contact and the CIO in writing. State what you were running, the target range, the start time, and the symptom. Ask the client's IT team to restore the printer; do not attempt restoration yourself unless the client explicitly asks and you have a documented procedure.

Preserve your nmap command line, output files, timestamps, and console history. Record the exact time the helpdesk reported the outage. Avoid blaming the device or the network; explain that a full-port SYN scan at -T4 can exhaust resources on embedded devices, and that you will exclude fragile devices going forward. Offer to pause scanning until the client confirms the line is back up. Document the incident in the daily log and in the final report as an operational impact, not as a finding against the client.

Treat the /16 as fragile production, not a lab. Changes:

• Drop to -T2 or -T1 and set an explicit --max-rate and --max-retries 1.
• Build an exclude file for printers, label systems, IP cameras, VoIP handsets, and any known embedded devices; confirm the list with IT.
• Scan smaller ranges in waves, starting with a low-impact host-discovery pass (ARP on the local segment, or -sn where appropriate).
• Avoid -p- on embedded subnets; use a targeted port list first (for example 22, 80, 135, 139, 443, 445, 3389, and common ICS ports only if in scope).
• Use -Pn only for hosts already confirmed alive, and avoid aggressive NSE scripts against fragile devices.
• Schedule scans in an agreed window and keep a rollback/stop contact available.

The CIO's 'finish fast' request does not override the no-damage constraint. Slower and narrower is the correct trade-off.

For 10.20.5.77, SMB is open and signing is required. Use low-intensity checks: nmap --script smb2-security-mode,smb-enum-shares,smb-os-discovery -p 445, then smbclient -L with null and guest sessions. Do not brute-force credentials. If shares are accessible, list directory names only and stop if you encounter sensitive data outside scope.

For 10.20.5.90, only 3389 responds; the rest are filtered. Run nmap --script rdp-enum-encryption,rdp-ntlm-info -p 3389 and record the NLA and encryption posture. Do not attempt password guessing. Use a TCP ACK scan (-sA) to map firewall behaviour without completing connections.

For 10.20.5.120, ARP replies but TCP SYN is dropped. That suggests a host firewall or IPS, not a dead host. Try a small set of common ports with -Pn and low timing, and a TCP ACK scan to see whether the firewall is stateful. If everything remains filtered, document it as filtered and request an authenticated scan or host-based review from the client rather than escalating scan intensity.