3. 3
Agenda
• Zeus and derivatives overview
• What information do we want to extract and why?
• How do we extract the information?
• Automation
• Conclusion
5. 5
Zeus and Derivatives
• Highly successful kit
• Source code leaked 2011
• New variants – Citadel, IceIX, KINS, Gameover + many more
• Leaked code also widely used with few or no modifications
• Many variants successful in their own right
• More builders leaked
6. 6
Zeus and Derivatives
• Variant prevalence:
Citadel
19%
Ice9
8%
P2P
31%
2.0.8.9 Based
17%
KINS
12%
Other
13%
Typical Weekly Breakdown
Citadel
Ice9
P2P
2.0.8.9 Based
KINS
Other
8. 8
High Level Goals
• What was stolen?
○ Network traffic
○ Cache data
• Where was data sent?
○ Drop zone URLs
○ Config file URLs
○ Backup URLs
• What changes were made?
○ Commands executed
○ Web injects – config data
• Who were the attackers?
○ Tracking
9. 9
How to Achieve These Goals?
• C2 addresses
○ Extract from binary, config file, network traffic captures
• Stolen data
○ Decrypt network data, cache files
• Configuration files
○ Obtain, decrypt, decipher config data
○ Webinjects, filters, targeted processes
• Runtime information
○ Exe path, registry keys etc
• Store and track data
○ Keys, URLs, customisations
11. 11
Key Variants
• Leaked Zeus (2.0.8.9)
○ Original codebase
○ Same process will work for many minor variations
• IceIX
○ Encryption algorithm changes
○ Config file retrieval complications
• Citadel (1.3.5.1)
○ Encryption heavily rewritten
○ More config file retrieval changes
• Gameover
○ Peer 2 peer
• KINS
○ VM based decryption routine
12. 12
Zeus 2.0.8.9
• Config file URL
• Retrieve, decrypt, decipher config file
• Assess stolen data – decrypt network traffic, cache file
• Read runtime information
13. 13
Zeus 2.0.8.9
• Static config details embedded in binary
• Config block XOR encrypted
• Find block offset and XOR key
Config file URL
15. 15
Zeus 2.0.8.9
• Regexp search, e.g:
○ "[x50-x57][xb8-xbf].{2}x00x00[x50-x57]x68.{4}[x50-
x57]xe8.{4}x8b.{5}x03“
• Key always at start of ‘.reloc’ section
• Key length = size of StaticConfig
• StaticConfig also contains RC4 key
Config URL
16. 16
Zeus 2.0.8.9
• Retrieved with simple Get request to URL
• RC4 decrypt
○ Using key from StaticConfig (no key scheduling stage)
• VisualDecrypt
○ for (m = (Size-1); m >0; m--)
○ Data[m] = Data[m] ^ Data[m-1]
• Decompress compressed blocks
○ nrv2b
• Covert to something more readable
○ XML is an option
Config File
17. 17
Zeus 2.0.8.9
• Common to many subsequent variants
• Config header structure:
Config file structure
Offset Size Value
0x0 0x14 Random data
0x14 0x4 Size of config file
0x18 0x4 Flags (usually 0)
0x1c 0x4
Number of
Blocks
0x20 0x10 MD5 of data
0x30 … Config blocks
18. 18
Zeus 2.0.8.9
• Config blocks – header then data
• Config block header structure:
Config file structure
Offset Size Value
0x0 0x4 Block ID
0x4 0x4
Flags, e.g.
compressed
0x8 0x4
Compressed
size
0xc 0x4
Decompressed
size
19. 19
Zeus 2.0.8.9
• Block ID identifies specific type of config entry e.g. version,
new exe url, drop zone url, web injects
• Leaked source indicates what each binary value means
• Conversion to XML makes the data easier to interpret:
Config file structure
20. 20
Zeus 2.0.8.9
• Network data
○ RC4 decrypt using key from StaticConfig
○ Data is structured similar to config data
• Cache data
○ Temporary store of data before sending back to drop zone
○ Structure:
Stolen data
Offset Size Value
0x0 0x4
Xor encoded
size of block
0x4 0x1 0
0x5 ??
First encrypted
block
21. 21
Zeus 2.0.8.9
• XOR key stored in runtime data at offset 0x1e2
• Blocks encrypted with VisualEncrypt + RC4
• New RC4 key from runtime data
• Blocks have same structure as network data
• Cache gets deleted when data sent over network
Cache data
22. 22
Zeus 2.0.8.9
• Dynamically created block written by dropper
• See
https://code.google.com/p/volatility/source/browse/trunk/con
trib/plugins/malware/zeusscan.py for structure
• Key fields:
○ RC4 key – encrypting cache data
○ XORkey – cache data block sizes
• Also, registry keys, exe file name, cache file name etc.
Runtime information
24. 24
IceIX
• Same goals
○ Config file URL
○ Retrieve, decrypt, decipher config file
○ Assess stolen data – decrypt network traffic, cache file
○ Read runtime information
• How do we identify?
• What are the differences?
25. 25
IceIX
• Config file URL by default ends with config.php
• Strings: “bn=1” and “&sk=1”
• Modified RC4 routine:
Identification
28. 28
IceIX
• POST request requires special format or config file is not
delivered
• POST data format:
bn=<BOTID string>&sk=<MD5 of encrypted BOTID string>
• BOTID generated per machine, e.g.: MYPC_737574566769_474
• Encrypted using modified RC4 with key from StaticConfig
• All POST data encrypted before being sent
Config file retrieval
29. 29
Citadel
• Giveaway string:
○ 'Coded by BRIAN KREBS for personal use only. I love my job & wife.‘
• Version number:
• Maybe further strings:
○ cit_ffcookie.module, cit_video.module
Identification
30. 30
Citadel
• Encryption process rewritten – AES + RC4, multiple keys
• Formatted POST request for config file retrieval
• Backup config file URLs
Modifications
31. 31
Citadel
• RC4 has XOR on top with LOGIN_KEY
○ Extra key generated at build time e.g.:
○ "C1F20D2340B519056A7D89B7DF4B0FFF"
• Config data encrypted with AES
• Network traffic requires generating a new RC4 key
Encryption process
33. 33
Citadel
• Formatted similar to config data – header with 2 data blocks
• Block ID 0x2725 – contains the login_key
• Block ID 0x2726 – file name from config URL:
○ http://pubber.ru/images/greater/wisdom/file.php|file=config.dll
○ Everything after the ‘|’ goes in the block data
POST data
39. 39
Gameover/P2P
• Static peer list
○ Each peer has its own RC4 key
• Connect to P2P network to retrieve config
• Zlib compression
• https://github.com/arbor/zeus_gameover-re
Modifications
40. 40
KINS/VMZeus
• VM based StaticConfig decryption
• Embedded byte code determines which VM handler is
executed on which byte of ciphertext
• Embedded opcode handler table
• Each element of bytecode is an index into the handler table
Modifications
42. 42
KINS
• RC4 key is in the StaticConfig but now much harder to decrypt
• Need to replicate the handler sequence by running the
bytecode through the handler table
• Leaked KINS source: source/common/configcrypt.cpp
• But handler table order is shuffled by the builder so we must
work out the correct order dynamically for each sample
Key extraction
44. 44
Automation
• As part of sandbox analysis – e.g. cuckoo
○ Process dump
○ Key extraction and data decryption as part of a processing module
○ Analyzer module to perform the retrieval for non-executing samples
• Volatility
○ Key and data extraction from a memory dump
○ https://code.google.com/p/volatility/source/browse/trunk/contrib/plugin
s/malware/zeusscan.py
46. 46
Conclusion
• Many successful and widespread variants spawned from Zeus
code
• More builders and source code leaked, many variants still
being actively developed
• Despite some significant modifications, new variants are
incremental
• Tools can be updated relatively easy for modifications