Security teams detect rc.common abuse by monitoring the macOS rc.common startup script for unauthorised edits and unexpected commands that run at boot. Baseline the file, check ownership and permissions, and review any changes alongside other startup items. Attackers can add code here to gain persistence and execute before normal user logon.
How rc.common abuse shows up in host telemetry
rc.common is an early boot startup script on macOS, so abuse usually looks like a persistence change rather than a noisy exploit. Security teams should expect a small file with unexpected edits, new shell commands, or references to other binaries that are not normally part of the host’s startup path. Because it runs before normal user logon, the signal is strongest when the change coincides with other startup-item modification.
Good detection starts with baselining the script and treating any drift as suspicious until explained. The most useful questions are simple: who changed it, when did it change, and what new command line was added. On macOS, that makes rc.common part of the broader persistence surface described in NHIMG’s Persistence Techniques Guide.
A practical review should also include ownership and permissions, because abuse is often enabled by weak write access rather than a sophisticated payload. If the file is writable by an unexpected user or group, or if the modification time changes without a corresponding admin change record, the script should be treated as a likely persistence mechanism rather than an isolated configuration tweak.
Why rc.common is valuable to attackers
rc.common is attractive because it executes early and can run before defenders or users notice the compromise. That gives an attacker a durable foothold that survives reboots and can stage follow-on commands before many endpoint tools or user sessions are active. The technique is not about sophistication, it is about abusing a trusted startup location to gain repeatable execution.
For defenders, that means the risk is not only persistence, but also concealment. A malicious line in a boot script can blend into routine system configuration unless teams compare the current file to a known-good baseline and correlate it with other startup mechanisms. When abnormal startup behavior appears alongside broader endpoint weakness, the pattern fits the kinds of control gaps covered in Top 10 Endpoint Security Risks.
Attackers also benefit from the fact that early boot execution can support chaining. A script that launches a helper binary, pulls a second-stage payload, or calls out to a remote location may be the first visible sign of a larger compromise. That is why rc.common should never be reviewed in isolation from the rest of the boot and login path.
What to check when you suspect tampering
Start with a trusted baseline and compare the current file line by line. Look for added commands, unusual path references, obfuscated shell logic, calls to curl or wget, and any attempt to suppress logging or launch hidden child processes. Then verify file provenance, owner, mode bits, and whether the timestamp change is consistent with an approved maintenance event.
Decision rule: if rc.common contains unexpected logic, assume persistence until proven otherwise and investigate adjacent startup items before making cosmetic fixes. If the file is only one part of a broader launch process, review nearby autostart locations, scheduled jobs, and login helpers together so you do not miss a companion entry point.
What to verify: confirm whether the same account that modified rc.common also touched other startup objects, because multi-location changes are a stronger indicator of malicious staging than a single isolated edit. If you find that pattern, preserve the file, capture process and login history, and treat the host as potentially compromised.
Risk and Threat Considerations
rc.common abuse creates persistence at a point in the boot sequence where defenders may have limited visibility, so a small unauthorized edit can have outsize impact. The main risk is durable execution that survives reboots and allows attacker commands to run before normal user activity begins.
Failure mechanism: an attacker with write access to the startup script adds commands that execute during boot, then uses that trusted path to relaunch malware or stage additional actions on every restart.
Impact: the host can retain a hidden foothold, re-establish malicious activity after cleanup attempts, and become harder to contain because execution occurs before typical user logon monitoring begins.
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 surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1037 — Boot or Logon Initialization Scripts | rc.common is a boot-time startup script used for persistence. |
| Recommendation — Hunt for boot-script tampering and related persistence on affected macOS hosts. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Monitoring unauthorized startup-script edits supports persistence detection and response. |
| Recommendation — Monitor and investigate unauthorized startup changes as part of malware defense. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Baselining rc.common supports detection of unauthorized configuration drift. |
| SI-4 — System Monitoring | Unexpected boot-time commands are a monitoring target for persistence abuse. | |
| Recommendation — Establish and compare a known-good startup-script baseline to detect drift. Alert on unauthorized startup-script modifications and suspicious boot execution. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration Management | Startup-script integrity and permission checks are configuration-management concerns. |
| Recommendation — Review and control changes to startup scripts and related host configuration. | ||
Practitioner Guidance
What to prioritize: treat rc.common as a high-value persistence artifact, not a routine text file. If it changes unexpectedly, verify whether the modification was part of a controlled change window before you spend time on the payload itself.
What to measure: track unauthorized edits, permission drift, and unexplained startup-item changes together. A single file modification is useful evidence; a pattern across multiple boot-time objects is much stronger and should move the incident into containment and host review.
Common mistake: teams often fix the script and stop there. The safer move is to assume the edit is a symptom of broader persistence and confirm whether the attacker also added another launch path, because removing only one boot hook can leave the compromise intact.
Practitioner takeaway: rc.common abuse is best detected as a boot-time integrity problem, and the fastest path to confidence is to baseline the script, verify who changed it, and look for companion persistence before declaring the host clean.