Endpoints like PCs and servers check in with domain controllers at recurring intervals, so even if all endpoints are behind firewalls and can’t talk to one another, they still reach out to domain controllers periodically to pull down configuration updates and so forth.
Firewalls do absolutely nothing once someone got your weakest link to click something and go to town.
From my last penn test it goes, phish, get a click and execute or credentials, use a hack like getting legacy NetBIOS exploit to give up hashes for all your users, crack the hashes and hope someone used a short 12 char password or something dictionary-easy like “Wr3st1ing1!”, then leverage that access again and again until you have a printer that someone gave domain admin access to because it was easier than setting correct policies, an admin actual, a service not account that has good AD privileges, etc. Then start pushing software as admin.
Most of the time it’s not even this complicated.
The only thing that “saves” you from paying the ransom is good backups. But if a group is fairly competent, they’ll encrypt your backups too. So it needs to be offline.
I don’t have much love for Barracuda Backup, but for very little money you get nightly offsite backups that might just save your cyber insurance or company itself from having to pay.
Disaster recovery can be quick if you can restore hundreds of virtual servers (and you're going to have hundreds), whole key machines, and all the user and network config from backup. If all you have is data files and bare hardware, then the business is going to have a lot of expensive downtime while you rebuild all the infrastructure. "cattle not pets" approach and automated provisioning of machines from config files helps in this regard, but almost no company has that for all their critical infrastructure, especially if we're talking about non-IT companies whose critical infrastructure is not some single consumer-facing app (e.g. Twitter), but a diverse, distributed collection of third-party IT solutions for various business-critical needs.
This is the part I’ve never understood. Surely you should be backing up in an append only fashion initiated from the backup server?
My best guess is that this gets managed from AD as well, so they find it and take over?
The key idea is assuming everything is compromised. Whether you use append or whatever, is not helpful if the functionality to change that configuration exists, because that gets changed, backup server is gone, backup storage is gone, etc.
You have to design a system where even a rogue IT admin with full access to everything can’t screw you. Usually that involves third parties where there is no mechanism for a rogue IT person or other attacker to delete your offline backups. So some people have Iron Mountain pick up disks in a lock box daily, or use an online backup service that specifically has features for this, where they keep extra copies of your backups completely offline and provide no mechanism for the customer to delete them.
OK, brilliant — this is a nice articulation of a fundamental principle.
Do you know of any books that describe how to design such systems?
Guaranteeing that offline backups exist is a great start, but if the backups contain backdoors, restoring could be extremely laborious and yet unsuccessful.
I do wonder if some of my misunderstanding is because my experience is mostly SaaS companies, so paying external providers is more “natural” vs a company that makes its money selling units.
Related - see how many examples of S3 policies split access into read and write rather than read, append, write. It doesn't even matter where the logic lives - only whether the storage service allows you to delete anything.
The trick is to get another S3 account (or any large storage really), to download everything from that bucket periodically. The "replication" needs read-only access to the first bucket. The second account doesn't need to be accessed by anything or anybody so it is relatively safe.
Well, fw would be effective if organizations used network segmentation effectively, but of course close to no one does that in practice (e.g. usually IT/support have access to everything).
It is quite challenging to recover from this kind of breach since the attackers had every opportunity to touch every system connected to the AD and leave backdoors behind. I have seen companies trashing their whole AD, re-imaging all machines and basically starting from scratch at great cost.
(They might still have to reimage all their machines but at least they still have a list of employees and customers)