ProxyShell leads to a domain-wide ransomware attack

The “proxieshell leads” vulnerability has led to domain-wide ransomware attacks on victims. According to a new study released Monday by the threat intelligence provider DFIR report.

ProxyShell is the name given to three Microsoft Exchange Server vulnerabilities revealed in July that together are capable of elevating privileges and executing code remotely. According to Monday’s report, an unpatched and anonymous Exchange Server client was the victim of ransomware attacks that exploited the vulnerabilities and compromised the entire domain of the organization.

The DFIR report publication describes in technical detail

The publication of the DFIR report describes the technical details. How did the threatening artists put multiple web shells on the victim’s network? Implemented system-level privileges. The domain administrator stole the account and used BitLocker and DiskCryptor encryption software to encrypt the victim’s systems.

Using the stolen domain administrator account, adversaries performed a port scan with KPortScan 3.0, then moved sideways using RDP. Targeted servers included backup systems and domain controllers. The threat actor also deployed the FRP package to these systems after gaining access, ”the post said. “Finally, the threat actors deployed setup.bat to the environment’s servers using RDP, then used an open-source disk encryption utility to encrypt the workstations. Setup.bat ran commands to enable BitLocker encryption, which made the hosts inoperable.

The attack did not involve any ransomware as a service and used “almost no malware” according to the report. Additionally, “This was a rare case of a ransomware attack where Cobalt Strike not use or any other C2 framework.

The ransom period was 48 hours, according to the DFIR report, including the time between the initial exploitation and the execution of the ransomware attack. ProxyShell Leads The threat actors, who were not identified in the message, demanded $ 8,000 from the victim.

While ProxyShell has not achieved the same significance as the critical ProxyLogon flaws disclosed earlier this year, ProxyShell attacks have been on the rise since the vulnerabilities were first discovered. That said, many servers are still not patched.

We observed an intrusion where an adversary exploited multiple Exchange

We observed an intrusion where an adversary exploited multiple Exchange (ProxyShell Leads) vulnerabilities to remove multiple web shells. In three days, three different web shells were deposite in publicly accessible directories. These web shells, expose to the internet,use to execute arbitrary code on the Microsoft Exchange server use PowerShell and cmd.

After gaining a foothold on the Exchange system, threat actors began discovery by running commands such as ipconfig, net, ping, system info, and others, using previously removed web shells. This initial battery of discoveries included a network call to themoscowtimes [.] Com. The threat actors repeated these tests twice in the first two days. On the third day, the next phase of the intrusion was in progress.

Commands executed by Web Shell run with system-level privileges. So the dangerous artists took advantage. And built-in default account enabled. Password set and added to groups of administrator and remote desktop users. The threat actors then ditched Plink and established an SSH tunnel to expose RDP on the tunnel. They then connected to the Exchange server through RDP using the DefaultAccount account.

Right after the transfer, the opponents executed install-proxy.bat to create two directories and move CacheTask.bat, dllhost.exe, and RuntimeBroker to their respective folders. A scheduled task was created and executed to run install-proxy.bat, which established network persistence through Fast Reverse Proxy (FRP) which was used to proxy RDP traffic during the intrusion.

To encrypt the workstations, an open-source utility call DiskCryptor was use. This was dropp on workstations via RDP sessions and then executed to install the utility and configure encryption. The utility required a reboot to install a kernel-mode driver, then another reboot to lock down access to the workstations.