Step 4: Recovery, After remediation, validate that no persistence mechanisms remain: review scheduled tasks (Windows), cron jobs (Linux/macOS), startup items, and shell profile modifications on affected hosts. Re-scan affected systems with EDR tooling post-remediation. Monitor outbound network traffic from previously affected hosts for 30 days for signs of residual C2 activity. Rotate credentials, tokens, and SSH keys stored on or accessible from affected developer machines, CI/CD runners, and build environments, as the RAT may have exfiltrated them during its execution window.
Recovery
NIST 800-61r3 §3.5 — Recovery
NIST IR-4 (Incident Handling)
NIST AC-2 (Account Management)
NIST IA-5 (Authenticator Management)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
CIS 5.3 (Disable Dormant Accounts)
CIS 6.2 (Establish an Access Revoking Process)
Compensating Control
Use the following platform-specific commands to enumerate persistence artifacts on affected hosts before declaring them clean. Windows: schtasks /query /fo LIST /v > scheduled_tasks.txt and reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run > startup_registry.txt. Linux/macOS: crontab -l -u <each_user> > crontabs.txt; cat /etc/cron.* >> crontabs.txt; cat ~/.bashrc ~/.bash_profile ~/.zshrc ~/.profile > shell_profiles.txt; ls -la /etc/init.d/ /etc/systemd/system/ ~/.config/autostart/. For credential rotation prioritization, enumerate secrets accessible from affected CI/CD runners using: grep -r 'AWS_SECRET\|GITHUB_TOKEN\|NPM_TOKEN\|SSH_PRIVATE\|API_KEY' ~/.bashrc ~/.profile ~/.zshrc /etc/environment .env* ci.yml .github/workflows/ — rotate all discovered secrets immediately in their respective platforms (AWS IAM, GitHub, npm registry). For 30-day network monitoring without a SIEM, configure a lightweight Zeek or Suricata instance on a network tap or span port and write a custom rule alerting on outbound connections from previously affected host IPs to non-approved external destinations.
Preserve Evidence
Before declaring recovery complete, document: (1) Results of scheduled task and cron job enumeration commands above as a timestamped baseline proving no RAT-installed persistence entries remain. (2) Shell profile file checksums (sha256sum ~/.bashrc ~/.bash_profile ~/.zshrc) compared against a known-good baseline or git-tracked dotfile repo — the RAT may have appended a reverse shell or beacon invocation to these files. (3) SSH authorized_keys file contents (~/.ssh/authorized_keys on all affected hosts) — a cross-platform RAT with SSH key access would add an attacker-controlled public key for persistent access. (4) npm token and registry authentication state from ~/.npmrc and CI/CD environment variable stores — exfiltrated npm publish tokens would allow the attacker to repeat the supply chain compromise against your own published packages.
