Extracting Forensic Information From Zeus Derivatives
•Download as PPTX, PDF•
1 like•3,430 views
Extracting Forensic Information from Zeus Derivatives James Wyke, Sophos
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (10)
Similar to Extracting Forensic Information From Zeus Derivatives
Similar to Extracting Forensic Information From Zeus Derivatives (20)
More from Source Conference
More from Source Conference (20)
Recently uploaded
Recently uploaded (20)
Extracting Forensic Information From Zeus Derivatives
- 1. 1 James Wyke Senior Threat Researcher Extracting Forensic Information from Zeus Derivatives SOURCE Dublin 2014
- 2. 22 Agenda
- 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
- 7. 77 What information do we want to extract?
- 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
- 10. 1010 How do we extract the information?
- 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
- 23. 23 Zeus 2.0.8.9 • Find block in dump: • Often appended to file 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
- 26. 26 IceIX • RC4 changes • Config file retrieval requires structured POST request Modifications
- 27. 27 IceIX • Classic: • Modified: RC4 changes
- 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
- 32. 32 • Extra non-standard permutation • Need to extract salt value • All network traffic encrypted in this way Citadel Config file retrieval
- 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 Citadel • Switch case based on DWORD value: POST data custom permutation
- 35. 35 Citadel • Python: POST data custom permutation
- 36. 36 Citadel Config file decryption • RC4 key from StaticConfig • login_key • 128-bit config XOR key
- 37. 37 Citadel • Found in the AES routine: Extra config key
- 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 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
- 41. 41 KINS/VMZeus • Find the entry to the VM handler: Identification
- 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. 4343 Automation
- 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. 4545 Conclusion
- 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© Sophos Ltd. All rights reserved.
Editor's Notes
- Typical weekly breakdown of Zeus variants seen by SophosLabs.
- Ref: http://nakedsecurity.sophos.com/2012/12/05/the-citadel-crimeware-kit-under-the-microscope/