Detect Systemd Service in Sumo Logic CSE
Adversaries may create or modify systemd services to repeatedly execute malicious payloads as part of persistence. Systemd is the default initialization system on many Linux distributions. Adversaries create new .service unit files or modify existing ones, placing them in /etc/systemd/system/, /lib/systemd/system/, or user-level ~/.config/systemd/user/ directories. The ExecStart, ExecStartPre, ExecReload, and ExecStop directives within service files execute commands when services start, reload, or stop. Threat actors including TeamTNT, Rocke, and Scattered Spider have leveraged systemd services for persistence and privilege escalation.
MITRE ATT&CK
- Tactic
- Persistence Privilege Escalation
- Technique
- T1543 Create or Modify System Process
- Sub-technique
- T1543.002 Systemd Service
- Canonical reference
- https://attack.mitre.org/techniques/T1543/002/
Sumo Detection Query
_sourceCategory=linux/sysmon
| json auto
| where EventID in ("1","11")
| eval TargetLower = toLower(coalesce(TargetFilename,""))
| eval ImageLower = toLower(coalesce(Image,""))
| eval CmdLower = toLower(coalesce(CommandLine,""))
| eval is_service_file = if(EventID == "11" AND (
TargetLower matches "/etc/systemd/system/.*\.service$" OR
TargetLower matches "/lib/systemd/system/.*\.service$" OR
TargetLower matches "/usr/lib/systemd/system/.*\.service$"), 1, 0)
| eval is_systemctl = if(EventID == "1" AND ImageLower matches ".*/systemctl$"
AND CmdLower matches ".*(enable|start).*"
AND (ParentImage matches ".*(bash|sh|python|curl|wget|ruby).*"), 1, 0)
| where is_service_file == 1 OR is_systemctl == 1
| eval SuspiciousDir = if(TargetLower matches "(/tmp/|/var/tmp/|/dev/shm/)", 1, 0)
| table _time, Computer, User, Image, CommandLine, TargetFilename, ParentImage, is_service_file, is_systemctl, SuspiciousDir
| sort by _time desc Detects systemd service persistence via Sysmon for Linux data in Sumo Logic.
Data Sources
Required Tables
False Positives & Tuning
- Package managers (apt, yum, dnf, rpm) installing legitimate software that includes systemd service units
- System administrators manually creating or modifying service files for legitimate infrastructure automation
- Configuration management tools (Ansible, Chef, Puppet, SaltStack) deploying service configurations
- Docker or container runtime installations that register systemd services
- Development environments where developers create test services locally
Other platforms for T1543.002
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Create Malicious Systemd Service for Persistence
Expected signal: Auditd SYSCALL=openat with path=/etc/systemd/system/df00tech-test.service and flags indicating file creation. Subsequent systemctl daemon-reload, enable, and start executions visible in auditd EXECVE records. MDE DeviceFileEvents shows FileCreated action for the .service file. DeviceProcessEvents shows systemctl invocations by root.
- Test 2User-Level Systemd Service Persistence (Non-Root)
Expected signal: File creation event for ~/.config/systemd/user/df00tech-user-test.service. Auditd records systemctl --user daemon-reload, enable, start. MDE DeviceFileEvents shows FileCreated with the user's home directory path. The initiating process AccountName matches the non-root test user.
- Test 3Systemd Service Mimicking Legitimate Service Name
Expected signal: Auditd and MDE file creation event for /etc/systemd/system/syslogd.service. The IsSuspiciousName flag in the KQL detection should evaluate to true based on the 'syslogd' service name match. DeviceProcessEvents shows systemctl enable syslogd.service.
- Test 4Systemd Generator for Dynamic Service Creation
Expected signal: File creation event for the generator script in /usr/local/lib/systemd/system-generators/. Subsequent daemon-reload execution triggers the generator, creating a .service file in /run/systemd/generator/. Auditd records the EXECVE of the generator script during daemon-reload. The generated service file appears in a systemd-controlled temporary directory.
References (10)
- https://attack.mitre.org/techniques/T1543/002/
- https://www.freedesktop.org/software/systemd/man/systemd.service.html
- http://man7.org/linux/man-pages/man1/systemd.1.html
- https://www.anomali.com/blog/rocke-evolves-its-arsenal-with-a-new-malware-family-written-in-golang
- https://www.elastic.co/security-labs/primer-on-persistence-mechanisms
- https://pberba.github.io/security/2022/01/30/linux-threat-hunting-for-persistence-systemd-timers-cron/
- https://pberba.github.io/security/2022/02/07/linux-threat-hunting-for-persistence-systemd-generators/
- https://redcanary.com/blog/attck-t1501-understanding-systemd-service-persistence/
- https://symantec-enterprise-blogs.security.com/threat-intelligence/troll-stealer-lazarus-group
- https://www.rapid7.com/db/modules/exploit/linux/local/service_persistence
Unlock Pro Content
Get the full detection package for T1543.002 including response playbook, investigation guide, and atomic red team tests.