ESET Threat Blog

Gadi Evron drew my attention in an article for Dark Reading to a piece in IT Pro by Asavin Wattanajantra. The piece quotes Dr. Steve Marsh, of the UK's Cabinet Office (the Office of Cyber Security, to be precise) as saying that botnet operators are interested in money-generating attacks on the private sector, not causing damage to "national networks".

You might recall that I made a not dissimilar point in this blog with regard to Conficker, when we were all wondering what April 1st would bring: basically, I maintained that the Conficker gang was unlikely to attack the Internet infrastructure, as some journalists and others were fearing.

However, I don't feel, for a number of reasons, that the UK government (or any government) should be complacent about the risk from botnet-directed attacks for purposes of espionage or cyberwarfare (whatever you may understand by that particularl buzzword). I've explained my reasons for that in a blog for (ISC)2 ( International Information Systems Security Certification Consortium) at http://blog.isc2.org/isc2_blog/2009/11/botnets-not-a-problem.html.

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

ESET Threatblog (TinyURL with preview enabled): http://preview.tinyurl.com/esetblog
ESET Threatblog notifications on Twitter: http://twitter.com/esetresearch
ESET White Papers Page: http://www.eset.com/download/whitepapers.php

Securing Our eCity community initiative: http://www.securingourecity.org/

