Behavioral Analysis of Malware Process…the on the fly approach

In most organizations when a host goes rouge, it’s automatically rebuild/reimaged without a second thought. Although this eradicates the malware and speeds up the recovery process, there is risk of the malware spreading undetected. I like to perform a quick behavioral analysis before re-imaging the host to build detective controls to watch for more infections in my organization.

When performing an organized (i.e. in a lab) behavioral analysis I use a methodology that consists of these different phases:

Lab Preparation

Malware Execution

Observation

Results Gathering

Interpretation

Repeat as Needed

Improving and Testing Defenses

Unfortunately when doing malware analysis quickly a couple of phases must be skipped since the malware is already running. For those situations, I use a slightly different methodology consisting of these phases:

Containment

Observation

Results Gathering

Interpretation

Improving Defenses

Since the host is already infected, the containment phase is about preventing the malware from spreading. My preferred choice is to disconnect the system from the network, but disconnecting the host is not always an option. When disconnecting is not an option, I will use network isolation to permit limited services to the host, i.e. a remote access tool (RAT) from the analyst host.

With the host contained, the next phase is observation. I recommend having a notebook handy, I always use a spiral notebook, to keep notes of any observations you make. During this phase, tools such as Process Monitor, Process Explorer, Autoruns, and TCPVeiw are used to analyze the host. If possible I try to use a network sniffer, but this may not always be an option.

After running the tools for about 15 to 30 minutes, save the results for analysis. I prefer to save them in a directory, than take an MD5 or SHA1 hash of the results to make sure they are not changed in the interpretation phase. Of course the longer the tools run, the better understanding of how the malware behaves can be achieved.

The interpretation phase is about looking at the output of the tools and interpreting the results. Since there is a high probability no baseline exist, this is by far the most challenging phase. To assist with this phase it’s important to have an understanding of how the Operating System operates without infection of malware. This knowledge makes it easier to sift through the results looking for how the malware behaves so it can be detected.

Improving defenses is taking the knowledge gained in earlier phases and improving the organizations defenses. Typically these include changing ACL, writing IDS/IPS signatures, and/or making host changes in an effort to detect the malware.

When performing malware analysis on systems connected to a production extreme caution should be used. This type of analysis should be performed for the purpose of creating detective controls for this piece of malware. If preventative controls can be built as well that is even better, but remember the objective is to use this information for detection of other infections.

Interpreting Discovery Scan Results

Last time I discussed how to perform an nmap syn scan for host discovery. With the scan complete interpreting the results is the next step. Lets start by discussing the results and how to interpret them, followed by looking at the three output files and what they are can be used for.


The first line in the results shows what options the scan was run with.. One thing to note is the version appears to only be the major release, not the exact version used for the scan. Here is the first line in the filename.nmap showing what scan options were used during the scan.

# Nmap 5.00 scan initiated Sun Sep 19 11:46:59 2010 as: nmap -PN -n -sS -T 1 -p 21-23,25,80,110,143,443,3389 -oA hostdiscovery 192.168.1.0/24

After the scan options the next line shows the IP address of the online host. The following line breaks down the description of the output, the port, the state and the service. After the description line, the number of ports listed will vary based on the scan options. Here is the nmap output of two of the host on the target network:

Interesting ports on 192.168.1.150:
PORT STATE SERVICE
21/tcp closed ftp
22/tcp filtered ssh
23/tcp closed telnet
25/tcp filtered smtp
80/tcp open http
110/tcp closed pop3
143/tcp closed imap
443/tcp open https
3389/tcp closed ms-term-serv

Interesting ports on 192.168.1.151:
PORT STATE SERVICE
21/tcp closed ftp
22/tcp filtered ssh
23/tcp closed telnet
25/tcp filtered smtp
80/tcp open http
110/tcp closed pop3
143/tcp closed imap
443/tcp open https
3389/tcp closed ms-term-serv

The port field (when scanning UDP and TCP protocols) lists the port number protocol that nmap scanned.

