On Thu, Oct 22, 2009 at 7:55 AM, James Rankin <[email protected]> wrote: > http://securitytube.net/How-to-own-a-Windows-Domain-video.aspx
ANALYSIS The way I interpret the procedure is: P1. Use physical access to compromise local machine P2. Brute force the password to the local machine's local admin account P3. Assume that password is the same on other machines P4. Use local machine admin password to login to another machine via network P5. Wait for a domain admin logon on remote machine (or look for cached creds) P6. Brute force the domain admin password Notes: N1. Brute forcing is not visible in log because it's done against the LM hash directly, rather than hitting the authentication subsystem. N2. If an org has a domain account which has admin rights on workstations (but not servers/domain), it could also be used for P2 and P4. N3. Ultimately, nothing new; just an application of existing mechanisms. COUNTERMEASURES C1. Physical security. C2. Disable booting from anything but local hard disk, and password protect BIOS setup. C3. Don't use same local admin account password everywhere. Also, don't use a simple formulaic method (e.g., "add 42 to asset tag") to vary them. C4. Disable local admin account. N4. We used to do C4, but it sucked when something broke domain logon. Then you couldn't get in to fix it without a password reset disk and some SAM editing. Now we do random local admin passwords. N5. Neither C3 nor C4 will defend against N2. C5. Don't login to potential P1 machines with any password exchange. N6. For example, RDP sends the password to the remote machine, so you have the C5 vulnerability. Same for local console. But RPC stuff uses Kerberos, so no password is exchanged. C6. Don't login to potential P4 machines with domain admin credentials. C7. Deny network logon for admin accounts used with P1 machines. N7. With C7, you loose remote admin capabilities. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
