Over the past several years, multiple ransomware groups and other threat actors have exploited vulnerabilities in the managed file transfer (MFT) applications that organizations rely on to enable secure remote access to business documents. Researchers from IBM have analyzed the components of 13 of these solutions and built a framework that can help defenders quickly build detections and incident response playbooks for their exploitation.

“Massive workloads and overwhelmed security teams hinder defenders from proactively inspecting or even just familiarizing themselves with the innerworkings of every software in their environment,” the IBM Security X-Force Incident Response team said in a blog post. “In fact, it's not until a vulnerability has been disclosed that they're trying to figure out the core components of a tool - when they are already racing against time to patch a system, or worse, contain an incident, pressured by the risk of business impact.

The new framework is available on GitHub and covers the following MFT tools, which were selected based on their popularity and direct internet exposure:

• Cerberus FTP Server
• FileZilla
• Cornerstone MFT
• SolarWinds Serv-U
• JSCAPE
• Oracle MFT
• WingFTP
• Aspera
• Diplomat MFT
• MyWorkDrive
• EasyFTPServer FTPD
• ShareFile
• ShareTru

MFT attacks on the rise

In June, the threat group behind the Clop ransomware exploited a zero-day SQL injection vulnerability in an MFT application called MOVEit Transfer to steal data from companies and subsequently extort money from them. This was not the first time the group targeted an MFT tool, having previously developed exploits for Accellion File Transfer Appliance (FTA) devices in 2020 and 2021 and Fortra/Linoma GoAnywhere MFT servers in early 2023.

The Clop gang is not the only group targeting such applications. Another threat actor that deployed the IceFire ransomware exploited a deserialization flaw in the Aspera Faspex file sharing software in March.

Building the MFT attack detection framework

The IBM researchers deployed demo instances, read through the available documentation, and gathered information from support forums to build a collection of file paths, process and service names, port numbers and other artifacts that a tool would create on a system. They then started simulating various actions that could be part of an attack based on past real-word exploitation: generating authentication events, creating new user accounts, executing commands through the MFT software, exfiltrating data in bulk, or deploying and interacting with web shells — web scripts that are not part of the application itself.

The goal was to understand the associations between these events and the data or changes they would create and which could be monitored for as a part of a detection strategy. This included real-time file activity, network data and process data on the system, events recorded in the system or the application logs, and changes in the application’s database. All these potential data sources were documented for every application as well as the process required to acquire them.

“Our analysis confirmed our belief: All of these tools are largely architected the same way, which means that the approach to detection and response for all MFT solutions would generally be the same,” the researchers said.

MFT-Detect-Response framework components

The resulting MFT detection and response framework called MFT-Detect-Response has several components. MFTData contains details specific for every application such as process names, file names, file paths, configuration file location, configuration options, log file location, logged events in case of various actions, port numbers, dependencies and more.

Another component called MFTDetect contains scripts that leverage the MFTData to generate detections automatically that can be used with popular incident response and detection tools such as Velociraptor or SIEM systems that support the Sigma signature format. The detection signatures would trigger if processes associated with the covered MFTs call system tools like powershell, certutil, cmd.exe, or wmic.exe with specific commands or arguments, or if system services like rundll32, regsvr32, mshta, wscript, cscript, or conhost are called by the MFTs in suspicious ways. These Windows tools and services are commonly abused by attackers in post-exploitation activities.

Another framework component called MFTRespond contains scripts that can help incident responders collect relevant data from one of the supported MFTs in case a compromise is suspected. Finally, the MFTPlaybook component contains a MFT incident response playbook template that can be used as a starting point for incident responders to build incident response playbooks for MFT software.

Using AI to build detection signatures for any application

The IBM X-Force researchers built a proof-of-concept AI engine that leverages IBM’s watsonx AI and data platform to automate the process needed to build detection solutions like those in the MFT detection framework, but for any type of software. The engine automatically analyzes documentation, forums and system data to identify processes that security teams should monitor, can produce customized detection and response playbooks and can produce a risk score for the defenders based on an analysis of the likelihood that a technology will be targeted in mass-exploitation attacks if an exploit is released.

“There are thousands of disparate software tools deployed across enterprises, so while defenders are highly skilled in identifying malicious activity, they must first know where to look,” the IBM researchers said. “We need a way to prioritize assets based on how they help an attacker achieve their goals and objectives, how exposed they are, and what their impact they could have on our organization.”