Chinese Hacktool Set - file release.exe

Hunt Hypothesis

This hypothesis posits that adversaries are deploying a specific Chinese hacktool named release.exe to establish persistence or conduct reconnaissance within the environment. Proactive hunting for this artifact in Azure Sentinel is essential because its low-severity classification may cause it to be overlooked by automated alerts, allowing attackers to maintain a stealthy foothold before escalating their activities.

YARA Rule

rule FreeVersion_release {
	meta:
		description = "Chinese Hacktool Set - file release.exe"
		author = "Florian Roth"
		reference = "http://tools.zjqhr.com/"
		date = "2015-06-13"
		hash = "f42e4b5748e92f7a450eb49fc89d6859f4afcebb"
	strings:
		$s1 = "-->Got WMI process Pid: %d " ascii
		$s2 = "This exploit will execute \"net user " ascii
		$s3 = "net user temp 123456 /add & net localgroup administrators temp /add" fullword ascii
		$s4 = "Running reverse shell" ascii
		$s5 = "wmiprvse.exe" fullword ascii
		$s6 = "SELECT * FROM IIsWebInfo" fullword ascii
	condition:
		uint16(0) == 0x5a4d and filesize < 100KB and 3 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 6 string patterns in its detection logic.

References

• http://tools.zjqhr.com/
• Source Rule

False Positive Guidance

Here are 4 specific false positive scenarios for the Chinese Hacktool Set - file release.exe detection rule, including suggested filters and exclusions:

• Scenario 1: Microsoft Visual Studio Build Artifacts

  • Context: In development environments, build pipelines (e.g., Azure DevOps or Jenkins) frequently compile C++ projects using the MSVC toolchain. The standard output executable for many release builds is named release.exe, often generated in temporary directories like C:\Program Files\Microsoft Visual Studio\<Version>\Common7\Tools or within specific project build folders (e.g., bin\x64\Release).
  • Suggested Filter/Exclusion: Create an exclusion based on the Parent Process Name and File Path. Exclude events where the parent process is devenv.exe, msbuild.exe, or VSTestPlatform.exe AND the file path contains \Microsoft Visual Studio\ or ends with \bin\x64\Release\release.exe.

• Scenario 2: Scheduled System Maintenance Scripts

  • Context: Enterprise IT operations often utilize PowerShell or batch scripts scheduled via Windows Task Scheduler to perform nightly maintenance (e.g., log rotation, cache clearing). These scripts may invoke a custom utility named release.exe located in the system administration folder to manage software deployment states.
  • Suggested Filter/Exclusion: Implement an exclusion for events triggered by the Windows Task Scheduler Service (svchost.exe with command line containing TaskScheduler) or directly by powershell.exe. Add a path filter for files located in C:\ProgramData\CompanyIT\Maintenance\ or C:\Scripts\AdminTools\release.exe.

• Scenario 3: Third-Party Endpoint Management Deployments

  • Context: Tools like SCCM (Microsoft Configuration Manager), Intune,