The Investigation

This will not be a full investigation; I will only be exploring a few observations and notes.

Investigation Notes:

Let's discuss what happened after executing this command.

psexec.py main.local/administrator@192.168.204.163 -hashes :baea263f1d7f5474de34adf195f4d38c

One of the most powerful and widely used tools in the Impacket suite is psexec.py. While it mimics the functionality of the original Sysinternals PsExec utility, it operates in a slightly different way. The script uploads a randomly named executable to the target system's ADMIN$ share and uses it to create a remote service. This service is registered through RPC using the Windows Service Control Manager. Once the service is running, psexec.py establishes a connection via a named pipe, ultimately granting an interactive SYSTEM-level shell on the target machine.

Let's review the system logs and filter for Event ID 7045, which indicates that a new service was installed on the system.

The service binary is located at the path: %SystemRoot%\KIzJwMyW.exe, which resolves to C:\Windows\KIzJwMyW.exe.

After executing the PsExec module, we were granted access to the System32 directory on the target host. Running the whoami command confirmed that we had obtained SYSTEM-level privileges. With this level of access, we are able to perform a wide range of actions on the host, including advanced enumeration, establishing persistence, and conducting lateral movement.

We have also created a Golden Ticket with a one-year validity period, let’s proceed to review it.

Let's generate a new Golden Ticket for a domain admin account other than the default Administrator, perform an action using this ticket, and observe the resulting behavior.

kerberos::golden /user:labadmin /domain:Main.local /sid:S-1-5-21-620716483-2719109048-3577772375 /rc4:b2b2d70531cd51d69f0e6414902f29f1 /id:2104 /endin:5256000 /ptt

dir \\DC01.Main.local\C$

In a Golden Ticket attack, adversaries generate forged Kerberos Ticket Granting Tickets (TGTs) using the hash of the compromised KRBTGT account. This enables them to request service tickets (TGS) directly, leading to Event ID 4769 logs without corresponding Event ID 4768 logs, as the initial TGT authentication process is bypassed. Consequently, the absence of Event ID 4768 is a key indicator of this type of attack.

It is currently 2:40 PM; let's review the logs to determine what actually occurred.

After filtering for Event Code 4768, no TGT requests were found. Let's proceed to examine Event Code 4769.

Here, we observe that a Ticket Granting Service (TGS) request was made by the domain administrator account labadmin without a preceding Ticket Granting Ticket (TGT) request.

For more detailed information, please refer to the following resource: Golden Ticket Attack and Defense

We have also conducted a Pass-the-Hash attack as part of our lab activities. For a comprehensive overview of this attack, please refer to the following resource: Pass-the-Hash Attack and Defense

We also conducted a Kerberoasting attack on a user in this scenario. For a detailed explanation of both the attack and its corresponding defense, please refer to the following link: Kerberoasting Attack and Defense

We also performed an LLMNR/NBT-NS poisoning attack to capture the NTLM hash of the user alice.smith. Let's analyze the captured traffic using Wireshark.

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are Microsoft Windows features that provide alternative methods for host name resolution when DNS fails. When a host is unable to resolve a name via DNS, it may attempt to query other devices on the local network using LLMNR. Based on the DNS format, LLMNR enables hosts on the same local link to resolve names for one another and operates over UDP port 5355. If LLMNR is unsuccessful, the system may fall back on NBT-NS, which resolves names using NetBIOS over UDP port 137. NBT-NS identifies devices on the local network by their NetBIOS names.

udp.port == 5355

By examining the source and destination IP addresses, we observe that the device at 192.168.204.171 is initiating a DNS query for "COM011," while the device at 192.168.204.152 is responding to the query.

The DNS query for COM011 appears to be a misspelling of the intended hostname (COM01). To clarify, we should further investigate the IP address 192.168.204.152 to determine its association.

dhcp

We have confirmed that the machine is a Kali system and not joined to our domain. Next, we will filter by ntlmssp to identify which user's credentials may have been compromised.

ntlmssp

NTLM authentication and negotiation are conducted through a sequence of three distinct packets:

• NTLMSSP_NEGOTIATE: Initiates the authentication process by indicating supported features and capabilities.

• NTLMSSP_CHALLENGE: The server responds with a challenge to verify the client's identity.

• NTLMSSP_AUTH: The client replies with authentication information to complete the handshake.

In the image above, Wireshark identifies the Kali machine as COM011 because the attacker impersonated this host during the attack, exploiting a typographical error made by the victim.

It appears that the credentials of the user alice.smith have been compromised.

For more information on this topic, please refer to the following article: LLMNR Poisoning Attack Detection.