Prevention Eventually Fails, part two – The Hot Knife of Malware
We already know that prevention eventually fails, and that NSM can help us out when it does. We also know that defence-in-depth is a common strategy in the IT world, whereby one employs many different preventative measures designed to back each other up and to cover as many attack vectors as possible.
Consider a small office with no public-facing servers, where one of the primary defensive tasks is to defend the desktop machines from malware. To this end, the following array of defences is deployed:
- A firewall device is at the office’s border with the Internet. As is usual, no unsolicited inbound traffic is allowed to pass through
- Sitting behind the firewall is an IDS, on the lookout for trouble on its way in and also for compromised internal machines phoning home to Hacker HQ (this is “extrusion detection”, and you can read all about it in this book)
- A spam firewall will scan all inbound email for viruses and spam
- A URL filter will categorise all outbound web traffic and prevent access to anything malicious
- Anti-virus is installed on each desktop machine, and is kept up to date
- All machines have Microsoft patches applied automatically via WSUS
- Users are trained not to do silly things like click on links in emails
That’s seven separate preventative measures, all employed concurrently and maintained in terms of patches, signatures, etc. In terms of coverage and thoroughness, this isn’t a bad setup.
Wouldn’t it be a gigantic shame if all seven failed at once? Surely that can’t happen…
The day starts with an infected machine showing popups for Fake-AV-du-jour, backed up by a BSOD screensaver. The support desk have already wheeled out Spybot and Ad-Aware etc. which have done a creditable job of removing the infection, and everyone’s happy.
Well, not quite everyone. We can’t consider the case closed, as we still need to know:
- How the infection got through what we thought were comprehensive defences, and
- What the infection did aside from the obvious popups (perhaps it also dropped a keylogger or other credential stealer?)
Fortunately, we have an NSM sensor installed behind the firewall, and we have access to all of the logs from the IDS, spam firewall, etc. Our starting point is the compromised machine, and we’re going to work backwards in time until we work out how it got like that. Working on the theory that the infection came in over the Internet somehow, we’re going to secure the following:
- Email logs for the affected user
- URL filter logs for hits from the compromised machine
- Session data for all traffic concerning the compromised machine
- Any relevant AV, firewall or IDS logs for the time frame concerned
Now we can start to put the pieces together. To cut a long story short:
- The infection vector was email. The spam firewall failed to catch it, and it was delivered to the user – this is FAIL #1
- The email said that the user has received an e-card, and gave a link which the user clicked, despite their training not to. Was this a blatant disregard for training? Forgetfulness? Not in this case – it turns out that twenty minutes earlier, the user had received a “legitimate” e-card email from a friend (they’d had several of these in the past without incident). When the malicious e-card email came in, the user was still in happy-e-card-land and clicked the link without giving it a second thought. FAIL #2
- The user’s attempt to download the e-card executable was permitted, despite the presence of the URL filter. This was because the URL was “uncategorised” at the time, and the manufacturer’s default policy in this case is to allow the download. FAIL #3
- The firewall isn’t designed to stop anything in these circumstances. As such, we’ll call this MOOT #1
- The IDS didn’t say anything either, because it has no signature to match what is going on. FAIL #4
- The e-card executable was downloaded and saved to the user’s machine and subsequently run. AV did nothing to intervene. FAIL #5
- Because the user ran the executable by choice, there was no need to exploit any vulnerabilities in our fully-patched Windows victim. MOOT #2
That’s five fails and two moots, which I reckon accounts for all seven of our defences. Oh well. Once again, the hot knife of malware scythes through the butter of prevention.
On to the second question – did the infected machine download or upload anything else? From an examination of the network session and URL filter logs, we can see that everything looks OK so far. We will assume, however, that Spybot/Ad-Aware/etc have missed something in their cleanup, and we’ll put the victim machine on the “watch list” for a week or two. If there’s any dormant undetected malware there (like a keylogger that uploads once a week or something), we’ll spot it.
Using what we learned, the following was done to shore up the defences:
- The URL filter was changed away from its default policy in order to make it block uncategorised sites. This would have prevented the e-card download
- The “Digital Postcards” category of websites was blocked as a matter of corporate policy. Having seen a blockpage instead of the “legitimate” e-card from a friend, the user would have hopefully remembered their training and not clicked the link in the malicious email
- A temporary band-aid was applied to the spam filter to block all emails containing “/e-card.exe”
Of course, these are just more preventative measures, none of which are foolproof. That said, any one of them would have increased our chance of keeping the infection out in this case.
Defences will let you down from time to time, and for me at least, the “clean the malware and carry on” approach isn’t enough. If there’s a chink in the armour, I need to know where it is and what I can do about it – this is where NSM can help.
Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk