Cryptanalysis in the Time of Ransomware

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

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
Agenda  Ransomware Execution Flow
 Cryptanalysis Workflow
 Walkthroughs
• Powerware
• Nemucod
• TorrentLocker
• Apocalypse
 Research in the Field
 Conclusion
 Questions

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
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
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

Cryptanalysis in the Time of Ransomware

Enumeration
Crypto setup
File
write
File Cleanup

10
Let’s deobfuscate this a little bit…

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

 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
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

Let’s build our own decrypter!

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

Decompiled view of ctr_encrypt

Decompiled view of aes_encrypt

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
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?

Let’s see if this holds true…

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

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

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

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…

 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

 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

Let’s test out the script…

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
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

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

Cryptanalysis in the Time of Ransomware

More Related Content

What's hot (20)

Similar to Cryptanalysis in the Time of Ransomware (20)

Recently uploaded (20)

Cryptanalysis in the Time of Ransomware