Researcher Warns Maybe of Another Exchange Server Vulnerability

On September 28, a Vietnamese security company, GTSC disclosed two zeroday vulnerabilities CVE-2022-41040 and CVE-2022-41082 affecting Microsoft Exchange Server. Later, Microsoft also confirmed that both the zero-day vulnerabilities affecting Microsoft Exchange Server 2013, 2016, and 2019 are being exploited in the Wild. 

Today, another Korean-based cyber threat analysis firm, AhnLab published the analysis report that inspected two of the affected Exchange servers and found that they were infected with LockBit 3.0 ransomware, and the AD administrator account was found to have been hijacked.

The key point on the AhnLab analysis report is that they mentioned the attack scenario or pattern on the Exchange server is different from the vulnerabilities disclosed by the GTSC report. The attacks method, the generated WebShell file name, and subsequent attacks after WebShell creation, it is presumed that a different attacker used a different zero-day vulnerability. 

Furthermore, attackers also used Lockbit 3.0 ransomware to infect victims' network and internal systems

According to the AhnLab report, attackers have users an undisclosed vulnerability in Microsoft Exchange Server is believed to exist. It took just 7 days from uploading WebShell to hijack AD administrator accounts and deploy ransomware on the systems.

Gaining administrator account

The attacker uploaded the WebShell in the OWA folder, and it operates with System privileges. With the system privilege attacker obtained the passwords of the AD administrator accounts, Administrator and Exchservice, using the Mimikatz malware.

Mimikatz is a malware frequently used to steal account credentials (credentials) from Windows systems.

Gaining Internal Access control

The attacker used WebShell to create and execute tunneling programs and scripts. If you run the generated r.bat script, the RDP firewall policy is allowed and RDP is enabled by modifying the registry. After that, the tunneling program p64.exe (Plink) is executed to connect the external server address and local 3389 (RDP). This bypasses the firewall used by the organization and allows RDP access from the outside to the internal network system.

Tools used by attackers

The attackers used administrative utility tools and many techniques to hack into the victim's internal networks. The attackers created and used Windows batch files containing system basic commands such as wmic, copy, or used utilities, and commercial programs for administrative purposes to avoid detection by the antivirus.

Here is the list of utilities used by the attackers while exploiting the whole network  -

The attacker obtained a list of internal systems using the network scanning utility netscan, and then obtained an account with AD administrator privileges (ExchService, Administrator) through the Mimikatz malware and accessed internal systems through various methods.

• Connection using RDP 
• Remote access with TeamViewer
• Copying remote files using the copy command
• Remote Command Execution Using WMIC
• Remote Command Execution with Psexec 

AhnLab noted that the attacker used a script in the form of a Windows batch file to distribute the ransomware. The ransomware distribution scripts commonly use the hard disk basic share (C$) and remote commands using wmic.

It is officially not yet confirmed that AhanLab's findings are different from the above disclosed exchange zero days, neither there is any new CVE reserved or disclosed by the MITRE. If this proves to be different then this could be another zero-day bug in the Microsoft exchange server. 

Mitigation Guide by Microsoft [Bypass multiple times]

The GTSC team and Microsoft have provided a temporary fix or patch to reduce the vulnerability of attacks by adding a rule to block requests with indicators of attack through the URL Rewrite Rule module on the IIS server. Additionally, Microsoft also released a script for the URL Rewrite mitigation.

But, some security researchers successfully tricked to bypass the mitigation guided by Microsoft. For the same Microsoft has also updated the mitigation rules many times (which can be tracked here) by the updated version released for EOMTv2 to remove an extra space in the script that didn’t impact the functionality and further improvement has been made to the URL Rewrite rule mitigation.