Below is an operational, SOC-ready expansion of Boot or Logon Autostart Execution (T1547), mapping it to real-world malware families and providing a practical detection checklist you can directly adapt into SOC runbooks, SIEM use-cases, or EDR policies.

1. Mapping to Real-World Malware Families

Attackers across all sophistication levels rely on autostart persistence. Below is a technical mapping showing how major malware families implement Boot/Logon Autostart Execution.

Malware Family → Autostart Technique Mapping

Malware Family	Platform	Autostart Mechanism	Technical Details	Privilege Level
Emotet	Windows	Registry Run Keys, Services	Adds payload under `HKCU/HKLM\...\Run`, later installs services for SYSTEM persistence	User → SYSTEM
TrickBot	Windows	Scheduled Tasks, Services	Creates hidden scheduled tasks (`At startup`) and service-based loaders	SYSTEM
QakBot (QBot)	Windows	Registry Run Keys	Uses randomized Run key names pointing to `%AppData%` DLL loaders	User
Agent Tesla	Windows	Startup Folder	Drops EXE/LNK into Startup folder to evade registry monitoring	User
Cobalt Strike (Beacon)	Windows	Services, Scheduled Tasks	Red teams & APTs register stealthy services or logon-triggered tasks	SYSTEM
Ryuk / Conti	Windows	Services	Registers ransomware as a Windows service to survive reboot before encryption	SYSTEM
LockBit	Windows	Scheduled Tasks	Uses `schtasks /create /sc onstart` to re-trigger encryption or C2	SYSTEM
APT29 (Cozy Bear)	Windows	Registry + Services	Masqueraded service names, often mimicking OS components	SYSTEM
APT41	Windows	DLL Search Order Hijacking	Autostarted legit app loads malicious DLL on boot	User / SYSTEM
Mirai (Linux)	Linux	Cron @reboot	Writes `@reboot` cron jobs to respawn botnet process	Root
XorDDoS	Linux	systemd Services	Drops fake `.service` files enabled at boot	Root
Shlayer	macOS	Launch Agents	Installs plist files with `RunAtLoad=true`	User
OSX.Dok	macOS	Launch Daemons	System-level persistence via LaunchDaemons	Root

Key Observations from Malware Usage

Commodity malware prefers Run keys & Startup folders
Ransomware heavily favors services & scheduled tasks
APTs use stealthy mechanisms:
- Masquerading names
- DLL hijacking
- SYSTEM-level execution
Linux malware overwhelmingly relies on cron & systemd
macOS malware almost exclusively uses LaunchAgents/Daemons

2. SOC Detection Checklist (Operational)

This checklist is designed for Tier 1 → Tier 3 SOC analysts and aligns with SIEM, EDR, and DFIR workflows.

A. Preventive Controls (Hardening)

✔ Enforce least privilege (block HKLM/service creation by users)
✔ Restrict schtasks / sc / reg add via AppLocker or WDAC
✔ Require signed services & drivers only
✔ Disable unused startup locations
✔ Monitor changes to startup paths with FIM

B. Continuous Monitoring Checklist

Windows Monitoring

Item	What to Monitor	Data Source
Registry Run Keys	New or modified Run/RunOnce entries	EDR, Sysmon (Event 13)
Services	New service creation	Event ID 4697
Scheduled Tasks	Tasks with `At startup/logon` triggers	Event ID 106
Startup Folder	File creation/modification	EDR, FIM
Parent-Child Anomalies	`services.exe → cmd.exe / powershell.exe`	EDR

Linux Monitoring

Item	What to Monitor	Data Source
systemd	New `.service` files	Auditd
Cron	New `@reboot` entries	`/var/log/syslog`
Shell Profiles	Modifications to `.bashrc`, `.profile`	FIM
Boot Processes	Unexpected root-owned processes	ps, EDR

macOS Monitoring

Item	What to Monitor	Data Source
LaunchAgents	New plist files	Unified Logs
LaunchDaemons	System-level plist creation	EDR
Persistence Flags	`RunAtLoad=true`	Plist inspection
Unsigned Binaries	Executed at login	Gatekeeper / EDR

C. Behavioral Detection (High-Fidelity)

Executables spawning immediately after boot/logon
Unsigned binaries running as SYSTEM/root
Startup entries pointing to:

%AppData%
/tmp
/var/tmp
User-writable directories

4. Randomized or OS-masquerading names (WinUpdateSvc, SystemHost)

D. Threat Hunting Queries (Conceptual)

Startup entry created within 5 minutes of suspicious download
Service binary not present on clean gold image
Scheduled task with obfuscated command-line
Startup execution followed by outbound C2 traffic

E. Incident Response Checklist (SOC Workflow)

1️⃣ Triage

Identify persistence mechanism
Confirm binary hash reputation
Check execution context (user vs SYSTEM)

2️⃣ Containment

Disable service/task/autostart entry
Isolate endpoint if C2 observed
Preserve disk & memory artifacts

3️⃣ Eradication

Remove startup artifacts
Delete payload from disk
Reset credentials if privilege escalation occurred

4️⃣ Recovery

Reboot and validate clean startup
Re-enable only approved autostart entries
Patch exploited vulnerabilities

5️⃣ Post-Incident Actions

Add detection rules for abused startup path
Update threat intel with new IOC patterns
Review alert gaps

SOC Analyst Quick Reference (Table)

Phase	Key Question
Detection	Why is this process starting at boot/logon?
Validation	Is this startup entry business-approved?
Scope	How many hosts have this persistence?
Impact	SYSTEM/root execution achieved?
Closure	Are all autostart artifacts removed?

Final Takeaway

Boot or Logon Autostart Execution is one of the most abused persistence techniques across all malware tiers.
A mature SOC must:

Monitor every startup extensibility point
Correlate creation + execution + network behavior
Treat unknown startup entries as high-risk by default

Real-world malware families using Boot or Logon Autostart Execution