mailing list archives
RE: Flaw in Microsoft Domain Account Caching Allows Local Workstation Admins to Temporarily Escalate Privileges and Login as Cached Domain Admin Accounts (2010-M$-002)
From: "George Carlson" <gcarlson () vccs edu>
Date: Fri, 10 Dec 2010 13:12:12 -0500
Your objections are mostly true in a normal sense. However, it is not
true when Group Policy is taken into account. Group Policies
differentiate between local and Domain administrators and so this
vulnerability is problematic for shops that differentiate between
desktop support and AD support.
Sr. Network Engineer
From: Stefan Kanthak [mailto:stefan.kanthak () nexgo de]
Sent: Friday, December 10, 2010 11:30 AM
To: bugtraq () securityfocus com; full-disclosure () lists grok org uk
Cc: stenoplasma () exploitdevelopment com
Subject: Re: Flaw in Microsoft Domain Account Caching Allows Local
Workstation Admins to Temporarily Escalate Privileges and Login as
Cached Domain Admin Accounts (2010-M$-002)
"StenoPlasma @ www.ExploitDevelopment.com" wrote:
Much ado about nothing!
Flaw in Microsoft Domain Account Caching Allows Local Workstation
Admins to Temporarily Escalate Privileges and Login as Cached Domain
There is NO privilege escalation. A local administrator is an
is an administrator...
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.
Wrong. The local administrator is already local administrator. There's
nothing the elevate any more.
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.
There is no need to masquerade: the local administrator can perform all
these modifications, and if s/he wishes, hide the tracks: turn off
auditing before, clear audit/event logs afterwards, change the SID in
the ACEs of all objects touched (SubInACL.Exe comes handy), ...
Or: just change the "NoDefaultAdminOwner" setting. After that, all
"Administrators" masquerade as "Administrators". uh-oh.
creating scripts to run as the Domain Admin account the next time that
they log in.
A local administrator can add any script/executable s/he wants to any
"autostart" (scheduled task, registry, logon script, userinit, shell,
There's ABSOLUTELY no need to masquerade.
All files created will not be linked to your domain
account in file and folder access lists.
ACEs can always be edited by a local administrator, see SubInACL.Exe,
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).
A local administrator can turn audit/event logs off, clear or modify