Rule to detect the screenlocker 5h311_1nj3c706

Hunt Hypothesis

This hunt targets adversaries deploying the ScreenLocker ransomware variant (identified by signature 5h311_1nj3c706) to lock user endpoints and disrupt business operations within the Azure Sentinel environment. Proactively hunting for this specific indicator is essential because, despite its low severity classification, early detection allows the SOC team to isolate affected assets before lateral movement occurs and prevents potential data encryption or extortion demands.

YARA Rule

rule screenlocker_5h311_1nj3c706 {

   meta:

      description = "Rule to detect the screenlocker 5h311_1nj3c706"
      author = "Marc Rivero | @seifreed"
      reference = "https://twitter.com/demonslay335/status/1038060120461266944"

   strings:

      $s1 = "C:\\Users\\Hoang Nam\\source\\repos\\WindowsApp22\\WindowsApp22\\obj\\Debug\\WindowsApp22.pdb" fullword ascii
      $s2 = "cmd.exe /cREG add HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\ActiveDesktop /v NoChangingWallPaper /t REG_DWOR" wide
      $s3 = "C:\\Users\\file1.txt" fullword wide
      $s4 = "C:\\Users\\file2.txt" fullword wide
      $s5 = "C:\\Users\\file.txt" fullword wide
      $s6 = " /v Wallpaper /t REG_SZ /d %temp%\\IMG.jpg /f" fullword wide
      $s7 = " /v DisableAntiSpyware /t REG_DWORD /d 1 /f" fullword wide
      $s8 = "All your file has been locked. You must pay money to have a key." fullword wide
      $s9 = "After we receive Bitcoin from you. We will send key to your email." fullword wide
   
   condition:

      ( uint16(0) == 0x5a4d and filesize < 200KB ) and 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 9 string patterns in its detection logic.

References

• https://twitter.com/demonslay335/status/1038060120461266944
• Source Rule

False Positive Guidance

Here are four specific false positive scenarios for the screenlocker 5h311_1nj3c706 detection rule, tailored for an enterprise environment:

• Endpoint Management Agent Health Checks

  • Scenario: The Microsoft Intune or Jamf Pro agent performs a scheduled health check and status reporting task every morning at 08:00. This process invokes the screen locker utility to verify user session integrity before syncing device compliance data, triggering the 5h311_1nj3c706 event even when no actual security threat is present.
  • Filter/Exclusion: Create an exclusion for processes originating from the specific service account (e.g., NT SERVICE\IntuneManagementExtension) and restrict the rule to trigger only outside of standard business hours (09:00–17:00) or exclude the specific process path C:\Program Files\Microsoft Intune Management Extension\.

• Automated Patch Deployment Cycles

  • Scenario: During the weekly Tuesday maintenance window, the Ivanti Endpoint Manager or SCCM (System Center Configuration Manager) deploys critical security patches. As part of the pre-deployment validation script, the system locks the user screen to prevent interaction during the installation phase, generating the 5h311_1nj3c706 alert as a standard operational artifact rather than an anomaly.
  • Filter/Exclusion: Whitelist the specific executable hash or process name associated with the patch deployment engine (e.g., ccmexec.exe or IvantiAgentService) and add a condition to suppress alerts if the parent process is identified as a known scheduled task (Task Scheduler).

• Third-Party DLP Policy Enforcement

  • Scenario: The enterprise Data Loss Prevention (D