PsExec Hunt Lab Walkthrough

Introduction

In this lab, we investigate a network compromise flagged by an Intrusion Detection System (IDS) alert indicating suspicious lateral movement activity involving PsExec. PsExec is a powerful, legitimate administrative tool often exploited by attackers to execute commands remotely and move laterally across a network. Our task as SOC analysts is to analyze the provided PCAP file to trace the attacker’s activities, identify their entry point, and understand their methods of traversal and compromise.

The investigation begins by identifying the initial access point, where the attacker leveraged SMB (Server Message Block) protocol over TCP to gain a foothold on the network. SMB, a protocol widely used for file sharing and resource access, becomes a key focus as we dissect its role in the attack. The attacker’s actions included negotiating SMB sessions, utilizing administrative shares such as ADMIN$, and installing the PsExec service executable, PSEXESVC.exe, on a compromised machine to enable remote execution.

What is PSEXESVC?

When PsExec is executed, it installs a lightweight service called PSEXESVC.exe on the target machine. This binary is automatically copied over the ADMIN$ share into the Windows system directory. Once installed, PSEXESVC runs as a Windows service under the SYSTEM account, giving the attacker (or administrator) the ability to execute commands remotely with high privileges. PsExec uses this service in conjunction with IPC$ to handle input/output redirection, command execution, and result collection. In legitimate environments, this allows administrators to manage systems without direct login; however, in adversarial hands, it becomes a powerful lateral movement and privilege escalation tool.

As the investigation progresses, we uncover the attacker’s lateral movement tactics, including the use of compromised credentials and connections to the special IPC$ share for inter-process communication. We also identify the hostname of the compromised machine and trace a failed attempt to pivot further to another machine, shedding light on the attack’s extent and limitations. By analyzing SMB session data and NTLM authentication processes, we piece together the attacker’s methodology and highlight key indicators of compromise (IoCs).

---

Step 0: Setup & Evidence Handling

I started by copying the provided PCAP file into a Working folder and preserving the original in an Evidence folder. This way, my analysis wouldn’t affect the original data, preserving chain-of-custody. I then opened the working copy in Wireshark and prepared filters for SMB2 and DCERPC traffic, since PsExec activity leaves distinct traces there.

We preserved the original evidence, created a working copy, and loaded the PCAP in Wireshark. This ensures forensic integrity and sets us up to analyze suspicious SMB2 and DCERPC traffic.

---

Q1: To effectively trace the attacker's activities within our network, can you identify the IP address of the machine from which the attacker initially gained access?

I applied a filter for SMB2/DCERPC traffic:

smb2 || dcerpc

I found a Negotiate Protocol Request sent from 10.0.0.130 → 10.0.0.133 over TCP port 445. This indicates 10.0.0.130 initiated the connection.

Answer:
10.0.0.130

We identified 10.0.0.130 as the attacker’s initial foothold because it initiated the SMB2 negotiation. This tells us where the compromise started, guiding our containment priorities.

---

Q2: To fully understand the extent of the breach, can you determine the machine's hostname to which the attacker first pivoted?

I filtered for NTLM authentication packets:

ntlmssp

Expanding the NTLMSSP_AUTH packet fields, the NetBIOS computer name showed SALES-PC. I confirmed this by following the TCP stream, which repeated the SALES-PC hostname in ASCII.

Answer:
SALES-PC

We extracted the target’s hostname from NTLMSSP authentication metadata, identifying SALES-PC as the first pivoted system. This confirms where the attacker moved after gaining their initial foothold.

---

Q3: Knowing the username of the account the attacker used for authentication will give us insights into the extent of the breach. What is the username utilized by the attacker for authentication?

Using the same NTLMSSP_AUTH packet, I expanded the authentication fields and found:

• User: ssales
• Domain/Host: HR-PC

Answer:
ssales

We confirmed the attacker authenticated using the ssales account. This indicates credential compromise and shows the attacker masqueraded as a legitimate user to pivot inside the network.

---

Q4: After figuring out how the attacker moved within our network, we need to know what they did on the target machine. What's the name of the service executable the attacker set up on the target?

I filtered for file creation commands:

smb2.cmd == 5

I found a Create Request where PSEXESVC.exe was written to the ADMIN$ share on 10.0.0.133. Following the TCP stream also showed the MZ header, proving it was a Windows executable.

Answer:
PSEXESVC.exe

We traced the creation of PSEXESVC.exe, PsExec’s service executable. Seeing this EXE dropped confirms PsExec was deployed on the target, providing remote command execution capability.

---

Q5: We need to know how the attacker installed the service on the compromised machine to understand the attacker's lateral movement tactics. This can help identify other affected systems. Which network share was used by PsExec to install the service on the target machine?

I filtered for SMB2 Tree Connect requests:

smb2.cmd == 3

This showed a connection to:

\\10.0.0.133\ADMIN$

Answer:
ADMIN$

We confirmed PsExec used the ADMIN$ share to copy its service binary. ADMIN$ maps to the Windows directory, giving attackers SYSTEM-level access when abused.

---

Q6: We must identify the network share used to communicate between the two machines. Which network share did PsExec use for communication?

I examined SMB2 Read Responses and Tree Connects, which showed the attacker also connected to:

\\10.0.0.133\IPC$

Answer:
IPC$

We saw PsExec mount the IPC$ share, which it used for inter-process communication and service control. Seeing ADMIN$ and IPC$ in sequence is a classic PsExec signature.

---

Q7: Now that we have a clearer picture of the attacker's activities on the compromised machine, it's important to identify any further lateral movement. What is the hostname of the second machine the attacker targeted to pivot within our network?

Filtering SMB2 Session Setup Responses revealed a new connection from 10.0.0.130 > 10.0.0.131. Expanding the NTLMSSP Target Info fields showed:

NetBIOS Computer Name: MARKETING-PC

The response ended with STATUS_LOGON_FAILURE, showing the attempt failed.

Answer:
MARKETING-PC

We confirmed the attacker attempted to pivot into MARKETING-PC, but authentication failed. Even failed pivots matter, because they reveal attacker intent and show which systems were probed.

---

Final Narrative Summary

In this PsExec Hunt lab, I analyzed a PCAP flagged by the IDS for suspicious lateral movement activity. My investigation showed the attacker originated from 10.0.0.130 and pivoted into SALES-PC using the compromised ssales account. They installed PSEXESVC.exe via the ADMIN$ share and maintained communication through IPC$, confirming PsExec activity.

Further analysis revealed an attempted pivot into MARKETING-PC, which failed with a logon error but still showed the attacker probing deeper into the environment.

This investigation highlights a textbook PsExec lateral movement pattern: valid credential abuse, ADMIN$ file drop, IPC$ communication, and subsequent pivot attempts. For defenders, monitoring for this exact sequence — ADMIN$ + PSEXESVC.exe + IPC$ — provides a strong detection signature for malicious PsExec use.