Exfiltration in Plain Sight: How the SafePay Ransomware Group Abused OneDrive to Steal Data

Ransomware defenses have traditionally focused on stopping encryption, blocking malicious infrastructure, and identifying suspicious tools. But in a recent ransomware investigation, Sygnia uncovered a more difficult detection problem: the attacker used Microsoft OneDrive as the exfiltration channel.

After a conventional FTP exfiltration attempt was blocked, the threat actor adapted. They installed the legitimate, Microsoft-signed OneDrive client on a compromised server, authenticated to a Microsoft 365 tenant they controlled, and placed staged data into the OneDrive sync folder.

From there, OneDrive did exactly what it was designed to do. It synchronized the files to the cloud over ordinary HTTPS.

To network and endpoint controls, much of that activity looked legitimate. The destination was Microsoft. The protocol was HTTPS. The application was trusted and signed. There was no unusual command-and-control infrastructure required for the transfer.

This real-world investigation illustrates an important shift in ransomware defense: organizations need to look beyond whether a destination or application is trusted and ask whether a trusted service is behaving as expected in its business context.

What is SafePay?

SafePay is a ransomware operation observed since the second half of 2024. Like other double-extortion groups, its model is not limited to encrypting systems. The attacker first steals data, creating leverage through the threat of disclosure, and then encrypts the victim environment.

That sequence changes the defensive priority. By the time ransomware encryption becomes visible, sensitive information may already have left the organization.

In the incident investigated by Sygnia, SafePay followed exactly this pattern. The threat actor gained access, escalated privileges, performed reconnaissance, targeted backup and virtualization infrastructure, staged valuable data, exfiltrated it, and then deployed ransomware.

Why are ransomware groups using trusted SaaS services for data exfiltration?

Trusted SaaS services can allow attackers to make malicious activity resemble normal business traffic.

Security teams have become increasingly effective at identifying conspicuous exfiltration channels such as raw FTP, suspicious hosting infrastructure, and known file-transfer services. But organizations cannot simply block platforms such as Microsoft OneDrive and SharePoint when those services are fundamental to business operations.

This creates an opportunity for attackers. Rather than trying to defeat a security control directly, they can exploit the organization’s existing trust in legitimate cloud infrastructure.

The SafePay investigation demonstrated that shift clearly. The attacker’s first exfiltration method was conventional: FileZilla and FTP to an external IP address. Egress filtering blocked the attempt.

The attacker did not abandon the operation. They changed tactics.

That is an important operational lesson for defenders. A successfully blocked exfiltration attempt should not automatically be treated as the end of an incident. It may be an early indication that an attacker is already staging data and looking for another route out.

How did SafePay gain access to the victim environment?

In this investigation, initial access involved exploiting two weaknesses working together: a vulnerability affecting an internet-facing FortiGate SSL VPN appliance and a weak, overprivileged administrative account that lacked MFA.

Once inside, the attacker reached domain administrator privileges within hours.

From there, much of the activity relied on tools and functionality already present in the environment. The threat actor used RDP, administrative shares, PowerShell, and other native capabilities for lateral movement and reconnaissance. Open-source tools were also used to enumerate systems, locate valuable file shares, and search for credentials.

The attacker paid particular attention to virtualization and backup infrastructure, including Veeam. That focus was strategic. Backup infrastructure is essential to recovery and can also provide privileged access across large portions of the environment.

The attacker then identified valuable data, copied it to a staging system, compressed it, and divided it into multipart RAR archives. After transfer, the archives were deleted.

How did SafePay use OneDrive for data exfiltration?

After the FTP attempt was blocked, the attacker installed the legitimate Microsoft OneDrive sync client on an already compromised server.

They then authenticated the client to a Microsoft 365 tenant under their control. The staged RAR archives were placed inside the corresponding OneDrive synchronization directory.

No custom exfiltration malware was necessary. OneDrive identified the new files and synchronized them to the attacker’s cloud environment over HTTPS.

The result was an exfiltration channel with several characteristics defenders normally associate with legitimate activity:

• A trusted Microsoft destination
• Standard HTTPS traffic
• A legitimate Microsoft-signed application
• No suspicious external IP required
• No dedicated malware responsible for the transfer

The exfiltration mechanism was the synchronization process itself.

This can be viewed as living off the land at the cloud layer. Instead of abusing only native Windows utilities, the attacker abused a trusted SaaS application and its expected functionality.

