lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
From: eckman at umn.edu (Brian Eckman) Subject: Analysis of a Spam Trojan I discovered a machine in our building spewing Spam on 9/23/2003. It exhibited behavior similar to other mysterious ones we've seen on campus. A co-worker and I went and found the machine. It was a Windows XP machine from the dorms that had been turned in to the helpline staff to have them clean it up for Welchia. They had cleaned up the Welchia worm and were in the process of applying further patches when the person working on it got called out to work on something else. So, we sat down at it and checked it out. We found a couple of suspicious files that Symantec AntiVirus CE (definition files were dated 9/17/2003) was not flagging as infected. They were: c:\windows\system32\audio.exe c:\windows\system32\sznwjhf.dll The file c:\windows\system32\sznwjhf.dll was being run as an application by rundll32.exe, and was configured in the registry to boot at startup. Due to it using rundll32, it is not displayed in the Processes tab of the Windows Task Manager (not even as rundll32). Deleting it from the registry or disabling it via Msconfig would only remove it for a couple of seconds - the running process would put it back right away. (System Restore had already been disabled before this point, so that was not to blame.) I copied those two files to a USB pen drive. Note that Windows would not let me delete sznwjhf.dll, even in Safe Mode. I booted to a Windows 98 startup disk that was laying around and deleted it via that. I was then able to go into Windows and delete the registry entry. I submitted the sznwjhf.dll file to Symantec (at that point in time, I had no idea that audio.exe was malware - it was on a hunch of my co-workers that I grabbed it) that day. They responded yesterday that it was Backdoor.Coreflood, and sent me beta virus definitions. I confirmed that those definitions caught it, and noticed that they caught audio.exe as a generic file "Download.Trojan". I have since verified that yesterday's (non-beta) LiveUpdate release does in fact identify these files as infected. I read Symantec and McAfee's write-up of Coreflood, and was not satisfied. This variant has several differences, particularly it's size. The DLL file is 111 KB, much larger than the McAfee writeup showed. So, I fired up an instance of VMWare and ran audio.exe on it. At the same time, I was sniffing traffic to/from that computer with Ethereal. I soon discovered that audio.exe was indeed the infection vector... Shortly after running audio.exe (6 KB), the VMWare instance made a connection to http://207.44.244.61 and issued a GET request for /test/tracker.exe. In the GET request, it identified the host as "www.artbookmark.com", which I believe is required in order to download the /test/tracker.exe file. (When I went to the 207.44.244.61 site manually, I got a 404 not found error when trying to download the file. So, don't fire up your Web browser and try to download the file, then assume this threat has disappeared just because you get the 404 error.) At this point in time, the DLL now exists in the %SYSTEM% directory, and the registry entry has been created. (Note: the DLL name is a random 7 character string, and thus will vary greatly.) After that, the VMWare instance made a POST to http://66.221.218.73/cgi-bin/ref.cgi, containing information regarding the now-infected computer, including the date and time of infection and the ports that the Socks and HTTP proxy are running on. In this POST, the host was identified as "l0g.org". Note that machines that are not newly infected appear to make this POST request shortly after being restarted. I assume but do not know for sure that the proxy ports are randomly chosen each time the malware is loaded (basically, upon reboot). After that, the VMWare made a "GET / HTTP/1.1" request to http://81.52.248.113. The GET request listed the host as "www.microsoft.com". Again, this appears to be required, as navigating to that Web server manually results in an error. The result of this HTTP request appears to be benign. The resulting HTML, which is never displayed on the now-infected client, appears to be a slightly old version of Microsoft's home page. My assumption would be that this is just one more machine that is being used to log infected hosts by looking at the GET requests, presumably in case the other one gets taken down. Note that I have never seen *any* IRC traffic going to/from these hosts. The write-ups for Coreflood by McAfee and Symantec claim that it's intent is DoS and that it is controlled by IRC, but that is *not* the case with this variant. The random TCP ports opened up by the Trojan DLL file show up as being run by Explorer.exe (the legitimate one) when using Fport until the first reboot. They then show as being run by rundll32. One of the ports is a wide-open HTTP Proxy. The other port is a standard SOCKS Proxy. These are being abused by spammers, who likely obtain the proxy info from the POST made to http://66.221.218.73/cgi-bin/ref.cgi. I think it is pretty clear that this operation is being run by spammers (or someone hired by them). I have seen at least six different IP addresses abusing the open proxies on one host at the same time, so this appears to be an organized effort. I have seen at least six infections on campus, so this isn't an isolated incident. I don't think what we have found has anything to do with DoS attacks and IRC like Symantec and McAfee claim in their write ups of Backdoor.Coreflood. Homemade Snort rules to detect this: alert tcp any any -> 66.221.218.73 80 (msg:"SPAM TROJAN\: Post Proxy Ports"; content:"|50 4F 53 54 20|"; classtype:bad-unknown;) alert tcp any any -> 207.44.244.61 80 (msg:"SPAM TROJAN\: GET tracker.exe"; content:"|47 45 54 20 2F 74 65 73 74 2F|"; classtype:bad-unknown;) As of 16:30 GMT, Thursday, September 25, 2003, this activity still occurs. There is no telling how long these sites will be active now that this information has been posted publicly. One student who was infected reported to me that Symantec AntiVirus CE could not delete or quarantine the Backdoor.Coreflood infected file, even in Safe Mode. This is consistant with the fact that I could not manually delete that file in Safe Mode either. They were running Windows 98. It is unknown how the audio.exe file got onto the computer hard drive in the first place. I have not yet notified abuse contacts of the ISPs of the IP addresses posted. Brian -- Brian Eckman Security Analyst University of Minnesota "There are 10 types of people in this world. Those who understand binary and those who don't."
Powered by blists - more mailing lists