Detecting Malware Through Process Chain Analysis
Recording of the webinar right away! The webinar is recorded from here so if you lose your internet connection or need to step away from your keyboard, don’t worry we will send the recording out once the webinar is finished.
I’m Benoit Hamelin, CTO at Arcadia and I’m standing in for Justin Seitz today. Basically the point and the goal of this webinar is to discuss process chains and how we can use them in order to detect malware so that we can respond to data breaches in good time. Let’s start with a short introduction to what I mean by process chains. It’s no secret to most users of modern computers, oh but I’m getting ahead of myself, maybe just a little plan for the meeting today and so my intent is basically to be chattering away like this for about 20 minutes and then will have a 10 minute and more time allocated for questions and answers. I will also be available for a half an hour past the beginning of the webinar, this means I will be available up until 2 pm EDT, and therefore just a bit of chatter on my end, just a bit of courses and then you drive the show by asking the questions.
I was talking about process chains and I was saying that basically it’s no secret to anybody familiar with the usage of computers or servers that programs are started by other programs. In a more technical parlance, processes are started by other processes and this who starts whom relationship is basically the note that in terms of parent-child relationships. There is an ancestral relationship between processes and walking on these ancestral links we can identify process chains basically built by a process related to all its parent processes down to the initial user mode process started by the kernel when the machine boots.
What is this with process change that can help us fight malware? When you run a computer you’re using a workstation of your own or you’re running a server that deploys a certain application or set of applications, the programs are generally started in rather regular patterns. If you take a look at process chains on a certain machine you can identify common process chains. So what happens when this machine is infiltrated? Malware will try to leverage the spawning of or forking of new processes. Why would it do that? Well, often your user mode processes will be running into certain sandboxes, so by exiting to another process malware can exit the sandbox. It will also do that in order to elevate its own privileges by pushing a computation unto privilege process. It can also use that in order to bootstrap code injection or just to run its malware activity away from the site of intrusion. These various activities that malware does, involve process change that do not follow the typical pattern on the host. It generates what we could consider anomalous process chains. This begets a detection heuristic stated by whenever we detect anomalous process chains we should be investigating the machine.
In order to make sense of this principle let us look at two cases of anomalous process chains that I have set up on this demo account on SNOWboard.
The first case concerns a Windows machine where we can we can see that malware has typical process chain patterns all its own and that is quite distinct from legitimate processing chain patterns. Here, let me open the investigation and now that I think about it I had it open here in full screen tab.
When we think about malware and the way it can show itself in terms of process chains, what do we think about? One of the very typical process chain patterns that malware does is the so-called drop execute pattern, by which a certain piece of malware will intrude through say a browser or PDF reader and the shellcode will contact in-situ server get a binary and write this binary to file just to execute it right away. This is the drop execute pattern.
Another thing that it can do is to infiltrate a common program, then just spawn out of it by injecting a certain piece of code or by spawning an interpreted program through a shell of some sort. Very typical examples are once again the web browser, acrobat reader, Macromedia flash or the dreaded Microsoft Office macros. In principle, generally, these guys these very common workstation programs they are not supposed to be spawning shells. They’re not supposed to shell out.
Let’s take a look at this investigation here. A single lead has been generated for this investigation for this Windows machine that I control basically. So what happens on it, well the summary is that in a sense when Word.exe has a child process three generations over of WSCRIPT.exe. W.script exe as you may recall, is a JavaScript interpreter that lives in the windows system 32 directory.
Let us go over the details. In essence the root program of this process chains is a Microsoft Word, the WINWord.exe executable. When Word has a parent but we don’t really care about it, we care more about its children processes. Its first step child is something called AppData\Roaming\Microsoft\Word\MSword.exe.
This is something that spells out like a Microsoft Word executable, but that has been deployed in the user Foobar\AppData\Roaming directory. That does not look good at all. If we dig further, this MSWord.exe program has itself spawned a child process and that child process is the WScript.exe windows script host binary and we even see from the command line that it’s running a JavaScript process also deployed into the appdata roaming directory of the Foobar user. This is where things get really bizarre, it does that from the Xeyqyn directory and the name of the script is fuarh.js. I don’t know about you guys, but I know a few foreign languages and I’m pretty damn sure that seeking is not anything foreign at all. If anything, it’s probably the result of generating a random directory name.
Same thing with the fuarh.js word. So very likely the javascript file has been written there in a randomly generated directory in the AppData\Roaming directory of user Foobar. Now random directories and file names are common in the temporary directory on Windows, but not quite that common on C:\users\Foobar\AppData especially if it’s been started by this weird MSWord.exe binary that’s also been deployed into C:\users\Foobar\AppData. To me this smells really really bad. So, how do I go about investigating? If we are running a JavaScript file and where Microsoft Word is not supposed to be running a JavaScript file it should be interesting to just go grab this javascript file and see what’s in it. The first thing that we should do is open the command, actually we don’t do it that way, rather we select this and indicate that we want to get this file in this host.
This takes a short while because this machine is not in constant contact with my interface, it beacons only at randomized regular intervals so this would take a little time if I were to send the command but as an all great cooking show, I already have done it beforehand and what I got from it is I actually got the file in the previous execution of this piece of malware and I got it from there. I’m then able to download this JavaScript file and try to reverse-engineer its purpose.
I could also do the same so if we go back to analyzing the lead, we saw that there were two levels of weird processes going on here. The first one spawned by WINWORD.exe and another one called MSWord.exe, I would also want to download it. In addition, if there is a smell a strong smell as it happens here of malware being deployed on this machine. I would get a full snapshot of everything that happens on this machine. How do I do that? I go to commands and I use the update info command, I just type in the investigation and host ID here, so the investigation is 677, the host ID is this, and then apply and the result is as we saw here, a bunch of fresh information about what’s going on on this machine.
So I get a full snapshot of all processes running on the machine, refreshed host information, list of services, list of drivers, and what kind of tickles me right now, a list of autoruns.
I’m not a big windows expert here, but what I can tell you is that every other autorun key on this machine is about stuff deployed on C:\windows\something\something except this one here which is also deployed into the AppData subdirectory for user Foobar. This again smells bad especially given that it’s something that calls itself as svchost update, I’m pretty sure that Microsoft whenever it updates its svchost will not go through the AppData local of some user. I would likely grab this as well and reverse-engineer it and find that this is actually a stage 0 component for the turla malware. If I go and take a look at these guys, I see here okay something about VMware, something about our ISO, Userinit, that’s smells good, stuff in when logon shell, isolated commands, yada yada yada, very common stuff, alternate shell, this is probably something legit.
In order to analyze these autorun dumps more quickly, we’re also working on a way of computing a diff of autorun snapshots between a previous version which presumably would have happened before the malware deployed itself and this version and this diff would likely show me this one entry added and would also tell me an idea of the time frame at a which when this new autorun has been added. That completes my investigation of the first case.
We saw that certain, not certain, but malware in general especially on Windows have a very common process chains of their own and so singling out those process chains help in detecting the threat.
The second case I wanted to go over, and I see that I will over spend my time, so please feel free to tell me to shut up if you really want to ask questions right now. The second case is about the fact that often especially on unix and linux systems, malware forks a new process in order to elevate its privileges. So here we’re confronted with a much simpler example. On unix there is such a thing that we called setuid programs. So what do they eat in winter? Typically when you run a program on unix or on linux this program runs with the privileges of the user that starts it. If I run an editor program this program runs at benoit hamelin with my limited privileges, but setuid program accepted this move instead of starting with the privileges of the invoker of the program, they start with the privileges of the owner of the program files and since most program files are owned by root on any given unix system, setuid programs owned by root will effectively start with root privileges even though they are not started by the root uses. This means that when these programs start they provide a free privileged elevation to the user that starts. In general it’s very well known that setuid programs are a huge security hole because many of these programs are more complex than the analyst or programmers will bother to remark and from this complexity they can be exploited to run arbitrary computations with root privileges. In order to make sense of what happens with this setuid program, let’s take a look at this investigation now.
What I see here, let’s close those keys, we see that I have a parent process – a simple bash script that I was running on there and what did I do there, I just type the name of setuid program. Now project yourself as a hunter who just got an alert of this type to investigate. So it’s not me, it’s somebody that says okay, this user they’re called hamelin has been running this program here and this program has user ID 0, whereas its parent has user ID 1000.
If we take a look at usernames 1000 means that this user named hamelin was doing something and all of a sudden his computation runs as root. There’s two possibilities here, first possibility is that this guy is running a privilege elevation exploit. I would want to check out the content of this test privilege program.
The other possibility is that he’s running a setuid program. The first thing I will do here is simply go check the rights with which this file has been done and for that I sent a simple ls-la command. We see from here that yes, this file belongs to root and yes, from this little S here by the RW we see that it’s a setuid program.
This is a program that could be used against the owner of the work station or against the owner of the machine in order to elevate privileges if it can be exploited. Two things I want to do here first is I get a copy of this file to go and audit in order to you know if I can find an exploit for it myself. If that’s so, I will sound the alarm to IT that they have to take it out right away. In any case, I will go and warn IT of this security hole and suggest a better approach for providing elevated privileges when running this program just to certain users or under certain circumstances by using things like the pseudo program or something else like this. That also concludes the study of this second case.
In conclusion before I start taking questions, I want to do point out again that the typical usage of computers will result in common process chain patterns. Your malware will tend to generate off pattern process chains and we must look for these. What do these things look like? They will look like a typical parent processing like in our MSWord example. They will look like for instance, signed processes that spawned unsigned programs. We did not see an example about this. Another thing we can see is child processes having higher privileges than their parents processes. This is also something that should raise your attention, you should investigate as soon as you can. Right now we’re also working on an artificial intelligence engine to identify the most common process chains on all machines that we monitor and eventually being able to detect anomalous process chains more generally than we do already.
All right, thank you and on this I will start taking your questions.
