In recent years, several high-profile data breaches have hit managed file transfer (MFT) and B2B service providers. Notably, Cleo, Fortra’s GoAnywhere MFT, and Progress MOVEit Transfer suffered zero-day exploits that led to widespread data theft. These incidents reveal common patterns in attacker tactics and expose weaknesses in how smaller B2B software vendors approach security. This report provides a technical breakdown of each breach, analyzes industry trends behind the targeting of MFT providers, identifies security deficiencies contributing to these exploits, compares these practices with IBM’s robust security approach, and outlines mitigation strategies to bolster defenses.
1. Technical Breakdown of Breaches
Cleo MFT Zero‑Day Exploit (2024)
A campaign in late 2024 exploited a zero-day remote code execution (RCE) flaw in Cleo’s secure file transfer products (Harmony, VLTrader, and LexiCom). Attackers took advantage of an insufficient patch for an earlier arbitrary file write vulnerability (CVE-2024-50623) – essentially bypassing Cleo’s October 2024 fix . The new exploit allowed unrestricted file upload/download, enabling attackers to write a specially crafted .txt file (e.g. healthcheck.txt) into the software’s autorun directory, which Cleo automatically processed .
Once placed in the autorun folder, the malicious file invoked built-in import functions to load an additional payload (a ZIP with an XML config). This XML (main.xml) contained PowerShell commands that the Cleo system executed on the host . Through this mechanism, the attackers achieved code execution without authentication. The PowerShell stager pulled down further payloads (malicious JAR files) from attacker-controlled servers and then wiped the initial files to hinder forensics . In post-exploitation, the adversaries used Windows nltest.exe to enumerate Active Directory domains and deployed web shells for persistent remote access . They established outbound TCP channels to exfiltrate data from the compromised servers, targeting the sensitive files handled by Cleo’s MFT platform. Before disengaging, the attackers issued PowerShell commands to delete artifacts of the attack (e.g. removing cleo.*.jar files in installation directories) to cover their tracks .
At least 10 organizations using Cleo’s software were confirmed impacted within days of the zero-day’s exploitation, including firms in the consumer products, food, trucking, and shipping industries . Because Cleo’s tools are used by over 4,000 companies (many mid-sized enterprises), the attack had the potential to scale widely . The Russian-speaking Clop cybercriminal group – infamous for targeting MFT software – claimed responsibility for the Cleo breaches, stating they stole data from numerous companies via this exploit . (Notably, cybersecurity researchers also observed a new ransomware gang dubbed “Termite” leveraging the same Cleo zero-day, suggesting multiple actors may have been involved .) In response, Cleo released an emergency update (v5.8.0.24) to address the incomplete patch, and a second CVE (CVE-2024-55956) was later assigned to the flaw that allowed unauthenticated import of arbitrary commands .
Fortra GoAnywhere MFT Breach (2023)
In early 2023, attackers exploited a pre-authentication RCE vulnerability in Fortra’s GoAnywhere Managed File Transfer product, which was being used by many organizations as a secure file exchange platform. The flaw (CVE-2023-0669) existed in the GoAnywhere administrative console and allowed an attacker to inject malicious code without needing to log in, if the admin panel was exposed to the internet . In late January 2023, Fortra discovered this zero-day and released an emergency patch, but not before attackers had begun mass-scanning for vulnerable servers.
The notorious Clop ransomware group quickly claimed credit for exploiting CVE-2023-0669 to steal data from GoAnywhere deployments. According to Clop, over a 10-day period they breached more than 130 organizations by targeting vulnerable GoAnywhere MFT instances accessible online . By sending crafted requests to the vulnerable endpoint, the attackers achieved RCE on the GoAnywhere application servers. This allowed them to access or download sensitive files that businesses had exchanged via GoAnywhere. Clop stated that they stole documents stored on the compromised servers – including databases of personal information – but consciously did not encrypt the systems with ransomware, focusing purely on data theft for extortion . (They hinted they had the capability to move laterally in victim networks and deploy ransomware payloads, but opted for a data-theft-only operation in this campaign .)
As details emerged, it became clear this breach had a far-reaching impact. Prominent victims publicly disclosed by March 2023 included a large U.S. healthcare provider (Community Health Systems), a fintech bank (Hatch Bank), tech firms (Rubrik), energy infrastructure (Hitachi Energy), and even city governments (City of Toronto) . The exposed data from these breaches ranged from personal patient records (in the case of CHS, affecting over 1 million individuals) to financial client data (e.g. ~140,000 customers’ SSNs from Hatch Bank) . In total, millions of individuals’ data were compromised across the dozens of known victim organizations . Security researchers linked the GoAnywhere attacks to the TA505 threat group (Clop’s known alias) and their use of the “TrueBot” malware downloader to deploy backdoors on some victim systems . The GoAnywhere incident highlighted that a single zero-day in a popular B2B file transfer product could trigger a cascade of breaches across many companies.
Progress MOVEit Transfer Breach (2023)
In mid-2023, Progress Software’s widely used MOVEit Transfer service became the target of a massive data theft campaign after a critical vulnerability was discovered. On May 31, 2023, Progress announced a MOVEit Transfer SQL injection flaw (CVE-2023-34362) that could allow an unauthenticated attacker to gain access to the MOVEit Transfer database . In practice, this bug let attackers execute SQL commands and ultimately achieve remote code execution on MOVEit servers. Almost immediately, the Clop/TA505 group began exploiting this zero-day in the wild (they had likely discovered it beforehand), leading to what became one of the largest data breaches of the year .
Clop’s attack chain on MOVEit was sophisticated. By sending specially crafted SQL inputs to a MOVEit Transfer web application endpoint, the attackers could inject malicious queries that created a web shell on the server . They installed a custom web shell (dubbed “LEMURLOOT”) disguised as a legitimate file (e.g. human2.aspx to mimic a normal human.aspx) . The web shell generated a secret key and awaited connections containing a matching header value for authentication . Once the attackers authenticated to LEMURLOOT, they could issue commands on the MOVEit server with high privileges. These commands allowed them to enumerate and steal data from the backend MOVEit database (which stores file metadata and user info) and even create or remove user accounts on the system . In essence, the attackers jumped directly to the data exfiltration stage – retrieving sensitive files and database contents – via SQL queries and the web shell, without needing to pivot deep into the network.
The impact of the MOVEit breach was staggering. By one analysis, 2,773 organizations and nearly 96 million individuals had personal data exposed through the MOVEit Transfer hacks in 2023 . Victims spanned banks, universities, governments, and Fortune 500 companies. Even technology consulting giants and accounting firms (including IBM, Cognizant, Deloitte, PwC, and EY) found some of their data compromised via the MOVEit zero-day . (This often occurred because those enterprises were using MOVEit or had third-parties that did, underscoring the supply-chain reach of the attack.) The stolen data sets ranged from social security numbers and contact info to intellectual property, depending on what files were being transferred by each victim organization. The U.S. CISA confirmed that multiple federal agencies had been breached via MOVEit as well . Clop orchestrated a large-scale extortion campaign, naming hundreds of victim companies on their leak site and demanding ransoms under threat of publishing the stolen data . Progress Software scrambled to issue patches and even temporary workarounds (such as disabling all HTTP/S traffic to MOVEit servers) within days , but the attackers already had a foothold. Over the following weeks, additional vulnerabilities in MOVEit (CVE-2023-35036 and CVE-2023-35708) were identified and patched as well, though those were not widely exploited at the time . The MOVEit incident underscored how a single zero-day in a ubiquitous file-transfer tool could facilitate a “mass exploitation” event affecting thousands of organizations nearly simultaneously.
2. Industry Trend: Why Threat Actors Target MFT and B2B Providers
The above breaches were not isolated – they form part of a deliberate trend by cybercriminal groups to target smaller B2B software providers (especially MFT services) as a way to compromise large numbers of downstream organizations in one swoop. The Clop ransomware group, in particular, has repeatedly pursued this strategy. In 2020, Clop (or affiliated actors like FIN11) exploited zero-days in Accellion’s legacy File Transfer Appliance to steal data from over 100 companies . In early 2023 they turned to GoAnywhere MFT, and by mid-2023 to MOVEit, compromising hundreds of organizations across these campaigns . By late 2024, even Cleo, a smaller B2B integration/MFT provider, became a target. This approach can be seen as a form of supply-chain attack, where breaching one software supplier or service leads to breaches in many client organizations.
Several factors explain why attackers are increasingly aiming at MFT and niche B2B platforms:
• Broad Reach to Sensitive Data: MFT solutions are by design used to store and transmit an enterprise’s crown jewels – they ferry sensitive files (financial data, personal records, intellectual property) between business partners, customers, and internal systems. Compromising an MFT server immediately yields access to a trove of valuable data without needing to individually breach each organization’s defenses. After Clop’s success with the MOVEit campaign in 2023, threat actors became “keenly aware of the broad access to sensitive enterprise data” that these file-transfer systems can provide . Essentially, a single zero-day in a popular B2B file exchange platform offers a one-stop shop to plunder data from many companies at once.
• Mass Exploitation Efficiency: Targeting widely-used file transfer software allows attackers to hit hundreds of victims in one campaign, a tactic that is far more efficient (for the attackers) than going after victims one by one. Security researchers note that these supply-chain style attacks are “ruthlessly efficient, allowing Clop to target hundreds of victims at once” . By writing or acquiring an exploit for a common MFT product, a ransomware gang can scan the internet for vulnerable servers and fully automate the exploitation across all of them, as seen when Clop exploited approximately 2,500 exposed MOVEit servers in a short time frame . This gives the attackers a head start to steal data from many targets before those organizations can patch. In contrast, traditional phishing or ransomware attacks are labor-intensive on a per-victim basis. The return on investment for zero-day exploits against MFT software has proven extremely high for these groups.
• Smaller Vendors as Soft Targets: The companies developing MFT and B2B solutions (like Progress, Fortra, Cleo) are often smaller firms specializing in file transfer or integration, rather than tech giants. Threat actors may perceive that such vendors have less mature security postures, making undiscovered vulnerabilities more likely. In some cases, the MFT products were legacy systems or recently acquired technologies (e.g., the GoAnywhere MFT originated from a smaller company, Linoma). Attackers count on the fact that these niche tools may not have been scrutinized as heavily as mainstream software by security researchers. Indeed, many security teams “were largely unfamiliar” with MFT software as an attack surface until these breaches elevated their profile . This relative obscurity, combined with the critical data handled by MFTs, created a sweet spot for cybercriminals. As one analysis put it, “file transfer programs are notoriously security-challenged” – they often hold unencrypted sensitive files, and a vulnerability in them gives cybergangs a field day for exploits .
• Interconnected Supply Chains: Modern enterprises have complex digital supply chains, relying on third-party services and software to move data. When an MFT provider is compromised, the breach can cascade through supply chains. For example, a single MOVEit breach at a payroll provider could expose data belonging to dozens of its client companies. The “increasingly intertwined nature of data, software, and supply chains” means a vulnerability in a smaller B2B service can lead to breaches in many larger organizations that use its services . Attackers understand that by hitting one weak link, they can indirectly penetrate otherwise well-defended networks. This dynamic is part of why smaller B2B providers are being targeted more frequently – they serve as gateways to bigger prey.
In summary, the trend of exploiting MFT software highlights a shift in ransomware tactics towards data-theft and extortion via supply-chain exploits. The mass attacks on Accellion, GoAnywhere, MOVEit – and now Cleo – show a repeating pattern: find a zero-day in a widely used file-transfer product, attack en masse, steal sensitive files in bulk, and then extort each victim company for ransom. The high payoff and efficiency of this approach virtually ensure that threat actors will continue to target similar systems in the near future .
3. Security Deficiencies Exposed in Smaller Providers
These breaches also cast light on gaps in security expertise and resources at many smaller B2B and MFT software providers. Several common deficiencies made these vendors more vulnerable to attack:
• Inadequate Secure Development Practices: The existence of these critical bugs (SQL injections, unrestricted file uploads, etc.) in enterprise software suggests that robust secure coding practices were lacking. Leading software vendors employ extensive security testing – including static code analysis, dynamic testing, and penetration tests – to catch flaws early . By contrast, the affected MFT providers evidently did not identify these weaknesses before release. For instance, Cleo’s vulnerability arose from an “unrestricted file upload” issue – a class of bug that secure development frameworks (like OWASP guidelines) are designed to prevent. The fact it remained and even the initial patch was incomplete implies insufficient security review and QA of code changes. Smaller firms may not have dedicated product security teams or rigorous threat modeling for how features (e.g. Cleo’s autorun functionality) could be abused.
• Limited In-House Security Research: Large technology companies often invest in internal research groups or bug bounty programs to hunt for vulnerabilities in their products. Smaller providers with tight R&D budgets might not have the security researchers or incentives in place to discover subtle zero-days on their own. In these cases, they end up reacting to external reports or, worse, learning of a vulnerability only after a breach. The GoAnywhere case is illustrative: Fortra was alerted to “suspicious activity” on January 30, 2023 and then found the zero-day, but by then Clop had already been exploiting it in the wild . The vendors were essentially outpaced by the attackers. A more proactive security posture (e.g. routine penetration testing and code audits) might have caught some of these issues earlier.
• Slow or Confusing Patch Processes: Another gap was in the response and patch management once a vulnerability was known. Progress Software did react quickly to MOVEit (issuing a patch within 48 hours ), but many organizations still struggled to apply fixes in time. In Cleo’s case, the patching was downright problematic – the initial fix did not fully close the hole, and Cleo’s communication around the issue lacked clarity. In early December 2024, Cleo customers were unsure if they were fully protected: the company released version 5.8.0.21 claiming to fix CVE-2024-50623, yet breaches continued, “suggesting the existence of a separate means of compromise” . It took multiple days and reports from researchers for Cleo to acknowledge a new patch was needed, and a CVE for the new issue was only “pending” at first . This confusion widened the window for attackers . Such handling indicates a lack of mature incident response planning at the vendor. Smaller providers may not have 24/7 security operations or well-drilled protocols to roll out patches and advisories the moment a critical flaw surfaces, unlike larger firms that often have formal zero-day response plans .
• Insufficient Operational Security Measures: The breaches also revealed that the deployed MFT systems often were not hardened or monitored adequately – a responsibility shared by vendors and customers. Many vulnerable GoAnywhere and MOVEit servers were directly accessible on the internet with default configurations. A security-savvy vendor could have at least guided customers to implement safer deployments (for example, recommending firewall restrictions or two-factor authentication on admin consoles). The lack of such guidance or enforcement can be viewed as a security lapse. Additionally, once the exploits began, it appears that neither the vendors nor many customers had effective monitoring for abnormal activity on these systems. In Cleo’s case, the presence of unusual files (like cleo*.jar or healthcheck.txt) and unexpected PowerShell processes were key indicators of compromise . The fact that breaches weren’t caught until data was already taken suggests gaps in log review and intrusion detection around these applications. Smaller providers often do not offer robust logging or alerting capabilities out-of-the-box, and their clients may lack the expertise to add those controls, creating blind spots during an attack.
• Resource and Expertise Constraints: Underpinning many of these issues is the reality that mid-sized B2B software firms do not have the same depth of security resources as a tech giant. They may have few (or no) full-time security engineers on the product team, little formal training on secure design for developers, and lean support staff. When a complex cyberattack occurs, they can be overwhelmed — handling digital forensics, patch development, and customer communications simultaneously is challenging even for large companies. Thus, important details can slip: for example, failing to realize the patch didn’t cover all attack vectors (Cleo), or not clearly instructing customers on immediate mitigations. The attackers bank on this disparity; they know once they unleash a zero-day exploit, a smaller vendor will struggle to contain the fallout quickly, giving them ample time to exploit at scale. In contrast, an organization with a larger security team might detect and respond to the threat more rapidly, limiting the damage.
In short, these breaches exposed that many niche service providers are operating without a safety net of strong security culture. Their products, while marketed as “secure” file transfer solutions, often had hidden weaknesses due to lapses in secure development and testing. And when those weaknesses were mercilessly exploited, the companies’ limited security experience led to delays and missteps in responding. This should serve as a wake-up call across the industry: security can no longer be an afterthought for any software handling sensitive data, regardless of company size.
4. IBM vs. Smaller Providers: A Comparative Security Analysis
Unlike the smaller vendors discussed, IBM has a long-established reputation for stringent security standards and has (so far) avoided similar catastrophic breaches in its own B2B software offerings. IBM’s ability to sidestep such incidents is not mere luck; it stems from deliberate investment in security-minded processes, research, and technology. Several factors illustrate how IBM’s approach differs:
• Security & Privacy by Design: IBM builds its products under a comprehensive Secure Engineering Framework. The IBM Security and Privacy by Design (SPbD@IBM) program mandates that security be woven into every stage of the product lifecycle . For instance, during development IBM conducts thorough threat modeling and risk assessments for new features . Teams are required to identify potential abuse cases and design mitigations up front. By contrast, smaller firms may skip formal threat assessment, leading to oversights (e.g., Cleo perhaps did not fully consider the abuse potential of an autorun file import feature). IBM’s engineers follow strict coding standards (aligned with industry best practices like OWASP Top 10 and NIST guidelines) and utilize automated tools to detect vulnerabilities in code. The SPbD process includes integrated security testing in CI/CD pipelines and periodic manual ethical hacking (pen-testing) of products before release . This rigorous approach makes it far less likely that a trivial SQL injection or unrestricted upload bug will slip through into production. In effect, IBM leverages its greater resources to maintain a much higher bar of software assurance than many smaller vendors can manage.
• Rigorous Security Standards and Certifications: IBM’s solutions are typically built to comply with heavy-weight security standards demanded by enterprise and government clients. This includes compliance with frameworks like FIPS 140-2 encryption, ISO/IEC 27001 information security management, and often product-specific certifications (Common Criteria, etc.). Adherence to such standards enforces discipline in areas like key management, access control, and audit logging. For example, IBM’s managed file transfer and integration products (such as IBM Sterling File Gateway) support strong encryption for data at rest and in transit, granular user permissions, and tamper-evident logging – features that mitigate the impact of a breach. Smaller MFT providers do offer security features, but the breadth and rigor of these controls can lag behind. Moreover, IBM is known to patch proactively and support products for years under clear maintenance policies, ensuring customers can keep systems up-to-date . This proactive maintenance culture, backed by dedicated support teams, contrasts with the more reactive posture seen in vendors who scramble after a zero-day is public.
• Dedicated Security Research and Threat Intelligence (X-Force): IBM augments its defensive posture with world-class security research capabilities. The IBM X-Force research team continuously investigates emerging threats, not just to warn IBM’s clients but also to bolster IBM’s own products. For instance, in response to the wave of MFT exploits, IBM X-Force released a detection and response framework specifically for MFT software in 2023 . This framework provides monitoring rules for the kinds of behaviors observed in the GoAnywhere and MOVEit attacks (web shell activity, suspicious process launches, etc.), enabling organizations to catch such intrusions faster. The fact that IBM swiftly developed and shared this solution shows its depth of expertise and commitment to preemptive defense. IBM also has X-Force Red, an autonomous team of veteran hackers who perform penetration testing on both IBM and third-party products. By actively seeking out vulnerabilities (and fixing them) before criminals do, IBM reduces the likelihood of an unpatched zero-day lurking in its offerings. Smaller providers rarely have an equivalent to X-Force; they might occasionally contract third-party audits, but they do not operate on the same intelligence-driven scale. IBM’s global view of the threat landscape (through monitoring cyber attacks across industries) helps it anticipate where attacks might shift next – an advantage that can inform product security hardening. In short, IBM’s research and threat intel apparatus serves as an early-warning system, something beyond the reach of most mid-sized vendors.
• Secure Configuration and Deployment Guidance: IBM tends to emphasize secure deployment architectures for its enterprise software. For example, IBM documentation will recommend best practices like placing servers behind demilitarized zones (DMZs), using web application firewalls, enabling MFA for administrative access, etc. This kind of guidance can prevent common misconfigurations. It’s notable that IBM’s own MFT solutions (e.g., IBM Sterling) have not been cited in these mass exploit campaigns. The nature of IBM’s deployments – often running in more tightly controlled environments (mainframes, private networks) as opposed to being left on an open internet server. Even when IBM was tangentially impacted by the MOVEit incident (through some third-party service using MOVEit) , IBM’s core systems remained secure, and it promptly informed stakeholders. The incident reinforced that IBM’s direct offerings had avoided such zero-day flaws, likely thanks to the robust engineering checks described.
• Culture of Security and Investment: Perhaps the biggest difference is cultural and financial. IBM, as a decades-old technology leader, invests heavily in security training and culture across its workforce. Developers and engineers are trained to prioritize security alongside functionality. IBM’s corporate policies (like requiring SPbD compliance) ensure accountability – teams cannot release a product that fails to meet internal security reviews. Additionally, IBM’s sheer size allows it to allocate significant budget to security tools, expert personnel, and continuous improvement. A smaller B2B software firm under market pressure to add features may not afford the same focus on security improvements or might consider them a lower priority until a disaster strikes. IBM, on the other hand, treats security as a fundamental brand pillar – one that has been built over years of demonstrating reliability to Fortune 500 clients and governments. This results in a track record largely free of the kind of headline-grabbing zero-day fiascos that have plagued some other providers.
In summary, IBM’s avoidance of similar breaches can be attributed to its comprehensive security ecosystem: from development standards aligned with NIST’s Secure SDLC , to rigorous testing (threat modeling, code scanning, pen-tests) , to proactive threat intelligence and swift incident response. While no vendor is infallible, IBM’s multilayered defense and preparedness significantly reduce the risk of a single flaw leading to a broad compromise. The comparison underscores that many smaller MFT/B2B providers might consider adopting analogous practices (scaled to their size) to boost their security posture.
5. Mitigation Strategies and Recommendations
The wave of breaches in Cleo, GoAnywhere, and MOVEit provide a number of lessons learned for both software providers and organizations using these services. To improve security in the MFT and B2B service ecosystem, the following mitigation strategies are recommended:
For Software Providers (MFT/B2B Vendors):
1. Adopt Secure Development Lifecycle (SDL) Practices – Incorporate security from the ground up in product development. This includes performing regular code reviews and automated testing (SAST/DAST) to catch vulnerabilities like SQL injection or unsafe file handling before release . Implement threat modeling for new features to foresee how attackers might abuse them. Following industry frameworks (such as NIST’s Secure Software Development Framework) helps ensure a baseline of secure coding and architecture is met.
2. Proactive Vulnerability Discovery – Don’t wait for external actors to find your bugs. Establish bug bounty programs or hire external security firms to audit your software periodically. Engage in penetration testing and red-team exercises that simulate real attacker tactics. Had Cleo or Progress done a thorough pen-test focusing on file upload functionality and SQL interfaces, they might have discovered CVE-2024-50623 or CVE-2023-34362 themselves and patched preemptively. Investing in an internal security research team (even a small one) can pay off by catching critical issues early.
3. Rapid Patch Development and Clarity – When a zero-day does surface, time is of the essence. Develop a rapid response plan for addressing critical vulnerabilities, including procedures for 24/7 engineering support and out-of-band patch releases . Equally important is clear communication: issue security advisories with explicit guidance as soon as possible. Ambiguity or delays can leave customers in the dark (as happened with the Cleo patch confusion) and give attackers more opportunity. If a patch is interim or incomplete, be transparent about it so customers can apply additional mitigations (like shutting off a service) until a final fix is ready.
4. Built-in Security Features – Strengthen the security controls within the product to limit damage if an attack occurs. For MFT software, this could mean enabling two-factor authentication for all administrative access, enforcing strong encryption for data at rest, and optionally encrypting files such that the server itself cannot decrypt content without an external key (reducing the value of stolen files). Implement role-based access so that even if an attacker exploits the app, they might compromise a low-privilege context first. Logging and alerting should be first-class features: the software should log admin activities, file transfers, and system changes in detail, and ideally provide hooks for SIEM integration so unusual events (like a sudden bulk download or new admin account creation) can trigger alerts.
5. Security Configuration Guidance – Provide customers with prescriptive guidance on how to deploy and harden the software. Encourage or require best practices like: placing the MFT system behind a firewall or VPN, disabling its internet exposure if possible, using allow-listed IP access for any external interface, and integrating a Web Application Firewall (WAF) to filter malicious requests. In the Cleo case, researchers explicitly urged users to move Cleo systems behind a firewall and restrict external access until patched . Vendors should echo such advice. Additionally, offer options to easily disable risky functionality (e.g., Cleo added an option to turn off the autorun feature post-incident ). Secure defaults and easy-to-follow hardening checklists can go a long way in preventing successful exploitation.
For Organizations Using MFT/B2B Services:
1. Reduce Internet Exposure – Wherever feasible, do not expose MFT portals or admin consoles directly to the internet. Use VPNs or private network connections for trusted partners to access file transfer services. If the service must be internet-facing (to serve clients), restrict access by IP address ranges or implement additional gateway/proxy security. By minimizing the accessible attack surface, you dramatically lower the chance of opportunistic mass exploitation. As one security report advised, “keep vulnerable services off the public Internet where possible… via IP allow lists or by keeping applications behind a VPN” .
2. Apply Patches and Updates Immediately – Aggressively follow your vendor’s security advisories and install patches as soon as they are available, especially for critical vulnerabilities. Many MOVEit victims were breached after a patch was released because they hadn’t applied it in time . Organizations should treat file transfer software like mission-critical infrastructure and allocate resources to patch management. Where possible, test and deploy emergency patches within hours or days, not weeks. If a patch cannot be applied immediately, use temporary workarounds the vendor suggests (for example, Progress recommended disabling all HTTP/HTTPS traffic to MOVEit until it could be patched ). Prompt patching closes the window of exposure that attackers are trying to maximize.
3. Continuous Monitoring and Detection – Implement robust monitoring on any MFT systems. This includes turning on verbose application logging and forwarding those logs to a SIEM or monitoring service. Set up alerts for telltale compromise indicators: e.g., creation of new user accounts (as Clop’s MOVEit web shell did ), unexpected file names appearing in directories (like the healthcheck.txt seen in Cleo exploits ), or invocation of command-line tools (PowerShell, MySQL clients, etc.) by the MFT process. Also monitor network traffic from the MFT server – large data egress or connections to unfamiliar IPs could signal exfiltration. IBM X-Force’s released framework for MFT detection can be a resource to identify relevant log sources and patterns . The key is to detect the attack early – if you see a web shell or strange activity, you might stop the attacker before large-scale data theft occurs or at least before they pivot elsewhere in your network.
4. Defense-in-Depth Controls – Employ additional security layers around the file transfer system. Use network segmentation: the MFT server should be isolated from the core network with tightly controlled ports, so even if compromised it can’t freely access internal systems. Implement endpoint security on the host – behavioral anti-malware could potentially catch the exploitation (e.g., flagging the web shell drop or the exploitation of a process). Consider using data loss prevention (DLP) solutions or at least strict file/folder permissions, so that the account running the MFT service cannot read or encrypt every file on the system unless necessary. In Cleo’s case, the attackers were able to load new JAR modules and run PowerShell; application whitelisting or restricting the service account’s privileges might have stopped those post-exploit actions.
5. Evaluate Vendor Security Posture – When choosing or continuing to use a B2B software provider, scrutinize their security maturity. Ask about their secure development process, whether they undergo third-party code audits, and how they handle incident response. Look for vendors that have achieved recognized security certifications and show transparency about past issues. For example, a provider that can articulate their proactive measures (pen-testing, 24/7 support, rapid patch policy) is preferable . As Redwood (an MFT vendor) suggests, you want to be confident your vendor will “act swiftly in a crisis” and has a track record of doing so . If a vendor appears to lack dedicated security staff or fails to communicate well during security incidents, consider that a risk to manage or mitigate (perhaps by placing additional controls on your side or even migrating to a more security-focused solution).
6. Incident Response Readiness – Given the rise of these exploits, organizations should prepare an incident response plan specifically for third-party software breaches. This includes knowing what to do if your file transfer server is compromised: how to contain it (e.g., disconnect from network, power down), how to preserve logs/evidence, and how to notify stakeholders/regulators if data was stolen. Conduct drills or tabletop exercises on a supply-chain attack scenario. The faster and more decisively you respond, the more you can limit damage. Some companies in the MOVEit case that detected the breach quickly were able to contain it to the file transfer system alone, whereas slower responders suffered broader compromise. Plan for the worst (data exfiltration) by ensuring you have backups of any critical files and by monitoring dark web sites for any leaked data related to your organization, so you can trigger your crisis management procedures promptly.
Broader Collaboration: Finally, improving security in MFT and B2B services isn’t just a one-company job – it requires community and industry collaboration. Threat intelligence sharing is vital: when one attack happens, indicators of compromise (IOCs) and TTPs should be rapidly shared via channels like ISACs or CISA alerts so others can defend themselves . Vendors should contribute by sharing technical details of exploits (once patched) to help the community learn. The cycle of Clop’s attacks has taught us that attackers will reuse techniques on similar software, so early disclosure and collective defense can thwart copycat campaigns. Moreover, pushing for higher security standards in procurement (e.g., requiring vendors to adhere to frameworks like SOC 2, ISO 27001, or NIST SSDF) will incentivize B2B providers to invest more in security upfront.
The breaches at Cleo, GoAnywhere, and MOVEit over the past three years serve as stark case studies of how vulnerabilities in smaller B2B and MFT platforms can lead to outsized consequences. Technically, these incidents involved different flaws – from SQL injections to file upload abuses – but all enabled unauthorized access to sensitive data and systems, which threat actors leveraged for large-scale extortion. The trend underscores a shifting attack surface: adversaries are targeting the less-obvious links in the chain (third-party transfer tools) to achieve broad compromises. This places the onus on software providers to elevate their security game and on organizations to diligently secure and monitor the third-party software they rely on.
Crucially, these events have exposed a divide between the security “haves” and “have-nots.” Industry leaders like IBM have avoided similar fates by investing in strong defenses: secure-by-design development, rigorous testing, swift response, and continuous intelligence. Their example illustrates that with the right practices and culture, software can be made resilient even against zero-day threats. Smaller providers must learn from this and shore up their expertise and resources – security cannot remain an afterthought for products that handle critical data exchanges.
By implementing the mitigation strategies outlined – from improved SDLC practices to network hardening and vigilant monitoring – the risk of such breaches can be significantly reduced. The goal is to break the cycle of easy victories for ransomware gangs in this arena. Organizations that prioritize security in their file transfer processes, demand accountability from their vendors, and prepare for the possibility of attacks will be far better positioned to protect their data in the tumultuous threat landscape. The hope is that the hard lessons from Cleo, GoAnywhere, and MOVEit drive lasting changes that make our interconnected systems safer against the next wave of exploits.
• Becky Bracken, Dark Reading – “Cleo MFT Zero-Day Exploits Are About to Escalate, Analysts Warn”
• Bill Toulas, BleepingComputer – “New Cleo zero-day RCE flaw exploited in data theft attacks”
• Ravie Lakshmanan, BleepingComputer – “Clop ransomware claims it breached 130 orgs using GoAnywhere zero-day”
• Censys Security – “RCE Zero Day in GoAnywhere MFT (CVE-2023-0669)”
• Mansi B., SentinelOne – “CVE-2023-34362: Unmasking MOVEit Transfer Vulnerability”
• CRN News – “5 Things To Know On The Cleo Data Theft Attacks”
• IBM Security X-Force – “X-Force releases detection & response framework for MFT software”
• ReliaQuest – “Clop Leaks: First Wave of Victims Named”
• Tanium – “The MOVEit Breach Is Still Going Strong: Here’s How to Keep Your Data Safe”
• IBM Trust: Security by Design – “IBM Security and Privacy by Design”
• Redwood (JSCAPE) – “Is your MFT vendor prepared for zero-day exploits?”
• Huntress Labs – “Cleo Zero-Day Exploitation in the Wild” (via BleepingComputer and DarkReading references)
• CISA Alerts – “#StopRansomware: Clop Exploits MOVEit Vulnerability” (context on related campaigns)