The state field is the critical field when determining if a host is online. For nmap there are 6 possible states. The three states from most scans, including a syn scan, is open, closed, and filtered. Be aware three other states may be seen in different types of scans. Here is a brief description of each state, but please visit the nmap website for more detailed explainations.

Open – the port is actively listening and accepting connections.

Closed – the port is not actively listenting

Filtered – the port is being filtered by a packet filtering device

For this example port state let’s focus on ports tcp/22 (ssh), tcp/25 (smtp) and tcp/80 (http) on host 192.168.1.150 (TargetA), and 192.168.1.151(TargetB).

Starting with tcp/22 on TargetA the port state is filtered. So we know that there is a packet filtering device between us and the target network. TargetB tcp/22 port state is open.

Next looking at tcp/25 on TargetA and the port state is filtered. Again it appears there is some of packet filtering device between us and the target network. TargetB tcp/25 port state is closed.

Finally looking at tcp/80 on TargetA and TargetB the port state for each host is open.

It’s important to note the service listed in the scan results uses the nmap-services database to identify the service. Suring this scan no service detection was performed and the results are relying solely on the services database. Remember it’s possible to have another service running on a port on any port. For example a web server could be listening on tcp port 21 (ftp server). During the enumeration scan, version detection should be done to ensure the correct service running on a particular port is identified.

The final line of the scan provides information about the total number of online hosts and how long the scan took to complete. Here is the last line of output from the scan results:

# Nmap done at Sun Sep 19 13:57:06 2010 -- 256 IP addresses (10 hosts up) scanned in 7807.86 seconds

Looking at the scan results a couple of items of interest can be determined. Looking at tcp/22 on the two hosts (TargetA and TargetB), there is a good chance a packet filtering device is being used. Looking at the various port states, with some ports in a filter state while others are in a closed state, it’s probable the packet filtering device policy is default permit.

By performing a discovery scan first, there is a better understanding of which systems are online and how the firewall is configured. When the information gathered during the discovery scan, the enumeration phase can be more targeted resulting in two benefits. The first benefit is time saved by focusing on only hosts online. The second benefit is there is a less likely hood of detection because later phases of the penetration test is more targeted.

With an understanding of how to interpret the results, the three different output files can be used to the testers’ advantage. The three types of output files were the normal, grepable and XML files.

The normal output file (.nmap file extension) is great when looking if looking at the entire scan result or for counting how many ports are open in a scan. If you want to search the results for how many host have a particular port, this simple search can be performed:

host#grep –i ‘80/tcp’ hostdiscovery.nmap | wc -l
10

The results from the grep shows that 10 hosts have tcp/80 open. With this information service detection scans could be used for tcp/80 or a full enumeration scan could be performed. The normal output is good for trying to gather information from an overall perspective (i.e. count all open tcp/80 ports), but if the objective is to know which specific hosts have tcp/80 open other formats should be used. The normal format output is one port per line making more complex searches much more difficult.

Searching for specific information is best done using the grep output file (.gnmap file extension). This format takes the scan results for one host and writes it on one line, making it easier to search with tools from the command line. For example to search for all host with tcp/80 open using grep this command would perform the search:

host# grep -i '80/open' hostdiscovery.gnmap
Host: 192.168.1.150 () Ports: 21/closed/tcp//ftp///, 22/filtered/tcp//ssh///, 23/closed/tcp//telnet///, 25/filtered/tcp//smtp///, 80/open/tcp//http///, 110/closed/tcp//pop3///, 143/closed/tcp//imap///, 443/closed/tcp//https///, 3389/closed/tcp//ms-term-serv///
Host: 192.168.1.151 () Ports: 21/closed/tcp//ftp///, 22/filtered/tcp//ssh///, 23/closed/tcp//telnet///, 25/closed/tcp//smtp///, 80/open/tcp//http///, 110/closed/tcp//pop3///, 143/closed/tcp//imap///, 443/open/tcp//https///, 3389/closed/tcp//ms-term-serv///
< -- output cut for brevity -- >

