Recovering from WannaCry Ransomware
At this point, I’ve reverse engineered and researched something like 30 ransomware families, from over 1000 samples. Wannacry isn’t really much different than every other ransomware family. Those include other infamous families like Locky, CryptoWall, CryptoLocker, and TeslaLocker.
They all pretty much work the same way, including Wannacry. Actually, this comic sums up the ransom process the best I’ve seen. Every successful family today encrypts each file for ransom with a new unique “session” key, and encrypts each session key with a “public” ransom key making it irrecoverable without the matching “private” key held closely by ransomware racketeers. Those session keys are generated on the host machine. This is where PayBreak shims the generation, and usage of those keys, and saves them. Meaning, the encryption of those session keys by the ransomware’s public key is pointless, and defeated.
The PayBreak system doesn’t rely on any specific algorithm, or cryptographic library to be used by ransomware. Actually, Wannacry implemented, or at least, statically compiled its own AES-128-CBC function. PayBreak can be configured to hook arbitrary functions, including that custom AES function, and record the parameters, such as the key, passed to it. However, a simpler approach in this case was to hook the Windows secure pseudorandom number generator function, CryptGenRandom, which the ransomware (and most others) use to create new session keys per file, and save the output of the function calls.
Recovering files is simply testing each of the recorded session keys with the encrypted files, until a successful decryption. Decrypting my file system of ~1000 files took 94 minutes.
Thanks @jeffreycrowell for sharing a sample. The full paper can be found here: https://eugenekolo.com/static/paybreak.pdf
SHA256 Hash of Sample: 24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c
WannaCry Custom AES: https://gist.github.com/eugenekolo/fe229be2a4230cf8322bf5537e291812