I was asked about malware infection in the UK (especially with reference to Conficker), and(a) if the situation is really as bad as we, the AV vendors make out, and what the real infection rate is; and (b) whether government and ISPs etc could do more to help. You can now find a link here (http://www.guardian.co.uk/technology/2009/nov/04/malware-pc-security-antivirus) to the piece that Jack Schofield (of the Guardian newspaper) was writing on the topic. However, I thought you might be interested in my original answer on that point, at any rate if you're in the UK.

ESET normally avoids giving out absolute numbers as they're too prone to be misleading or misinterpreted, since we can't say how they compare to the entire population of the Internet. (Not that it stops other companies giving "authoritative" statistics!)  I can say that our lab gets over 100,000 unique malicious binaries a day from Threatsense.Net®, a mechanism for sending in samples from machines running ESET products that detect malware. Obviously that's a global figure, not the UK: I don't have a figure for that.

However, we can give percentage figures that give an idea of which malware (and other suckware) is scoring highly regionally. If you want to compare these figures with the results we got globally in October, they're at http://www.eset.com/threat-center/threat_trends/Global_Threat_Trends_October_2009.pdf, Note, however, that this is a slightly "apples and oranges" comparison: for a number of reasons, we don't list the global top ten in the monthly report in quite the same way. For instance, nuisance applications that aren't necessarily technically malicious are filtered and some closely related detection statistics are consolidated to show the underlying trend more clearly.

•  In October in the UK, the top scorer was actually a "possibly unwanted application " (PUA), with 4.02% of detections.  
• Conficker variants were 2nd (2.68%) and 9th (2.14%) (this is an example where we conflate the figures in the report, to make the trend clearer).
• Malware that exploits the Autorun vulnerability took positions 3 (2.66) and 5 (2.36%).
• Number 4 was another type of adware  (2.47%) – note that some types of adware have serious Trojan functionality (Virtumonde, for example), they're not just a nuisance.
• Position 6 was a fake anti-malware program (2.31%) – that's a higher score than we usually get globally for a specific rogue AV variant, which is interesting. It doesn't mean that the UK is more prone to attacks by rogue AV than the rest of the world, though: it's just that there are a lot of different detections for these things. The situation is analogous to bots: while the total number of infections is very high, it doesn't show up clearly in the statistics because there are so many families and variants.
• Number 7 was an advanced heuristic that picks up an even wider range of malware than INF/Autorun.
• Number 8 was malware targeting online gamers (2.16%).
• Number 10 was a highly generic detection for a range of bots and similar malware.

I don't think there's much that governments can do on a legal/governance level (some have some catching up to do, though). The vendor research community does work with law enforcement and even intelligence services to a greater extent than you might suspect, and I wouldn't want to play down the importance of that co-operation. Some ISPs do make a serious effort to block malicious URLs, which are a -major- cause of infection, but they come and go hydra-like. It does help that AV vendors recognize a high percentage of malicious binaries once they're downloaded to a protected system (whereas detection on the site or during download tends to be highly resource intensive). However, I  don't think there's a single, easy solution: anti-malware is only one layer of remediation.

Just to give a little global perspective, the data I drew on here suggest that the threats detected by ESET-protected machines in the UK over October represented about 0.44% of the binaries submitted by all the protected machines in the world, and 1.61% of them were unique to the UK.

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

ESET Threatblog (TinyURL with preview enabled): http://preview.tinyurl.com/esetblog
ESET Threatblog notifications on Twitter: http://twitter.com/esetresearch
ESET White Papers Page: http://www.eset.com/download/whitepapers.php

Securing Our eCity community initiative: http://www.securingourecity.org/

Conficker

• If you have not already done so, deploy Microsoft’s MS08-067 patch for the vulnerability initially used by the worm to infect systems.  It is also a good idea to install the MS08-068 and MS09-001 patches as well.
• Disable AutoRun on removable media.  More about this below.
• Use strong passwords.  The Conficker worm contains a set of commonly-used passwords in order to make it easier for the worm to spread across network shares.  A list is mentioned in this news article.  For more information about choosing good passwords, see these three earlier ThreatBlog articles here, here and here.  We also have a white paper on the subject.

Worms continue to spread quick as a flash

Conclusion

Aryeh Goretsky MVP, ZCSE
Distinguished Researcher

The Register has reported that it cost Ealing Council, in London (UK) some £500,000 in lost revenue and repairs after a "virus infection" in May. According to El Reg’s John Leyden, the virus in question was Conficker-D, though because of differences in Conficker variant naming, it’s difficult to say exactly which variant that would refer to. Not that it matters very much at this point, I suppose.

According to the Guardian further costs to the Council include:

• 1,838 parking tickets cancelled (total cost of £90,000)
• libraries lost £25,000 in fines and booking fees
• an unspecified amount of council property rent went uncollected (presumably the council expects to catch up with this, but will obviously lose out on revenue in the short term)
• £14,000 spent on clearing housing benefit claims.

The cause of the infection has been traced back to a council employee who plugged an infected USB memory stick of some kind into a PC at work.

Now do you believe us when we tell you that you need to install the Microsoft patches that will stop Autorun executing from most USB devices?

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

ESET Threatblog (TinyURL with preview enabled): http://preview.tinyurl.com/esetblog
ESET Threatblog notifications on Twitter: http://twitter.com/esetresearch
ESET White Papers Page: http://www.eset.com/download/whitepapers.php

Securing Our eCity community initiative: http://www.securingourecity.org/

Potentially Abandoned Conficker Grows

According to an article at Internetnews.com http://www.internetnews.com/security/article.php/3832846 the authors of the Conficker botnet may have abandoned it, yet it continues to grow in numbers. The growth of the botnet is troubling because it is completely preventable and because it means the infected computers are vulnerable to other threats and that these users are not using security software that is current.

Conficker spreads through USB devices using autorun. Disabling autorun is a good security precaution. I’ve blogged on it a few times before.

Conficker spreads by exploiting a vulnerability in Windows, except if you patch like you should. Evidently many corporate IT people failed to learn the lessons of CodeRed, Nimda, Slammer, Sasser, BubbleBoy, and a host of other threats from days gone by that were preventable just by applying security patches.

Conficker also spreads through share folders on networks. People need to use strong passwords and protect network shares.

It isn’t really surprising that the authors may have abandoned the botnet as it is encountering significant scrutiny, but it is disappointing that the growth of the botnet is a barometer of the current state of security and it leave a lot to be desired.

Randy Abrams
Director of Technical Education

Our July ThreatSense.Net® report has been released today, and will eventually be available from the Threat Center page here. Most of the top ten entries are old friends: well, familiar names might be a better way of putting it. One of the disadvantages of having a scanner that makes heavy use of advanced heuristics is that many of the most common detections don’t really map to single malware families the way that they do for companies that are more signature-oriented.

There are advantages, though, as we’ve discussed before, apart from the obvious (and important) advantage of proactive detection: it gives us more time to concentrate on processing detections rather than fussing with crossmatching samples to malware families, and it gives us a better picture of major threat trends, which we consider to be more useful. Unfortunately, some sectors of the media are still hung up on the minutiae of malware naming, which I don’t consider so important at a time when some sources are talking about collections of (much) more than 20 million individual samples. Hopefully they’ll catch up with the rest of us eventually…

Pierre-Marc and I presented a paper on the naming problem at Virus Bulletin last year, and I’ve developed the theme further in another conference paper that will be available on the white papers page in September.

As it happens, there aren’t a lot of surprises: the first few positions remain unchanged from June. However, Win32/TrojanDownloader.Bredolab.AA, despite a strong local showing in some countries, has dropped out of the worldwide top ten, while W32/FlyStudio is in at Number 5. FlyStudio is kind of interesting: it’s not exactly a malware family, but a development platform (a scripting language, to be more precise) much used in China. Unsurprisingly, the FlyStudio malware we’re seeing also seems to be targeting computer users in China, but is also being reported elsewhere, including North America. This may mean that it’s being deployed by another malware family.

 Elsewhere in the top ten section, we’ve updated some of the descriptions. Over the lifetime of a threat family, there are often substantial changes in the way the malware works, or in our understanding of it as more variants appear and more information becomes available. And, as usual, we’ve included some notes on other issues that have been addressed recently by the labs and/or the Research team, including:

• Adobe and Microsoft patching issues
• Twitter and Facebook problems
• A little about AMTSO
• Some white papers that are about to appear
• Waledec and the Dewey Effect
• ESET in Europe’s initiative on safe wi-fi.

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

ESET Threatblog (TinyURL with preview enabled): http://preview.tinyurl.com/esetblog
ESET Threatblog notifications on Twitter: http://twitter.com/esetresearch
ESET White Papers Page: http://www.eset.com/download/whitepapers.php

Securing Our eCity community initiative: http://www.securingourecity.org/

SC Magazine in the UK picked up on our Global Threat Report for June, based on statistics that derive from our ThreatSense.Net® threat-monitoring technology. Thanks, Dan: when you do as much writing as I do, it’s comforting to know that someone is reading it.

I thought, though, I’d develop some thoughts on a topic arising from that article.

SC Magazine tends to use the term “claimed” a lot. Which is fair enough: I don’t take the truth of anything this or any other software industry tells me for granted, and I don’t think anyone else should. And it’s perfectly true that while the fact that ThreatSense.Net® reports an awful lot of Conficker-related detections is statistical fact (but I’ll come back to that in a second), I did say that I “guessed” that this was partly because “users still are not taking basic steps such as timely patching and disabling Autorun to protect their computers and themselves from cyber attack.” (Actually, I could have added something about using and properly maintaining anti-malware products there, but it’s pretty obvious that an absence of antivirus protection is a factor.)

However, the SC report also mentions a comparison I made between Conficker and some elderly mass mailers that are still circulating. “The report also claimed that massmailers such as Netsky, Mydoom and Bagle are still lingering despite patches being released.” Putting it this way actually gives the impression that these little beauties are still in circulating because people don’t patch, and in some cases (and with some variants) this is indeed a factor.

However, what I actually said is that “Conficker is not the only malware to hang around long after a patch has been released; massmailers such as Netsky, Mydoom and Bagle still linger on, although in much smaller numbers, years after patches and antivirus definitions have been released. However, Conficker, being less reliant on direct social engineering, should really be declining in impact by now after all the publicity it’s received.”

That’s an important distinction. Good patching practice is important, and the three practices mentioned (patching, disabling autorun, and securing network shares) provide a lot of protection against Conficker. But most malware uses social engineering as well as or instead of exploiting vulnerabilities. Unfortunately, the “gullibility gene” in computer users is not only the most successfully exploited “vulnerability” around, it’s the hardest to patch.  Which is, of course, one of the arguments for continuing to use malware detection products in a multi-layered strategy that also includes generic and precautionary measures such as patching.

But I said I’d come back to statistical accuracy. Well, our “claims” in this months report are based on two statistical resources. ThreatSense.Net® monitors threat trends using a facility built into our products: when an ESET-protected machine detects malware, it calls home to tell us about it. Of course, that mechanism is both anonymised and optional. However, that means that it can’t be totally accurate. For instance, it’s difficult to compensate for an instance where two or more machines are detecting malware from the same source: however, it’s reasonable to assume most of the time that where we see a spike, it indicates a general trend, and that’s what we’re looking for, not exact but spurious figures. In any case, it’s already a self-selective mechanism, since it polls only machines protected by ESET products.

The other resource is a monitoring mechanism called Virus Radar, which only picks up email-borne threats (executables rather than links). We don’t talk about that much nowadays, because that’s a vector that isn’t much used nowadays by new malware, and to make a big deal out of what we still pick up that way would give a false impression of the current threatscape as we see it. Even then, though, that “as we see it” is important. Different products generate different figures according to who buys the product and where it sits. Like Virus Radar, products that sit on mail gateways will still see a lot of massmailer activity, which is probably why Netsky, for instance, is still prominent in Virus Bulletin’s prevalence report. This is less a case of proving anything you want with statistics (though you probably can….) than of the importance of correctly interpreting statistics.

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

Larry Seltzer, one of the better commentators on malware issues, has picked up on the disparity between ESET’s naming of the latest variant and Symantec’s – they call it W32.Downadup.E. Richard Adhikari (who also seems to pretty clueful) also picked up on the naming issue when we exchanged emails a few days ago.

This issue kind of echoes a question that came up at a presentation I gave recently. "Will vendors ever sort out the naming mess?" The short answer is probably no. Because it’s no longer about naming the malware: it’s about naming the detection.

There was a time when the model of one name to one variant made sense. In general, one boot sector infected by a given boot sector infector looks much like another.  There was even a convention for naming established by CARO, which many vendors still follow, to an extent. And there was (still is) a publicly available utility (vgrep) that crossmatched names across most of the mainstream vendor detections.

Sadly, though, the present threat landscape defies any attempt to categorize samples more than roughly, if at all.

In general, people want to know whether we detect specific malware because, not unreasonably, they want to be reassured that they’re protected against it. But because most malware is tweaked by repacking and reobfuscating at frequent intervals, the sheer glut of samples (anti-malware labs process tens of thousands of unique samples a day) makes that depth of analysis impractical. Fortunately, adding detection for a threat doesn’t generally require an exhaustive manual analysis, and ESET puts a lot of Research & Development effort into proactive detections that lessen our reliance on near-exact identification of known samples.

One of the side-effects of this approach is that the name we give to a detection doesn’t necessarily tell you much about individual samples. To take a simple example, there is a very wide range of malware that (mis)uses the Autorun faclity as an infection mechanism*, so two malicious programs may be identified using the same detection label even though they have no shared code or any other perceptible relationship at all. Sometimes, the detection label used has more to do with the method of detection than the code family to which it belongs.Pierre-Marc and I presented a paper at Virus Bulletin last year in which we suggested that:

• Effectively, the "name" of a malicious program is effectively (usually) its hash value.
• More and more, it’s the proactive detections that count, not the exact/near-exact identifications (signatures, loosely speaking).
• The industry as a whole needs to coax its customers away from this unrealistic model, rather than going along with the near myth that names mean the same thing that they did even ten years ago. 

(Some people might find that paper a bit geekish: I plan on revisiting the theme in the near future, aiming at a less specialist audience. There’s also a less geeky article here, but it isn’t free..

As I understand it, our Conficker variant names have diverged because we were tracking variants quite assiduously at the beginning, at least until we put together a particularly effective generic signature which is still working quite nicely, thank you, and detecting a range of variants and subvariants. So our Conficker variant names have been divergent from the beginning. It’s not that we claim that our classification is any better than anyone else’s (though it might be ), simply that there’s no real standard for classification, and it isn’t usually practical or useful to try to enforce one retroactively.  

* Including Conficker, though the latest versions seem to have dropped that approach, perhaps in the hope of reducing susceptibility to generic detections.

So now for a little more tech detail on Win32/Conficker.AQ (kindly supplied by Juraj Malcho at our labs in Europe – however, if I get anything wrong, that will almost  certainly be down to my faulty interpretation!)

The new variant has two main components. The server component is an .EXE that infects vulnerable PC’s in the network using the same vulnerability described in Microsoft Security Bulletin MS08-067 that Conficker has used since the beginning. This installs the client component, a .DLL (Dynamic Link Library – despite the name, these contain executable code), so as to recruit vulnerable machines into the Conficker botnet.

There is also a driver component that remains on the “server” (the machine that is probing and attempting to exploit other PCs): the driver is used to allow as many machines as possible to connect to the server without the server machine falling over. The infective mechanism stays the same as in previous variants: the shellcode downloads the .DLL from the http server provided by the "server" component (the .EXE) to the targeted, victim machine. The worm starts a HTTP server on a random port. It connects to remote machines via TCP/139 and TCP/445 in an attempt to exploit the Server Service vulnerability. However, the server component will deactive and remove itself after May 3rd, though the client will remain active. The deactivation is carried out using MoveFileEx with the MOVEFILE_DELAY_UNTIL_REBOOT flag, so that the program is removed after the next reboot.

The .DLL contains a newly obfuscated version of the “old familiar” executable, rebuilt using a modified version of the UPX packer. It appears to have been compiled on the 7th April, so the gang seem to be right back in the game and hoping to confuse us by changing the rules. Analysis is ongoing, but a particularly interesting feature is that this version doesn’t contact any of those 50 000 domains a day that we were all so excited about. The new variant, which we call Win32/Conficker.AQ, communicates only within its own peer-to-peer (P2P) network. You’ll find a fuller description of this variant, what it does to the system, which domains it blocks and so forth here.

Curiously, it looks as if the Autorun infection mechanism has been dropped, but it  may still be lurking in a dark corner somewhere: analysis continues, and we’ll confirm that. Our removal tool should work with the new variant, but we’ll be testing and confirming that.

This is, perhaps, the real significance of Conficker: while detection hasn’t presented too many difficulties – the dropper was already detected proactively using a heuristic detection, and all components are detected generically as Win32/Conficker.AQ – guessing where the botnet was going (if anywhere) has been a lot harder. It was for this reason that I was playing with the idea that the whole thing was one immense practical joke. (I yanked that blog because people seemed to think that was serious analysis, not a speculative fancy: however, I might pursue that idea further later on, though not necessarily with reference to Conficker.)

Clearly there’s no out-and-out hoax here, though: reports of an association with Win32/Waledac and the dissemination of spam and fake anti-malware suggests that Conficker is now doing what we always thought it was likeliest to do, and behaving like a botnet. However, despite some reports, I’ve seen no reports of a direct link between Waledac or Conficker and the Storm botnet, though it has been suggested that Waledac comes from the same gang that was responsible for Storm. Hoax or not, the mythmaking goes on.

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence