Tradecraft Please!

“We’re gonna hand you the tools — the black arts. Not witchcraft — tradecraft.” — Al Pacino, in The Recruit

Wait, What? 

Tradecraft is a term only some know from a specific line of work, Intelligence. Tradecraft encompasses the techniques people use during intelligence operations to steal and pass information, avoid detection, blend in, and cover their tracks. 

It’s Not an Attack, It’s Espionage

Whether you like it or not, you’re in the spy game. Almost all network intrusions are mislabeled by marketing and advertising as attacks. “Stop attacks as they happen!” “Stop attacks before they happen!” “Understand what happened during the attack!”

Well, how much physical damage are they causing in your network? How much data corruption are they causing in your network? How much data are they stealing from your network?

If you answered the last question more thoroughly than the first two, welcome to the world of counterintelligence. 

The Technical Problem with Network Defense  

Network defense today is made a technical problem, not an intelligence problem. For some breaches, this is fine. Ad campaigns, ransomware, browser drive-by, etc. A lot of that stuff is automated and can be treated as a technical problem with the wipe and reload methodology as the answer.

But when you treat advanced threats as a technical problem, things start to break down. Advanced threat actors are using a myriad of tradecraft within a single operation against your network. They have a reason to be there and they have an end game.

By making network defense a technical problem, you rely on detection measures that are driven by atomic signatures and anomaly detection. This leaves you a pile of un-correlated indicators that may or may not have something to do with an intrusion, let alone something to do with the same intrusion.

Just because you can put a bunch of analytics in a box, doesn’t mean you should.

Analytic Tradecraft and Desired Outcomes

Someone once told me:

Before you sit down and start analyzing, understand exactly what questions you want answered. Otherwise, you’ll analyze forever.

When analyzing for threat activity, you must keep this in mind. You should know exactly you’re looking for, and when you find it, have a plan for how to react.

When you plug in a magic box into your network, do you really know what the desired outcome of its analytics are? Lots of products are placing all sorts of analytics in a box that look for known threats and detect new anomalies, but they fail to identify a discrete problem in the world of cyber intelligence that they are trying to solve.

At Efflux, we’re looking for something. We’re building our analytics to target the tradecraft of human interactivity on the network. That magic moment, when on the other end of all those TCP sessions, there’s a human, typing at their keyboard, tearing through your network going after whatever it is they are looking for.

Going After The Human

We aim to target the specific network activity that is generated by human interaction for one reason: vulnerability. It’s the moment when the actor is most vulnerable. For someone to be controlling malware or using built in remote access tools (yes, all of your computers have those), a virtual circuit leads from the target computer(s) all the way back to the actor.

From a counterintelligence perspective, this can reveal a lot of information about your unwanted visitor:

  • What parts of they network they are interested in going after
  • What resources they are using for C2 (cloud providers, VPS)
  • What resources they are using for exfil (cloud providers, databases, etc)
  • What access methods they have to your network (backdoors, credentials, rootkits, etc)

When the human at the other end of the circuit is “live” in your network, they’re combining lots of tradecraft to make that happen. We’re not making it a technical problem, we’re making it an intelligence problem.

The exact means for adversary to do this is not so important at the discovery and triage stage. And you certainly shouldn’t be trying to chase down exploit methods this early on… Worry that it’s bad, worry about how to stop it, worry about the technical details of how it all went down later.


Triage Now, Investigate Later

By making detection and discovery an intelligence problem, you abstract away the nitty gritty details of the “how” for a later investigation.

Early on, the triage of advanced threat activity needs to be kept short and sweet:
“A lateral remote desktop session between DHCP hosts is underway, it is being tunneled and controlled out through a cloud service provider, the person is zipping up documents and uploading them to a cloud based file storage service.”

Three pieces of tradecraft, one event. Respond.
That’s what Efflux is doing.

I'll fill in the exact details later. I’ve found that the laborious act of today’s triage is partially due to the use of a very hacker-centric kill chain. Where defenders are left “filling in the blanks” of various stages of the kill chain that the hacker may have used.

In a later post, I’ll cover a consolidated kill chain that should focus more on the defender’s analytic tradecraft, and is better suited for the triage and initial response to malicious events.