WarCon 2018 - Building a Malwarestein. Adapting and repurposing existing malware into new projects

Presented at WarCon 2018 - http://warcon.pl/2018/

Transcript

1. Building a Malwarstein adapting and repurposing malware hasherezade
2. About me • I am Hasherezade from twitter ;) • Programmer & malware analyst • Write technical articles about malware, crackmes etc • Author of some tools for malware analysis, i.e. PE-bear, PE-sieve, libPeConv • Contractor for Malwarebytes, but today I present my personal research • More: http://hasherezade.net
3. Agenda 1. Who and why repurpose existing malware? 2. A brief case study: Petya.A/Not Petya – probably the most famous Malwarestein in wild 3. Wrapping and modifying executables using libPeConv 4. Demo: meet my little Malwarestein... Happy Birthday, Petya/NotPetya!
4. Repurposing malware – who, why, how?
5. Who, why, how? •Script kiddies •Commodity malware authors •Nation state/politically motivated actors •Researchers
6. Who, why, how? • Script kiddies Why? to prepare an attack without having a deep technical knowledge
7. Who, who, how? • Using leaked/published sources (i.e. Hidden Tear, Mirai)
8. Who, who, how? • Decompiling .NET malware...
9. Who, why, how? • Stolen DMA Locker https://blog.malwarebytes.com/cybercrime/malware/2017/05/stolen-version-dma-locker-making-rounds/)
10. Who, why, how? • Script kiddies • Modifications are usually small • Sometimes they are chaotic and corrupting the malware functionality • Tend to use high-level languages: .NET, Python...
11. Who, why, how? • Commodity malware authors (middle class) • to save time and resources dedicated to the development I am almost like Slavik
12. Who, why, how? • Using leaked/published sources (i.e. ZeuS based malware, malware incorporating leaked NSA exploits/modules)
13. Who, why, how? • Rewriting fragments of known malware using reverse engineering...
14. Who, why, how? • Using more sophisticated patching (i.e. PetrWrap) From „ PetrWrap: the new Petya-based ransomware used in targeted attacks” https:// securelist.com/petrwrap-the- new-petya-based-ransomware- used-in-targeted- attacks/77762
15. Who, why, how? • Commodity malware authors (middle class) • Modifications display good technical knowledge of their author. • Patches are made in the way that serves exactly the purpose, showing that the author did reverse engineering on the sample and understood it.
16. Who, why, how? • Sophisticated actors(including possibly nation-state linked) • Also: to save time and resources dedicated on development See the talk: „Cyberwar on a Shoestring: How Kim Jong Un Stole My Malware” by Kenneth Geers
17. Who, why, how? • Sophiasticated actors (including possibly nation-state linked) • To make attribution more difficult From „The devil is in Rich Headers” https://securelist.com /the-devils-in-the- rich-header/84348/
18. Who, why, how? • Beware of the Red Herrings! From „The devil is in Rich Headers” https://securelist.com /the-devils-in-the- rich-header/84348/
19. Who, why, how? • Sophiasticated actors (including possibly nation-state linked) • Used methods: • Same as in commodity malware: using sources, rewriting by reverse engineering, sophiasticated patching • Malware may incorporate legitimate applications, repurposed for malicious reasons • Elements of other, known malware can be used as red herring
20. Who, why, how? • Researchers (me ;) ) • To join and monitor botnets, to decrypt ransomware, test tools, to learn techniques, to build crackmes... https://github. com/a0rtega/ pafish
21. Who, why, how? • Researchers (me ;) ) Rather than writing a full decryptor from the scratch, I repurposed DMA locker to work in a decryption mode...
22. Who, why, how? • Used methods: • Reverse engineering samples and reimplementing techniques • Patching and hooking malware i.e. to intercept its communication with the CnC • ...and I have my own library, that allows me to wrap malware binaries, export functions of my choice and use them as my library https://www.youtube.com /watch?v=KMcSAlS9zGE https://www.youtub e.com/watch?v=yV4 jiidyFXw
23. Petya.A/NotPetya – probably the most famous Malwarestein in wild
24. Petya.A/NotPetya • Used elements • Petya (Goldeneye version) • NSA exploits • Mimikatz • Used methods • Binary patching • Reverse engineering the original code of Petya dropper and coping its functionality
25. Petya.A/NotPetya • Patches made in the Petya low-level component Removed the screen with Petya Skull Patches were cosmetic: changed strings, colors... Not the functionality
26. Petya.A/NotPetya • Reverse-engineered and rewritten high-level Petya components
27. Petya.A/NotPetya • Experiment – was it difficult to make it a better wiper? • Lines responsible for xoring the input with the keystream: https://github.com/alexwebr/salsa20/blob/master/salsa20.c
28. Petya.A/NotPetya • Experiment – was it difficult to make it a better wiper? • What if instead of xoring it with keystream, we just overwrite it with a keystream? • Minimal patch: just one byte 88 01 -> MOV [BX+DI], AL
29. Petya.A/NotPetya • Experiment – was it difficult to make it a better wiper? • To make the changes more visible, we can overwrite it with a defined character i.e. # B0 23 -> MOV AL, # 88 01 -> MOV [BX+DI], AL
30. Petya.A/NotPetya • Yes, it works! Repurposing Petya to become a real wiper can be SUPER EASY, providing that you understood the code
31. Patching – lessons learned • Patching always requires a good understanding of the binary! • It is easy to destroy something, hard to keep track on changes and undo them • It is a simple and powerful technique, but it has its limitations: the size of the patch much be possibly small to fit in the space • Workarounds? • Injecting a DLL into a process, hooking and redirecting functions... • What if we want something simpler? And allowing for persistent changes? • Thinking of it I created my own library, libPeConv
32. LibPeConv – how it works
33. libPeConv – how it works • A static library for custom loading of PE files • Features: • load a PE file from a buffer without dropping it on the disk. • export any function from the PE file, providing that you know its offset and API (HexRays decompiler is your friend) • Easily hook IAT of the loaded PE files • Replace selected functions in the loaded PE file by your custom functions
34. libPeConv – how it works • Custom loading of PE files #include "peconv.h" https://github.com/has herezade/libpeconv Load any PE file from the buffer (without dropping it on the disk
35. libPeConv – how it works • Custom loading of PE files The imports of the loaded executable can be resolved by your own resolver
36. libPeConv – how it works • Export any function from a malware of your interest – you only need to know the API and RVA 1. Find the function of your interest and its offset 2. Reconstruct the API 3. Load the EXE with libPeConv and export the function 4. Use it like your local function
37. libPeConv – how it works • Custom import resolvers allow you to hook IAT in a very easy way Whenever the „Sleep” is called by the loaded malware, the function „my_Sleep” in the loader is executed instead
38. libPeConv – how it works • Not only imports: we can redirect any local function from the malware to our local function More: https://goo.gl/VCLMn1
39. libPeConv – how it works • We can also hook a one, chosen call to a particular function... This time, not the function but the address of particular call was replaced The original function „BlueScreen” is untouched and can be called elsewhere.
40. libPeConv – how it works • Tutorials: • https://hshrzd.wordpress.com/tag/libpeconv • Examples: • https://github.com/hasherezade/libpeconv/tree/master/tests • Helpers: • https://github.com/hasherezade/libpeconv_wrappers • https://github.com/hasherezade/libpeconv_project_template • A compiled (harmless) demo (open source): • https://goo.gl/3YzTjJ
41. DEMO: Let me introduce my Malwarestein
42. DEMO https://youtu.be/zSqwu2y2hSY DISCLAIMER: This is a Proof-Of-Concept project, created for demonstration purpose only. It will never be released and used outside the lab.
43. Thank you!