Technology News • • 5-8 minutes

The Rosstat Cyberattack: Seven Days Without Publishing Data and What It Teaches About Continuity

Diego Cortés
Diego Cortés
Full Stack Developer & SEO Specialist
Share:
The Rosstat Cyberattack: Seven Days Without Publishing Data and What It Teaches About Continuity
Image generated with AI

Rosstat confirmed a coordinated cyberattack on its online services between October 29 and November 1. A week later, the systems are still not restored and economic reports are delayed until November 13.

What Happened at Rosstat and Why It Matters

Rosstat is Russia's federal statistics service: inflation, prices, population and economic activity. Its series are what analysts, newsrooms and companies rely on, and much of that work is published from its own web systems.

Coordinated Attacks Between October 29 and November 1

The agency acknowledged the attack on its online services in that window, and Tom's Hardware places the hits on the servers between October 29 and 31. Two groups, Silent Crow and the Belarusian Cyber Partisans, claimed the operation: they say they reached the internal network, with access to roughly 25,000 machines and 23 TB of data, including war casualty figures.

A Week Later, Reports Are Still Late

On November 7, Bloomberg reported the systems were still down: economic reports are delayed until at least November 13, two weekly price releases were postponed several times before going out, and some previously published information vanished from the site. Administrative deadlines moved too: forms P-1 and C-1 can be filed until the 13th.

What Is Confirmed and What Is Not

What the Agency Acknowledged

The attack, the date window, the delays and the filing extension for companies. That is in its own statements and in the outlets quoting them.

What the Attackers Claim and the Agency Denies

The 23 TB figure, access to 25,000 machines and the casualty data are the attackers' claims. Rosstat admitted the attack and denied the theft. Without independent verification, this is written as what it is, a claim: a leaked figure nobody could cross-check is not a fact, it is a version.

What Breaks First When a Data Site Goes Down

The Publishing Calendar Is the First Service Users Lose

Someone reading a statistical series does not need the server: they need this month's figure on the date they expected it. Once that date passes, the user has gone elsewhere. Continuity runs on two clocks: the system clock, measured by RTO (how long you take to come back), and the calendar clock, measured by RPO (how much data you can lose). A two-day RTO sounds reasonable until the commitment was weekly and the week is already gone.

Administrative Deadlines Drag Behind the Down System

When the site that receives the forms is down, the legal deadline moves with it. The cost stops being a broken website: it becomes a third party's paperwork reopened.

Three Decisions That Prevent a Week of Downtime

Immutable Backups With a Restore You Actually Test

Having a backup is not having recovery: a copy never restored in a clean environment is a hypothesis. Keep immutable or offline copies against ransomware encryption, and run a restore drill with measured time. If you do not know how long you take to come back, you do not have an RTO, you have hope. The same logic applies to patching: a critical unauthenticated vulnerability does not wait for you to have free time.

Read-Only Publishing From Static Copies

The last good state can be saved as static HTML and CSV. When the transactional system goes down, serve that snapshot read-only with the cutoff date visible, instead of a 503 for a week. The data is old and you say so: a dated number beats an error screen.

A Communication Plan With Dates, Not "We're Working on It"

A notice with a specific date, something like "the report ships on the 13th", cuts down on queries and holds trust together. Seven days of "we are working on it" turn a technical incident into a reputation problem.

Conclusion

You can contain an attack; you cannot get the missing week back. The real damage was not done by the hack, it was done by a stopped calendar. If you run systems that publish on a schedule, check three things today: when you last tested a restore, which snapshot you would serve if the database stopped answering, and who would get a specific date. We keep taking apart the infrastructure news that ends up on your server.

Categories