This detection identifies potential SafeNet Sentinel SuperPro endpoint protection activities that may indicate an adversary attempting to evade security controls or establish persistence through automated defense mechanisms. SOC teams should proactively hunt for these signals in Azure Sentinel to distinguish between legitimate software updates and anomalous behaviors where attackers mimic trusted security processes to mask malicious operations.
rule SentinelSuperProAutomaticProtectionv640Safenet
{
meta:
author="malware-lu"
strings:
$a0 = { 68 [4] 6A 01 6A 00 FF 15 [4] A3 [4] FF 15 [4] 33 C9 3D B7 00 00 00 A1 [4] 0F 94 C1 85 C0 89 0D [4] 0F 85 [4] 55 56 C7 05 [4] 01 00 00 00 FF 15 [4] 01 05 [4] FF 15 }
condition:
$a0 at pe.entry_point
}
This YARA rule can be deployed in the following contexts:
This rule contains 1 string patterns in its detection logic.
Here are 5 specific false positive scenarios for the SentinelSuperProAutomaticProtectionv640Safenet detection rule, along with recommended filters and exclusions:
Scenario: Scheduled Antivirus Definition Updates via WSUS
ProcessName matches wuauserv.exe and the parent process is svchost.exe. Alternatively, add a time-based exclusion for the specific update window (e.g., 02:00 – 04:00 UTC) on all domain-joined endpoints.Scenario: Enterprise Backup Agent Scanning Protected Volumes
C:\ProgramData\SentinelOne directory to archive security logs and configuration files. The rule detects this file access as a potential “protection engine modification” event, flagging it as an anomaly when the backup agent is simply reading/writing metadata.vbrservice.exe (Veeam) or commvault.exe from triggering alerts when accessing paths containing \SentinelOne\. Implement a path-based exclusion: Path contains "C:\ProgramData\SentinelOne" AND ProcessName IN ("vbrservice.exe", "commvault.exe").Scenario: Group Policy Software Deployment of SafeNet Client