Attackers use rc.common on macOS by placing commands in this startup script so they run during system boot or service initialisation. Review startup scripts for unauthorised edits, compare them against known-good baselines, and monitor for new commands added to boot-time files. Restrict who can modify these scripts and investigate any unexpected persistence there.
Why rc.common Matters as a Persistence Point on macOS
rc.common is a startup script hook that can execute commands during boot or service initialisation, so attackers value it as a persistence mechanism. The security issue is not the file name alone, but the trust placed in boot-time code paths. If an adversary can alter that script, they can arrange for their command to run early and repeatedly without needing a user to launch anything.
That makes rc.common part of the broader Persistence Techniques Guide landscape, where the key question is whether a startup path has been modified in a way that survives reboots and hides inside normal system administration activity. On macOS, boot and service initialisation paths deserve the same attention as launch agents, shell profiles, or other autostart locations.
Because this is a startup-time execution path, defenders should treat any change as potentially security-relevant until it is explained. A legitimate configuration change can look very similar to attacker persistence, so the deciding factor is provenance: who changed the file, when it changed, and whether the new command matches approved system behaviour.
What Attackers Typically Change in rc.common
Attackers usually do not need a complex payload. They often add a one-line command, a download-and-execute instruction, or a callout to another script so their code runs whenever the system reaches the relevant startup sequence. The script then acts as a durable launch point rather than the full malware itself.
This is why the State of NHI & AI Agent Breach Report 2026 is still relevant as a defensive reference even though the mechanism here is macOS persistence: once an attacker has trusted execution on a host, the same playbook often expands into credential theft, lateral movement, or additional persistence. Early detection of the startup hook helps stop that progression before the foothold spreads.
In practical terms, rc.common abuse usually shows up as one of three patterns: a newly inserted command, a changed command target, or a legitimate command wrapped with attacker-controlled arguments. Even when the file still looks “normal” at a glance, small additions can be enough to create durable execution at boot.
How to Detect, Contain, and Remove rc.common Abuse
Detection starts with baseline comparison. Compare the current script to a known-good copy, look for unfamiliar commands, and verify whether recent administrative change records explain the difference. Any unexpected modification should be treated as a persistence indicator until it is validated.
Operationally, the right response is to restore the file from a trusted source, remove unauthorised commands, and review adjacent startup locations for a paired persistence mechanism. Attackers often combine boot-time scripts with other autostart entries so that losing one foothold does not end the compromise.
Do not stop at cleanup if the script was altered without approval. Investigate the host for signs that the attacker used the persistence window to run post-exploitation activity, especially additional binaries, unusual network connections, or newly created local accounts. If the startup script was modified, assume the system may have been used to stage further access.
Risk and Threat Considerations
Boot-time scripts are attractive because they run before many users notice anything is wrong, and because defenders often trust them as part of system startup. If the attacker can edit rc.common, they gain a low-noise persistence path that can survive simple process termination and ordinary user logoff.
Failure mechanism: The compromise succeeds when an attacker can write to a startup script or an adjacent path that rc.common invokes, allowing malicious commands to execute during system boot or service initialisation.
Impact: The result is durable persistence, repeated command execution after reboot, and a higher likelihood of follow-on actions such as credential theft, re-entry, or broader host compromise.
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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547.011 — Boot or Logon Initialization Scripts | rc.common abuse is boot-time script persistence on macOS. |
| Recommendation — Monitor boot-time scripts for unauthorized changes and correlate edits with persistence activity. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Detecting rc.common abuse depends on known-good baselines and controlled startup configuration. |
| Recommendation — Baseline startup scripts and alert on unauthorized modifications. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Restricting who can alter boot scripts directly reduces persistence injection risk. |
| Recommendation — Limit modification rights for startup scripts and review every nonstandard change. | ||
Practitioner Guidance
What to verify: Confirm the file owner, permissions, and last modification trail before trusting any rc.common entry. If the edit cannot be tied to an approved change, treat the script as hostile until proven otherwise.
Decision rule: If the script contains an unexpected command, prioritise containment and restoration first, then investigate compromise scope. If the change is approved but unexpected in production, verify whether the same pattern exists on other hosts that share the image or configuration set.
Practitioner takeaway: With startup scripts, the real control is not just file integrity, it is change provenance plus rapid comparison against a trusted baseline, because persistence often hides in the smallest boot-time edit.