An attacker who can write to one user's shell profile or desktop autostart folder gets code execution every time that user logs in, without administrator rights and without touching system services. MITRE D3FEND names the defence User Session Init Config Analysis (D3-USICA), synonym "User Startup Config Analysis", and defines it as "Analyzing modifications to user session config files such as .bashrc or .bash_profile." It sits under the Detect tactic as a child of Operating System Monitoring, and is the per-user counterpart of the system-wide D3-SICA System Init Config Analysis. This card covers what D3-USICA watches, which ATT&CK techniques D3FEND relates it to, how to deploy it on Linux, macOS and Windows, and how to prove it fires. It is written for detection engineers and endpoint teams; the broader persistence picture is in the Persistence Techniques Guide.
Key takeaways
- The artefact is small and well known. D3FEND ties D3-USICA to one digital artefact, the User Init Configuration File: shell profiles, desktop autostart entries and per-user registry settings that run or shape a session at logon.
- D3FEND relates it to three ATT&CK sub-techniques. Unix Shell Configuration Modification (T1546.004), XDG Autostart Entries (T1547.013) and Hidden Users (T1564.002), all inferred through the shared artefact rather than hand mapped.
- Change alone is noisy; change plus context is a detection. Users and package managers edit these files legitimately. The useful signal is an edit by an unexpected process, followed by new execution or network activity at the next logon.
- Coverage needs every home directory. Service and automation accounts have profiles too, and they are rarely reviewed, which makes them attractive persistence spots.
- Test with a harmless marker edit. A scheduled, benign change to a canary profile proves the watch, the log pipeline and the alert all still work.
D3-USICA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-USICA (d3f:UserSessionInitConfigAnalysis) |
| Tactic | Detect |
| Parent technique | Operating System Monitoring |
| Synonym | User Startup Config Analysis |
| Digital artefact | User Init Configuration File (D3FEND relation: analyzes). D3FEND defines it as a file that configures the part of a user's environment common to all applications and actions |
| D3FEND references | MITRE CAR-2020-09-002 (COM hijacking), CAR-2020-11-011 (registry edit from screensaver), Microsoft "Registry Key Security and Access Rights", and an IBM patent on filesystem views for forensic indicators |
| Typical data sources | Linux audit subsystem, file integrity monitoring, EDR file and registry telemetry, Sysmon events 11 to 14 on Windows |
| Effort | Low to start on servers; medium on user workstations, where legitimate edits are frequent |
| Main limitation | Detects the change, not intent; needs baselining and process context to stay useful |
How it works
D3FEND gives only the definition, so the mechanics come from the related ATT&CK techniques and the CAR analytics it cites. The countermeasure has three parts.
- Watch the files and keys: record create, write, rename and attribute change on the per-user startup locations listed below, with the process, user and host that made the change.
- Compare against a baseline: know which accounts normally have which profile contents, which packages ship autostart entries, and which tools legitimately edit them.
- Correlate with the next logon: ATT&CK's own detection strategy for T1546.004 pairs a shell configuration change with unusual process execution or network connections at shell login. The edit is the lead; what runs next confirms it.
Locations to watch
| Platform | Per-user locations | System-wide equivalents (D3-SICA scope, often watched together) |
|---|---|---|
| Linux, bash | ~/.bash_profile, ~/.bash_login, ~/.profile, ~/.bashrc, ~/.bash_logout | /etc/profile, /etc/profile.d/ |
| macOS, zsh (default since 10.15) | ~/.zprofile, ~/.zlogin, ~/.zshrc, ~/.zlogout | /etc/profile, /etc/zshenv, /etc/zprofile, /etc/zlogin, /etc/zlogout, /etc/bashrc |
| Linux desktop (XDG) | ~/.config/autostart/*.desktop (the Exec key holds the command) | /etc/xdg/autostart/ |
| Hidden user settings | macOS user record IsHidden attribute; GNOME greeter setting org.gnome.login-screen disable-user-list | macOS /Library/Preferences/com.apple.loginwindow Hide500Users; Windows HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList |
| Windows, per-user registry (CAR references) | HKCU\Software\Classes\CLSID (COM hijacking, T1546.015); the policy value \Software\Policies\Microsoft\Windows\Control Panel\Desktop\SCRNSAVE.EXE (screensaver, T1546.002) | HKLM\SOFTWARE\Classes\CLSID |
The Windows rows come from the two MITRE CAR analytics D3FEND cites. CAR-2020-11-011 is tagged to D3-USICA on the CAR site; CAR-2020-09-002 is tagged there to D3-SICA, because it covers both the HKCU and HKLM CLSID branches.
Where identity fits
Every service account, deployment user and CI runner account on a Linux host has a home directory and, usually, a .bashrc or .profile. Those profiles are sourced when an operator or automation opens an interactive or login shell as that account, nobody owns them as a "user", and they are rarely reviewed. Include non-human accounts' home directories in the watch scope, and keep their shells non-interactive where they do not need one. The Service Account Security Guide covers the account side.
ATT&CK techniques D3FEND relates to D3-USICA
Relationship type: inferred only. D3FEND derives these rows through the shared User Init Configuration File artefact and labels them "inferred and experimental" (checked November 2026). The D3FEND technique page lists T1546.004 and T1564.002; the D3FEND ontology also records that T1547.013 may create or modify the same artefact. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Relation to the artefact | What D3-USICA catches |
|---|---|---|---|
| T1546.004 | Event Triggered Execution: Unix Shell Configuration Modification | Modifies User Init Configuration File | A command appended to ~/.bashrc or ~/.zshrc that runs at each new shell |
| T1547.013 | Boot or Logon Autostart Execution: XDG Autostart Entries | May create or modify User Init Configuration File | A new .desktop file in ~/.config/autostart whose Exec key points at an unpackaged binary |
| T1564.002 | Hide Artifacts: Hidden Users | Modifies User Init Configuration File | A greeter or login window setting changed so a new account does not appear at logon |
ATT&CK lists M1022 Restrict File and Directory Permissions for T1546.004 and T1547.013, and M1028 Operating System Configuration for T1564.002. Those are preventive and complement this detection. Defensive detail for the parent techniques is in the T1546 Event Triggered Execution Defensive Guide and the T1547 Boot or Logon Autostart Execution Defensive Guide.
Where it is implemented
| Implementation class | Signal | Fits when | Watch out for |
|---|---|---|---|
| Linux audit subsystem (auditd) | Syscall rules with -F path (one file) or -F dir (a directory and its subtree) plus -F perm=wa, tagged with a key | Servers where you already ship audit logs | The auditctl man page marks the older -w watch form as deprecated for performance reasons; per-user paths must be listed per home directory |
| File integrity monitoring | Hash and attribute change on listed files, reported on a schedule or in real time | Fleets with an existing FIM tool and change process | Scheduled scans miss a file that is changed and restored between scans |
| EDR file and registry telemetry | File write and registry set events with the writing process and its lineage | Workstations, where process context separates user edits from malware | Vendor default rules may cover shell profiles but not XDG autostart or greeter settings |
| Sysmon on Windows | Event 11 FileCreate, 12 registry object create and delete, 13 registry value set, 14 key and value rename; filtered with include rules on the keys above | Windows estates with a SIEM | Exclude rules take precedence over include rules, so a broad exclusion can silently remove coverage |
| Configuration management drift checks | Managed profile content compared with the declared state | Servers where profiles are managed as code | Only covers accounts and files the tool manages |
Linux audit rule design is covered in Linux Logging and auditd for Defenders Guide, FIM tuning in the Linux File Integrity Monitoring Guide, and Sysmon configuration in the Sysmon Guide.
Implementation steps
- Inventory accounts with a home directory. Include service, deployment and break-glass accounts, not just people. On macOS list user records including hidden ones; on Linux read /etc/passwd for accounts with a valid shell.
- Define the watch list. Start from the locations table. Add shells actually in use (fish and others keep their own files) and any login hooks your desktop environment reads.
- Turn on collection in audit or report-only mode. Deploy the audit rules, FIM policy or Sysmon include rules to a pilot group of servers and workstations. Confirm events reach the SIEM with the writing process recorded.
- Baseline for two to four weeks. Record which processes legitimately write these files: editors, dotfile managers, package installers, configuration management agents. Tune by process and account, not by dropping the path.
- Write the detection. Alert on writes by processes outside the baseline, on new autostart entries whose Exec target is not owned by an installed package, and on any change to hidden-user settings. Raise severity when the next logon shows a new child process or outbound connection from the shell.
- Prefer prevention where it is cheap. On servers, make service account profiles root-owned and read-only to the account (M1022). On managed macOS and Windows, restrict hidden-user settings by policy (M1028).
- Roll out and keep a rollback. Expand ring by ring. Keep the previous rule set versioned so a noisy release can be reverted without losing the core shell profile coverage.
How to verify it works
- Canary edit: on a schedule, have an approved test account append and remove a harmless comment line in its ~/.bashrc and create and delete a test .desktop file. Confirm both alerts arrive with the correct process and host.
- Next-logon correlation test: in a lab, add a benign command that writes a marker file at shell start, open a new login shell and confirm the correlation rule links the edit to the new execution.
- Coverage audit: compare the list of home directories on each host with the paths in the deployed rules. New accounts created after deployment are the usual gap.
- Emulation: include T1546.004 and T1547.013 in authorised adversary emulation runs and record whether each was detected, and how fast.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Hosts passing the scheduled canary edit test | 100% of in-scope hosts | Proves rules, agent and pipeline end to end |
| Home directories covered by rules | All accounts with a valid shell | Unwatched service accounts are the common gap |
| Alerts per 1,000 hosts per week after tuning | Low and stable | Shows the baseline is right and analysts will act on hits |
| Emulated techniques detected | T1546.004 and T1547.013 detected in every exercise | Confirms the related techniques are actually caught |
Limits, bypasses and failure patterns
- Watching only people: rules generated from the HR user list skip service and automation accounts whose profiles are sourced by scripts and operators.
- Path coverage gaps: watching ~/.bashrc but not ~/.profile, ~/.bash_login or ~/.zshrc lets an attacker pick the unwatched file. Shells read different files for login and interactive sessions.
- Indirect inclusion: a profile that sources another file (for example a dotfiles directory or a file under /etc/profile.d) moves the real payload outside the watched path. Watch what the profile sources, not only the profile.
- Write and restore: scheduled FIM scans miss a change that is used and reverted between scans. Use event-driven collection for these paths.
- Tuning by path: excluding a whole path because a dotfile manager edits it removes coverage for everyone. Exclude the known process and account instead.
- Alert without correlation: a stream of "profile modified" alerts with no process context is ignored within weeks. Ship process lineage with every event.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring for unauthorised changes and indicators of attack on hosts |
| NIST SP 800-53 Rev 5 | SI-7 Software, Firmware, and Information Integrity | Integrity checking of configuration files |
| NIST SP 800-53 Rev 5 | CM-3 Configuration Change Control | Managed profiles and drift detection |
| NIST CSF 2.0 | DE.CM-09 | Computing hardware and software, runtime environments and their data are monitored |
| MITRE ATT&CK mitigations | M1022, M1028 | Preventive controls listed for the related techniques |
| MITRE D3FEND | Operating System Monitoring, D3-USICA | Parent and technique |
Related countermeasures
- System Init Config Analysis (D3-SICA): the same idea for system-wide startup configuration. See the D3-SICA System Init Config Analysis.
- Process Spawn Analysis (D3-PSA): catches the process the modified profile launches at logon. See D3-PSA Process Spawn Analysis.
- File integrity monitoring: the general file change capability many teams use to implement this card. See the File Integrity Monitoring Guide.
Practitioner checklist
- List every account with a home directory and a valid shell, including service accounts.
- Watch login, interactive and logout profile files for every shell in use, not just ~/.bashrc.
- Watch ~/.config/autostart and /etc/xdg/autostart on Linux desktops.
- Alert on any change to hidden-user settings on macOS, Windows and Linux greeters.
- Use event-driven collection with process lineage, not only scheduled hash scans.
- Tune by process and account, never by dropping a watched path.
- Correlate profile edits with new execution or network activity at the next logon.
- Make service account profiles read-only to the account where possible.
- Run a scheduled canary edit per host group and record the result.
Standards and references
- MITRE D3FEND: User Session Init Config Analysis (D3-USICA)
- MITRE ATT&CK: T1546.004 Unix Shell Configuration Modification
- MITRE ATT&CK: T1547.013 XDG Autostart Entries
- MITRE ATT&CK: T1564.002 Hidden Users
- MITRE CAR: CAR-2020-11-011 Registry Edit from Screensaver
- MITRE CAR: CAR-2020-09-002 Component Object Model Hijacking
- Linux man-pages: auditctl(8)
- Microsoft Learn: Sysmon
Related NHI Mgmt Group resources: MITRE D3FEND Guide · Persistence Techniques Guide · Linux Logging and auditd for Defenders Guide · Sysmon Guide · Service Account Security Guide