Check basic reachability
What you are learning
One of the first things a security tester may want to know is whether a computer or server on a network is responding. A common first check sends a small network message called an ICMP (Internet Control Message Protocol) echo request, often called a ping, to the target. Use the trainer's authorized lab action to perform this check. If a reply comes back, the request reached the target and the target responded to ICMP. If no reply comes back, do not assume the computer is offline: a firewall or other network control may block ICMP while websites or other network services still work. A ping checks this kind of host reachability; it does not identify which TCP or UDP ports are open. Port and service checks are separate authorized steps that can determine whether particular network services are reachable.
- Explain why reachability may be checked before deeper service discovery.
- Confirm whether an authorized target responds without treating reachability alone as proof of a specific service.
- Recognize that filtering and routing can affect whether a target appears reachable.
- Identify defender telemetry that could record the same reachability probe.
Security teams use reachability checks for troubleshooting, asset review, and incident work. Similar traffic can also appear during reconnaissance, so defenders should decide whether the pattern is expected. In real environments, the same kind of traffic may come from legitimate troubleshooting, asset discovery, monitoring, or security testing. Defenders therefore compare the pattern with approved work before deciding that the activity is suspicious.
Use a repeatable web-testing method
Connect this ATT&CK training activity to the WSTG approach: establish expected behavior, identify the relevant attack surface, change one controlled input or observation at a time, compare the response with the baseline, and record evidence before drawing a conclusion.
For reconnaissance-oriented lessons such as T1595, treat reachability, exposed services, and observable application behavior as information gathering. A reachable service is evidence about exposure; it is not by itself proof of a vulnerability.
Open WSTG web security fundamentalsRun only the trainer-provided reachability action against the configured lab target. Record whether a reply appears. Then give one reason that no reply would be inconclusive and one defender data source that could record the probe. Do not test any other address.
What the command is doing
This controlled lesson sends two ICMP echo requests, commonly called pings, to the facilitator-authorized lab target. ICMP is a network protocol used for status and diagnostic messages. A reply is evidence that the target responded to this type of request. No reply is inconclusive because ICMP can be blocked even when other services are available. This action does not test individual ports; later port checks ask whether specific network communication points accept connections.
Command used in this lesson
The command that will be run:
ping -c 2 <authorized-target>
What each part means
ping— Sends ICMP echo requests for this controlled reachability check.-c 2— Stops automatically after two echo requests so the exercise remains small and bounded.<authorized-target>— The participant's facilitator-authorized lab target. The trainer substitutes this value automatically; the participant cannot edit it.
How to read the ping result
- A reply line is evidence that an ICMP response came back from the authorized target.
- No reply does not prove the target is down; ICMP may be blocked or deprioritized.
- Packet loss and timing describe this observation only and should not be treated as vulnerability evidence.
Authorized reconnaissance action
Commands, flags, ports, and targets are fixed by the trainer. The participant cannot enter arbitrary shell commands.
Enter one finding per line. Identity and condition are locked by the facilitator.
A reply is useful evidence. No reply is inconclusive because ICMP can be blocked. Defenders should interpret this result with other evidence and context before deciding what it means.
Defenders may see ICMP requests and replies in firewall logs, flow logs, packet captures, IDS/IPS data, or device logs. Compare the source, timing, rate, and destinations with approved monitoring or troubleshooting. Reduce risk by limiting unnecessary exposure, using network segmentation, and monitoring public systems. Defenders should compare the source, timing, rate, and destination pattern with approved administration, monitoring, and vulnerability-management work. This comparison helps separate normal activity from scanning that needs review.