Rule to detect Acroware ScreenLocker

Hunt Hypothesis

This hypothesis posits that adversaries may deploy Acroware ScreenLocker to establish persistent screen monitoring and enforce access controls within the Azure environment. Proactively hunting for this behavior is essential to distinguish legitimate administrative deployments from unauthorized surveillance tools that could be used to exfiltrate sensitive visual data or mask malicious user activity.

YARA Rule

rule screenlocker_acroware {

   meta:

      description = "Rule to detect Acroware ScreenLocker"
      author = "Marc Rivero | @seifreed"
      reference = "https://www.bleepingcomputer.com/news/security/the-week-in-ransomware-august-31st-2018-devs-on-vacation/"
      
   strings:

      $s1 = "C:\\Users\\patri\\Documents\\Visual Studio 2015\\Projects\\Advanced Ransi\\Advanced Ransi\\obj\\Debug\\Advanced Ransi.pdb" fullword ascii
      $s2 = "All your Personal Data got encrypted and the decryption key is stored on a hidden" fullword ascii
      $s3 = "alphaoil@mail2tor.com any try of removing this Ransomware will result in an instantly " fullword ascii
      $s4 = "HKEY_CURRENT_USER\\SoftwareE\\Microsoft\\Windows\\CurrentVersion\\Run" fullword wide
      $s5 = "webserver, after 72 hours the decryption key will get removed and your personal" fullword ascii
      
   condition:
      ( uint16(0) == 0x5a4d and filesize < 2000KB ) 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 5 string patterns in its detection logic.

References

False Positive Guidance

Here are 4 specific false positive scenarios for the Acroware ScreenLocker detection rule, along with suggested filters and exclusions:

Scheduled Group Policy Deployment of ScreenLocker Configuration
- Scenario: During a weekly maintenance window (e.g., Sunday at 02:00 UTC), the IT Operations team pushes updated GPO policies to enforce new ScreenLocker timeout settings across all workstations. This triggers the detection rule as the Acroware.ScreenLocker.Service process initiates configuration changes on hundreds of endpoints simultaneously, mimicking a potential unauthorized policy enforcement or tampering event.
- Suggested Filter/Exclusion: Create an exclusion based on the Source IP belonging to the Domain Controller (e.g., 10.20.30.5) and restrict the trigger time window to Sunday 01:00 - 04:00 UTC. Additionally, filter for event IDs specifically related to “Policy Update” rather than “Session Lock.”
Patch Management Execution via SCCM (System Center Configuration Manager)
- Scenario: The patch management team utilizes Microsoft SCCM to deploy a critical security update for the Acroware ScreenLocker agent. During the deployment, the wuauserv or ccmexec service interacts with the ScreenLocker binaries to install updates and restart services. This activity generates file integrity alerts and process execution logs that match the rule’s logic for “ScreenLocker Activity,” even though it is a planned maintenance task.
- Suggested Filter/Exclusion: Exclude events where the Parent Process is ccmexec.exe or wuauserv.exe. Furthermore, add a condition to suppress alerts if the File Hash of the modified ScreenLocker binary matches the known “Good” baseline hash stored in your CMDB.
**Endpoint Detection and Response (EDR