The next three posts will concentrate on the application of forensics to our deception network. First, please note that I will be dealing with three levels of cyber forensics: network, computer, and application (usually malware). These three posts will concentrate on the network aspects of forensics, and I'll get into the other two in a future series.
As you will see soon, one of the most useful aspects of a deception network based upon machine learning is that it can look at devices it can see and, using machine learning, craft similar devices that are, simply, decoys. Given these devices, the attacker does not know where he is in the enterprise and ends up going down a rat hole into a sinkhole. On the way, he reveals a lot about his TTPs.
Last week, if you recall, I introduced the deception network and told you that I had configured a decoy on the internet. There is a difference between a decoy and a lure. Decoys are places, lures are things. The place for last week's decoy was a web server. It had a landing/login screen as shown here in Figure 1.
Figure 1 - Deception net decoy on the internet
The deception net used that as a model and created several clone decoys with exactly the same parameters inside the network. This gives the attacker the impression that he can—once the outside is penetrated—get to the internal network. If he enters the network in some other manner, he finds the internal decoys and proceeds to hack them. Figure 2 shows the current internal decoys as seen by a device on the internal network. At this point, we don't know whether or not that device has been compromised, but we know that it can see our decoys. In an real system, those servers actually would be the internal-facing IP of the web server, and that IP typically would be used by webmasters and system engineers.
Figure 2 - Decoys (blue) in the Internal Network as seen by an attacker (red)
Let's have a look at 192.168.1.122. This is particularly interesting because of the red arrow going from 192.168.1.106 to it. That means that there has been some high-risk activity between these two devices. I'll get into more detail about that shortly. But for now, we can see that there is some interesting activity involving our attacker and three of the decoys. Tactically, this is important because we know a couple of things: first, our attacker has somehow gotten into the network—if he is an attacker at all… more on that in a moment; and second, he has found our decoys. Let's take a poke at the first question: how did he get into the network in the first place?
For that, we need to see the big picture. We'll look at the network as a whole—decoys and real devices—and see if the 106 device has been compromised. Figure 3 backs us away from the attacker, and if we look carefully, we'll see that there has been no attack against him that would compromise that device.
Figure 3 - Internal deception network showing no external connections
You will notice that the decoys and the .106 IP all are connected to Port-6, the internal port. You'll also notice that all IPs are internal IPs (192.168.1.*). If the .106 IP was compromised from outside, there would be an inbound connection associated with Port-5, the internet-facing port. However, in a later post, I'll explore that possibility a bit further and identify what the .106 device actually is. For now, though, we know that we have something internal that is seeking out decoys and attacking them. Of course, the .106 device does not know that it is attacking decoys. If I was to add some lures such as documents, credit card numbers, or other desirable content, or show enough email addresses that the BOTsink could start creating deceptive emails, that would make the decoys more attractive to the attacker. But we'll get into lures later.
Let's digress a bit and look at the architecture. First, BOTsink comprises a set of some number (depending upon the model; in our case, six) of virtual machines. On our system, we have CentOS 7.0, Ubuntu 1.24, Ubuntu 1.31, Windows 7-64 bit, Windows 7, and Windows Server 2008. We can configure each of those VMs and then—because there are 32 possible ports for each machine—we can identify 32 additional IP addresses. Each will have the characteristics of the VM we set it up on, and we can connect to each VM directly through the IP of the virtual target. In this use case, all of our decoys are on the Ubuntu 1.31 VM, so we can go into any for the IPs and access the decoy for forensic evidence. Figure 4 shows the decoys' configurations. I SSH'd into 192.168.1.122 and showed the configuration.
Figure 4 - Decoy System Information
Note that the IP addresses for eth0 and eth1 are internal to the Ubuntu VM. These IPs are not accessible from the network, so decoys do not appear to be VMs, a dead giveaway to intruders that they are in a honeypot. The deception network sends everything that it sees going against a decoy to the sinkhole, so nothing runs the risk of escaping the deception network and entering the real network.
Next time, I'll dig a bit deeper into the decoy, look at it directly, and see if we can identify the attacker. Just a reminder that there are several deception networks out there. I am particularly fond of BOTsink, though, for its ease of use and configuration. It has lots of nice features, but, as they say, your mileage may vary. I've been using it a long time, and this old dog hasn't learned a new trick in many a long year—but I'm always looking.
~~~
Read the first three installments in this series here:
• Part 1: Getting Started
• Part 2: Learning the Lingo
• Part 3: Meet the Deception Network
