Welcome to a new multi-part discussion of the application of some next generation tools for current challenging as well as next generation attacks. In this series of blog posts, I'll address the use of deception as a defense and apply forensics in the mix. I will focus on deception networks and enterprise-grade forensics using some tools that I've had in my lab for a couple of years. More about the tools later. I define next generation tools as those that incorporate some form of AI—usually some form of machine learning—and I define next generation adversarial TTPs similarly.
The key issues we'll examine all have to do with next generation tools and techniques coming of age in the underground. While there is very little underground use of AI at present, there are techniques that are in use today that make detection and response very difficult. They also are capable of obfuscating attacks, making forensics challenging. And, make no mistake, we are on the verge of cutting-edge attacks such as autonomous bots.
But, the bots of the [near] future are not the only things that artificial intelligence has brought us. Consider, for example, deepfake images, texts, and audio. This machine learning technique is in use already and promises to become more of a challenge in the future. So, it is useful to dig into the issues surrounding our use of next generation tools to combat next generation threats. Some of the topics I'll take up in this series are deepfakes, machine learning, deception, and adversarial machine learning. These are emerging areas of both attack and defense, and our defense kit does not need to—and, in fact should not—wait until the adversary masters the use of AI in attacks.
The series of blog posts that this one starts off will be strategic and tactical in nature. I am not going to go too deeply into operations issues—there is a lot of that available already—and I am not going to give specific product-based "how-to" tutorials. There is a lot of that available, as well, much of it from the vendors who should know their products well enough to teach any operational training necessary.
As we progress, I will give examples of current advanced and emerging next generation attacks and how to use next generation tools against them. I'll point out potential tool weaknesses and how to work around them. I'll give specific examples and show screen shots from my lab of the examples as I explain them. I am using some tools that I have a lot of experience with, but there are others (in some cases) that you can apply as well. Because the speed of the adversary is increasing exponentially, I am going to focus upon automation and enterprise grade approaches. We have reached a point where a human cannot respond adequately to a concerted, sophisticated attack that is shifting its focus at wire speeds.
A cautionary tale to get us started
Over the next few weeks, I'll use some terms with which some of you may not be familiar. It makes sense, then, to start out with a brief look at the terms and techniques to which I'll refer, obviating the need to explain as we go. I'm not going to take a deep dive into most of these technologies, but I'll cover enough so that you'll understand what I'm talking about.
Before I start that, though, here is a hypothetical attack that illustrates where we'll go in this series. While I do not believe that this attack—or even one quite like it—has yet occurred, each of the technologies mentioned are alive and well today. More important, this hypothetical sets the stage for the types of challenges I'll take up here over the next few weeks.
We'll define our victim as a very large European bank with an online banking capability. The bank has, as one might expect for a bank of its size, a sophisticated security stack. Much of the collection of security tools are next generation tools with machine learning (ML) capability. Sensor placement is good and the IT security team believes that the bases all are covered.
Our attackers choose a bank holiday to launch the visible part of their attack. At around 1 a.m. local time on a Saturday, the NOC engineer notices that a lot of accounts are being emptied. This takes place over the span of just a few minutes before the engineer can disconnect from the internet. By that time, several million Euros have been exfiltrated along with payment card data.
Of course, the money had to go somewhere, so when the cyber forensics team arrives that is where they start. However, there is no record of any bank transfers; the money simply is gone. The next forensic step was to search for artifacts on the compromised servers. There are none. Finally, the network monitoring tools—all of which use ML—are queried. Nothing there either. It is, on the surface, the perfect crime. Millions of Euros and hundreds of high-value payment cards are gone, to where nobody can tell. Certainly, the payment cards will surface in an underground dump shop, but by then it will be even more difficult to trace the cyber crooks.
How was the crime committed?
This is a complicated crime. It requires a lot of advanced planning and a lot of advance work to prepare for the ultimate smash-and-grab that occurred on that fateful early Saturday morning. Here is one way this could have been accomplished.
First, the adversary established a huge hive net. The hives are comprised of large numbers of autonomous swarm bots. The swarm bots communicate with their hives and the hives communicate with each other. There is no command and control as we are used to seeing with current botnets. The hives, and thus the bots, are given their mission by the hive master who programs a single hive. The hive creates more hives and then destroys itself to avoid tracing. The hives program/create swarm bots, and the bots go to work sharing data with each other through the hives and, using ML, learning from each other.
Each bot's mission is to enter the target undetected, steal a single set of credentials, exfiltrate to a web site, and destroy itself. Entering the target undetected depends upon knowing what the border guard is looking for. To learn that, the bots launch multiple attacks and observe the network monitor's response. This is called "querying the oracle." Once that information is known, the hive can autonomously craft an attack that will appear to be business as usual and penetrate the network. The bots only steal and exfiltrate a single set of credentials to avoid raising any alarms.
Instead of swarm bots and hives communicating with standard IP addresses, they use blockchain DNS. It's not untraceable, but the technique does obfuscate data paths sufficiently to slow down investigators until the address is of no use. Where did the money go?
Once the bots are finished slowly exfiltrating the credentials, the smash-and-grab occurs. An army of swarm bots armed with credentials enters the system simply by logging in normally. Each bot sends out its money and destroys itself. The money goes into the Blockchain as crypto currency and no longer is traceable. The money is gone, the paths are gone, and the hive master issues a command that destroys the hive net.
This type of scenario has a few flaws, and over the next few postings I'll take them up and show you some ideas as to how you might set up your defenses. Next posting, we'll take up the issues of definitions and vocabulary I mentioned earlier, and then I'll introduce you to deception networks, one way to defend against this type of attack—and today, it probably is the most reliable. For that, I'll use Attivo's BOTsink. This is my primary experiment/test platform here in the lab, and, while there certainly are other choices, I know this one pretty well and it has served my needs for a couple of years or so.
