Nmap Commands Cheat Sheet: What an Outside Scan Shows

Nmap commands help you answer a precise question: which ports can a permitted outside observer reach on a specified host? A short scan can reveal reachable services, but it cannot prove that every company asset was included or that an open service is vulnerable. This cheat sheet follows a controlled workflow from target selection through validation. Use each example only on a lab system or an asset your organization has authorized you to test.

Which Assets Can You Scan, and What Does an Outside Scan Actually See?

Start with a written scope that names the domains or IP addresses, the approved source network, and the time window. Confirm that the current address belongs to the authorized target before running a command. A hostname can resolve to infrastructure operated by another party. Ownership and permission are separate questions, especially for hosted applications and shared services.

An outside scan observes responses to probes from its particular network position. It does not inspect internal routing, application authorization, or every virtual host behind an address. Nmap says the same port can appear open from one network and filtered from another. Record where and when you scanned so another analyst can interpret the result.

For the examples below, lab.example stands for an approved lab hostname. Replace it with a target inside your scope. A scan of one address is a snapshot of that address, not an inventory of all related domains, cloud assets, or certificates. The broader discovery task is explained in the EASM 101 guide.

Before interpreting a result, check what Nmap actually sent. The basic nmap lab.example command scans the 1,000 most common TCP ports by default. An unlisted port may therefore be untested, not closed. That distinction matters when a service owner uses an uncommon port or when your scope includes separate IPv6 addresses.

Which Nmap Commands Give You a First Port Inventory?

Begin with the ordinary TCP scan on one approved host. Nmap reports a host and port state for the targets it reaches. Save the command, target, scan source, and timestamp alongside the result. Those details make a later comparison meaningful when a firewall rule or deployment changes.

The table is a selection guide, not a batch of commands to run automatically. Start with the smallest approved target and port set. Expand only when the scope and operational window allow it. A full TCP scan sends many more probes than the default selection and can take longer.

Use -p to name ports when an inventory or change ticket already identifies a service. Nmap’s port specification guide says -p- covers ports 1 through 65535. It also explains that -F narrows the default scan to fewer ports. Neither option changes the ownership question: the target must still be approved.

Use -Pn only when host discovery may be suppressing a known target. Nmap defines it as treating hosts as online and skipping discovery. If a scan then returns a state, read that state as the outcome of the selected probes. Do not turn a skipped discovery check into proof of availability.

How Do You Narrow Ports and Check the Service Behind an Open Port?

A port number is a hint, not a service identity. Nmap’s service database maps common port numbers to likely names. The project warns that software can run on unusual ports. Check the service behind a relevant open port with -sV, then compare the result with an authorized configuration record.

For example, nmap -sV -p 443 lab.example sends service probes to the selected port after the port scan. Nmap may report an application name, version, or other identifying detail when the service responds. Its documentation also says many services do not expose all of those details. Treat an incomplete or generic result as a lead for an owner, not as a completed fingerprint.

Keep the service check targeted. A short list such as nmap -sV -p 80,443 lab.example can help test a web team’s stated exposure. If the port is closed or filtered from your source, collect the exact state and reason before asking the owner to investigate. You may be seeing an intended network policy rather than a missing application.

Service detection and a vulnerability assessment answer different questions. A visible version string can be stale, masked by a proxy, or different from the patched package behind it. Confirm the product, build, and applicable vendor guidance with the system owner. An open port alone does not establish a flaw, exploit path, or business priority.

UDP needs its own explicit scan type. The example nmap -sU -p 53 lab.example tests only the selected UDP port. Nmap can report an ambiguous state when it cannot distinguish a silent open service from filtering.

Its version detection can sometimes obtain a response and clarify that state. Silence still requires careful interpretation.

How Should You Read Open, Closed, and Filtered Results?

Nmap’s port states describe what its probes observed, not a permanent property of a host. open means an application accepted the relevant connection or datagram. closed means the port was reachable but no application listened. filtered means Nmap could not determine whether it was open because filtering affected the probe.

These meanings support different next steps. An open administrative service calls for an owner check and an access-policy review. A closed port may confirm that no listener answered at that moment, but the state can change later. A filtered port calls for a look at the approved firewall path before anyone concludes the service is absent.

The distinction matters across scan locations. A corporate VPN, a cloud runner, and a public network can encounter different access controls. Repeat a disputed check from the intended external vantage point with the same target and port selection. Keep the original result; do not replace it with a later, more convenient answer.

Nmap also documents unfiltered and two combined states for scan methods that cannot make a finer distinction. These are uncertainty labels, not extra severity levels. Ask which scan type produced the label before drawing a conclusion.

A UDP open|filtered result is not the same evidence as a TCP open result. The UDP state leaves open the possibility that a filter dropped the probe.

When a report says a service is missing, inspect the command first. The default port set may have omitted it, the target name may have resolved differently, or filtering may have hidden the response. The appropriate follow-up is a scoped recheck, not an unsupported claim that the asset is safe. This is why an external attack surface inventory starts with asset discovery as well as port checks.

Which Findings Need a Second Check Before You Prioritize Them?

A first scan produces candidates for validation. For an open port, confirm which asset owns the listener, whether it is meant to be internet-facing, and which team operates it. For a service name or version, corroborate the probe result against configuration or an owner-provided record. For a filtered result, check the relevant path and policy.

A practical validation sequence keeps evidence tied to the same question. Discovery identifies the approved host and scan vantage point. The service check narrows the port and tests the responder.

Validation asks the owner whether that exposure is expected and whether the configuration matches the scan. Record each stage separately so an assumption never becomes a finding by repetition.

1. DiscoveryConfirm the approved asset, address, source network, and scan window.
2. Service checkRecord the port state and, where relevant, run a targeted service probe.
3. ValidationAsk the asset owner to confirm exposure, configuration, and intended access.

Priority comes after validation. A reachable service may be essential and correctly restricted. Another may be an abandoned deployment without an owner.

Compare the actual access path, asset importance, and remediation options before ranking the work. The attack surface reduction approach places findings in a broader asset and risk context.

Retest after a change from the same relevant outside position. If a service was meant to close, confirm that the formerly open port is no longer reachable. If access was meant to narrow, compare the results from permitted and unpermitted source networks. A configuration change is complete only when the intended exposure has been checked.

How Does the Atlas Attack-Surface View Help Track the Same Exposure Question Over Time?

One Nmap command answers a narrow question about one target from one location. Brandefense’s public Atlas attack-surface page describes a different workflow: finding domains, subdomains, IPs, cloud assets, and certificates linked to an organization. It then checks for open ports, exposed services, and weak settings. This helps an analyst ask which assets need a port check in the first place.

The page makes a useful distinction between its free one-domain grade and the continuing attack-surface map. The free grade uses Brandefense information held on a domain and does not test the target’s systems. The map builds an asset list and flags new assets or exposures as they appear. Neither description makes the grade an Nmap port scan or promises identical observations.

Use a local Nmap result as evidence for a specific question, such as whether a selected port answers from an approved network. Use the Atlas attack-surface view to frame the larger inventory and change question. The two views can disagree because they differ in scope, timing, method, and vantage point. Investigate that difference with asset ownership and the original scan details.

A useful handoff contains the target and its authorization, the exact command, the timestamp, the source network, and the observed state. Add the asset owner, expected access, and validation outcome. If the port or service changes later, this record shows what was actually observed and what decision followed. That is more actionable than a port list with no context.