D3-SICA System Init Config Analysis: What It Detects, Which ATT&CK Techniques It Counters and How to Verify It

Anything an attacker adds to the places an operating system reads at startup will run again after every reboot, which makes startup configuration the most reliable persistence spot on a host and one of the most useful to inspect. MITRE D3FEND names that inspection D3-SICA System Init Config Analysis (also listed as System Initialization Configuration Analysis, with the synonyms Autorun Analysis and Startup Analysis). It is a Detect tactic countermeasure under Operating System Monitoring (D3-OSM), defined as analysis of any system process startup configuration. This card covers the artefact it analyses, the ATT&CK techniques D3FEND relates it to, where to collect the data on Windows, Linux and macOS, and how to prove the analysis catches change. It is written for detection engineers, endpoint owners and incident responders.

Key takeaways

• The artefact is startup configuration. D3FEND's System Init Configuration (also called Autoruns) is the configuration used to set services, parameters and initial settings for an operating system at startup.
• Diff, do not just list. MITRE CAR-2013-01-002 runs an autoruns inventory on a schedule and compares results over time; the change is the signal.
• Two collection modes are needed. Periodic snapshots catch everything that exists; real-time registry and file events catch the moment of change and the process that made it.
• The ATT&CK mapping is narrow but central. D3FEND relates D3-SICA to Registry Run Keys / Startup Folder, RC Scripts, Startup Items and Services Registry Permissions Weakness.
• Noise comes from software updates. Signed vendor entries and change windows must be handled explicitly or analysts stop reviewing diffs.

D3-SICA at a glance

How it works

D3-SICA has three moving parts. Enumerate: list every startup location the platform supports and the entry in each, with the target binary, its hash and its signature status. Compare: diff that list against a known good baseline or the previous snapshot. Investigate: attribute each new or changed entry to an installer, a change ticket or an unknown process.

MITRE CAR-2013-01-002 Autorun Differences, one of the analytics D3FEND cites, uses this method on Windows: run Sysinternals Autoruns on a schedule, ignore validated Microsoft entries and review the differences. CAR describes it mainly as situational awareness, notes it can be noisy where software changes often, and suggests a sensor that streams registry and file data for real-time use. The other two analytics D3FEND cites are narrow, real-time checks: CAR-2020-09-005 for AppInit DLLs and CAR-2020-11-001 for the HKEY_CURRENT_USER\Environment\UserInitMprLogonScript logon script value, watching both registry edits and reg.exe command lines that set it.

Startup locations to cover

On systemd hosts, remember precedence: files in /etc/systemd/system override same-named units in /usr/lib/systemd/system, and drop-in .conf files override settings in the unit itself. A diff that only looks at vendor unit files misses an attacker's drop-in. See the systemd Service Hardening Guide and the Linux Logging and auditd for Defenders Guide.

Where identity fits

Services start under accounts, and a startup entry is also an identity decision. A new service configured to run as LocalSystem, or an existing service whose account is changed to a privileged domain service account, is both persistence and privilege escalation. Record the run-as account for each service entry in the baseline and alert on changes. Unit files and service definitions that embed credentials or tokens in arguments or environment settings are a secrets exposure as well as a startup entry.

ATT&CK techniques D3FEND relates to D3-SICA

Relationship type: inferred, not a direct mapping. D3FEND does not map ATT&CK techniques to D3-SICA directly; it infers each relationship because the technique and the countermeasure involve the same digital artefact (System Init Configuration). An inferred relationship shows relevance, not coverage.

D3-SICA analyses the System Init Configuration artefact, and these techniques modify it. They indicate relevance, not complete coverage. Each ID was checked against ATT&CK v20. D3FEND still lists Safe Mode Boot under its pre-v20 ID, which ATT&CK v20 revoked; the table shows the current technique, T1688 Safe Mode Boot.

CAR-2013-01-002, which D3FEND links to D3-SICA, rates moderate coverage for a wider set, including Windows Service (T1543.003), Scheduled Task (T1053.005), Winlogon Helper DLL (T1547.004), AppInit DLLs (T1546.010) and Logon Script (Windows) (T1037.001). For defensive detail see the T1547 Boot or Logon Autostart Execution Defensive Guide, MITRE ATT&CK T1037 Boot or Logon Initialization Scripts, the T1574 Hijack Execution Flow Defensive Guide and the T1543 Create or Modify System Process Defensive Guide.

Choosing an approach

