Threat hunting with next-generation tools

We've covered two AI-based next generation tools: deception networks and network monitoring.  This time we're going to use next generation enterprise forensics to go on a threat hunt. If you recall, we deployed an Attivo BOTSink deception network in the lab and added, last time, the MixMode Packetsled network monitor.  Both of these use true artificial intelligence with machine learning and deep learning. We have beaten the definition horse to death but in case you didn't pick up on it I discussed artificial intelligence in the last two parts of this four-part series.

The tool I'll introduce this time is a dream tool for anyone who has suffered through the tedium of forensic analysis on a dozen or so computers in a digital forensics incident response. In my experience it can take hours to image a single hard drive, a day or more to ingest it into the digital forensic tool and days to weeks to analyze it.  And that is just one disk.  If you have a dozen possibly compromised computers, multiply that by twelve and then add days or weeks to tie all of the analyses together.  You may have a different process (for example, ingest all twelve disks and analyze them together in the first pass) but whatever you use it is very time consuming. 

Moreover, this is dead box forensics.  At best you'll maybe get a memory snapshot but if you are looking at an event that took places days or even months in the past your memory snapshots are going to be limited in what they see. The tool I'm going to introduce will let you cut that analysis time dramatically. In fact, I've used it to do a full analysis of 1,400 computers on the network and get live rather than dead box forensics in just a couple of hours. The tool I'm talking about is Infocyte HUNT.  I have been using it in my lab and at a client for quite some time.  It cuts analysis time dramatically and it finds things that I might have missed.

Let's Set up the Problem

For our threat hunt we are going to respond to a suspected banking Trojan.  We don't know what it is (actually, in this case we do since I loaded it for this problem - so in this test we'll meet Citadel - but for now let's assume that we don't know what's troubling us), where it is or even if it is. But we have noticed the network acting a bit hinky. A hint, here… HUNT performs scans of the network and you can schedule daily scans as I do with a client.  You can see a daily analysis report and you can receive an email alert if there is anything found in the current scan.  So this becomes an alerting tool as well as a threat hunting tool. In our case, I was not running regular scans because I set this problem up specifically for this article.

The other thing to note is that HUNT works, in part, by seeing what artifacts have been left by a piece of malware or a manual/programmed attack.  It does not do a static analysis of every file leaving you to figure out what, exactly, happened.  HUNT checks the shim cache and tells you assuming that a file that never has executed is not a problem. However, if such a file has been placed on the computer in a non-standard manner - a dropper, for example - it will notice that.  Also, there is a very cool function, added recently, called Activity.  Activity lets you look at a suspicious event, artifact, connection or user activity and see every step involved with it since it first interacted with the computer.  More on that later.

This is beginning to sound like a product review so let's get on with our problem.  I'll explain other features as we meet them. To create the problem, I set up some of the virtual machines  in my Malware Analysis Environment (MAE).  MAE is isolated from the rest of my network, runs its virtual machines in a VMWare environment and is not part of the deception network.  HUNT cannot analyze the deception network because the deception network sinkholes anything it doesn't like and HUNT's agent is something it doesn't like because its behavior feels to HUNT like malware.  So it sinkholes all of the responses from the agent back out to the Infocyte cloud and we never see them.  But that's ok because BOTSink provides its own forensics so HUNT's would be duplicated effort and needless traffic.

On one of our VMs I fired a copy of a file with the Citadel Trojan on it. Then I ran the scan of the machines in our test environment.  I did not set up many machines just to keep things easy to see. Figure 1 shows the machines.

We have seven computers consisting of two Centos Linux computers, one Ubuntu 15.10 computer, one Windows 10 Pro, two Windows 7 SP1 and one Windows Server 2008 R2 Datacenter server. You'll note, I'm sure, that HUNT thinks that the Windows 10, The Server2008 and both Windows 7 machines are compromised. That pretty well confirms that our theory that something is not as it should be is potentially correct.  It also means that if we were to analyze this manually we would have four disks to look at, once we tracked them down which could take a while, and there might or might not be something on any or all of them. Our memory capture may or may not bear fruit as well.

You'll also notice on the left-hand menu that in addition to the four compromised computers, we have three artifacts and two instances of a memory problem shown in red.  Our first step in the threat hunt is done.  We now know that we have four computers that may have problems, three artifacts and two memory activities that look interesting. Now, we dig in.  I should note (so I will) that you may not have the advantage of having HUNT available but the process - though quite a bit more tedious - is the same if you do this manually.  You just need more tools and more time.

Now, the Hunt

I'll begin by opening the first computer, the Windows 10 Pro machine.  Looking under Artifacts (we checked memory and found nothing so this is not a machine with an interesting memory dump) we see that this computer ran bittorrent.exe on 6 Aug 2016 at 1:02 PM.  It shows up as bad. See Figure 2.

Let's look at that and see why HUNT thinks that is a problem. Clicking on the artifact we open the analysis page and we see that it is showing bad because four anti-malware programs think it is. It still may or may not be bad.  It could, of course just be considered an unwanted application (two of the four AV results tagged it thus) or it might be infected. Figure 3 shows the analysis page for the artifact.

