System Store Trojan, Infection Persistence, Save the Pr0n

System Store Trojan, Infection Persistence, Save the Pr0n
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.orgI will be teaching next: Application Security: Securing Web Apps, APIs, and Microservices - SANS London June 2022	Johannes 4473 Posts ISC Handler Sep 17th 2004
Thread locked Subscribe	Sep 17th 2004 1 decade ago