THE SWARM EFFECT: Why Parallel Ransomware Activity Is Now the Real Risk to SaaS and Why Backup needs Independent identity-resilient backup architecture

(FullBackup Threat Intelligence - November 2025)

The Threat Has Mutated

For a long time, organisations treated ransomware like a single-event crisis:

One attacker.

One compromise.

One clean-up.

One recovery.

That model no longer fits the world we operate in.

Threat intelligence across 2025 points to a different pattern entirely: multiple ransomware groups active in the same window, each running their own campaigns, each exploiting the same identity weaknesses that almost every SaaS platform depends on.

They’re not collaborating.

They’re not synchronised.

They’re not sharing infrastructure or objectives.

But the effect is the same for defenders: persistent, multi-directional pressure on identity systems and the SaaS applications built on top of them.

This is the swarm effect - not coordination, but concurrency. The risk created when many unrelated threat actors operate simultaneously across the cloud and identity ecosystem.

Organisations are now shifting toward resilient backup architecture to ensure recovery remains possible even when identity systems or SaaS tenants are compromised.

A swarm of ransomware variants - the reality driving boards to demand fast, clean, independent recovery.

The Swarm Effect: Many Attackers, One Problem

October didn’t deliver one dominant ransomware group — it delivered many.

Activity spiked across:

• LockBit

• Medusa

• RansomHub

• Hunters

• 8Base

• Play

• BlackSuit

• Cactus

  
  

Each group runs its own playbook.

Each targets different industries.

Each uses different intrusion methods.

Each probes different layers of the modern SaaS stack.

None of them work together.

But they do operate in the same month, often the same week and that overlap creates a level of background risk far higher than most organisations are built for.

From the defender’s side of the fence, it doesn’t feel like eight separate campaigns. It feels like one continuous, unbroken pressure coming from every angle.

That’s the swarm effect in practice:

not collaboration, but concurrency, many independent attackers active at once, all exploiting the same structural weaknesses in identity and SaaS.

Identity Is the New Blast Radius & Why Identity Resilient Backup Architecture Matters in 2025

Attackers don’t break in through servers anymore. They break in through identity.

It’s the part most resilience plans still underestimate.

Groups like UNC3944 (Scattered Spider) proved this repeatedly. They didn’t need hypervisor exploits or kernel flaws. They gained control by undermining the trust layer:

• MFA fatigue

• SIM swapping

• social engineering of identity support

• OAuth consent abuse

• session hijacking

• cloud admin portals

• SaaS-level permissions

Once identity falls, every system that trusts that identity becomes exposed - immediately.

In a cloud-first organisation, that means the entire SaaS estate:

• M365

• Entra ID

• Okta-federated apps

• Salesforce

• BambooHR

• Confluence

• DevOps tooling

And yes - the backup systems that authenticate through the same identity plane.

Identity compromise doesn’t give attackers access to one system. It gives them access to all of them.

That’s why identity is now the real blast radius.

Why Identity Breaches Break SaaS Backups

Identity attacks don’t stop at production systems, they extend instantly to anything that depends on the same identity plane.

If your backup lives inside the same tenant, trusts the same OAuth permissions, or uses the same admin accounts, it becomes part of the blast radius the moment identity falls.

This is exactly how real incidents unfold.

M365 / Entra ID

Most backup tools operating inside Microsoft 365 inherit the same trust boundaries as production. They rely on:

• Entra ID authentication

• OAuth applications

• delegated in-tenant permissions

• Microsoft API scopes

• the same admin identities used for everyday access

So when identity is compromised, attackers can:

• strip or modify backup permissions

• delete or corrupt connector apps

• shorten or disable retention

• purge objects or entire workloads

• impersonate backup administrators

• delete snapshots

• poison or erase audit logs

None of this requires ransomware.

None of this requires encryption.

Just control of identity.

If the backup lives inside the tenant, it lives inside the blast radius.

Okta

Okta increasingly acts as the identity broker for entire SaaS estates .When Okta is compromised, attackers can:

• create shadow admin accounts

• bypass MFA

• grant malicious OAuth consent

• steal tokens

• impersonate administrators

• escalate privileges across connected apps

Any backup solution that authenticates through Okta inherits the same exposure. Once identity is compromised, the backup layer becomes accessible, or modifiable through the same trust path.

HR, CRM, Collaboration & DevOps SaaS

UNC3944-style identity attacks affect platforms such as:

• BambooHR

• Salesforce

• Dynamics 365

• Confluence

• Jira

• Azure DevOps

• Zendesk

If backup data is stored inside these platforms, or if recovery relies on the same SaaS identity trust, the backup fails for the same reason the platform fails.

The backup is not separate - it is downstream of the same compromise.

When attackers take identity, they inherit everything that trusts it - SaaS platforms and any backups stored inside them. This is the shared blast radius.

In-Platform Backups Fail for the Same Reason

Attackers don’t need to “break the backup.” They simply:

• break the identity layer

• hijack OAuth relationships

• disable connectors

• escalate privileges

• modify retention

• poison logs

• delete snapshots

• disrupt API scopes

Once identity fails, everything inside that boundary becomes exposed - including backups.

This is why snapshots, versioning, recycle bins, API-driven retention, and in-tenant backup layers are no longer resilience strategies.

They’re support features - not recovery systems.

Real resilience requires the recovery layer to sit outside the identity plane entirely.

Regulators Already Agree - Why Resilient Backup Architecture Matters in 2025

The shift toward independent, immutable, out-of-band recovery isn’t just best practice, it’s quickly becoming the regulatory baseline across Australia. And every major framework points in the same direction: recovery must survive a failure of the system being recovered.

