Trojan Stealing System Store

A "multi-stage" trojan has been reported to us by Morton Krkvik (Telenor Security Operations Center, Norway). The trojan starts at www.alarm-works.com, and uses the old
.chm exploit to upload its 'first stage' (ttt.exe). Next, it will grap
as second stage from 65.77.216.38. This part, a binary called sstore2k.exe
is a UPX packed. It appears to upload the SSL certificates and cached passwords from the
Windows Systems Store to the same system.

This analysis is not complete, and may be completely wrong ;-). more
later or in tomorrows diary.
Infection Persistence

The data collected by DShield.org can be used to estimate the time it
takes on average to clean an infected system. The infection persistence
can be estimated by calculating the time between the first and last
report received for a particular host. Overall, this should provide
use with a reasonable estimate.

Errors are introduced by three issues:

(1) Our sensors will likely not receive the first and last bad packet
sent by an infected host. This will shorten the observed duration of
an infection.

(2) We are not able to connect reports from dialup users (or in
general dynamic IP users) who are assigned a new IP address whenever
they connect.

(3) Some systems in our database may not be infected at all, but due
to configuration choices of a particular sensor, or due to unusual but
legit traffic from the site it may show up as infected.

Given these caveats, here is the data:
http://isc.sans.org/images/persistence_new.gif

I did try to fit a few different models to this curve. Without exhausting all the possible models, the model that fits in particular well is the assumption of two different populations with a distinct half-life to be fixed. The red
dots represent the data collected by our sensors, while the thick green
line is calculated using the following assumption:

(1) 96% of the infected systems will have a 50% chance to be discovered and
fixed within 6 hrs.

(2) 4% of the infected systems will have a 50% chance to be fixed within 7 days.
I did a similar graph about 2 years ago:
http://isc.sans.org/images/persistence_old.gif

Interesting, even then we had a similar split between fast/slow fixed systems. However, only 0.5 % of the systems fell into the 'slow' group. It is however too earlier to call this evidence that systems are less like to be fixed right away. There are a couple of things that changed over the last two years.

First of all, the older data was collected not too long after a worm outbreak
(Nachia worm if I remember right). If you call the fast-fixing systems 'well maintained', you can assume that shortly after a worm outbreak you are more likely to have well maintained systems infected vs. some time after a worm outbreak. On the other hand, our sensor coverage increased substantially over the last two years. As a result, for some of the systems we observed for only a short time two years ago, we not get more data which extends their 'persistence' in our database.

Save the Pr0n

We got a note from Frank somewhat flaming yesterday's handler (Cory) for his suggestion to move back to a text based Internet (we all still have a gopher client?).

Clarification: It was meant to be a joke. However, in case you are using
Lynx to read this, here is a text based ISC logo for you:
http://isc.sans.org/images/logo.php
(thanks to http://www.degraeve.com/gif2txt.php )

-----------------

Johannes Ullrich, jullrich_'at&sa\ns.org