{
	"id": "18d3a34d-47ee-4018-9760-450630a59276",
	"created_at": "2026-04-06T03:36:41.267303Z",
	"updated_at": "2026-04-10T03:21:08.775644Z",
	"deleted_at": null,
	"sha1_hash": "0cd5c208f3dc0247ec583c8bdc4395c865a3e854",
	"title": "Investigating PowerShell Attacks",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 48762,
	"plain_text": "Investigating PowerShell Attacks\r\nBy PowerShell Magazine\r\nPublished: 2014-07-16 · Archived: 2026-04-06 03:19:45 UTC\r\n“Huh, that’s weird. Look at this system. I think the attacker used PowerShell.” It was late summer 2012, and we\r\nwere working on an incident response investigation for a Fortune 100 technology company compromised by an\r\nintruder attempting to steal intellectual property. The evidence wasn’t terribly exciting: just a simple\r\nreconnaissance script to enumerate domain users and systems. But it was an anomaly – or at least, a rare\r\noccurrence within the scope of our previous case work. We conduct hundreds of incident response investigations\r\nevery year, most of which involve targeted attacks for the purposes of espionage, stealing intellectual property, or\r\ntheft of financial data. Attacker tools, tactics, and procedures regularly change and evolve – and PowerShell was a\r\nnew wrinkle.\r\nFast forward almost two years later. Stories of PowerShell usage in both targeted compromises and opportunistic\r\nmalware are hitting infosec media with alarming frequency. We also see these trends in our daily casework: an\r\nincreasing number of investigations involve attacker reconnaissance, command execution, or data theft facilitated\r\nby PowerShell. Just a few months ago, we responded to a case where the attacker evolved from relying on custom\r\ntools and PsExec, to exclusive use of PowerShell remoting, for lateral movement and command-and-control (and\r\nthereby evaded detection for many months). The gap between attackers’ PowerShell skills, and organizations’\r\nability to detect and respond to its misuse, is growing.\r\nPrior articles by Matthew Graeber, Joseph Bialek, and Will Schroeder did a great job of explaining why\r\nPowerShell is so dangerous in the hands of an attacker – particularly given elevated privileges during the post-exploitation phase of an incident. It provides:\r\nA built-in mechanism for remote command execution\r\nThe ability to execute malicious code without ever touching disk\r\nThe ability to evade many Anti-Virus and Intrusion Prevention Systems\r\nFull access to WMI and .NET Framework\r\nThe unauthorized use of PowerShell presents several challenges to forensic analysts and system administrators\r\nalike:\r\nAs a legitimate component of Windows, PowerShell execution does not necessarily indicate malicious\r\nbehavior.\r\nPowerShell 2.0 does not provide a practical mechanism for detailed (e.g. per-command) auditing.\r\nPowerShell 3.0 and later provides comprehensive module logging – but is only installed by default on\r\nWindows 8 or Server 2012, which remain uncommon in many corporate environments.\r\nPowerShell remoting sessions occur in ephemeral process memory with few-to-no persistent artifacts.\r\nMany system administrators and security professionals remain unfamiliar with PowerShell and its\r\nmanagement or security controls.\r\nhttps://powershellmagazine.com/2014/07/16/investigating-powershell-attacks/\r\nPage 1 of 4\n\nFaced with these mounting challenges, we decided to research the forensic “footprints” left behind by the ways\r\nthat an attacker might use PowerShell – a topic for which publicized information is scarce. Our work focused on\r\nthree fundamental scenarios: local PowerShell execution, PowerShell remoting, and the configuration of a\r\npersistent PowerShell backdoor through the use of WMI. We examined multiple sources of evidence, including\r\nthe registry, file system, event logs, process memory, and network traffic.\r\nUnfortunately, we never found the “white whale” – a single source of evidence, consistently available across all\r\nversions of Windows and PowerShell, that provides a complete history of all activity on an endpoint regardless of\r\nhow it occurs. However, we did identify multiple artifacts containing tidbits of information that, when combined,\r\ncan solve common investigative questions.\r\nIn the upcoming weeks, we’ll be releasing a whitepaper and presentation at Black Hat USA and DEF CON that\r\nfocuses on the forensic analysis portion of our research. However, in this article we wanted to share a corollary of\r\nour findings – the sources of evidence that are best suited for establishing a baseline and monitoring a Windows\r\nenterprise environment.\r\nAs alluded to by Microsoft in their recent update to the Mitigating Pass-the-Hash whitepaper, organizations should\r\norient their detection and prevention efforts around the assumption that a breach has occurred. More specifically,\r\nthat means assuming that an attacker has successfully compromised credentials that provide local administrator-equivalent access to targeted system(s) (if not domain administrator outright). The worst-case scenario is\r\nunfortunately the reality for the majority of Windows environments that we encounter during investigations. Any\r\nsecurity control put in place to limit the use of PowerShell – be it the execution policy, disabled remoting, or\r\nconstrained endpoints, may be bypassed altogether.\r\nInstead of depending on these settings to prevent malicious usage of PowerShell, we recommend using them to\r\nestablish a baseline of normal activity in an environment. Deviations from this baseline may serve as an indication\r\nof attacker activity. We recommend that organizations formulate a PowerShell monitoring strategy by first\r\nassessing and enumerating the following:\r\nWhich servers/server groups are administered via PowerShell remoting? By local PowerShell script\r\nexecution? What about workstations/end-user systems?\r\nWhich domain accounts use PowerShell remoting? What are the source hostnames from which these users\r\nwould administer systems?\r\nWhat are the names and common directories used for legitimate PowerShell scripts within the\r\nenvironment? Are legitimate scripts used by the organization digitally signed?\r\nAre any systems configured to automatically load and execute PowerShell scripts for maintenance or\r\nadministration purposes?\r\nOnce complete, administrators can rely on centralized Windows event log forwarding and collection (for at-scale\r\nmonitoring) or local event log analysis (for targeted forensics and investigations) to identify signs of anomalous\r\nPowerShell usage. This effort will require filtering and tuning – that’s where having a baseline, or even monitoring\r\na subset of known-good systems with common configuration for a period of time, can help.\r\nIn the interest of providing recommendations applicable to all versions of PowerShell, inclusive of 2.0, we\r\nrecommend evaluating the following log sources and events:\r\nhttps://powershellmagazine.com/2014/07/16/investigating-powershell-attacks/\r\nPage 2 of 4\n\nWindows PowerShell event log entries indicating the start and stop of PowerShell activity:\r\nEvent ID 400 (“Engine state is changed from None to Available”), upon the start of any local or\r\nremote PowerShell activity.\r\nEvent ID 600 referencing “WSMan” (e.g. “Provider WSMan Is Started”), indicating the onset of\r\nPowerShell remoting activity on both source and destination systems.\r\nEvent ID 403 (“Engine state is changed from Available to Stopped”), upon the end of the\r\nPowerShell activity.\r\nSystem event log entries indicating a configuration change to the Windows Remote Management service:\r\nEvent ID 7040 “The start type of the Windows Remote Management (WS-Management) service\r\nwas changed from [disabled / demand start] to auto start.” – recorded when PowerShell remoting is\r\nenabled.\r\nEvent ID 10148 (“The WinRM service is listening for WS-Management requests”) – recorded upon\r\nreboot on systems where remoting has been enabled.\r\nWinRM Operational event log entries indicating authentication prior to PowerShell remoting on an\r\naccessed system:\r\nEvent ID 169 (“User [DOMAIN\\Account] authenticated successfully using\r\n[authentication_protocol]”)\r\nSecurity event log entries indicating the execution of the PowerShell console or interpreter:\r\nEvent ID 4688 (“A new process has been created”) – includes account name, domain, and\r\nexecutable name in the event message.\r\nAppLocker event log entries recording the local execution of PowerShell scripts. We recommend enabling\r\nAppLocker in audit mode across an environment for this specific purpose. Upon script execution in audit\r\nmode, the AppLocker MSI and Script Event Log may record:\r\nEvent ID 8006 (“[script_path] was allowed to run but would have been prevented from running if\r\nthe AppLocker policy were enforced”)\r\nEvent ID 8005 (“[script_path] was allowed to run”).\r\nBoth of these events will include the user account that attempted to execute a script.\r\nWe fully expect that threat actors will continue to employ more sophisticated PowerShell techniques and improve\r\ntheir counter-forensic strategies over time. It is our hope that our work will increase awareness of these attacks,\r\nmotivate organizations to enhance their detection and monitoring capabilities, and drive additional research. We\r\nlook forward to sharing further details in our forthcoming whitepaper and presentations at Black Hat USA and\r\nDEF CON.\r\nAuthors are Ryan Kazanciyan and Matt Hastings.\r\nhttps://powershellmagazine.com/2014/07/16/investigating-powershell-attacks/\r\nPage 3 of 4\n\nRyan Kazanciyan is a Technical Director with Mandiant and has eleven years of experience in incident response,\r\nforensic analysis, and penetration testing. Since joining Mandiant in 2009, he has led investigation and\r\nremediation efforts for dozens of Fortune 500 organizations, focusing on targeted attacks, industrial espionage,\r\nand financial crime.\r\nMatt Hastings is a Consultant with Mandiant, a division of FireEye, Inc. Based in the Washington D.C area, Matt\r\nfocuses on enterprise-wide incident response, high-tech crime investigations, penetration testing, strategic\r\ncorporate security development, and security control assessments; working with the Federal government, defense\r\nindustrial base, financial industry, Fortune 500 companies, and global organizations.\r\nShare on:\r\nSource: https://powershellmagazine.com/2014/07/16/investigating-powershell-attacks/\r\nhttps://powershellmagazine.com/2014/07/16/investigating-powershell-attacks/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://powershellmagazine.com/2014/07/16/investigating-powershell-attacks/"
	],
	"report_names": [
		"investigating-powershell-attacks"
	],
	"threat_actors": [],
	"ts_created_at": 1775446601,
	"ts_updated_at": 1775791268,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0cd5c208f3dc0247ec583c8bdc4395c865a3e854.pdf",
		"text": "https://archive.orkl.eu/0cd5c208f3dc0247ec583c8bdc4395c865a3e854.txt",
		"img": "https://archive.orkl.eu/0cd5c208f3dc0247ec583c8bdc4395c865a3e854.jpg"
	}
}