« Deprecated TLS Version or Weak Cipher Negotiated Externally Potential DHCP Starvation via High Client MAC Cardinality »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.27

ICMP Timestamp or Information Request from the Internet

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

ICMP Timestamp or Information Request from the Internet

edit

Identifies inbound ICMP Timestamp (type 13) or Information (type 15) requests from external addresses to internal RFC1918 destinations. These message types are rarely used in modern networks and are commonly associated with host and path fingerprinting during reconnaissance.

Rule type: query

Rule indices:

  • logs-network_traffic.icmp-*

Severity: low

Risk score: 21

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Network
  • Tactic: Discovery
  • Tactic: Reconnaissance
  • Use Case: Network Security Monitoring
  • Use Case: Threat Detection
  • Data Source: Network Traffic
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating ICMP Timestamp or Information Request from the Internet

ICMP Timestamp and Information requests are legacy diagnostic messages. Inbound use from the Internet toward internal hosts is uncommon in production networks and often indicates active scanning or OS fingerprinting.

Possible investigation steps

  • Review source.ip against threat intelligence and prior scan activity on the environment.
  • Determine whether the targeted destination.ip is an exposed host, VPN concentrator, or mis-NATed internal asset.
  • Look for adjacent port scans, SYN sweeps, or exploit attempts from the same source around the alert window.
  • Check whether the destination host replied and whether follow-on connections were attempted.

False positive analysis

  • Some legacy network monitoring or SLA probes may still use ICMP Timestamp requests. Maintain exceptions for known monitoring source ranges after validation.
  • Shared hosting or multi-tenant environments with overlapping address space may require destination-specific tuning.

Response and remediation

  • Block or rate-limit the external source at the perimeter if activity is unauthorized.
  • Verify that the targeted internal host is not unintentionally exposed to the Internet.
  • Increase monitoring on targeted assets for follow-on exploitation attempts.

Setup

edit

Setup

This rule requires ICMP transaction telemetry from the Elastic network_traffic integration (network_traffic.icmp data stream).

Rule query

edit
data_stream.dataset:network_traffic.icmp
  and (network_traffic.icmp.request.type:(13 or 15) or icmp.request.type:(13 or 15))
  and destination.ip:(
    10.0.0.0/8 or
    172.16.0.0/12 or
    192.168.0.0/16
  )
  and not source.ip:(
    10.0.0.0/8 or
    100.64.0.0/10 or
    127.0.0.0/8 or
    169.254.0.0/16 or
    172.16.0.0/12 or
    192.168.0.0/16 or
    192.0.0.0/24 or
    192.0.0.0/29 or
    192.0.0.8/32 or
    192.0.0.9/32 or
    192.0.0.10/32 or
    192.0.0.170/32 or
    192.0.0.171/32 or
    192.0.2.0/24 or
    192.175.48.0/24 or
    192.31.196.0/24 or
    192.52.193.0/24 or
    192.88.99.0/24 or
    198.18.0.0/15 or
    198.51.100.0/24 or
    203.0.113.0/24 or
    224.0.0.0/4 or
    240.0.0.0/4 or
    "::1" or
    "FE80::/10" or
    "FF00::/8"
  )

Framework: MITRE ATT&CKTM

« Deprecated TLS Version or Weak Cipher Negotiated Externally Potential DHCP Starvation via High Client MAC Cardinality »