Masquerade Task or Service is ATT&CK T1036.004. It sits under Stealth and applies to Linux, macOS and Windows. The idea is to name a scheduled task or service so that it looks like something that belongs on the system.
How attackers use it
MITRE explains that tasks run by Task Scheduler or systemd typically carry a name and a description, and Windows services have both a service name and a display name. Many benign tasks and services have commonly associated names, so an adversary can choose names similar or identical to those. The description field can also be written to look legitimate.
The procedure examples show how plain it can be. One group disguised its scheduled tasks as ones used by Google. Another appended a Unicode no-break space to a legitimate service name, so that the two looked the same on screen. Others created services that appeared to be benign system tools or reused names of real Windows binaries.
How to detect it
MITRE's detection strategy focuses on creation or modification followed by unusual execution:
- Windows: creation or modification of services or scheduled tasks with names or descriptions that mimic legitimate entries, followed by execution of untrusted binaries.
- Linux: creation or modification of systemd units or cron jobs with deceptive names and untrusted command paths, sometimes followed by lateral network activity or privilege escalation.
- macOS: creation of LaunchAgents or LaunchDaemons with names resembling known system services but running code that is not signed by Apple.
The name is not the signal. The executable path, the signer and the time of creation are. Collect service install events and scheduled task creation events, and for each one record the binary it runs.
On Windows, event 7045 in the System log records a new service install, and event 4698 in the Security log records a scheduled task creation when auditing is enabled. Those IDs are widely documented, but confirm them in your own environment before you build alerts on them.
How to reduce the risk
MITRE's page for this sub-technique lists no dedicated mitigations. Practical steps that follow from the description: keep an inventory of the tasks and services your estate is supposed to have, review new ones against it, and require that the binary behind a service has a valid signature and sits in a protected folder.
Check your own environment
Windows PowerShell, list scheduled tasks and the program each one runs:
Get-ScheduledTask | Select-Object TaskName, TaskPath, @{n='Run';e={$_.Actions.Execute}}
Windows PowerShell, list services and their binary paths:
Get-CimInstance Win32_Service | Select-Object Name, DisplayName, PathName, StartMode
Linux, list loaded systemd service units:
systemctl list-units --type=service --all
For each item you do not recognize, read what it executes before you read what it is called.
Quick check
What is a more reliable signal than a task's name?
The program the task or service runs, including its path and signature, and when the task or service was created.
