Post-mortem reading list: what the 2024–2025 breach wave teaches us about vendor file transfer

The 2024–2025 period produced an unusually dense cluster of supply-chain compromises affecting file-transfer infrastructure and the ecosystems adjacent to it. We’ve spent the past several months doing structured post-mortem analysis on the attack patterns — not the specific incidents, which are documented elsewhere, but the attack categories, the defensive failures that allowed them, and the controls that would have disrupted them.

This post is our synthesis. Three attack categories dominate the pattern. For each one we’ll describe the technique, the defender failure mode, and what actually works.

Category one: build-tool and dependency chain vulnerabilities

The most technically sophisticated attacks in the 2024–2025 wave exploited vulnerabilities inserted into or discovered in build tooling and dependency chains. CVE-2024-3094, the xz-utils backdoor, is the clearest illustration. A malicious contributor spent approximately two years building credibility in an open-source project before introducing a carefully obfuscated backdoor into the build system. The payload targeted a specific SSH authentication path and would have provided unauthenticated remote access on affected systems. Detection required deep familiarity with the xz build process — the kind of familiarity that almost no organization’s production deployment team possesses.

CVE-2021-44228 (Log4Shell) had different characteristics but similar structural logic: a widely-deployed library with a dangerous capability (JNDI lookup via user-controlled strings) that existed in the codebase for years before it became known as a vulnerability. Log4Shell became a mass-exploitation event because the dependency was present deep in the transitive dependency graph of countless applications, including file-transfer products, and most organizations didn’t know it.

The common structure: a vulnerability or backdoor exists somewhere in the dependency chain of production software. An attacker discovers or introduces it. Exploitation happens at scale before defenders can respond.

The defensive failure modes. Organizations that were slow to respond to Log4Shell almost uniformly had one or more of the following gaps: no software bill of materials (SBOM) and therefore no way to quickly determine which systems were affected; no vulnerability scanning that covered transitive dependencies; no mechanism to isolate and patch specific components without taking down systems. Organizations that were not affected by CVE-2024-3094 were running distributions that hadn’t yet updated to the vulnerable xz version — fortuitously, not because of any proactive defense.

What actually works. The NIST 800-161 supply-chain risk management framework addresses this category with controls that are now making their way into CMMC 2.0 requirements. Specifically: SBOM maintenance and review; dependency scanning that includes transitive dependencies, not just direct dependencies; vendor assertions about build-process integrity (reproducible builds, SLSA provenance attestation); and contracts with SaaS vendors that require timely disclosure of affected components when supply-chain vulnerabilities are discovered.

For file-transfer infrastructure specifically: demand that your vendors maintain and share SBOMs. Evaluate their patch cadence on dependency vulnerabilities — a vendor that takes three weeks to patch a critical dependency CVE is a different risk profile than one that patches within 72 hours. Include supply-chain security posture in vendor security questionnaires.

Category two: OAuth token theft in multi-tenant workflows

The second category is operationally lower sophistication than build-tool exploitation but higher volume and broader impact: theft and abuse of OAuth tokens used to authenticate file-transfer workflows in multi-tenant and B2B contexts.

The attack pattern exploits a structural property of how OAuth tokens are used in practice. When a file-transfer platform uses OAuth to allow a third-party system or partner to authenticate, it typically issues an access token with a defined scope and lifetime. In many implementations those tokens have lifetimes measured in hours or days, not minutes. And the tokens, once issued, are often stored in client systems — in environment variables, application configuration files, or credential stores — in ways that expose them to exfiltration without requiring a new authentication event.

MITRE ATT&CK T1550.001 (token impersonation/theft) captures the technique. The attacker obtains a valid token through endpoint compromise, credential theft, or misconfigured token storage and then uses it to authenticate file-transfer operations as the legitimate principal, with no need to repeat the authentication that generated the token.

The B2B file-transfer context makes this particularly dangerous. A token authorizing a partner’s access to a shared file workspace typically has broad scope over that workspace — read and write access to the transfer directories, ability to download files, potentially ability to modify access controls. Theft of that token provides an attacker with partner-level access that may persist for the lifetime of the token.

