Executable Installer File Permissions Weakness (T1574.005) is a Windows technique in the stealth and execution tactics. The adversary hijacks the binaries an installer uses.
How attackers use it
Installers often run other binaries automatically as part of their work. If the permissions on the directory holding a target binary, or on the binary itself, are wrong, a user-level account can overwrite that binary. If the original process runs at a higher privilege level, the replacement runs at that level too, which MITRE says could include SYSTEM.
MITRE describes a second variation common in self-extracting installers. During installation they often unpack DLLs, EXEs or other payloads into a subdirectory of %TEMP%. When installers create those subdirectories and files without restricting write access, untrusted code placed there can run, or binaries used in the installation can be overwritten. This is related to DLL search order hijacking (T1574.001).
Some installers need elevated privileges, so this can lead to privilege escalation. MITRE also relates it to Bypass User Account Control (T1548.002).
How to detect it
MITRE's analytic looks for executables written or modified in installer directories, such as %TEMP% subdirectories or Program Files installer paths, followed by execution under an elevated context. Signals include abnormal file replacement, installer processes launching attacker-supplied binaries, and unexpected module loads in elevated processes.
The sequence matters most: a write by a low-privilege user, then a launch by a high-privilege installer.
How to reduce the risk
- Audit. Use tools that detect file system permission weaknesses and correct them. MITRE mentions PowerUp modules from the PowerSploit toolkit.
- User Account Control. MITRE describes denying elevation requests for standard users and enabling installer detection for all users, so installers prompt for a password.
- User account management. Limit privileges so only authorized administrators can touch service changes and service binary paths. Deny execution from user directories such as downloads and temp folders where possible.
Check your own environment
# Windows cmd: show who can write to a folder (replace the path)
icacls "C:\Program Files\ExampleApp"
- Do installers in your software catalog run from a user-writable temp folder with elevation?
- Can standard users write to Program Files subfolders on any managed machine?
- Is installer detection enabled?
Quick check
Why does a replaced installer binary run at high privilege?
The original process runs at a higher level, and it launches whatever binary sits at the target path, including a user-written replacement.
