Prove effective file, registry and service-object permissions
Needs: Correct trustee/token, object type and effective rights including parents and deny entries
Windows commands
REM Baseline
icacls "C:\Path\To\OBJECT"
sc.exe sdshow SERVICE
accesschk.exe -accepteula -nobanner -v -w "USER" "C:\Path\To\OBJECT"
accesschk.exe -accepteula -nobanner -v -w -c "USER" SERVICE
Verify → Name the exact allowed operation on the exact object and independently check a privileged consumer/trigger.
If it fails → Generic write labels can refer to another object or an inactive group. Resolve actual effective rights before modifying anything. More detail ↓
Explanation & examples
Prove effective file, registry and service-object permissions
- USE WHEN
- A privileged object appears writable or an ACL tool reports a useful right
- STARTING ACCESS
- A verified Windows foothold with a known token, integrity level and groups
- RESULT
- A specific confirmed control primitive for a privileged consumer
Recognize the clue
Take a real service/task/application path from inventory, then inspect its file, parent and separate service-object permissions.
icacls "C:\Path\To\OBJECT"
icacls "C:\Path\To"
sc.exe sdshow SERVICE
File: BUILTIN\Users:(RX)
Parent: DOMAIN\GROUP:(M)
Service-object rights: separate DACLMeans: A modifiable parent can differ from a read-only file; service configuration rights are another control plane.
Confirm: Use icacls/Get-Acl on the reported object and parents. For a service also inspect sc qc/sc sdshow; for a task inspect its action/principal. Check the specific write/replace/configuration operation and its trigger.
- After validation
- The intended effective operation and higher consumer are proved: select that object-control method.
- Ruled out in this context
- Only read/execute applies to the current token: reject the proposed modification.
- Still inconclusive
- An ACL for an inactive or ambiguous group leaves effective access unresolved.
Troubleshooting: Generic write labels can refer to another object or an inactive group. Resolve actual effective rights before modifying anything.
Additional prerequisite checks
whoami /all
icacls "C:\Path\To\OBJECT"
icacls "C:\Path\To"
sc.exe sdshow SERVICE
icacls common rights: F full, M modify, RX read/execute, R read, W write, D delete. Common inheritance markers: I, OI, CI, IO, NP.
File, directory, registry, service-object, task and process permissions are separate. Check whether the ACE applies to the current user or an enabled group and grants the exact required operation. Mandatory Integrity Control can still block a lower-integrity write.
Why it works
A service-object DACL controls operations such as configuration changes; the executable's filesystem ACL is separate. Parent delete/create rights can allow replacement without direct file modification.
Worked example · hypothetical
Observation: a service executable is read-only but its directory grants replacement rights. Test: inspect the effective token and parent permissions. Illustrative output: replacement is possible but service restart is denied. Interpretation: the control primitive is valid; the trigger remains missing.
New identity, privilege, host or route? Re-enumerate → All topic tasks →