1
James Wyke
Senior Threat Researcher
Extracting Forensic
Information from Zeus
Derivatives
SOURCE Dublin 2014
22
Agenda
3
Agenda
• Zeus and derivatives overview
• What information do we want to extract and why?
• How do we extract the informa...
44
Zeus and Derivatives
5
Zeus and Derivatives
• Highly successful kit
• Source code leaked 2011
• New variants – Citadel, IceIX, KINS, Gameover +...
6
Zeus and Derivatives
• Variant prevalence:
Citadel
19%
Ice9
8%
P2P
31%
2.0.8.9 Based
17%
KINS
12%
Other
13%
Typical Week...
77
What information do
we want to extract?
8
High Level Goals
• What was stolen?
○ Network traffic
○ Cache data
• Where was data sent?
○ Drop zone URLs
○ Config file...
9
How to Achieve These Goals?
• C2 addresses
○ Extract from binary, config file, network traffic captures
• Stolen data
○ ...
1010
How do we extract
the information?
11
Key Variants
• Leaked Zeus (2.0.8.9)
○ Original codebase
○ Same process will work for many minor variations
• IceIX
○ E...
12
Zeus 2.0.8.9
• Config file URL
• Retrieve, decrypt, decipher config file
• Assess stolen data – decrypt network traffic...
13
Zeus 2.0.8.9
• Static config details embedded in binary
• Config block XOR encrypted
• Find block offset and XOR key
Co...
14
Zeus 2.0.8.9
Config URL
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 al...
16
Zeus 2.0.8.9
• Retrieved with simple Get request to URL
• RC4 decrypt
○ Using key from StaticConfig (no key scheduling ...
17
Zeus 2.0.8.9
• Common to many subsequent variants
• Config header structure:
Config file structure
Offset Size Value
0x...
18
Zeus 2.0.8.9
• Config blocks – header then data
• Config block header structure:
Config file structure
Offset Size Valu...
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
...
20
Zeus 2.0.8.9
• Network data
○ RC4 decrypt using key from StaticConfig
○ Data is structured similar to config data
• Cac...
21
Zeus 2.0.8.9
• XOR key stored in runtime data at offset 0x1e2
• Blocks encrypted with VisualEncrypt + RC4
• New RC4 key...
22
Zeus 2.0.8.9
• Dynamically created block written by dropper
• See
https://code.google.com/p/volatility/source/browse/tr...
23
Zeus 2.0.8.9
• Find block in dump:
• Often appended to file
Runtime information
24
IceIX
• Same goals
○ Config file URL
○ Retrieve, decrypt, decipher config file
○ Assess stolen data – decrypt network t...
25
IceIX
• Config file URL by default ends with config.php
• Strings: “bn=1” and “&sk=1”
• Modified RC4 routine:
Identific...
26
IceIX
• RC4 changes
• Config file retrieval requires structured POST request
Modifications
27
IceIX
• Classic:
• Modified:
RC4 changes
28
IceIX
• POST request requires special format or config file is not
delivered
• POST data format:
bn=<BOTID string>&sk=<...
29
Citadel
• Giveaway string:
○ 'Coded by BRIAN KREBS for personal use only. I love my job & wife.‘
• Version number:
• Ma...
30
Citadel
• Encryption process rewritten – AES + RC4, multiple keys
• Formatted POST request for config file retrieval
• ...
31
Citadel
• RC4 has XOR on top with LOGIN_KEY
○ Extra key generated at build time e.g.:
○ "C1F20D2340B519056A7D89B7DF4B0F...
32
• Extra non-standard
permutation
• Need to extract salt
value
• All network traffic
encrypted in this way
Citadel
Confi...
33
Citadel
• Formatted similar to config data – header with 2 data blocks
• Block ID 0x2725 – contains the login_key
• Blo...
34
Citadel
• Switch case based on DWORD value:
POST data custom permutation
35
Citadel
• Python:
POST data custom permutation
36
Citadel
Config file decryption
• RC4 key from StaticConfig
• login_key
• 128-bit config XOR key
37
Citadel
• Found in the AES routine:
Extra config key
38
Gameover/P2P
• Command strings used in the P2P protocol:
○ OPTIONS
○ PROPFIND
○ PROPPATCH
○ SEARCH
○ UNLOCK
○ REPORT
○ ...
39
Gameover/P2P
• Static peer list
○ Each peer has its own RC4 key
• Connect to P2P network to retrieve config
• Zlib comp...
40
KINS/VMZeus
• VM based StaticConfig decryption
• Embedded byte code determines which VM handler is
executed on which by...
41
KINS/VMZeus
• Find the entry to the VM handler:
Identification
42
KINS
• RC4 key is in the StaticConfig but now much harder to decrypt
• Need to replicate the handler sequence by runnin...
4343
Automation
44
Automation
• As part of sandbox analysis – e.g. cuckoo
○ Process dump
○ Key extraction and data decryption as part of a...
4545
Conclusion
46
Conclusion
• Many successful and widespread variants spawned from Zeus
code
• More builders and source code leaked, man...
47© Sophos Ltd. All rights reserved.
Upcoming SlideShare
Loading in...5
×

Extracting Forensic Information From Zeus Derivatives

1,073

Published on

Extracting Forensic Information from Zeus Derivatives
James Wyke, Sophos

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,073
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
26
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Typical weekly breakdown of Zeus variants seen by SophosLabs.
  • Ref: http://nakedsecurity.sophos.com/2012/12/05/the-citadel-crimeware-kit-under-the-microscope/
  • Extracting Forensic Information From Zeus Derivatives

    1. 1. 1 James Wyke Senior Threat Researcher Extracting Forensic Information from Zeus Derivatives SOURCE Dublin 2014
    2. 2. 22 Agenda
    3. 3. 3 Agenda • Zeus and derivatives overview • What information do we want to extract and why? • How do we extract the information? • Automation • Conclusion
    4. 4. 44 Zeus and Derivatives
    5. 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. 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
    7. 7. 77 What information do we want to extract?
    8. 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. 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
    10. 10. 1010 How do we extract the information?
    11. 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. 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. 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
    14. 14. 14 Zeus 2.0.8.9 Config URL
    15. 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. 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. 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. 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. 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. 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. 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. 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
    23. 23. 23 Zeus 2.0.8.9 • Find block in dump: • Often appended to file Runtime information
    24. 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. 25 IceIX • Config file URL by default ends with config.php • Strings: “bn=1” and “&sk=1” • Modified RC4 routine: Identification
    26. 26. 26 IceIX • RC4 changes • Config file retrieval requires structured POST request Modifications
    27. 27. 27 IceIX • Classic: • Modified: RC4 changes
    28. 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. 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. 30 Citadel • Encryption process rewritten – AES + RC4, multiple keys • Formatted POST request for config file retrieval • Backup config file URLs Modifications
    31. 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
    32. 32. 32 • Extra non-standard permutation • Need to extract salt value • All network traffic encrypted in this way Citadel Config file retrieval
    33. 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
    34. 34. 34 Citadel • Switch case based on DWORD value: POST data custom permutation
    35. 35. 35 Citadel • Python: POST data custom permutation
    36. 36. 36 Citadel Config file decryption • RC4 key from StaticConfig • login_key • 128-bit config XOR key
    37. 37. 37 Citadel • Found in the AES routine: Extra config key
    38. 38. 38 Gameover/P2P • Command strings used in the P2P protocol: ○ OPTIONS ○ PROPFIND ○ PROPPATCH ○ SEARCH ○ UNLOCK ○ REPORT ○ MKACTIVITY ○ CHECKOUT ○ M-SEARCH ○ NOTIFY ○ SUBSCRIBE ○ UNSUBSCRIBE Identification
    39. 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. 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
    41. 41. 41 KINS/VMZeus • Find the entry to the VM handler: Identification
    42. 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
    43. 43. 4343 Automation
    44. 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
    45. 45. 4545 Conclusion
    46. 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
    47. 47. 47© Sophos Ltd. All rights reserved.
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×