Message-ID: <3F73200E.8020707@umn.edu>
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