Check­list

• Check if the Repli­ca­tion share is mount­able. If yes, grep for ass­word in Groups.xml, which can be recov­ered with Pow­er­Sploit’s Get-GPPPassword.ps1.

A domain of a DC con­sists out of the fol­low­ing elements:

• users
• groups
• com­put­ers

An object in AD may have a set of ACE Access Con­trol Entries which is called ACL Access Con­trol List. An objec­t’s ACE can be retrieved in PS with Get-ObjectAcl [-Identity| $object.

The SCM Ser­vice Con­trol Man­ag­er con­tains a data­base of installed ser­vices and dri­vers on Windows.

Authentication methods

Authen­ti­ca­tion is per­formed main­ly via NTLM and Kerberos

NTLM

1. Client cal­cu­lates a NTLM hash from the user’s password.
2. Client sends to the Appli­ca­tion Serv­er AS a username.
3. AS sends to the Client a Nonce/Challenge.
4. Client encrypts the Nonce/Challenge with the NTLM hash (aka user pass­word) and sends it to the AS.
5. AS sends this to the DC togeth­er with the user­name and nonce.
6. The DC com­pares it with the stored NTLM hash from the user and when iden­ti­cal, it sends a green light to the AS.

Kerberos

See the Ker­beros article.

The DC is the Key Dis­tri­b­u­tion Cen­ter. Because TGT can only be used for a short time because of the aging time­stamp, the sys­tem has to been able to gen­er­ate new TGT for which is need the user’s pass­word. It is cached in the Local Secu­ri­ty Author­i­ty Sub­sys­tem Ser­vice LSASS. To obtain the hash­es, sys­tem access is needed.

Service Account attacks

See Ker­beros article

Low and slow passwort guessing

Check the pass­word poli­cies on a AD system

net accounts

Note the Lock­out thresh­old and the Lock­out obser­va­tion win­dow. The idea is to try very few com­mon pass­words against a large set of users.

The script Spray-Passwords.ps1 can be used for this.

.\Spray-Passwords.ps1 -Pass 'pw1,pw2,pw3' -Admin

This script can be let on the vic­tim’s sys­tem. It will per­form n‑1 pass­word attempts in each time win­dows and maybe some­when deliv­er a pos­i­tive result.

Tools

respon­der: See blog post

mitm6: Win­dows pref­eres IPv6 over IPv4 for DNS servers. mitm6 can announce itself as IPv6 DNS serv­er which would then be used by Win­dows sys­tems. (Source)

• See also the source arti­cle which describes how to catch DNS requests and add pay­load into requests.

mitm6 -d lab.local

blood­hound: See the article

GetUserSPNs.py: Retrieves an Ker­beros tick­et which can include a hash. (Down­load)

GetUserSPNs.py -request -dc-ip $victim $domain/$user

User/Attributes: See OSCP 630f for a Pow­er­Shell script which enu­mer­ates through all users with their attributes.

ADAPE: Please describe me: https://github.com/hausec/ADAPE-Script

Death­Star: Pease describe me: https://github.com/byt3bl33d3r/DeathStar

Get password hashes

The DC stores pass­word hash­es for all users in the whole domain in the %systemroot%\ntds\ntds.dit file. It can be parsed with Impack­et’s secretsdump.py.

See also Win­dows pass­word files post.

Secretsdump.py

Required: Domain Admin user account and password.

Get the krbt­gt cre­den­tials (e.g. to per­form Gold­en Tick­et attacks afterwards):

secretsdump.py domain.local/svcsqlserver:$password@$dc-ip -just-dc-user krbtgt

Skeleton Key (Generalschlüssel)

When hav­ing domain admin access to the DC, a mal­ware can be inject­ed into the mem­o­ry which patch­es the authen­ti­ca­tion to check against the nor­mal process­es (NTLM/Kerberos) and a con­stant string. An attack­er can then use this con­stant string as pass­word to obtain any tick­et. There is no need to crack a domain admin’s pass­word anymore.

Mimikatz has inte­grat­ed this patch. Exe­cute the fol­low­ing on a DC with domain admin access:

privilege::debug
misc::skeleton

That’s it. Now, the pass­word mimikatz is valid for all users in the whole domain. Notes:

• This does not affect the “real” cre­den­tials. All users can authen­ti­cate as before.
• The patch is applied in the mem­o­ry. After the DC restarts, the skele­ton key is not longer avail­able. (But hey, who ever restarts a DC…?)

DCShadow

DCShad­ow makes anoth­er sys­tem to a pri­ma­ry DC. On this tem­po­rary DC, actions can be per­formed like pass­word changes, which prop­a­gate to the “real” (now sec­ondary) DC and all oth­er sys­tems but with­out hav­ing log­ging events on these sys­tems. The log­ging takes place on the “faked” DC.

On an attack­er (Win­dows Serv­er-) sys­tem, exe­cute Mimikatz. Make all changes there and then make the “real” DC again to the pri­ma­ry DC.

Notes

• SPN Ser­vice Prin­ci­pal Name is used to deter­mine a spe­cif­ic ser­vice with­in a AD.
• Arti­cle with attack techniques
• To pre­vent pass­word reusage, the DC nor­mal­ly stores the cur­rent and the pre­vi­ous pass­word (in Mimikatz ntlm‑0 and ntlm‑1). Maybe the old hash/password can work somewhere…?
• DFSR Dis­trib­uted File Sys­tem Repli­ca­tion: A stan­dard AD ser­vice which syn­chro­nizes direc­to­ries on all AD-joined sys­tems. Is used to repli­cate small con­fig­u­ra­tions on every device. (The oth­er, for users vis­i­ble way, is samba.)

Countermeasures

• Check if there are tick­ets some­where with a life-span which is too long. (Can be up to 10 years, which is used by most tools, but “nor­mal” tick­ets have a life­time only for some minutes/hours.)
• Check peri­od­ic on end-user sys­tems (e.g. with klist) if there are tick­ets with a valid­i­ty time which is too long.
• Mon­i­tor the DCs log for logs about new DCs/replications.