Site icon Sophos News

Observing OWASSRF Exchange Exploitation… still

  • Benjamin Sollman and Colin Cowie

    • Late last year, Sophos X-Ops responded to exploitation of what appeared to be the ProxyNotShell attack flow, which targets Microsoft Exchange servers, and which Microsoft attempted to address in an early-November patch. That patch targeted two vulnerabilities, CVE-2022-41080 and CVE-2022-41082, which when attacked could result in remote code execution on vulnerable systems.

    Right before the December holidays, however, X-Ops’ MDR team saw additional exploitation campaigns against Microsoft Exchange servers, leveraging (nearly) the same two vulnerabilities. This was followed by sustained activity in January, including attacks on high-profile entities such as RackSpace, leading up to a law-enforcement takedown of the Hive network and its infrastructures. This network has been linked in the past to the PLAY ransomware, which makes use of the OWASSRF technique associated with the two vulnerabilities. However, additional ransomware entities, such as Cuba, have also been seen making use of the flaw, and some reports suggest that PLAY shares infrastructure with yet other ransomware groups such as Quantum as well as the SVCReady and Emotet botnets.

    The situation was both tangled and active, and by the end of January, the US Cybersecurity and Infrastructure Security Agency (CISA) had taken the strong step of ordering federal executive-branch agencies to apply the available patches, strongly recommending that other organizations do the same.

    This post details some of our observations and provides visibility into current indicators of compromise associated with the attacks.

    Prologue: CVE-2022-41040 and CVE-2022-41082

    The two vulnerabilities in Microsoft Exchange Server that made ProxyNotShell possible were first publicly flagged in October, though attacks in the wild were underway not later than midsummer of 2022. The attack based on the pair was dubbed “ProxyNotShell” by the industry at large, for its similarity to the notorious ProxyShell attacks of 2021 – in both cases, a server-side request forgery (SSRF) attack followed by remote code execution (RCE). In response, Microsoft released first a hotfix, then a patch that provided URL Rewrite rule improvements.

    The Holiday Rush

    Unfortunately, these improvements were swiftly bypassed by a technique dubbed “OWASSRF” by CrowdStrike and LogPoint researchers, among many others. It is an awkward but descriptive moniker: The OWASSRF technique once again chains two CVEs – CVE-2022-41080 allows an SSRF-like privilege escalation against an Outlook Web Access (OWA) endpoint, replacing CVE-2022-41040’s SSRF against an AutoDiscover endpoint on an Exchange server; CVE-2022-41082 allows RCE as it did before — to achieve a ProxyShell / ProxyNotShell-style attack via OWA.

    On November 26, Sophos MDR Operations began responding to novel Microsoft Exchange exploitation efforts that resembled ProxyNotShell. The Sophos MDR team observed post-compromise activity in multiple unique environments. In all cases, the threat actor was evicted prior to successfully completing the attack. Unit 42 also reported eight incidents with similar observations around that time.

    During December 2022, CrowdStrike published research about a ProxyNotShell bypass identified during a PLAY ransomware incident. Unit42 also continued to report multiple incidents with similar observations. In this timeframe, the MDR Operations team observed a variety of activities spawning from the IIS Worker Process (w3wp.exe) following successful exploitation with OWASSRF. This led to the execution of encoded PowerShell commands, reconnaissance via domain logging tools, usage of BITSAdmin for file transfers, attempted installation of dual-use agents, and enablement of remote connections.

     

    Figure 1: A snippet of the threat actor’s OWASSRF exploitation tooling (poc.py). Among other findings, we noted that the email address owa/mastermailbox<at>outlook.com occurred in multiple POST requests made to the Exchange servers in question.

    As stated above, we saw encoded PowerShell commands spawning from w3wp. These encoded commands spawned child processes that performed the following actions:

    Observed command-and-control (C2) IP addresses during this period included:

    While investigating 179.60.149[.]28 back in December, Dray Agha from HuntressLabs recovered the exploit script (poc.py), along with other post-compromise tooling. CrowdStrike researchers attempted to run the poc.py script against Exchange servers. They were able to replicate the exploit on Exchange servers that had not been updated to the latest November patch (KB5019758). However, this exploit could not be replicated successfully on servers running the November update.

    Figure 2: Multiple defenders have been working to observe, identify, report, and analyze OWASSRF in its various aspects

    An Attempt to Turn the Tables

    Over the course of the last half of December 2022, Sophos observed new threat actor activity following the OWASSRF mitigation bypass. Given the tools, tactics, and procedures used, we believe this threat actor intended to deploy ransomware. (As noted above, they failed.) As one would expect from malware of this type, we saw varied use of living-off-the-land binaries (LOLbins), including the perpetually abused PowerShell, PsExec, and RDP. Legitimate-but-abused third-party tools included WinRAR.

    After exploiting vulnerable Exchange servers, the attackers used encoded PowerShell commands to write GoToAssist Remote Support and multiple other malicious files to the %PROGRAMDATA% folder:

    Note the last item on this list. In February 2022, Mandiant published research about incidents in which malware using the naming schema “komar<.>dll” (with an apparently random number appended) was observed prior to Cuba ransomware deployment. These findings were later echoed by CISA.gov’s Cuba information roundup. (Interesting fact: While “komar” is the Russian word for “mosquito,” the Komar designation might be more familiar to some readers as the NATO reporting name for a class of guided-missile patrol craft used by the Soviet Navy, Cuban Revolutionary Navy, and others. A Komar-class craft was the first to sink another ship using anti-ship missiles.)

    PLAY likewise takes aim at defenders, attempting to disable antimalware and logging tools in use, including Microsoft’s own Windows Defender features (in that case via PowerShell). After the DLL files listed above triggered Cobalt Strike detections, the threat actor even attempted to leverage tools to disable Sophos protections, including an attempt to bring their own driver file:

    The Windows Service Control Manager program was executed to load this driver:

    This driver file uses a code-signing certificate from Beijing Kate Zhanhong Technology Co.,Ltd. that has been used in conjunction with malware the past, most notably with DirtyMoe.

    For more research from Sophos X-Ops on the rise of signed-driver malware, please see “Signed driver malware moves up the software trust chain.”

    Mitigations

    Existing mitigations are in place for those running on-premises Exchange servers, which are covered by Microsoft’s November 8, 2022 cumulative update (KB5019758). Release versions can be found here. It’s important to note that even though the Microsoft patch has been on offer for over a quarter of a year, there are unfortunately plenty of unpatched Exchange servers at risk. (It has been suggested that this was initially a communication failure, as Microsoft had incorrectly marked the CVE-2022-41080 patch as an elevation of privilege issue, not RCE, though the company corrected the error in later communications.) Worse, ransomware writers are adapting, using hands-on-keyboard techniques to navigate targeted systems, as we’ve shown above. Patching, log monitoring, and vigilance should both be considered core defenses as the situation evolves.

    A full list of Indicators of Compromise related to this analysis has been published to the IoC directory on SophosLabs’ Github.

    Acknowledgements

    Thanks to Daniel Souter of Sophos X-Ops for contributing to this analysis.

    Exit mobile version