{
	"id": "74e879f5-2975-4346-a62f-c22822401f71",
	"created_at": "2026-04-06T01:29:57.891046Z",
	"updated_at": "2026-04-10T13:11:28.324452Z",
	"deleted_at": null,
	"sha1_hash": "7e1b3fb33a2e1224fa1c6e9314d26f74513850f4",
	"title": "Greater Visibility Through PowerShell Logging | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 130474,
	"plain_text": "Greater Visibility Through PowerShell Logging | Mandiant\r\nBy Mandiant\r\nPublished: 2016-02-11 · Archived: 2026-04-06 00:06:27 UTC\r\nWritten by: Matthew Dunwoody\r\nUPDATE (Feb. 29): This post has been updated with new configuration recommendations due to the Feb. 24\r\nrerelease of PowerShell 5, and now includes a link to a parsing script that users may find valuable.\r\nIntroduction\r\nMandiant is continuously investigating attacks that leverage PowerShell throughout all phases of the attack. A\r\ncommon issue we experience is a lack of available logging that adequately shows what actions the attacker\r\nperformed using PowerShell. In those investigations, Mandiant routinely offers guidance on increasing\r\nPowerShell logging to provide investigators a detection mechanism for malicious activity and a historical record\r\nof how PowerShell was used on systems. This blog post details various PowerShell logging options and how they\r\ncan help you obtain the visibility needed to better respond, investigate, and remediate attacks involving\r\nPowerShell.\r\nBackground\r\nAttackers and developers of penetration-testing frameworks are increasingly leveraging Windows PowerShell to\r\nconduct their operations. PowerShell is an extremely powerful command environment and scripting language that\r\nis built in to Microsoft Windows. By default, PowerShell does not leave many artifacts of its execution in most\r\nWindows environments. The combination of impressive functionality and stealth has made attacks leveraging\r\nPowerShell a nightmare for enterprise security teams[1].\r\nPowerShell 2.0, which comes installed on all Windows 7/2008 systems, provides very little evidence of attacker\r\nactivity. The Windows event logs show that PowerShell executed, the start and end times of sessions, and whether\r\nthe session executed locally or remotely (ConsoleHost or ServerRemoteHost). However, they reveal nothing about\r\nwhat was executed with PowerShell. Figure 1 shows an example of the event log messages recorded in the\r\nPowerShell 2.0 log Windows PowerShell.evtx.\r\nhttps://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html\r\nPage 1 of 7\n\nFigure 1: PowerShell Session Start in PowerShell 2.0\r\nMicrosoft has been taking steps to improve the security transparency of PowerShell in recent versions. The most\r\nsignificant improvements, such as enhanced logging, were released in PowerShell version 5.0. This enhanced\r\nlogging records executed PowerShell commands and scripts, de-obfuscated code, output, and transcripts of\r\nattacker activity. Enhanced PowerShell logging is an invaluable resource, both for enterprise monitoring and\r\nincident response.\r\nPowerShell 5.0 is the current release for Windows 7/2008 R2 and above. Though many of the enhanced logging\r\nfeatures of PowerShell 5.0 were backported to version 4.0, Mandiant recommends installing PowerShell 5.0 on all\r\nWindows platforms. PowerShell 5.0 includes features not available in 4.0, including suspicious script block\r\nlogging.\r\nInstallation\r\nWindows 10 does not require any software updates to support enhanced PowerShell logging.\r\nFor Windows 7/8.1/2008/2012, upgrading PowerShell to enable enhanced logging in PowerShell 5.0\r\n(recommended) requires:\r\n.NET 4.5\r\nWindows Management Framework (WMF) 4.0 (Windows 7/2008 only)\r\nWindows Management Framework (WMF) 5.0\r\nWindows 7 and 2008 R2 must be upgraded to Windows Management Framework (WMF) 4.0 prior to installing\r\nWMF 5.0.\r\nEnabling enhanced logging in PowerShell 4.0 for Windows 7/8.1/2008/2012 requires:\r\n»      .NET 4.5\r\n»      Windows Management Framework (WMF) 4.0\r\nhttps://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html\r\nPage 2 of 7\n\n»      The appropriate WMF 4.0 update\r\n        -     8.1/2012 R2 – KB3000850\r\n        -     2012 – KB3119938\r\n        -     7/2008 R2 SP1 – KB3109118\r\nDownloading these updates from Microsoft may require the completion of an automated request process.\r\nLogging Configuration\r\nLogging must be configured through Group Policy as follows:\r\nAdministrative Templates → Windows Components → Windows PowerShell\r\nFigure 2: PowerShell configuration options\r\nPowerShell supports three types of logging: module logging, script block logging, and transcription. PowerShell\r\nevents are written to the PowerShell operational log Microsoft-Windows-PowerShell%4Operational.evtx.\r\nModule Logging\r\nModule logging records pipeline execution details as PowerShell executes, including variable initialization and\r\ncommand invocations. Module logging will record portions of scripts, some de-obfuscated code, and some data\r\nformatted for output. This logging will capture some details missed by other PowerShell logging sources, though\r\nit may not reliably capture the commands executed. Module logging has been available since PowerShell 3.0.\r\nModule logging events are written to Event ID (EID) 4103.\r\nWhile module logging generates a large volume of events (the execution of the popular Invoke-Mimikatz script\r\ngenerated 2,285 events resulting in 7 MB of logs during testing), these events record valuable output not captured\r\nhttps://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html\r\nPage 3 of 7\n\nin other sources.\r\nTo enable module logging:\r\n1. In the \"Windows PowerShell\" GPO settings, set \"Turn on Module Logging\" to enabled.\r\n2. In the \"Options\" pane, click the button to show Module Name.\r\n3. In the Module Names window, enter * to record all modules.\r\n    a. Optional: To log only specific modules, specify them here. (Note: this is not recommended.)\r\n4. Click \"OK\" in the \"Module Names\" Window.\r\n5. Click \"OK\" in the \"Module Logging\" Window.\r\nAlternately, setting the following registry values will have the same effect:\r\n»      HKLM\\SOFTWARE\\Wow6432Node\\Policies\\Microsoft\\Windows\\PowerShell\\ModuleLogging →\r\nEnableModuleLogging = 1\r\n»      HKLM\\SOFTWARE\\Wow6432Node\\Policies\\Microsoft\\Windows\\PowerShell\\ModuleLogging\r\n\\ModuleNames → * = *\r\nScript Block Logging\r\nScript block logging records blocks of code as they are executed by the PowerShell engine, thereby capturing the\r\nfull contents of code executed by an attacker, including scripts and commands. Due to the nature of script block\r\nlogging, it also records de-obfuscated code as it is executed. For example, in addition to recording the original\r\nobfuscated code, script block logging records the decoded commands passed with PowerShell’s -\r\nEncodedCommand argument, as well as those obfuscated with XOR, Base64, ROT13, encryption, etc., in addition\r\nto the original obfuscated code. Script block logging will not record output from the executed code. Script block\r\nlogging events are recorded in EID 4104. Script blocks exceeding the maximum length of an event log message\r\nare fragmented into multiple entries. A script is available to parse script block logs and reassemble fragmented\r\nblocks (see reference 5).\r\nWhile not available in PowerShell 4.0, PowerShell 5.0 will automatically log code blocks if the block’s contents\r\nmatch on a list of suspicious commands or scripting techniques, even if script block logging is not enabled. These\r\nsuspicious blocks are logged at the “warning” level in EID 4104, unless script block logging is explicitly disabled.\r\nThis feature ensures that some forensic data is logged for known-suspicious activity, even if logging is not\r\nenabled, but it is not considered to be a security feature by Microsoft. Enabling script block logging will capture\r\nall activity, not just blocks considered suspicious by the PowerShell process. This allows investigators to identify\r\nthe full scope of attacker activity. The blocks that are not considered suspicious will also be logged to EID 4104,\r\nbut with “verbose” or “information” levels.\r\nScript block logging generates fewer events than module logging (Invoke-Mimikatz generated 116 events totaling\r\n5 MB) and records valuable indicators for alerting in a SIEM or log monitoring platform.\r\nGroup Policy also offers an option to \"Log script block execution start / stop events\". This option records the start\r\nand stop of script blocks, by script block ID, in EIDs 4105 and 4106. This option may provide additional forensic\r\ninformation, as in the case of a PowerShell script executing over a long period, but it generates a prohibitively\r\nhttps://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html\r\nPage 4 of 7\n\nlarge number of events (96,458 events totaling 50 MB per execution of Invoke-Mimikatz) and is not\r\nrecommended for most environments.\r\nTo enable script block logging:\r\n1. In the \"Windows PowerShell\" GPO settings, set \"Turn on PowerShell Script Block Logging\" to enabled.\r\nAlternately, setting the following registry value will enable logging:\r\n»      HKLM\\SOFTWARE\\Wow6432Node\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging →\r\nEnableScriptBlockLogging = 1\r\nTranscription\r\nTranscription creates a unique record of every PowerShell session, including all input and output, exactly as it\r\nappears in the session. Transcripts are written to text files, broken out by user and session. Transcripts also contain\r\ntimestamps and metadata for each command in order to aid analysis. However, transcription records only what\r\nappears in the PowerShell terminal, which will not include the contents of executed scripts or output written to\r\nother destinations such as the file system.\r\nPowerShell transcripts are automatically named to prevent collisions, with names beginning with\r\n\"PowerShell_transcript\". By default, transcripts are written to the user's documents folder, but can be configured\r\nto any accessible location on the local system or on the network. The best practice is to write transcripts to a\r\nremote, write-only network share, where defenders can easily review the data and attackers cannot easily delete\r\nthem (see reference 2 below). Transcripts are very storage-efficient (less than 6 KB per execution of Invoke-Mimikatz), easily compressed, and can be reviewed using standard tools like grep.\r\nTo enable transcription:\r\n1. In the \"Windows PowerShell\" GPO settings, set \"Turn on PowerShell Transcription\" to enabled.\r\n2. Check the \"Include invocation headers\" box, in order to record a timestamp for each command executed.\r\n3. Optionally, set a centralized transcript output directory.\r\nThis directory should be a write-only, restricted network share that security personnel can access. If no output\r\ndirectory is specified, the transcript files will be created under the user's documents directory.\r\nAlternately, setting the following registry values will enable logging:\r\n»       HKLM\\SOFTWARE\\Wow6432Node\\Policies\\Microsoft\\Windows\\PowerShell\\Transcription →\r\nEnableTranscripting = 1\r\n»       HKLM\\SOFTWARE\\Wow6432Node\\Policies\\Microsoft\\Windows\\PowerShell\\Transcription →\r\nEnableInvocationHeader = 1\r\n»       HKLM\\SOFTWARE\\Wow6432Node\\Policies\\Microsoft\\Windows\\PowerShell\\Transcription →\r\nOutputDirectory = “” (Enter path. Empty = default)\r\nLog Settings\r\nhttps://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html\r\nPage 5 of 7\n\nWhere possible, Mandiant recommends enabling all three log sources: module logging, script block logging and\r\ntranscription. Each of these sources records unique data valuable to analyzing PowerShell activity. In\r\nenvironments where log sizes cannot be significantly increased, enabling script block logging and transcription\r\nwill record most activity, while minimizing the amount of log data generated. At a minimum, script block logging\r\nshould be enabled, in order to identify attacker commands and code execution.\r\nIdeally, the size of the PowerShell event log Microsoft-Windows-PowerShell%4Operational.evtx should be\r\nincreased to 1 GB (or as large as your organization will allow) in order to ensure that data is preserved for a\r\nreasonable period. PowerShell logging generates large volumes of data that quickly rolls the log (up to 1 MB per\r\nminute has been observed during typical admin or attacker activity).\r\nThe Windows Remote Management (WinRM) log, Microsoft-Windows-WinRM%4Operational.evtx, records\r\ninbound and outbound WinRM connections, including PowerShell remoting connections. The log captures the\r\nsource (inbound connections) or destination (outbound connections), along with the username used to\r\nauthenticate. This connection data can be valuable in tracking lateral movement using PowerShell remoting.\r\nIdeally, the WinRM log should be set to a sufficient size to store at least one year of data.\r\nDue to the large number of events generated by PowerShell logging, organizations should carefully consider\r\nwhich events to forward to a log aggregator. In environments with PowerShell 5.0, organizations should consider,\r\nat a minimum, aggregating and monitoring suspicious script block logging events, EID 4104 with level \"warning\",\r\nin a SIEM or other log monitoring tool. These events provide the best opportunity to identify evidence of\r\ncompromise while maintaining a minimal dataset.\r\nAppendices\r\nAppendix A: Module Logging displays the contents of one module logging event generated during the\r\nexecution of the Invoke-Mimikatz PowerShell script.\r\nAppendix B: Script Block Logging displays the contents of one script block logging event generated\r\nduring the execution of the Invoke-Mimikatz script.\r\nAppendix C: PowerShell Transcription contains a sample transcript generated when executing Invoke-Mimikatz.\r\nReferences\r\n1. http://blogs.msdn.com/b/powershell/archive/2016/01/19/windows-management-framework-wmf-4-0-\r\nupdate-now-available-for-windows-server-2012-windows-server-2008-r2-sp1-and-windows-7-sp1.aspx\r\n2. http://blogs.msdn.com/b/powershell/archive/2015/06/09/powershell-the-blue-team.aspx\r\n3. https://www.fireeye.com/content/dam/fireeye-www/global/en/solutions/pdfs/wp-lazanciyan-investigating-powershell-attacks.pdf\r\n4. https://blogs.msdn.microsoft.com/powershell/2016/02/24/windows-management-framework-wmf-5-0-rtm-packages-has-been-republished/\r\n5. https://github.com/matthewdunwoody/block-parser\r\nSpecial thanks to Lee Holmes and the Microsoft PowerShell team.\r\nhttps://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html\r\nPage 6 of 7\n\n[1] See the Shmoocon 2016 presentation “No Easy Breach” by Mandiant consultants Matthew Dunwoody and\r\nNick Carr for some additional context of our experience analyzing PowerShell attacks:\r\nhttps://archive.org/details/No_Easy_Breach.\r\nPosted in\r\nThreat Intelligence\r\nSource: https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html\r\nhttps://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html"
	],
	"report_names": [
		"greater_visibilityt.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775438997,
	"ts_updated_at": 1775826688,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7e1b3fb33a2e1224fa1c6e9314d26f74513850f4.pdf",
		"text": "https://archive.orkl.eu/7e1b3fb33a2e1224fa1c6e9314d26f74513850f4.txt",
		"img": "https://archive.orkl.eu/7e1b3fb33a2e1224fa1c6e9314d26f74513850f4.jpg"
	}
}