Why can OneDrive exfiltration evade traditional security controls?

Many security controls evaluate individual signals. Is the destination malicious? Is the application suspicious? Is the protocol unusual? Is the executable known to be malicious?

In this case, those individual signals all appeared benign.

The destination belonged to Microsoft. The connection used HTTPS. The executable was Microsoft’s legitimate OneDrive client. The application was performing its intended function.

The meaningful anomalies existed elsewhere: a Microsoft 365 tenant that did not belong to the organization, a OneDrive synchronization directory appearing on a server, multipart RAR archives being staged for transfer, and sustained Microsoft traffic from a system that had little reason to generate it.

That distinction matters. The detection question is no longer simply, “Where is this host communicating?”

It also needs to be, “Does this trusted service make sense on this host, for this identity, with this tenant, at this volume, and at this point in time?”

This aligns with a broader detection principle in Sygnia’s incident response readiness guidance: modern attackers increasingly blend into legitimate activity through trusted identities, tools, and services, making behavioral context and cross-source investigation increasingly important.

How did Sygnia prove that data had been exfiltrated through OneDrive?

No single artifact provided definitive proof. Investigators established the exfiltration by correlating multiple sources of evidence.

Browser history showed access to a OneDrive tenant that had no legitimate business relationship with the compromised server.

Windows ShellBag artifacts showed navigation within the corresponding local OneDrive folder, including the presence of staged RAR files.

Network telemetry showed sustained HTTPS traffic to Microsoft during the data-staging period.

Finally, the NTFS Master File Table, or MFT, preserved evidence of files that had existed on the system even after the attacker deleted the staged archives.

Individually, each artifact could potentially have an innocent explanation. Together, they established a coherent timeline connecting the tenant, local synchronization directory, staged files, and network activity.

This is why correlation matters when investigating trusted-service abuse. Endpoint, network, browser, identity, and filesystem evidence can become substantially more valuable when analyzed together.

What unexpected forensic evidence did the OneDrive sync leave behind?

The investigation produced an unusual secondary finding.

OneDrive synchronization is bidirectional. When the attacker authenticated their Microsoft tenant on the victim’s server, OneDrive did not only upload the victim’s staged data. It also began synchronizing material from the attacker’s cloud environment back onto the compromised server.

That tenant contained data associated with other organizations.

As investigators examined MFT artifacts, they found references to files and organizations unrelated to the victim. Sygnia cross-referenced those names with SafePay’s leak site and identified several as previously disclosed victims. Other organizations had not yet been publicly identified, and Sygnia took steps to notify them.

The attacker’s own exfiltration infrastructure had inadvertently left forensic traces of a broader victim set on the compromised system.

The finding reinforces a core forensic principle: evidence that appears unrelated to the immediate victim may still reveal important information about attacker infrastructure, methodology, or campaign scope.

How did SafePay deploy ransomware after the data theft?

Once exfiltration was complete, the attacker moved to encryption.

The ransomware payload was delivered as a malicious DLL. Rather than executing it through an obviously suspicious standalone binary, the attacker used the legitimate Microsoft-signed Windows utility regsvr32.exe to load and execute the DLL.

Persistence was established through a Windows Run registry key, allowing the malicious code to execute again when the affected user logged in.

From a central server, the attacker ultimately encrypted more than 60 servers, including systems supporting backup, virtualization, file storage, and identity.

Again, the attacker’s reliance on trusted functionality was central to the operation. Legitimate administrative tools and signed binaries provided cover for malicious actions.

What should security teams monitor to detect OneDrive data exfiltration?

Detection should focus on context and behavior rather than Microsoft traffic alone.

At the endpoint level, investigate the creation of new OneDrive tenant directories under user profiles, particularly on servers. OneDrive registration artifacts and configuration data can also help determine which tenant a client has been configured to use.

At the network level, baseline Microsoft cloud traffic by host and volume. Sustained OneDrive traffic from a server that normally does not synchronize files should receive scrutiny, particularly when it coincides with archive creation, staging, or deletion.

For forensic investigations, browser history, ShellBag artifacts, OneDrive configuration information, and MFT entries can help reconstruct activity after the fact.

Most importantly, correlate these signals. An unfamiliar tenant alone may be benign. A multipart archive alone may be benign. Microsoft HTTPS traffic alone is expected. When an unknown tenant, archive staging, unusual synchronization, and abnormal network volume appear on the same host within the same window, the risk picture changes substantially.

