{ "id": "322bb729-7d45-4402-967e-b1709db95933", "created_at": "2026-04-06T00:08:36.236991Z", "updated_at": "2026-04-10T03:35:48.477001Z", "deleted_at": null, "sha1_hash": "64cd2437964fbe72d5f04301519911ffb1a92a6a", "title": "Detecting HAFNIUM Exchange Server Zero-Day Activity in Splunk | Splunk", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 85876, "plain_text": "Detecting HAFNIUM Exchange Server Zero-Day Activity in\r\nSplunk | Splunk\r\nBy Ryan Kovar\r\nPublished: 2021-03-03 · Archived: 2026-04-05 13:33:01 UTC\r\nIf you want just to see how to find HAFNIUM Exchange Zero-Day Activity, skip down to the “detections”\r\nsections. Otherwise, read on for a quick breakdown of what happened, how to detect it, and MITRE ATT\u0026CK\r\nmappings.\r\nIntroduction to HAFNIUM and the Exchange Zero-Day Activity\r\nWhat you need to know\r\nYou may be thinking, “another Tuesday filled with patches, just like any other month.” That may be true to some\r\nextent, but it is essential to point out based on Volexity’s blog that:\r\nI don’t know about you, but whenever I see an adversary stealing copies of my Active Directory (AD) database,\r\nthat sends chills down my spine because, at that point, I am rebuilding my entire AD from scratch as part of my\r\nremediation effort. For more color, stealing the AD database implies that the adversary will have domain\r\nadministrator privilege, so this is important to investigate.\r\nOWA! That hurts!\r\nSome of these vulnerabilities are being exploited via Outlook Web Services (OWA), a commonly enabled feature\r\nof Exchange Server 2013, 2016, and 2019. Underlying OWA is Microsoft’s venerable web server, Internet\r\nInformation Services (IIS). It just so happens that elements of this attack can be detected by looking for the\r\nappropriate POST requests in IIS logs.\r\nWait just a moment! Splunk is super good at ingesting logs from all sources and looking for patterns in them! All\r\nwe need to do is ensure that logs are being ingested from our OWA servers appropriately.\r\nOur recipe for success is to use the Splunk Universal Forwarder and add in a little bit of the Splunk-supported\r\nTechnical Add-On for Microsoft IIS. Next, add something like this to your inputs.conf file so that you can ingest\r\nall of the exciting logs in the C:\\inetpub\\logs\\LogFiles directory in W3C format. This will let you search through\r\nthe IIS access logs for unusual User-Agent string patterns known to be associated with this attack, as was\r\nmentioned earlier today by our friends at Red Canary. You’ll also want to add a monitoring entry to capture log\r\nactivity in C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Logging\\HttpProxy.\r\nRefer to the Volexity blog post for other interesting User-Agents seen both pre and post-exploit.\r\nhttps://www.splunk.com/en_us/blog/security/detecting-hafnium-exchange-server-zero-day-activity-in-splunk.html\r\nPage 1 of 6\n\nYes, Yet Again, We Need Windows Events and Command Line Auditing\r\nWhile you’re under the hood of that Universal Forwarder, you might as well ensure you’re collecting both\r\nWindows Security events of interest and process start events, as both of those are important for certain HAFNIUM\r\ndetections. For this, we recommend you use the Technical Add-On for Windows and also collect event 4688 (with\r\ncommand line arguments) from the Security event log, OR you can always use Microsoft Sysmon and collect\r\nevent 1. These process start events can be searched for anomalous execution of the Exchange UM service.\r\nYou can also configure auditing on your Exchange server UM process and then search for Windows 4663 events\r\nfor suspicious FileCreated events (in this case, the web shells.) However, be careful here - the possibility to\r\ngenerate many thousands of 4663 events exists if you do not set up your auditing policies correctly!\r\nFinally, collect the Application log from your Exchange servers, again using the Windows TA. This allows you to\r\nsearch for errors in the log containing specific patterns in the RenderedDescription field about the Exchange UM\r\nservice’s execution.\r\nDetecting HAFNIUM and Exchange Zero-Day Activity in Splunk\r\nHere we will give you some hot-off-the-press searches to help find some of the HAFNIUM badness derived from\r\nthe Volexity and Microsoft blogs. If we have coverage for these searches in ESCU, we call them out further below\r\nin the MITRE ATT\u0026CK section.\r\nPlease note that the actual remote code execution (RCE) proof of concept (POC) for these CVEs has not been\r\npublicly released. As such, the detections below are all derived from the original blogs from Microsoft and\r\nVolexity. When we have more information, we will publish updates!\r\nIndicators of Compromise (IOCs)\r\nBoth Volexity and Microsoft published IOCs, including IP addresses of observed attackers, web shell hashes and\r\nfilenames, and user-agents in their blog posts. We have converted these indicators into simple CSV format so that\r\nyou may use them as lookup tables - they are posted here. But what’s a lookup table, and how does it help with\r\nsecurity detection in Splunk? Got you covered there, too.\r\nAuthentication Bypass Vulnerability\r\nFrom Volexity’s blog, we see that this exploit is bypassing authentication and then moving to access users’ emails\r\nwith minimal effort. The exploit requires an HTTP POST to files in a specific directory\r\n/owa/auth/Current/themes/resources/.\r\nWe can detect this behavior via the following search, which requires ingesting the IIS logs on the Exchange OWA\r\nserver.\r\nindex=* sourcetype=\"ms:iis:auto\" http_method=POST uri_path=\"/owa/auth/Current/themes/resources/*\"\r\n| stats count by src_ip, http_user_agent, uri_path, http_method, uri_query\r\nhttps://www.splunk.com/en_us/blog/security/detecting-hafnium-exchange-server-zero-day-activity-in-splunk.html\r\nPage 2 of 6\n\nNishang PowerShell framework\r\nOne of the tools used by HAFNIUM in this attack was using the Nishang PowerShell framework. One method\r\nwould be to look for PowerShell messages where the Nishang commandlets called out in the Microsoft blog\r\nwould be detected:\r\nindex=\"*\" sourcetype=\"WinEventLog\" source=\"WinEventLog:Security\" EventCode=4104 Message=\"* Invoke-PowerShellTCP\r\nAnother would be to use other would use event code 4688 and find some of the specific activity executed:\r\nindex=\"*\" sourcetype=\"WinEventLog\" source=\"WinEventLog:Security\" EventCode=4688 Creator_Process_Name=\"powershel\r\nPowercat detection\r\nThe adversary used PowerShell to download and execute Powercat in memory. We’ve talked about PowerShell\r\nand IEX cradles for years at Splunk (like this blog and this .conf16 talk). One simple way to detect if you were\r\naffected by this activity is to make sure you are bringing in event code 4104 and check for “powercat”:\r\nindex=\"*\" sourcetype=\"WinEventLog\" source=\"WinEventLog:Security\" EventCode=4104 Message=\"*powercat*\"\r\nExchange Unified Messaging Service Creating Executable Content\r\nThe Unified Messaging Service in Microsoft Exchange Server may be abused by HAFNIUM to create executable\r\ncontent in common server-side formats such as PHO, JSP, ASPX, etc. It is unusual and dangerous for a server-side\r\ncomponent like the Unified Messaging Service to create new executable content. Such content, if subsequently\r\nexecuted, could be used for remote code execution. This search inspects Event ID 4663 file system audit logs for\r\nevidence that the Unified Messaging service has been misused to create new executable content on the server.\r\nindex=* sourcetype=WinEventLog source=\"WinEventLog:Security\" EventCode=4663 Object_Type=\"File\" (Object_Name=\"*\r\nExchange Unified Messaging Service Creating Child Process\r\nThe Unified Messaging Service in Microsoft Exchange Server may be abused by HAFNIUM to launch child\r\nprocesses. Watching for unusual parent processes is a well-established detection technique that we can adapt and\r\napply in this situation. This Splunk search takes advantage of Windows Event ID 4688, also referred to as Process\r\nCreation events. When the parent process is related to Exchange Unified Messaging, the process may be\r\nsuspicious. This search employs a NOT clause to help reduce noise.\r\nhttps://www.splunk.com/en_us/blog/security/detecting-hafnium-exchange-server-zero-day-activity-in-splunk.html\r\nPage 3 of 6\n\nindex=* sourcetype=\"WinEventLog\" source=\"WinEventLog:Security\" EventCode=4688 (Creator_Process_Name=\"*umworkerp\r\nFinding Hacker Tools\r\nSuspicious zip, rar, and 7z files that are created in C:\\ProgramData\\ may indicate possible data staging for\r\nexfiltration. The searches below for Sysmon and Windows Event logs, respectively, may assist in identifying these\r\nfiles.\r\nindex=* (sourcetype=\"XmlWinEventLog:Microsoft-Windows-Sysmon/Operational\" OR source=\"XmlWinEventLog:Microsoft-W\r\nOR\r\nindex=* (sourcetype=\"WinEventLog\" source=\"WinEventLog:Security\" OR sourcetype=XmlWinEventLog source=\"XmlWinEve\r\nIt has also been noted that the execution of 7-Zip to create archives as a means of staging data for exfiltration has\r\nbeen utilized as well. To determine if this specific file has been executed, the following searches using Sysmon\r\nand Windows Event logs, respectively, can be used as a starting point.\r\nindex=* (sourcetype=\"XmlWinEventLog:Microsoft-Windows-Sysmon/Operational\" OR source=\"XmlWinEventLog:Microsoft-W\r\nOR\r\nindex=* (sourcetype=\"WinEventLog\" source=\"WinEventLog:Security\" OR sourcetype=XmlWinEventLog source=\"XmlWinEve\r\nWeb Shells\r\nIf you don’t have IIS logs, don’t fret, Wire data (like Splunk for Stream) or Zeek logs that capture web traffic can\r\nalso serve as a way of gaining some visibility. Obviously, we need a “Hunting with Splunk” post on the subject!\r\nHowever, until then, check out this classic Youtube video from James Bower about how to hunt web shells with\r\nSplunk.\r\nSplunk Enterprise Security and ESCU\r\nKnow thyself\r\nWhile we have spent some time explaining that this attack is essential and effort needs to be put toward\r\ninvestigating this, it is also important to note that the basics are important. Basic asset management, hopefully via\r\nyour asset and identity framework, will tell you where your Exchange servers reside. Running regular\r\nvulnerability scans that integrate into Splunk will display which Exchange servers are vulnerable and can help you\r\nprioritize your patching schedule and better focus your detection efforts.\r\nhttps://www.splunk.com/en_us/blog/security/detecting-hafnium-exchange-server-zero-day-activity-in-splunk.html\r\nPage 4 of 6\n\nThreat Intelligence Framework\r\nIf you are using Splunk Enterprise Security, the lookups of IOCs that are listed above can be ingested easily into\r\nthe threat intelligence framework. Perhaps you aren’t sure how to do that. No worries, we published some\r\nguidance and a how-to on integrating lists of IOC into the Enterprise Security threat intelligence framework.\r\nEnterprise Security Content Updates (ESCU)\r\nFor folks using ESCU, our Security Research team will release a new Splunk Analytic Story called “HAFNIUM\r\nGroup” on March 4th, 2021, containing detections for this threat. Saying that, check out the MITRE ATT\u0026CK\r\ntable below. If you have ESCU running today, you already have some great coverage!\r\nMITRE ATT\u0026CK\r\nReviewing the blog posts from Microsoft and Volexity, we mapped the adversary’s activity to MITRE ATT\u0026CK.\r\nEach tactic is then linked to Splunk Content to help you hunt for that information. Be aware; these searches are\r\nprovided as a way to accelerate your hunting. We recommend you configure them via the Splunk Security\r\nEssentials App. You may need to modify them to work in your environment! Many of these searches are\r\noptimized for use with the tstats command.\r\nFinally, as more information becomes available, we will update these searches if more ATT\u0026CK TTPs become\r\nknown.\r\nHere is a list of all the MITRE ATT\u0026CK TTP’s that we saw being used in this attack:\r\nT1003.001, T1005, T1027, T1046, T1059, T1059.001, T1070, T1071, T1074.002, T1083, T1110, T1190, T1505,\r\nT1560.001, T1589.002, T1590.002\r\nConclusion\r\nWe know that this is a significant vulnerability and that customers will want to patch as soon as possible and\r\ndetermine if they were affected by this attack in the past. If you haven’t patched yet (we’ve all been there),\r\nhopefully, these searches will provide you the ability to have more visibility into your environment and any\r\nmalicious activity that you might be experiencing. If they don’t work perfectly, think of them as\r\n“SplunkSpiration” :-). As soon as we have more information, we will update this blog and, as we talked about\r\nearlier, be on the lookout for more detections from our threat research team that will be released through\r\nEnterprise Security Content Updates.\r\nAs always, security at Splunk is a family business. Credit to authors and collaborators:\r\nMick Baccio\r\nJames Brodsky\r\nShannon Davis\r\nMichael Haag\r\nAmy Heng\r\nJose Hernandez\r\nhttps://www.splunk.com/en_us/blog/security/detecting-hafnium-exchange-server-zero-day-activity-in-splunk.html\r\nPage 5 of 6\n\nDave Herrald\r\nRyan Kovar\r\nMarcus LaFerrera\r\nJohn Stoner\r\nSource: https://www.splunk.com/en_us/blog/security/detecting-hafnium-exchange-server-zero-day-activity-in-splunk.html\r\nhttps://www.splunk.com/en_us/blog/security/detecting-hafnium-exchange-server-zero-day-activity-in-splunk.html\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "MISPGALAXY", "Malpedia" ], "references": [ "https://www.splunk.com/en_us/blog/security/detecting-hafnium-exchange-server-zero-day-activity-in-splunk.html" ], "report_names": [ "detecting-hafnium-exchange-server-zero-day-activity-in-splunk.html" ], "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": 1775434116, "ts_updated_at": 1775792148, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/64cd2437964fbe72d5f04301519911ffb1a92a6a.pdf", "text": "https://archive.orkl.eu/64cd2437964fbe72d5f04301519911ffb1a92a6a.txt", "img": "https://archive.orkl.eu/64cd2437964fbe72d5f04301519911ffb1a92a6a.jpg" } }