AD Recycle Bin group abuse

The Active Directory Recycle Bin is a feature that, when enabled, keeps deleted objects (users, computers, groups) along with all their attributes for a while (the msDS-deletedObjectLifetime, 180 days by default), so they can be restored. Members of the AD Recycle Bin group can read and recover those deleted objects.

The abuse is textbook: a deleted object keeps sensitive attributes normally hidden, and if an account we control belongs to that group, we can query them. The typical case is a temporary admin account created and later deleted, whose password is still stored in an attribute (a cascadeLegacyPwd, something written in info or description, etc.).

Mechanism

First confirm membership in the group (that is why we have access to the bin):

Get-ADGroupMember -Identity "AD Recycle Bin"
whoami /groups | findstr /i "Recycle"

The key query lists the deleted objects in the CN=Deleted Objects container with all their attributes:

Get-ADObject -Filter 'isDeleted -eq $true -and name -ne "Deleted Objects"' -IncludeDeletedObjects -Properties *
# narrow to a specific user and show only the juicy fields
Get-ADObject -Filter 'samAccountName -eq "TempAdmin"' -IncludeDeletedObjects -Properties * |
  select samAccountName,description,info,cascadeLegacyPwd,lastKnownParent

Finding the interesting deleted user (for example a TempAdmin) recovers the password it carried when it was deleted. If that account reused a privileged user's password, the jump to Administrator is direct. If instead of reading an attribute you want to restore the object (to reactivate an account and its group memberships), you do it with:

Restore-ADObject -Identity <objectGUID>

Requirements

The AD Recycle Bin enabled (it is not by default on old domains) and an account belonging to the AD Recycle Bin group or with read permissions over CN=Deleted Objects. The value depends on someone having deleted an object with a reusable secret inside.

How to detect it. Reading deleted objects is an LDAP query against the CN=Deleted Objects container; with directory access auditing enabled, it leaves Event ID 4662 (an operation was performed on an object) over that container by an account that does not manage restorations. Enumerating all deleted objects at once (a sweep with Get-ADObject -IncludeDeletedObjects) is the signature versus a one-off legitimate restore. A real restore (Restore-ADObject) also generates a 5136/4741/4720 depending on the type of object reactivated. Watching membership of the AD Recycle Bin group (a 4728/4732 when a member is added) catches the abuse before it is used.

Defence. Treat the AD Recycle Bin group as a privileged group (its membership must be minimal and audited), do not store secrets in object attributes, and never reuse a privileged account's password in temporary accounts that are later deleted (deletion does not remove the attribute from the bin). It connects to credential reuse and ACL abuse.