yup. But the fact they're using bitcoin shows a clever way for ransomware to collect payment with virtually zero-risk; since it's not possible(that I know of) to really trace exactly who, in real life, got those bitcoins. Which means, ransomware might make a strong comeback since the risk is now basically zero, this program isn't that difficult to write and there's real money to be made. Even if you only charged 50 USD, this idea would make hundreds, if not thousands, a month. Change the binary every once in awhile so its signature doesn't match popular anti-virus databases and you got free money coming in for... well ...forever[1]

1. Educating users to stop running random programs in zip files attached to emails, is apparently impossible. Maybe email-clients should scan the contents of any zipfile it receives and if it finds any kind of executable, put up all kinds of warning dialogs saying "You really don't want to run this. There's no reason to get a program in zipped email attachment nowadays. Please go consult your IT-admin or somebody who knows about computers for a 2nd-opinion"

the bitcoin pseudo-anonymity is a plus, but i feel the real value in this new round of ransomware is that the unlocking actually works. Its possible for the ransomware app to verify payment and unlock itself, with no contact or control from the ransomware author, greatly reducing the author's risk. Actually, its easier for the victim too - rather than wiring funds to some bank account in far off lands, a quick anonymous digital payment instead. Im speculating but its possible for the app to query blockchain.info for a deposit for a given address, or (less likely) for the app to download the blockchain itself, and then unlock after a certain balance. If there is high confidence that the data will actually get unlocked, that swings the balance of fight the app or pay the app towards the pay the app side. The author sits back and waits for those wallets to fill up.

The way this ransomware works still requires a centralized command and control server; without one, it would be possible to trigger the "unlock" codepath in the client without paying the authors.

The authors run a key-storage service which notifies the client (and provides a private key) once payment is received.

In this case the authors are still at a substantial advantage, though - as long as enough unlocks work that "just pay up" is the advice given online, they don't have to care if their C+C server is down half the time or the feds take it down, because the money rolls in even when the decryption isn't working.

That won't work, it could be prevented by a man-in-the-middle attack on the victim's own computer. Just spoof the blockchain signatures required as if the payment was sent on an ad-hoc network and the program would unlock itself.

If blockchain.info was queried over ssl, the spoofing would be a bit harder to pull off.

Lower risk, but it probably reduces income: how many people can figure out how to make a bitcoin payment? How long does it take to make a bitcoin payment? The harder it is, the more likely the target is to give up and do without.

I think their Bitcoin payment method is actually to facilitate international payments (funny in a dark way) - they also take the popular shady prepaid-debit/cash-wire service GreenDot Moneypak and I'd imagine most US victims paid up that way.

There are a couple of anecdotes on Reddit about Canadians and other non-US residents scrambling to find a physical Bitcoin storefront or Craigslist contact to pay the ransom for them since Moneypak wasn't available in their area.

I've never done it before myself, but this looks simple enough; like a paypal donation:

http://shop.wikileaks.org/donate

Now, how the malware-writer goes about verifying payment is beyond my understanding...

I would think their C&C server sets up a random Bitcoin wallet, and waits for a deposit, then allows the private key to be retrieved the next time CryptoLocker phones home.

Actually bitcoin has many strengths, but anonymity is not one of them. There have been multiple papers that go into how easy it is to trace, and even laundering style services like SRO used aren't very good.

http://fc13.ifca.ai/proc/1-3.pdf http://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf

> Educating users to stop running random programs in zip files attached to emails, is apparently impossible.

Imagine something just like the malware we're discussing, but instead of a 72 hour timer, it's a 4 hour timer - and at the end, it pops up a "gotcha! just kidding. but if this were real malware, you would have either lost hundreds of dollars, or all your documents. Don't open attachments like me."

That wouldn’t work. People subjected to this would:

1. Immediately kill the messenger, and

2. Continue to open executable mail attachments, because nothing bad has ever happened that didn’t work itself out in the end.

Yes, but that alone is important. A lot more difficult to shut down.