Incident Response Without Root: Contain the Persistence

An alert fired: this host is beaconing out every minute, and the schedule points at cron. You've been paged as the responder — but you are NOT root on this box. You landed as 'student', an on-call account with deliberately scoped access. Your prompt is $, and that is the reality of most real IR: you arrive with the access you were granted, not a root shell.

Good news: looking doesn't need root. Triage with what you have — read /etc/cron.d (those files are world-readable), follow the schedule to the payload it launches, and corroborate the alert against what the beacon has already written to disk. You'll find a rogue cron job and the script it drops-and-runs.

Bad news: you can't just fix it. The cron file and the payload are root-owned — rm is denied, and so is killing a root process. Whatever you do about them has to come out of the access this account was actually granted, so establish what that is before you reach for anything else.

And however you neutralize them, the artifacts themselves have to survive. The investigators need both intact for root cause, so a response that destroys evidence is a failed response even if the beaconing stops — both artifacts must end up preserved in this host's quarantine store.

The workflow: triage as yourself → discover your grant → escalate only for the sanctioned containment step → leave the evidence intact for the investigators.