Finally, the response stage, which happens after the alert has been confirmed to be a true positive and an incident has been declared, involves the eviction of the threat actor. After determining the scope of the incident (how many systems, users, etc. are involved), security teams have many options to clear the attacker out, ranging from simply rebooting the host to clear out memory-resident malware to drastic measures like burning down their entire environment. Ultimately, success is binary here — either the adversary was fully evicted or not.
The biggest mistake I’ve encountered in this stage while in a red team is when the defense team improperly scoped the incident, leading to incomplete eviction and allowing us to persist in the environment for nearly 18 months (we were eventually kicked out only when the server on which we persisted was decommissioned by their IT team as part of a tech lifecycle upgrade process). Improving the response process to reduce an adversary’s chances of evading eviction comes down to having solid processes that have been rehearsed, the ability to identify the whole scope of the compromise, and the ability to validate the complete eradication of the adversary.
Documentation
Describing XDR evasion with sufficient granularity allows us to better identify which component of our detection pipeline failed and, more importantly, what we can do to fix it. Most evasions can be grouped into either observation (whether the XDR saw the malicious behavior), detection (whether the XDR positively identified the behavior as malicious), or response (whether the behavior led to an adequate response by the security team). During your next encounter with evasion, push for more descriptive language to be used and see what improvements to your remediation process can be made.
