Rc.common

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.

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?