forensics on a trojaned machine

Greetings:

Today was an entertaining day. I got a call this morning from a relative
panicked about her windows computer, stating that it reported that she had
been trojaned. She runs a third party antivirus & firewall, and runs behind
a broadband router/firewall appliance, so you had to figure it she had to
have been a victim of either drive-by download or an e-mail.

I don't get many chances to see what the script-kiddies are up to (read:
I'm lazy), so I thought I'd actually do some forensics. Primarily, I was
curious as to how they would initiate remote control since inbound
connections were firewalled off in two layers. It had to be making outbound
connections, but to where? Dee had sent me a paper awhile back about the
asian registrars allowing near real-time authoritative server updates by the
baddies in order to make it impossible to track down the true source of the
activity (they used bots as the authoritative DNS servers, with responses
filtering activity both ways through the bots).

Would this be doing something like that? I wanted to know, but I also
didn't want the machine to actually connect to the outside world. Finally,
I did want it to make connections to *something* so I could get a glimpse at
what protocols they might be using.

So, to make a long story short, here's what I did:

   --Configured my laptop to provide the following:
     --dhcp: gave out myself as the default route/dns
     --dns: create a root zone which would resolve *everything* to myself
     --http: created a global stanza that served nothing out, but
              logged all requests including the user-agent header
     --inetd: enabled tcp/udp echo service (port 7)
   --Configured the firewall to do the following:
     --dhcp: allow dhcp broadcasts to be serviced normally
     --dns: dnat'd all tcp/udp port 53 traffic to be serviced by local
              bind server
     --http: dnat'd all tcp port 80 traffic to be serviced by local apache
     --echo: dnat'd all tcp/udp port 7 traffic to be serviced by local
              inetd
     --icmp: dnat'd all layer-3 ICMP traffic to be serviced by the laptop
     --all tcp/udp: everything else was dnat'd to the local echo service

All this, in theory, should guarantee a connection to my machine regardless
of whether they were using hard-coded IPs or resolvable names.

With the trojaned box down, I fired up all the services and connected both
machines to a switch with nothing else attached. I then fired up the box
and logged in as the primary user.

Here's where I'm both amused and disappointed. Amused that just about every
application installed has a ET-phone-home app or update checker, but
disappointed because there was no unexpected trojan traffic. Turns out the
trojan was just social engineering -- they used javascript associated with
banner ads to attempt to trick you into downloading a security tool to get
rid of a false backdoor, and the trick did point to a trojan that your click
would launch to install itself. Luckily, my relative didn't click, and it
didn't install, and the file was cleared normally from the cache.

I also learned that the network printer monitor that HP installs pings and
SNMP polls the crap out of the printer, and if echo is just returning the
original request it actually trys *harder*. <sheesh> I'm actually
surprised that the program didn't crash from bad input, so they get some
credit there.

All told, I think it was an entertaining exercise. For those of you who
have to work with less transparent platforms, you should try it and see what
programs poke their little heads out of the hole. With persistent Internet
increasingly becoming more the norm, companies are getting a lot more
aggressive about knowing who's using their software, and some are keeping
watch over every single time you launch the software as well.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sun Dec 2 21:46:41 2007