Security Show

VECTOR 2 !! The Security Show, Coming Soon to Novi Michigan!!!

Stay Tuned!

Mentoring SANS Classes!!

Hey I wanted to let eveyone know I am going to be Mentoring a couple of SANS classes here in the Metro Detroit area in the near future.

504 Hacker Techniques, Exploits and Incident Response April - June

508 Computer Forensics, Investigation, and Response August - October

Check them out!! If you ever wanted a SANS course close to home without all the travel expense...

504 class: http://www.sans.org/mentor/details.php?nid=21248

508 class: http://www.sans.org/mentor/details.php?nid=21249

If you are interested or have any questions please contact me!! I am also available to give brief demonstrations of the class!

Please feel free to pass this info on to everyone!!

Also feel free to contact me directly about the course either email here at the blog or call me

Mark Bennett
248-767-6342

Finding Malicious Code in Memory

Today I'm going to expand on Mark's recent article regarding memory analysis. I would like to show how one can gain insight into an unknown piece of malware just by analyzing memory artifacts. The tools I will be using for this will be mdd (for memory acquisition) and Volatility (for memory analysis).

The piece of malware we will be examining is still unknown, but by the end of this article we should have a positive id.

The first thing we want to consider before we lay any fingers on the keyboard is the volatility (not to be confused with our tool Volatility) of the evidence in question. We want to ensure that we capture this evidence in the order of most volatile first.

We start with capturing a memory image of the suspected machine. We should have on hand a cd with our tools. We can then run these tools directly from cd instead of copying the tools to the hard drive and possibly overwriting evidence. The command we will use to capture the memory is quite simple:

mdd.exe -o output-dir\image-name

If possible we will want to avoid writing this image file to the local drive for the same reasons stated above. We have a couple of options. We can write the file to a usb device such as a thumb drive (new files will be written when thumb drive is plugged in). We can also write the image file across the network to a share.

After we capture our memory image we will want to capture our other volatile information such as active network connections and a list of running processes.

We will use the command 'netstat -nao' to view the network connections. The 'o' flag will allow us to view the process id that is associated with the connection.

We will use pslist from sysinternals to acquire a list of running processes.

Now that we have collected our most volatile information we will begin the analysis of our memory image. The remainder of this post will be run from our analysis machine.

I typically will look at the active network connections and processes that are running that have been found in memory. I then can compare this against what was found from the operating system perspective (netstat and pslist).

Using the tool Volatility we can peer into what is actually happening.

As you can see, there is one odd connection established on port 31337 that wasn't listed in our netstat output. We are also able to determine a process id of the strange connection. We will want to pay particular attention to PID 1604.

Looking at our processes we can now see that we have a netcat process that is responsible for the odd connection. We can also see that we have another process that is not listed when compared to our original process list. This is process id 284.

Lets look at this process a little closer to see if we can gain any additional information. I will use memdmp in order to create a binary image of this particular process.

After running the command we have a new file called 284.dmp. We will now search the file for any ascii strings.

Just looking at the first line of output we can determine that this is not something we want on our machine.

Looking further into our apparent rootkit we find what looks like configuration information as well as the driver file name. It looks like we can also id our malware as the HackerDefender rootkit. If we needed to confirm our findings we could dump this process to an executable file and submit it to a site like virustotal.com.

Keep in mind that when attempting to find malicious code within memory it may not always be as straight forward as what we have just looked at. I will say that using just these initial steps I have shown, you will have a much greater chance of finding that elusive piece of malware.

Please post any questions you may have in the comments section.

Applying Criticality to Security Incidents

A few years ago I was asked to come up with a way to rate and prioritize security incidents into 3 different categories. These categories would define not only how we would respond to various incidents, but also how we would report them to management. After some thought I decided on using a scoring system. This would provide the ability to base a priority on several different factors as well as take the human element out of the rating process.



As you can see. I am first applying an initial score based on direction of traffic. All other scores are based on a combination of activity and network location. I am defining Critical Infrastructure as anything that routes or applies security controls to network traffic.

I will admit that this system is not perfect. There have been times that the score didn't seem to accurately represent the true criticality of the incident. For the most part though, I feel this scoring system has worked well for us.

I am interested in what others are doing in this area. If you have an opinion on this subject or would like to share your methods, please do so. You can use the comment link below.

Memory Analysis

What am I talking about? I am talking about RAM!

Here are some of the things we can get from RAM, processes, network connections, open files, Encryption Keys – Bitlocker.

The last one Encryption keys from Bitlocker is an awesome presentation I read from Jesse Kornblum on how to get the keys for bitlocker, check it out: http://jessekornblum.com/presentations/omfw08.pdf

There are simply some great tools to get memory, You can use win32dd.exe. This tool will create a raw image file as well as write a MD5 hash of the output file you create.

