Beefing Up Your Next Generation Security Tool Set

In my last article I introduced you to deception networks.  This is a next generation tool that lets you alert on potential malicious activity while protecting your enterprise and capturing forensic evidence at the same time.  Over the course of four articles I'm going to help you deploy a next generation - true AI and machine learning - security stack that will let you do three really nice things. Remember that the specific tools I am using as examples may not be the only ones available.  They simply are the staples in my lab and I have up to three years (depending upon the tool) working with them. Focus as much (or more if you wish) on the functionality as you do the specific tool.

First, the total cost of the tool set I am recommending will be less in many cases than a much larger set of tools of the type upon which we've learned over the years to depend. The story here is that you can spend more money but you likely won't do the job any better or, in some cases, as well.

Second - and this is very important in today's environment of not enough security specialists - once you're up and running with these tools, their care and feeding is almost nil.  These tools - especially the  deception network from last time and the one we're about to discuss - learn and configure themselves on the fly so you don't have to. They also minimize false positives, the bane of most SOC engineers' existence.

Last, as I mentioned last time we are rapidly approaching a time when humans cannot react fast enough to defend against the adversary's next generation weapons.  It takes good AI to defend against an AI attacker. These are three very good reasons to think about cyber defense in next generation terms: cost, manpower and competitive (with the adversary) power.

For this article I will introduce you to a true AI system that can work closely with your deception network.  If you haven't got a deception network yet - perhaps you depend upon a SEIM and/or next generation firewalls - this approach will be a real force multiplier for you.  Remember that term: "force multiplier".  This occurs when the pieces of your tool set work well together to give you the answers and protection you need in whatever situation in which you find yourself; the result exceeding the sum of the parts.  This is a military term and it certainly fits here; we all are fighting a cyber war and the adversary is skilled, well-funded and persistent.

Before we charge ahead with this article, let's review a term or two from the last one.  The big one is "emergence".  An entity is emergent when, by learning its environment, it can grow to address the environment and respond to environmental changes without outside intervention. We said that the next generation of malware will exhibit emergence so we must have defenses that can address that. In a real sense the emergent malware becomes part of your network.

Another issue that is critical to next generation defense is context.  That means that the defense system is constantly and continuously learning and baselining enterprise behavior. A typical SIEM, for example, usually depends upon static baselines.  If something happens outside of the baseline it considers the event anomalistic and alerts on it.  The event may be perfectly legitimate but the SIEM doesn't expect it in the context of its static baseline.  The result? False positive that your SOC team has to investigate. True AI and machine learning (there is a difference but we won't get that far into the weeds here) constantly are learning about the network's behavior and adjusting baselines accordingly.  As time passes the contextual awareness of the next generation tool continuously improves. In other words, a next generation system must be contextually aware.

Let's look at an example of the adversary side of this requirement. Imagine, for example, that a piece of next generation malware has been injected into your network. It will have some baseline tasks to perform.  It might need to learn your network's topology. It might need to learn where files are stored and what kinds of files there are.  Are the files all interesting?  Is there some subset that are of particular interest to the adversary?  What is the file naming convention if there is one? Who at the organization uses email? What is the email system and is there a naming convention for email addresses? What is the departmental and management structure of the organization? What individuals in the organization are of particular interest? Do these individuals have a consistent way of expressing themselves in email (a "must" for good phishing)?  With whom do they usually communicate? 

We could go on for a very long time coming up with criteria for the malware but the point is that it has been created to learn this baseline information and then, within that context, become an undetectable part of the network, adjusting autonomously, never needing a bot-herder and never needing instructions from a command and control server. In military terms, it has prepared the battlefield and now its job is to accomplish its predetermined mission. It will learn what it needs to as it goes along and it will use internal resources in the enterprise - "living off the land" - to accomplish that mission. Simply, it now is contextually aware. The only way to defend against it is to beat it at its own game.  That's where next generation security tools enter the picture.

Upping the Ante - We Add Packetsled to our Tool Kit

In our last article we established our deception network using the Attivo BOTSink 3200.  For this one we are adding the latest version of Packetsled, 6.0. Recently, Packetsled announced a name change to MixMode in recognition of the strong AI component in their tool.  So to avoid confusion, that is how I'll refer to the tool in this article.

MixMode 6.0 looks and feels very different from Packetsled.  For one thing, it is not nearly as visual as Packetsled's earlier versions.  My knee-jerk reaction was that the change would bother me.  Nothing could be farther from the truth.  I selected this tool as a next generation addition to my lab for its advanced learning capability and the way it moves the analyst closer to its BRO roots. BRO is a preeminent language for cyber analysis and it has been present in all Packetsled versions. Now, however, there is a nice API in MixMode that lets you do some pretty fancy dancing with detections and reporting.  For example, now we can export to a SIEM.

