Restrict who can edit rc.common and related startup scripts, and verify them after updates. Prefer managed startup configuration over manual shell edits, then monitor for unexpected persistence commands, new processes, or changes in system boot scripts. Attackers abuse these files to run code automatically at startup with elevated context.
How rc.common gets abused at startup
rc.common is dangerous when it becomes a launch point for code that runs automatically with elevated context. The risk is not the file name itself, but the trust placed in startup scripts and boot-time configuration. If an attacker can alter those files, they can turn a routine reboot, login, or service start into reliable execution.
That is why the safest mitigation starts with tight write access and a preference for managed startup configuration instead of ad hoc shell edits. The goal is to make startup behavior predictable, reviewable, and harder to tamper with after maintenance or software updates.
What to harden before attackers touch rc.common
Restrict who can edit rc.common and related boot or init scripts, and treat those paths as high-value configuration assets. Managed configuration reduces the chance that a one-off shell change survives unnoticed or gets reintroduced during troubleshooting. When changes are necessary, keep them explicit, documented, and tied to a controlled deployment process.
Verification matters because startup files are often edited legitimately during updates, then forgotten. Recheck permissions, ownership, and contents after upgrades or configuration pushes so a malicious or accidental change does not persist across the next boot cycle.
Monitoring should focus on persistence indicators, not just file integrity in isolation. Unexpected startup commands, new long-lived processes, and changes to system boot scripts are the practical signals that the startup path may have been turned into an execution mechanism.
Why persistence controls matter more than one-time cleanup
rc.common abuse is valuable to an attacker because it survives reboots and can execute early in the lifecycle before many user-space controls fully engage. The attacker does not need to win every time, only to establish a durable startup hook once.
A lightweight, well-placed control can therefore reduce more risk than a broad cleanup effort after compromise. If startup scripts are writable by the wrong account, or if review only happens during incidents, persistence can remain dormant until the next restart and then reappear even after partial remediation.
Risk and Threat Considerations
Startup-script abuse is a persistence risk because it converts a local edit into repeated execution. If an attacker gains write access to rc.common or nearby boot scripts, they can create durable footholds, survive reboots, and blend malicious activity into normal system startup.
Failure mechanism: Weak permissions, manual script edits, or incomplete post-update verification allow malicious commands to be inserted into the startup chain, where they execute automatically with the privileges available at boot.
Impact: The system may repeatedly launch unauthorized processes, re-establish access after remediation, and hide compromise inside trusted initialization behavior, making containment and recovery slower.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547 — Boot or Logon Autostart Execution | rc.common abuse is a persistence mechanism that runs code at startup. |
| Recommendation — Map boot-time changes to T1547 and hunt for unauthorized persistence on startup paths. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | Startup scripts need controlled baselines and change control to prevent tampering. |
| Recommendation — Enforce approved configuration baselines for startup scripts and review deviations quickly. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Hardening startup script permissions and baselines is a secure configuration control. |
| Recommendation — Harden startup files and verify their integrity after updates and administrative changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Assets are managed, including hardware, software, and associated resources. | Startup scripts and boot paths are assets that must be governed and tracked. |
| Recommendation — Track boot scripts as managed assets and review them after maintenance or image changes. | ||
Practitioner Guidance
What to verify: Confirm that rc.common and every related startup path are owned by the expected administrative account, not writable by routine operators, and not drifting after patching or image refreshes.
Decision rule: If a change to startup behavior is needed, route it through managed configuration and deployment controls; if it must be edited manually, require a post-change review that compares the active file to the approved baseline.
What good looks like: Startup scripts are inventoryable, changes are rare and attributable, and any new boot-time process can be explained by a known maintenance action rather than discovered after the fact.
Practitioner takeaway: The main defense is to make startup execution boring and auditable, because once an attacker can hide code in boot logic, the reboot itself becomes their persistence mechanism.