The defensive failure modes. Long token lifetimes are the most common contributing factor. Tokens with 24-hour or longer lifetimes mean that a stolen token remains valid for operational access long after the theft event. The second failure mode is overpermissioned token scope — tokens that grant more access than the specific workflow requires, violating the principle of least privilege. The third is absence of anomaly detection on token usage: a token that authenticates from a new geographic location or IP range, or that initiates download volume inconsistent with its normal usage pattern, may indicate theft.

What actually works. OAuth 2.1 best current practices (the BCP published as an IETF draft) recommends short-lived access tokens — under 15 minutes for high-value resource servers — with refresh token rotation. In practice, most B2B file-transfer workflows can tolerate short-lived access tokens if the refresh mechanism is implemented correctly. Scope minimization is equally important: tokens issued for a specific workflow should be scoped to that workflow, not to the entire workspace.

Sender-constrained tokens (DPOP or mTLS certificate binding) provide a stronger defense: the token can only be used from the client that proved possession of a specific cryptographic key at issuance time. A stolen token is useless to an attacker who doesn’t also have the corresponding private key. This is more complex to implement but meaningfully more resilient against token theft scenarios.

Download-volume anomaly detection should be running on any workspace that accepts third-party OAuth access. Bulk download initiated by a token that normally accesses a single file at a time is a detection signal regardless of whether the authentication itself appears valid.

Category three: vendor admin-account takeover

The third category is organizationally simpler than the previous two but operationally very impactful: compromise of the administrative accounts that control file-transfer platform configuration.

The attack pattern targets the humans and systems with administrative authority over file-transfer infrastructure: the workspace administrator who can modify access controls, the IT admin who manages user provisioning, the shared service account used for platform configuration. Compromise of these accounts doesn’t require exploiting a software vulnerability — it requires compromising an identity, which can be accomplished through phishing, credential stuffing (T1110.004), session hijacking, or social engineering.

Once an attacker has admin access to a file-transfer platform, the options are broad: exfiltrate stored files, add backdoor access grants for future persistence, modify audit log settings to reduce detection probability, or use the platform as an infrastructure component in attacks against other organizations by adding unauthorized transfer destinations.

The defensive failure modes. Shared administrative accounts — single credentials used by multiple people or systems — are the most common failure mode. They provide no per-action attribution in audit logs and create a credential that’s harder to rotate and whose compromise is harder to detect. Insufficient MFA on administrative accounts is the second failure mode: platform admin accounts with password-only authentication are a high-value target for credential stuffing campaigns. The third failure mode is lack of privileged-action review: admin actions that should be rare — adding a new admin, modifying audit log configuration, bulk-deleting files — aren’t monitored for anomalous patterns.

What actually works. Dedicated, individual administrative accounts with phishing-resistant MFA (FIDO2/passkeys) for every user with admin access. Administrative action auditing with out-of-band alerting for high-privilege actions: if someone modifies audit log settings or adds a new admin, a security-team alert should fire immediately, not be available only in a log that the attacker can also access. Privileged Access Management patterns for admin credential issuance — just-in-time access grants that expire rather than persistent admin roles — significantly reduce the attack surface of admin account compromise.

The through-line

All three categories share a common structure: they exploit trust relationships that were designed for efficiency, not adversarial conditions. Dependencies are trusted because they’re in the supply chain. OAuth tokens are trusted because they were validly issued. Admin accounts are trusted because they’re legitimate identities. The attacker’s job is to insert themselves into a trust relationship that was designed assuming the trusted party is the party it claims to be.

The defensive principle that applies across all three categories is verification at trust boundaries: don’t assume that supply-chain components, tokens, or administrative identities are what they claim to be — verify it. SBOMs and dependency scanning verify supply chain integrity. Sender-constrained tokens verify token holder identity. Just-in-time access and anomaly detection verify that administrative actions are consistent with expected behavior.

File-transfer infrastructure is a high-value target because it sits at the intersection of external connectivity, high-sensitivity data, and complex multi-party trust relationships. It gets harder to defend as the sophistication of attacks against it increases. The post-mortem analysis from 2024–2025 gives us the patterns. The defenses exist. The work is implementing them before the next wave, not after.