Detect AD attacks

هحدثه كل فترة إن شاء الله

DCSync attack

DCSync is a credential dumping technique used by threat actors to compromise domain users’ credentials.

This attack abuses the Directory Replication Service (DRS) remote protocol domain controllers used for synchronization and replication.

To successfully perform this attack, a threat actor must have access to a domain user account with “Replicating Directory Changes” and “Replicating Directory Changes All” privileges.

  • DCSync attacks are typically performed using tools like Mimikatz

The DCSync module sends a request to the domain controller, simulating the behavior of a legitimate domain controller replication request.

The domain controller, thinking it's replicating data to another domain controller, provides the requested sensitive account information.

Once the attacker receives the requested data, they can extract password hashes and other credential information from the response.

These password hashes can then be cracked offline using various techniques, potentially revealing plaintext passwords.

PS> .\mimikatz.exe "lsadump::dcsync /user:DOMAIN\krbtgt"
 
[DC] 'domain.com' will be the domain
[DC] 'DC1.DOMAIN.com' will be the DC server
[DC] 'DOMAIN\krbtgt' will be the user account
 
Object RDN           : krbtgt
 
** SAM ACCOUNT **
 
SAM Username         : krbtgt
User Principal Name  : krbtgt@DOMAIN.COM
Account Type         : 30000000 ( USER_OBJECT )
User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT )
Account expiration   :
Password last change : 09/03/2021 14:51:03
Object Security ID   : S-1-5-21-5840559-2756745051-1363507867-502
Object Relative ID   : 502
 
Credentials:
  Hash NTLM: 1b8cee51fd49e55e8c9c9004a4acc159
 
# ... output truncated ...
 
* Primary:Kerberos-Newer-Keys *
    Default Salt : DOMAIN.COMkrbtgt
    Default Iterations : 4096
    Credentials
      aes256_hmac       (4096) : ffa8bd983a5a03618bdf577c2d79a467265f140ba339b89cc0a9c1bfdb4747f5
      aes128_hmac       (4096) : 471644de05c4834cc6cbc06896210e7d
      des_cbc_md5       (4096) : 23861a94ea83a4cd
 
# ... output truncated ...

  • The obtained KRBTGT account credential is a prerequisite to perform a Golden ticket attack.

  • It is possible to detect a DCSync attack by monitoring network traffic to every domain controller, or by analyzing Windows event logs.

  • Event ID 4662 in the subcategory Audit Directory Service Access audits basic information about users performing operations within Active Directory for events specified in an object’s system access-control list (SACL).

SIGMA

engoy reading :

LogoCredential Dumping: DCSync AttackHacking Articles
LogoA primer on DCSync attack and detectionAltered Security
LogoDCSync Attacks Explained - HawkEyeHawkEye

Golden ticket attack

Golden tickets are forged authentication tickets that abuse the Kerberos protocol that encrypts and signs messages using shared secrets.

Kerberos tickets are generated using the password hash of the KRBTGT user account. These tickets can be used to access systems and data because the tickets are trusted and valid for authentication.

  • The NTLM password hash of the KRBTGT account obtained in the DCSync attack is used to facilitate the Golden ticket attack.

  • Run mimikatz as administrator and run the following command to forge Kerberos tickets using the NTLM hash of the KRBTGT account obtained

  • To mint the TGT, the adversary must specify the following information to mimikatz kerberos::golden:

  • /domain — The FQDN of the domain

  • /sid — The SID of the domain

  • /aes256 — The AES-256 password hash of the KRBTGT user (alternatively, /ntlm or /rc4 can be used for NTLM hashes, and /aes128 for AES-128)

  • /user — The username to be impersonated

  • /groups — The list of groups (by RID) to include in the ticket, with the first being the user’s primary group

  • /ptt — Indicates that the forged ticket should be injected into the current session instead of being written to a file

We can see from the output that the golden ticket was successfully submitted for the current session.

  • Run the following command to open a command prompt session authenticated with the forged Kerberos ticket.

Detecting the use of a golden ticket requires analyzing Kerberos tickets such as:

  • Usernames that don’t exist in Active Directory

  • Modified group memberships (added or removed)

  • Username and RID mismatches

  • Ticket lifetimes that exceed the domain maximum (the default domain lifetime is 10 hours but the default assigned by mimikatz is 10 years)

  • Event ID 4769: Audit Kerberos Service Ticket Operations "generated every time the Key Distribution Center (KDC) receives a Kerberos Ticket Granting Service (TGS) ticket request."

SIGMA

  • EventID: 4769 (Kerberos ticket creation).

  • TicketOptions: '0x40810000' represents the specific ticket options indicating a TGT request with forwardable, renewable, and forwarded tickets. You might need to adjust this value based on your research.

  • ServiceName: 'krbtgt' specifies the target service name for the TGT. In a Golden Ticket attack, attackers often target the Key Distribution Center (krbtgt) account.

