What an auditor want to make sure is that you have non-repudiation in place. This also applies to forensic work. You want to make sure you can track the activity to a person and to do that we need to first identify the user account. But what if it just has disappeared from Active Directory?
When an attacker gains privilege’s enough to create security principals , mainly user and group objects, it’s possible to do so in such a way that it’s really hard to identify once deleted. The reason is that the DC moves these objects right to /dev/null skipping the recycle bin and the tombstone state when deleting it. All that might be left is the trace of an unresolved SID.
This object type is called dynamic object and has been in AD DS since Windows Server 2003. Dynamic Object has a TTL that the creator set during the creation. The TTL is an associated time-to-live value in seconds that increment until it reach zero. A deleted dynamic object due to its TTL expiring does not leave a tombstone behind. The idea was to allow applications creating objects that would off-load the garbage collection services.
So basically the attacker can choose to have its temporarily user account exist for just a certain period of time (by default the minimum is 15 min but can be changed) .
After the TTL reached zero no traces can be found of the object…. No metadata .. Nothing..
Here’s the TTL ticking down on a user object:
You create an dynamic object by specifying that the object shall be of both dynamic objectClass and the other objectClass of choice.
This is all the necessary PowerShell code you need to create one:
[int]$intDynTTL = "15"
$intDynTTL = $intDynTTL * 60
$objDomain = New-Object System.DirectoryServices.DirectoryEntry("LDAP://OU=Accounts,DC=contoso,DC=com")
$objName = "DYNUSER1"
$objDyn = $objDomain.Create("user", "CN=" + $objName)
$objDyn.Put("objectClass", @("dynamicObject","user") )
$objDyn.Put("entryTTL", $intDynTTL )
$objDyn.Put("sAMAccountName", $objName )
The best way to detect this today is setting a SACL (System Access Control List) on the domain root.
Configure the Domain Controller Audit Policy by turning on advanced auditing setting:
Directory Service Changes - Success and Failure
This will catch all events triggered by the configured system access control lists.
Eventlog and Windows Event Forwarding
You most likely want to look at one central log rather than each DC's log , so I strongly advise you to set up a central logging solution, unless you have it already. Maybe you got OMS or SCOM? If not take a look at : https://docs.microsoft.com/en-us/azure/operations-management-suite/oms-security-getting-started
Otherwise WEF is the simplest thing to set up and its built-in and scalable, see this blog:https://blogs.msdn.microsoft.com/canberrapfe/2015/09/21/diy-client-monitoring-setting-up-tiered-event-forwarding/
Then use this XPath filter to find all events related to creation of dynamic objects (18.104.22.168.4.1.1422.214.171.124 = dynamicObject):
<QueryList> <Query Id="0" Path="Security"> <Select Path="Security">*[System[EventID=5136]] and *[EventData[Data[@Name='AttributeValue']='126.96.36.199.4.1.14188.8.131.52']]</Select> </Query> </QueryList>
This is the event you will see:
Monitor these event (Send mail open program are options in event viewer if you don't have a monitoring solution in place) and review it so the objects are not used for any malicious activity.
Bottom line :
Do delegation so only trusted admins are allowed to create objects. Review your Access Control Lists. See previous blog posts on reviewing access (Forensics: Active Directory ACL investigation/) and Take Control Over AD Permissions and the AD ACL Scanner Tool
Set up auditing and proper monitoring.