This document outlines Mark Mager's presentation on cryptanalysis of ransomware. The presentation covers the typical execution flow of ransomware, including key generation, file encryption, and leaving ransom notes. It then discusses the cryptanalysis workflow of performing dynamic and reverse engineering analysis. Specific ransomware examples are walked through, including Powerware, Nemucod, TorrentLocker, and Apocalypse. Common issues seen in ransomware crypto implementations are highlighted. The document concludes that cryptanalysis is an iterative process of testing theories and developing proofs of concept to decrypt files.

1. Cryptanalysis in the
Time of Ransomware
July 28th 2017
DEF CON 25 Crypto Village
Mark Mager

2. 2
 Senior Malware Researcher at
Endgame
 Reverse engineer and software dev
 Please note: I am NOT a cryptographer
 Washington, DC area
 Previously at
 US-CERT
 CYBERCOM
 Lockheed Martin
 Battelle
 Twitter - @magerbomb
About Me

3. 3
Agenda  Ransomware Execution Flow
 Cryptanalysis Workflow
 Walkthroughs
• Powerware
• Nemucod
• TorrentLocker
• Apocalypse
 Research in the Field
 Conclusion
 Questions

4. 4
Ransomware
Execution
Flow
 Payload written disk and executed
 Key generation / retrieval
• Exchange with C2 (optional)
 Enumeration / directory traversal
• Files are individually encrypted
• Ransom note in each directory (optional)

5. 5
Cryptanalysis
Workflow
 Dynamic analysis
• Observe network communications
• Analyze encrypted files
∙ Magic byte sequences / watermarks
∙ Whole vs. partial encryption
• Forensic artifacts on disk
∙ Reg keys, dropped files, event logs
• Repeat tests multiple times
∙ Adjust environment as needed
∙ Known / chosen plaintext attacks
 Reverse engineering
• Identify crypto algorithm(s) used
∙ Implementation mistakes that may
potentially weaken the crypto
• Key generation, storage, transmission
 Apply lessons learned to decrypter dev

6. 6
Walkthroughs  Walk through ransomware encryption schemes
that can be defeated
 Older variants that are no longer in circulation
 High level reverse engineering
 Crypto implementation details
• Note any differences b/w note and reality
 Focus on devising POC for decrypting

7. Powerware

9. Enumeration
Crypto setup
File
write
File Cleanup

10. 10
Let’s deobfuscate this a little bit…

11. 11
Much better! Now what sticks out?
 Symmetric encryption
• RijndaelManaged class (AES)
 256 bit (32 byte) key
 Initialization vector
 Padding with zero
 Cipher block chaining (CBC) mode

12.  Only the first 2048 bytes of the file are to be read in and encrypted
 Files less than 2048 bytes are ignored
 No further modifications made to the crypto object before CreateEncryptor()
Deobfuscated file transformation code block

13. 13
Back to the crypto setup…
 Symmetric encryption
• RijndaelManaged class (AES)
 256 bit (32 byte) key
 Initialization vector
 Padding with zero
 Cipher block chaining (CBC) mode

15. Let’s build our own decrypter!

16. 16

17. Nemucod

19. 2048 bytes max
XOR static key

20. 20
Nemucod  Asymmetric crypto
• RSA-1024
 XOR
 Unique key generation
 255 byte key
• Hard-coded
• Same for every file
 Only the first 2048 bytes
 Simple encrypter binary

21. How can we decrypt our files?

22. 22

23. TorrentLocker

26. Decompiled view of ctr_encrypt

27. libtomcrypt source code

28. Decompiled view of aes_encrypt

29. libtomcrypt source code

30. 30
TorrentLocker  From limited reverse engineering we know…
• AES
• Counter (CTR) mode
• libtomcrypt
 Could this potentially be vulnerable?
• Implementation flaws
Source: “Counter Mode Security: Analysis and Recommendations”

31. 31
TorrentLocker  A = large plaintext file of NULL bytes
• Exhaust keystream (if file size limitation)
 B = non-NULL plaintext (arbitrary size < than A)
 ENCRYPT(A) = A’
 A’ XOR A = KEYSTREAM
• A = NULL bytes
∙ XOR A is redundant
・ A’ = KEYSTREAM
 ENCRYPT(B) = B’
 B’ XOR KEYSTREAM = B
How can we test
for a flawed
AES-CTR
implementation?

32. Let’s see if this holds true…

33. 33

34. 34
TorrentLocker  AES
 Counter (CTR) mode
 Static key
 Static IV / nonce
 2 MB file size limit
 No padding
• Need to consider byte alignment and
determine block size to cover edge cases

35. Apocalypse

37.  After viewing ciphertexts spanning multiple file types, a magic byte sequence
reveals itself
• 77 2A 3C D0

38.  After encrypting a chosen plaintext
containing solely null bytes
• Appears to be some repetition

39. 39
Apocalypse  Magic byte sequence
 Repetition in ciphertext
• Produced from NULL byte plaintext
 Ransom note doesn’t mention encryption type
 Let’s proceed with reverse engineering…

40.  Text search in IDA Pro for XOR operations
• Most XORs just clearing out registers, but two stick out in sub_40108
• Good place to start, but it’s not always this easy

41.  The two XORs of interest are looped over
 Appears that the previously identified magic byte
sequence is written by the first WriteFile call
 Second WriteFile writes out the transformed buffer
containing the presumably encrypted data

44. Let’s test out the script…

45. 45

46. 46
Research in
the Field
 Tracking and reverse engineering new variants
 Developing and releasing decrypters for free
 BleepingComputer forums
• BloodDolly
 @malwarehunterteam
• http://id-ransomware.malwarehunterteam.com
 @malwaretech
• WannaCry killswitch
• https://www.malwaretech.com
 @demonslay335
 … and many others!
Despite
proliferation,
researchers have
kept pace

47. 47
Conclusion  Crypto implementation issues prevalent
• “Crypto is hard”
 Ransom notes are not trustworthy for technical
specs
• Don’t believe the hype
 RE and cryptanalysis / decrypter dev are not
linear processes
• Known / chosen plaintext attacks
• Trial and error
• Focus on sections where modifications
occur, then dig deeper for more clues
• Build out POC, then stress test and harden
as needed to cover all edge cases

48. Thanks!
Twitter - @magerbomb
E-mail - mager@endgame.com