Lateral Movement: There’s No Patch for Privilege Escalation
In the soft underbelly of IT security I discussed what Sanjay Tandon of Paramount Defense calls the “#1 cybersecurity risk,” or privilege escalation. However, sometime after finishing the post, I realized that I hadn’t emphasized sufficiently the following key point:
Once inside an enterprise account, hackers don’t need domain administrator access. They can still use Active Directory to gather intelligence and move laterally through the IT administrative hierarchy to access their target.
The subtle point here is that while domain administrator accounts at the top of the administrative hierarchy may be heavily protected, the rest of the IT environment is not typically hardened to the same level. Once attackers compromise an endpoint device – something that’s fairly easily done given what Bruce Schneire calls “the terrible state of endpoint security” and which I also wrote about in trust no one (device) – they can gain get access to that user’s domain account surreptitiously using a keylogger or other spyware technologies. Of course, if the attacker is already an employee or contractor at the organization, he or she already has an account.
Anyone with a domain account can perform read operations against Active Directory to discover target accounts and delegated administrators of those accounts, and then “move laterally” by compromising the credentials (using a phishing technique) or the computer of that delegated admin. Once there, the attacker can reset the password of the desired account and gain access to it. (For a detailed example, see the CFO link below.)
Sanjay Tandon illustrated a few examples of possible attacks:
Financial fraud: “Let’s say you wanted to compromise the Chief Financial Officer (CFO’s) account to access the Earnings Statement (to which he definitely has access). You only need to find out who can reset the CFO’s password, then iterate the process over those individuals until you find a delegated admin / IT guy sitting down the hall from you, and to whose computer you have physical access. Then, you’re just a few password resets away from being the CFO (for a few minutes), at which point, the amount of damage you can do (financially) is huge.”
Deny service, or distract the IT security department to cover another attack: “Let’s say you wanted to DOS out an internal LOB running on a group of servers. Simply find out who can link Group Policy Objects (GPOs) to the OUs/Site in which the computer account of those LOBs reside, then determine who can reset their passwords, iterate a few times, and you’re a few minutes from being able to create and link a GPO that is being sent down to each of these servers, which can then be made to control whatever you like on those machines, including preventing a specific service from starting.”
Thus, any user account (say the CFO’s), or any database or application that can be accessed through Active Directory single sign on is vulnerable to this sort of lateral movement and privilege escalation. There’s no patch for it because it’s not a code vulnerability per se. It’s a vulnerability that’s built into the system design of Active Directory management single sign on in the Windows environment. That’s why I called it the “soft underbelly.” Once a hacker is through the hard shell of the enterprise firewall, or the thin skin of endpoint security, he or she can escalate privileges moving laterally through the IT hierarchies reflecting larger networks of working relationships within the organization.
Why does this weakness exist? If you look at other enterprise directory, security and management systems I think you’ll find its not unique to Active Directory. I believe that “soft administrative underbellies” are endemic to IT as product of organic growth of multiple vendor’s systems, developer’s applications and administrative arrangements. After building large IT environments over time in a more or less unplanned manner, organizations buy ingenious centralized management and security systems to connect them all together.
Unfortunately, centralized management and security systems like Active Directory have their own systemic vulnerability in that they become grand central station for all IT operations. They furnish millions of essentially unauditable read operations and host thousands of access control lists and security groups. Whenever someone wants to get access to a managed resource, they have to go the directory or management configuration to open up another path to productivity. And once established, groups or configuration settings are rarely cleaned up after they’re no longer needed. If there was once an IT security policy, or architecture, that was supposed to define a strict administrative process, all too often the real environment drifts away from it. Thus, even if only the CFO has access to the earning statement, some admin group has access to the CFO’s account in the directory and another admin group has access to the server where the earnings statement lives. Any of those admins can reset the CFO’s password; thus, tens or hundreds of people may have EFFECTIVE (or lateral) access to any given resource.
This IT vulnerability to lateral movement and privilege escalation is almost like a law of nature for humans in large groups or organizations. The following reiterates and improves some general recommendations from my earlier post:
- Follow a Systematic, Comprehensive Approach to Security, and – since one of the points of this post is that you can’t really secure anything very well unless you can first manage it – strive for a coherent enterprise architecture, and technical IT architecture. These are the catch-all recommendation to armor the whole belly and body of the enterprise with a minimum of weak links.
- Separate the most sensitive IT resources from the rest of the body, as I recommended in Restricted Zones Redux.
- Vigorously protect privileged accounts, whether for people such as domain administrators, or network service and management interfaces. In some cases, organizations deploy privileged identity management solutions such as Lieberman Software, or password vaulting solutions for maximum hardening of these accounts.
- For Active Directory specifically, take a good look through the links in this post and Sanjay Tandon’s Active Directory Security blog. After you’ve established your desired administration procedures through security and operations policy – including a reasonable change management approach – Sanjay’s Active Directory audit products could help you monitor on a continuous basis whether those tightened policies remain in effect, or have drifted.
Do you have other ideas, such as how better security at scale can be built in by design or achieved after the fact? Comments encouraged!