Monday, April 27, 2020

Defending Forward, aka, hacking the hackers

So the Cyberspace Solarium articles [1] and many other pieces talking about "Defending Forward" have been quite confusing, and I wanted to draw upon a few decades of history to put this strategy in context. In summary, however, defending forward is a complex and expensive tactic that has a perhaps outsized space in our national strategy, especially as espoused by the Cyberspace Solarium.

The traditional graphic to show effort to replace pieces of hacker kit although obviously at the top is "people". :)

Part of the expense is that hackers are constantly rebuilding their tool chains. Burning their rootkits or trojans or exploits or C2s or targets has two effects: They switch to their backups or spend a few months doing a rewrite and then move on. Of course, when they rewrite their tools, they are going to do a BETTER job than before, and this means your tracking effort is going to get harder over time.

It's a bit like attacking a footlock in BJJ - you put your own sources and methods at risk by revealing what you know and what you don't know as this graphic clearly illustrates by showing someone's cell phone selfie and a black space for someone else.


Indictments, a crucial part of the US defend forward and national pressure effort, seeks to be even more longterm, by blowing an actual individual or group's cover. One obvious thing this has done (since it has not resulting in convictions or the cessation of Chinese hacking efforts) is lock the people we indict into their government system, instead of allowing them to migrate into defensive jobs in industry, which is probably not in our best interest. Alisa Esage, while not indicted, was sanctioned as part of a US effort and cannot give speeches in Europe because of this. Did this help us? Of course the smart thing for us to do is include our HUMINT sources in our indictments to provide cover for them. Apparently this has already happened, and I am late on the update as always.

A more extreme example of defend forward in cyber is, of course, the Israeli campaign in Iran, assassinating people involved in their cyber efforts.

Layers of Vulnerability in Cyber Campaigns

I'm going to rank these from easiest to hardest, but it is also walking backwards on the kill chain, if that's your thing.

There are of course multiple ways to skin the onion that is a cyber campaign. You can hack the targets of that campaign, and from those steal the toolkit used. This is a non-inconsequential purpose of some pieces of kit we already know about (sigs.py).

You can also hack (or collect) the C2 and launch servers used by hacker groups, as appears to have been done against many of the Chinese crews, some of which decided to use Facebook and other social networks from their exploitation boxes, blowing their attribution instantly.

You can also hit the analysis arms of various APT groups (i.e. with trojaned Office documents or directly if you can figure out who they are via HUMINT/SIGINT). This is the most long-term effect you can have against your adversaries.

You can also hack the hackers themselves, which is where historically things have happened amongst hacker groups. There's a rich history here that no cyber strategist should be unfamiliar with because it's the most important analogy to what Defend Forward is trying to do. Let's list some examples:

  • Mitnick Era - You can read about these exciting stories in all sorts of books, but they predate modern life so I don't recommend using them for basing cyber strategy on.
  • EL8/PHC/ZF0/#ANTISEC - I'm not trying to imply these are all the same, but they are a modern history everyone in cyber policy should know. 
  • Lulzsec - The public story is that they were eventually rounded up by law enforcement. The private rumors is that they were a victim of an OCO.
  • HackingTeam/GammaGroup - Phineous Fisher is still an unknown hacktivist force wandering around making offers for people to release databases. Lots of people drunkenly claim at conference parties to be him/her though, which is traditional in the hacker world. 
  • Dutch vs Russians - A classic example of modern defend forward from a partner state
  • Israel vs Kaspersky/GRU - I only believe about 10% of the NYT reporting on cyber, since it's usually super off-base but it's worth a read.
  • ShadowBrokers - We don't know the details of how this was done, but that was an opdisk, not stolen from C2 so belongs here as the primary example of how to do denial of national-grade capabilities correctly.


Even with this limited set of examples, it is possible to start putting together some context for how the defend forward strategy matches our capabilities and investment. Much of the public discussion of defend forward talks about escalatory ladders, but I'd like to frame a few questions here that I find more useful for analysis.


  1. Are we deterring adversary action, or simply shaping it to be more covert and have greater long-term impact?
  2. Is our activity cost effective and low on side-effects?