We could, if we wished, download a sample and send it to a sandbox such as our favorite, JoeSecurity, but in this case we'll just open the Activity and see what happened with this application.  You can see that I created it on 6/19/2016 and modified it on 8/6/2016.  That makes sense in my recollection so we won't pay any more attention to it.  Since there is no indication that I did a bit torrent download of something malicious (I didn't - I was fiddling with bitcoin analysis at the time) We'll move on the next one.  The Activity page is shown in Figure 4.

Returning to our Hosts page, we'll look at the next computer, the Server2008 machine. Again, we see no memory activity so we go to the artifacts and see one called rdrservicesupdater2_1901020091.exe. I don't know what that is but, as you can see from the Artifacts analysis in Figure 5, three AV programs don't like it and two of the think it's a Trojan. See Figure 5.

Now I have a couple of choices.  First, I can submit it to either Virus Total, Google or both.  Or I can download it and send it to JoeSandbox or, if I wish, to Infocyte for further analysis. I'll take the path of least resistance for now and check Virus Total.  It tells me that only one engine detected the file (a zero-day or a false positive, more likely a false positive) and it says that this is the Adobe Web Installer.  The SHA-1 hash in Virus Total matches the one HUNT found so I'm pretty sure that we're OK but let's look at the Activity just to be certain. Activity says that I created (installed, in this case) on 2/26/2019 and modified it at 2/26/2019 both at 3:53:02 AM.  I think that we are safe on this one so we move to the first Win 7 Pro SP1 ("Win7sp1-master").

As is my habit, I check memory first and I find a treasure trove of data. The first thing I notice is a file called abatu.exe.  When I Google it I find no information.  That may make sense since many malwares rename their files randomly. Checking the Artifacts, all I found was the Cylance agent - my AV program - which I had to disable before I could run this problem. Figure 6 shows a partial memory dump.  There are over a hundred lines in total but I probably won't need to examine everything.  I do note, however, that abatu.exe executed because it has a process ID (PID) assigned by the operating system.

Well, I want to know more about this.  Next step is to look at the victim and see if the file is where it is supposed to be (in c:userspstephenappdateroamingazov) and it is.  Great! I'll upload it to Virus Total and see what I get.  Perhaps, if it's interesting enough I'll send it to JoeSandbox as well for a more complete analysis but for now it's VT. The result is pretty conclusive: we have a problem.  VT tells us 49 of 67 engines detected the file. There is no consensus but it may be a Trojan, a back door or an injector. None of those is particularly good.  A partial VT result is shown in Figure 7.

Next, let's look at the Activity for this machine. At 2:11:08 PM you see that I executed the cmd command. At exactly that time you can see that the abatu.exe file was executed by me. That is because I executed the malware and it fired immediately. So we see that.  At that point I stopped any activity so the malware would not spread. The events after that time have to do with the Infocyte agent's behavior.  We have a lot of possibilities for this malware as indicated by the VT scan.

Because we don't really know what, if anything, it has done since I triggered it, we're going to send it to JoeSandbox Cloud for deeper analysis. The nice thing about Joe is that it does a full revering on the malware. That includes both static and dynamic.  It presents the results in a way that facilitates further analysis by security engineers without requiring the more tedious task of reverse engineering.  In this case we are going to look for embedded strings and any attempts to access the Internet.

First, we see that Joe regards the sample as malicious with 99% confidence, and classifies it as an evader, a Trojan and a banker.  See Figure 8.

Reading down the report we see that Joe identified ZeusVM e-Banking Trojan. Doing a bit of research we find that the Zeus v2 that leaked into the underground in 2011 was subsequently used in other similar malware families such as Citadel.  This explains our results since we know that I infected the target with Citadel. In fact, Citadel is considered one of the primary forks of Zeus. No matter, though… we identified our problem and we see that no successful effort to download a dropper or exfiltrate data was made. 

Additionally, Joe has the Mitre Attack Matrix. It gives us a lot of very useful information such as the malware can encrypt and exfiltrate data, it can discover accounts and it can perform process injection.  As well, Joe gives us a list of similar samples that the tool has reverse engineered and we see quite a lot with different names reinforcing our speculation that the malware has generated a random filename for the malware executable. There are lots of strings but for our purposes now nothing jumped out at me. For now, then, I don't need any of that but it is there if I want it later to understand the malware's behavior better.

Now, we can remove the malware and get on with life.  The entire analysis took less than an hour rather than the more tedious methods which could take days to weeks since we have no idea without a tool such as HUNT how many - if any - other machines were infected or to where the malware might have spread.

Oh, and returning to the last of our machines designated by HUNT as compromised, we find that other Windows 7 VM - MAEConsole - was positive for nmap. nmap was not signed - that costs it on the HUNT scoreboard and three AV programs consider it malicious.  That is not an uncommon false positive for that tool but just to be sure I did some quick testing and all is well.

In this episode we went on a threat hunt using one of my favorite workhorse tools, Infocyte HUNT. As I said earlier, you can use the same process without HUNT… it just takes longer and needs more tools. 

Next time we'll apply all of our next gen tools and add the dimension of threat intelligence to complete our AI-based security stack. I'll be pulling the pieces together for the full Monte of alerting, analysis, DFIR and hunting in a compact next generation tool kit. Join me, won't you?