$30 off During Our Annual Pro Sale. View Details »

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

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. Building a Malwarstein
    adapting and repurposing malware
    hasherezade

    View Slide

  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

    View Slide

  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!

    View Slide

  4. Repurposing malware – who, why, how?

    View Slide

  5. Who, why, how?
    •Script kiddies
    •Commodity malware authors
    •Nation state/politically motivated actors
    •Researchers

    View Slide

  6. Who, why, how?
    • Script kiddies
    Why?
    to prepare an attack without having a deep technical knowledge

    View Slide

  7. Who, who, how?
    • Using leaked/published sources (i.e. Hidden Tear, Mirai)

    View Slide

  8. Who, who, how?
    • Decompiling .NET malware...

    View Slide

  9. Who, why, how?
    • Stolen DMA Locker
    https://blog.malwarebytes.com/cybercrime/malware/2017/05/stolen-version-dma-locker-making-rounds/)

    View Slide

  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...

    View Slide

  11. Who, why, how?
    • Commodity malware authors (middle class)
    • to save time and resources dedicated to the development
    I am almost
    like Slavik

    View Slide

  12. Who, why, how?
    • Using leaked/published sources (i.e. ZeuS based malware, malware
    incorporating leaked NSA exploits/modules)

    View Slide

  13. Who, why, how?
    • Rewriting fragments of known malware using reverse engineering...

    View Slide

  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

    View Slide

  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.

    View Slide

  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

    View Slide

  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/

    View Slide

  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/

    View Slide

  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

    View Slide

  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

    View Slide

  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...

    View Slide

  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

    View Slide

  23. Petya.A/NotPetya – probably the most
    famous Malwarestein in wild

    View Slide

  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

    View Slide

  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

    View Slide

  26. Petya.A/NotPetya
    • Reverse-engineered and rewritten high-level Petya components

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  30. Petya.A/NotPetya
    • Yes, it works!
    Repurposing Petya to become a real wiper can be SUPER EASY, providing that you understood the code

    View Slide

  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

    View Slide

  32. LibPeConv – how it works

    View Slide

  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

    View Slide

  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

    View Slide

  35. libPeConv – how it works
    • Custom loading of PE files
    The imports of the
    loaded executable
    can be resolved by
    your own resolver

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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

    View Slide

  41. DEMO:
    Let me introduce my Malwarestein

    View Slide

  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.

    View Slide

  43. Thank you!

    View Slide