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
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!
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...
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
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.
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
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/
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
hshrzd
fullflu
yumulab
kitachan_black
seiichiinoue
arumakan
yellowshippo
gpeyre
kuribayashi4
hpprc
jnunemaker
dougneiner
holman
brad_frost
bluesmoon
sonatard
chrislema
morganepeng
mthomps
michaelherold
maltzj
samanthasiow