Adversaries may create or modify Windows services to repeatedly execute malicious payloads as part of persistence. When Windows boots up, it starts programs or applications called services that perform background system functions.^[1] Windows service configuration information, including the file path to the service's executable or recovery programs/commands, is stored in the Windows Registry.

Adversaries may install a new service or modify an existing service to execute at startup in order to persist on a system. Service configurations can be set or modified using system utilities (such as sc.exe), by directly modifying the Registry, or by interacting directly with the Windows API.

Adversaries may also use services to install and execute malicious drivers. For example, after dropping a driver file (ex: .sys) to disk, the payload can be loaded and registered via Native API functions such as CreateServiceW() (or manually via functions such as ZwLoadDriver() and ZwSetValueKey()), by creating the required service Registry values (i.e. Modify Registry), or by using command-line utilities such as PnPUtil.exe.^[2],[3],[4] Adversaries may leverage these drivers as Rootkits to hide the presence of malicious activity on a system. Adversaries may also load a signed yet vulnerable driver onto a compromised machine (known as "Bring Your Own Vulnerable Driver" (BYOVD)) as part of Exploitation for Privilege Escalation.^[5],[4]

Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges. Adversaries may also directly start services through Service Execution.

To make detection analysis more challenging, malicious services may also incorporate Masquerade Task or Service (ex: using a service and/or payload name related to a legitimate OS or benign software component). Adversaries may also create ‘hidden’ services (i.e., Hide Artifacts), for example by using the sc sdset command to set service permissions via the Service Descriptor Definition Language (SDDL). This may hide a Windows service from the view of standard service enumeration methods such as Get-Service, sc query, and services.exe.^[6],[7]

References

1. Microsoft. (n.d.). Services. Retrieved June 7, 2016.
2. Nicolas Falliere, Liam O. Murchu, Eric Chien. (2011, February). W32.Stuxnet Dossier. Retrieved December 7, 2020.
3. Thomas, W. et al. (2022, February 25). CrowdStrike Falcon Protects from New Wiper Malware Used in Ukraine Cyberattacks. Retrieved March 25, 2022.
4. Reichel, D. and Idrizovic, E. (2020, June 17). AcidBox: Rare Malware Repurposing Turla Group Exploit Targeted Russian Organizations. Retrieved March 16, 2021.
5. Hromcova, Z. and Cherpanov, A. (2020, June). INVISIMOLE: THE HIDDEN PART OF THE STORY. Retrieved July 16, 2020.
6. Joshua Wright. (2020, October 13). Retrieved March 22, 2024.
7. Joshua Wright. (2020, October 14). Retrieved March 22, 2024.

Adversaries may create or modify Launch Daemons to execute malicious payloads as part of persistence. Launch Daemons are plist files used to interact with Launchd, the service management framework used by macOS. Launch Daemons require elevated privileges to install, are executed for every user on a system prior to login, and run in the background without the need for user interaction. During the macOS initialization startup, the launchd process loads the parameters for launch-on-demand system-level daemons from plist files found in /System/Library/LaunchDaemons/ and /Library/LaunchDaemons/. Required Launch Daemons parameters include a Label to identify the task, Program to provide a path to the executable, and RunAtLoad to specify when the task is run. Launch Daemons are often used to provide access to shared resources, updates to software, or conduct automation tasks.^[1],[2],[3]

Adversaries may install a Launch Daemon configured to execute at startup by using the RunAtLoad parameter set to true and the Program parameter set to the malicious executable path. The daemon name may be disguised by using a name from a related operating system or benign software (i.e. Masquerading). When the Launch Daemon is executed, the program inherits administrative permissions.^[4],[5]

Additionally, system configuration changes (such as the installation of third party package managing software) may cause folders such as usr/local/bin to become globally writeable. So, it is possible for poor configurations to allow an adversary to modify executables referenced by current Launch Daemon's plist files.^[6],[7]

References

1. Apple. (n.d.). Creating Launch Daemons and Agents. Retrieved July 10, 2017.
2. Patrick Wardle. (2014, September). Methods of Malware Persistence on Mac OS X. Retrieved July 5, 2017.
3. Dennis German. (2020, November 20). launchd Keywords for plists. Retrieved October 7, 2021.
4. Claud Xiao. (n.d.). WireLurker: A New Era in iOS and OS X Malware. Retrieved July 10, 2017.
5. Patrick Wardle. (2016, February 29). Let's Play Doctor: Practical OS X Malware Detection & Analysis. Retrieved November 17, 2024.
6. Bradley Kemp. (2021, May 10). LaunchDaemon Hijacking: privilege escalation and persistence via insecure folder permissions. Retrieved July 26, 2021.
7. Stokes, Phil. (2019, June 17). HOW MALWARE PERSISTS ON MACOS. Retrieved September 10, 2019.

Adversaries may create or modify container or container cluster management tools that run as daemons, agents, or services on individual hosts. These include software for creating and managing individual containers, such as Docker and Podman, as well as container cluster node-level agents such as kubelet. By modifying these services, an adversary may be able to achieve persistence or escalate their privileges on a host.

For example, by using the docker run or podman run command with the restart=always directive, a container can be configured to persistently restart on the host.^[1] A user with access to the (rootful) docker command may also be able to escalate their privileges on the host.^[2]

In Kubernetes environments, DaemonSets allow an adversary to persistently Deploy Containers on all nodes, including ones added later to the cluster.^[3],[4] Pods can also be deployed to specific nodes using the nodeSelector or nodeName fields in the pod spec.^[5],[6]

Note that containers can also be configured to run as Systemd Services.^[7],[8]

References

