I have an idea for a way to stop a ransomware infection after it begins. I will preface this by saying I’m not a ransomware or Kerberos expert and my line of thinking may be off. I also know that what I’m asking will not prevent any ransomware attacks.
My thinking is that when ransomware infects a user’s computer, it begins to encrypt as many files as it can, especially shared files. Now if I have file monitor watching my core business files for any changes and I see a user modifying (encrypting) many files more than normal then this might be a ransomware attack. My file monitor can launch a Powershell script if it detects activity such as this. I know how to easily disable a user’s AD account but from what I understand is that with Kerberos when that user tried to access the file share, they were granted an access token. This access token was then presented to the file share validating the user and the file share uses it to grant what files they have access to. Even though the their AD account is disabled this access token is still valid on the file share and can still encrypt files.
I’m looking to see if there is a Powershell command that can remove this access token and cause it to re-authenticate so the infected user can’t make any more changes. I understand that some files may be encrypted but restoring some from backup is better than all.
You’re going to get a lot of false positives with this approach, and at least the .NET FileSystemWatcher could never keep up. You’d have to differentiate between a thousand corporate users legitimately changing a file or two apiece, and one user changing a thousand files - to a watcher, it would look the same, and .NET was never engineered with that level of performance.
And no, you can’t really revoke a token. It’s be easier to just remove that user’s SID from whatever ACLs there are. Which will also be time-consuming. Or, send a forced shutdown command to whatever machine the traffic is coming from (which has the effect of dumping the token cache). I’d argue that the shutdown would be a lot more effective.
Or, if your network is properly built to be secured, send a forced shutdown command, and then tell your internal firewalls to block traffic from that machine. Revoke its DHCP lease in your DHCP server, and replace it with a DHCP reservation for a useless IP address. That way the machine shuts down, and if it comes back up, it’s locked out at the IP level. be sure to do IPv6, too, of course.
As the fall out from this last attack, I’d be curious to see if companies that have invested in Whitelisting were not hit, assuming they had the vulnerability unpatched. I haven’t seen how the ransomware was spreading and propagating on machines, but I would imagine it would still be an exe being downloaded\executed, so a Whitelisted environment should have been safe.