Security teams can detect RC scripts by monitoring startup and service initialisation paths for unexpected modifications, new launch entries, or scripts that run automatically at boot. Focus on changes made by unusual accounts, especially on Unix-like systems where rc files control startup behaviour. Compare the current configuration with a known-good baseline and alert on newly added persistence logic.
What RC scripts are and where they hide
rc scripts are startup and runtime configuration scripts that can execute automatically when a system boots, a shell starts, or a service initialises. On Unix-like systems, they often appear in shell profile files, init paths, launch mechanisms, or other boot-time hooks. Because they run early and quietly, they are attractive persistence points and easy to miss if you only monitor interactive logons.
The practical detection problem is not just spotting a file named like an rc script. It is recognising when a normal startup path has been altered to run something unexpected, when a legitimate script has been edited to include extra commands, or when a new autostart mechanism appears in a directory that should already be baselined.
How to spot suspicious rc script activity
Start with the places that normally control automatic execution and compare them with a known-good baseline. Watch for new entries, changed file contents, altered permissions, unusual ownership, or paths that point to temporary locations, user-writable directories, or recently introduced binaries. If a script is meant to manage startup behaviour, even a small change can matter because it may execute every time the system starts.
Time and actor context are important. Changes made by unusual accounts, service accounts that should not edit boot logic, or users outside the normal administrative workflow deserve priority triage. That is especially true when the modification lands in a path tied to persistence techniques, because rc-based startup hooks are one of several common ways attackers preserve access after initial compromise.
Detection is stronger when you look for execution evidence as well as file change evidence. A modified rc file that never runs may be a latent issue, but a modified rc file that fires during boot or shell initialisation is an active persistence path. Correlate file integrity alerts with process creation, command-line arguments, and service start events so you can distinguish harmless administrative change from implant behaviour.
Building detection that catches rc persistence early
The best coverage comes from combining file integrity monitoring, configuration drift detection, and execution telemetry. File integrity tells you what changed, but execution logs tell you whether the change actually affected startup behaviour. Baseline both the expected content and the expected owner, then alert on new commands appended to startup files, unexpected sourced scripts, and entries that redirect execution to attacker-controlled locations.
On Unix-like systems, review rc-style files as part of broader startup and service initialisation monitoring, not as an isolated control. That includes shell profiles, login scripts, init scripts, and other autostart locations that can carry equivalent persistence logic. For Windows fleets, it is still useful to map the same mindset to adjacent persistence paths so the team does not miss the pattern when it appears in a different form. PCI DSS 4.0 Guide is not about rc files specifically, but it is a useful reminder that security teams need a clear, testable control objective rather than ad hoc review.
A useful operational rule is to treat any newly added startup logic as suspicious until you can explain who changed it, why it changed, and whether the change matches an approved maintenance window. That rule helps because persistence edits often look like small administrative adjustments, while the security impact only becomes obvious when the script executes on reboot or user session start.
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 — Boot or Logon Autostart Execution | RC scripts are boot or shell startup persistence mechanisms. |
| Recommendation — Monitor autostart locations for unexpected persistence changes and investigate new execution paths. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Startup scripts and autostart entries need asset visibility to detect drift. |
| Recommendation — Inventory startup files and autostart paths so unauthorized changes stand out quickly. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Unexpected rc script edits are unauthorized configuration changes. |
| Recommendation — Restrict who can modify startup logic and alert on unauthorised configuration changes. | ||
Practitioner Guidance
What to verify: Confirm the exact startup path, file owner, hash, and last-modified time before deciding whether the change is benign. If the script executes during boot or shell initialisation, verify the execution chain as well, not just the file diff.
Decision rule: If the rc change came from an account that should not manage startup logic, or if the added command launches from an unusual location, prioritise containment and review over cosmetic cleanup. If the change is legitimate, preserve the evidence and update the baseline so the next drift alert remains meaningful.
What good looks like: Teams can explain every startup script in scope, show who owns it, and detect drift before the system reboots into attacker-controlled persistence. The control is working when unexpected startup logic produces an alert with enough context to investigate quickly.
Practitioner takeaway: rc-script detection works best when you treat startup paths as a monitored execution surface, not just a configuration file set. The key judgement is whether a change can cause code to run automatically, because that is what turns a small edit into a persistence event.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org