1. Ofek Itach and Assaf Morag. (2023, July 13). TeamTNT Reemerged with New Aggressive Cloud Campaign. Retrieved February 15, 2024.
2. GTFOBins. (n.d.). docker. Retrieved February 15, 2024.
3. Michael Katchinskiy, Assaf Morag. (2023, April 21). First-Ever Attack Leveraging Kubernetes RBAC to Backdoor Clusters. Retrieved July 14, 2023.
4. Kubernetes. (n.d.). DaemonSet. Retrieved February 15, 2024.
5. Kubernetes. (n.d.). Assigning Pods to Nodes. Retrieved February 15, 2024.
6. Abhisek Datta. (2020, March 18). Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1. Retrieved January 16, 2024.
7. Valentin Rothberg. (2022, March 16). How to run pods as systemd services with Podman. Retrieved February 15, 2024.
8. Docker. (n.d.). Start containers automatically. Retrieved February 15, 2024.

Adversaries may create or modify launch agents to repeatedly execute malicious payloads as part of persistence. When a user logs in, a per-user launchd process is started which loads the parameters for each launch-on-demand user agent from the property list (.plist) file found in /System/Library/LaunchAgents, /Library/LaunchAgents, and ~/Library/LaunchAgents.^[1],[2],[3] Property list files use the Label, ProgramArguments , and RunAtLoad keys to identify the Launch Agent's name, executable location, and execution time.^[4] Launch Agents are often installed to perform updates to programs, launch user specified programs at login, or to conduct other developer tasks.

Launch Agents can also be executed using the Launchctl command.

Adversaries may install a new Launch Agent that executes at login by placing a .plist file into the appropriate folders with the RunAtLoad or KeepAlive keys set to true.^[5],[6] The Launch Agent name may be disguised by using a name from the related operating system or benign software. Launch Agents are created with user level privileges and execute with user level permissions.^[7],[8]

References

1. Apple. (n.d.). Creating Launch Daemons and Agents. Retrieved July 10, 2017.
2. Marc-Etienne M.Leveille. (2016, July 6). New OSX/Keydnap malware is hungry for credentials. Retrieved July 3, 2017.
3. Thomas Reed. (2017, January 18). New Mac backdoor using antiquated code. Retrieved July 5, 2017.
4. Thomas Reed. (2017, July 7). New OSX.Dok malware intercepts web traffic. Retrieved July 10, 2017.
5. Dani Creus, Tyler Halfpop, Robert Falcone. (2016, September 26). Sofacy's 'Komplex' OS X Trojan. Retrieved July 8, 2017.
6. Patrick Wardle. (2014, September). Methods of Malware Persistence on Mac OS X. Retrieved July 5, 2017.
7. Patrick Wardle. (2016, February 29). Let's Play Doctor: Practical OS X Malware Detection & Analysis. Retrieved November 17, 2024.
8. Eddie Lee. (2016, February 17). OceanLotus for OS X - an Application Bundle Pretending to be an Adobe Flash Update. Retrieved July 5, 2017.

Adversaries may create or modify systemd services to repeatedly execute malicious payloads as part of persistence. Systemd is a system and service manager commonly used for managing background daemon processes (also known as services) and other system resources.^[1] Systemd is the default initialization (init) system on many Linux distributions replacing legacy init systems, including SysVinit and Upstart, while remaining backwards compatible.

Systemd utilizes unit configuration files with the .service file extension to encode information about a service's process. By default, system level unit files are stored in the /systemd/system directory of the root owned directories (/). User level unit files are stored in the /systemd/user directories of the user owned directories ($HOME).^[2]

Inside the .service unit files, the following directives are used to execute commands:^[3]

• ExecStart, ExecStartPre, and ExecStartPost directives execute when a service is started manually by systemctl or on system start if the service is set to automatically start.
• ExecReload directive executes when a service restarts.
• ExecStop, ExecStopPre, and ExecStopPost directives execute when a service is stopped.

Adversaries have created new service files, altered the commands a .service file’s directive executes, and modified the user directive a .service file executes as, which could result in privilege escalation. Adversaries may also place symbolic links in these directories, enabling systemd to find these payloads regardless of where they reside on the filesystem.^[4],[5],[6]

The .service file’s User directive can be used to run service as a specific user, which could result in privilege escalation based on specific user/group permissions.

Systemd services can be created via systemd generators, which support the dynamic generation of unit files. Systemd generators are small executables that run during boot or configuration reloads to dynamically create or modify systemd unit files by converting non-native configurations into services, symlinks, or drop-ins (i.e., Boot or Logon Initialization Scripts).^[7],[8]

References

1. Linux man-pages. (2014, January). systemd(1) - Linux manual page. Retrieved April 23, 2019.
2. Tony Lambert. (2022, November 13). ATT&CK T1501: Understanding systemd service persistence. Retrieved March 20, 2023.
3. Free Desktop. (n.d.). systemd.service — Service unit configuration. Retrieved March 20, 2023.
4. Anomali Labs. (2019, March 15). Rocke Evolves Its Arsenal With a New Malware Family Written in Golang. Retrieved April 24, 2019.
5. airwalk. (2023, January 1). A guide to backdooring Unix systems. Retrieved May 31, 2023.
6. Rapid7. (2016, June 22). Service Persistence. Retrieved April 23, 2019.
7. Ruben Groenewoud. (2024, August 20). Linux Detection Engineering - A primer on persistence mechanisms. Retrieved March 18, 2025.
8. Pepe Berba. (2022, February 7). Hunting for Persistence in Linux (Part 5): Systemd Generators. Retrieved April 8, 2025.