Detect timestamp requests by monitoring ICMP traffic for requests that ask for a host time value, especially when they come from unfamiliar or external sources. In most environments this traffic is rare, so treat repeated use as reconnaissance. Pair network alerts with endpoint logs to see whether the source host is mapping systems or testing reachability.
What timestamp requests look like on the wire
Timestamp requests are a narrow ICMP pattern, so the first job is to separate them from ordinary reachability checks and other control traffic. In practice, security teams should look for repeated ICMP messages whose purpose is to ask a host for its time value, especially when they appear in bursts or from a source that does not normally talk to the target network.
That matters because timestamp traffic is rarely needed in well-managed environments. When it shows up unexpectedly, it can be part of simple network mapping, protocol probing, or host fingerprinting rather than a business process. The signal is strongest when the request pattern is inconsistent with the source host's usual role or network zone.
A useful way to read the traffic is by context: who sent it, how often it appears, and whether the destination responds across many systems. A single request may be benign, but repeated requests across multiple hosts suggest a deliberate scan. Network Ports and Protocols Security Guide is a useful reference point for treating unusual protocol use as part of broader network exposure analysis.
How to confirm the activity is reconnaissance
Confirmation comes from correlation, not from the ICMP event alone. Network telemetry should be checked alongside endpoint logs, firewall records, and flow data to see whether the same source is also touching other hosts, testing reachability, or moving through adjacent subnets. That combination turns a noisy protocol event into a more actionable detection story.
Look for breadth and repetition. Reconnaissance often produces small, low-risk requests across many addresses, while legitimate traffic is usually narrower and tied to a known management function. If the same source also generates other discovery-style activity, such as sweeps, hostname lookups, or probes on nearby services, the timestamp request becomes more suspicious.
It also helps to baseline what is normal in your environment. Some legacy tools or diagnostic workflows may still use ICMP in limited ways, but that should be documented. When no such use is expected, timestamp requests should be treated as a detection rule candidate rather than a standalone alert.
Turning detections into a usable hunting signal
The practical value is not just alerting on one packet type, but folding it into a hunt for discovery behavior. Timestamp requests are best treated as one clue in a cluster of low-noise indicators, especially when they originate from external addresses or from internal systems that should not be mapping their peers.
That means the hunt should ask three questions: is the source known, is the pattern repeated, and is there evidence of follow-on discovery? If the answer to all three points is yes, the activity is more likely to be a recon phase than a one-off diagnostic test. MITRE ATT&CK Enterprise Matrix helps place that behavior in an adversary workflow that includes discovery, scanning, and later access attempts.
Security teams should also enrich alerts with asset criticality and network placement. A timestamp request against a lab system is less important than the same pattern against production systems or network segments that are normally quiet. The goal is to reduce false positives without missing the early signs of enumeration.
Risk and Threat Considerations
Timestamp requests are low-noise by themselves, but they can expose an environment that still answers legacy ICMP probes and therefore reveals that a host is reachable. Attackers use that kind of signal to map live systems, compare responses across hosts, and refine later scanning. In environments with weak segmentation, repeated requests can be the first visible sign of broader discovery activity.
Failure mechanism: A monitoring stack that only flags high-volume scans can miss low-and-slow ICMP probing, while endpoint telemetry that is not correlated with network events may fail to show the wider pattern.
Impact: The result is delayed detection of reconnaissance, weaker confidence in asset exposure, and less time to contain follow-on discovery before an attacker shifts to more targeted probing.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1016 — System Network Configuration Discovery | Timestamp probing often supports discovery and host mapping activity. |
| Recommendation — Map repeated timestamp probes with discovery techniques and hunt for broader reconnaissance patterns. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | Detecting unusual ICMP timestamp traffic depends on continuous network monitoring. |
| Recommendation — Monitor ICMP patterns and alert on unusual or repeated timestamp requests. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Timestamp-request detection is a network monitoring use case needing alerting and analysis. |
| Recommendation — Add ICMP anomaly detection to your network monitoring and defense workflow. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | ICMP timestamp requests are detected through event and network monitoring controls. |
| Recommendation — Correlate network telemetry and endpoint logs to identify suspicious ICMP reconnaissance. | ||
| ISO/IEC 27001:2022 | A.8.16 — Monitoring activities | This pattern is found through security monitoring of network activity and alerts. |
| Recommendation — Define monitoring rules that flag unusual ICMP activity and support investigation. | ||
Practitioner Guidance
What to prioritise: Tune alerts around repetition, source novelty, and cross-host spread rather than on a single timestamp request. A lone event is weak evidence; a source that touches many systems is materially more important.
What to verify: Confirm whether any approved tool, monitor, or diagnostic process is expected to use this ICMP pattern. If not, investigate the source host for broader discovery behavior and review whether the network segment should even be receiving such traffic.
Practitioner takeaway: Timestamp requests are most useful as a reconnaissance indicator when you correlate them with other discovery signals, because the security value comes from pattern recognition, not from the ICMP message alone.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org