What stopped

The Superior Tribunal de Justiça is Brazil's highest court for non-constitutional matters - the last instance for most of the civil and criminal law that affects ordinary life. On Tuesday 3 November 2020 it identified a cyberattack on its network. The website went down the same day. Case files and the court's email were inaccessible.

The court's response was to take everything offline to preserve its integrity, and then to do something that has no equivalent in most breach stories: the president of the court issued a resolution suspending judicial sessions and procedural deadlines. Only urgent matters - habeas corpus, injunctions - would be heard. In a legal system, deadlines are not administrative conveniences; they are the mechanism by which rights are preserved or lost. An attack on a file server had stopped the clock for an entire jurisdiction.

The suspension ran to 9 November and the website returned on the 10th. The court announced that its technology secretariat had completed the restoration of the system on 18 November - fifteen days after the attack was identified. All of this happened while the judiciary was working remotely because of the pandemic, which is part of why it mattered so much and part of why it was possible.

What hit it

The malware was identified in security reporting as RansomEXX, a repackaged strain that had become known in June 2020 after an attack on the Texas Department of Transportation. Journalists reported a ransom note left in a text file on at least one server, named in a form matching what researchers had recorded in other RansomEXX incidents. Reporting also put the scale at more than 1,200 virtual machines encrypted.

It was widely described in Brazil as the most serious security incident ever suffered by a public body in the country.

The contradiction, which is the interesting part

Here the record does not agree with itself, and the disagreement is more instructive than a clean story would be.

The court's account: the system backup was not affected by the attack, which is what allowed the files to be restored.

Security reporting's account: the attackers encrypted the virtual machines and destroyed the backups.

Both statements are on the public record. They cannot both be complete. And a third thread runs alongside them: the court never confirmed that a ransom had been demanded, which led at least one legal analysis to note that, strictly, it could not be stated with certainty that this was at all - the classification rested on reporting rather than on anything the institution said.

There is no way, from outside, to resolve this, and pretending otherwise would be dishonest. What can be said is what the disagreement demonstrates. An institution recovering from an attack is answering to several audiences at once - litigants who need to know their case still exists, a legislature, the press, and an adversary who is still reading. Its statements are shaped by all of them. Security reporting, working from artefacts and from people who saw the machines, answers to a different audience and is often more specific and less accountable. A practitioner reading a public incident account should assume it is true, incomplete, and shaped - and should notice which questions were not answered rather than only reading the ones that were.

The RSA and DigiNotar article makes the same observation about 2011 from the other side of the world.

It was not one attack

The STJ is remembered because it was the biggest, but the sequence around it is the part a practitioner should take away.

The Tribunal de Justiça de Pernambuco reportedly suffered a similar intrusion on 27 October, a week before. On 5 November, two days after the STJ, the databases of the Federal District's economy secretariat and of the National Council of Justice were attacked; the health ministry reported an attempted intrusion. The Federal Police, which opened an inquiry at the justice ministry's direction, examined whether the STJ attack was connected to the intrusions at federal district and federal bodies. Army intelligence assisted the response.

Read as a set rather than as one event, this is a campaign against a sector - courts and the federal administration - within a fortnight, in a country whose judiciary had just moved its work online. That is the same shape as the managed-file-transfer campaigns the Progress entry records: an attacker who has learned that one category of victim shares software, suppliers and habits, and works the category rather than the target.

This case sits at the end of a sequence: the Brazil thread reads it together with the market reserve, the governance model, the payment-fraud industry and the data protection law, in the order in which they caused each other.

Why this belongs on a Brazilian practitioner's reading list

Because the consequence class is different. Most breach stories end in money or data. This one ended in suspended legal deadlines and cancelled hearings, which is to say in delayed justice for people who had no connection to information technology at all. When you argue for a segmentation project or a backup test, this is the example where the harm is legible to a non-technical audience.

Because recovery took fifteen days, with the state's resources. The court had the Federal Police, army intelligence and unlimited political attention. Fifteen days. Any organisation estimating its own recovery time against a smaller budget and less help should use that number as a floor rather than a ceiling.

And because the backup question is the whole ballgame. Whichever account is correct, the case turns on it. If backups survived, they were the reason the court came back; if they were destroyed and something else was used, then the recovery happened in spite of the backup strategy. Either way the practical instruction is identical and is the one the NotPetya article draws from Maersk's accidental offline domain controller: a backup that is reachable from the network that is being encrypted is not a backup. Offline or immutable copies, tested restores, and a documented recovery time are the three things that decide the length of the outage, and none of them can be arranged after the event.

Sources