Patching Windows Executables with the Backdoor Factory | DerbyCon 2013
Upcoming SlideShare
Loading in...5

Patching Windows Executables with the Backdoor Factory | DerbyCon 2013



Slides from my DerbyCon 2013 talk.

Slides from my DerbyCon 2013 talk.



Total Views
Slideshare-icon Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Changes: Entry location and the code at entry.
  • First stub:Allocates memoryCopies 2ndshellcode into memoryCreates and launches it a separate thread
  • From hopper disassembler for mac The outer blue lines show jumps to greater memory addresses The red line show jumps to lesser memory addresses
  • On Mac test on win7
  • On Mac
  • On mac, test on win7
  • On win 8.1 with MSSE binary
  • On Mac
  • X64 shellcode is the way to go.

Patching Windows Executables with the Backdoor Factory | DerbyCon 2013 Patching Windows Executables with the Backdoor Factory | DerbyCon 2013 Presentation Transcript

  • Patching Windows Executables with the Backdoor Factory Joshua Pitts DerbyCon 2013
  • Other Potential Titles • I’M DOWN WITH APT (yeah you know me) • Lassie, did Timmy fall in a Code Cave again?? • Why I Cyber and How You Can Cyber too • When ET met EMET (A Love Story) • Hugging Your Way to the Top, One Hug at a Time • How I Owned Your Mother
  • About Me • US Marine, Pre-911: SIGINT • Past: IT and Physical Security Auditor, Operational Security Lead, Malware and Forensic Analyst • Current: Reverse Engineer, Pentester • Python, C/C++, ASM (INTEL) • I have certs.. Serious inquires only :P • Currently work at Leviathan Security Group
  • Urban Dictionary
  • Overview • History of Patching • How I learned to patch binaries • The Backdoor Factory – Features – Capabilities • Demos (Live and Video) • Mitigations • Going forward
  • What is Patching Definition (Wikipedia): A patch is a piece of software designed to fix problems with, or update a computer program or its supporting data. This includes fixing security vulnerabilities and other bugs, and improving the usability or performance.
  • For This Presentation My Definition: Adding or taking away content or functionality to a compiled binary.
  • Security Pros and Patching • Red Teaming – persistence in plain sight • Pentesting/Social Engineering – Salt all the parking lots! • Research – Just because :D • Malware/Code analysis – Break the anti-analysis code
  • History of Patching Good thing we don’t do this with operating systems.
  • The MS Method • MSP – Windows install patch file. • Contains at least two data transforms – One updates the install database – One has info that the installer uses for ‘patching files’ • The installer will then use this info to apply the patch from the cabinet file • Yada Yada Yada…
  • What does this mean? MS definition of patching is replacing old registry entries, dlls, and exes with new items Not the patching that we’re taking about today
  • How Key Gens/Crackers do it • Find code branch(es) that validate(s) the software’s protection mechanism(s) • Make it return to a value that meets a valid condition for approved/continued operation • Sometimes its a function that returns a True/False (0/1) value after the check.
  • How Metasploit Patches • msfvenom –p windows/shell_reverse_tcp –x psexec.exe … The overwrite program entry method • msfvenom –p windows/shell_reverse_tcp –x psexec.exe –k … The allocate and create thread and return to original program entry method (Keep)
  • MSF Overwrite program Entry - Before
  • MSF Overwrite program Entry - After
  • Pros/Cons • PRO: Attacker receives a shell (or 17) :D • PRO: Size of EXE not changed • CON: No continued execution of program – WIN - LOSE
  • MSF Create Thread Method (Keep) When debugging in Immunity Debugger
  • MSF Create Thread Method (Keep) Immunity is telling the truth, memory sections: Original memory sections:
  • Msfvenom x32 Keep Method Explained • Two separate functions or stubs • Part Two: The shellcode payloads that we all know • Part One: Is not new, not so well known, but is awesome • Looks like an un-named section of code that has RWE attributes (very suspicious) • Very important for stager payloads
  • Pros And Cons of the Msfvenom Keep Method • PRO: Attacker receives shell and the binary works ‘normally’ for the user – That’s a WIN-WIN • CON: Should be easy for AV to catch • CON: Size of binary has increased
  • MSFVenom Win64 Patching Support Only supports x32 – Submitted a bug post on security street – A feature request was submitted (#8383):
  • The Portable Executable Format MS-DOS 2.0 HEADER and unused space OEM ID/INFO OFFSET to PE header MS-DOS 2.0 Stub and Reloc table And unused Space PE Header Section Headers Import pages (import/export info Base reloc info Resource info) • Not much has changed in the last 20 or so years • Must be backwards compatible (win8 must read the header) • Easy to automatically manipulate • dware/gg463125
  • The Common Object File Format (COFF) Format Microsoft COFF Header (machine type, number of sections, etc..) Section Headers Raw Data Code Data Debug Info Relocations • This is included in the PE File Format • The most important section for RE • Includes: - Machine Type - Number of Sections - Size and Access (RWE) of Sections • Typically includes the rest of the file Code, Data, Debug, Reloc (the actual sections)
  • End of PE/COFF
  • How I learned to Backdoor Windows Binaries • Though the Offensive Security Cracking the Perimeter course – Duh • Manual Labor • Time Consuming – At first hours – Now about 10-15 mintues • Missing some important concepts: – Working with the import table – Working with staged payloads (stagers) – Multi cave jumping – win32 only (slight differences in x64 asm)
  • CTP Methods • Append a new section of code – Similar to the Metasploit msfvenom keep – Named RWX section (e.g. .sdata, .moo, .what, etc…) • Use existing code caves for encoding/decoding shellcode in the appended section – We looked at XOR encoding – XOR encoding is no longer effective against AV
  • CTP Method
  • Code Caves?
  • Code Caves? A code cave is an area of bytes in a binary that contain a null byte pattern (x00) greater than two bytes.
  • How are code caves created? • Not sure, so I did some research… • Or went on a quest…
  • How are code caves created? • Starting out, I assumed that a unicorn would know everything. • So I went to defcon. • And what’s better than a unicorn at DEFCON!!!
  • How are code caves created? Hi Unicorn! Hi.. err, human! How are code caves made? I don’t know.  Aww. Want a beer?  Pssst… Check compliers… o/
  • How are code caves created? Tested the following x32 compilers: • G++ - GNU C++ • Cl.exe – MS compiler linker. • Lcc-win32 • Mingw32-c++
  • How are code caves created? Against this code: #include <stdio.h> #include <string.h> #include <stdlib.h> #include <windows.h> int array[600] = {0}; int main(int argc, char **argv) { printf("hello world"); return 0; } This Code is FREE as in BEER.
  • Find Code Caves Demo Code: Binaries:
  • How Are Code Caves Created? Results for code caves greater than 200 bytes in named sections (e.g. .text, .data, .idata, etc…): • Cl.exe : 7 • G++: 4 • Mingw32-c++: 3 • Lcc-win32: 0
  • How Are Code Caves Created? • Remember this line of code: – int array[600] = {0}; • Not one had a cave of at least 600 bytes.
  • How Are Code Caves Created? Lesson: If you want to minimize code caves in your code, carefully pick your compiler.** **More research could be done in this area.*** ***I don’t write compilers**** ****Nor do I want too… …yet :P
  • Some Ideas • Automation • Split shellcode into smaller sections • Use multiple code caves • Non-sequential cave jumping • Use user provided shellcode • Combine the Metasploit Stager solution with the CTP code cave use
  • Solution: BDF • x32 version released in March 2013 – Supported only single cave jumping – No x32 stagers support • Python27 - Single Script • Supports win32/64 – Supports x32 stagers – No stagers payloads for x64 yet. (Remember that bug feature request?) • Code Cave injection (single and multiple) • Support user-provided shellcode • Some Randomization (different hash every time an EXE is created) – Through random one’s compliment in the code – And different types of nops • Injector Module
  • How BDF works • Enumerates PE/COFF Header format • Determines if binary is supported (win32/64 intel) • Locates code caves that correspond to size of shellcode • Patches executable in an attempt to return registers/flags to the original state for continued execution – Patches entry location with a JMP to the first selected code cave/appended section – Patches each user selected code cave
  • How BDF works • Very primitive disassembler to do just what we need • Reworked the x32 msfvenom stager ‘keep’ stub to work in code caves and with user provided shellcode -x64 stager support is in the works • Reworked a handful of useful metasploit payloads to allow for multiple code cave jumping
  • Original Way BDF Worked
  • Now You Can Do This
  • Or This
  • Demos • Support Check (Live) • Backdooring win32/64 binaries (Live) – Append code cave – Single code caving – Code Cave jumping • Mass backdooring (directory) - Live • Provide your own shellcode - Live • Prototyping shellcode (video) • The injector module (video)
  • DEMO – Support Check • If not supported, then what? • Email me with the disassembly of the entry function (from a legitimate email) • I’ll send you the opcode update
  • DEMO - Patch a file with shellcode win32/64 • Append • Pick a single Cave • Multi-Jumps • Note – Non-stager payloads will ‘hang’ if C2 is not available – Payloads are patched ‘in-line’ and not run in a separate thread
  • DEMO - Mass backdooring (directory)
  • DEMO - Prototyping shellcode
  • DEMO – Injector Module • Injector is the hunt and backdoor binary of doom. • Use responsibly
  • DEMO - Provide your own shellcode • Can be anything, just make sure it matches the process type (x32 for x32) • Make sure you use ExitFunction=Thread or you will kill the parent process (not good)
  • Attack Scenarios or Methods • Salting Parking Lots with USBs • Hosting Rouge Exes • Attacking system services • Linux Setuid Attack for Windows – Patching binaries that require elevated perms but might be in non-admin directories • Sysinternal tools • Setup files
  • Mitigations • UPX encoding • Self Validation • AVs • EMET 4.0+ • Hash verification • White Listing
  • Mitigations - UPX Encoding • Not supported by BDF • Unpack – Patch – Pack • UPX is not protection against patching • Could opens your up your Exe to potential weaknesses – Are you unpacking to unprotected memory space?
  • Mitigations - Self Validation • Team Viewer • Round Robin Checking • Find the check, patch it
  • Mitigations – Anti-Virus’ • I broke the “rule” and uploaded my samples to Virustotal for this presentation • It really doesn’t matter • AV is dead
  • MSFVENOM keep vs MSVENOM non-keep vs BDF Cave Jumping MSFVENOM –k –t exe Hash: 6d0cb53a4fa983287310260f5c8659ab6c3a761ef8dbd147cf2cfd9e971f4295
  • MSFVENOM keep vs MSVENOM non-keep vs BDF Cave Jumping MSFVENOM –t exe Hash: 6d0cb53a4fa983287310260f5c8659ab6c3a761ef8dbd147cf2cfd9e971f4295
  • MSFVENOM keep vs MSVENOM non-keep vs BDF Cave Jumping BDF Cave jumping Hash: 5620ba8c64ff0d9cde65eda4156fbb85186f2bd0f16636cded5c9a0d8024d4e9
  • win32 BDF vs win64 BDF ZoomIt.exe vs ZoomIt64.exe
  • EMET 4.0+ FTW? • If you use position-independent shellcode (metasploit) • And the target binary is protected by EMET… • And the Caller protection setting is enabled… • And the application is running as win32… • EMET will stop this type of attack!
  • EMET 4.0+ FTW? • If the binary executes as a win64 process • EMET will not stop this type of attack! From the EMET 4.0 User Guide:
  • Mitigations - Whitelisting • Based on what you’ve seen today, why would you use trust AV. • There are whitelisting vendors, I’m not endorsing any of them • I did not test it, but they “should” work – if based on hashing verification and not name • Not the end game solution (e.g. powershell memory injection)
  • Enterprise Mitigations • Don’t let end users download binaries • Verify Your Binaries before Deploying – Verify hashes – Conduct forensic analysis and testing – Look at network traffic – Etc…
  • Road Map • x64 stub to support staged payloads • Support Mach-O and ELF formats • Patch the IAT and api pointers to shorten required shellcode and elimiate ROP-like calls • MITM patching of binaries during download
  • Progress on x64 Stager
  • Questions?