The results return every host with tcp/80 open but they are difficult to read, especially when looking at large networks. Since the objective is to find hosts with tcp/80 open, the grep command can be combined with awk to find hosts with tcp/80 open as seen here:

grep -i '80/open' hostdiscovery.gnmap | awk '{print $2}'
192.168.1.150
192.168.1.151
192.168.1.152
192.168.1.200

The final format, XML output (.xml file extension) can be read by many different application including scanpnbj. Using scanpnbj the results in the XML file can be imported and stored in a sqlite database. Then using outputpbnj the results can be query using sql statements. Remember many other applications also can import XML formatted output as well.

Performing a discovery scan and properly interpreting the results increases the value of the penetration test for the client. Correctly identify online targets allows the penetration test more time to focus on known live hosts. The customer receives a more accurate understanding of the risk to their organization.

Detecting live hosts on a target network.

When performing a penetration test it is imperative that all hosts on the target network are identified. Typically when performing a penetration test all that is provided to the tester is the IP range, sometimes that is not even provided. With just a network range you must identify all live hosts in that range.

In the past, ping sweeps was reliable enough that a pen tester could be comfortable in those results. Today this is not the case, as many organizations block ALL unsolicited ICMP traffic at their border, so other methods must be used to identify live host on the network. Not only are organizations blocking ICMP but they are using tools to identify this type of activity such as firewalls, IPS/IDS and possibly even a Security Event Incident Manager (SEIM).

Since just a ping sweep can’t be performed other methods must used to identify live hosts. To accomplish this I typically use the tool nmap to perform a TCP SYN scan.

To understand how this scan works you must first understand how TCP connections are established on open ports, what happens if the port is closed and finally what happens if the target host is not online. When two hosts want to communicate over TCP a TCP connection called a TCP session must be established. To establish the connection the TCP three way handshake must be completed.

The first step is for the host initiating the connection (Host A) to send a TCP packet to a specific port, for example 80, with the SYN flag set to the target host (Host B) it is attempting to establish the connection with as seen in this lovely ASCII art.

Host A ------SYN------- > Host B

Since Host B is listening on port 80, Host B sends a TCP packet with both the SYN/ACK flag set back to Host A as seen here.

Host A <------SYN/ACK-----Host B

Host A, after receiving the packet from Host B, sends a TCP packet with the ACK flag set to Host B to acknowledge it received the 2nd packet, and the connection is now established and data can be transferred as seen here.

Host A ------ACK------- > Host B

So now that there is understanding of how a TCP session is established, let’s examine what happens if the Host B is not listening on port 80.

The first step is the same with Host A initiating a connection to port 80 on Host B with the SYN flag set.

Host A ------SYN------- > Host B

Since Host B is not listening port 80, Host B will reply with a TCP packet with the RST flag set.

Host A <------RST-----Host B

Although the Host B is not listening on that port a response from Host B is still sent to Host A indicating it’s online.

Finally let’s look at attempting to establish a TCP connection for a host that is not online.

Again the first step is the same with Host A initiating a connection to port 80 on Host B with the SYN flag set and a timeout of 1 second.

Host A ------SYN------- > Host B

Since Host B is offline there is no response, Host A will send another packet these time waiting 2 seconds for Host B to respond. After not hearing from Host B a second time it will send a third packet waiting 4 seconds for Host B to respond. After the third packet Host A will assume Host B is unavailable and quit trying to reach it.

Understanding how TCP sessions are establish can be useful in identifying live host on the network. With this knowledge it is time to start discovery live hosts.

The objective of this scan is Host discovery, with a secondary objective of being stealthy to avoid detection. To meet these objectives nmap’s TCP SYN or “half open” scan will be used.

Nmap’s SYN scan sends a TCP packet with SYN flag set to the target. The target host will reply if online with the appropriate response (SYN/ACK for open ports, or RST for closed ports) depending on the state of the port. If the target host sends a TCP packet with the SYN/ACK flags set, the scanning host will not complete, resulting in a half open connection. If the target host is offline there should be no response.

