- Millions of Apple Applications Were Vulnerable to CocoaPods Attack
- Half of Employees Fear Punishment for Reporting Security Mistakes
- Bitwarden vs KeePass (2024): Battle of the Best – Who Wins?
- 4 essential lessons in AI governance
- Scaling gen AI right takes a certain kind of CIO. Are you one of them?
Squirrelwaffle Exploits ProxyShell and ProxyLogon to Hijack Email Chains
Exploits & Vulnerabilities
Squirrelwaffle is known for using the tactic of sending malicious spam as replies to existing email chains. We look into how by investigating its exploit of Microsoft Exchange Server vulnerabilities, ProxyLogon and ProxyShell.
Read time: ( words)
In September, Squirrelwaffle emerged as a new loader that is spread through spam campaigns. It is known for sending its malicious emails as replies to preexisting email chains, a tactic that lowers a victim’s guard against malicious activities. To be able to pull this off, we believe it involved the use of a chain of both ProxyLogon and ProxyShell exploits.
The Trend Micro Incident Response team looked into several intrusions related to Squirrelwaffle, that happened in the Middle East. This led to a deeper investigation into the initial access of these attacks. We wanted to see if the attacks involved the said exploits.
This comes from the fact that all of the intrusions we observed originated from on-premise Microsoft Exchange Servers that appeared to be vulnerable to ProxyLogon and ProxyShell. In this blog entry, we shed more light into these observed initial access techniques and the early phases of Squirrelwaffle campaigns.
Microsoft Exchange infection
We observed evidence of the exploits on the vulnerabilities CVE-2021-26855, CVE-2021-34473, and CVE-2021-34523 in the IIS Logs on three of the Exchange servers that were compromised in different intrusions. The same CVEs were used in ProxyLogon (CVE-2021-26855) and ProxyShell (CVE-2021-34473 and CVE-2021-34523) intrusions. Microsoft released a patch for ProxyLogon in March; those who have applied the May or July updates are protected from ProxyShell vulnerabilities.
CVE-2021-26855: the pre-authentication proxy vulnerability
This server-side request forgery (SSRF) vulnerability can allow a threat actor access by sending a specially crafted web request to an Exchange Server. The web request contains an XML payload directed at the Exchange Web Services (EWS) API endpoint.
The request bypasses authentication using specially crafted cookies and allows an unauthenticated threat actor to execute EWS requests encoded in the XML payload then ultimately perform operations on victims’ mailboxes.
From our analysis of the IIS log, we saw that the threat actor uses a publicly available exploit in its attack. This exploit gives a threat actor the ability to get users SID and emails. They can even search for and download a target’s emails. Figures 1 to 3 highlights evidence from IIS logs and show the exploit code.
The logs (Figure 2 to 3) also show that threat actor used the ProxyLogon vulnerability to get this particular user’s SID and emails to use them to send malicious spam.
CVE-2021-34473: the pre-auth path confusion
This ProxyShell vulnerability abuses the URL normalization of the explicit Logon URL, wherein the logon email is removed from the URL if the suffix is autodiscover/autodiscover.json. This grants arbitrary backend URL the same access as the Exchange machine account (NT AUTHORITYSYSTEM).
CVE-2021-34523: Exchange PowerShell backend elevation-of-privilege
Exchange has a PowerShell remoting feature that can be used to read and send emails. It can’t be used by NT AUTHORITYSYSTEM as it does not have a mailbox. However, in cases where it is accessed directly via the previous vulnerability, the backend/PowerShell can be provided with X-Rps-CAT query string parameter. The backen/PowerShell will be deserialized and used to restore user identity. It can therefore be used to impersonate a local administrator to run PowerShell commands.
With this, the attackers would be able to hijack legitimate email chains and send their malicious spam as replies to the said chains.
Malicious spam
In one of the observed intrusions, all the internal users in the affected network received, where the spam emails have been sent as legitimate replies to existing email threads. All of the observed emails were written in English for this spam campaign in the Middle East. While other languages were used in different regions, most were written in English. More notably, true account names from the victim’s domain were used as sender and recipient, which raises the chance that a recipient will click the link and open the malicious Microsoft Excel spreadsheets.
In the same intrusion, we analyzed the email headers for the received malicious emails, the mail path was internal (between the three internal exchange servers’ mailboxes), indicating that the emails did not originate from an external sender, open mail relay, or any message transfer agent (MTA).
Delivering the malicious spam using this technique to reach all the internal domain users will decrease the possibility of detecting or stopping the attack, as the mail getaways will not be able to filter or quarantine any of these internal emails. The attacker also did not drop or use tools for lateral movement after gaining access to the vulnerable Exchange servers, so that no suspicious network activities will be detected. Additionally, no malware was executed on the Exchange servers that will trigger any alerts before the malicious email is spread across the environment.
The malicious Microsoft Excel file
The attacker exploited the Exchange servers to deliver internal mails. This was all done to catch users off-guard, making them more likely to click the link and open the dropped Microsoft Excel or Word file.
Both links used in the malicious emails (aayomsolutions[.]co[.]in/etiste/quasnam[]-4966787 and aparnashealthfoundation[.]aayom.com/quasisuscipit/totamet[-]4966787 ) drop a ZIP file in the machine. The ZIP file contains, in this case, a malicious Microsoft Excel sheet that downloads and executes a malicious DLL related to Qbot.
These sheets contain malicious Excel 4.0 macros that is responsible for downloading and executing the malicious DLL.
The spreadsheets download the DLL from hardcoded URLs which are hxxps:[//]iperdesk.com/JWqj8R2nt/be.html, hxxps:[//]arancal.com/HgLCgCS3m/be.html and hxxps:[//]grandthum.co.in/9Z6DH5h5g/be.html.
The DLL is dropped in C:Datop. Finally, the document executes the DLL using the following commands:
- C:WindowsSystem32regsvr32.exe” C:Datopgood.good
- C:WindowsSystem32regsvr32.exe” C:Datopgood1.good
- C:WindowsSystem32regsvr32.exe” C:Datopgood2.good
Once the DLL executes, it starts to inject the Microsoft process (c:windowssystem32mobsync.exe). Finally, communicating with the command-and-control (C&C) server (hxxp:[//]24.229.150.54:995[/]t4).
Security recommendations
As mentioned earlier, by exploiting ProxyLogon and ProxyShell attackers were able to bypass the usual checks that would have stopped the spread of malicious email. This highlights how users plays an important part in the success or failure of an attack. Squirrelwaffle campaigns should make users wary of the different tactics used to mask malicious emails and files. Emails that come from trusted contacts may not be enough of an indicator that whatever link or file included in the email is safe.
It is important to ensure that patches for Microsoft Exchange Server vulnerabilities, specifically ProxyShell and ProxyLogon (CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207) have already been applied. Microsoft reiterated, those who have applied their patch for ProxyLogon in March are not protected from ProxyShell vulnerabilities, and should install more recent (May or July) security updates.
Here are other security best practices to consider:
- Enable virtual patching modules on all Exchange servers to provide critical level protection for servers that have not yet been patched for these vulnerabilities.
- Use endpoint detection and response (EDR) solutions in critical servers, as it provides visibility to machine internals and detect any suspicious behavior running on servers.
- Use endpoint protection design for servers.
- Apply sandbox technology on email, network, and web is very imported to detect similar URLs and samples.
Users can also opt to protect systems through managed detection and response (MDR), which utilizes advanced artificial intelligence to correlate and prioritize threats, determining if they are part of a larger attack. It can detect threats before they are executed, preventing further compromise.
The indicators of comromise (IOCs) can be found here.
Tags
sXpIBdPeKzI9PC2p0SWMpUSM2NSxWzPyXTMLlbXmYa0R20xk
