Advanced Persistent Threats - Blame It On REO

Sunday, April 10, 2011

J. Oquendo


With the cat out of the bag, I can now re-state what I have said all along: "Nothing to see here move along..." when it comes down to the Advanced Persistent Threat.

Ultimately I feel that these APTs all boil down to "Recurringly Easy Ownage" - REO. Blame it on REO. Humor aside, I feel the need to re-visit this theme in hopes to raise security awareness to even those who claim to be experienced.

ARS Technica has a write up on this [1], so here goes my take:

"A spear-phishing e-mail was sent to two small groups within the company. Though the e-mail was automatically marked as Junk, the subject of the message ("2011 Recruitment Plan") tricked one employee into opening it anyway. Attached to the mail was an Excel spreadsheet, "2011 Recruitment plan.xls". Embedded within the spreadsheet was a Flash movie that exploited a Flash vulnerability. Adobe has since released an emergency patch for the flaw."

Rinse and repeat time. I mentioned this before, it is more embarrassing to state "we goofed internally" as opposed to stating something sexy like: "hackers got us... they were so advanced, they were using advanced threats."

Reality is, RATs are nothing new in fact, Poison Ivy is rather old.  "The Flash movie's payload in turn installed a modified version of Poison Ivy. Poison Ivy is known as a RAT, a Remote Administration/Access Tool/Toolkit/Trojan."

There is a high likelihood that most companies touting the "APT" theme have all been compromised in similar fashion. Personally, its nice to know "how" the attack took place (client side) versus the speculation that something truly "advanced" was lurking on the Internet. Kudos to RSA for giving us the information they did.

This is not to downplay the sophistication of the "payload" (the application compromised), I am sure there is a lot of sophistication in the getURL function of Flash, although that too is nothing new either.

The RSA compromise should also become sort of an eye opener on how a very old (Poison Ivy) yet "modified" attack tool managed to run in an enterprise environment. RSA's wording leads me to believe that either

a) RSA's antivirus/antimalware software is or was out of date

b) is or was not running

c) is or was not capable of detecting modifications (obvious).

Therein lies another issue, the realistic protection capabilities of antivirus and antimalware software: They are not the all-encompassing protection tools that too many people have relied upon. AV and AntiMalware are something that has just been marketed to us repeatedly as the all-inclusive. Again, not to say it doesn't work, just to say that it is not all that cracked up slash marketed to be.

Malware and virus analysis is way beyond explaining here, but those in the field will know and will likely chuckle at how simple it is to take an existing, well known piece of malware, make one or two (non-sophisticated) changes and re-use that malware. There is no method that a "signature based" malware or antivirus software being able to detect what an attacker will do, there is no heuristic based software capable of thinking on how a human thinks.

Now, for those who took Lenny Zeltser's excellent GREM VLive [2] course with me in February of this year, if by chance you stumble upon this writing, your eyebrow might be raised as some may recall that I expounded on "just how dangerous" Flash can be, to Michael Murr on I believe it was day three; "As an attacker, I don't even need you to interact with anything, I just need you to see it."

This is not a new "security voodoo slash mojo" slash advanced attack. On the contrary, the attackers were not all that advanced as they needed a two stage exploit, Flash inside of Excel. This could actually be accomplished across any HTML capable e-mail client with only Flash, extra staging not require. (shhh I promise I won't tell other hackers who also know this trick).

Now this article may come across like like an "I told you so," arrogant rant, I assure you that I in no way, mean for my writing to come across as such but more of a "geez, don't you get it by now?"

So counter remedy? It is simple, and I seriously mean this, simple. The reality is, an attacker compromised a machine, this will happen, persistently. It is the only truthful explanation of anything associated with the acronym APT, the rest is all marketing.

So we can establish factually that we can never stop an attacker from trying to compromise us, it is out of our control, however, this does not mean that we cannot stop connections from leaving that machine. After all, controlling what leaves a machine will always be more important than what is coming INTO a machine.

There are no ifs, ands, or buts to the last sentence above via way of control. You can never stop someone from trying to compromise a machine (please repeat this until it sinks in). You can however, stop your machine from speaking to parties it should not be speaking to.

Stop your machines from opening OUTGOING ports, MONITOR what is leaving your network. This, is what is under your control, not the opposite (what an attacker does or is trying to do). Fixes like these (inverse/EXTRUSION detection and reporting) are simple however, enterprise security managers will say differently.

Had an SIEM been in place reporting on anomalous OUTBOUND connections, it is likely that the SIEM would have not only caught it and alerted someone, but depending on who the vendor of the SIEM was, it could have prevented the incident as well.

Hell, even a simple expect script would have nipped this in the butt. Security professionals need to take a new approach or at least think of a sexier term as APT is now REO.



Nothing to see here


Possibly Related Articles:
Information Security
Antivirus RSA malware SIEM Advanced Persistent Threats REO
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.