Create or Modify System Process (T1543): How to detect malicious service persistence

What is Create or Modify System Process?

Windows services are the backbone of operating system functionality, hundreds of them run silently in the background, starting at boot, executing with SYSTEM privileges, and restarting automatically on failure. Attackers exploit this by creating their own malicious services or modifying existing legitimate ones. T1543 covers these techniques, with T1543.003 (Windows Service) being the dominant sub-technique in enterprise environments.

Service-based persistence is particularly dangerous because it provides three things at once: automatic execution at boot, SYSTEM-level privileges (the highest on the local machine), and automatic restart if the service crashes or is killed. Ransomware operators favor this technique because a malicious service can survive reboots, re-download payloads, and re-encrypt files even after initial cleanup, which is why the CrowdStrike 2026 Global Threat Report identifies service installation as a top-5 persistence mechanism across ransomware campaigns.

Part of the Persistence (TA0003) tactic in the MITRE ATT&CK® framework.

Key facts about T1543

How the attack works: Attack scenario

Stage 1: Obtain elevated access

Service creation requires administrative privileges. The attacker achieves this through credential theft, privilege escalation, or exploitation, often combining Initial Access (TA0001) with Execution (TA0002). Groups like Wizard Spider commonly obtain domain admin credentials before installing services to ensure persistence at the highest privilege level.

Stage 2: Service installation

The attacker uses sc.exe create, PowerShell New-Service, or the Windows API to register a new service. The service binary points to the attacker's payload, and the startup type is set to Automatic so it launches at every boot. Alternatively, the attacker modifies the binary path of an existing legitimate service - a subtler approach that does not create any new service entries.

What this looks like in logs:

The attacker chose a name that mimics legitimate Windows services and placed the binary in a writable system directory. The auto-start type and LocalSystem account ensure the payload runs with maximum privileges at every boot.

Stage 3: Persistent SYSTEM execution

On reboot, the Service Control Manager starts the malicious service. The payload executes as LocalSystem, re-establishes C2, and the attacker has persistent high-privilege access. If the service crashes, the Service Control Manager restarts it automatically, a feature designed for reliability that attackers exploit for resilience.

Real-world attacks using T1543

How to detect and investigate T1543 with Log360

Log360's detection engine monitors service installation and modification events in real time, applying process lineage analysis to identify malicious service creation.

Detecting critical process manipulation

The most dangerous form of T1543 abuse involves replacing or injecting into core Windows processes. The Suspicious parent spawning wininit/services/csrss rule (Critical, Windows) detects when an unexpected parent process spawns wininit.exe, services.exe, or csrss.exe, the foundational processes of the Windows boot sequence. In normal operations, only smss.exe and the Windows kernel spawn these processes. When another process spawns them, it indicates process injection, replacement, or a rootkit-level attack that compromises the integrity of the entire operating system. This is the highest-severity persistence detection because it represents complete system compromise.

Detecting service creation via command-line tools

The most common method of service creation is through sc.exe. Log360's New Service Creation Using Sc.EXE rule (Attention, Windows) monitors for sc.exe create commands, providing broad visibility into all command-line service installations. The Attention severity reflects that sc.exe service creation is also used by legitimate administrators, so context is needed to triage, the alert includes the full command line, creating user, and binary path for rapid evaluation.

When the new service is a kernel-mode driver, the threat level escalates significantly. The New Kernel Driver Via SC.EXE rule (Trouble, Windows) fires when sc.exe creates a service with type=kernel, indicating the installation of a kernel driver, the mechanism used for rootkit persistence and the most deeply embedded form of system compromise. Legitimate kernel driver installation is rare in operational environments and almost always associated with planned software deployments, not ad-hoc sc.exe commands.

Detecting service tampering

Rather than creating new services, sophisticated attackers modify existing ones. The Suspicious Service Path Modification rule (Trouble, Windows) catches modifications to the binary path of existing services, the attacker changes where the service binary points, so an existing trusted service launches attacker code instead. This technique bypasses security controls that focus on new service creation because no new service entry appears. The Potential Persistence Attempt Via Existing Service Tampering rule (Trouble, Windows) provides broader coverage for service configuration changes that indicate tampering, including modifications to service accounts, dependencies, and failure recovery actions.

For general suspicious service creation patterns, the Suspicious New Service Creation rule (Trouble, Windows) applies heuristic analysis to new service events, flagging services with suspicious binary paths, unusual service accounts, or naming patterns that mimic legitimate Windows services.

Investigation workflow in Log360

1. Verify the service binary path: Open the alert and examine the service file name. Legitimate services reference signed binaries in C:\Windows\System32\ or C:\Program Files\. Binaries in Temp, AppData, or Public directories are strong compromise indicators.
2. Check the creating process: Identify what process called sc.exe or the service creation API. If the parent is PowerShell, cmd.exe, or a dropped binary, trace the process chain backward to find the execution origin.
3. Validate the service account: Services running as LocalSystem have maximum privileges. If a newly created service uses LocalSystem without a corresponding change ticket, escalate immediately.
4. Search for upstream events: Use Log360's correlated timeline to find Execution and Initial Access events on the same host. Service creation follows code execution, and the execution event reveals how the attacker got there.
5. Check for lateral deployment: Search for the same service name or binary path across all monitored hosts. Attackers using tools like PsExec deploy services across multiple systems simultaneously.

Behavioral detection with UEBA

Log360's UEBA module baselines service creation patterns per host role. A domain controller that suddenly gains a new user-mode service, or a file server where sc.exe runs for the first time, receives an elevated risk score even if the service binary path appears benign.

How to remediate and prevent T1543 attacks with Log360

Immediate containment

1. Stop the malicious service: Use sc stop "ServiceName" to halt the service, then sc delete "ServiceName" to remove it. For service tampering, restore the original binary path from backup or baseline.
2. Kill the service process: If the service has spawned child processes or established C2, terminate the process tree before removing the service.
3. Isolate the host: Move the compromised system to quarantine while investigating for additional persistence mechanisms and lateral movement.

Root cause remediation

• Trace the privilege source: Service creation requires admin privileges. Investigate how the attacker obtained them, credential theft, privilege escalation, or initial exploitation.
• Rotate service account credentials: If the attacker created or modified services running under domain service accounts, rotate those credentials immediately.
• Check for companion persistence: Service persistence is often paired with scheduled tasks (T1053) and Registry Run Keys (T1547) for redundancy. Search for all persistence types in the same time window.

Long-term hardening

• Enforce driver signing: Enable Windows Driver Signature Enforcement and Secure Boot to prevent unsigned kernel driver installation, per CIS Controls guidance.
• Restrict sc.exe usage: Use AppLocker or Windows Defender Application Control (WDAC) to limit sc.exe execution to approved administrative accounts and processes.
• Baseline services per server role: Document approved services for each server type (DC, file server, web server). Automated monitoring flags any deviation.
• Monitor Event IDs 4697 and 7045: Ensure both Security and System log service installation events are forwarded to Log360, per NIST CSF monitoring guidance.

Log360 automated response configuration

Configure automated responses via Log360's SOAR framework:

• Block and disable: For Critical-severity alerts (suspicious critical process spawning), automatically disable the creating account and isolate the host via network integration.
• Create incident ticket: Auto-create a ServiceDesk Plus ticket with service name, binary path, creating process, and host details.
• Evidence collection script: Execute a PowerShell script that captures the running service list, process tree, and network connections for forensic preservation.

Need to explore ManageEngine Log360? Schedule a personalized demo

FAQ