Services File Permissions Weakness (T1574.010) is a Windows technique in the stealth and execution tactics. The adversary hijacks the binary a service runs by taking advantage of flawed file permissions.
How attackers use it
Windows services run specific binaries automatically. If the permissions on the directory that holds a service binary, or on the binary itself, are set wrong, a user-level account may overwrite it. If the service runs at a higher privilege level, the replaced binary runs at that level too, which MITRE says could include SYSTEM.
Two outcomes follow. It can be a privilege escalation, because code runs in the service's context. And if the service starts on a schedule or at an event such as boot, it can serve as persistence.
How to detect it
MITRE's analytic watches for modification or replacement of service executables caused by weak permissions. Signals: file writes to service binary paths, unexpected changes to executables associated with registered services, and the service then running an attacker-supplied binary with elevated permissions.
The simplest rule: any write to a service binary outside a patch or install window deserves a ticket. Compare file hashes against a known baseline where you can.
How to reduce the risk
- User account management. Limit privileges of user accounts and groups so only authorized administrators can interact with service changes and the service binary target paths. Deny execution from user directories such as downloads and temp folders where able.
- Audit. Use auditing tools that find file system permission abuse opportunities and correct them. MITRE mentions PowerUp modules from the PowerSploit toolkit for service file permission weaknesses.
- User Account Control. MITRE describes denying elevation requests for standard users and enabling installer detection for all users.
Check your own environment
# Windows PowerShell: list services and their binary paths
Get-CimInstance Win32_Service | Select-Object Name,StartName,PathName
# Windows cmd: show who can modify a given service binary (replace the path)
icacls "C:\Program Files\ExampleApp\service.exe"
When reviewing icacls output, look for write or modify rights granted to broad groups such as Users or Authenticated Users on a service binary or its folder.
- Which services run as SYSTEM, and can anyone but administrators write to their binaries?
- Are third-party agents installed in folders with inherited broad write access?
- Do you monitor file changes under service install directories?
Quick check
Why is a writable service folder dangerous?
A low-privilege user can replace the binary, and the service will run the replacement with its own, often higher, privileges.
