Patching Windows Executables with the Backdoor Factory | DerbyCon 2013


Published on

Slides from my DerbyCon 2013 talk.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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

    1. 1. Patching Windows Executables with the Backdoor Factory Joshua Pitts DerbyCon 2013
    2. 2. 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
    3. 3. 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
    4. 4. Urban Dictionary
    5. 5. Overview • History of Patching • How I learned to patch binaries • The Backdoor Factory – Features – Capabilities • Demos (Live and Video) • Mitigations • Going forward
    6. 6. 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.
    7. 7. For This Presentation My Definition: Adding or taking away content or functionality to a compiled binary.
    8. 8. 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
    9. 9. History of Patching Good thing we don’t do this with operating systems.
    10. 10. 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…
    11. 11. 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
    12. 12. 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.
    13. 13. 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)
    14. 14. MSF Overwrite program Entry - Before
    15. 15. MSF Overwrite program Entry - After
    16. 16. Pros/Cons • PRO: Attacker receives a shell (or 17) :D • PRO: Size of EXE not changed • CON: No continued execution of program – WIN - LOSE
    17. 17. MSF Create Thread Method (Keep) When debugging in Immunity Debugger
    18. 18. MSF Create Thread Method (Keep) Immunity is telling the truth, memory sections: Original memory sections:
    19. 19. 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
    20. 20. 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
    21. 21. MSFVenom Win64 Patching Support Only supports x32 – Submitted a bug post on security street – A feature request was submitted (#8383):
    22. 22. PE/COFF
    23. 23. 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
    24. 24. 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)
    25. 25. End of PE/COFF
    26. 26. 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)
    27. 27. 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
    28. 28. CTP Method
    29. 29. Code Caves?
    30. 30. Code Caves? A code cave is an area of bytes in a binary that contain a null byte pattern (x00) greater than two bytes.
    31. 31. How are code caves created? • Not sure, so I did some research… • Or went on a quest…
    32. 32. 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!!!
    33. 33. 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/
    34. 34. How are code caves created? Tested the following x32 compilers: • G++ - GNU C++ • Cl.exe – MS compiler linker. • Lcc-win32 • Mingw32-c++
    35. 35. 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.
    36. 36. Find Code Caves Demo Code: Binaries:
    37. 37. 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
    38. 38. How Are Code Caves Created? • Remember this line of code: – int array[600] = {0}; • Not one had a cave of at least 600 bytes.
    39. 39. 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
    40. 40. 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
    41. 41. 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
    42. 42. 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
    43. 43. 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
    44. 44. Original Way BDF Worked
    45. 45. Now You Can Do This
    46. 46. Or This
    47. 47. 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)
    48. 48. 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
    49. 49. 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
    50. 50. DEMO - Mass backdooring (directory)
    51. 51. DEMO - Prototyping shellcode
    52. 52. DEMO – Injector Module • Injector is the hunt and backdoor binary of doom. • Use responsibly
    53. 53. 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)
    54. 54. 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
    55. 55. Mitigations • UPX encoding • Self Validation • AVs • EMET 4.0+ • Hash verification • White Listing
    56. 56. 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?
    57. 57. Mitigations - Self Validation • Team Viewer • Round Robin Checking • Find the check, patch it
    58. 58. Mitigations – Anti-Virus’ • I broke the “rule” and uploaded my samples to Virustotal for this presentation • It really doesn’t matter • AV is dead
    59. 59. MSFVENOM keep vs MSVENOM non-keep vs BDF Cave Jumping MSFVENOM –k –t exe Hash: 6d0cb53a4fa983287310260f5c8659ab6c3a761ef8dbd147cf2cfd9e971f4295
    60. 60. MSFVENOM keep vs MSVENOM non-keep vs BDF Cave Jumping MSFVENOM –t exe Hash: 6d0cb53a4fa983287310260f5c8659ab6c3a761ef8dbd147cf2cfd9e971f4295
    61. 61. MSFVENOM keep vs MSVENOM non-keep vs BDF Cave Jumping BDF Cave jumping Hash: 5620ba8c64ff0d9cde65eda4156fbb85186f2bd0f16636cded5c9a0d8024d4e9
    62. 62. win32 BDF vs win64 BDF ZoomIt.exe vs ZoomIt64.exe
    63. 63. 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!
    64. 64. 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:
    65. 65. 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)
    66. 66. 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…
    67. 67. 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
    68. 68. Progress on x64 Stager
    69. 69. Questions?