Linux hack tools - file scanssh

Hunt Hypothesis

This detection identifies adversaries utilizing the scansh utility to enumerate and analyze shell scripts on Linux systems, a common reconnaissance step for identifying executable entry points or hidden backdoors. SOC teams should proactively hunt for this activity in Azure Sentinel because early discovery of script scanning behavior can reveal initial foothold establishment before attackers escalate to privilege escalation or lateral movement phases.

YARA Rule

rule LinuxHacktool_eyes_scanssh {
	meta:
		description = "Linux hack tools - file scanssh"
		author = "Florian Roth"
		reference = "not set"
		date = "2015/01/19"
		hash = "467398a6994e2c1a66a3d39859cde41f090623ad"
	strings:
		$s0 = "Connection closed by remote host" fullword ascii
		$s1 = "Writing packet : error on socket (or connection closed): %s" fullword ascii
		$s2 = "Remote connection closed by signal SIG%s %s" fullword ascii
		$s4 = "Reading private key %s failed (bad passphrase ?)" fullword ascii
		$s5 = "Server closed connection" fullword ascii
		$s6 = "%s: line %d: list delimiter not followed by keyword" fullword ascii
		$s8 = "checking for version `%s' in file %s required by file %s" fullword ascii
		$s9 = "Remote host closed connection" fullword ascii
		$s10 = "%s: line %d: bad command `%s'" fullword ascii
		$s13 = "verifying that server is a known host : file %s not found" fullword ascii
		$s14 = "%s: line %d: expected service, found `%s'" fullword ascii
		$s15 = "%s: line %d: list delimiter not followed by domain" fullword ascii
		$s17 = "Public key from server (%s) doesn't match user preference (%s)" fullword 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 13 string patterns in its detection logic.

References

• not set
• Source Rule

False Positive Guidance

Here are 5 specific false positive scenarios for the “Linux hack tools - file scansh” detection rule, including recommended filters and exclusions:

• Scenario: Automated vulnerability scanning by security teams using open-source tools.

  • Context: Security administrators frequently run lynis or trivy on production servers to assess hardening compliance. These tools perform deep recursive file system scans that mimic the behavior of threat hunting utilities, triggering the rule when they access kernel modules or configuration files in /etc.
  • Filter/Exclusion: Exclude processes matching ^(/usr/bin/lynis|/usr/local/bin/trivy)$ running under the user context of the dedicated security service account (e.g., secadmin).

• Scenario: Scheduled system health and integrity checks via cron jobs.

  • Context: The enterprise utilizes a nightly cron job running aide (Advanced Intrusion Detection Environment) to verify file integrity against a baseline database. This process iterates through thousands of files in /var, /opt, and /home, generating scan events that look like active threat hunting.
  • Filter/Exclusion: Create an exclusion for the command line containing --check or --audit executed by the system user (root) specifically during the maintenance window (e.g., 02:00–04:00 UTC).

• Scenario: Configuration management and drift detection tools.

  • Context: Infrastructure teams use ansible or puppet agents to push configuration updates. During the “gather_facts” phase, these agents scan directory structures to detect file changes before applying patches, which triggers the file scanning signature.
  • Filter/Exclusion: Filter out events where the parent process is python3 (for Ansible) or puppetd and the command line includes keywords like `