Thursday, March 8, 2012

Remotely connecting to a compromised machine is almost always a bad idea because of the tremendous amount of risk involved. It has been my experience that incident responders either underestimate or downplay that risk when writing procedures or handling incidents. I don't know whether its arrogance or ignorance, but either way the team I am on has frequently exploited it. Often times, escalating privileges in a domain is just a matter of waiting for an administrator (or incident responder) to connect to a machine that you've compromised and then impersonating those credentials to dump the hashes of the entire domain (including the responder's account).

Recently, a detailed article written by Mike Pilkington titled "Protecting Privileged Domain Accounts: Safeguarding Password Hashes" was published on the SANS Forensics Blog (I recommend that you read it before continuing). The article focuses on ways of protecting domain (NT or LM) password hashes (in memory) and briefly mentions other topics that will be discussed in future articles including Access Tokens and Network Authentication. The methodology used in the article is pretty solid and it was detailed enough for me to setup a similar lab network and recreate the work. However, I feel that the focus on hashes leads the reader to several false conclusions the most notable being that "Network Logins" are safe.

Here are 3 quotes that I feel lead the reader toward an inaccurate conclusion:

"...in all situations I can think of, the safest bet is to utilize a local administrative account if you already know the password."

"Network logons created by tools such as NET USE, WMIC, and PsExec (without "-u" alternate credentials) are safe to use with regard to protecting password hashes. (emphasis is mine) More to the point, any tool that uses only a network logon will prevent your password hashes from being available on the remote machine. To check other tools on your own, simply run the tool of interest against a remote test machine and verify in the remote Windows Event Logs that the tool only results in a Type 3 network logon."

"Also keep in mind, whether the compromised host is down the hall or on the other side of the world, using remote network logon connections is the only way to safely access the host with domain credentials."

This post is going to focus on the first misconception that local accounts are safer to use. For brevity’s sake, I will discuss what I feel are other misconceptions in the next post (UPDATE: Mike touches on a those issues in his latest post Safeguarding Access Tokens so I won't belabor the point.)

The first quote is mostly accurate if we are appropriately using the "worst-case" scenario. In the example used in the article, the attacker has most likely gained "NT AUTHORITY/SYSTEM"-level privileges on the box. That means the attacker has already gained access to the NT (or LM) hashes of all local accounts by any of the methods discussed in the article. Essentially, we are using an account that the attacker likely already owns.

What if we have detected the attack early and the attacker only has user-level credentials as a result of a client-side attack? What if the attacker hasn't had the opportunity to try these methods of gaining more privilege? Let's see what could happen if we use the local administrator account to investigate.

Soon after compromising the box with a meterpreter session, the attacker loads the sniffer extension and sniffs the network. The incident responder uses the local administrator account and "net use" to mount a share to the compromised box and investigates with PsExec.

Next, the attacker analyzes the PCAP for credentials. An easy way to pull credentials from a PCAP is to use Cain. Cain displays the NTLM Session Security Hashes which would need to be cracked in order to be useful to the attacker.

As pointed out in the referenced blog post, PsExec passes the username and password in cleartext so that will always be a bad idea. Instead, PowerShell or WMIC should be used to prevent the credentials from being snagged off the wire in cleartext.

So now the attacker has access to the local "500 account" NTLM session security hash. This hash can't be passed (it is not the NT hash), but it can be cracked. If it is cracked, the password is more than likely shared by the administrator account on many other workstations. Now the scenario appears to have changed to a race condition. Can the attacker crack the password before you can remove his or her access? Unfortunately, that argument is also shortsighted. The attacker can voluntarily disconnect and can take as long as it takes for you to change every workstation's administrator password.

The odds are in the attackers favor if the password is stored in LM or the attacker has discovered a pattern similar to the one used to set the password. Then, the only thing stopping the attacker is getting back in through a similar client-side attack no matter what you do with the compromised host. Then the attacker can use WMIC to "administer" any machine that is using the password which is a situation far worse than a single compromised host.

Also, it is generally easier to track the use of domain account versus a local account. Very few organizations have the ability to quickly (without connecting to each host) correlate local account usage through the event log.

In this case, the attacker was able to crack the password with his dictionary and Cain. In my experience, it's just over half the time that we are able to crack the password. The odds are in the attackers favor whether the account is local or domain.

My argument is that a tailored-access domain account is more appropriate. I recommend that the account used for risky activity should be low-privileged and heavily-monitored. The account can be disabled and a member of no groups until needed. When needed, the account can be enabled and added to the lowest-privileged group that can still administer the potentially-compromised box. Although there is still a tremendous amount of risk, it can be slightly mitigated by immediately changing the password of the account (rendering access tokens unusable) and disabling it after initial analysis is done.

This concept can be applied to most administrative and security tasks in order to prevent an excess of elevated account "access tokens" which I may still talk about in my next post. We'll see.

In addition to monthly blog posts, I am hoping to add other content to the site that you might find useful. So far, I have added a "Recommended Books" page and a "Recommended Links" page. My plan for now is to continue to add content to both pages regularly.

The books section is pretty self-explanatory, but the links page contains links to tutorials, technical posts and opinion articles that I reference or frequently use. Both sections will contain short reviews of the material and I am open to suggestions for new content.