Sitemap
EternalSec

EternalSec

EternalSec | Security Researcher Specializing in Web Security, Vulnerability Research, and Red Teaming concepts. ~ Durgesh

ICMP Timestamp Disclosure: When a Ping Reveals More Than Expected

5 min readSep 7, 2026

--

Sometimes, even a timestamp can give an attacker useful information.

Press enter or click to view image in full size

During a Network Vulnerability Assessment, Nessus commonly reports ICMP Timestamp Request Remote Date Disclosure when a host responds to ICMP Timestamp Requests.

At first glance, this may look harmless. After all, the server is only returning its system time. But from a security perspective, this information can help an attacker understand the target system and identify differences between the attacker’s clock and the remote host.

Let’s understand what this finding means, how it works, how to verify it, its impact, and how to remediate it.

What is ICMP?

ICMP (Internet Control Message Protocol) is primarily used for network diagnostics and error reporting.

You have probably used:

ping <IP>

Ping uses ICMP Echo Request and Echo Reply messages to determine whether a host is reachable.

For example:

But ICMP isn’t limited to ping.

It contains several different message types, including Timestamp Request and Timestamp Reply.

What is an ICMP Timestamp Request?

An ICMP Timestamp Request asks a remote system for timestamp information.

The basic communication looks like this:

The server can therefore reveal information about its system clock.

What is the Vulnerability?

The finding:

ICMP Timestamp Request Remote Date Disclosure

means that the target responds to ICMP Timestamp Requests and discloses its timestamp information.

This is generally considered an information disclosure issue, rather than a vulnerability that directly provides system access.

The important distinction is:

It does not mean:

ICMP Timestamp Response
↓
Remote Code Execution ❌

Why Does Nessus Report It?

Nessus can send an ICMP Timestamp Request to the target.

Conceptually:

If the target responds, Nessus can identify that the system is disclosing timestamp information.

This is why you may encounter this finding during routine Nessus network vulnerability scanning.

How Can an Attacker Use This Information?

The disclosed time itself is usually low-value information.

However, reconnaissance is about collecting multiple pieces of information.

An attacker may use the timestamp to:

  • Determine the approximate remote system time.
  • Compare the remote clock with their own.
  • Identify clock differences.
  • Build a better understanding of the target environment.
  • Combine the information with other reconnaissance findings.

For example:

The important concept is that this finding generally contributes to reconnaissance rather than directly compromising the system.

How to Perform the Verification

For an authorized assessment, you can manually test whether a host responds to ICMP Timestamp Requests.

One approach is using Nmap NSE:

nmap -sn — script=ipidseq <TARGET-IP>

However, ipidseq is not an ICMP timestamp test, so don't use it as proof of this particular finding.

For this vulnerability, use a tool capable of sending ICMP Timestamp Requests and inspect whether the target returns an ICMP Timestamp Reply.

Get EternalSec’s stories in your inbox

Join Medium for free to get updates from this writer.

The verification goal is simply:

This is an important VAPT habit:

Always verify what the scanner is actually detecting rather than blindly reproducing a scanner command.

Exploitation

Unlike vulnerabilities such as SQL Injection or Remote Code Execution, there is usually no meaningful “exploit” that gives an attacker control of the target.

The attack is essentially an information-gathering technique.

Attack Flow

The attacker can then combine this information with other reconnaissance data.

For example:

Therefore, when writing a VAPT report, avoid claiming:

“An attacker can compromise the server using ICMP Timestamp.”

That would be technically inaccurate.

A better statement is:

“An attacker can obtain remote system time information, which may assist reconnaissance and system profiling.”

Why Does System Time Matter?

System time can occasionally provide useful information about a target.

For example, an attacker may compare:

Attacker Time: 10:30:15
Target Time: 10:42:51

This reveals a clock difference of approximately:
+12 minutes

Clock information can sometimes be useful when analyzing authentication systems, logs, distributed services, or other time-dependent behavior.

However, the impact of this specific Nessus finding should not be exaggerated.

The disclosed timestamp by itself generally does not provide credentials, remote access, or code execution.

Impact

Technical Impact

  • Remote system time disclosure
  • Additional information available during reconnaissance
  • Improved target profiling
  • Potential assistance in analyzing time-dependent services

Business Impact

The direct business impact is generally low.

However, when combined with other information disclosures, it can contribute to an attacker’s overall reconnaissance capability.

For example:

Severity Perspective

This finding is commonly considered a low-severity information disclosure.

That’s because:

  • No authentication bypass occurs.
  • No credentials are disclosed.
  • No arbitrary code execution occurs.
  • No direct privilege escalation occurs.
  • The exposed information is relatively limited.

The actual severity should still be assessed according to the organization’s risk-rating methodology and the affected system’s exposure.

Recommendation

The simplest recommendation is to prevent unnecessary ICMP Timestamp Requests from reaching the system or prevent the system from responding to them.

Depending on the operating system and network architecture, this can be achieved through:

1. Firewall Filtering

Block unnecessary ICMP Timestamp Request/Reply traffic at the host or network firewall.

2. Host-Based Filtering

Configure the host firewall to prevent responses to ICMP Timestamp Requests where supported.

3. Network-Level Filtering

If multiple systems are affected, filtering at a network security device can provide centralized protection.

4. Verify After Remediation

After applying the change:

--

--

Written by EternalSec

EternalSec | Security Researcher Specializing in Web Security, Vulnerability Research, and Red Teaming concepts. ~ Durgesh