Why Whitelisting Would Stop Operation Shady RAT

Over a period of many years, hackers intruded into more than 70 large organizations around the world in a campaign McAfee dubbed Operation Shady RAT. It has garnered many a sensational headline, but the actual hacks involved are more typical than sensational, and they are the type that would have been stopped by a well-implemented whitelisting system.

RAT in this case stands for Remote Access Tool, since it provides the attackers with remote access to the systems on the compromised network.  Shady RAT got a lot of press as more evidence of how scandalously open to attack large organizations are, and there’s something to the story. 

21 governmental organizations, mostly US but also Canada, Vietnam, Taiwan, India and a host of international organizations from the UN to ASEAN were bit by the RAT. Defense contractors and other heavy industry were also victims, as was news media and one (and this is embarrassing) network security firm. McAfee identified very few of the actual targets.

The main reaction from experts has been to point out that there’s nothing especially sophisticated about how Shady RAT works. It doesn’t compare, in terms of innovation, to Stuxnet, the attack against Iranian nuclear installations, not that McAfee claimed RAT to be a sophisticated attack. Rather, Shady RAT shows how much you can accomplish using off-the-shelf malware and stock social engineering techniques.

McAfee didn’t describe the actual malware or entry attacks in any meaningful detail, but Symantec followed up to provide some of that information, and this is where whitelisting comes in.

Shady RAT’s foot in the door of the enterprise was a socially engineered spear phish e-mail with an attachment, usually an Excel file but sometimes a different format such as Adobe PDF. Spear phish e-mails, as you may know, are customized for the recipient, written directly to them from someone they know (spoofing the sender’s e-mail address, which is easy to do). A little bit of research on the company web site or – even better – on LinkedIn, will give you a lot of information about who works for the company, what their jobs are, who their immediate co-workers are and who they work for.

Armed with this information, attackers send the mark a message purportedly from their boss’s boss asking them to review the numbers in the attached spreadsheet. It’s good if they are fooled by the spreadsheet, but once they open the file it’s not strictly necessary for them to keep on believing because the spreadsheet exploits a vulnerability in Excel (or Acrobat or whatever the target is) that allows the attacker to run their own code.

Whitelisting, as I have written before, does not detect or block the exploitation of vulnerabilities in whitelisted applications, but in this case it probably doesn’t have to. The way these attacks work is for the actual exploit code to download and execute another malicious program. This is the way a lot of malware and vulnerability exploiting works; the initial attack is kept as simple as possible; it just downloads and transfers control to other programs which contain more of the “smarts” of the attack.

“Spear phishing” e-mails with malicious attachments sent get Shady RAT started inside an organization. Image courtesy of Symantec.

The second stage of the attack would have to get by the whitelisting system and it would have a hard time doing that. Both McAfee and Symantec, in their reports on Shady RAT, note that the malware is old and boring that they have protected against it for years. I would add that the vulnerabilities in Excel and Acrobat were almost certainly patched by Microsoft and Adobe long before Shady RAT came along to abuse them.  But companies defer patches and a lot of malware gets used in attacks before the AV vendors get around to protecting against it.

A highly-targeted attack could attempt to bypass the whitelisting system by attacking it somehow from within the initial exploit code. There probably are ways to do this, but they aren’t obvious and there’s no evidence that Shady RAT’s authors customized anything besides the initial attack e-mail.

The bottom line of all this supports defense-in-depth generally as much as it does whitelisting specifically, but whitelisting in this case provides one of the most solid layers in a defense-in-depth.

Users could be running as administrator with unpatched applications and out-of-date antivirus and whitelisting would still block the attack at an early stage. That’s a safety net worth using.