Small organisations: a weekly scripted inventory per host type plus EDR registry and file alerts for the run keys and service keys is enough. Large organisations: centralise inventories in the SIEM, keep a fleet-wide prevalence count per entry, and treat any entry seen on one host only as a triage priority.

Implementation steps

1. Build the location list. Start from the Autoruns categories on Windows (logon, services and drivers, AppInit, Winlogon, boot execute, scheduled tasks, WMI) and the systemd load path and drop-in directories on Linux.
2. Capture a baseline from a clean build. On Windows, autorunsc with -a * (all entry types), -c (CSV), -h (hashes), -s (verify signatures) and -t (UTC timestamps) produces a comparable record. Keep the baseline per image, not per host.
3. Schedule snapshots and diff them. Ship each snapshot to central storage and compare to the previous one and to the image baseline. Use -m to hide signed Microsoft entries only after confirming signature checks are on.
4. Add real-time rules for the top locations. Sysmon Event ID 12 and 13 (or EDR equivalents) for Run keys, service keys and UserInitMprLogonScript; Linux audit rules such as -a always,exit -F arch=b64 -F dir=/etc/systemd/system -F perm=wa -k sica_units, preferring the dir= form over deprecated -w watches as the auditctl manual recommends.
5. Join with change management. Suppress diffs that match an approved change or a known installer hash, never by path alone.
6. Pilot and tune. Run on one business unit for two weeks, record each diff's cause and adjust suppressions.
7. Roll back safely. D3-SICA only reads configuration, so rollback means disabling a rule or suppression; keep removal of malicious entries in the incident process, using the tool's disable function before deletion so evidence is kept.

How to verify it works

• Planted entry test: on a test host, add a harmless Run key value and a harmless systemd drop-in, then confirm both the real-time alert and the next diff report them, and remove them.
• Service account change test: change a test service's run-as account and confirm the baseline diff flags it.
• Offline check: during incident response, use the Autoruns offline mode (-z) against a suspect system image and compare with live results.
• Coverage review: compare your rule set with the CAR-2013-01-002 coverage list each quarter.

Limits, bypasses and failure patterns

• Partial location coverage: watching Run keys only, while attackers use services, Winlogon values or systemd drop-ins. Use the full Autoruns category list as the yardstick.
• Trusting the path: suppressing entries because they sit under a vendor directory. Suppress by hash and signature instead, and alert on unsigned binaries under trusted paths.
• Hiding Microsoft entries without signature checks: filtering on publisher names without verification lets a renamed binary blend in.
• Snapshot only: inventories show that something changed but not which process did it; pair them with real-time events.
• Ignoring precedence: diffing /usr/lib/systemd/system while an override sits in /etc/systemd/system or a .d/ directory.
• Removing before preserving: deleting a malicious entry before recording it loses the evidence needed to scope the incident.

Framework mapping

Related countermeasures

Siblings under Operating System Monitoring cover adjacent startup and runtime state: D3-USICA User Session Init Config Analysis (per-user logon configuration), D3-SJA Scheduled Job Analysis, D3-SDM System Daemon Monitoring, D3-SFA System File Analysis, D3-EHB Endpoint Health Beacon, D3-IDA Input Device Analysis and D3-MBT Memory Boundary Tracking. For the framework overview, see the MITRE D3FEND Guide; for the Windows telemetry side, see the Sysmon Guide.

Practitioner checklist

• Document every startup location per platform and map it to a collection method.
• Capture a signed, hashed startup baseline for each gold image.
• Schedule snapshots at least weekly and diff against baseline and previous run.
• Stream real-time events for Run keys, service keys, logon script values and systemd unit directories.
• Record the run-as account for every service and alert on changes.
• Suppress by hash, signature and change ticket, never by path alone.
• Run planted entry tests monthly and track the pass rate.
• Preserve entries as evidence before removal during incidents.

Standards and references

• MITRE D3FEND: System Init Config Analysis (D3-SICA)
• MITRE CAR: CAR-2013-01-002 Autorun Differences
• MITRE CAR: CAR-2020-11-001 Boot or Logon Initialization Scripts
• Microsoft Learn: Autoruns for Windows
• Microsoft Learn: Sysmon
• freedesktop.org: systemd.unit
• Linux man-pages: auditctl(8)

Related NHI Mgmt Group resources: MITRE D3FEND Guide · T1547 Boot or Logon Autostart Execution Defensive Guide · MITRE ATT&CK T1037 Boot or Logon Initialization Scripts · systemd Service Hardening Guide