File Attributes and Locking: When Artifacts Resist Discovery or Removal
Attributes can reduce casual visibility, while open handles and sharing modes can prevent access, renaming, or deletion. Responders should identify the owning process and object state before remediation destroys volatile evidence.
No concealment or malicious locking procedures are included. Examples remain forensic and conceptual.
Resolve the object
Attributes describe properties such as hidden, system, read-only, compressed, or encrypted. Locks arise from handles, requested access, sharing modes, oplocks, mapped sections, and delete-pending state. A path-level error does not explain why an artifact persists.
Detection and response
- Unexpected hidden/system attributes in user-writable or startup locations.
- Repeated sharing violations, rename failures, or deletions around a rare process.
- Deleted files retained by executable mappings or handles.
- Attribute changes followed by persistence, execution, or archive staging.
Collect hashes, MFT/USN data, ACLs, handles, mapped images, lineage, services, tasks, and minifilter context; preserve memory before terminating a suspicious owner. Use Sysinternals, Velociraptor, MFTECmd, and Volatility 3. Validate telemetry with a benign text file held by a test application.
ATT&CK and controls
Hidden artifacts map to T1564.001; cleanup may map to T1070.004. These are normal OS features, not CVEs. Restrict writes, monitor sensitive paths, centralize selected object telemetry, and collect handle ownership before automated termination.