MicrosoftGood writeup. The point about sequence is the right one. curl, rsync, tar, openssl all look normal one event at a time. One thing from the data side I'd pair with this. On a lot of Linux servers the data the attacker actually wants, or wrecks, sits on an NFS export, a mounted volume or a bucket, not on the host itself. The incident graph tells you which process ran and when. It usually can't tell you which files on that share were rewritten, deleted or encrypted, or how far back that started. So So when a Linux box lands in an incident, get the storage team to pull snapshot history for the volumes that host could write to, and compare a few points across the window security gives you: change rate, renames, file types, files that suddenly look encrypted. That gives you a real answer on which snapshot predates the damage, instead of grabbing the newest one before the alert and hoping. Disclosure: I'm founder and CEO at CyberSnap, we work on that storage side.
MicrosoftThanks for adding this perspective. Great point. Correlating the security timeline with storage-level history can provide important context on the actual blast radius and help identify a known-good recovery point.
