I'm a huge proponent of triage incident response. So much so that I developed procedures based on the idea that gathering a little information from key data points early can lead to an accurate assessment of the situation without having to conduct laborious processes such as creating a full disk image all the time. Triage saves time and effort. The purpose of triage is not to conduct a full analysis. The purpose is to 1) sort and prioritize and 2) gather enough information to decide whether or not to continue an investigation. It also maximizes the effectiveness of analyst, systems, and tools. Tools like F-response make triage possible. Tools like Responder Pro from HBgary make triage possible. Speaking of Responder pro..
I recently upgraded my copy of Responder 1.5 to Responder 2. I've got some great things to say about this product but I'll save that for another post. I ran an analysis some time ago in 1.5 against a dangerous little piece of malware that got quite a bit of press in 2008. The malware in question is Trojan.Agent.BTZ. This little gem is what ransacked the military and pentagon. Vendors like to call it Autorun malware, as that's really how it works but it's of course more than what a vendor will tell you.
Generally speaking I was looking for a piece of malware that infects removable media, phones home, gives remote control and downloads other malware. I arrived on scene a short while after the alert and after talking to the admin, decided to plug in my USB key, knowing full well what would probably happen to it. USB key defenses aside, I ran FastDump Pro and grabbed an .hpak memory dump.
So now I had a memory dump and I grabbed a disk image from the computer. In this case I decided to take the drive because I would use this later in a lab scenario for training. Triage requirements aside, this was a good case to capture for later use.
Let's analyze it quickly with 2.0 eh?
*note I've already done this in 1.5 I'm just re-doing it in 2.0 and during the middle of this I experienced a licensing hiccup*
My standard technique for beginning memory analysis in Responder is as follows:
1) Evaluate DDNA listing.
DDNA while not perfect, can be used to quickly hone in on oddities and badness. It helps identify WHAT is on the box, WHAT it might be, and HOW it might be working. Add a cross reference listing to the modules running on the box for more detailed information. DDNA is a boon to any analyst looking to conduct rapid analysis.
Here's what the DDNA output looked like for BTZ. Focusing on the left hand side, we don't see a whole lot that sticks out. A sea of Orange really...
2) Evaluate Network connections. This helps me answer two questions. WHAT is talking, and to WHOM? I tend to go for Network connections before Processes as network connections often identify the process I need to investigate. For all intensive purposes, 2&3 are interchangeable.
3) Evaluate Process lists.
Typically I evaluate processes in a number of ways. I'll look for processes that don't belong, those with odd names, those that are 'hidden', all svchost processes since they are a huge target for process and dll injection attacks, those processes that are "red flags" such as ones executing from the wrong directory or with incorrect paths and processes that don't normally exist.
4) Open file handles and Registry keys.
This should be fairly obvious as to the why. It allows me to find out what process has what file handles and reg keys open.
5) Use a DNS blacklist or keyword list. There are great blacklists out there plus I have a few extras. This immediately helps with data reduction in some cases. It can also assist in zeroing in on the malware. This is great for casting a drag net on a network to look for other infections.
6) Other poking - looking for clues that might tip me off to the true nature of the infection or compromise.
This usually does the trick for the overwhelming majority of malware cases I look at. Granted there are more difficult ones but with malware being as templated as it is..this tends to work.
So now let's work through this for real...
DDNA in this case didn't appear to be helpful, or was it? Looking at the listing, there's a wide variety of suspicious looking processes and modules. That's not really that helpful by all appearances. Let's add a little intelligence to this analysis by pulling up the module listing next to the DDNA listing for processes. This is what that looks like:
So, now we have even more orange...GREAT you might be thinking sarcastically..but what do we see if we look closely? Like a simple equation we can rule out common processes and modules that we have a possible explanation for now and I've highlighted something that looks REALLY suspicious..a process loading a module out of the user's profile. As I said DDNA is not perfect, but what it does is raise the interesting stuff to the top by severity and color coding. This is automated analysis and while it has limits, when we add human intelligence to the analysis process we get an immediate bead on the target.
So what are the key indicators?
* The .dll
* rundll32.exe is calling a .dll out of the user profile
* The file path for the .dll.
Yeah that's pretty odd isn't it? What traits does it have?
Nothing sticks out a whole lot, but there are some good clues in there.
So now I've found something odd and definitely worth looking in to a bit further. This happens to be the jackpot but let's keep evaluating.
How about the DNS blacklist for connections to known bad domains?
The list of hits was far too many to show here. The matches numbered upwards of 336 bad domains. That's too many domains to be helpful but it's definitely a sign that the computer was talking to a lot of known bad actors.
And Network Connections?
The network cable in this incident was unplugged when I arrived. No joy for active connections.
And the process listing?
There's one above the rest that sticks out:
C:\WINDOWS\system32\rundll32.exe" "C:\Documents and Settings\ctuser\Application Data\HELP\system32\rtn.dll"
That just about settles it for me. rtn.dll does not belong. Let's go ahead and process it. I always start by right clicking and taking a look at the strings. This allows me to drill right in to what I am interested in.
Immediate strings of interest:
C:\DOCUME~1\ctuser\LOCALS~1\Temp
C:\DOCUME~1\ctuser\LOCALS~1\Temp
C:\DOCUME~1\ctuser\LOCALS~1\Temp\
C:\DOCUME~1\ctuser\LOCALS~1\Temp\~DFD.tmp
C:\Documents and Settings\ctuser\Application Data\Help
C:\Documents and Settings\ctuser\Application Data\Help
C:\Documents and Settings\ctuser\Application Data\HELP\
C:\Documents and Settings\ctuser\Application Data\HELP\\system32\
C:\Documents and Settings\ctuser\Application Data\HELP\\system32\mswmpdat.tlb
C:\Documents and Settings\ctuser\Application Data\HELP\\system32\wmcache.nld
C:\Documents and Settings\ctuser\Application Data\HELP\system32
C:\Documents and Settings\ctuser\Application Data\HELP\system32\rtn.dll
Yep, this tells us a little about the files the malware is using. Point of interest here is that the malware created a directory structure for the user the malware was run under, and one of the few directories it could write to was in the profile as the user had no elevated privileges. Many people still think that Administrator rights is a means of stopping the execution of modern malware. Those people couldn't be more wrong but I digress...
Right now we don't know what the files are are specifically but we will soon...
How about this?
1dM3uu4j7Fw4sjnbcwlDqet4F7JyuUi4m5Imnxl1pzxI6as80cbLnmz54cs5Ldn4ri3do5L6gs923HL34x2f5cvd0fk6c1a0s
My that's odd isn't it? And it's referenced in three different memory locations. So just what is that string? The following code should give you a big hint.
If you can't tell that's an XOR key and function. We can use that bit of information later when we want to do deeper analysis. As we learn from later analysis, this XOR key is used to encode data written to log files by the malware.
When I did this analysis for real I completed the analysis and decoded the log files kept by the malware, and conducted a more thorough disk based analysis. The purpose of this posting is to illustrate a quick analysis method that pays off with the extraction of the XOR key to encode log files created by malware. In all, doing it this way takes about 15 minutes to get actionable intelligence. Think about it. In a just a few minutes we've gathered:
* Filenames on a filesystem. Pass that information off to your windows admins, and they can search desktops for the files.
* The XOR key to decrypt any discovered log files
* There's more to be seen in the memory dump that allows us to create a snort signature if need be(of course one already exists at present time).
* The malware does not require administrative privileges to execute or maintain persistence.
I realize this post is a bit incomplete..hopefully I'll get back to a continuation piece.
I recently upgraded my copy of Responder 1.5 to Responder 2. I've got some great things to say about this product but I'll save that for another post. I ran an analysis some time ago in 1.5 against a dangerous little piece of malware that got quite a bit of press in 2008. The malware in question is Trojan.Agent.BTZ. This little gem is what ransacked the military and pentagon. Vendors like to call it Autorun malware, as that's really how it works but it's of course more than what a vendor will tell you.
Generally speaking I was looking for a piece of malware that infects removable media, phones home, gives remote control and downloads other malware. I arrived on scene a short while after the alert and after talking to the admin, decided to plug in my USB key, knowing full well what would probably happen to it. USB key defenses aside, I ran FastDump Pro and grabbed an .hpak memory dump.
So now I had a memory dump and I grabbed a disk image from the computer. In this case I decided to take the drive because I would use this later in a lab scenario for training. Triage requirements aside, this was a good case to capture for later use.
Let's analyze it quickly with 2.0 eh?
*note I've already done this in 1.5 I'm just re-doing it in 2.0 and during the middle of this I experienced a licensing hiccup*
My standard technique for beginning memory analysis in Responder is as follows:
1) Evaluate DDNA listing.
DDNA while not perfect, can be used to quickly hone in on oddities and badness. It helps identify WHAT is on the box, WHAT it might be, and HOW it might be working. Add a cross reference listing to the modules running on the box for more detailed information. DDNA is a boon to any analyst looking to conduct rapid analysis.
Here's what the DDNA output looked like for BTZ. Focusing on the left hand side, we don't see a whole lot that sticks out. A sea of Orange really...
2) Evaluate Network connections. This helps me answer two questions. WHAT is talking, and to WHOM? I tend to go for Network connections before Processes as network connections often identify the process I need to investigate. For all intensive purposes, 2&3 are interchangeable.
3) Evaluate Process lists.
Typically I evaluate processes in a number of ways. I'll look for processes that don't belong, those with odd names, those that are 'hidden', all svchost processes since they are a huge target for process and dll injection attacks, those processes that are "red flags" such as ones executing from the wrong directory or with incorrect paths and processes that don't normally exist.
4) Open file handles and Registry keys.
This should be fairly obvious as to the why. It allows me to find out what process has what file handles and reg keys open.
5) Use a DNS blacklist or keyword list. There are great blacklists out there plus I have a few extras. This immediately helps with data reduction in some cases. It can also assist in zeroing in on the malware. This is great for casting a drag net on a network to look for other infections.
6) Other poking - looking for clues that might tip me off to the true nature of the infection or compromise.
This usually does the trick for the overwhelming majority of malware cases I look at. Granted there are more difficult ones but with malware being as templated as it is..this tends to work.
So now let's work through this for real...
DDNA in this case didn't appear to be helpful, or was it? Looking at the listing, there's a wide variety of suspicious looking processes and modules. That's not really that helpful by all appearances. Let's add a little intelligence to this analysis by pulling up the module listing next to the DDNA listing for processes. This is what that looks like:
So, now we have even more orange...GREAT you might be thinking sarcastically..but what do we see if we look closely? Like a simple equation we can rule out common processes and modules that we have a possible explanation for now and I've highlighted something that looks REALLY suspicious..a process loading a module out of the user's profile. As I said DDNA is not perfect, but what it does is raise the interesting stuff to the top by severity and color coding. This is automated analysis and while it has limits, when we add human intelligence to the analysis process we get an immediate bead on the target.
So what are the key indicators?* The .dll
* rundll32.exe is calling a .dll out of the user profile
* The file path for the .dll.
Yeah that's pretty odd isn't it? What traits does it have?
Nothing sticks out a whole lot, but there are some good clues in there.
So now I've found something odd and definitely worth looking in to a bit further. This happens to be the jackpot but let's keep evaluating.
How about the DNS blacklist for connections to known bad domains?
The list of hits was far too many to show here. The matches numbered upwards of 336 bad domains. That's too many domains to be helpful but it's definitely a sign that the computer was talking to a lot of known bad actors.
And Network Connections?
The network cable in this incident was unplugged when I arrived. No joy for active connections.
And the process listing?
There's one above the rest that sticks out:
C:\WINDOWS\system32\rundll32.exe" "C:\Documents and Settings\ctuser\Application Data\HELP\system32\rtn.dll"
That just about settles it for me. rtn.dll does not belong. Let's go ahead and process it. I always start by right clicking and taking a look at the strings. This allows me to drill right in to what I am interested in.
Immediate strings of interest:
C:\DOCUME~1\ctuser\LOCALS~1\Temp
C:\DOCUME~1\ctuser\LOCALS~1\Temp
C:\DOCUME~1\ctuser\LOCALS~1\Temp\
C:\DOCUME~1\ctuser\LOCALS~1\Temp\~DFD.tmp
C:\Documents and Settings\ctuser\Application Data\Help
C:\Documents and Settings\ctuser\Application Data\Help
C:\Documents and Settings\ctuser\Application Data\HELP\
C:\Documents and Settings\ctuser\Application Data\HELP\\system32\
C:\Documents and Settings\ctuser\Application Data\HELP\\system32\mswmpdat.tlb
C:\Documents and Settings\ctuser\Application Data\HELP\\system32\wmcache.nld
C:\Documents and Settings\ctuser\Application Data\HELP\system32
C:\Documents and Settings\ctuser\Application Data\HELP\system32\rtn.dll
Yep, this tells us a little about the files the malware is using. Point of interest here is that the malware created a directory structure for the user the malware was run under, and one of the few directories it could write to was in the profile as the user had no elevated privileges. Many people still think that Administrator rights is a means of stopping the execution of modern malware. Those people couldn't be more wrong but I digress...
Right now we don't know what the files are are specifically but we will soon...
How about this?
1dM3uu4j7Fw4sjnbcwlDqet4F7JyuUi4m5Imnxl1pzxI6as80cbLnmz54cs5Ldn4ri3do5L6gs923HL34x2f5cvd0fk6c1a0s
My that's odd isn't it? And it's referenced in three different memory locations. So just what is that string? The following code should give you a big hint.
If you can't tell that's an XOR key and function. We can use that bit of information later when we want to do deeper analysis. As we learn from later analysis, this XOR key is used to encode data written to log files by the malware.
When I did this analysis for real I completed the analysis and decoded the log files kept by the malware, and conducted a more thorough disk based analysis. The purpose of this posting is to illustrate a quick analysis method that pays off with the extraction of the XOR key to encode log files created by malware. In all, doing it this way takes about 15 minutes to get actionable intelligence. Think about it. In a just a few minutes we've gathered:
* Filenames on a filesystem. Pass that information off to your windows admins, and they can search desktops for the files.
* The XOR key to decrypt any discovered log files
* There's more to be seen in the memory dump that allows us to create a snort signature if need be(of course one already exists at present time).
* The malware does not require administrative privileges to execute or maintain persistence.
I realize this post is a bit incomplete..hopefully I'll get back to a continuation piece.
4 comments:
Surely, HBGary Responder is a great tool for malware analysis, but you should know the fact it cannot detect DKOM attack or dead process information from RAM image.
Please read my post if interested.
http://cci.cocolog-nifty.com/blog/2010/02/hbgary-responde.html
cci,
Nice stuff. I like the volatility-> enscripts. I've experienced what you refer to as well. I can validate that it struggles with stale network connections and dead processes.
Would you be willing to share your FU sample? Is your second sample from my memory snapshot collection? Looks familiar ;)
@cci: You are using Responder 1.5 in that post. I'm not saying that is a good excuse but I've tested FU with Responder 2.0 and the hidden proc shows up as "hidden" in the process listing.
@hogly: Try using the column chooser option in the DDNA GUI. You don't have to have the modules panel up. You just choose the process ID and path columns to add to the standard DDNA view.
Hi, Phil
The result of 2.0 is the same as 1.5. interesting...
Post a Comment