The Future of Adversaries is Software Development
“A year from now, you’ll wish you started to learn to code today.”
As security advances, issues get more complicated. They still have the same core basic security principles — those don’t change — but the quantity of detail for how those principles work in modern implementations increases.
For example, look at stack overflows. Once upon a time, nobody handled strings correctly in their C binaries, leaving buffer overflows everywhere. Fast forward to today, those simple examples of code injection flaws (the unchanging “security principle”) are rare and only found in obscure applications that haven’t gotten proper attention. Today’s state of the art requires bypassing memory protections, maybe spraying data onto the heap, grooming the conditions to be the way you need them to be. The injection flaws still exist, but to be a proficient practitioner in that discipline requires background knowledge a couple orders of magnitude higher than several years ago (e.g. Google’s Project Zero). This is great, because security is all about the economics anyway — it now costs more to weaponize a vulnerability.
Several other security disciplines are affected by increasing complexity, too. Today, let’s look at adversarial operations, both real and pretend (a.k.a. “red teaming”).
[Due to marketing hype, “red teaming” in this case means simulating an adversary group in a large scope, no holds-barred, we’re going after monetizable access (not Domain Admin), intrusion OPERATION. This has nothing to do with your pentesting or product testing “red team” here (P.S. stop calling it that). This is about getting as close as you can to the reality of how the best adversary groups operate, legally, start to finish.]
As organizations mature their landscapes, the low hanging fruit TTPs dry up. Life was simpler a few short years ago, when PowerShell was discovered as a great offensive playground. Adding a Cobalt Strike license (either paid, or, in the case of some of these groups, pirated) would take an adversary a long way. Some consulting red teams who get to introduce some of their less mature clients to the concept of red teaming for the first time indicate that older TTPs like these still work, sometimes with only minor tweaking. Breaches show us real adversary groups still achieve similar success following these playbooks as well. This models how nature works: there are apex predators chasing apex prey, and less capable predators taking easy prey. It sucks to be the injured, sick, or old Wildebeest when the lions show up, but your organization can choose to spend the time and money to become the Giraffe (they can kill a lion with a single kick).
As TTPs dry up, so does the tooling. This makes sense since “tooling” is the collection of software artifacts implementing a set of TTPs that an adversary introduces into the defender’s space (e.g. the offensive PowerShell and Cobalt Strike mentioned above). Is offensive PowerShell 100% dead? Certainly not. Is Cobalt Strike viable? In many organizations, yes, for a while longer as long as the operator can push its flexibility to its limits and supplement its TTPs with outside help. Likewise, in nature, a predator will find some lame Wildebeests here and there. Yesterday’s tools can run longer, at great risk of detection, just like a hand-me-down Honda Accord with 300K miles on it, but you risk missing your objective.
So as detection measures increase, the requirement for offensive countermeasures also increases. The game field gets tougher with defensive improvements like the introduction of more telemetry (e.g. the recently added new Sysmon DNS query collection), or, perhaps more important, the ability to quickly and accurately process the plethora of incoming events from this telemetry. This is the wildebeests lining up in tight formations around their weak and their young. Some adversaries, real and pretend, will see some of their operators unable to keep up. These lions will get tired and move on to something else. As a security industry, we should want and embrace this. But that means for those of us persisting on the quest to be the apex predator, there are new dimensions of knowledge that must become our active vocabulary. We race to become more creative than the defenders so we can provide world-class training opportunities for them; we want to bring a BlackHat level training exercise straight to them, unannounced on a Monday morning (or perhaps a Friday evening on a holiday weekend — sorry, not sorry). We cannot do this by following a lather, rinse, repeat playbook. If we can, then anyone can, and security fails for everyone.
“Shoot, Move, and Communicate.”
Common military doctrine says these are the three tasks you must prevent your opponent from doing successfully. Let’s substitute “code execution” for “shoot,” think “lateral movement” as equivalent to “move,” and remember C2 (Command/Control) is the “communicate” component. Now we can borrow their doctrine as an analogy into our discipline for a moment. These three tasks are what an adversary needs to succeed and what a defender must disrupt.
The security landscape will reach a point (if it hasn’t already) where the understanding of the nuances and edge cases of how code is executed and systems pass messages (“shoot, move, communicate”) requires intimate API level understanding of Operating System and infrastructure fabric internals. You won’t be able to survive leaning on somebody else’s tooling alone, because you may not have the fine-grained control over it that you need. Even if you do rely on third-party tooling, knowing the API structure will help you to select which tooling is best. You may have a blunt tool when you need a surgical scalpel. There will come a time when only the apex of the apex predators will be able to remain serviceable in the future of attacking apex prey. [I can hear some moans with that statement now — I’m not talking about your injured-gazelle-of-an-organization; you can accept mediocrity on your own terms — this article is not for you anyway.]
This brings us to the inevitable: code. You’ll need to be able to bring your own. Borrowing, stealing, and modifying somebody else’s will only take you so far, unless you have their source, or you have the ability to reverse engineer their binary into source you can modify. You’ll need to be able to understand the tradeoffs of different languages, compilers, compiler options, platforms, and how their output and artifacts look to defensive measures. You’ll need to learn development patterns that scale; patterns that take your code away from a one-hit-wonder console app (an over-glorified script) into a fully reusable library that can be consumed by more complicated projects needing to orchestrate several features in concert with each other. You’ll probably need to learn proper CI/CD and QA frameworks, so your foundation is not a jumbled mess. You’ll need to be a fully-fledged developer and learn from the mistakes of other developers. Or at least you’ll need to have a few developers on your team doing it for you, driving your tooling to meet your tradecraft goals. But if that’s the case, at some point, the developers may be all that your team needs. There may come a time when a non-coding red team operator becomes extinct. If you want to stay in the driver’s seat, learn to code.
An adversary operating on custom tooling is very expensive, compared to just pulling a PowerShell web cradle straight from GitHub to get a shell. This is what we as an industry truly want. Just like we want the required complexity to achieve a weaponizable exploit in vulnerability research — how this article started — we need an adversary’s entire tooling to require bespoke customization in order to succeed. At that point, only the fastest cheetah can take down the slowest gazelle.
In many ways, this isn’t a prediction; this is a weather report. The trend is already in motion.
We have seen the top nation state actors and criminal groups doing this for decades. Several of the top red teams are doing this on the simulation side. This is why I’ve joked that “2019 is the year of the C2 framework” with all of the new open source examples popping up. (A better example may be all the teams keeping their tooling private, demonstrating the economic impact from shared tooling.) Operators know they need to be different, to have more control, in order to acquire their prey.
Look at some of the advanced classes at security conferences. Just a few short years ago you might see many “hacking” classes, but only one (if any) focused on the development of bespoke adversarial toolkit. This year’s BlackHat training course list this year shows a 2x increase, from organizations like Silent Break Security and FireEye’s FLARE team (I have no monetary ties to either but recommend both), and others.
If you’re in the adversary space and you want to stay here for years to come, then you better be working on your dev skills.
