I am not sure that being able to trigger the deletion of all data in one sweep would be of any interest to the attacker. Firstly, if they simply chose to stop ransoming decryption keys, the encrypted data would effectively be deleted anyway, and secondly, deleting the data would foreclose on any prospect of further gains from the attack.
"Due to interference, we are no longer able to process unlock requests. Goodbye."
It's probably easier, as you point out, to have the virus delete its keys and wipe itself out. (And has the added benefit of taking some forensic info with it.)
But in a marketing sense, blaming people interfering with your network for the lost data may make you safer, as many victims are likely to prefer you extorting them to the good guys causing data loss by stopping you.
> Two domains, one defuses the ransomware, the other detonates it.
And one of the domains will be called redwire[randomchars].com, and the other bluewire[randomchars].com. Which one do you sinkhole, the red wire or the blue wire?
You just test both in a disposable environment, and then you know which one to sinkhole publicly.
The researcher in this case registered the domain right away because he had experience that that creates a positive result. Once that sort of thing starts creating bad results, then researchers will start testing more carefully before grabbing domains.
This would be Very Bad if your ISP is one of those that intercepts NXDOMAIN responses and instead returns an A record to some other "helpful" thing... or some DNS provider that returns a "this site has been blocked by your administrators" page...
Why? What would be the goal? If you're in ransomware business, why would you ever want to delete data before the scheduled time? You want to get paid instead.
So you'd slow the researcher by a few minutes of extra disassembly time if they needed to be careful - what would the malware authors gain here? A few more potential payments in that timeframe? Same time could be invested in improving the sandbox detection instead of creating fun decoys that will be identified anyway. It was still only version 1, we'll see how v2 evolves.
> Same time could be invested in improving the sandbox detection
It isn't an either-or proposition, and the psychology of the conflict is important. If you force your opponent consider every possible move to be potentially dangerous, you slow them down by more than just the cost of the game with a domain name. And that's valuable.
Googling for "OODA Loop" might be helpful in thinking about this.
Wow! Thanks for mentioning OODA (https://en.wikipedia.org/wiki/OODA_loop), never heard of that before. That's a really intriguing concept... so many cogsci, ML, netsec, and game theory connections. While the wikipedia page is rather sparse, it's already added a few things to my reading pile.
One thing I was curious about as I read this was: are there not extenuating circumstances during which the domain registrar can seize a domain? If say, this domain that was unregistered had been registered, is the fact that it's controlled already mean that there's no way to reset it to a new registrar?
Yeah, I guess in his experience that scenario is less likely tan it being a c2 endpoint so he made the decision on that. And it turned out to be the correct one and might have prevented this from becoming a much more destructive blaster worm.
Ransomware authors could come up with better flags than registering a domain since anyone can do it. Why not do something like creating an ipns address in ipfs and check if it contains something? Nobody but them would be able to put content at that address and can be checked through multiple gateways.
The malware could have just as easily used the registration of that domain as a flag to start deleting data, no?