While providing security monitoring and incident response services around the beginning of August 2022, the GTSC SOC team learned that a vital infrastructure was under assault, specifically their Microsoft Exchange application. The research revealed that the attack used a 0-day RCE vulnerability in the Exchange security system, therefore the GTSC Blue Team experts instantly devised a temporary containment strategy. Red Team specialists began investigating and debugging Exchange decompiled code at the same time in order to identify the vulnerability and develop an exploit. The RedTeam has a deep grasp of Exchange’s code flows and processing methods as a result of their experience discovering the prior 1-day Exchange attack; as a result, research time was cut down and the vulnerability was discovered promptly.
The flaw ends up being so serious that it enables the attacker to perform RCE on the infected system. GTSC immediately reported the flaw to the Zero Day Initiative (ZDI), working with Microsoft to create a patch as soon as possible. Regarding the exploit, ZDI confirmed and acknowledged the following 2 defects, whose CVSS ratings are 8.8 and 6.3.
However, GTSC has so far seen that other clients are also having the same issue. We verified that these systems were being attacked using this 0-day RCE vulnerability after extensive testing. We present this post specifically for companies utilizing the Microsoft Exchange email system in an effort. And to assist the community in temporarily halting the attack prior to the release of an official patch from Microsoft.
Vulnerability information
GTSC Blueteam discovered exploit requests in the same pattern as the ProxyShell vulnerability while providing SOC services to a client: autodiscover/autodiscover.json?@evil.com/Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.com. We discovered that the attacker is able to issue commands to the machine being attacked by inspecting other logs. Because the most recent upgrade had already been implemented on these Exchange servers, it was impossible to attack the vulnerability using Proxyshell. Blueteam experts can confirm that it was a brand-new 0-day RCE vulnerability issue. Redteam members received this data and used it to do research to come up with the following answers: Why were the requests for the exploit the same as those for the ProxyShell bug? How is the RCE put into practice?
The above-mentioned approach has been successfully used by the GTSC Redteam to get access to a component in the Exchange backend and carry out RCE. We do not want to reveal the vulnerability’s technical information just yet, though.
Post-exploit activities
Once we had mastered the exploit, we recorded attacks to gather data and establish a presence on the victim’s system. The assault team also employed a number of methods to insert backdoors into the compromised system and move laterally to other servers within it.
Webshell
We saw webshells being dropped to Exchange servers that were largely disguised. We discovered the attacker’s use of Antsword, an active opensource cross-platform website administration tool with Chinese roots that allows webshell control, using the user-agent.
Command Execution
The attacker uses certutil, a legitimate programme included in the Windows environment, to download files. And check connections in addition to gathering information about the machine.
Malware Analysis
DLL analysis
Other DLL samples contain activities and behaviors that are identical to the sample under analysis. (074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82); the only difference is in the listener configuration.
The DLL is made up of two classes, Run and m, which each call methods to carry out distinct duties. Specifically:
The Run class instals a listener at the route https://*:443/ews/web/webconfig/ that watches for connections on port 443.
The malware then starts a new thread that calls to r after listening. What Method R accomplishes:
– Verify if the received request contains data in the body; if not, return 404.
In contrast, the DLL continues to execute the stream inside the IF branch if the request contains data:
Check to see if “RPDbgEsJF9o8S=” is present in the request that was received. If so, handle the received request by calling method I in class m. Run.m.i results are converted to base64 strings before being returned. The client received results in the following format.
Temporary containment measures
By using this 0-day vulnerability, an attack campaign targeted more than 1 company, according to the GTSC’s direct incident response method. We are also concerned that many additional organizations may have been taken advantage of but were not identified. By setting a rule to prevent requests with attack indicators through the URL Rewrite Rule module on the IIS server. GTSC provides a temporary remedy to lessen the vulnerability of assaults while waiting for the official patch from the firm.
Detection:
IIS log files are typically kept in the %SystemDrive%inetpublogsLogFiles folder. GTSC has issued guidelines and a programme to search these files to assist enterprises in determining whether their Exchange Servers have yet been attacked by this bug:
Method 1: Run Get-ChildItem -Recurse -Path Path IIS Logs> in PowerShell. PowerShell.*autodiscover.json.*@.*200 -Filter “*.log” |
Method 2: Select-String Use the GTSC tool as a second option: We developed a programme to search with considerably less time spent than when using PowerShell, based on the exploit signature. Downloadable file here: https://github.com/ncsgroupvn/NCSE0Scanner
Follow the latest guidance from Microsoft until a security patch is released. Microsoft Guidance
