BitLocker used to attack servers in "intrusion with almost no malware"
Hackers breached an organisation running on-premises Microsoft Exchange servers and after moving laterally proceeded to encrypt systems domain wide, using Microsoft's own BitLocker tool rather than malware associated with a Ransomware-as-a-Service group, analysts writing for The DFIR report said Monday.
Dubbing it an "intrusion with almost no malware" (beyond the initial webshells) they described it as a "rare occurrence of a ransomware attack where Cobalt Strike was not used or any other C2 framework”...
The attackers gained their initial access by exploiting a trio of vulnerabilities in Microsoft Exchange known as ProxyShell (CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207) that were first disclosed in early August.
See also: 200k+ servers vulnerable to ProxyShell attacks
Declining to identify any details about the target organisation to The Stack, analysts at the DFIR Report said the attackers used Microsoft's own encryption tool BitLocker to encrypt server files and an open source disc encryption tool to lock files in workstations before demanding $8,000 for the encryption keys.
After chaining the initial ProxyShell exploits for SYSTEM privileges on the target system, the hackers dropped three different web shells -- script that can be uploaded to a web server to enable remote administration of the machine in publicly accessible directories -- to execute arbitrary code on the server, using Microsoft configuration management programme PowerShell and the Windows command line interface cmd.
They wrote: "After gaining an initial foothold on the Exchange system, the threat actors started discovery by executing commands like ipconfig, net, ping, systeminfo, and others, using the previously dropped web shells. Since the commands executed via the web shell run with SYSTEM level privileges, threat actors took advantage of this and enabled a built-in account DefaultAccount, set the password and added it to Administrator and Remote Desktop Users groups. The threat actors then dropped Plink and established an SSH tunnel to expose RDP over the tunnel. They then connected to the Exchange server over RDP using the DefaultAccount account.
"They then copied their tools into the environment via RDP... Right after the transfer, the adversaries executed install-proxy.bat to create two directories and move CacheTask.bat, dllhost.exe and RuntimeBroker into their respective folder. A scheduled task was created and executed, to execute install-proxy.bat, which established network persistence via Fast Reverse Proxy (FRP) which was used to proxy RDP traffic during the intrusion.
"Utilizing the Plink RDP connection, the threat actor dumped LSASS using Task Manager. Thirty minutes later, the threat actor started using a domain administrator account. Using the stolen Domain Admin account, adversaries performed port scanning with KPortScan 3.0 [aand then moved laterally using RDP. Targeted servers included backup systems and domain controllers. The threat actor also deployed the FRP package to these systems after gaining access. Finally, the threat actors deployed setup.bat across the servers in the environment using RDP and then used an open source disk encryption utility to encrypt the workstations.
"Setup.bat ran commands to enable BitLocker encryption, which resulted in the hosts being inoperable.."
A full technical write-up and TTPs from the DFIR Report are here.
The three ProxyShell bugs are exploited remotely through Microsoft Exchange’s Client Access Service (which Tsai describes as “a well-written HTTP Proxy”) running on port 443 in IIS. Microsoft actually patched this CAS frontend in issue in its April 2021 cumulative update, stripping out the “pre-auth” element of the attack, but many users have not updated their servers, as this incident demonstrates. The three-step ProxyShell attack, as laid out by exploit creator/finder Orange Tsai is as follows:
1: “Deliver [an] encoded WebShell payload by SMTP
2. Launch the native PowerShell and intercept the WinRM protocol
• Rewrite the /PowerShell/ to /Autodiscover/ to trigger [a] Path Confusion bug
• Add query string X-Rps-CAT with corresponding Exchange Admin Access Token
3. Execute commands inside the established PowerShell session
• New-ManagementRoleAssignment to grant ourself Mailbox Import Export Role
• New-MailboxExportRequest to write ASPX file into the local UNC path
4. Enjoy the shell”
(A detailed look at this process and the nature of the vulns is here).
Users, as ever, should endeavour to keep their software updated.
