FeedDiscussion
Solid playbook, the ctime vs mtime timestomping point alone is worth bookmarking.
One thing I'd add right at the top, before any of the /proc work: the opening scenario mentions an SSH session "from an IP address block in a country where your engineering team has zero presence," but that judgment call is doing a lot of work and it's worth making it explicit rather than trusting the alert. A quick geolocation + ASN lookup on the source IP tells you fast whether you're looking at a residential ISP in an unexpected country (bad sign) or just a known corporate VPN exit / cloud NAT range that happens to geolocate oddly (false alarm). ipgeolocation.io's free tier is enough for this, one call gives you country, ASN and organization/network type, so you're not burning time on /proc forensics for what turns out to be a coworker on a company VPN.
Worth wiring straight into the alert itself so the country/ASN shows up before anyone even opens a terminal.
This is one of the most thorough triage playbooks I've read here - the ctime-vs-mtime timestomping point and catching the pty-less sshd session via ss instead of w are both things most writeups skip entirely. One gap worth flagging for anyone running this against a cloud-hosted replica specifically: none of the persistence vectors here check the instance metadata service. If db-prod-01 is EC2, an attacker with even a few seconds of shell access can curl 169.254.169.254/latest/meta-data/iam/security-credentials/ and walk off with temporary IAM credentials that keep working long after you've frozen the box and rebuilt from known-good IaC - no local persistence needed at all. Worth checking VPC flow logs or CloudTrail for that request alongside the /proc and ld.so.preload checks (GuardDuty flags it directly as InstanceCredentialExfiltration), since the "rebuild the instance" advice at the end doesn't help if the stolen credentials are still valid off-box.