We’re sorry we fucked you over: why paying a ransome may not be the best thing to do

I’ve been contemplating my article title for talking about something that I thought was never a good idea anyhow. Paying for ransome should be nothing but a resounding “no.”

The problem we have, however, is that not everyone has the capability of backing up systems At very large organizations, it may cost a fortune to backup every possible machine’s critical files to a centralized location, and this I can understand. For small businesses, your typical Google, Icloud, Dropbox, Jungle Disk, Amazon or other aspect of backup solutions should suffice depending on your needs.

I pay for Dropbox plus, and I’ve not lost anything critical like web sites and their data. I may have lost items, but they were on the route of the drive, probably for temporary storage and I don’t even remember what I lost.

Even if you don’t pay the ransome because you have the backups, the actors may ask for a second ransome for them not to publish the data they stole to begin with.

This is the best part of the article I really like, and it is the end of it. It says:

“When you look at a lot of ransom notes, you can actually see groups address this very directly and have texts that say stuff along the lines of, Yeah,
you are fucked now. But if you pay us, everything can go back to before we fucked you.’”

How about getting it double when you pay the ransome, and then they want you to pay not to published? You’re just as getting fucked as you would have if you didn’t pay and tried a different method. You’re fucked if you make a mistake, you have backups but they fuck you when you still have to pay.

I may have made mistakes by doing things wrong with my computer, however, I didn’t really fuck myself over because my data was always safe in my Dropbox.

Companies hit by ransomware often face a dual threat: Even if they avoid paying the ransom and can restore things from scratch, about half the time the
attackers also threaten to release sensitive stolen data unless the victim pays for a promise to have the data deleted. Leaving aside the notion that victims
might have any real expectation the attackers will actually destroy the stolen data, new research suggests a fair number of victims who do pay up may see
some or all of the stolen data published anyway.

How is this fair that they can publish the stolen data even if we paid the ransome because we’re a large business? They’re definitely doing this right, and its time we changed it.

“Previously, when a victim of ransomware had adequate backups, they would just restore and go on with life; there was zero reason to even engage with the
threat actor,” the report observes. “Now, when a threat actor steals data, a company with perfectly restorable backups is often compelled to at least engage
with the threat actor to determine what data was taken.”

I could see this, because they need to know how to proceed with letting their customers and steakholders know what happened and how they can prevent this from happening again.

“Unlike negotiating for a decryption key, negotiating for the suppression of stolen data has no finite end,” the report continues. “Once a victim receives
a decryption key, it can’t be taken away and does not degrade with time. With stolen data, a threat actor can return for a second payment at any point
in the future. The track records are too short and evidence that defaults are selectively occurring is already collecting.”

You can’t take back a decryption key, but you can’t even trust that if you even decrypt, that’ll even work because they could’ve done something to it but you can’t take it back. You can learn by not clicking on everything and being caucious even if you’re in a hurry.

I would be looking to see if an invoice is due that day. If so, you should know how the invoice is coming, and not react to something that is just out of the blue.

For more on this very interesting story, check out Kreb’s piece: Why Paying to Delete Stolen Data is Bonkers and feel free to leave those thoughts on this one!