Shields up against Domain Escalation Worms

Internal networks are the core of the business activity. Resources should be available, shares must be reachable, and servers should expose a wide number of services that are used every day by employees. Enterprise officers usually agree that security components are easier to manage if they are centralized and that password rotation is also better achieved Single Sign On architectures are used. Active Directory is one of the most deployed and pervasive Single Sign On solutions with 40% Market Share in large organizations (Microsoft Custom Research Market Study, May 2004). Active Directory “using the same database, for use primarily in Windows environments, allows administrators to assign policies, deploy software, and apply critical updates to an organization” (Wikipedia).

Unfortunately Enterprise networks are still very vulnerable to attacks performed from the inside of the network. Skilled attackers leveraging multiple types of attacks can easily obtain access to most of the systems. Some of the techniques include: exploiting unpatched systems (more the services exposed, more the breaches), exploiting unpatched applications, performing layer 2 attacks and riding trust between systems. Things get worse if we consider that most of the previous attacks can be pursued by an automated program and not by a physical attacker. Worms are able to spread across networks in very subtle ways and can easily spread from the inside when a laptop gets infected. From such privileged position, it’s easier to further spread by exploiting vulnerabilities on unpatched systems as shown by the recent Downadup Worm (W32.Downadup Symantec Security Response).

Since Active Directory is fundamentally a centralized Single Sign On architecture that authenticates and authorizes resources using Kerberos, Active Directory creates implicit trusts between systems. Authenticated clients in possession of privileged access grants are able to access or to delegate their grants to other systems. Once a user is authenticated, he receives a session token signed by AD authority and he does not need to enter his credentials again.

Can Worms spread faster by exploiting the Active Directory trust model? Could a Worm impersonate other users to escalate privileges in an Active Directory environment?

A Domain Escalation attack takes places when a malicious user is able to extend his privileges on the Active Directory Domain. One of the most ingenious ways to accomplish this task is to impersonate another user that has a higher set of privileges by stealing his Active Directory token (or session). Luke Jennings from MWR Infosecurity in his brilliant paper describes all the details of this particular attack (MWR Infosecurity Delegation Token Security Explained).

Any task with Local Administrative privileges is able to grab the token from any process that has previously obtained a delegation. It’s easier to say that if your machine gets infected by a malicious piece of software, this software can get domain privileges by waiting that a remote system will use delegation remotely to perform any kind of operation. How long should it wait? Not, so long, considering that also WSUS service may use delegation while pushing updates and Remote Desktop uses it as well.

Example of Internal Spreading process:

• CEO’s Laptop get Infected by a Worm at the Airport;
• CEO’s after a week gets back to the headquarter and authenticates to Active Directory Domain;
• The worm start spreading on a limited number of systems using MS08-067 or 06-040 or similar publicly known exploits
• The worm reveals to be a Domain Escalation Worm and start monitoring the properties of the local processes on the compromised machines;
• When a new local process is created with a Delegation token of a domain user, the worm is able to steal that token and to impersonate the remote user
• The worm start spreading with the new obtained privileges

As it’s possible to see the combined usage of other spreading vectors increase the number of monitored systems and the chance to impersonate a highly privileged user (e.g. users that belongs to “Domain Administrator”, “Enterprise Administrator”, “Workstation Administrators” groups ).

Conclusions
Worms may use this technique to spread faster. The process could be easily automated, for targeting only privileged users of the Active Directory domain . If a Worm can then impersonate a Domain Administrator, via a Policy Deploy rule it can infect any machine in the network.