A helpdesk ticket lands on your queue. A finance workstation has slowed to a crawl, the user reported it on their way out of the office for a week off-site, Remote Desktop is blocked to that subnet by policy, and no EDR agent was ever deployed on that segment. What you have is a set of local administrator credentials and a network path to the host. 

But that is enough! An authenticated administrator can read a great deal of a Windows machine across the network: what it is, what is running on it, what is configured to start, who is connected, and every file on its disk. The Sysinternals PsTools suite covers most of that, and the host’s own administrative share covers the rest. 

In this month’s campaign, we’ll walk you through how to triage that host end to end, from first contact to containment, without once logging in. The work is a sequence of small, deliberate steps, and every finding is something you read off the host itself. 

But wait… there’s more… 

Read through to the end for a very special Halloween treat (or trick!). 

Understanding remote triage with PsTools 

Remote triage is the discipline of investigating a host you cannot sit in front of. Windows exposes a great deal of host state to an authenticated administrator over the network, and the Sysinternals PsTools are command-line clients for those interfaces. Each tool connects to a named host over SMB, reads what it needs, and prints the result on your own console. Nothing is copied to the target, and nothing is installed there. 

The whole investigation turns on the habit of reading every finding off the host itself, and trusting a name only once a source that cannot be faked confirms it. A process name is a claim a program makes about itself. A service’s display name and description are free text. The one field an attacker does not fully control is where a binary sits on disk, so the path becomes the evidence that decides what is malicious and what is merely suspicious. 

How to remote triage with PsTools, step by step 

A remote triage with PsTools runs as an ordered sequence, and each step narrows the question the next one answers. 

1. Establish remote access and confirm the host 

Start with PsInfo, which reports how a host is built (kernel build number, product type, install date, uptime, and memory). Running it first settles three questions at once, namely that the host is reachable, that your credentials carry administrative rights there, and that the machine answering is the one on the ticket.  

Because the workstation’s admin account is local to the machine, qualify it with the host name, as host\account.  

Note: PsInfo reads some fields from the registry that stopped being accurate years ago, so read the kernel build number and treat the product name above it as decoration. 

2. Enumerate the remote processes 

PsList reports the processes running on the host, with a tree view that shows which process started which. It reads through the Windows performance counters, a different interface from the one that serves registry reads, so a host answers one query and refuses another.  

Note: Remember that a process list does not tell you the full path on disk and the command line. A name is a lead, never a finding, and attackers pick names that sit close to a genuine Windows component without landing on it, so look for the near-miss, such as a digit appended, a letter doubled, or a character substituted. 

3. Identify who is connected 

PsLoggedOn answers two different questions:  

• Who is logged on locally, with a desktop session 

• Who is reading the host’s files over the network 

A local logon that contradicts the ticket is worth chasing. No local logon at all is just as informative, because a process running on a host where nobody is logged in was started by the operating system, which points to a service, a scheduled task, or something else that runs without a session. PsLoggedOn takes no credentials of its own, so on a host that is not domain-joined, authenticate the session first by connecting to the host’s IPC$ share, then let the tool inherit it. 

4. Trace the process to its service 

A service is a program Windows starts on its own, at boot, as SYSTEM, with nobody logged in, which makes the service database a dependable place to establish persistence (MITRE ATT&CK T1543.003). PsService reads that database remotely, and its config command reports the binary path each service launches.  

Filter the listing down to the services whose binaries do not sit under the Windows directory, and a handful survive. A service binary running from a user-writable directory, such as a user profile, C:\ProgramData, or C:\Windows\Temp, is a finding on location alone, because no legitimate installer deploys there. 

5. Read the payload 

A service registration tells you how something starts; it does not tell you what it does. For that, you need to read the file. The full command line often names the script the service runs, and that name is the link between the service and the payload worth opening.  

Windows publishes each fixed volume as a hidden administrative share, so the system drive is reachable as the host’s C$ share by a local administrator, and you read a dropped script across it without running it. Read for behavior, not sophistication:  

• The address it contacts and how often 

• The paths it reads 

• Where it writes the data it collects 

6. Rule out the look-alike 

The harder half of triage is clearing something that looks equally guilty. A second service can carry the same vendor branding, the same start type, and a similar binary name, and still be legitimate, because branding is not evidence.  

The one field that separates them is where the binary sits, for example, a binary under C:\Program Files was placed there by a privileged process and cannot be swapped by an unprivileged one, while a binary in a user-writable path has neither property. State what you ruled out and the field that decided it, so the rest of the report can be trusted. 

7. Contain the threat 

Containment stops the harm now; eradication removes the mechanism, and a triage pass ends at the first. There are two things to act on. 

1. Terminate the process, and anything still configured to start it returns at the next boot. Change the configuration, and the running process carries on, so do both.  

2. Terminate by PID rather than by name with PsKill, because killing by name takes down every process with that name, and set the malicious service’s start type to disabled with PsService, which keeps it down while leaving the registration in place for whoever investigates properly. Do not restart the host, because a restart destroys the volatile evidence and hands execution back to anything still armed to start automatically. 

The handover admits what is still outstanding. Disabling the mechanism you found does not prove it was the only one, and a full autostart review across services, scheduled tasks, and the registry is still due before anyone calls the host clean. 

About the Sysinternals course 

Remote Triage with PsTools is one module in the new Sysinternals course, released this month. The course is a complete, hands-on tour of the free Sysinternals Suite, the tools experienced analysts reach for when there is no EDR or SIEM to lean on. Across 13 modules, the course moves from the fundamentals of Windows processes to investigating live hosts: reading process trees in Process Explorer, watching file and registry activity in Process Monitor, mapping connections in TCPView, checking signatures with Sigcheck, finding persistence with Autoruns, pulling strings out of a binary, and working remote hosts with PsTools. It builds to a final challenge that puts every tool together. 

Trick or treat, a la Sysinternals 

Remote Triage with PsTools is Hands-on Lab in the new Sysinternals course, released this month. The course is a complete, hands-on tour of the free Sysinternals Suite, the tools experienced analysts reach for when there is no EDR or SIEM to lean on. 

While the full course isn’t available for free, you’re still getting something very special this month! Instead of unlocking a single Hands-on Lab as we usually do, we’ve added a Halloween twist. 

The treat: For the first time ever, we are allowing free access to the course’s final Challenge. A Challenge like this normally sits at the end of the course, after the labs and theory that teach each tool. This time you get the challenge on its own. Here’s what you should expect going in the Sysinternals Challenge:  

• Start on a flagged workstation with the full Sysinternals Suite. 

• Find what is running, verify it, and work out what it is doing. 

• Find every way it restarts. 

• Pivot to a second host you can only reach with PsTools. 

• Contain both hosts so the fix survives a reboot. 

The trick: You go in cold! No hints, no walkthrough, and no access to the modules that lead up to it. It is you, a host you cannot log into, and the PsTools. Good luck!  

If you solve it, be proud! Going in with no hints is genuinely hard, and building a defensible case against a live host without once logging into it is the skill that transfers to the next endpoint you cannot reach. 

One more thing. If you are really struggling, contact support from inside the platform, and we will flip a coin on whether we help you. Heads, you get a hint. Tails, you are on your own. Happy Halloween!