APRA CPS 230 - “Recovery must survive system failure.”

CPS 230 requires entities to prove they can recover from operational disruption.

That is only possible when recovery data is stored outside the system or service experiencing the failure.

Backups held inside the same SaaS tenant, relying on the same identity boundary, cannot meet this requirement — because the failure and the backup sit inside the same blast radius.

Essential Eight - “Isolation and immutability.”

The ACSC’s Essential Eight calls explicitly for:

• immutable backups, and

• isolation from compromise pathways.

In-tenant snapshots, SaaS recycle bins, and cloud-native version histories fail both tests.

ACSC Cloud & Identity Guidance - “Identity compromise breaks everything behind it.”

The ACSC has repeatedly warned that identity compromise undermines:

• authentication,

• access control,

• audit integrity,

• privilege separation, and

• operational continuity.

This is why the ACSC recommends segregating identity, administration, and recovery functions.

If your backups use the same identity provider (Entra ID, Okta) as production, they inherit the same vulnerability and break this requirement outright.

ISO 27001 - “Recovery data must be independent and non-repudiable.”

ISO 27001 requires controls ensuring that recovery data:

• cannot be altered,

• cannot be repudiated, and

• remains available even during system failure.

This presumes a recovery layer that is operationally separate from production systems. In-platform backups simply cannot satisfy this.

SOCI Act & CIRMP - “Backup must withstand a critical-infrastructure failure.”

For operators regulated under the Security of Critical Infrastructure (SOCI) Act, backup isn’t an IT best practice - it’s a statutory requirement embedded in the Critical Infrastructure Risk Management Program (CIRMP).

SOCI expects operators to:

• maintain system availability during cyberattack,

• demonstrate continuity, and

• prove recoverability even when primary systems or identity layers are compromised.

Any backup held inside:

• the same SaaS platform,

• the same cloud region,

• the same identity domain, or

• the same administrative boundary

fails this expectation.

If identity collapses or if a SaaS provider suffers a disruption - SOCI requires that recovery remains possible.

This is only achievable when backup data is held outside the compromised system and outside its trust boundary.

Independent, sovereign, immutable backup (Keepit + ExaGrid) achieves this.

In-tenant SaaS backups do not.

Australian Incidents Confirm the Trend

Across the last two years, Australian breach reports show the same root cause repeatedly:

identity compromise → SaaS disruption → data loss or administrative lockout.

And in every case where organisations relied on in-platform backups, the result was identical:

the “backup” was trapped inside the same environment that had already failed.

The FullBackup Approach: Selecting Technology That Survives Modern Threats

Modern ransomware and identity-driven attacks require more than one tool, one platform, or one vendor mentality. We select the best technologies globally for the specific weaknesses attackers now exploit: identity compromise in SaaS, and privilege escalation in infrastructure.

Two technologies stand out because they solve different halves of the modern failure pattern.

Keepit - True Independence From SaaS & Identity

Keepit protects SaaS workloads by storing backup data completely outside the platform it is protecting. That includes:

• outside the customer tenant

• outside Microsoft/Entra ID

• outside Okta

• outside Salesforce, BambooHR, and Atlassian

• stored in sovereign Australian data centres

• enforced through immutable retention

• with no reliance on OAuth or production identity

• no trust in the SaaS provider’s control plane

Because Keepit operates in a separate identity domain, identity compromise cannot reach it.

UNC3944-style intrusions, OAuth manipulation, administrator impersonation, and token theft - none of these can alter or delete Keepit backups.

Retention is fixed.

Data is immutable.

Recovery is guaranteed even when the SaaS tenant or identity layer is fully compromised.

This is what it means to be outside the blast radius.

Identity compromise doesn’t stop at production. In-platform backups fall with the tenant. Only an independent, immutable vault like Keepit stays outside the blast radius.

ExaGrid - Isolation From Privilege-Based Tampering

In infrastructure environments, the failure point isn’t usually encryption anymore - it’s privilege.

Once an attacker gets domain admin, root, or hypervisor control, most backup platforms collapse with the rest of the estate.

ExaGrid breaks that pattern.

Its architecture puts the protected data on a non-network-facing Tier-2 repository, a tier you cannot address, scan, or delete from over the network. On top of that, ExaGrid layers:

• Immutable objects

• Time-Lock retention

• Delayed deletes

• A design where even ExaGrid admin credentials cannot purge data

ExaGrid’s tiered architecture keeps backups outside the blast radius - fast Landing Zone performance up front, and a locked-down, non-network-facing Repository Tier with Time-Lock protection behind it.

This flips the usual attack flow on its head.

Attackers can move through the network.

They can escalate.

They can take domain admin.

They can compromise vCenter or the hypervisor itself.

But they still cannot touch the data sitting inside ExaGrid’s isolated repository tier.

That’s the entire point:

privilege escalation no longer equals backup deletion.

Even a full Active Directory breach - the nightmare scenario - cannot reach the copies held in that tier.

This is what true ransomware-resilient infrastructure backup looks like.

The Bottom Line

Multiple threat actors operate at the same time - and almost all of them break in through identity.If your backup depends on the same identity plane attackers are already exploiting, your recovery plan is compromised before the incident even begins.

The path to resilience is simple, but it’s architectural, not operational:

FullBackup delivers this model across Australia using independent recovery platforms forM365, Entra ID, Okta, Salesforce, BambooHR, Confluence, and hybrid infrastructure workloads.

If you want a recovery layer that sits outside the blast radius, aligns to real-world threat behaviour, and meets CPS 230, Essential Eight, SOCI and ISO 27001 expectations, talk to us.

We’ll map it clearly and show you what resilience actually looks like in 2025 and beyond.