Create or Modify System Process

What the technique means

Create or Modify System Process describes the ability to start a new operating system process or alter an existing one with system-level context. On Windows and Unix-like systems alike, that means an actor can influence how code is launched, what context it inherits, and how its behaviour blends into normal administration or startup activity.

This matters because the technique is not just about “running a program”. It is about gaining control over execution flow in a place defenders often trust, which makes it a common foundation for payload execution, persistence, and post-compromise manipulation. The same primitive can be used legitimately by administrators and maliciously by attackers, so the surrounding context is what separates normal operations from abuse.

Why attackers value it

Attackers use process creation or modification to launch payloads, inject code, or alter execution behaviour without needing a separate noisy mechanism. A modified process can inherit privileges, environment variables, parent-child relationships, or startup paths that help the activity appear routine.

This is why the technique often appears alongside persistence, code injection, and defense evasion. The Persistence Techniques Guide is a useful companion here because it shows how attackers chain process manipulation with autostart mechanisms, service changes, and execution hijacking to keep access alive.

How defenders should interpret it

Process creation events become more valuable when read as a graph, not as isolated records. Unusual parent-child chains, unexpected command lines, integrity-level changes, and processes spawned from services, scripting hosts, or administration tools can all indicate that a normal launch path has been repurposed.

Defenders should also treat process modification as a trust issue. If an attacker can alter an existing process, they may be changing what that process loads, how it behaves, or what downstream actions it can perform. In practice, the key question is whether the observed execution matches the approved administrative pattern for that host and application.

For threat mapping, the MITRE ATT&CK Enterprise Matrix is the most direct reference for placing this activity in the broader adversary kill chain, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control lens for monitoring, auditability, and configuration discipline.

What good detection and hardening look like

Detection should focus on baseline deviation, not just raw volume. A small number of suspicious launches can matter more than a noisy host if the process tree, signer, image path, or elevation pattern is wrong for that environment. Post-incident review should include the full process ancestry, any injected modules or altered command lines, and whether the process was used to stage additional execution.

Hardening is largely about reducing the attacker’s freedom to shape execution. That includes constraining what can start processes, limiting who can alter them, and watching for integrity drift in high-value services and management tools. Where process activity is tied to access boundaries or privileged workflows, Zero Trust principles help keep execution decisions explicit rather than implicit. The NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture both reinforce that model.

Risk and Threat Considerations

Because this technique can hand an attacker a trusted execution context, the main risk is not the process itself but what it lets the attacker inherit, disguise, or redirect. That can turn a single execution event into persistence, code loading, privilege abuse, or lateral movement.

Failure mechanism: A malicious actor abuses process creation or modification to run code inside an approved execution path, or to change an existing process so its behaviour no longer matches its expected security boundary.

Impact: Defenders may miss the compromise if they only look for obviously malicious binaries, while the attacker gains a foothold that can support stealth, escalation, or repeated execution.

Practitioner Guidance

What to watch for: Prioritise process trees that do not fit the host role, especially processes spawned by unexpected parents, services, schedulers, scripting engines, or management tools. Integrity changes to long-lived or privileged processes deserve immediate review because they often indicate that execution has been repurposed rather than merely started.

Practitioner takeaway: Treat unusual process creation as a context problem, not just an event problem. The security value comes from understanding who launched it, why it launched, and what trust it inherited.

Related resources from NHI Mgmt Group

• Why do IT process automation tools create NHI risk?
• When does a ticketing process create more access risk than it reduces?
• Why do privileged credentials create more risk when system state is not tightly controlled?
• When does distributed identity create more risk than a central identity system?