To perform the SYN scan using nmap is the command line options:

nmap –Pn –n –sS –T 1 –p 21-23,25,80,110,143,443,3389 TARGET -oA OUTPUTFILES

The first option (-Pn) treats all host online, skipping the Host Discovery phase. Nmap’s Discovery Host sends an ICMP echo request, ICMP timestamp request, a TCP SYN packet to port 443, and a TCP ACK packet to port 80. This type of discovery is good if there are no packet filtering devices between the scanner and the target, but this typically will not be successful over the Internet.

The second option (-n) turns off name resolution. Other tools such as nslookup, dig, can be used for DNS enumeration. Turning off name resolution has an additional benefit of speeding up the scan, especially when scanning large networks.

The third option (-sS) is the SYN scan option.

The fourth option (-T 1) is the speed of the scan. The speed range of the scan is 1 through 5 with 1 being the slowest and 5 being the fastest. This option can be used to assist in evading detection during a scan. Since an objective is to scan undetected slow scans are preferred, but not always an option.

The fifth option (-p) selects the ports to scan.

The TARGET is of course the target of the scan. For nmap this can be a single host, a subnet, a range of host (such as 10.0.0.1-10.0.0.23) or a combination of any or all of them (such as 10.0.0.1,10.10.10.0/25,10.10.20.4-56).

The last option (-oA) is to output the scan results in normal, XML, and grepable formats. Following that flag is the base name of the output files. The normal (-oN) output is great if you want to look through all of the results. The grepable (-oG) output is for using grep and other shell commands to search through the output. The XML (-oX) output produces the output formatted in XML.

For demonstration purposes the target network to be scanned is 192.168.1.0/24. To simulate a typical Internet connected target network this network is protected by a firewall. To begin host discovery, type this command:

nmap –Pn –n –sS –T 1 –p 21-23,25,80,110,143,443,3389 192.168.1.0/24 -oA hostdiscovery

Once the scan completes the following information will appear.

Nmap done: 256 IP addresses (10 hosts up) scanned in 7807.86 seconds

From these results we see 10 hosts are up. The benefit is there is a likely chance, not guaranteed though, most online host are detected. Now more extensive scans can be performed against known live targets.

Another thing to note it took over two hours to complete the scan, even though the scan host and the target network are connected to same switch. This could have been performed quicker using the timing option, but the likely hood of detection would have been higher.

Also looking in the directory there will be three files containing the output of the scan named hostdiscovery.gnmap (-oG), hostdiscovery.nmap (-oN) and hostdiscovery.xml (-oX). These file will be used to determine if host are on online.

With the discovery scan complete, the results have to be interpreted. The interpretation of the results is critical to determine online host that should have more intensive port scans. Next time I will discuss how to interpret the scan results.

WEP cracked in under 10 seconds………….

In a previous post I discussed taking the Offensive-Security Wireless Attacks course. I went through the first technical section which focuses on using aircrack-ng (and associated tools) to detect and attack wireless networks in a lab. The lab I built for this class consists of an Alfa USB Wifi Card and a Linksys WRT-54G (Linux) that supports WEP, WPA and WPA2 encryption.

Most Information Security professionals with exposure to wireless security understand why WEP is insecure, why not to use it and the risk associated with using it. However there are people who still believe WEP is sufficient for security of a wireless network.

During one of the exercises cracking WEP keys, I came across something that I could not believe at first. I was able to capture packets for my lab SSID using airodump. Typically you want about 40000 IV’s to start cracking WEP, to get a decent opportunity at successfully cracking it.

On this exercise though I thought I would take a shot at 20000 IV’s. Well, I should have bought a lottery ticket because my WEP key was cracked in 8 seconds. Now this WEP key uses a “64” bit key and is quicker to crack, but the fact that it took me longer to enter in the commands to crack the key then it took to actually crack the key shows how insecure WEP is.

I saved the packet capturefor demonstration purposes when I hear people discuss WEP security/insecurity. Like the say a picture is worth a 1000 words!