------- Forwarded message follows -------
Date sent: Sat, 9 Dec 2000 00:41:15 -0500
Send reply to: [email protected]
From: "Howard, Aaron" <[email protected]>
Subject: Re: Millennium Trojan
To: [email protected]
Well, since I have received several requests, I'll include a more full
analysis
of this trojan.
Please note that this is all from reviewing the executable, not
actually
running it. I'm not confident enough in my abilities to keep it from
doing
damage if I run it.
So, a little background...
We hired an outside consultant to help us set up an
accounting/distribution
software package. He came in and was seated at an open PC.
We block a lot of things, but I have heretofore been lenient on
outbound
traffic (allowing all machines inside with valid source addresses to
establish
connections on any local port > 1023 to any other machine outside our
network
on any port > 1023.
The idea was to allow our users to run IRC, MSN Messenger, AOL Instant
Messenger, Yahoo Instant Messenger, ICQ, RealAudio, etc. (Modification
of
this policy is already underway...)
But, even though we allow(ed) these outbound connections, they are all
logged
to a central logging machine and that log is constantly scrolling in
the
background of my screen.
So one day I'm working away and notice a bunch of connections on
destination
port 6667...this peaks my curiosity because I KNOW nobody at our
company uses
IRC but me...and this wasn't me.
Here are the actions I took ...
1. nbtstat -A internal.source.ip.address
this returned me the following:
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
PCNAME <00> UNIQUE Registered
OURDOMAIN <00> GROUP Registered
PCNAME <03> UNIQUE Registered
CONSULTANT <03> UNIQUE Registered
MAC Address = xx-xx-xx-xx-xx-xx
The key here was that is showed the source IP address in question was
in use
by our consultant.
Now usually I'd just call the user up and say, "What are you doing?"
but this
being a consultant, I decided it was best to be more discreet.
We use VNC on all our internal machines for support-related issues. So,
I
checked him out.
2. I used VNC to view his screen and take screen shots of him chatting
via
mIRC for nearly an hour.
3. After this, we let him go and immediately blocked outbound
connections on
all ports > 1023. However, we left the machine on. Then I started
noticing
blocked connections on port 6667 from that machine. Blocked attempts
looked
like this:
(Note: destination ip addresses were not attempted in this order, this
is a
sorted list of unique destination IPs...)
4. I VNC'ed over to it and saw NO applications running. Nothing in the
task
list at all.
5. So, I created bootable Norton Antivirus 5.0 disks with the latest
virus
defs (11/27/00) and went to that machine and scanned it. Nothing. So,
I
started MSINFO32.EXE to check loaded modules and found something called
kernel32.vxc was in memory but it had no version info. And it was in
\windows\system... I scanned it specifically again, NAV said not a
virus. It
was attrib-ed as HIDDEN/SYSTEM.
6. I copied it to a floppy to take to another machine for testing and
renamed
it BADGUY.EXE.
7. QuickView of the EXE showed very little other than that the EXE was
mangled
(packed) to prevent viewing like this.
8. So I checked backlogs of my bugtraq e-mails and found a few sites
with
reverse engineering tools. www.suddendischarge.com was most helpful.
9. I downloaded several tools from sudden discharge: 1) Universal File
Scanner
(fs11-27-00.zip), 2) Anti-Aspack 0.2 (unaspack02.zip), 3) DeDe 2.431
(dede2431full.zip), 4) PE Explorer 1.0 Beta (pex_b090.zip)
I thought one thing was odd about this...the linktime says
19.Jun.1992...so
was this program REALLY compiled in 1992? Not likely. I imagine a
little
hex-editing of the file and you can make the link date whatever you
want.
Or change the date on your system before linking.
b. Since I couldn't tell much more about the file without unASPack-ing
it,
I used unaspack to remove the packing and created badguy2.exe, then fs
showed
the following...
c. I used DeDe to disassemble it and generate the attached form1.pas
file.
(Note: I removed the password as I see no need for it to be included...)
d. I generated a strings reference from the "source" DeDe creates in
strings.txt. From this we can tell the trojan will accept a number of
commands and take certain actions based on those commands.
e. I used PE Explorer to grab out a little more (saved as nmshow.pas)
Which shows they are using a component from NetMasters in this trojan...
Source files created by DeDe and PE Explorer are not all attached as I
keep
getting my message rejected for being over 3000 lines.
...but I think what's here explains well enough.
-Aaron
--
Aaron Howard, RHCE, CCNA, CNE, MCSE
[email protected], [email protected]
PGP key available via key servers
------- End of forwarded message -------
generated by msg2page 0.06 on Jul 21, 2006 at 19:04:51
search: