RC Scripts are startup and shutdown scripts used by Unix-like systems to launch services and perform system actions during boot. Attackers modify these scripts to gain persistence or execute code early in startup, so defenders should restrict write access, checksum them and review changes carefully.
What RC scripts are and why they matter
RC scripts are the boot and shutdown scripts Unix-like systems use to start services and perform system actions early in startup. Because they execute with high trust during initialization, tampering can turn them into a durable persistence mechanism or an early-stage code execution path.
That makes RC scripts operationally sensitive even when they look like ordinary host configuration. If an attacker can alter them, they can often run code before many monitoring agents, user sessions, or application controls are fully active, which raises the value of strict file ownership and change control.
How RC scripts are used during startup and shutdown
RC scripts typically live in the host’s service startup flow, where they can launch daemons, mount filesystems, set environment state, or trigger other initialization tasks. Shutdown scripts can also stop services cleanly or run cleanup actions, which means both paths can affect availability and host integrity.
Different Unix-like platforms implement startup sequencing differently, but the core security concern is the same: these scripts sit on a trusted execution path. A modified line, added command, or redirected call can alter what the system launches and when it launches it.
Why attackers target RC scripts for persistence
Attackers value RC scripts because they can provide persistence that survives reboots and can execute before many defensive processes are ready. That makes them useful for maintaining access, planting loader logic, or reintroducing malicious tools after cleanup.
A practical example is the kind of package or software supply chain abuse seen in script-based startup abuse, including the coa and rc npm hijacks 2021, where trusted startup-related code paths were abused to deliver password-stealing behaviour. The lesson for defenders is that startup mechanisms are not just administrative glue, they are execution surfaces.
What defenders should validate on hosts that use RC scripts
Defenders should treat RC scripts as integrity-sensitive assets and verify who can modify them, what process governs changes, and whether the files are monitored for drift. Checksums, configuration monitoring, and review of startup-sequence changes help reveal unauthorized persistence before it becomes embedded in the host.
It is also important to understand the broader control environment around these files, including least-privilege file permissions, audit visibility, and startup-order dependencies. General hardening guidance in the NIST SP 800-53 Rev 5 Security and Privacy Controls and the NIST Cybersecurity Framework 2.0 supports this kind of change-control and integrity discipline, while the NIST Privacy Framework is less central here and should not be the primary lens for host startup script integrity.
Detection and recovery after suspected tampering
Detection should focus on unexpected edits, new startup entries, unusual ownership or permission changes, and commands added to files that normally change rarely. Review timestamps and correlate file modification with process execution, administrative activity, and any sign of interactive compromise.
After remediation, a post-patch or post-cleanup review should confirm that the host boots cleanly, that no unauthorized commands remain in startup paths, and that any credentials, tokens, or service material exposed during the compromise have been rotated if the scripts were used to launch or revive malware. That final review matters because persistence mechanisms often leave behind the conditions for re-entry even after the visible payload is removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | RC scripts need file-change visibility and review to spot tampering and persistence. |
| Recommendation — Log and review changes to startup scripts so unauthorized persistence is detected quickly. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | RC script tampering is a change-control problem involving restricted modification rights. |
| SI-7 — Software, Firmware, and Information Integrity | Checksum verification and integrity monitoring directly protect trusted startup code paths. | |
| Recommendation — Restrict who can modify startup scripts and approve changes before deployment. Monitor startup scripts for unauthorized integrity changes and investigate any drift immediately. | ||
| NIST CSF 2.0 | PR.DS-6 — Integrity Monitoring | RC scripts are configuration assets whose unauthorized changes should be detected and acted on. |
| Recommendation — Implement integrity monitoring for startup scripts and alert on unexpected modifications. | ||