Last time, we looked for a phantom attacker from inside the deception network and found that it was not an attack at all but, rather, was the normal activity of our AlienVault UTM scanning the internal network. Had we gone further, we could have whitelisted the UTM and we would not have seen the phantom attacks in the future. This is a common occurrence, and we can whitelist any device that shows up as false positive activity in the deception net.
This time, we are going to take the first step to identifying malicious activity against our perimeter. I started by looking at all high severity events against the perimeter over the course of a week. As Figure 1 shows, that was quite a lot.
Figure 1 - High Severity Attacks Against the Deception Net's Perimeter
That's a lot of attacks, so what I really care about are those that comprised a successful login but were not for user admin, since I purposely set admin up with an easily guessable password. I found two: root and ubnt. There were no successes for root but there were for ubnt. Extracting the log for the event from the deception net, I get:
Figure 2 – Deception Net Event Log
This is an example of compromising the device and downloading tools (using wget) from an external server, probably maintained by the attacker. In this case, we can see that the attacker is 52.170.149.131 and the target is our decoy 108.85.99.13.
Noting that the target port is 22, we can see that this is an SSH attack. Looking up the attacker using Cisco Investigate, we find that he is attacking from a Microsoft Azure server. (This does not mean that he is a legitimate user, of course; he likely compromised the host. This is common with Microsoft Azure and Amazon Web Services.) Our hypothesis is supported by the fact that the host from which the attacker downloaded his tools is part of AWS, again, likely compromised by the attacker. This host is a well-known repository of malware. Shodan reports the IP as being in Tokyo, Japan, and shows many vulnerabilities.
A check with Recorded Future reveals that the attacker is known but has only been referenced by Recorded Future in black and gray lists for a single day. However, there are multiple accesses reported on the various lists themselves. Recorded Future gives the IP a risk score of only 38 (out of 100): "suspicious." Shodan lists a large number of vulnerabilities on the host, suggesting that it was, in fact, compromised. AlienVault's OTX reports that there are three pulses from community members identifying the IP.
I logged into the decoy to identify the details of the files that were dropped on it, not expecting to find anything, of course, since the log shows clearly that the attacker removed them after using them. Because our host is a decoy, the attack was not completely successful, since it went into the deception net's sinkhole without doing any damage or transiting the network.
My next action—after blacklisting the attacker and his tool repository—was to step up the game a bit by looking for very high severity attacks over the past week. In this I was successful, but first a quick word about blacklisting IPs. You may well have mixed results in this. If the host that you blacklist is hosting other IPs, those still will be active and, if they are malicious, all you've done is move the attacker to another one of his platforms. Now on to the very high severity attacks. Figure 3 shows what I found.
Figure 3 - Attacks Labeled Very High Severity Against the Perimeter
Note that there are three attackers against two decoys. Let's examine these a bit more closely. Our deception net tells us that the attackers are from Romania (attacks against web services) and China (attacks against telnet). Our attackers have selected both of our internet-facing decoys as targets and have attempted to inject shell code in all cases.
Let's begin by examining the shell code for these two attacks. Our deception net allows me to extract the shell code and, if it can, it will decode the shell script. We'll start with the telnet attack. The shell code that the attacker is attempting to inject is:
Figure 4 – Shell Code 1, Telnet
This suggests assembly code, but it is not clear—to the deception net, anyway. There are a lot of possible reasons for this, including garbled data, encrypted or modified code (perhaps using base 64?), or simply lack of skill on the part of the attacker. Examination of the decoy does not reveal any action taken by the injected code, so we can assume the attack failed.
Moving to the web services attack from Romania, we get a somewhat different picture:
Figure 5 – Shell Code 2, Web Services
This is pretty blatantly assembly code. Looking at step 1, we see the instruction adc (add with carry). Following the code, we see that the attacker is repeatedly loading 000 to the low byte (al) of the eax data register. This suggests a buffer overflow attempt, probably in web services. The purpose, of course, is to allow the attacker to execute a command from within the service, likely http. Because the deception net prevents this type of command execution, we see no evidence of it succeeding. However, this IP (185.100.87.190 - Bucharest, Romania) is rather notorious, according to Recorded Future, even though it has a rather low risk score. Shodan shows no vulnerabilities, and access is through port 22 (SSH). Likewise, there are no malicious files present. Recorded Future tells us that the IP has been caught in honeypots and has been historically reported as linked to other attacks. This smells like an attacker's platform.
In this article, I have addressed some of the basics, including the use of some internet forensics tools, to characterize an attack against the perimeter of our deception network. In this case, not only have the attacks been derailed by the BOTsink, we have gathered enough valuable information to block future attacks.
Next time, I will dive a bit deeper into the forensics, including some endpoint capabilities of the deception network that let us look at memory.
