Why can't the OS be write protected? Why can't the configuration also be write protected?
Why can't the OS be write protected? Why can't the configuration also be write protected?
No matter what the application does, it can't access the backups in such a system.
And if the gang get's admin rights on the box your backups are gone.
How is this program to know that a file edited by the virus to encrypt is legitimate or not when the edit is being made by a user that created and owns those files? The backups themselves can be contaminated months before the encryption and ransomware attack is sprung. Restoring from last week or last month's backup might still lead to your system being encrypted.
Additionally, as the other user pointed out the goal would be to gain access to the appropriate user with the level of permissions, such as an admin or root account, and use those credentials to carry out the attack.
The configuration and data which gets changed all the time is valuable (the effort that was made in making those changes) and the prime target of ransomware, and it can't be write-protected because, well, it needs to get changed. I mean, if "reimage all these computers to the default configuration" would be a viable solution, everybody would just do that instead of paying large ransoms.
Precisely the wrong way to think about this.
If the OS can't protect itself, you've got a system with zero security.
It won't prevent lateral movement through the network (that's often memory only, no need to write to disk), it won't prevent persistence through theft of credentials or kerberos tickets (and possibly make it harder to rotate credentials), and of course it won't prevent the exfiltration, encryption and/or destruction of the actually valuable data.
If we look at an advanced ransom attack (e.g. as many described in this article - manually operated after initial access like many Emotet attacks, not some purely automated malware) then I struggle to imagine what parts of the attack would be thwarted if the OS and config would be write protected - do you have something specific in mind?
First - protect the AD and authentication infrastructure from a black start event.
I'd have an offline physical machine, no matter how old, that was a viable backup domain controller. I would have a stack of hard drives for it, and a copy of clonezilla. Every so often, clone the hard drive, boot the replacement, and sync it with the domain, then turn it off.
For the truly paranoid, do this in each location. Keep the machine and drives in a safe.
Test the black start backups on a temporary network built from spare hardware. Note that if you boot a Windows machine, it might adapt itself to the hardware and cause issues, so discard that image, and regenerate it.
In a black start event, you could turn off all the outside networks, and start with the old AD server, and restore from backups.
--
Any Virtualization or SAN layers should have administrative credentials that are unused for anything else, and only written down on pieces of paper, never scanned or typed in.
All servers should have saved images in offline, unencrypted hard drives, in a safe.
--
The main thing then is to get periodic offline unencrypted backups of the systems and data in a safe.
--
So, if the system is breached, there is at least a way to restore to the last backup, and you have some confidence it actually works.