My personal favorite though is Memoryze from Mandiant. You can find it here as a free download http://www.mandiant.com The cool thing about memoryze is that you can run enumeration tools to give you process information, the registry keys that are being used by the process, what DLL's are running, drivers loaded in memory, etc... The great thing about this is that you can do that on an image that it can enumerate from or on a live machine.

Here is how it works:

Open a command shell (cmd.exe) Change directories to where you installed Memoryze.

Type “MemoryDD.bat” It will create a directory called audits where it will put your memory image or

To write the image to a specific directory, type “MemoryDD.bat –output <directory_name>

To identify all open ports and their processes and Process Id's, type “Process.bat –ports true"

The output is put in xml format:

Notice above you can see the process forcefield.exe as process ID 900 it is making a connection out to IP address 68.142.101.68 on Port 80 This is simply a great way to tell what process is doing what. (ie…malware outbound connections)

Now suppose you wanted to look for rootkit's in Memory. You can use Mandiant's HookDetection.bat file. This executes RootkitAudit.Batch.xml. It identifies hooks in kernel memory often used to subvert the integrity of the system.  So you can see below the different processes and how the relate to the kernel or drivers etc…

Notice above you can see the module that has hooks into the kernel i.e 1394BUS.sys where it is located: \windows\system32\drivers\ and a description of it: “Driver”

If you had an unknown process  with hooks into the kernel you could find it here.

Now these are all great tools but, what do you do with a memory image after you have it? There are some basic techniques that you can use to do analysis.  I would start with a “strings” command.  So you can run strings memory.img > memory.str. Then you can begin to parse the file for emails, websites surfed to, or connected to by malware, passwords, blogged text, and unknown executables.

Once you have your image, you might choose to use a tool called Volatility. This tool simply ROCKS!

Here is how it works using Linux:

python volatility command –f /path_to_windows_memory_image

The keyword command refers to a series of commands that you can choose from. Here is a list:

So what can we do with this? Let me show you. First let’s see what processes are running in memory.

first I type the command:

python volatility pslist –f /path_to_image/imagefile.img

and I will see output like this:

Now you can see the executables running. You can also see from the second column what the PID (Process ID) is. So let’s say we did not know what jusched.exe was. (PID 2228) and we thought it might be malware and would like to send it to virus total. Well then, let’s grab it right out of the memory.

python volatility procdump –p 2228 –f /path_to_image/imagefile.img

Now we have carved that process out. However to be sure we did this correctly let’s take a look at what it is using khexedit. Since this is suppose to be an .exe file it should start off in hex with MZ

so in linux khexedit executable.2228.exe

We can see that it is in fact what we are looking for so we could now send this up to virus total, or look deeper into the file to see what it does.

Well that is it for memory on this post. As always be good, be safe, hack legally, responsibly, and share the knowledge -–I’m Out

Hacking 101

I woke up this morning feeling a little under the weather so I decided it would be best for me (and my co-workers) that I stay home from work today. After laying on the couch and watching Sponge Bob with my youngest daughter for a few hours I decided that my time could be much better spent doing anything but watching Krabby Patties being flipped at the Krusty Krab.

After pondering all of the different things I could do I finally decided to break out my laptop to see what (if anything) had happend with my honeypots since the night before. I saw the normal ssh scans hitting my linux honeypot. I also observed the normal vnc connection attempts against a windows honeypot I have. I then see the ip address of the hacker, which I will now refer to as Duh, log into my linux honeypot via an ssh connection.

I have been observing Duh for about 2 weeks now. It usually goes something like this:
1. He logs into the honeypot.
2. Downloads and installs misconfigured tools.
3. Leaves traces of his activities.
3. Honeypot then attempts to spew crap out to the internet due to misconfiguration.
4. I reset honeypot.
5. Cycle starts all over again.

Here are the issues I have with Duh.
1. If you're gonna hack a box, at least know the tools and the reason you're installing them.
- Duh installed a rootkit, then changed the root password on the box. Duh!
- Duh installed a trojan'd version of ssh which logs password changes, then changed all of the passwords to prevent others from logging in. Duh!
- Duh installed an ssh backdoor on a port that is blocked by my firewall. Duh!

2. If you want to hide your activities, practice before you go live with it.
- Duh tried to remove his activities from the .bash_history file by editing the file and removing any entries. He then typed exit to close his ssh session which then wrote all of his activities to the .bash_history file. Duh!
- Duh continues to drop the same tools in the same directories even after they obviously have been deleted by someone other than him. Duh!
- Duh still hasn't realized that after 2 weeks of re-hacking the same box that someone may be on to him. Duh!

3. If you want to install tools then make sure your tool will work.
- Duh continues to install a bot, but then gets G-Lined (banned) from Undernet for too many connection attempts
- Duh has scanned millions of ip addresses for ssh password attacks before verifying that he can actually ssh from the honeypot (he can't). Duh!

Thats all I have for now. Thanks for listening while I vent.