{
	"id": "734f4aca-cfb1-4cf0-a815-51827c2bd2b1",
	"created_at": "2026-04-06T00:11:04.917484Z",
	"updated_at": "2026-04-10T03:34:22.793641Z",
	"deleted_at": null,
	"sha1_hash": "27c3ee126ed2d85a3d7c0b5f3076b99f9095cf30",
	"title": "Attack and Defense Around PowerShell Event Logging - NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks.",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 989894,
	"plain_text": "Attack and Defense Around PowerShell Event Logging -\r\nNSFOCUS, Inc., a global network and cyber security leader,\r\nprotects enterprises and carriers from advanced cyber attacks.\r\nBy NSFOCUS\r\nPublished: 2019-02-27 · Archived: 2026-04-05 15:44:22 UTC\r\n0x00 Overview\r\nPowerShell has been a focus of concern for network defense. The fileless PowerShell, featuring LotL and\r\nexcellent ease of use, is widely used in various attack scenarios. In order to capture PowerShell-based attacks, an\r\nincreasing number of security professionals tend to, through PowerShell event log analysis, extract attack records\r\nsuch as post-exploitation data for enterprise security monitoring, alerting, trackback, and forensics.\r\nThus, it can be seen that how to evade event logging has become an important phase in network defense. Keeping\r\ntabs on continuous improvements in security features in the PowerShell event viewer, attackers employ a variety\r\nof techniques and methods to corrupt data concerning the PowerShell logging tool itself and compromise the\r\nintegrity of event logs. The vulnerability (CVE-2018-8415) patched by Microsoft in October 2018 is another\r\nmeans to evade the logging of the PowerShell event viewer. This document dwells upon security features of the\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 1 of 15\n\nlogging function of major versions of PowerShell, as well as attack means, ideas, and techniques against each\r\nversion of the event viewer.\r\n0x01 Introduction to PowerShell Attack and Defense\r\nPowerShell is a powerful scripting language and shell framework mainly available for Windows-based computers,\r\nfacilitating system management by administrators and likely to replace the default command prompt window on\r\nWindows operating systems. The PowerShell script, with good functions, is usually used for normal system\r\nmanagement and security configuration. Unfortunately, these features are also understood by attackers who have\r\ntranslated them into attack features (see below), and therefore, they will definitely pose serious threats to\r\nenterprise networks.\r\nMain Attack Characteristics of PowerShell\r\nFileless anti-AV tool to evade firewalls, various antivirus software, and intrusion prevention systems: With\r\nits fileless feature, PowerShell can be loaded from the memory and execute arbitrary code, without\r\ntouching the hard disk.\r\nLotL: Attackers can easily reach the attack destination, while evading common attack detection systems\r\nand intrusion prevention systems. PowerShell comes with many Windows operating systems. It is highly\r\nunlikely that these built-in trusted tools could be detected and restricted by anti-malware software. Using\r\nsuch tools, attackers can effectively dodge common attack detection systems and intrusion prevention\r\nsystems, without adding extra binaries.\r\nObfuscating code extremely easily: Sharing characteristics of scripting languages, the flexible\r\nPowerShell, in conjunction with multiple obfuscation methods, can easily render traditional detection tools\r\nineffective.\r\nExcellent functionality and adaptability to fit into various attack scenarios: PowerShell has a remote\r\nmanagement mechanism built in for remote command execution. PowerShell supports WMI and .NET\r\nFramework, boasting incredible ease of use.\r\nSince PowerShell was released in 2005, Microsoft has fixed a number of security issues in PowerShell during the\r\n13-year course of fighting between defenders and offenders, making the PowerShell attack environment\r\nincreasingly difficult to be exploited. One of important security measures Microsoft puts in place is the\r\nScriptBlock logging function of PowerShell, which keeps full records of historical executions of PowerShell. Of\r\ncourse, this function contributes to attack trackback and forensics. However, there is a reciprocal relationship\r\nbetween offenders and defenders, who have been and will continue to be fighting a long battle against each other.\r\nThe security defense research has been focusing on vulnerabilities in the PowerShell’s logging function and the\r\nlogging bypass method. In July 2018, a foreign security researcher nicknamed @Malwrologist spotted a flaw in\r\nthe logging module of PowerShell, which allows attackers to truncate logs with null characters, causing the\r\nmissing of important logs. Microsoft has fixed this issue (assigned CVE-2018-8415) in its patches released for\r\nthis month.\r\nPowerShell’s Logging Function from the RT\u0026BT Angle\r\nPrior to analysis of this vulnerability, we will give a summary of PowerShell’s logging function from the RT\u0026BT\r\nangle. Now, we will look back the protection ideas and attack means of various PowerShell versions.\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 2 of 15\n\n0x02 PowerShell V2—Initial Version of PowerShell\r\nPowerShell V2 provides an event logging capability which assists the Blue Team (defender) with deduction\r\nand correlative analysis of attack events. Its simple logging function hardly records any traces of post-exploitation. For later versions, attackers, considering system compatibility, will try to downgrade later\r\nversions to V2 to evade logging.\r\nPowerShell V2, as the initial version of this utility released by Microsoft, provides a basic event recording\r\ncapability to make a brief record of events, but lacks a satisfying logging function. All the same, the default\r\nlogging level of the old version can also provide sufficient evidence to show the way PowerShell is used. Besides,\r\nPowerShell V2 isolates remote handling from local activities and provides contextual information such as the\r\nsession duration and related user accounts. All of these are sufficient to help members of the Blue Team with\r\ndeduction and correlative analysis of attack events.\r\nDefense angle (from the perspective of Blue Team)\r\nWhen any PowerShell commands or scripts are executed, whether locally or remotely, Windows can write events\r\ninto three log files:\r\nWindows PowerShell.evtx\r\nMicrosoft-Windows-PowerShell/Operational.evtx\r\nMicrosoft-Windows-PowerShell/Analytic.etl\r\nPowerShell implements remote handling via Windows Remote Management (WinRM): The following event log\r\nfiles can capture remote PowerShell activities.\r\nMicrosoft-Windows-WinRM/Operational.evtx\r\nMicrosoft-Windows-WinRM/Analytic.etl\r\nUsually, PowerShell 2.0 can generate event logs indicating when the command or script execution starts or ends,\r\nwhat provider (show the type of function being in use) is loaded, and which user account performs activities, but\r\nfail to present detailed historical records of all executed commands or output. Analytic logs contain more\r\ninformation, helping us locate where certain errors occur. However, the analytic logging function, once enabled\r\n(disabled by default), will generate a great deal of record data in the production environment, hindering the actual\r\nanalysis.\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 3 of 15\n\nTo view analytic logs, users can click Show Analytics and Debug Logs in the menu bar of the event viewer and\r\nselect Enable Log in Microsoft-Windows-WinRM/Analytic or run the wevtutil Set-Log command to enable the\r\nlogging function:\r\nThe following is a summary of important evidence captured by each event log file of PowerShell 2.0.\r\nWindows PowerShell.evtx\r\nEach time PowerShell executes a single command, whether it is a local or remote session, the following event logs\r\n(identified by event ID, i.e., EID) are generated:\r\nEID 400: The engine status is changed from None to Available. This event indicates the start of a\r\nPowerShell activity, whether local or remote.\r\nEID 600: indicates that providers such as WSMan start to perform a PowerShell activity on the system, for\r\nexample, “Provider WSMan Is Started”.\r\nEID 403: The engine status is changed from Available to Stopped. This event records the completion of a\r\nPowerShell activity.\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 4 of 15\n\nThe HostName field is included in message details of events identified by EID 400 and EID 403. For a local\r\nactivity, this filed is recorded as ConsoleHost (HostName = ConsoleHost); for a remote activity handled by\r\nPowerShell, HostName is recorded as ServerRemoteHost (HostName = ServerRemoteHost) on the system that is\r\naccessed.\r\nNeither message records the user accounts associated with PowerShell activities. Viewing these events, analysts\r\ncan determine how long a PowerShell session lasts and whether the session runs locally or remotely.\r\nMicrosoft-Windows-PowerShell/Operational.evtx\r\nFor PowerShell 2.0, this log file is not found to record any material information.\r\nMicrosoft-Windows-WinRM/Operational.evtx\r\nThis log file records the use of WinRM, including remote handling activities by PowerShell.\r\nEID 6: recorded when a remote handling activity is started on the client system, including the destination\r\naddress to which the system is connected.\r\nEID 169: recorded when a remote handling activity is started on an accessed system, including the user\r\nname and authentication mechanism used to access WinRM.\r\nEID 142: If WinRM is disabled on the remote server, this event is recorded when the client attempts to\r\ninitiate a remote shell connection.\r\nMicrosoft-Windows-PowerShell/Analytic.etl\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 5 of 15\n\nAs mentioned above, events can be captured only when analytic logging is enabled. Capturing such events is\r\nintended for troubleshooting rather than long-term security audits. When active, the log file records all security\r\nevents relating to remote code execution under the following event IDs:\r\nEID 32850: records the user account authenticated for remote handling.\r\nEID 32867/32868: records each PowerShell input and output object exchanged during the remote handling\r\nof PowerShell, including protocol and version negotiation as well as command I/O. The objects are stored\r\nas XML-encoded hexadecimal strings in a field denoted “Payload data”. Such objects, because of the\r\nlength, are often fragmented across multiple log messages.\r\nEID 142: If WinRM is disabled on the remote server, this event is recorded when the client attempts to\r\ninitiate a remote shell connection.\r\nMicrosoft-Windows-WinRM/Analytic.etl\r\nSimilar to PowerShell Analytic logging, WinRM Analytic logging is not enabled by default. Once configured, it\r\ngenerates a great number of events which are encoded once again and difficult to analyze.\r\nAttack angle (from the perspective of Red Team):\r\nDue to the incompleteness of logs in earlier versions, various post-exploitation activities concerning PowerShell\r\nare nearly traceless. Even in later versions, as PowerShell 2.0 can be enabled on the system, attackers, by taking\r\nadvantage of forward compatibility, often run the powershell -version 2 command to switch the PowerShell\r\ncommand line to PowerShell 2.0 to evade the logging function. This is analogous to “downgrade attack”.\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 6 of 15\n\n0x03 PowerShell V3/V4 Featuring Comprehensive Logging\r\nCompared with earlier versions, PowerShell V3/V4 provides a more comprehensive logging function. At this\r\ntime, attackers turn to obfuscation means to obscure logs so as to escape identification and detection.\r\nWindows PowerShell 3.0 improves the logging and tracing support for commands and modules, with support for\r\nEvent Tracing in Windows (ETW) logs, an editable LogPipelineExecutionDetails property of modules, and the\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 7 of 15\n\n“Turn on Module Logging” Group Policy setting. PowerShell module logging has been available since\r\nPowerShell V3 and will log all events to EID 4103.\r\nPowerShell module logging can be configured to record all activities of each PowerShell module, covering single\r\nPowerShell commands, imported modules, and remote management. The module logging function can be enabled\r\nby configuring GPO settings.\r\nAlternately, setting the following registry values will have the same effect:\r\nHKLM\\SOFTWARE\\Wow6432Node\\Policies\\Microsoft\\Windows\\PowerShell\\ModuleLogging →\r\nEnableModuleLogging = 1\r\nHKLM\\SOFTWARE\\Wow6432Node\\Policies\\Microsoft\\Windows\\PowerShell\\ModuleLogging\r\n\\ModuleNames → * = *\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 8 of 15\n\nThe module logging records the CommandInvocation type and ParameterBlinding content involved during\r\nPowerShell script or command execution, covering the execution process and input/output contents. The addition\r\nof the logging function makes it possible to almost keep complete records of PowerShell execution logs, greatly\r\nfacilitating log analysis and alert monitoring.\r\nIn view of the attack-defense development, after this version is released, attackers also consider other methods to\r\nescape the logging function, for example, employing quite a few obfuscation algorithms for obscuring data.\r\n0x04 PowerShell v5 Capable of Deobfuscation\r\nPowerShell V5 adds the CLM and ScriptBlock logging functions, thus capable of deobfuscating PowerShell\r\ncode and recording event logs to effectively fight against previous attack means. At this time, the attack\r\nthinking lays great emphasis on how to downgrade to PowerShell V2.\r\nAs the PowerShell attack technology matures, attackers have carried out a lot of code obfuscations to evade\r\nprotection and logging. However, it is difficult to discover or confirm what these code is executed for, prior to\r\ncode execution. This makes attack detection and forensics a trickier job. For this reason, Microsoft has added the\r\nlog dumping and ScriptBlock logging functions to PowerShell V5.0 and later and logs all events to EID 4104. The\r\nScriptBlock logging gives the capability of recording de-obfuscated PowerShell code.\r\nAs script code needs to be de-obfuscated prior to execution, the ScriptBlock logging function records the actual\r\ncode before it is passed to the PowerShell engine for execution. Therefore, many centralized log systems hardly\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 9 of 15\n\nreport an alert when capturing suspicious logs. Of course, in my opinion, such alerts are valuable for sample\r\nanalysis and emergency forensics.\r\nTo enable ScriptBlock logging, users can run PowerShell V5 with administrative privileges and execute the\r\nfollowing commands:\r\nInstall-Module -Name scriptblocklogginganalyzer -Scope CurrentUser\r\nset-SBLLogSize -MaxSizeMB 1000\r\nEnalbe-SBL\r\nAlternatively, users can enable this function and record script file invocation information by configuring GPO\r\nsettings:\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 10 of 15\n\nCertainly, users can enable this function by modifying the following registry key:\r\nHKLM\\SOFTWARE\\Wow6432Node\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging →\r\nEnableScriptBlockLogging = 1\r\nPowerShell 5.0 supports Windows 7/2008 R2 and later. Though a number of enhanced logging functions in\r\nPowerShell 5.0 are reversely ported to PowerShell 4.0, we recommend that PowerSehll 5.0 be installed on each\r\nWindows platform.  PowerShell 5.0 provides functions unavailable in V4.0, such as generating logs for suspicious\r\nscript blocks.\r\n0x05 PowerShell V6 Providing PWSH—A New Attack Surface\r\nOut of functional requirements, PowerShell V6 supports more operating systems and also exposes a new attack\r\nsurface—PWSH.\r\nAs PowerShell is installed with PWSH on Linux and macOS among other operating systems, logging is an\r\nindispensable part, for the sake of security. PowerShell uses the os-log API on a local host to log in to Apple’s\r\nuniform logging system. On Linux, PowerShell uses the syslog-based logging function which Microsoft has\r\nelevated to a logging solution almost available across the platform.\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 11 of 15\n\nAttack thinking (from the perspective of Red Team): The addition of PowerShell to other systems, though\r\nfacilitating management by administrators, undoubtedly expands the attack surface of these systems. Besides, the\r\nlogging function is inadequate in the latest version currently available. During certain relevant tests, I find two\r\npoints: 1. Logs are generated once a PowerShell execution error is reported. 2. If PowerShell runs properly\r\nwithout an error, only two syslog logs are generated: “PowerShell console is starting up” and “PowerShell console\r\nis ready for user input”. For instance, creating a simple reverse shell is another method and this reverse PWSH\r\noperation is yet logged.\r\n0x06 Logging Bypass Vulnerability (CVE-2018-8415)\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 12 of 15\n\nA tampering vulnerability exists in PowerShell that could allow an attacker to execute unlogged code. To exploit\r\nthis vulnerability, an attacker would need to log on to the affected system and run a specially crafted application.\r\nThe security update addresses the vulnerability by correcting log management of special characters.\r\nMicrosoft describes and rates this vulnerability as “important” (yet to reach the severe level). Taking advantage of\r\nthis vulnerability, attackers, via crafted code, could bypass the ScriptBlock logging function that is mentioned\r\nabove. According to the patch indicated on the GitHub website, this vulnerability affects all PowerShell Core\r\nversions (including PWSH) and the patch remediation solution only replaces \\u0000 with \\u2400 in Unicode.\r\nFrom the comments included in the patch shown in the following figure, we can speculate about how the\r\nvulnerability works, which, to put it simply, is that truncating logs with null characters leads ScriptBlock logging\r\nto stop recording commands.\r\nThe vulnerability discoverer nicknamed @Malwrologist revealed this issue on his own Twitter profile as early as\r\nJuly 2018. Following the discoverer’s thinking, we have reproduced this vulnerability and found that because of\r\nthe null character restriction, this vulnerability can only be triggered during script execution. Due to inner\r\nrestrictions of the command-line environment, it is impossible to exploit this vulnerability using a single\r\ncommand. Of course, EID 4103 event logs cannot be truncated as intended during the execution of multiple\r\nspliced commands, with key-value pairs in the logs still left.\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 13 of 15\n\nAttack thinking (from the perspective of Red Team): Though key-value pairs are left after exploitation of the\r\nvulnerability, attack script code, in actual attack scenarios, features a complicated execution logic for\r\nimplementing related functions. Moreover, as EID 4103 logs lack the deobfuscation capability, generalizing script\r\nfunctions and attack intentions from a large amount of data incurs a high analysis cost. Clearly, this vulnerability\r\nis still very valuable for launching attacks.\r\n0x07 Conclusion\r\nAs a matter of fact, PowerShell has been widely exploited for carrying out attack activities of varied scales. For\r\ninstance, it can be seen in downloaders, horizontal scaling of the intranet, privilege maintaining system backdoor,\r\nand even attack events initiated by APT organizations such as MuddyWater and FruityArmor. Predictably,\r\nPowerShell will still be a hot technology in the coming years. Therefore, as important data support for alert\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 14 of 15\n\nmonitoring in this regard, PowerShell event logs must be given to full play. It is recommended that enterprise\r\nusers keep the PowerShell event viewer updated to the latest version all the time and enable ScriptBlock logging\r\nfor better defense.\r\nNSFOCUS Fu Ying Labs will keep abreast of the latest attack and defense technologies and threat risks. All\r\npeople interested in various attack and defense technologies are welcome to communicate with us.\r\n0x08 References\r\nhttps://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team/\r\nhttps://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8415\r\nhttps://github.com/PowerShell/PowerShell/pull/8253\r\nhttps://twitter.com/DissectMalware/status/1016462916059631616\r\nAbout NSFOCUS Fu Ying Labs\r\nNSFOCUS Fu Ying Labs focuses on security threat research and monitoring technologies, covering threat\r\nidentification, tracing, and capture technologies as well as threat actor identification technologies.\r\nBy doing research in botnet threats, anti-DDoS, web confrontation, threats of exploitation of vulnerabilities in\r\npopular service systems, ID authentication threats, digital asset threats, threats from the underground industry, and\r\nemerging threats, we have a good grasp of threats in the live network so as to identify risks, mitigate harms done\r\nby threats, and provide decision-making support for defense against threats.\r\nSource: https://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nhttps://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/\r\nPage 15 of 15\n\n  https://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/   \n0x03 PowerShell V3/V4 Featuring Comprehensive Logging  \nCompared with earlier versions, PowerShell V3/V4 provides a more comprehensive logging function. At this\ntime, attackers turn to obfuscation means to obscure logs so as to escape identification and detection. \nWindows PowerShell 3.0 improves the logging and tracing support for commands and modules, with support for\nEvent Tracing in Windows (ETW) logs, an editable LogPipelineExecutionDetails property of modules, and the\n   Page 7 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://nsfocusglobal.com/attack-and-defense-around-powershell-event-logging/"
	],
	"report_names": [
		"attack-and-defense-around-powershell-event-logging"
	],
	"threat_actors": [
		{
			"id": "0f47a6f3-a181-4e15-9261-50eef5f03a3a",
			"created_at": "2022-10-25T16:07:24.228663Z",
			"updated_at": "2026-04-10T02:00:04.905195Z",
			"deleted_at": null,
			"main_name": "Stealth Falcon",
			"aliases": [
				"FruityArmor",
				"G0038",
				"Project Raven",
				"Stealth Falcon"
			],
			"source_name": "ETDA:Stealth Falcon",
			"tools": [
				"Deadglyph",
				"StealthFalcon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "02e1c2df-8abd-49b1-91d1-61bc733cf96b",
			"created_at": "2022-10-25T15:50:23.308924Z",
			"updated_at": "2026-04-10T02:00:05.298591Z",
			"deleted_at": null,
			"main_name": "MuddyWater",
			"aliases": [
				"MuddyWater",
				"Earth Vetala",
				"Static Kitten",
				"Seedworm",
				"TEMP.Zagros",
				"Mango Sandstorm",
				"TA450"
			],
			"source_name": "MITRE:MuddyWater",
			"tools": [
				"STARWHALE",
				"POWERSTATS",
				"Out1",
				"PowerSploit",
				"Small Sieve",
				"Mori",
				"Mimikatz",
				"LaZagne",
				"PowGoop",
				"CrackMapExec",
				"ConnectWise",
				"SHARPSTATS",
				"RemoteUtilities",
				"Koadic"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "77aedfa3-e52b-4168-8269-55ccec0946f7",
			"created_at": "2023-01-06T13:46:38.453791Z",
			"updated_at": "2026-04-10T02:00:02.981559Z",
			"deleted_at": null,
			"main_name": "Stealth Falcon",
			"aliases": [
				"FruityArmor",
				"G0038"
			],
			"source_name": "MISPGALAXY:Stealth Falcon",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "2ed8d590-defa-4873-b2de-b75c9b30931e",
			"created_at": "2023-01-06T13:46:38.730137Z",
			"updated_at": "2026-04-10T02:00:03.08136Z",
			"deleted_at": null,
			"main_name": "MuddyWater",
			"aliases": [
				"TEMP.Zagros",
				"Seedworm",
				"COBALT ULSTER",
				"G0069",
				"ATK51",
				"Mango Sandstorm",
				"TA450",
				"Static Kitten",
				"Boggy Serpens",
				"Earth Vetala"
			],
			"source_name": "MISPGALAXY:MuddyWater",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "156b3bc5-14b7-48e1-b19d-23aa17492621",
			"created_at": "2025-08-07T02:03:24.793494Z",
			"updated_at": "2026-04-10T02:00:03.634641Z",
			"deleted_at": null,
			"main_name": "COBALT ULSTER",
			"aliases": [
				"Boggy Serpens ",
				"ENT-11 ",
				"Earth Vetala ",
				"ITG17 ",
				"MERCURY ",
				"Mango Sandstorm ",
				"MuddyWater ",
				"STAC 1171 ",
				"Seedworm ",
				"Static Kitten ",
				"TA450 ",
				"TEMP.Zagros ",
				"UNC3313 ",
				"Yellow Nix "
			],
			"source_name": "Secureworks:COBALT ULSTER",
			"tools": [
				"CrackMapExec",
				"Empire",
				"FORELORD",
				"Koadic",
				"LaZagne",
				"Metasploit",
				"Mimikatz",
				"Plink",
				"PowerStats"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "3c430d71-ab2b-4588-820a-42dd6cfc39fb",
			"created_at": "2022-10-25T16:07:23.880522Z",
			"updated_at": "2026-04-10T02:00:04.775749Z",
			"deleted_at": null,
			"main_name": "MuddyWater",
			"aliases": [
				"ATK 51",
				"Boggy Serpens",
				"Cobalt Ulster",
				"G0069",
				"ITG17",
				"Mango Sandstorm",
				"MuddyWater",
				"Operation BlackWater",
				"Operation Earth Vetala",
				"Operation Quicksand",
				"Seedworm",
				"Static Kitten",
				"T-APT-14",
				"TA450",
				"TEMP.Zagros",
				"Yellow Nix"
			],
			"source_name": "ETDA:MuddyWater",
			"tools": [
				"Agentemis",
				"BugSleep",
				"CLOUDSTATS",
				"ChromeCookiesView",
				"Cobalt Strike",
				"CobaltStrike",
				"CrackMapExec",
				"DCHSpy",
				"DELPHSTATS",
				"EmPyre",
				"EmpireProject",
				"FruityC2",
				"Koadic",
				"LOLBAS",
				"LOLBins",
				"LaZagne",
				"Living off the Land",
				"MZCookiesView",
				"Meterpreter",
				"Mimikatz",
				"MuddyC2Go",
				"MuddyRot",
				"Mudwater",
				"POWERSTATS",
				"PRB-Backdoor",
				"PhonyC2",
				"PowGoop",
				"PowerShell Empire",
				"PowerSploit",
				"Powermud",
				"QUADAGENT",
				"SHARPSTATS",
				"SSF",
				"Secure Socket Funneling",
				"Shootback",
				"Smbmap",
				"Valyria",
				"chrome-passwords",
				"cobeacon",
				"prb_backdoor"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434264,
	"ts_updated_at": 1775792062,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/27c3ee126ed2d85a3d7c0b5f3076b99f9095cf30.pdf",
		"text": "https://archive.orkl.eu/27c3ee126ed2d85a3d7c0b5f3076b99f9095cf30.txt",
		"img": "https://archive.orkl.eu/27c3ee126ed2d85a3d7c0b5f3076b99f9095cf30.jpg"
	}
}