author photo
By Dr. Peter Stephenson
Sun | Aug 2, 2020 | 6:45 AM PDT

In my last post, I pointed to an attack against an internal device apparently originating from other internal device, none of which had any—nor had they ever had—connections from outside the deception network. Although there were several such connections, I am going to select two for analysis. If both present similar analyses, we will stop there. If they are vastly different, we will continue looking at others. Figure 1 shows the two that we will examine.

Figure 1 - Phantom AttackersFigure 1 - Phantom Attackers

Now, let's take a close look at the attacker. Its specs appear in Figure 2.

Figure 2 - Attacker SpecificationsFigure 2 - Attacker Specifications

The thing that jumps out at me is the operating system because there is no VoIP running on our test network. 192.168.1.106 is a real machine, not a decoy, so this is of interest. We have a few possibilities. First, the attacker could be a rogue machine running a VoIP OS. Another possibility is that it is a legitimate device that just happens to be running VoIP. And the third possibility is that it is a false positive. Let's explore these.

I'll start by doing the obvious: attempting to connect to the device. I'll do that simply by browsing to the IP and seeing what happens. The result is in Figure 3.

Figure 3 - 192.168.1.106

Figure 3 - 192.168.1.106

This is my AlienVault appliance which apparently uses the BATM VoIP adapter. Since this is a UTM—similar to a SIEM—it is logical that it would be contacting other devices on the network. In this case, the UTM is checking for vulnerabilities. Due to the similarities between Windows 7 and Windows Vista, sometimes it interprets the host OS as one and sometimes as the other. The scanning of these two host addresses is normal behavior for the AlienVault appliance, so we have no concerns on that account. My conclusion is that this is a false alarm.

Going a bit deeper, we go to the events analysis on the deception net and find that this is a typical logon by 192.168.1.106 to 192.168.1.3. This type of logon is commonly some form of monitoring. The deception network gives us the following description:

Windows Logon Success ( WinEvtLog; 2020 Jul 27 09:54:35 WinEvtLog: Security: AUDIT_SUCCESS(4624): Microsoft-Windows-Security-Auditing: (no user): no domain: Windows7-64: An account was successfully logged on. Subject: Security ID: S-1-0-0 Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 New Logon: Security ID: S-1-5-7 Account Name: ANONYMOUS LOGON Account Domain: NT AUTHORITY Logon ID: 0x571cd794 Logon GUID: {00000000-0000-0000-0000-000000000000} Process Information: Process ID: 0x0 Process Name: - Network Information: Workstation Name: nmap Source Network Address: 192.168.1.106 Source Port: 54206 Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): NTLM V1 Key Length: 128 This event is generated when a logon session is created. It is generated on the computer that was accessed. The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (netwo )

I've highlighted some important points. The nmap Source Network suggests that .106 is scanning .3. Because there is no indication—either on the BOTsink or the AlienVault of an external connection to .106—I concluded that this is a scan from the AlienVault SIEM (the UTM contains SIEM functionality) against .3 and .222. This does not constitute an intrusion, it simply is business as usual for the AlienVault device. I also should point out that .3 and .222 are virtual machine interfaces—decoys created by the BOTsink.

Let's examine the relative benefits of the deception network and other forms of monitoring. Given the example above, it should follow naturally that we get a broader picture of the adversary's efforts against our enterprise. Of course, we can get a similar picture from any number of other tools with one major exception. Because the BOTsink is a next generation tool, it is learning the enterprise constantly. We'll address how it applies machine learning in a future posting dealing with Active Directory. Suffice it for the moment, however, we will say that the BOTsink uses AD extensively to learn the enterprise and how it operates.

That allows the BOTsink to create decoys—so far I've created them manually—that conform to the rules set in the enterprise's AD. This provides an authentic extension to the real enterprise, and the adversary is hard-pressed to tell the difference between a decoy and a real device. Since the BOTsink takes measures to deflect the adversary from real devices and lead him to decoys, the deception network is a proactive defense as well as a data gathering tool.

A portion of the dashboard of our BOTsink is shown in Figure 4.

Figure 4 - Key Metrics BOTsink DashboardFigure 4 - Key Metrics from the BOTsink Dashboard

Note that we show four active decoys and 10 of 11 real IPs discovered. The decoy configuration is shown in Figure 5.

Figure 5 - BOTsink DecoysFigure 5 - BOTsink Decoys

Note that the IP Address column shows a U next to the address. That means that the decoy was created manually by the user. In a future post, I'll discuss the other types of decoys and lures.

Now, let's dig a bit deeper while we have a fairly simple configuration. Since we have explored the phantom attacker and decided that it was a normal occurrence generated by our AlienVault device, let's move on to an actual attack against our decoys. I have not set up AD on the test network, so, as you saw above, the decoys are created manually. I'll use, as an example, 108.85.99.13, an Ubuntu VM. Figure 6 shows the activity against that decoy.

Figure 6 - Attack Activity Against 108.85.99.13Figure 6 - Attack Activity Against 108.85.99.13

I've limited the search to only those where the keyword "success" appears in the description. So what we're looking at are the SSH login attempts that were successful. Figure 7 shows the sequence from the BOTsink logs of one of the attacks.

Figure 7 - BOTsink Log Attacks Against 108.85.99.13Figure 7 - Spreadsheet of the BOTsink Log of Attacks Against 108.85.99.13

We can get further detail from the log by drilling down as shown in Figure 8.

Figure 8 - Attack Log DetailsFigure 8 - Attack Log Details

If the adversary performed other tasks, such as dropping a binary or moving within the device, those details would show as well. Apparently, our attacker was content for the moment with gaining access. An example of this also shows up for 88.214.26.93. The BOTsink log details are in Figure 9 and 9a, and the syslog from the target device (108.85.99.13) is in Figure 10.

Figure 9 - BOTsink LogFigure 9 - BOTsink Log

Figure 9 - BOTsink Log 2Figure 9a - BOTsink Log

Figure 10 - Syslog Entry Username Password CompromisedFigure 10 - Syslog Entry from the Device Showing Username and Password Compromised

Note in Figure 10 that the user was admin and the password 123456. I made the password simple to guess to ensure that some percentage of attackers would be successful. This tactic can be reflected in the real world by creating a difficult password (or, better, two-factor authentication) and watching the deception net logs for efforts to guess the password. In that case, you might see something such as Figure 11.

Figure 11 - Deception Net Log Failed LoginFigure 11 - Deception Net Log Showing a Failed Login Attempt

This is important because there are adversaries—for example, China—that constantly are performing automated SSH scans. These rarely attempt to compromise the password.

In this example, the adversary is from Germany and was persistent in attempting a compromise. Our deception net allows us to track the activities of a particular actor as in Figure 12. The figure shows only the first few attempts as an example due to space limitations, but the entire log shows a pattern of behavior that will allow you to block or sinkhole the offending adversary. It also, in more complicated attacks, allows forensics on the device itself. We limited that in our example to a look at the syslog.

Figure 12 - Tracking Actor Deception NetFigure 12 - Tracking an Actor in the Deception Net

That's enough for this post. Next time, we'll dig more deeply into the forensics as we track external attacks against our deception network. We'll enlist the aid of some other tools, such as the AlienVault tool we touched on this time.

One more thing to mention. Stay tuned for the launch of my new podcast, "AI & Security: The Next Generation." Details coming soon.

Editor's Note: Dr. Stephenson has been on medical leave since his last post (not coronavirus). All is now well, and he's back in the saddle.

Comments