How can organizations prevent attackers from abusing OneDrive for exfiltration?

The SafePay investigation points to five practical defensive measures.

1. Restrict outbound access to cloud applications that the organization does not require. Servers should have narrowly defined egress requirements.
   
2. Enforce Microsoft tenant restrictions so managed systems can authenticate only to approved organizational tenants. This directly addresses the technique observed in the SafePay investigation by preventing an attacker from simply connecting a compromised host to an external tenant.
   
3. Audit privileged accounts capable of accessing remote services such as VPNs. Enforce MFA and eliminate unnecessary privileges and legacy accounts.
   
4. Alert on OneDrive synchronization from servers where OneDrive has no legitimate operational purpose.
   
5. Monitor for unknown OneDrive tenant directories and registrations. Knowing which tenants are authorized provides defenders with a comparatively clean baseline against which anomalies can be identified.

Does blocking an exfiltration attempt mean the attack has been contained?

No.

One of the most important lessons from this investigation is that blocking an attacker is not the same as removing an attacker.

The firewall successfully stopped SafePay’s FTP transfer. That control worked exactly as intended. But the threat actor still had access, still had staged data, and still intended to steal it.

The block forced the attacker to adapt.

Security teams should therefore treat blocked exfiltration attempts as potential investigative triggers. Determine which host initiated the connection, what data was being staged, which account was involved, what activity preceded the attempt, and whether the attacker still has alternative routes available.

Preventive controls remain essential because they impose friction and buy defenders time. But the value of that time depends on whether the organization recognizes the signal and responds.

The bigger lesson: hunt for trusted services behaving strangely

The SafePay case reflects a larger detection challenge.

Attackers do not always need malware, unusual infrastructure, or exotic techniques to evade defenses. Sometimes the most effective option is to use the same applications, identities, protocols, and cloud services the business trusts every day.

For security teams, this means moving beyond binary distinctions between trusted and untrusted activity. Detection increasingly depends on business context: which tenant should exist, which application belongs on which host, what normal data movement looks like, and whether multiple low-confidence signals form a coherent attack sequence.

The practical takeaway from this investigation is simple: stop relying exclusively on strange destinations as the signal of malicious activity. Start looking for trusted services behaving strangely.

That shift from isolated alerts toward correlated, behavior-based detection reflects Sygnia’s broader approach to cyber resilience: apply lessons from frontline incident response to improve detection, response, and long-term readiness against the techniques attackers are actually using.

Frequently Asked Questions

Can ransomware use OneDrive to steal data?

Yes. In the SafePay incident investigated by Sygnia, the attacker used Microsoft’s legitimate OneDrive client to synchronize staged victim data to a Microsoft 365 tenant controlled by the attacker.

Why might EDR not detect malicious OneDrive activity?

OneDrive is a legitimate, Microsoft-signed application. If an EDR is primarily looking for malicious executables, the synchronization process may not appear inherently malicious. Detection therefore requires additional context, such as the host, tenant, data volume, and associated staging activity.

What is the strongest indicator of suspicious OneDrive activity on a server?

One high-value signal from this investigation is OneDrive synchronization from a server where the service has no legitimate business purpose. An unknown OneDrive tenant folder on that server provides additional investigative context.

Can organizations block external Microsoft 365 tenants?

The webinar recommends using tenant restrictions and proxy-level controls to restrict access to approved Microsoft 365 tenants. Organizations with legitimate requirements for multiple tenants should design an explicit allowlist around approved tenants rather than assuming all Microsoft cloud destinations are trusted.

What forensic artifacts can reveal OneDrive exfiltration?

Useful evidence can include browser history, ShellBag artifacts, OneDrive tenant and registration information, network telemetry, and MFT records showing staged or deleted files. Correlating these artifacts is more valuable than relying on any single indicator.

Should security teams still block FTP and other obvious exfiltration channels?

Yes. Blocking suspicious outbound channels imposes friction on attackers and can create an early detection opportunity. The key is to investigate the blocked activity rather than treating the control action itself as proof that the threat has been resolved.

Watch Sygnia’s webinar, “Exfiltration in Plain Sight: Inside SafePay’s OneDrive Play”, for a firsthand look at the investigation, the forensic evidence that revealed the OneDrive exfiltration technique, and practical detection opportunities across endpoint, network, and Microsoft artifacts.

On-Demand Webinar

Exfiltration in Plain Sight:
SafePay’s OneDrive Play

Watch the Replay