/w32miller

malware development kit for x86 windows based platforms with a linux compatible build system

Primary LanguageCOtherNOASSERTION

Gitlab-CI

abstract

The project emerged during my studies.
It is a showcase demonstration which covers DLL injection and a (very basic) command&control infrastructure.
However, as I never had the time to finished it (and presumably lost focus), it is still premature. So please see this project as a unstable-as-fuck-example and not as a copy-pasta-ready development framework.
As this project was written by an unexperienced and fault-tolerant student, the code looks ugly w/ limited readability, missing documentation and may crash at any time.

w32miller

An educational malware development kit or my preferable abbreviation: mdk.
Only x86 architectures are supported at the moment. Most of the code is written in C, porting it to other architectures isn't wizardry.
The more complex parts are the assembler sources, which are tied to x86. Porting the loader to x64 may cause some headaches.
It's name was derived from Chaim Miller, the real Inglourious Basterd.
Why did I choose that name you may ask. Long story - to make it short: I love his attitude!
Used languages: Bash, CMake, ASM-x86, C, Go, Python

build

As my favourite platforms are (Arch|Debian) based, the whole config&build process was designed to work on those platforms.
Other build environments may not produce the desired results.
The following commands should only be run once.

Pre-Requirements (debian)

sudo apt-get install g++ gcc autoconf automake flex bison texinfo cmake
See INSTALL for more information.

Build miller toolchain

./deps/makedeps.sh N (where N is the number of simultaneous build jobs, default: 1)
It will download/extract/compile basic developer tools (python-2.7.18, nasm-2.12.02, binutils-2.31.1, gcc-8.2.0, mingw-w64-v6.0.0)
The Toolchain build is necessary, because we will probably use a patched gcc in the future.
This project may neither compile nor work with other toolchain combinations!

Configure project

cd /path/to/project
mkdir build && cd build
cmake -DBUILD_ALL_TOOLS=ON -DBUILD_CNCPROXY=ON -DBUILD_TESTS=ON -DEXTRA_VERBOSE=ON -DHTTP_LOCALHOST=ON -DINFECT_DUMMY=ON ..

Build project

make -jN (where N is the number of simultaneous build jobs)

To install all generated binaries use: make install DESTDIR=[PATH]

Try it!

There are a several ways to tryout this project.
If you want a basic CNC communication you should start the cncproxy first with: [BUILD_DIR]/host-tools/cncproxy-host

  1. cd [BUILD_DIR]/bin
  2. wine loader_base.exe (PART encrypted binary)
  3. OR wine loader_base_enc.exe (FULL encrypted binary)
  4. run wine dummy.exe 120 which should now be infected and try to contact the CNC service

Other intresting executables:

  • wine runbin.exe libw32miller_pre-shared.dll
  • wine runbin.exe libw32miller-shared.dll
  • wine runbin.exe bin/w32miller_pre.bin
  • wine runbin.exe bin/w32miller.bin

Test Windows Portable Executable compliance:

  • wine loadmodule.exe bin/libw32miller_pre-shared.dll
  • wine loadmodule.exe bin/libw32miller-shared.dll

UNIT tests:

  • wine tests.exe

Or use a virtual machine and run it there. (e.g. VirtualBox)

This is an educational mdk only: It tries to infect one windows pe binary named dummy.exe in your current working directory.

It is recommended using a VM like virtualbox. If you do not care about the integrity of your host OS, wine may work as well.

features

  • mingw64 toolchain (and build script)
  • minimal x86/x64 disassembler/patcher
  • pe code/data injector
  • command&control communication
  • golang based c&c service

how it works

DLL (infect):

  1. DLL adds loader section to target (default: .minit)
  2. DLL adds own section to target (default: .miller)
  3. DLL sets const data in loader
  4. DLL copies the loader to its section
  5. DLL copies itself to its very own section
  6. DLL injects FAR JUMP somewhere near the EntryPoint RVA and set the operand to the loader VA

An infected file:
  1. somewhere near the Address of EntryPoint RVA it calls the loader entry address

LOADER:
  1. decrypt strings
  2. get some function pointers/data
  3. copy encrypted DLL section to temporary allocated buffer
  4. decrypt DLL if encrypted and read PE header
  5. allocate memory for image sections
  6. copy sections from (parsed/plain PE file) temp buffer to final destinations
  7. do fixups if image relocation is necessary
  8. jump to the CRT

CRT (part of DLL):
  1. does minimal initializing
  2. check if started by loader (and set data/register as needed)
  3. setup function parameter
  4. call real dll entry function _main(...)
  5. start some threads e.g. infection/network thread
  6. cleanup stack
  7. return to the loader

LOADER:
  1. cleanup and jump back right after where we were injected

Command'n'Control (CNC)

The Go written CNC proxy which acts as man-in-the-middle between an infected binary and CNC master.
CNC proxy does the basic authentication and receives commands from the CNC master.
Keep in mind that this part of the project is the most ALPHA'ic one.
So the cncmaster does not do anything useful at the moment.
For a very basic test, the cncproxy is sufficient.

Documentation (missing)

App Injection Workflow