« Potential Network Scan Detected Uncommon Registry Persistence Change »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.37

Potential Low-Packet Port Scan Detected

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

Potential Low-Packet Port Scan Detected

edit

This rule identifies a potential low-packet port scan. It detects final flows or firewall connection attempts from one internal source to many destination ports on one destination and transport, while requiring no more than two packets in each matching observation. Attackers can use low-packet scans to identify exposed services while minimizing completed connections. Low packet count is a scan heuristic and does not by itself prove that the traffic contains bare TCP SYN packets.

Rule type: threshold

Rule indices:

  • logs-network_traffic.*
  • packetbeat-*
  • filebeat-*
  • logs-panw.panos*

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: 5

References: None

Tags:

  • Domain: Network
  • Tactic: Discovery
  • Tactic: Reconnaissance
  • Use Case: Network Security Monitoring
  • Data Source: PAN-OS
  • Resources: Investigation Guide
  • Noise: High
  • Performance: Normal
  • Profile: Aggressive
  • Rule Type: Threshold
  • Data Source: Network Packet Capture

Version: 17

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 Potential Low-Packet Port Scan Detected

Low-packet port scanning is a reconnaissance technique where an actor probes many ports while completing little or no application exchange. This method helps adversaries identify exposed services for potential exploitation. The rule flags final flows or firewall attempt records from an internal source to many ports on one destination and transport when each observation contains no more than two packets. The heuristic does not verify TCP SYN flags.

Possible investigation steps

  • Review the source IP address involved in the alert to determine if it belongs to a known or authorized scanner. Check for any recent changes or unusual activity associated with this IP.
  • Analyze the destination ports targeted by the scan to identify any patterns or specific services that may be of interest to the attacker. Determine if these ports are associated with critical or vulnerable services.
  • Review network.transport and raw flow or firewall records. For TCP, inspect TCP flags or connection state from another source before classifying the activity as a SYN scan.
  • Examine historical logs to identify any previous scanning activity from the same source IP or similar patterns of behavior. This can help establish whether the activity is part of a larger reconnaissance effort.
  • Correlate the alert with other security events or alerts to assess if there is a broader attack campaign underway. Look for related alerts that might indicate subsequent exploitation attempts.
  • Investigate the timing and frequency of the scan attempts to understand if they coincide with other suspicious activities or known attack windows. This can provide context on the attacker’s intent and urgency.
  • Assess the network’s current security posture and ensure that appropriate defenses, such as firewalls and intrusion detection systems, are configured to mitigate potential exploitation of identified open ports.

False positive analysis

  • Internal network scanning tools or scripts used by IT teams for legitimate network mapping can trigger this rule. To manage this, create exceptions for known internal IP addresses or subnets used by IT for network discovery.
  • Automated monitoring systems or security appliances that perform regular port checks might be flagged. Identify these systems and exclude their IP addresses from the rule to prevent false positives.
  • Software updates or patch management systems that check multiple ports for service availability can be mistaken for a low-packet port scan. Add exceptions for these systems after validation.
  • Load balancers or network devices that perform health checks across multiple ports may trigger the rule. Exclude these devices from the rule to ensure accurate detection.
  • Development or testing environments where multiple port scans are part of routine operations can cause false positives. Implement exceptions for these environments to maintain focus on genuine threats.

Response and remediation

  • Isolate the affected internal IP address to prevent further reconnaissance or potential exploitation of identified open ports.
  • Conduct a thorough review of firewall and network access control lists to ensure that only necessary ports are open and accessible from internal networks.
  • Implement appropriate connection-attempt rate limits or access controls to reduce unauthorized scanning.
  • Monitor the network for any unusual outbound traffic from the affected IP address, which may indicate further malicious activity or data exfiltration attempts.
  • Escalate the incident to the security operations team for further analysis and to determine if additional network segments or systems are affected.
  • Update intrusion detection and prevention systems to enhance detection capabilities for similar low-packet scanning activity.
  • Review and update network segmentation policies to limit the exposure of critical services and systems to internal reconnaissance activities.

Setup

edit

Setup

This rule supports final flow records from the Elastic Network Packet Capture integration and PAN-OS traffic attempt records. It also retains a compatibility branch for standalone Packetbeat.

Network Packet Capture 2.0.0 and later always applies ECS compatibility remapping. On earlier integration versions, enable map_to_ecs (the default since 1.31.1) so completed flows contain data_stream.dataset:network_traffic.flow, event.action:network_flow, and network_traffic.flow.final:true. The standalone Packetbeat branch uses the root flow.final field and requires type:flow.

This rule requires cumulative lifetime flow counters. For standalone Packetbeat, configure packetbeat.flows.enable_delta_flow_reports: false. Network Packet Capture package 1.34.3 does not expose that setting in its Fleet policy template and uses cumulative reports by default; verify the deployed package and agent version before relying on the rule. Delta flow reporting is unsupported because a final delta can contain zero or few packets even when the complete connection transferred many packets.

For PAN-OS, ingest TRAFFIC records through the PAN-OS integration. The rule counts session starts and does not include terminated, dropped, or denied flows.

The rule evaluates TCP and UDP separately. The network.packets <= 2 condition identifies low-packet observations but is not TCP-flag evidence. Create exceptions for approved scanners and monitoring infrastructure after validation.

Rule query

edit
(
  (
    data_stream.dataset:network_traffic.flow and
    event.action:network_flow and
    network_traffic.flow.final:true
  ) or
  (
    type:flow and
    event.action:network_flow and
    flow.final:true
  ) or
  (
    (data_stream.dataset:panw.panos or event.dataset:panw.panos) and
    panw.panos.type:TRAFFIC and
    event.action:flow_started
  )
) and
destination.port:* and
network.transport:(tcp or udp) and
network.packets <= 2 and
source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)

Framework: MITRE ATT&CKTM

« Potential Network Scan Detected Uncommon Registry Persistence Change »