4 ms·
My very good guess is that you had a database failure caused by a crypto virus. They will not wish to announce that this was the root cause until A. A plan of
by postingposts 5y ago
My very good guess is that you had a database failure caused by a crypto virus. They will not wish to announce that this was the root cause until
A. A plan of action to avoid a future infection can be enumerated.
B. They can be certain they will restore the functionality of the trains.
The other part of my guess is that they have a SQL db which is stored on /likely/ a windows server instance. I’d even surmise that this instance may be hosted on Azure but that’s speculation, not a good guess.
- lucb1e 5y agoThis is one of my leading theories as well, although I thought they usually hit on Friday night in order to catch admins off-guard and encrypt as much as possible before being stopped? "The IT failure occurred at the end of [Sunday] morning". On Sunday there is also not as much pressure to get things running as there would be on Monday. Or perhaps this is the incentive to pay now and get things fixed on time for the work week? In that case Friday night would again have made more sense unless the attackers have some very specific insight into how much slower restoring without paying is. My alternative theory is an expired certificate that makes some core systems just not talk to each other anymore. The announcements on the stations, for example, were also out, and they lost control of the mobile apps (couldn't make the apps show that trains didn't run, the in-app scheduler showed all was A-OK), and that sounds quite dissimilar from the core train operation service, making me think it's more of an infrastructure than a specific system's problem. On the other hand, once the app could be controlled again (assuming this singular underlying cause), you'd think they could then also start putting train service back in place and that didn't happen for hours still. I can't really make the pieces fit together for any theory, so then presumably something multi-faceted (one thing tripping one or two other things so it escalated from restarting one component to not being able to restart the trains anymore the whole day).
- withinboredom 5y agoCertificates make the most sense to me. The delay can possibly be due to cached certificates, having to find the person to sign the CSR (assuming in-house PKI or even just someone with access to the right email address for external PKI), and/or a CA that isn’t valid on the machines.
- rocqua 5y ago> On the other hand, once the app could be controlled again (assuming this singular underlying cause), you'd think they could then also start putting train service back in place and that didn't happen for hours still. Before you can get the actual service up and running, you need to get trains and personnel to the right locations. So I don't think this discredits your theory as much as you think.
- postingposts 4y agoIt takes time to roll the backups out and define the level of affected systems before doing so. That’s your time window.
- skeeter2020 5y ago>> but that’s speculation, not a good guess. Well, as long as you're clearly stating _this_ part of your otherwise validated and highly likely pre-post-mortem is speculation... </s>
- slim 5y agoMy guess for the attacker : conti ransomware group. They've been pretty active since Ukraine war. Last weekend they targeted the central bank of Tunisia
- jollybean 5y agoWhat would lead us to be inclined to believe that this is a 'very good guess'?
- glitchcrab 5y agoPeople are very good at putting 2 and 2 together and getting 655.
- gpvos 5y agoDo you have any way of backing up that guess related to NS, or are you just wildly speculating?