Kerberoasting attack

Kerberoasting is an attack technique that involves an attacker abusing the privilege given to authenticated users to request a Ticket Granting Service (TGS) ticket for any servicePrincipalName (SPN) from a domain controller.

The ticket may be encrypted with a Cipher suite like RC4, HMAC, or MD5 using the password hash of the service account associated with the SPN.

The threat actor extracts the password hash of the ticket and attempts to crack the password offline.

  • STEP 1 Enumerate servicePrincipalNames

In a Kerberoasting attack, an adversary may target as many service accounts as possible or conduct internal reconnaissance to find specific service accounts with privileges they desire. In either case, the attacker needs to enumerate the servicePrincipalNames (SPNs) for the service accounts being targeted.

  • STEP 2 Request TGS tickets and extract the password hashes

  • STEP 3 Crack the passwords offline

  • STEP 4 Use new privileges to further objectives

With the plaintext password, the adversary can authenticate to any resources the service account has access to, helping them to compromise data or escalate privileges.

Here’s how an attacker can use compromised credentials to authenticate directly to a database the service account uses, and then exploit configuration vulnerabilities to escalate their privileges to a database administrator.

  • Events 4769 and 4770 in subcategory Audit Kerberos Service Ticket Operations audit all TGS requests and renewals.

  • Adversaries casting a wide net or running Kerberoasting tools with default configuration options may trigger a large number of TGS requests than normally observed for a given user.

SIGMA

Pass the hash attack

Pass the Hash is a technique used by threat actors to steal credentials and perform lateral movement.

This attack exploits the NTLM authentication protocol to authenticate a user with a password hash captured rather than using the account plaintext password.

STEP 1 Steal password hashes

An adversary who has gained a foothold in a network can use any of multiple methods to obtain password hashes, including DCSync attacks and extracting hashes from NTDS.dit.

Another method, is to extract password hashes from the LSASS.exe process memory, which stores hashes for users with active sessions to the computer.

Note that this technique requires the adversary to have compromised administrative privileges to the computer (e.g., by enticing a user who is an administrator on the workstation to open a phishing email)

  • Open mimikatz as an administrator, then run the log passthehash.log and privilege::debug commands. The log passthehash.log enables logging of all the activities performed while the privilege::debug command grants the mimikatz process debug right by elevating privilege.

  • . Run sekurlsa::logonpasswords to extract password hashes from the LSASS.exe process memory, which stores the hashes for users with active sessions to the computer.

  • The goal of this command is to obtain a user account with the relevant privileges to achieve the objective of the attack.

STEP 2 Authenticate using a stolen password hash

To pass-the-hash using mimikatz sekurlsa::pth,

  • /user: — The compromised user’s username

  • /domain: — The FQDN of the domain (if using a domain account) or “.” (if using a local account)

  • /ntlm:, /aes128: or /aes256: — The stolen NTLM, AES-128 or AES-256 password hash

STEP 3 Access other resources

the adversary can use the PSExec tool to execute commands on remote systems in order expand their footprint and repeat the cycle of credential theft and lateral movement on an ever-growing number of systems.

pass-the-hash can be challenging for organizations to detect, as each endpoint needs to be monitored for suspicious activity.

  • Monitor NTLM authentications for example: a user accessing a larger number of endpoints than normal; or a user accessing endpoints for the first time.

  • in order to extract hashes from an endpoint's LSASS.exe process, the malware would need to obtain a handle with the PROCESS_VM_OPERATION and PROCESS_VM_WRITE privileges. EDR solutions can monitor for processes creating suspicious handles.

  • Extracting hashes from Active Directory requires administrative privileges and use of other techniques like DCSync and extracting hashes from NTDS.dit

SIGMA

Ntds.dit password extraction

The ntds.dit file located in C:\Windows\NTDS\ is the database that stores all the data in the Active Directory on every domain controller.

Attackers can compromise users’ credentials by extracting the password hash from the ntds.dit file.

This attack can be achieved by using several techniques to copy the ntds.dit file from the DC to a local system to crack the password offline.

STEP 1 Obtain required privileges

  • An attacker needs access to the domain controller file system to extract ntds.dit file

  • In the example below, the adversary uses mimikatz to gain access to a domain controller’s file system via a Golden Ticket.

STEP 2 Exfiltrate ntds.dit

  • With access to a domain controller’s file system, the adversary can exfiltrate ntds.dit as well as the HKEY_LOCAL_MACHINE\SYSTEM registry hive, which is required to obtain the Boot Key for decrypting ntds.dit.

  • while Active Directory is running, it maintains a file system lock on the ntds.dit file, so attempts to copy it will fail. Adversaries

