Detect WS_FTP Server Exploitation with Splunk Attack Range

A recently disclosed CVE-2023-40044, which targets Progress Software WS_FTP Server Ad Hoc module, highlights the importance of providing detection developer environments where they can replicate, validate, and produce data of ongoing exploitations campaigns with the purpose of developing detections to protect their organizations.

As its name suggests, the named software is a file transfer application that is being targeted for exploitation. This application is developed by the same company that developed MOVEIt File transfer software which was also recently affected by a published vulnerability (CVE-2023-34362). As the Splunk Threat Research Team (STRT), we develop community tools that provide defenders the ability to replicate and develop detections by using the Splunk Attack Range. Splunk Attack Range allows the quick creation of a pre-configured sandbox lab that allows quick grab, processing, and analysis of attack generated data.

In this blog, we are going to showcase how we used it to develop detection content related to CVE-2023-40044.

Attack Range Setup

As outlined above, the vulnerability targets the WS_FTP Server Ad Hoc IIS module. Prior work by the STRT related to IIS components and inventorying IIS Modules may be found in our blog and on research.splunk.com. This application, WS_FTP — which is composed of several modules including the Ad Hoc transfer module — requires the installation of Microsoft IIS and several IIS extensions in order to run. According to at least one Proof of Concept, the attack was replicated on an instance running Microsoft IIS. Since Splunk Attack Range does not collect IIS logs by default, we had to set up Microsoft IIS log collection. The following steps were followed:

Install Splunk Add-on for Microsoft IIS on a Splunk Server withinSplunk Attack Range

Once the installation was successful we had to configure inputs for IIS. We followed the instructions here Configure inputs in the Splunk Add-on for Microsoft IIS. Remember, if you have a Splunk distributed architecture deployment of this application, you might follow a different workflow. In our case, since it was a single instance. We just had to install the application at the single Microsoft Windows Server 2016 instance created in Splunk Attack Range.

Once the application is configured and Splunk Universal Forwarder is restarted, we can see the flow of IIS logs.

And now that we have IIS logs flowing in our Splunk instance, we can attempt to reproduce the attack and see what data is generated.

Attempting to Replicate Exploit

We looked at a couple of POCs available online and attempted to reproduce the exploit. However, even though it can be seen in the next screenshots, we did get similar results. We did not get successful exploitation in the backend. However, we were able to generate attack attempts data which is enough to craft a detection.

The targeted endpoints in the POCs are:

• /AHT/AhtApiService.asmx/AuthUser
• /AHT/AhtApiService.asmx/UploadFilesForEmail

According to this POC, the exploit is related to the IIS HTTP modules These modules provide multiple features or building blocks that can be used by developers in order to implement functionality in applications. The specific module targeted in this vulnerability is MyFileUpload.UPloadModule which provides file upload functionality within the Ad Hoc Transfer module (AHT). For a detailed explanation on the exploit logic, please visit the POC page. We proceeded to attempt to replicate the exploit using Burp Suite intercepting requests and repeating them via POST method inserting a payload generated via ysoserial.net binary as shown in the POCs reviewed. Ysoserial is a payload generator that takes advantage of .Net applications that perform unsafe deserialization of objects. This unsafe deserialization can be abused in order to execute commands at the backend of targeted applications. (WS_FTP Server Requires .NET framework). We tested these exploit requests on version 8.7.0.102, which according to available information, is supposed to be vulnerable.

According to the published POCs, the targeted POST requests against the aforementioned endpoints are followed by HTTP Status 302 (Redirect) or 200s (Found). We also observed 500 (Internal Server Error). HTTP Status 500s are internal server backend errors which at times may indicate exploitation attempts.

Below are the logs produced by these attempts:

Based on the few attempts and the POCs relevant information, we suspect there might be other functions within the (/AHT/AhtApiService.asmx) endpoint vulnerable for exploitation.

In summary, the recently released CVE-2023-40044, targeting the WS_FTP Server Ad Hoc module. Leveraging the capabilities of the Splunk Attack Range, the STRT team effectively created a sandbox to reproduce and study this specific vulnerability. Although direct successful exploitation wasn't achieved in our tests, valuable insights were garnered from attack attempt data. This data serves as a foundation for crafting precise detections.

Security Content

The following analytics will assist defenders in utilizing multiple log sources to identify suspicious and malicious behavior related to IIS and WS_FTP.

Data sources:

• Windows Sysmon, process monitoring
• Microsoft-IIS-Configuration/Operational
• Windows Application
• PowerShell Scripted Input - Get-WebGlobalModule
• Web datamodel

WS FTP Analytic Story

The WS FTP analytic story focuses as a resource for defenders to identify precise analytics and post exploitation signatures to identify suspicious activity.

WS FTP Remote Code Execution

| tstats count min(_time) as firstTime max(_time) as lastTime from datamodel=Web where Web.url IN ("/AHT/AhtApiService.asmx/AuthUser") Web.status=200 Web.http_method=POST by Web.http_user_agent, Web.status Web.http_method, Web.url, Web.url_length, Web.src, Web.dest, sourcetype
| `drop_dm_object_name("Web")`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

STRT IIS Components Analytic Story

The IIS Components analytic story will assist with providing robust monitoring for IIS including modules.

Windows IIS Components Get-WebGlobalModule Module Query

Inventory may assist in confirming usage of WS_FTP Ad Hoc module and any other additional modules in the fleet.

Summary

In closing, we showcased how the STRT develops security content related to recently disclosed CVEs and proof of concept scripts within Splunk Attack Range. In addition, not every attempt is successful in exploitation, therefore STRT works to ensure the POC is dissected to validate that we can provide security content to customers and the community in a timely manner.

References

• https://www.assetnote.io/resources/research/rce-in-progress-ws-ftp-ad-hoc-via-iis-http-modules-cve-2023-40044
• https://community.progress.com/s/article/WS-FTP-Server-Critical-Vulnerability-September-2023
• https://www.cve.org/CVERecord?id=CVE-2023-40044
• https://www.rapid7.com/blog/post/2023/09/29/etr-critical-vulnerabilities-in-ws_ftp-server/
• https://www.splunk.com/en_us/blog/security/fantastic-iis-modules-and-how-to-find-them.html

Learn More

You can find the latest content and security analytic stories on GitHub and in Splunkbase. Splunk Security Essentials also has all these detections available via push update. For a full list of security content, check out the release notes on Splunk Docs.

Feedback

Any feedback or requests? Feel free to put in an issue on GitHub and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions if you need an invitation to our Splunk user groups on Slack.

Acknowledgement

STRT would like to thank David Mayer for his assistance in crafting this blog.