You can dump the local cached hashes, take a domain admins, and use a pass the hash attack, which has been around for a while, such as: Hernan Ochoa / http://oss.coresecurity.com/projects/pshtoolkit.htm
I don't see this being any more concerning. Whatever you do in the above, is under the other account. Granted, I may be missing something, so enlighten me. > -----Original Message----- > From: Mike Hale [mailto:eyeronic.des...@gmail.com] > Sent: Thursday, December 09, 2010 7:20 PM > To: Thor (Hammer of God) > Cc: stenopla...@exploitdevelopment.com; full-disclosure@lists.grok.org.uk > Subject: Re: [Full-disclosure] Flaw in Microsoft Domain Account Caching > Allows Local Workstation Admins to Temporarily Escalate Privileges and Login > as Cached Domain Admin Accounts (2010-M$-002) > > "In fact, I can just make the Domain Admin a "guest" on my workstation if I > want to and there is nothing they can do about it." > With the caveat that they can readd themselves using GP anytime they > want...but you know. I just wanted to throw that out there. > > I think the key vulnerability in this is the non-repudiation one the OP > mentioned. Being able to run stuff under the domain admin's account is > something a rogue user could potential abuse. > > I don't think this issue is particularly critical, but something a good > admin should be aware of, IMO. > > On Thu, Dec 9, 2010 at 7:07 PM, Thor (Hammer of God) <t...@hammerofgod.com> > wrote: > > What do you mean by "regular local administrator"? You're a local admin, > or you're not. There are not degrees of local admin. Why are you under the > impression that there are things on a local system that the local admin > should not have access to? They can do anything they want to by design. > Are you under the impression that the Domain Administrator has different > permissions on a local machine than the local administrator does? The only > reason a Domain Admin has admin rights by default on a domain workstation is > because they simply belong to the local Administrators group. If I, as a > local admin, remove the domain admin account from my local Administrators > group, then they will not be local admins. In fact, I can just make the > Domain Admin a "guest" on my workstation if I want to and there is nothing > they can do about it. > > > > Sorry to be the bearer of bad news for you, but the local admin can do > what they want to by design, and there is nothing that was "not intended by > the software developer" here. This is, of course, why the people at MSFT > dismissed it as noted. > > > > t > > > > -----Original Message----- > > From: StenoPlasma @ ExploitDevelopment > > [mailto:stenopla...@exploitdevelopment.com] > > Sent: Thursday, December 09, 2010 6:13 PM > > To: Thor (Hammer of God); full-disclosure@lists.grok.org.uk > > Subject: RE: [Full-disclosure] Flaw in Microsoft Domain Account > > Caching Allows Local Workstation Admins to Temporarily Escalate > > Privileges and Login as Cached Domain Admin Accounts (2010-M$-002) > > > > T, > > > > My article describes how to use the SECURITY registry hive to trick the > Microsoft operating system in to performing an action that has a result that > is not intended by the software developer. This action is performed on the > Active Directory logon account cache that regular local administrators > should not have access to. There are always other ways of doing things when > it comes to this type of work. > > > > > > Thank you, > > > > ----------------------------------------------------- > > StenoPlasma at ExploitDevelopment.com > > www.ExploitDevelopment.com > > ----------------------------------------------------- > > > > -------- Original Message -------- > >> From: "Thor (Hammer of God)" <t...@hammerofgod.com> > >> Sent: Thursday, December 09, 2010 6:07 PM > >> To: "stenopla...@exploitdevelopment.com" > > <stenopla...@exploitdevelopment.com>, "full-disclosure@lists.grok.org.uk > " > > <full-disclosure@lists.grok.org.uk> > >> Subject: RE: [Full-disclosure] Flaw in Microsoft Domain Account > >> Caching > > Allows Local Workstation Admins to Temporarily Escalate Privileges and > > Login as Cached Domain Admin Accounts (2010-M$-002) > >> > >> Why all the trouble? Just change the log files directly when logged > >> in > > as the local admin. It's a whole lot simpler, and you don't even need > the domain administrator to have interactively logged into your workstation. > > Or is your point that local administrators are, um, local administrators? > >> > >> t > >> > >> >-----Original Message----- > >> >From: full-disclosure-boun...@lists.grok.org.uk > > [mailto:full-disclosure- > >> >boun...@lists.grok.org.uk] On Behalf Of StenoPlasma @ > >> >www.ExploitDevelopment.com > >> >Sent: Thursday, December 09, 2010 5:07 PM > >> >To: bugt...@securityfocus.com; full-disclosure@lists.grok.org.uk > >> >Cc: stenopla...@exploitdevelopment.com > >> >Subject: [Full-disclosure] Flaw in Microsoft Domain Account Caching > > Allows > >> >Local Workstation Admins to Temporarily Escalate Privileges and > >> >Login > > as > >> >Cached Domain Admin Accounts (2010-M$-002) > >> > > >> > >>---------------------------------------------------------------------- > >>- > >>--- > > > > > >> >www.ExploitDevelopment.com 2010-M$-002 > >> > >>---------------------------------------------------------------------- > >>- > >>--- > > > > > >> > > >> >TITLE: > >> >Flaw in Microsoft Domain Account Caching Allows Local Workstation > >> >Admins > > to > >> >Temporarily Escalate Privileges and Login as Cached Domain Admin > > Accounts > >> > > >> >SUMMARY AND IMPACT: > >> >All versions of Microsoft Windows operating systems allow real-time > >> >modifications to the Active Directory cached accounts listing stored > >> >on > > all > >> >Active Directory domain workstations and servers. This allows domain > > users > >> >that have local administrator privileges on domain assets to modify > > their > >> >cached accounts to masquerade as other domain users that have logged > >> >in > > to > >> >those domain assets. This will allow local administrators to > > temporarily > >> >escalate their domain privileges on domain workstations or servers. > >> >If > > the local > >> >administrator masquerades as an Active Directory Domain Admin > >> >account, > > the > >> >modified cached account is now free to modify system files and user > > account > >> >profiles using the identity of the Domain Admin's account. This > > includes > >> >creating scripts to run as the Domain Admin account the next time > >> >that > > they > >> >log in. All files created will not be linked to your domain account > >> >in > > file and > >> >folder access lists. All security access lists will only show the > >> >Domain > > Admin's > >> >account once you log out of the modified cached account. This leads > >> >to > > a > >> >number of security issues that I will not attempt to identify in the > > article. One > >> >major issue is the lack of non-repudiation. Editing files and other > > actions will > >> >be completed as another user account. Event log entries for object > > access will > >> >only be created if administrators are auditing successful access to > > files (This > >> >will lead to enormous event log sizes). > >> > > >> >DETAILS: > >> >Prerequisites to exploit: > >> > > >> >#1: The user has a "Domain User" account that has administrative > > privileges on > >> >his/her workstation (This is a common configuration for both small > >> >and enterprise networks). > >> >#2: The Microsoft Windows Active Directory domain has not disabled > >> >the > > use > >> >of Group Policy "Interactive logon: Number of previous logons to > >> >cache > > (in > >> >case domain controller is not available)". The default value for > >> >this > > setting is > >> >"10 logons". > >> >#3: A domain/enterprise/schema/privileged administrator has logged > >> >in to > > the > >> >user's workstation at any time in the past (It would be very > >> >difficult > > to not > >> >have some type of admin from the domain login to a workstation for a > >> >number of reasons). > >> > > >> >Use the following steps to exploit this vulnerability: > >> > > >> >Step 1: Log in to your workstation using your Active Directory > >> >domain > > account. > >> >This account only needs to have administrative access to your > > workstation. > >> >Step 2: Create an interactive scheduled task to run a minute after > > creating it. > >> >This scheduled task brings up a command prompt as the NT > > Authority\SYSTEM > >> >account on Windows XP, and 2003. 'at 11:24 /interactive cmd.exe'. If > > using > >> >Windows Vista, 7, or 2008 Server, the attacker can use the psexec > >> >tool > > (psexec > >> >-i -s cmd.exe). > >> >Step 3: Once the SYSTEM command prompt comes up, open regedit from > >> >the command line. > >> >Step 4: Browse to 'HKEY_LOCAL_MACHINE\SECURITY\Cache' > >> >Step 5: The list of "NL$1-10" records contain the cached active > > directory > >> >domain account sessions. To identify which account is yours, perform > > the > >> >following steps. Take note of all NL$ entries and entry content. > >> >Change > > your > >> >domain account password. Leave the SYSTEM shell and regedit > >> >application open. Log off the workstation, and then log back in to > >> >your domain > > account. > >> >Refresh the NL$ list. The NL$ line item that has been updated is > >> >your > > domain > >> >user's cached session. > >> >Step 6: For this example, we will assume that your NL$ record is "NL$4" > >> >Step 7: Double click on "NL$4". Take note of the four hex characters > > that are > >> >located in positions 1, 2, 3, and 4 on line 3 of the hex data. > >> >Step 8: For this example, the hex characters are "5a 04". This > >> >number is > > the > >> >Active Directory octet string representation of your domain > >> >account's objectSID (The user account unique section of your AD > >> >Security > > Identifier). > >> >Step 9: For this example, there is only one other cached account > >> >listed > > in the > >> >NL$ listing (NL$3). Double click on "NL$3". Take note of the four > >> >hex > > characters > >> >that are located in positions 1, 2, 3, and 4 on line 3 of the hex data. > >> >Step 10: For this example, the hex characters are "59 04". This user > > account is > >> >"Domain\DomainAdminAcct". > >> >Step 11: Double click on "NL$4". Replace your SID hex representation > >> >"5a > > 04", > >> >with DomainAdminAcct's SID hex representation "59 04". > >> >Step 12: *Important* Disconnect all physical network connections > >> >from > > the > >> >workstation. > >> >Step 13: Log off of the domain account, then log back in to your > >> >domain account. > >> >Step 14: You will now be logged in to your modified cached account > >> >that > > is > >> >really the Domain Admin's account. > >> >Step 15: You are now free to modify system files and user account > > profiles > >> >using the identity of the Domain Admin's account. This includes > > creating > >> >scripts to run as the Domain Admin account the next time that they > >> >log > > in. All > >> >files created will not be linked to your domain account. All > >> >security > > access lists > >> >will only show the Domain Admin's account once you log out of the > > modified > >> >cached account. > >> >Step 16: All actions taken are indeed logged in the Security Event > >> >Log, > > but all > >> >actions are shown as being completed by "Domain\DomainAdminAcct". > >> >Deeper inspection of event logs will show inside the login and > >> >logout > > events > >> >for your modified cached account, your actual user name is listed > >> >inside > > the > >> >event, but not in the Security Event Log Viewer listing. Event log > > entries for > >> >object access will only be created if administrators are auditing > > successful > >> >access to files (This will lead to enormous event log sizes). These > > events will > >> >be listed as being performed as "Domain\DomainAdminAcct" in the > >> >event > > log > >> >viewer, but deeper inspection will show your true user name. > >> > > >> >VULNERABLE PRODUCTS: > >> >All patch levels of Windows 2003 Server, Windows XP, Windows Vista, > >> >Windows 7, and Windows 2008 Server. > >> > > >> >REFERENCES AND ADDITIONAL INFORMATION: > >> >N/A > >> > > >> >CREDITS: > >> >StenoPlasma (at) ExploitDevelopment.com > >> > > >> >TIMELINE: > >> >Discovery: December 4, 2010 > >> >Vendor Notified: December 7, 2010 > >> >Vendor Fixed: N/A > >> >Vendor Dismissed: December 9, 2010 > >> >Vendor Notified of Disclosure: December 9, 2010 > >> >Disclosed: December 9, 2010 > >> > > >> >VENDOR URL: > >> >http://www.microsoft.com > >> > > >> >ADVISORY URL: > >> >http://www.ExploitDevelopment.com/Vulnerabilities/2010-M$-002.html > >> > > >> >VENDOR ADVISORY URL: > >> >N/A > >> > > >> > > >> >------------------------------------------------------------- > >> >StenoPlasma at ExploitDevelopment.com www.ExploitDevelopment.com > >> >------------------------------------------------------------- > >> > > >> >_______________________________________________ > >> >Full-Disclosure - We believe in it. > >> >Charter: http://lists.grok.org.uk/full-disclosure-charter.html > >> >Hosted and sponsored by Secunia - http://secunia.com/ > > > > > > > > _______________________________________________ > > Full-Disclosure - We believe in it. > > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > > Hosted and sponsored by Secunia - http://secunia.com/ > > > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/