Detect Services File Permissions Weakness in Microsoft Sentinel
Adversaries may replace service executable binaries by exploiting weak file or directory permissions on service binaries. Windows services run with specific account privileges (often SYSTEM, LocalService, or NetworkService). If the permissions on the service binary or its parent directory allow non-privileged users to write, an adversary can overwrite the binary with a malicious payload. When the service starts (on reboot or manually), the malicious binary executes at the service's privilege level. BlackEnergy malware used this technique to replace disabled driver service binaries and then re-enable the service for persistence. PowerSploit's Get-ModifiableServiceFile discovers exploitable service binaries.
MITRE ATT&CK
- Technique
- T1574 Hijack Execution Flow
- Sub-technique
- T1574.010 Services File Permissions Weakness
- Canonical reference
- https://attack.mitre.org/techniques/T1574/010/
KQL Detection Query
DeviceFileEvents
| where Timestamp > ago(24h)
| where ActionType in ("FileModified", "FileCreated")
| where FileName endswith ".exe" or FileName endswith ".dll"
| where FolderPath has_any ("\\Program Files\\", "\\Program Files (x86)\\", "\\Windows\\")
| where not(InitiatingProcessFileName in~ ("msiexec.exe", "wusa.exe", "trustedinstaller.exe", "svchost.exe"))
| where InitiatingProcessAccountName != "SYSTEM"
| where InitiatingProcessAccountName != "NT AUTHORITY"
| where InitiatingProcessAccountName != ""
| join kind=leftouter (
DeviceRegistryEvents
| where Timestamp > ago(24h)
| where RegistryKey has "Services"
| where RegistryValueName =~ "ImagePath"
| extend ServiceName = extract(@"Services\\([^\\]+)\\ImagePath", 1, RegistryKey)
| project DeviceId, ServiceName, ImagePath=RegistryValueData
) on DeviceId
| where ImagePath has FileName
| project Timestamp, DeviceName, AccountName=InitiatingProcessAccountName, FileName, FolderPath, ServiceName, SHA256
| sort by Timestamp descDetects modification of service binary files by non-SYSTEM, non-installer accounts. The query correlates file modification events on EXE/DLL files in service installation directories with the Services registry hive to identify which service is affected. A non-privileged account modifying a service binary is a direct indicator of file permission weakness exploitation.
Data Sources
Required Tables
False Positives & Tuning
- Software auto-updaters that replace service binaries during updates (often run with user-level permissions rather than SYSTEM)
- IT management tools (SCCM, Intune) that update service binaries as part of software deployment
- Antivirus self-update mechanisms that replace their own service binaries
- Some developer workflows where the developer account has write access to Program Files for testing
Other platforms for T1574.010
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Check Service Binary Permissions for Exploitation
Expected signal: PowerShell process creation with WMI Win32_Service query and file ACL enumeration. Sysmon Event ID 19 may log the WMI query. Multiple file read operations to check ACLs on service binaries.
- Test 2Simulate Service Binary Replacement (Hash-Verified)
Expected signal: Service creation event (Security Event ID 7045). File modification event (Sysmon EventCode 11) for test_svc.exe after replacement. Hash change detectable via Sysmon event which includes SHA256.
- Test 3Verify Service Permission Using AccessChk
Expected signal: Process creation for accesschk.exe or icacls.exe with Program Files as target. These tools inspect file ACLs without modifying them. Security audit logs may capture the file access depending on auditing configuration.
Unlock Pro Content
Get the full detection package for T1574.010 including response playbook, investigation guide, and atomic red team tests.