Friday, August 29, 2014

It's not Always "Either-Or"

It is often possible to narrow a given intrusion or breach down to a single event or vulnerability that caused it. However, this is not always the case. In fact, as any penetration tester can tell you, almost any far-reaching breach must leverage multiple avenues of discovery and attack in order to be successful.

This popped into my head while reading about the Community Health Systems Inc. (CHS) breach. One particular article asked a question that I think is frequently asked by which flies in the face of the fact that most breaches are inherently multi-faceted.

Near the end of the article, the author asks: "Attack Vector – Spear Phishing or Heartbleed?" He points out that there are conflicting reports as to the root of the CHS intrusion. The FBI seems to indicate it came from spearphishing, while other reports implicate the Heartbleed bug on a Juniper router as the root cause.

But why need it be just one or the other? The article says that the breach revolved around malware running on a Windows machine and set up to run as a service. Well, that wasn't done via Heartbleed, was it? Heartbleed is (almost) exclusively a confidentiality risk, which can be exploited to expose information to which the person exploiting the bug was not intended to have access. A huge variety of information, but still just information disclosure. That disclosure might include, however, usernames, passwords, or password hashes on the system which was exploited. These credentials could possibly be used to directly gain access to that device (if a management interface was enabled that was facing the Internet), or they could be used internally (either directly or by seeding a dictionary attack) against other hosts that might have been accessed in an entirely different way. Such as... the aforementioned spearphishing!

So there's one example of a three-step breach: a) gain admin user's credentials off a router/firewall via Heartbleed, b) spearphish a user to get a RAT running on their machine, and c) use the known privileged credentials to elevate privileges on that machine (or another). Extra cleverness points for using the credentials again on the router/firewall once you're inside to access the admin interface and alter any rules or logs that might block or detect your C2 mechanism.

Lesson in a nutshell: never assume that a given intrusion is has a single "root cause." Root cause analysis is important, but keep in mind that things can have more than one root.

No comments:

Post a Comment