Rc.common is a macOS startup script used to run common system initialisation tasks during boot. If an attacker modifies it, they can gain persistence or execute code early in the startup sequence. Defenders restrict write access, monitor for changes, and verify the file against trusted baselines.
What Rc.common Does in macOS Startup
Rc.common is a shared shell script used by macOS startup components to run common initialisation logic during boot. It sits in a sensitive execution path, so changes to it can affect what runs early and what runs before normal user visibility or many endpoint controls.
Because it is part of startup orchestration, the file matters less as a standalone script and more as a trust anchor for the boot sequence. A small change can have outsized operational effect if it is executed automatically and repeatedly.
Why Rc.common Is a Persistence Target
Attackers value startup scripts because they offer early execution and repeatable persistence. If an attacker can alter persistence techniques, the malicious logic can run every time the system starts, often before interactive login or many higher-level controls are active.
This makes rc.common attractive for stealthy code execution, especially when defenders focus only on user sessions or visible autoruns. Startup-time abuse can blend into normal boot behaviour and survive routine restarts.
How Organisations Assess Exposure
Exposure review starts with knowing whether the file exists in the expected location, whether it is writable by non-administrative principals, and whether the current hash or contents match a trusted baseline. The key question is not just “is the file present?”, but “who can change it and would that change execute on boot?”
Administrators should also compare the system to vendor documentation and known-good images, because startup files are often modified indirectly through admin tooling, package installation, or post-exploitation activity. Broad NIST Cybersecurity Framework 2.0 hygiene still applies here: asset awareness, integrity checking, and detection of configuration drift are the core defensive disciplines.
Detection, Hardening, and Recovery
Effective defence combines write restriction, integrity monitoring, and behavioural review. If rc.common changes unexpectedly, the priority is to confirm whether the modification was authorised, whether it introduced additional execution paths, and whether nearby startup artefacts were also touched.
Monitoring should look for post-boot effects as well as file changes, because persistence often arrives with companion artefacts such as modified scripts, launch items, or adjacent binaries. Where compromise is suspected, rebuild trust from known-good media or a verified baseline rather than only reverting the file in place.
For detection mapping, MITRE ATT&CK Enterprise Matrix is useful for framing the behaviour as boot or logon autostart execution and execution flow hijacking, while the NIST Privacy Framework is not the main lens here; integrity and persistence are.
Risk and Threat Considerations
Rc.common is risky because it can turn a single file change into durable system-level persistence. An attacker who gains the ability to edit it may be able to survive reboots, execute early in startup, and establish a foothold that is harder to spot than a userland process.
Failure mechanism: Weak file permissions, unsafe admin workflows, or post-compromise tampering allow malicious code to be inserted into the startup path, where it runs automatically before defenders notice.
Impact: The result can be repeated code execution, stealthy persistence, and follow-on compromise of system integrity, credentials, or adjacent startup components.
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 CSF 2.0 and CIS Controls v8 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 is a boot-time persistence mechanism |
| Recommendation — Monitor startup scripts for unauthorized changes and investigate autostart execution paths. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | File integrity and write protection preserve trusted startup content |
| DE.CM-06 — External service provider activities are monitored | Change monitoring detects tampering with critical startup artefacts | |
| Recommendation — Restrict write access and verify startup files against a trusted baseline. Alert on unexpected modifications to startup scripts and related boot artefacts. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Integrity monitoring and review support detection of startup-file tampering |
| Recommendation — Log and review changes to boot-time scripts and other high-impact system files. | ||
Practitioner Guidance
What to watch for: Treat unexpected modifications to rc.common as a high-value integrity event, especially when paired with other boot-time changes or unexplained restart behaviour. The file is small, but the security consequence of altering it can be substantial.
Governance implication: Ownership of startup scripts should be explicit, with a trusted baseline, change control, and file-integrity monitoring that covers early-boot artefacts as part of standard macOS hardening.
Related resources from NHI Mgmt Group
- What is the most common mistake organisations make with NHI credential management?
- What was the common factor in the Snowflake, BeyondTrust, OmniGPT, and DeepSeek breaches?
- What are common vulnerabilities associated with service accounts in AI deployments?
- What common vulnerabilities do cloud applications face with OAuth tokens?