Generic rule for NMAP - based on NMAP 4 standalone

Hunt Hypothesis

This detection identifies adversaries conducting network reconnaissance by executing standalone Nmap scans to map host availability and open ports within the environment. A proactive hunt is essential in Azure Sentinel to uncover early-stage threat actors who are gathering infrastructure intelligence before initiating lateral movement or data exfiltration attacks.

YARA Rule

rule iKAT_tools_nmap {
	meta:
		description = "Generic rule for NMAP - based on NMAP 4 standalone"
		author = "Florian Roth"
		date = "05.11.14"
		score = 50
		reference = "http://ikat.ha.cked.net/Windows/functions/ikatfiles.html"
		hash = "d0543f365df61e6ebb5e345943577cc40fca8682"
	strings:
		$s0 = "Insecure.Org" fullword wide
		$s1 = "Copyright (c) Insecure.Com" fullword wide
		$s2 = "nmap" fullword nocase
		$s3 = "Are you alert enough to be using Nmap?  Have some coffee or Jolt(tm)." ascii
	condition:
		all of them
}

Deployment Notes

This YARA rule can be deployed in the following contexts:

• Microsoft Defender for Endpoint — Custom indicators / advanced hunting
• Email Gateway — Attachment scanning
• File Share Monitoring — Periodic scanning of shared drives
• YARA CLI — Manual threat hunting on endpoints

This rule contains 4 string patterns in its detection logic.

References

• http://ikat.ha.cked.net/Windows/functions/ikatfiles.html
• Source Rule

False Positive Guidance

Here are specific false positive scenarios and corresponding exclusions for the Generic rule for NMAP detection logic:

• Scenario: Scheduled Vulnerability Assessment Scans

  • Context: Security teams often run automated vulnerability scans using tools like Tenable Nessus, Qualys, or OpenVAS. These tools utilize Nmap under the hood to perform port discovery and service enumeration across the entire enterprise network on a weekly basis.
  • Filter/Exclusion: Create an exclusion rule that filters out traffic originating from known scanner IP addresses (e.g., 10.50.10.20 for Nessus) or restricts detection to non-business hours if scans are scheduled overnight.

• Scenario: IT Admin Network Inventory Audits

  • Context: System Administrators frequently use the command-line Nmap tool (or GUI wrappers like Zenmap) during change management windows to document new server deployments, verify firewall rule effectiveness, or map network topology before decommissioning hardware.
  • Filter/Exclusion: Implement a whitelist based on specific Service Accounts (e.g., svc-netadmin, svc-inventory) and restrict the rule trigger to traffic coming from the “Management VLAN” subnet where admin workstations reside.

• Scenario: Third-Party Compliance & Penetration Testing

  • Context: External security firms or internal compliance teams conduct quarterly penetration tests using Nmap scripts (--script vuln, --script discovery) to validate regulatory requirements (e.g., PCI-DSS, SOC2). These scans often mimic external attack patterns.
  • Filter/Exclusion: Establish a temporary exclusion window (e.g., 08:00–17:00 on Tuesdays and Thursdays) during known audit periods, or filter by the specific User-Agent string if the scanner identifies itself as `Nmap