Adversaries have multiple ways ,they can:

  • Simply stop Active Directory (though this is likely to result in being detected).

  • Use the Volume Shadow Copy Service (VSS) to snapshot the volume and extract ntds.dit from the snapshot.

  • Use a PowerShell tool like PowerSploit’s Invoke-NinjaCopy to copy the files even though they are in use.

  • Use a built-in tool like DSDBUtil.exe or NTDSUtil.exe to create active directory installation media files.

STEP 3 Extract the password hashes

  • Once the adversary has exfiltrated ntds.dit and the HKLM\SYSTEM registry hive, they no longer require access to the organization’s network.

  • An adversary interested in cracking the passwords will often want to run a brute-force attack with a computer optimized for that purpose, but first they’ll need to extract the hashes from ntds.dit

  • The DSInternals PowerShell module provides the Get-BootKey and Get-ADDBAccount cmdlets for this purpose.

Run the following command to extract password hashes from the ntds.dit file.

STEP 4 Use the password hashes to gain further objectives

  • The adversary can now use the password hashes in pass-the-hash attacks within the environment

  • they will seek to crack these passwords for use in credential stuffing attacks against non-domain joined systems.

  • Attempts to access ntds.dit can be detected using the Windows event log. Event IDs 4663 and 4656 of the Audit File System subcategory can be used to audit file system access. Use these events to monitor for both regular and Volume Shadow Copy attempts to read or modify ntds.dit.

SIGMA

  • For Event ID 4663, it checks for read access to the Ntds.dit file (ObjectPath: '*\ntds.dit' and AccessMask: '0x2').

  • For Event ID 4662, it checks for specific access to the SAM database, which can be an indication of DCSync attack.

  • Event ID 4670 is checked for access to the Ntds secrets.

  • Event ID 5145 is checked for write access to the Ntds.dit file.

  • Event ID 4660 is checked for delete access to the Ntds.dit file.

enjoy with that

LogoCredential Dumping: NTDS.ditHacking Articles
Logoextracting-password-hashes-from-the-ntds-dit-filePuckieStyle

LogoExtracting Password Hashes from the Ntds.dit File | Netwrixblog.netwrix.com
LogoBlogwww.ultimatewindowssecurity.com
LogoNTDS.DIT – Penetration Testing LabPenetration Testing Lab

AdminSDHolder Attack

AdminSDHolder modification is a persistence technique in which an attacker abuses the SDProp process in Active Directory to establish a persistent backdoor to Active Directory.

Each hour (by default), SDProp compares the permissions on protected objects (e.g., Users with Domain Admin Privileges) in Active Directory with those defined on a special container called AdminSDHolder.

If they differ, it replaces the permissions on the protected object with those defined on AdminSDHolder. Therefore, an adversary who modifies the AdminSDHolder container can establish a path of shadow administration and a means to regain administrative access to Active Directory.

  • By modifying the permissions of a protected group or user account, an attacker can grant themselves unauthorized administrative privileges.

STEP 1 Acquire the required privileges

Before an adversary can modify the AdminSDHolder container, they must gain administrative privilege in the domain

the adversary utilizes the Rubeus tool to AS-REP roast a privileged user (JoeD) with Kerberos pre-authentication disabled.

STEP 2 Modify the AdminSDHolders access control list (ACL)

After successfully cracking password hash for the JoeD account obtained through AS-REP roasting,

The attacker authenticates with the password and uses PowerSploit’s Add-DomainObjectACL cmdlet to grant all privileges on the AdminSDHolder container to a normal user they’d previously compromised (BobT).

The next time the SDProp process runs, BobT’s new privileges will be applied to all protected objects.

STEP 3 Use permissions to regain access

the attacker has control of the JoeD and BobT accounts and has created a persistence mechanism that will allow them to regain Domain Admins privileges if they lose access to JoeD. BobT is a shadow administrator of the Active Directory domain.

If he has lost access to JoeD’s account. Instead of having to AS-REP roast again or use some other method, the attacker can use BobT’s account to re-establish their position.

  • Watching for changes to the AdminSDHolder container ACL is a good way to detect potentially malicious activity. In a normal environment, changes to AdminSDHolder should occur infrequently and follow change control processes.

  • Event ID 5136 in the Audit Directory Service Changes subcategory of the Windows event log monitors directory service changes.

  • To identify changes to the AdminSDHolder container ACL, monitor events that match the ObjectDN “CN=AdminSDHolder,DC=System” and the AttributeLDAPDisplayName is ‘nTSecurityDescriptor’.

SIGMA

  • The rule monitors specific Event IDs (5136, 5137, 5139, 5141) that correspond to object modifications and changes in Active Directory.

PreviousInvestigating with Windows Event LogsNextHunt Evil

Last updated