Aeroflot Hack: Immutable Backup and Disaster Recovery

On July 28, 2025, Russia’s flagship carrier Aeroflot lost the use of its IT systems and started canceling flights. The Foundation for Defense of Democracies reported more than 100 cancellations that day, including international services to Belarus, Armenia and Uzbekistan. Two hacktivist groups, Silent Crow and the Belarusian Cyber Partisans, claimed responsibility.

We are not writing about this because it was an airline, or because of the politics around it. We are writing about it because it is the clearest recent example of an attack with no ransom note — and that makes it an immutable backup and disaster recovery story rather than a negotiation story. When there is nothing to buy back, restoring from a copy the attacker could not touch is the entire plan.

Here is what the reporting supports, what it does not, and what a small business, school district, clinic or government contractor should do with it.

What happened in the Aeroflot cyberattack in 2025?

Attackers disabled Aeroflot’s IT systems on July 28, 2025, grounding flights out of its Moscow hubs. Commentary from LaSoft published the following day reported that the website, mobile app and call center were all offline as well, leaving passengers without a self-service option at the moment they most needed one.

Now the part that most write-ups skip. The dramatic numbers you have seen attached to this incident came from the attackers, not from an investigation:

• The claim of roughly 7,000 physical and virtual servers destroyed originates with the groups themselves and was repeated across press coverage, as summarized by ComplexDiscovery.
• The claims of 22 terabytes of stolen data and remediation costs in the tens of millions of dollars also come from the groups, as Meduza laid out.
• The widely quoted “more than a year” of access before the destructive event traces to attacker statements and early reporting, not to a published forensic finding.

No independent forensic report has been released. We are flagging that because the useful lessons here survive the uncertainty. Even if every attacker claim were inflated, the confirmed facts — a major carrier’s systems disabled, flights canceled, plus reporting that its customer channels went dark — are enough to run your own tabletop against.

How long do attackers stay in a network before they strike?

Long enough to learn your environment in detail. In this case, the reported dwell time was over a year — an attacker claim echoed in early coverage, per Yellowtail, which noted that period was used to map infrastructure and identify critical systems. Commentary from TeckPath framed extended access like that as a symptom of unpatched systems, weak segmentation or stolen credentials, and characterized the intent as destruction rather than ransomware.

Sit with the question for your own organization. If someone had held valid credentials in your environment since last summer, what would they now know? They would know which file server holds the contract deliverables, which virtual host runs the student information system, when your backup jobs fire, and where those jobs write.

Dwell time is a detection problem, which is why backup alone is not an answer. It is why palmiq runs a 24/7 SOC with a 15-minute response SLA on critical issues, and why we care about log retention long enough to answer “how long were they here?” Across our MDR and EDR services we see a 99.9% threat neutralization rate and neutralize 1,200+ threats monthly — that is the detection layer, not a recovery guarantee.

How do you recover if attackers delete your servers and your backups?

You recover from a copy the attacker could not reach, using an identity path they do not control. Post-incident guidance from Cybertex made the point that matters most and gets discussed least: your restore path must not depend on the domain the attacker owns. That means signed golden images stored off-domain, a rebuild-over-clean policy for compromised servers, reissued device certificates and rotated infrastructure secrets.

If your recovery runbook starts with “log into the management console with a domain admin account,” you do not have a recovery runbook. You have a recovery hope.

The rest of the practitioner guidance published after the incident clusters tightly, per both Cybertex and Yellowtail: network segmentation, offline or immutable backup copies, credential rotation and hygiene, and regular audits and penetration testing. Yellowtail put the consequence plainly — recovery from a server wipe is close to impossible without working backups.

What is immutable backup and how does it work?

In general terms, an immutable backup is a copy that cannot be modified or deleted for a defined retention window, even by an administrator account. The storage layer enforces the rule, so a stolen credential is not enough to erase history. An air-gapped copy adds separation — the backup target is not reachable from production in the normal course of business.

Two design questions decide whether yours will hold up. First, can the credentials that manage production also manage the backup repository? If yes, fix that. Second, does the retention lock survive someone with the highest privileges in your tenant? If you cannot answer, that is your next test.

palmiq is an Acronis Platinum partner, in the top 1% globally, and Acronis is the recovery layer we deploy alongside Fortinet or Sophos at the perimeter and CrowdStrike or SentinelOne on the endpoint. Which immutability and retention features are available to you depends on your specific Acronis product and license tier, so we confirm that against current Acronis documentation during design rather than assuming it. No product prevents a determined intruder, and no stack guarantees a clean restore. The goal is to shorten recovery time and improve the odds.

How often should a business test its backup restores?

Often enough that the last successful restore is recent, timed, and performed from the copy you would actually use in a crisis. “We back up” and “we restored last quarter, with a stopwatch, from an immutable copy, without domain credentials” are different sentences. LaSoft’s commentary made the same observation: plenty of organizations believe they are protected until someone attempts a restore.

Five questions worth taking to your next leadership meeting:

1. When did you last complete a full restore test, timed?
2. Is at least one copy immutable and unreachable from your production domain?
3. If your domain controllers were destroyed, what is your recovery order?
4. Which systems are you contractually obligated to bring back first?
5. Who talks to customers when the website, app and phone system are all down at once?

That last one is not an IT question, and the reported simultaneous loss of Aeroflot’s web, app and call center is why it belongs on the list. Pre-drafted status page, an alternate mail path, a printed contact tree.

What is the difference between backup and disaster recovery?

Backup is a copy of data. Disaster recovery is a tested sequence that returns the business to operation within an agreed recovery time objective, with an agreed recovery point objective for how much data you can afford to lose. One is an artifact; the other is a plan with owners, order of operations and proof.

Priorities differ by sector. A K-12 district in the middle of state testing needs the student information system and network authentication back first. A government contractor holding CUI needs to restore without dragging unverified images back into a controlled environment. A clinic needs the EHR and its dependencies, in order.

On compliance: contingency planning and backup expectations appear in the frameworks our government, healthcare and education clients are held to, and the exact control text changes over time — verify current requirements with your assessor or counsel. palmiq supports your compliance efforts; we do not issue certifications or legal advice.

Where to start

Pick one thing this month: a timed restore test of your most critical system, from your most protected copy, without domain credentials. Whatever you learn will tell you what to fix next.

If you would rather not run that alone, book a discovery call and we will walk your recovery path with you.