{
	"id": "b373bbb8-3994-4594-9d25-f6278c9372ee",
	"created_at": "2026-04-06T00:20:52.936966Z",
	"updated_at": "2026-04-10T03:20:45.660482Z",
	"deleted_at": null,
	"sha1_hash": "cfab75f8a554e57e873e4ee8b5aa8d4a2645fb9a",
	"title": "Threat hunting for PsExec and other lateral movement tools",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 64962,
	"plain_text": "Threat hunting for PsExec and other lateral movement tools\r\nBy Tony Lambert\r\nArchived: 2026-04-05 16:26:12 UTC\r\nAdversaries in post-compromise security incidents are like shoppers in a grocery store. It’s rare that they head\r\nstraight to a single place to get what they need. Instead, they enter the building and move around the aisles,\r\ngathering pieces along the way before they check out. In the same way, adversaries won’t hit a single place on\r\nyour network that contains all the data they’re trying to steal. They have to move laterally from system to system\r\n(or aisle to aisle) to gather the information that they came for.\r\nTo move around freely without attracting too much attention, attackers often use reliable software that looks\r\nnormal in an enterprise environment. One of the favorites among adversaries is an old friend of many IT\r\nadministrators: SysInternals PsExec.\r\nIn this post, we’re going to discuss some tactics that threat hunters can use to identify instances where adversaries\r\nuse PsExec (even when it’s been renamed or cloned) and similar tools to move laterally between endpoints on\r\nyour network.\r\nThe Classic: What is PsExec?\r\nSysInternals first released PsExec more than a decade ago, and it has provided administrators a reliable method for\r\nremotely accessing systems via the Server Message Block (SMB) protocol ever since. The fundamental behavior\r\nof PsExec follows a simple pattern:\r\n1. Establishes an SMB network connection to a target system using administrator credentials\r\n2. Pushes a copy of a receiver process named PSEXESVC.EXE to the target system’s ADMIN$ share\r\n3. Launches PSEXESVC.EXE, which sends input and output to a named pipe\r\nIn general, a named pipe is a method of interprocess communication, and various specific pipes are common in\r\nWindows Active Directory domains. Pipes may be named for specific uses, and, in this case, a pipe for PsExec\r\ncommunication usually looks like this: \\\\.\\pipe\\psexesvc. This detail becomes incredibly important when\r\nsearching for malicious uses of PsExec in your environment because even an evasive, renamed version of PsExec\r\nwill still use named pipes to communicate. In fact, this behavior is so predictable that we even see it in other\r\nsoftware that merely clones the functionality of PsExec. (We’ll come back to this in a moment).\r\nBinary metadata also helps identify renamed instances of PsExec. For the source process establishing a\r\nconnection, PsExec’s internal name value is simply PsExec , while the target’s receiving process, PsExeSvc.exe,\r\nhas an internal name of PsExec Service Host. Since PsExec is primarily available as precompiled binaries,\r\nthese metadata aren’t easily changed and can be handy to determine execution.\r\nIn addition to the metadata, a Windows Registry artifact (such as\r\nHKEY_CURRENT_USER\\software\\sysinternals\\psexec\\eulaaccepted ) can indicate when PsExec has been used.\r\nhttps://redcanary.com/blog/threat-hunting-psexec-lateral-movement/\r\nPage 1 of 5\n\nAdditionally, an admin must accept an End-User License Agreement if they want to use the utility, and the\r\nacceptance is written to this key. As with binary metadata and named pipe usage, this will not change if PsExec is\r\nrenamed, but it can be easily removed by an informed adversary.\r\nSend in the Clones\r\nSince PsExec is easy to use and reliable, it became a natural choice for legit software and adversaries alike, as\r\neach needed a way of issuing commands to remote systems. PsExec’s licensure terms, however, do not allow for\r\nredistribution within other software packages, which presented a problem for software developers, so now there\r\nare a variety of open-source tools that clone the capabilities of PsExec.\r\nRemCom\r\nRemCom is an open-source, redistributable utility providing the same remote management functions. It achieved a\r\nlevel of notoriety after adversaries used it to move laterally in their attack on the Democratic National Committee\r\nin 2016. However, it’s also included in several legitimate software packages. By default, RemCom sends\r\nRemComSvc.exe to a remote computer, which then uses the named pipe \\\\.\\pipe\\remcom_comunication\r\n(misspelling and all) in the place of PsExec’s named pipe. In addition, the process’s internal name has a value of\r\nremcom .\r\nPAExec\r\nPAExec features all the same functions of RemCom and PsExec, and is primarily intended for use with the\r\nPowerAdmin server management solution. By default, PAExec uses a named pipe containing the string PAExec\r\ncombined with a unique process identifier and computer name values. The receiving process is similarly named\r\nand usually has an internal name value of paexec.\r\nCSExec\r\nhttps://redcanary.com/blog/threat-hunting-psexec-lateral-movement/\r\nPage 2 of 5\n\nCSExec is a highly configurable, C# implementation of PsExec’s functionality. By default, CSExec sends\r\ncsexecsvc.exe to the remote computer and uses a named pipe called \\\\.\\pipe\\csexecsvc. The internal name\r\nvalue is readily changeable—although this depends on compilation instructions—but it should contain the string\r\ncsexec by default either way.\r\nComparing and contrasting all of these clones, a few things should become apparent:\r\nAll the clones are open-source, with their source-code available to the public\r\nAdversaries can download the code and recompile it with different values for named pipe names and\r\nbinary internal names\r\nDespite this, the underlying functionality for communication will remain the same\r\nHunting for Clones\r\nNow that we’ve established a reliable behavior for an entire class of lateral movement tools, we can devise a\r\ndetection strategy. Detection based on named pipes can get a bit messy because pipes are commonplace on\r\nWindows endpoints, but we can get a head start by excluding the pipes that we know are benign. Within Active\r\nDirectory environments, you can expect to find named pipes such as:\r\n\\\\.\\pipe\\netlogon\r\n\\\\.\\pipe\\samr\r\n\\\\.\\pipe\\lsarpc\r\nYou can also find other legitimate ones in specialized environments for things like SQL database queries and in\r\nmainframe systems. In your environment, you can establish a baseline of named pipes by using Sysinternals\r\nPipeList or Sysmon with Windows Event Logging. If you leverage endpoint detection and response (EDR) tools\r\nin your environment, then you can examine process file modifications to find named pipes as well.\r\nOnce you’ve found your baseline, you can start searching for abnormal pipes. Normal pipes should be abundant,\r\nwhile abnormal ones should be uncommon.\r\nWhat Else Can You Find With Pipes?\r\nWith the data we just collected about normal named pipes, you can also hunt for additional lateral movement and\r\nreconnaissance in your environment. For example, tools like Cobalt Strike and Metasploit both support lateral\r\nmovement using named pipes. In the case of Cobalt Strike, a default pipe name containing the string “msagent” is\r\ncommon, but this can be changed easily.\r\nhttps://redcanary.com/blog/threat-hunting-psexec-lateral-movement/\r\nPage 3 of 5\n\nIn the case of Metasploit, the adversary must specify a pipe name during configuration instead of accepting a\r\ndefault. In both cases, looking for outlier pipes in a dataset can reveal the usage of these tools, although\r\nconfirmation generally requires further investigation within your specific environment. This is especially handy as\r\npayloads from Cobalt Strike and Metasploit can be injected into other legitimate processes to evade detection.\r\nWe’ve found that a unique named pipe can make an awesome indicator of compromise during an incident.\r\nOn the reconnaissance side, you can detect tools like Bloodhound or Sharphound performing Active Directory\r\nenumeration. These tools communicate with domain infrastructure over ordinary named pipes that are common\r\nacross Windows systems, but they do so in extreme excess. Analyzing a named pipe dataset for a large amount of\r\nnamed pipe communications originating from a single process on a single host can lead you to find the origin of\r\nthis enumeration. Just like Cobalt Strike and Metasploit payloads, Bloodhound can be injected into legitimate\r\nprocesses or executed using PowerShell in unexpected ways. As such, detection through pipes can help narrow\r\ndown the suspect activity.\r\nPipes Are Noisy, How Can I Get Better Results?\r\nAfter you gather a dataset of named pipes from your endpoints, you’ll probably notice that there are a lot of\r\nprocesses using a lot of pipes. One way to decrease this noise is to limit the use of specific processes so that the\r\noutliers can stand out more. For example, if you want to increase the fidelity of hunts for PsExec in your\r\norganization, then you could ban its use by administrators in favor of PowerShell Remoting. PowerShell\r\nRemoting can perform the same actions as PsExec—and it does so more securely. Making little changes like this\r\ncan help you slowly improve your hunt results while teaching you more about your environment!\r\nWait, What About the Binary Metadata?\r\nDon’t fret if you can’t gather information about named pipes at scale in your environment right now. If you have\r\naccess to binary metadata in your environment, then you can start searching for suspicious lateral movement using\r\nthese searches:\r\nhttps://redcanary.com/blog/threat-hunting-psexec-lateral-movement/\r\nPage 4 of 5\n\nBinary internal name is psexec or Psexec Service Host , but the process name isn’t psexec.exe or\r\npsexesvc.exe\r\nBinary internal name is remcom but the process name isn’t remcom.exe or RemComSvc.exe\r\nBinary internal name includes paexec but the process name doesn’t contain paexec\r\nBinary internal name includes csexec but the process name doesn’t contain csexec\r\nThese searches are a good starting point if you’re looking for renamed instances of these tools, but they may prove\r\nineffective against certain open-source variants, especially those that have been custom-compiled by more\r\ndetermined adversaries.\r\nConclusion\r\nDespite the wealth of lateral movement tools similar to PsExec, an evergreen tactic for detecting these tools is to\r\nhunt for outlying named pipes used by processes on your Windows endpoints. Hunting in this manner will help\r\nreveal activity from unauthorized remote management tools in multiple forms, even when the tools have been\r\nmodified by adversaries. Collecting and analyzing named pipe data will also have benefits outside the realm of\r\nPsExec clones, allowing you to find adversary tools for covert movement and reconnaissance that would\r\notherwise be difficult to find.\r\nIf you’re interested in further reading, I wrote about some methods for detecting lateral movement when\r\nadversaries use Windows Remote Management (WinRM) and Windows Management Instrumentation (WMI)\r\nalmost exactly one year ago.\r\nTo take a deeper dive into threat hunting for lateral movement and other ATT\u0026CK tactics, watch our\r\nLateral Movement webinar series.\r\nSource: https://redcanary.com/blog/threat-hunting-psexec-lateral-movement/\r\nhttps://redcanary.com/blog/threat-hunting-psexec-lateral-movement/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://redcanary.com/blog/threat-hunting-psexec-lateral-movement/"
	],
	"report_names": [
		"threat-hunting-psexec-lateral-movement"
	],
	"threat_actors": [],
	"ts_created_at": 1775434852,
	"ts_updated_at": 1775791245,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cfab75f8a554e57e873e4ee8b5aa8d4a2645fb9a.pdf",
		"text": "https://archive.orkl.eu/cfab75f8a554e57e873e4ee8b5aa8d4a2645fb9a.txt",
		"img": "https://archive.orkl.eu/cfab75f8a554e57e873e4ee8b5aa8d4a2645fb9a.jpg"
	}
}