Detecting create or modify system process (T1543)

What is T1543 — Create or modify system process?

MITRE ATT&CK® T1543 describes the technique of creating new system processes primarily Windows services or modifying existing ones to execute attacker-controlled code with elevated privileges. Windows services run as SYSTEM by default, making them a natural privilege escalation vehicle: create a service pointing to your malicious binary, start it, and your code runs as SYSTEM.

T1543 sub-technique T1543.003 (Windows Service) is the most prevalent on Windows endpoints. It encompasses three primary attack patterns: new service creation with a malicious binary, modification of an existing service's binary path, and kernel driver installation (both malicious drivers and bring-your-own-vulnerable-driver attacks). All three patterns are logged in Windows Event Logs and detectable by Log360's pre-built rule set. Comprehensive log collection from both Security and System channels is required for complete T1543 visibility.

How attackers create and modify system processes

The T1543 attack flow follows one of three primary paths, each requiring different detection approaches:

Path 1: New service creation (most common)

The attacker creates a new Windows service using sc.exe create [service-name] binpath= "[path-to-malware]" start= auto or equivalent PowerShell/WMI calls. The service is configured with automatic start type (runs at system boot) and defaults to running as SYSTEM. The attacker then starts the service immediately: sc.exe start [service-name]. The malicious binary executes as SYSTEM, granting full local privilege.

This creates Windows Event IDs 4697 (Security log) and 7045 (System log) with the service name, binary path, and creating account directly actionable by Log360's service creation rules.

Path 2: Service path tampering (stealth)

Rather than creating a visible new service, the attacker modifies an existing service's binary path to point to their malicious payload. On the next service restart or system reboot, the malicious binary runs as SYSTEM under a legitimate-looking service name. Unquoted service path vulnerabilities where a service binary path contains spaces and is unquoted allow attackers in lower-privilege directories to create a binary that Windows resolves before the legitimate service path. Log360's "Suspicious Service Path Modification" rule detects changes to service binary entries in the Windows registry. The file integrity monitoring capability complements registry-based detection by alerting on unauthorized binary replacements at the file system level.

Path 3: Kernel driver installation (highest privilege)

Windows kernel drivers run in kernel space with Ring-0 privileges the highest possible privilege level, above SYSTEM. Attackers install malicious or vulnerable kernel drivers using sc.exe create [name] type= kernel binpath= "[driver path]". Two variants exist: direct malicious driver installation (detected immediately by modern EDR and Log360), and Bring Your Own Vulnerable Driver (BYOVD) where a legitimately signed but vulnerable driver is loaded to exploit its vulnerability for unsigned kernel code execution.

Detection indicators for T1543

Effective T1543 detection combines service creation event analysis, process lineage monitoring, and binary path verification:

• Service binary paths in user-writable locations: Legitimate system services have binaries in C:\Windows\System32\, C:\Program Files\, or signed installer locations. Services with binaries in %TEMP%, %AppData%, user home directories, or network shares are immediately suspicious.
• Service creation by non-SYSTEM accounts via unusual parents: When sc.exe is spawned by scripting engines (wscript, cscript, powershell) or interactive user sessions rather than configuration management tools, it indicates manual attacker activity rather than legitimate software installation. Correlate with incident detection data from the same account to establish whether this is part of a broader compromise pattern.
• Critical process spawning anomalies: The processes wininit.exe, services.exe, and csrss.exe have well-defined parent processes in normal Windows operation. Any of these processes appearing with unexpected parents is a high-fidelity indicator of service manipulation or exploitation. Log360's "Suspicious parent spawning wininit/services/csrss" (Critical) rule targets this pattern.
• Kernel driver type in service creation: SC.EXE service creation with type= kernel parameter is rare in legitimate administrative operations. Any non-vendor, non-OS kernel driver installation warrants immediate review.
• Service modifications on existing critical services: Changes to service binary paths, start types, or account credentials for existing services especially Windows OS services should fire alerts. Log360's "Potential Persistence Attempt Via Existing Service Tampering" rule addresses this.

Log360 detection rules for T1543

Investigation steps

1. Verify the service binary: Extract the binary path from Event 4697 or 7045. Check whether the binary exists, verify its digital signature (unsigned binaries from non-vendor publishers are immediately suspicious), and check the file hash against VirusTotal or your threat intelligence platform. Log360 can integrate with VirusTotal for automated hash enrichment.
2. Trace the service creation source: Who created the service? What process spawned SC.EXE or the PowerShell cmdlet? Use Log360's process lineage view to trace the creation back through the parent chain. A user terminal, management tool, or legitimate installer are benign. A scripting engine, web server process, or unusual system process are red flags.
3. Check the parent process of services.exe: If Log360's "Suspicious parent spawning wininit/services/csrss" alert fired, investigate the anomalous parent immediately. This indicates that services.exe itself was spawned unexpectedly suggesting a service manipulation exploit rather than a simple new service creation.
4. Review service account and privileges: Was the service configured to run as SYSTEM, LocalService, NetworkService, or a custom high-privilege account? Services running as SYSTEM with no legitimate business need are escalation risks even when not immediately malicious.
5. Check for execution evidence: Has the service started? Look for Event ID 7036 (service entered running/stopped state) and any process creation events from the service binary after the 4697/7045 events. If the service executed, assess what actions the SYSTEM-level process performed.
6. Survey for companion techniques: T1543 is rarely standalone. Search the same time window for T1053 scheduled task creation, T1078 group membership changes, and credential access activity. These are the most common companion techniques in real-world T1543 incidents.

Response playbook

• Stop the malicious service immediately: Use sc.exe stop [service-name] followed by sc.exe delete [service-name]. For kernel driver services, use sc.exe stop first do not unload a kernel driver while it is active without understanding its cleanup behavior, as abrupt termination can cause system instability.
• Quarantine the service binary: Move the malicious binary to a quarantine location (do not delete it preserve it as forensic evidence). Compute the file hash and share it with your threat intelligence provider. Submit to VirusTotal if policy permits.
• For service path tampering: Restore the original service binary path to the legitimate value. If the original binary was replaced, restore from a known-good backup or system image. Check whether the tampering was made via registry modification and review the full registry audit trail.
• For kernel driver incidents: Treat as a critical incident requiring full incident response activation. A successfully loaded malicious or exploited kernel driver may have disabled security controls, hooked system calls, or hidden other malicious artifacts. A memory forensics investigation is strongly recommended before reimaging. Review threat hunting playbooks for post-kernel-compromise indicators established threat actors using BYOVD often have characteristic lateral movement behaviors that can be profiled with cyber threat intelligence.
• Audit all services on affected hosts: Use Get-Service | Select-Object Name, Status, StartType, @{N='BinaryPath';E={(Get-WmiObject Win32_Service -Filter "Name='$($_.Name)'").PathName}} to export a complete service listing from affected hosts and review for additional malicious entries created in the same attack window.
• Harden service creation controls: Restrict who can install services using Windows built-in privileges. Review the SeLoadDriverPrivilege and SeServiceLogonRight assignments. Implement WDAC policies preventing execution of unsigned binaries, which blocks most service-based T1543 attacks even when detection fails.

Explore related privilege escalation detection guides

Frequently asked questions