Red Teams Think in Algorithms

Everything can be done algorithmically, even responding to security alerts.

Let me tell you a story …

#A Red Team Story

About 6-7 years ago, I was talking with a Red Team who had been contained within hours a handful of times in a row by their Blue Team peers. It was a new experience for the team.

Keep in mind: no detail was missed in the Red Team’s preparation. All infrastructure was perfectly aged, with categorized DNS domains over a year old. Only fresh payloads known to be “clean” by endpoint tools at that time were used. The phishing lures were excellent and would have caught any of us–including me. The team had good post-exploitation strategies for what to do after their payloads phoned home and initial access was achieved. This team knew what they were doing.

But the team of defenders who used these engagements as training didn’t want to “lose” another one. They were hungry to shut down threats. They were hungry to win. And that’s what they did, multiple time in a row!

So I took the Red Team into a conference room to brainstorm and whiteboard a solution. We didn’t think we could evade setting off a detection alarm at some point, so we knew we were just going to have to go faster. That’s when it hit me: let’s build an algorithm to do what red team operators do after payloads phone home.

One of the most senior Red Team operators, and my long time personal colleague, told me it couldn’t be done. So I pushed him on it:

“What do you mean it can’t be done? Tell me what it is you do every time a shell lands. Then we can build an algorithm to replicate that. We can do your work in code.”

“I don’t know. I have to feel the shell”

“What? What do you mean feel?”

“I mean, I don’t know. I have to see what kind of device I’m on. Maybe look at [x] directory or [y] directory.”

“OK, good. You’re defining an algorithm. Keep going.”

“Well, then I’m probably going to look at [z].”

“OK, what will you do if it’s [A] vs. [B]?”

“Well, I’d start to …”

And that conversation led to building a malware C2 framework that would automate the collection of data the operators wanted to know when they first got access to a shell. Rather than sit there, dumbly and idly, then get paged at 3 AM when the shell finally phoned home for the first time, the C2 would collect what the operators would have manually collected, giving them situational awareness of what access they had and where they were. All of this information was placed into a heads up display for them to make faster decisions. From there, the algorithm was also extended to do some of the final stages of collections, wrapped in conditional logic that could be tweaked in configuration between targets. That conditional logic was the codification of their personal decision making approach.

Just like that, the Red Team were fast again, and the time pressure of getting contained in hours did not as badly as before, because time wasn’t wasted. The next time a 3 AM shell from halfway around the world phoned in for the first time, a clean and simple algorithm ran, collecting all of the situational awareness information a manual human operator would have collected, but in seconds compared to their 30+ minutes of stealthy cautious collection. Then the algorithm made decisions it was allowed to make, collecting some target data that previously would have been manually collected. It was all done before a groggy human could get hands on keyboard.

The ever-vigilant Blue Team peers, with a very well-instrumented environment, eventually saw an indicator and succinctly contained the threat. The shell was lost before a human could do much with it. But in post-mortem analysis, the Red Team realized there really wasn’t anything else that could or would have been done with that host. The algorithm did all the important work. What the Red Team didn’t get, resulted in an update to the algorithm for next time.

Continue with the Blue Team sequel to this story.

---

Want to see what Wirespeed is all about? Follow us on LinkedIn / X or join our mailing list.