A technique that uses legitimate interpreter or runtime loading behaviour to execute malicious code automatically when a process starts. In Python environments, .pth files are a common example, and the danger lies in using an approved mechanism to create hidden execution before many defenses activate.
How Path-Based Persistence Works
Path-based persistence exploits startup and import behaviour that defenders often consider normal. Instead of dropping a visible service or scheduled task, the attacker places code where an interpreter, runtime, or loader will automatically process it when a program starts, turning a trusted execution path into an activation point.
This matters because the malicious code runs before many endpoint, application, or user-initiated checks are engaged. The technique is not limited to Python, but Python .pth files are a familiar example because they can trigger code execution during interpreter initialisation without requiring an obvious launch command.
Why It Is Dangerous
Path-based persistence is dangerous because it hides inside legitimate configuration and loading mechanics. Security tools that focus on processes, autostart entries, or obvious binaries may miss it if they do not inspect the directories, startup hooks, and runtime search paths that a platform trusts by design.
The attacker gains durable execution that may survive normal application restarts, patching, or routine administrative review. In developer systems, shared build hosts, and automation environments, that can create a quiet foothold for credential theft, lateral movement, or repeated re-entry after cleanup.
Where Defenders Should Look
Exposure usually depends on whether the environment allows write access to locations that influence interpreter or loader startup. That includes site-packages, plugin paths, user-writable runtime directories, and any path that a language runtime or application loads automatically at launch.
Detection starts with inventorying which interpreters, runtimes, and loaders exist on the host and then checking those startup paths for unexpected files, path entries, or modified initialisation artefacts. Compare what is present with vendor documentation and with the behaviour that the platform normally expects during startup.
A useful review also asks whether those locations are writable by accounts that should not be able to influence execution. If they are, the persistence mechanism is already closer to an abuse path than a configuration detail.
Cleaning Up and Preventing Recurrence
Removal should include the malicious file or path entry, plus a review of whatever granted write access in the first place. If the actor used a startup hook to gain code execution, the environment may also contain staging files, modified packages, or adjacent loaders that need to be checked before declaring the system clean.
Prevention is strongest when runtime startup locations are treated as privileged surfaces. Lock down write permissions, monitor package and loader directories for unexpected changes, and validate interpreter behaviour after updates so that legitimate automation does not become an execution blind spot.
Risk and Threat Considerations
Path-based persistence is attractive to attackers because it blends into routine runtime behaviour and can be re-triggered every time the affected process starts. The main risk is not just initial execution, but long-term survival inside a trusted startup path that defenders may not inspect with the same urgency as a service binary or logon autorun.
Failure mechanism: A writable interpreter or loader path lets malicious code execute automatically at process start, which means the attacker can regain execution without relying on a new exploit each time.
Impact: The compromise can persist across reboots and application restarts, enabling repeated credential capture, reinfection, and follow-on activity that is harder to remove than a one-time payload.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1546 — Event Triggered Execution | Path-based persistence uses legitimate startup or loading behaviour to trigger code execution. |
| Recommendation — Map startup-hook abuse to T1546 and hunt for unexpected execution triggered by runtime initialisation. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Limiting who can alter startup paths directly reduces persistence via writable execution locations. |
| Recommendation — Restrict who can modify interpreter and loader paths to prevent unauthorized persistence. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Hardening and monitoring trusted software paths is a core secure-configuration problem. |
| Recommendation — Harden and monitor runtime startup paths for unauthorized files or configuration changes. | ||
Practitioner Guidance
What to watch for: Focus on startup locations that are supposed to be boring, such as language-specific package paths, plugin folders, and interpreter initialisation files. Unexpected files in those places deserve the same scrutiny as more obvious autostart mechanisms.
Governance implication: Ownership of runtime loading paths should be explicit. If multiple teams can install packages, deploy apps, or manage hosts, assign one group responsibility for monitoring the execution surfaces those actions create.
Related resources from NHI Mgmt Group
- Guide: Identity Threat Detection and Response (ITDR) Guide
- What do security teams get wrong about token-based persistence?
- What breaks when path-based security controls depend on framework matching alone?
- Who is accountable for stopping proxy-based persistence after intrusion?
- What is the difference between string-based path validation and realpath-based containment checks during extraction?