One thing I think people don't recognize about some of the efforts on the above list is they involve a different type of hacking team than most military or government organizations use today. In particular, 90's hacker groups (c.f. Phineous Fisher) often wrote bespoke tool chains, exploits, implants, C2, and everything, for each target. It was, in modern parlance, a vertically integrated supply chain. It epitomizes the opposite of scale and was highly targeted. 


The USG has the opposite issue - a thousand potential adversaries, but with the advantages of existing HUMINT and SIGINT infrastructure. The other major difference, of course, being the goal of many of these attacks. Once most attacks happened in the list above, the result was a mailspool drop, and in many cases, along with a full chain of the attack, which adds valuable credibility, and is a tool the USG has not yet used.

The "Forward" part of "Defend Forward" is hard enough. The other major issue is finding a way to cause an impact on your adversaries longer than a hummingbird's cough. The easiest metric for whether or not your cyber security strategy is a good one is does it give my adversary more difficult equity issues than I have. The downside of releasing what you know about a target's malware is that they can trace their OPSEC compromises, potentially finding YOUR malware. The upside is that larger corporations, American and otherwise, who have automated threat feeds that include your IoC information may detect and remove the adversary's access. 

On the other hand, they may not.

Friday, April 10, 2020

Informing cyber policy from the vulnerability treadmill

This is a non-trivial part of being in offense or high level defense.


I recently wrote on the technical mailing list DD about the vulnerability treadmill, which essentially is the huge workload taken upon every technical person in the industry to keep up with vast amount of exploit information that is released daily. This firehose of information is distinct from the databases set up by various agencies which are used as lexicons (CVD/CVE/etc.) so various products can in theory talk together over XML pipes.

When talking to policy groups I like to compare any offensive researcher's lifestyle as one where they spend a few hours a day reading every patent that comes out in any particular field. I do this because you often see news articles about how China has exceeded US patents in some area or another based on patent application counts.

But CONTENT IS A LEADING INDICATOR. If any five random Chinese patents are ten times as interesting for a professional to read than any five US patents, then you know what's up without having to do the math on who has more. It is this way with vulnerabilities as well.

One of the things that is distressing to technical experts in this area is the policy focus on "patching". Patching is not nearly as important as people (in particular, as the Cyberspace Solarium's software liability section) make it sound. If you look at two recent vulnerabilities, the Citrix Netscaler and the recent Symantec Web Gateway vulnerability, you don't see "patchable" vulns.

The first thing to see about the Symantec Web Gateway exploit (here) is that it only exists if an upload directory has been created on the device. I'm not sure how common that is. The other thing to note is that the thing appears to be written in PHP, and contain a million other bugs, so I don't really care if this particular bug is realistic or not. It's basically impossible to write secure software in PHP or Perl, which are languages which exist only to prove how hard it can be to write secure software in them.


The Citrix Netscaler exploit sends as similar message of "Your purchasing department failed and no patch is available for that kind of governance mistake".

"The bug here is ... someone installed PERL and decided to use it on their VPN"

This kind of vulnerability does not exist on equipment when your purchasing department has done their job of due diligence. You don't patch that kind of issue - you rip the equipment out and fire your purchasing manager.

And in fact, banks regularly do this! Josh Corman had a panel on software liability where he discussed a scenario where banks take all the risk and software vendors take none. But this is not true! Banks are extremely tough customers and the majority of Immunity's business for a long time was reviewing the code of various things banks wanted to purchase, BEFORE THEY PURCHASED IT. If we found vulnerabilities that indicated poor code quality, or if the vendor didn't have a process to handle the vulnerabilities we found, they simply didn't buy it.

But what does this bring to a policy discussion? Here are three things you can know from staying on that treadmill:

  1. Patching is often just a quality signal - it often can't be used as a metric for a lot of very complex reasons
  2. The Chinese are actually better at cyber than we are right now. We are the "near peer" in cyberspace. I've read all their public exploits and...that's the state of the art. Thinking otherwise is egotism.
  3. Any norms process is going to have to include a much broader group of countries than just the top three. The Scandanavian countries, South Korea, Japan, and a huge host of "secondary cyber powers" are all far past the point of no return when it comes to capabilities. It is as if we are starting the nuclear norms conversation, but you have to take everyone's views into account including Uzbekistan and GreenPeace. This may color your projections on how realistic these norms discussions are.