Upgrade to Pro — share decks privately, control downloads, hide ads and more …

WarCon 2018 - Building a Malwarestein. Adapting...

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

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

hasherezade

June 02, 2018
Tweet

More Decks by hasherezade

Other Decks in Research

Transcript

  1. 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
  2. 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!
  3. Who, why, how? • Script kiddies Why? to prepare an

    attack without having a deep technical knowledge
  4. 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...
  5. Who, why, how? • Commodity malware authors (middle class) •

    to save time and resources dedicated to the development I am almost like Slavik
  6. Who, why, how? • Using leaked/published sources (i.e. ZeuS based

    malware, malware incorporating leaked NSA exploits/modules)
  7. 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
  8. 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.
  9. 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
  10. 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/
  11. 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/
  12. 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
  13. 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
  14. Who, why, how? • Researchers (me ;) ) Rather than

    writing a full decryptor from the scratch, I repurposed DMA locker to work in a decryption mode...
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. Petya.A/NotPetya • Yes, it works! Repurposing Petya to become a

    real wiper can be SUPER EASY, providing that you understood the code
  22. 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
  23. 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
  24. 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
  25. libPeConv – how it works • Custom loading of PE

    files The imports of the loaded executable can be resolved by your own resolver
  26. 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
  27. 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
  28. 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
  29. 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.
  30. 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
  31. 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.