Incident Response and OPSEC
It’s always important to consider OPSEC when performing incident response. We regularly work with clients to ensure that they don’t cause issues for themselves during the investigation. Tipping your hand to the attacker can result in a failed containment, which likely will lead to a failed remediation.
Today, while teaching my last SANS Incident Response course (for those who don’t know, I’m leaving SANS), I suspect one of my students submitted part of a payload to PasteBin. Many bots sift through Pastebin content to discover potential malware, and sure enough this is malware.
Paul M. (the operator of the bot that found the content on Pastebin, opined that this smelled like a Red Team to him.
This led to an interesting discussion, terminating when I paged Tim Medin, the operator who owns the domain in question.
But this brings up an interesting point about OPSEC in incident response. Had this been a real incident with a real apex predator on the other side of the keyboard, uploading the payload to Pastebin there’s a non-zero chance that the attacker would have been watching. In response, they would have changed TTP’s or possibly taken destructive measures.
Why was it uploaded?
I don’t know for sure who uploaded the payload. I do know that at least one team was having trouble sharing some data because a team member couldn’t disable the AV on their laptop. I strongly suspect a technical limitation led to the OPSEC failure.
OPSEC, OPSEC, OPSEC. Every time you make a piece of data potentially public, understand what you could be giving up to the adversary. Try to play that chess game a few moves ahead. Also, learn your IR team’s workflows and make sure you don’t have technical controls that make Pastebin “the best bad plan” for transferring a malicious PowerShell script.