ESET Threat Blog

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

This is bizarre, if slightly nostalgic.

I spent a lot of time in the first half of this decade writing and presenting on problems with email filters that assumed that if the "From" field of an email header says that the sender was me@thenameofmysite.com (apologies to thenameofmysite.com if it actually exists, but I don’t think it does), then it must indeed have come from me@thenameofmysite.com.

Of course, there are any number of reasons why this might not be true. (Occasionally there are even understandable, arguably legitimate reasons for forging an email address, though that might open up all sorts of legal issues.) One, of course, is that spammers usually forge sender addresses – in fact, this is often one of the identifying characteristics that legal measures are based on, though there are almost as many definitions of spam as there are of malware.

• A "Joe Job" is the name usually used when a specific person is targeted by forging his or her address as the sender, with the particular intention of causing trouble: for instance, by causing him or her to be targeted by anti-spam vigilantes, DNS blacklists, even law enforcement.
• Mail sent from an automated source (a spambot, for instance) may have to forge a sender address, since otherwise it won’t be delivered. Sometimes that address will be a real address  harvested from a Direct Harvesting Attack (DHA), the address book on a bot-compromised system, and so on. Often it will be a made-up address that looks right, which is all that many mail servers require. However, there’s a possibility that a made-up or automatically generated address will correspond to a real account name somewhere on the wild and woolly internet.

Sometimes this results in what is often referred to as backscatter or outscatter: this usually results in the innocent party receiving a non-delivery notification for a message they never sent. Sometimes this is neutral in tone but confusing – some people get into a panic because they think someone may have taken over their account to send email (which can happen, but happens less than you might think). I often see questions relating to this phenomenon on sites where people ask for advice on security issues.

Sometimes the notification suggests malicious intent on the part of the innocent sender, misidentified as a spammer or virus distributor, which frightens the naive and irritates the knowledgeable. It used to annoy me particularly when people would accuse me of sending spam from an address that wasn’t actually capable of sending messages: it can be useful in some contexts to have addresses that are set up to receive and forward messages to another account, but are not set up for sending.

So I had something of a timeslip moment this morning when I got a non-delivery notification from a German company telling me that they found a virus in "my" email. To their credit, they did offer me help if I contact their postmaster address: when I was the fall guy for email security for a Certain Organization, it depressed me intensely to get this sort of stuff from no-reply addresses. Almost as much as it depressed me that the service I was supposed to look after used an outsourced service that didn’t allow me to get backscatter turned off (well, not till I’d nagged for about 18 months). So on one hand I was popping up at conferences and in print saying "misdirected virus alerts aren’t free advertising for an AV product, they’re a form of spam" – the term "collateral spam" is sometimes used, by analogy with "collateral damage" from "friendly fire." On the other hand I was getting angry mail from people telling me what was wrong with service that had my name on it (the administration was actually outsourced), as if I wasn’t already too aware.

Anyway, I don’t seem to see much of this any more. But if you’re still administering a mail server that sends virus alerts to the apparent sender, can I politely suggest that there’s a reason why AV companies don’t usually do this by default any more?

Okay, sorry about the horrible pun. It suddenly occurred to me that people (especially those from outside the UK) might be somewhat shocked that the Barts and the London NHS Trust, a group of three major hospitals in London took so long to deal with a malicious program that was, apparently, detected by their provider as long ago as January 2008. I still don’t know exactly how a fairly elderly variant of a positively antique mass mailer managed to escape both the on-site anti-malware service and the NHS email service protection, but it doesn’t surprise me that the Trust’s IT team were cautious about the recovery, prioritising clinical areas rather than administrative staff.

Some years ago, the entire NHS suffered a fairly lengthy network outage because the Code Red worm was known to be infecting some unprotected machines. At that point, there were over three million systems known to be connected to the NHS network – I’ve no idea what the current figure is but I doubt if it’s less – so it would have been miraculous if there were no unprotected or infected machines. So there were two main considerations: (1) essential services shouldn’t be disrupted – and by that I mean clinical services, not the director of something or other being unable to track something he was auctioning (or bidding on) on eBay (2) the NHS should not be transmitting malware to the rest of the world. In a rational, properly secured healthcare organization, a networking problem, even over days rather than hours, really shouldn’t endanger lives. So the WAN service was severely restricted while a handful of machines were traced and cleaned/patched, but life went on in Britain’s health service: it wa a little more difficult to keep the wheels greased, but no panics or mass burials.

This time, too, there seems to have been a determined effort to maintain control and balance: a crisis, but not the drama you might have expected. In fact, in spite of our increasing dependence on sophisticated electronics, it looks as if healthcare is still about people making do and coping, not about The Machine Stops. Which cheers me up, anyway. Political dissensions notwithstanding.

David Harley CISSP FBCS CITP
Director of Malware Intelligence.

I’m still in Washington, but have just picked up some news that reminds me not only of home, but of my job of a few years ago, when I worked as a security manager for the UK’s National Health Service. It’s been announced that the Barts and The London NHS Trust, which includes several of the best-known hospitals in London (St. Bartholomew’s, the Royal London, and the London Chest Hospital), has been hit by a virus (apparently a version of the venerable Mytob email worm). It’s been commented that an urgent review of the Trust’s security policy is needed. That couldn’t do any harm - how come so many systems were apparently compromised? - but the problem may go a little deeper than that.

Unless the infrastructure has changed dramatically in the last 2 1/2 years, much NHS email (and there is a lot of it – well over a million people work for for the National Health Service) goes through a mail service currently called NHSmail. NHSmail (which is at least the third incarnation of this particular service) was intended to replace the relay services that carried the bulk of NHS email at the beginning of this decade. The current service is defended by "cutting edge" anti-virus and anti-spam, and that protection was supposed to have been extended to the relay services several years ago. So, there is certainly a question to be asked about the state of the Trust’s own email defences. I have to wonder, though, how email-borne malware can apparently still get through to an NHS site as easily as it could earlier in the decade, when email services were far more fragmented and decentralized?

David Harley CISSP FBCS CITP
Director of Malware Intelligence