Linux hack tools - file pscan2.c

Hunt Hypothesis

This detection rule identifies the presence of pscan2.c, a source code file commonly associated with post-exploitation reconnaissance and network scanning tools used by adversaries to map Linux environments. SOC teams should proactively hunt for this artifact in Azure Sentinel because its appearance often signals an attacker’s early-stage information gathering phase, enabling timely intervention before lateral movement or data exfiltration occurs.

YARA Rule

rule LinuxHacktool_eyes_pscan2_2 {
	meta:
		description = "Linux hack tools - file pscan2.c"
		author = "Florian Roth"
		reference = "not set"
		date = "2015/01/19"
		hash = "eb024dfb441471af7520215807c34d105efa5fd8"
	strings:
		$s0 = "snprintf(outfile, sizeof(outfile) - 1, \"scan.log\", argv[1], argv[2]);" fullword ascii
		$s2 = "printf(\"Usage: %s <b-block> <port> [c-block]\\n\", argv[0]);" fullword ascii
		$s3 = "printf(\"\\n# pscan completed in %u seconds. (found %d ips)\\n\", (time(0) - sca" ascii
		$s19 = "connlist[i].addr.sin_family = AF_INET;" fullword ascii
		$s20 = "snprintf(last, sizeof(last) - 1, \"%s.%d.* (total: %d) (%.1f%% done)\"," fullword ascii
	condition:
		2 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 5 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 pscan2.c detection rule, including targeted filters and exclusions:

• Scenario: Developer Environment Compilation

  • Context: In a Linux-based CI/CD pipeline or developer workstation, build agents frequently compile custom network scanning utilities. The source file pscan2.c is compiled into an executable during the daily “Build & Test” stage of the Jenkins/GitLab runner workflow.
  • Filter/Exclusion: Exclude file creation events where the parent process is a known CI tool (e.g., jenkins-agent, gitlab-runner) or located within standard build directories like /var/lib/jenkins/workspace or /home/dev/builds.

• Scenario: Scheduled Security Audit Script

  • Context: The enterprise security team runs a nightly cron job that deploys a custom port scanning utility to verify firewall rules. This script explicitly extracts and compiles pscan2.c from an internal repository before execution to ensure the latest logic is used for compliance reporting.
  • Filter/Exclusion: Create an exclusion rule based on the parent process name cron or systemd-cron, specifically when the file path matches /opt/security-audit/scripts/pscan2.c.

• Scenario: Automated Patch Management Deployment

  • Context: During a scheduled maintenance window, the IT operations team deploys a new version of an internal network monitoring agent via Ansible or SaltStack. The deployment playbook includes a step to copy and compile pscan2.c as part of the agent’s core module update on all Linux bastion hosts.
  • Filter/Exclusion: Filter events where the user context is a service account (e.g., ansible, salt-minion) or the file path resides in `/opt/internal-monitoring