{
	"id": "af0de7f0-6afe-4de4-8508-e9fb25ad9074",
	"created_at": "2026-04-06T00:17:21.577077Z",
	"updated_at": "2026-04-10T03:35:48.533442Z",
	"deleted_at": null,
	"sha1_hash": "fe8cfc6ec616c1632d85903b00a5094853ed9180",
	"title": "Reproducing the Microsoft Exchange Proxylogon Exploit Chain",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2676876,
	"plain_text": "Reproducing the Microsoft Exchange Proxylogon Exploit Chain\r\nBy Justin Copeland\r\nPublished: 2021-03-09 · Archived: 2026-04-05 19:21:01 UTC\r\nIntroduction\r\nIn recent weeks, Microsoft has detected multiple 0-day exploits being used to attack on-premises versions of\r\nMicrosoft Exchange Server in a ubiquitous global attack. ProxyLogon is the name given to CVE-2021-26855, a\r\nvulnerability on Microsoft Exchange Server that allows an attacker to bypass authentication and impersonate\r\nusers. In the attacks observed, threat actors used this vulnerability to access on-premises Exchange servers, which\r\nenabled access to email accounts, and install additional malware to facilitate long-term access to victim\r\nenvironments.\r\nThe Praetorian Labs team has reverse engineered the initial security advisory and subsequent patch and\r\nsuccessfully developed a fully functioning end-to-end exploit. This post outlines the methodology for doing so but\r\nwith a deliberate decision to omit critical proof-of-concept components to prevent non-sophisticated actors from\r\nweaponizing the vulnerability. While we have elected to refrain from releasing the full exploit, we know a\r\ncomplete exploit will be released by the security community shortly. Once the remaining steps are public\r\nknowledge, we will more openly discuss our end-to-end solution. We believe the hours/days in between will\r\nprovide additional time for our customers, companies, and countries alike to patch the critical vulnerability.\r\nMicrosoft has rapidly developed and published scripts, indicators, and emergency patches to aid in the mitigation\r\nof these vulnerabilities. Microsoft Security Response Center has published a blog post detailing these mitigation\r\nmeasures here. Of note, the URL rewrite module successfully prevents exploitation without requiring emergency\r\npatching, and should prove an effective rapid countermeasure to Proxylogon. However, as discussed elsewhere,\r\nexploitation of Proxylogon has been so widespread that operators of externally facing Exchange servers must turn\r\nto incident response and eviction.\r\nMethodology\r\nFor the reverse engineering process we implemented the following steps to allow us to perform both static and\r\ndynamic analysis of Exchange and its security patches:\r\nDiff: review differences between vulnerable version and patched version\r\nTest: deploy a full test environment of the vulnerable version\r\nObserve: instrument deployment to gain knowledge of typical network communication\r\nInvestigate: iterate over each CVE, connect patch diff to network traffic, and fabricate proof-of-concept\r\nexploits\r\nDiff\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 1 of 21\n\nBy examining the differences (diffing) between a pre-patch binary and post-patch binary we were able to identify\r\nexactly what changes were made. These changes were then reverse engineered to assist in reproducing the original\r\nbug.\r\nMicrosoft’s update catalog was helpful when grabbing patches for diffing. A quick search for the relevant software\r\nversion returned a list of security patch roll-ups that we used to compare the latest security patch against its\r\npredecessor. For example, by searching for “Security Update For Exchange Server 2013 CU23” we identified\r\npatches for a specific version of Exchange. Exchange 2013 was chosen here because it was the smallest set of\r\npatches for a version of Exchange vulnerable to CVE-2021-26855 and therefore easiest to diff.\r\nTo begin, we downloaded the latest (3/2/2021) and the previous (12/2/2021) security update rollup. By extracting\r\nthe .msp file from the .cab file, and unpacking the .msp file using 7zip, we were left with two folders of binaries to\r\ncompare.\r\nThe .msp update contains a few hundred binaries – most of which are .NET applications\r\nBecause most of the binaries were .NET applications we used dnSpy to decompile each binary to a series of\r\nsource files. To speed up analysis we automated decompilation and leveraged the comparison functionality of\r\nsource control by uploading each version to a GitHub repository as separate commits for comparison.\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 2 of 21\n\nDiffing on GitHub can help important changes stand out at a glance\r\nAn alternative diffing option that we also found helpful was Telerik’s JustAssembly. It was a little bit slower for\r\nobserving the actual file differences, but was helpful in immediately identifying where code had been added or\r\nremoved.\r\nJustAssembly succinctly shows changes for an entire dll\r\nWith this preparation complete, we needed to spin-up a target Exchange server to test against.\r\nTest\r\nTo begin, we set up a standard domain controller using the ADDSDeployment module from Microsoft. We then\r\ndownloaded the relevant Exchange installer (ex: https://www.microsoft.com/en-us/download/details.aspx?\r\nid=58392 for Exchange 2013 CU23) and performed the standard installation process.\r\nFor an Azure-based Exchange environment, we followed the steps outlined here, swapping the installer\r\ndownloaded in step 8 of `Install Exchange` with the correct Exchange installer found in the above link.\r\nAdditionally, we modified the PowerShell snippet in the server provisioning script to spin up a 2012-R2\r\nDatacenter server instead of the 2019 Server version.\r\n$vm=Set-AZVMSourceImage -VM $vm -PublisherName MicrosoftWindowsServer -Offer `Windows\r\nThis allowed for a quick deployment of a standalone Domain Controller and Exchange server, with a network\r\nsecurity group in place to prevent unwanted Internet-based exploitation attempts.\r\nObserve\r\nMicrosoft Exchange is composed of several backend components which communicate with one another during\r\nnormal operation of the server. From the user perspective, a request to the frontend Exchange server will flow\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 3 of 21\n\nthrough IIS to the Exchange HTTP Proxy, which evaluates mailbox routing logic and forwards the request on to\r\nthe appropriate backend server. This is shown in the diagram below.\r\nMicrosoft Exchange 2016 Client Access Protocol Architecture diagram\r\n(https://docs.microsoft.com/en-us/exchange/architecture/architecture#client-access-protocol-architecture)\r\nWe were interested in observing all traffic sent from the HTTP Proxy to the Exchange Back End as this should\r\ninclude many example requests from real services to help us better understand the source code and from requests\r\nin our exploit. Exchange is deployed on IIS, so we made a simple change to the Exchange Back End binding to\r\nupdate the port from 444 to 4444. Next, we deployed a proxy on port 444 to forward packets to the new bind\r\naddress.\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 4 of 21\n\nThe Exchange HTTP Proxy validates the TLS certificate of the Exchange Back End, so for our proxy to be useful,\r\nwe wanted to dump the “Microsoft Exchange” certificate from our test machine’s local certificate store. Since this\r\ncertificate’s private key is marked as non-exportable during the Exchange installation process, we extracted the\r\nkey and certificate using mimikatz:\r\nmimikatz# privilege::debugmimikatz# crypto::certificates /export /systemstore:LOCAL_M\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 5 of 21\n\nUsing mimikatz to extract the Exchange certificate and key from our test machine.\r\nWith the certificate and key in hand, we used a tool similar to socat, a multi-purpose network relaying tool, to\r\nlisten on port 444 using the Exchange certificate and relay connections to port 4444 (the actual Exchange Back\r\nEnd). The socat command might look like:\r\n# export the certificate and private key (password mimikatz)openssl pkcs12 -in 'CERT_\r\nWith our proxy configured, we began using Exchange as normal to generate HTTP requests and learn more about\r\nthese internal connections. Additionally, several backend server processes sent requests to port 444, allowing us to\r\nobserve periodic health checks, Powershell remoting requests, etc.\r\nInvestigate\r\nWhile each CVE is different, our general methodology for triaging a particular CVE was composed of five phases:\r\n1. Reviewing indicators\r\n2. Reviewing patch diff\r\n3. Connecting the indicators to the diff\r\n4. Connecting these code paths to proxied traffic\r\n5. Crafting requests to trigger these code paths\r\n6. Repeat\r\nWarming up with CVE-2021-26857\r\n“CVE-2021-26857 is an insecure deserialization vulnerability in the Unified Messaging service. Insecure\r\ndeserialization is where untrusted user-controllable data is deserialized by a program. Exploiting this vulnerability\r\ngave HAFNIUM the ability to run code as SYSTEM on the Exchange server.” – via Microsoft’s bulletin about the\r\nHAFNIUM exploits\r\nWhile this particular vulnerability was ultimately unnecessary to obtain remote code execution on the Exchange\r\nserver, it provided a straightforward example of how patch diffing can reveal the details of a bug. The advisory\r\nabove also explicitly identified the Unified Messaging service as a potential target – which significantly helped to\r\nnarrow the initial search space.\r\nThe Exchange binary packages were named fairly clearly – proxying functionality lived in\r\nMicrosoft.Exchange.HttpProxy.*, log uploading lived in Microsoft.Exchange.LogUploader, and Unified\r\nMessaging code lived in Microsoft.Exchange.UM.*. When diffing files we don’t always have clear indicators in\r\nthe file names, but there was no reason not to use this during our investigation.\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 6 of 21\n\nThe JustAssembly diff of these dlls indicates the root cause fairly clearly\r\nThe diffed classes here showed that a Base64Deserialize function had been removed and a\r\ncontactInfoDeserializationAllowList property had been added. .NET historically has struggled with\r\ndeserialization issues, so seeing these kinds of changes strongly suggested the removal of vulnerable code and the\r\naddition of protections against .NET deserialization exploitation. Examining Base64Deserialize confirms this:\r\nThe removed function passes the output of a base64 string to a BinaryFormatter’s Deserialize\r\nBefore the patch, this unsafe method was invoked from\r\nMicrosoft.Exchange.UM.UMCore.PipelineContext.FromHeaderFile as we observed by examining the diff:\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 7 of 21\n\nThe ContactInfo property of a serialized PipelineContext can be used to trigger the vulnerability\r\nThe updated version of this function included much more code for properly verifying types before deserializing\r\nthem.\r\nEssentially, this patch removed functionality that is vulnerable to a .NET deserialization attack which can be\r\nexploited using tools like ysoserial.net. While the attack path here is fairly straightforward, Unified Messaging is\r\nnot always enabled on servers and as a result our proof of concept exploit relied on CVE-2021-27065, discussed\r\nbelow.\r\nServer-Side Request Forgery (CVE-2021-26855)\r\nSince all of the remote code execution vulnerabilities require an authentication bypass, we turned our attention to\r\nthe Server-Side Request Forgery (SSRF). Microsoft published the following Powershell command to search for\r\nindicators related to this vulnerability:\r\nImport-Csv -Path (Get-ChildItem -Recurse -Path \"$env:PROGRAMFILESMicrosoftExchange Se\r\nAdditionally, Volexity published the following URLs related to SSRF exploitation:\r\n/owa/auth/Current/themes/resources/logon.css/owa/auth/Current/themes/resources/.../ec\r\nUsing these indicators, we searched the patch diff for related terms (including strings like host, hostname, fqdn,\r\netc.) and discovered interesting changes in Microsoft.Exchange.FrontEndHttpProxy.HttpProxy namespace. This\r\nled us to also discover a relevant diff in the BackEndServer class used by BEResourceRequestHandler .\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 8 of 21\n\nPatch diff related to ServerInfo / authentication / host / fqdn.\r\nPatch diff of the BackEndServer class used by BEResourceRequestHandler.\r\nNext, we traced calls to BEResourceRequestHandler and found this relevant path from the\r\nSelectHandlerForUnauthenticatedRequest method in ProxyModule .\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 9 of 21\n\nMinified code showing path to hit BEResourceRequestHandler.\r\nLastly, we evaluated the CanHandle method of BEResourceRequestHandler and found that it required a URL\r\nwith the ECP “protocol” (e.g. /ecp/), a X-BEResource cookie, and a URL that ended with a static file type\r\nextension (e.g. js, css, flt, etc.). Since this code was implemented in the HttpProxy, the URL did not need to be\r\nvalid, which explained the fact that some indicators simply used /ecp/y.js , a non-existent file.\r\nThe X-BEResource cookie was parsed in BackEndServer.FromString , which effectively split the string on \"~\"\r\nand assigned the first element to an “fqdn” for the backend and parsed the second as an integer version.\r\nWe then traced the usage of this BackEndServer object and discovered it was used in the ProxyRequestHandler\r\nto determine which Host to send the proxied request to. The URI was constructed in\r\nGetTargetBackEndServerUrl via a UriBuilder , which is a native .NET class.\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 10 of 21\n\nMinified code showing relevant methods from ProxyRequestHandler.\r\nAt this point, we could theoretically control the Host used for these backend connections by setting a specific\r\nheader and sending requests to a “static” file in /ecp. However, simply controlling the Host is not enough to call\r\narbitrary endpoints on the Exchange Back End. For this, we looked inside the .NET source code itself to see how\r\nUriBuilder is implemented.\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 11 of 21\n\nToString method from the UriBuilder reference source code.\r\nAs shown in the snippet above, the ToString method of UriBuilder (which is used to construct URIs) performs\r\nsimple string concatenation with our inputs. Therefore, if we set Host to be \"example.org/api/endpoint/#\" , we\r\neffectively gain full control over the target URL.\r\nWith this information, we had enough to demonstrate the SSRF with the following HTTP request…\r\nFailed SSRF attempt to example.org due to Kerberos host mismatch.\r\nAlas! Our SSRF attempt “failed” due to a NegotiateSecurityContext error communicating with example.org.\r\nAs it turned out, this error was key to our understanding of the SSRF, as it demonstrated the fact that the HTTP\r\nProxy was attempting to authenticate via Kerberos to the backend server. By setting the hostname to the Exchange\r\nserver machine name, the Kerberos authentication succeeds and we can access endpoints as NT AUTHORITYSYTEM .\r\nWith this information, we had enough to demonstrate SSRF with the following HTTP request…\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 12 of 21\n\nFailed SSRF attempt due to backend authentication check.\r\nAlas! Again! The backend server rejected our request for some reason. Tracing this error, we eventually\r\ndiscovered the EcpProxyRequestHandler.AddDownLevelProxyHeaders method, which is only called if\r\nProxyToDownLevel is set to true in the GetTargetBackEndServerUrl method. This method checked that the user\r\nwas authenticated and returned an HTTP 401 error if they were not.\r\nThankfully, we can prevent GetTargetBackEndServerUrl from setting this value by modifying the server version\r\nin our cookie. If the version was greater than Server.E15MinVersion , ProxyToDownLevel remained false. With\r\nthis change in place, we successfully authenticated to a backend service (the autodiscover service).\r\nSuccessful SSRF to the autodiscover endpoint.\r\nWhile reviewing the code paths above, we discovered an additional SSRF in the OWA proxy handler. These\r\nrequests were sent without Kerberos authentication and therefore could be targeted to arbitrary servers as shown\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 13 of 21\n\nbelow.\r\nSuccessful SSRF attempt to example.org via X-AnonResource cookie.\r\nAt this point, we had enough information to forge requests to some backend services. We are not publishing\r\ninformation on how to properly authenticate to more sensitive services (e.g. /ecp) as this information is not\r\npublicly available.\r\nArbitrary File Write (CVE-2021-27065)\r\nWith SSRF in hand, we turned our attention to remote code execution. Before we began patch diffing, our first\r\nclue on this vulnerability came from the indicators published by Microsoft and Volexity. Namely, this Powershell\r\ncommand to search the ECP logs for indicators of compromise:\r\nSelect-String -Path \"$env:PROGRAMFILESMicrosoftExchangeServerV15LoggingECPServer*.log\r\nAdditionally, the Volexity blog post described requests to /ecp/DDI/DDIService.svc/SetObject as related to\r\nexploitation. With these two facts in hand, we searched our diff for anything related to file I/O in the ECP or DDI\r\nclasses. This quickly came back with a result for the WriteFileActivity class in\r\nMicrosoft.Exchange.Management.ControlPanel.DIService . The “control panel” is the user-facing name for ECP\r\nand DDIService is directly in the indicator URL. As shown in the diff below, the old functionality wrote a file with\r\na user-controlled name directly to disk. In the new functionality, the code appends a “.txt” file extension if not\r\nalready present. Knowing that the general exploit involved writing an ASPX webshell to the server, the\r\nWriteFileActivity seemed like a prime candidate for exploitation.\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 14 of 21\n\nPatch diff of WriteFileActivity.cs\r\nIf we search the Exchange installation directory for WriteFileActivity, we see it used in several XAML files within\r\nExchange ServerV15ClientAccessecpDDI.\r\nCode snippet from ResetOABVirtualDirectory.xaml\r\nAfter examining the XAML files and reviewing the ECP functionality in the Exchange web UI, we determined\r\nthat the SetObjectWorkflow above described a series of steps to be executed server-side (including Powershell\r\ncmdlet execution) to perform a specific operation.\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 15 of 21\n\nECP user interface showing the configuration options for ResetVirtualDirectory.\r\nBy submitting a sample ResetVirtualDirectory request, we observed that the Exchange server wrote a pretty-printed configuration of the VirtualDirectory to the specified path, removed the VirtualDirectory, and recreated it.\r\nThis configuration file contained several properties from the directory and could be written to any directory on the\r\nsystem with an arbitrary extension. A screenshot of the request and resulting file are shown below.\r\nExample HTTP request to the DDIService to reset the OAB VirtualDirectory:\r\nPOST /ecp/DDI/DDIService.svc/SetObject?schema=ResetOABVirtualDirectory\u0026msExchEcpCana\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 16 of 21\n\nFile exported by the DDIService showing all properties of the VirtualDirectory.\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 17 of 21\n\nECP web UI showing editable parameters for a VirtualDirectory.\r\nThe following parameters were exposed in the UI for editing a VirtualDirectory. Notably, the Internal URL and\r\nExternal URL were exposed in the UI, described in the XAML as parameters, and written to the file at our\r\narbitrary path. This combination of factors allowed an attacker controlled input to reach an arbitrary path, which is\r\nthe necessary primitive to enable a webshell.\r\nAfter some experimentation, we determined that the Internal/External URL fields was partially validated by the\r\nserver. Namely, the server validated the URI scheme, hostname, and imposed a maximum length of 256 bytes.\r\nAdditionally, the server “percent encoded” any percent signs in the payload (e.g. “%” become “%25”). As a result,\r\na classic ASPX code block like \u003c% code %\u003e was transformed into \u003c%25 code %25\u003e which is invalid. However,\r\nother metacharacters (e.g. \u003c and \u003e) were not encoded, allowing injection of a URL like the following:\r\nhttp://o/#\u003cscript language=\"JScript\" runat=\"server\"\u003efunction Page_Load(){eval(Request\r\nAfter resetting the VirtualDirectory, this URL was embedded in the export and saved to the path of our choosing,\r\ngranting remote code execution on the Exchange server.\r\nUsing webshell to execute commands on compromised Exchange server.\r\nLeaking the Backend + Domain\r\nThe complete exploit chain requires the Exchange server backend and domain. In Crowdstrike’s blog post about\r\nthe attack they posted a full log of the attack being sprayed across the Internet. In this log, the first call was to an\r\n/rpc/ endpoint:\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 18 of 21\n\nThe initial request hits the /rpc/ exposed by Exchange\r\nThis initial request must be unauthenticated, and is likely utilizing RPC over HTTP which essentially exposes\r\nNTLM authentication through the endpoint. RPC over HTTP is itself a fairly complicated protocol which is\r\nthoroughly detailed via Microsoft’s open specification initiative.\r\nAs attackers, we were interested in parsing the NTLM Challenge message that is returned to us after sending an\r\nNTLM Negotiation message. This challenge message contains a number of AV_PAIR structures that contain the\r\ninformation we are interested in – specifically MsvAvDnsComputerName (the backend server name) and\r\nMsvAvDnsTreeName (the domain name).\r\nImpacket’s http.py already contains code to perform this negotiation to generate a negotiation message and then\r\nparse the challenge response into AV_PAIR structures. The request and response ends up looking like:\r\nRPC_IN_DATA /rpc/rpcproxy.dll HTTP/1.1Host: frontend.exchange.contoso.comUser-Agent:\r\nHTTP/1.1 401 UnauthorizedServer: Microsoft-IIS/8.5request-id: 72dce261-682e-4204-a15a\r\nThe base64 encoded hash can be parsed using Impacket to show the leaked domain information.\r\nLeaked domain information embedded in the WWW-Authenticate NTLM Challenge\r\nThe recovered AV_PAIR data is encoded as Windows Unicode and maps a specific AV_ID to a value. AV_IDs\r\nare constants that map to specific content, for example, we want to grab the strings for 3 (the backend hostname)\r\nand 5 (the domain).\r\nMappings for the AV_PAIR structures to numbers in the calculated data\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 19 of 21\n\nThe information posted here resolves that the backend value is ex.corp.contoso.com and the domain is\r\ncorp.contoso.com. These are the values needed to abuse the SSRF vulnerability discussed earlier.\r\nHomework\r\nAs described elsewhere, we have omitted certain exploit details to prevent ease of exploitation. The mechanism\r\nthrough which the exploit authenticates to ECP endpoints as arbitrary users is left as an exercise to the reader. We\r\nwill release further details on this in a follow-up blog post once sufficient time has elapsed.\r\nDetection\r\nMicrosoft’s Threat Intel Center (MSTIC) has already provided excellent indicators and detection scripts which\r\nanyone with an on premise Exchange server should use. To determine if there is a compromise we recommend\r\nSOCs, MSSPs, and MDRs take the following steps:\r\n1. Ensure all endpoint protection products are updated and functioning. While the exploit itself may not have\r\na large quantity of IoCs published to detection engines yet, post exploitation activity can be easily detected\r\nwith modern tooling.\r\n2. Run the “TestProxyLogon.ps1” script from Microsoft’s github linked above across all Exchange servers.\r\nFrom our experience with the weaponization of the exploit the script should detect any evidence of an\r\nexploited system.\r\n3. Double check the configuration of the Servers in question, scheduled tasks, autoruns etc, are all places that\r\nan attacker could be hiding after gaining initial access. Ensure the Audit Process Creation audit policy and\r\nPowerShell logging are enabled for Exchange servers and check for suspicious commands and scripts.\r\nDiscrepancies should be verified, reported, and remediated ASAP.\r\nAs we continue our exploration of these vulnerabilities, we intend to publish additional material on detecting any\r\nevidence of this exploit in your environment.\r\nPost-Exploitation\r\nPrevious work by Sean Metcalf and Trimarc Security details the high level of permissions that often accompany\r\non-premise Exchange installations. When configured in this way, an attacker with control of an Exchange server\r\ncan easily use this access for domain-wide compromise with an ACL abuse. Affected environments can determine\r\nif site-wide compromise should be suspected by examining the ACLs applied to the root domain object, and\r\nobserving whether or not vulnerable Exchange resources fall into these groups. We have adapted the PowerShell\r\nsnippet in the Trimarc post to more specifically filter on the Exchange Windows Permissions and Exchange\r\nTrusted Subsystem groups. If your environment has added Exchange resources to custom groups or groups outside\r\nof these, you will need to adapt the script accordingly.\r\nimport-module ActiveDirectory$ADDomain = ''$DomainTopLevelObjectDN = (Get-ADDomain $A\r\nAcknowledgements\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 20 of 21\n\nReproduction of this bug did not happen in a vacuum -our development process relied on the published works of\r\nthe original researchers, incident responders, and other security researchers who also worked to reproduce these\r\nbugs. Our thanks and appreciation go out to:\r\nDEVCORE-Who found the original bug\r\nVolexity-Who identified the bug in the wild\r\n@80vul-The first user seen to reproduce the exploit chain\r\nRich Warren (@buffaloverflow)-Who we actively worked with while investigating\r\nCrowdstrike-Who published additional information about active exploitation in the wild\r\nMicrosoft-Who quickly published indicators and patches\r\nSource: https://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nhttps://www.praetorian.com/blog/reproducing-proxylogon-exploit/\r\nPage 21 of 21",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.praetorian.com/blog/reproducing-proxylogon-exploit/"
	],
	"report_names": [
		"reproducing-proxylogon-exploit"
	],
	"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": 1775434641,
	"ts_updated_at": 1775792148,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/fe8cfc6ec616c1632d85903b00a5094853ed9180.pdf",
		"text": "https://archive.orkl.eu/fe8cfc6ec616c1632d85903b00a5094853ed9180.txt",
		"img": "https://archive.orkl.eu/fe8cfc6ec616c1632d85903b00a5094853ed9180.jpg"
	}
}