The marrying of MixMode and the deception network allows us to cover both the network activity - MixMode's strong point - and the device activity generated by the BOTSink.  It also provides us with a correlation point so that we can follow an event from start to finish. Figure 1 will refresh your recollection of the BOTSink layout from last time. Now, however, we have added a lot of internal decoys that you can see on Port 6. Port 5 shows two external (Internet-facing) decoys and there also is one on Port 3 which is under attack by two adversaries. Our external decoys are set up on a CentOS virtual machine within the BOTSink.

There are two use cases for the tool set I am describing: alerting and hunting.  Let's begin this time with alerting. Looking at the Indicators Dashboard in Figure 2, we see that MixMode is reporting events, some of which may be of interest.  We have two sensors set up for our MixMode deployment and they track, roughly, the deception network. Sensor CDFS Honey looks at our honeynet from the outside, showing us inbound attacks and outbound replies, and CDFS-MAE shows the internal malware analysis environment where our 10.20.10.X decoys are deployed.  This is an isolated environment that will let us analyze malware should it become useful.

If we scroll down, we see - as in Figure 3 - several specific attacks or probes against one of our external decoys.

We'll pick the first Swedish event that looks interesting because it shows as a possible Command & Control server. When we expand the MixMode log dump we see quite a bit of information. Take a look at Figure 4.

There are a couple of things of note here. First, before we dive into the log, we should note that the field names down along the left-hand side are from BRO logs.  Lest you become completely confused (assuming that you don't speak BRO) there is a great BRO log cheat sheet at https://gauss.ececs.uc.edu/Courses/c6055/pdf/bro_log_vars.pdf. It's a nice pdf so you can download it and use it to help you navigate the log dumps in MixMode.

So, first thing to note is that the attacker - the possible C&C - has an IP address of 87.241.107.62.  Sticking that into our Cisco Investigator tool (part of Cisco Umbrella) we find that the IP hosts some malware but not much else.  So we go to AlienVault OTX and find that it is a new but known malicious IP that seems to specialize in brute force telnet attacks.

Returning to our log we find that the attempt is on port 23 - telnet (id_resp_p). We also look at the conn_state and see S0.  From our BRO cheat sheet we find that S0 means "Connection attempt seen, no reply".  We infer from that a connection attempt that did not succeed. But let's be sure.  It's time to go to the BOTSink and see what it tells us. Figure 5 will help us figure that out.

Figure 6 gives us some details.

We see a couple of lines in the Description column that merit a closer look.  Bear in mind that MixMode told us that the connection did not get a reply.  When we looked at the IP in OTX we found that the contributor saw clear text passwords.  If that had been the case here we would have seen it in the BOTSink.  As you will see, we did not.  Here are two log entries from the BOTSink Description:

                        TELNET connection started ( 19/3/23@04:51:45: START: telnet pid=29195 from=87.241.107.62 )

                             Details:

                        TELNET connection ended ( 19/3/23@04:51:43: EXIT: telnet status=1 pid=28929 duration=46(sec) )

                             Details:

In both cases - as in all of the other cases in the BOTSink logs for this event - we see a start and an end but no reply from the target IP (from the MixMode logs).  We see that the attacker sat on line for 46 seconds (second connection, above) but there was no attempt to log in, hence no clear text password in either log. One inference we can make here is that this is an automated attack that did not even complete.  Most likely it was a probe, probably not explicitly directed at us but rather catching our IP in a web of automated probes across an IP range.

Tying it all Together

In this article I've added the network dimension of MixMode to our BOTSink deception network.  To be clear, both tools give us some level of both network and device information. It's true that there is some overlap.  But this is overlap, not duplication. The levels of detail do more than simply corroborate… they add depth and certainty to our analysis.  I do not believe in wholesale duplication of tools simply to achieve defense-in-depth.  That is an expensive way to go both in dollars and manpower.  However, I do believe that tools that collaborate with each other make the best defense-in-depth tool kit.

Here we have used an alerting approach.  This is what happens when the SOC operator gets to work in the morning and looks at his or her logs to see if there is anything interesting on which to follow up. Next time we will use our tools plus one more to expand our AI tool kit just a bit more. All of the tools I am using are true AI and fall clearly into the next generation category.  As I said earlier, these may or may not be the only tools of their type. They simply are the ones I have in my lab and in my personal view are among the best of their breed. But, remember: it's the functionality, not just the tool that makes the difference.

Next time: we go on a threat hunt.