Patching Windows Executables with the Backdoor Factory | DerbyCon 2013
•Download as PPTX, PDF•
7 likes•8,751 views
Patching Windows Executives with the Backdoor Factory is a presentation about binary patching techniques. It discusses the history of patching, how key generators and Metasploit patch binaries, and how the author learned to manually patch binaries. The presentation then introduces the Backdoor Factory tool, which can automatically patch Windows binaries by injecting shellcode into code caves. It demonstrates patching via code cave insertion, single cave jumps, and cave jumping. Mitigations like self-validation and antivirus are discussed.
Report
Share
Related slideshows
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Patching Windows Executables with the Backdoor Factory | DerbyCon 2013
Similar to Patching Windows Executables with the Backdoor Factory | DerbyCon 2013 (20)
Recently uploaded
Recently uploaded (20)
Patching Windows Executables with the Backdoor Factory | DerbyCon 2013
- 1. Patching Windows Executables with the Backdoor Factory Joshua Pitts DerbyCon 2013
- 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. 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
- 5. Overview • History of Patching • How I learned to patch binaries • The Backdoor Factory – Features – Capabilities • Demos (Live and Video) • Mitigations • Going forward
- 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. For This Presentation My Definition: Adding or taking away content or functionality to a compiled binary.
- 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. History of Patching Good thing we don’t do this with operating systems.
- 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. 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. 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. 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. MSF Overwrite program Entry - Before
- 15. MSF Overwrite program Entry - After
- 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. MSF Create Thread Method (Keep) When debugging in Immunity Debugger
- 18. MSF Create Thread Method (Keep) Immunity is telling the truth, memory sections: Original memory sections:
- 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
- 21. 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
- 22. MSFVenom Win64 Patching Support Only supports x32 – Submitted a bug post on security street – A feature request was submitted (#8383):
- 23. PE/COFF
- 24. 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 • http://msdn.microsoft.com/library/windows/har dware/gg463125
- 25. 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)
- 26. End of PE/COFF
- 27. 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)
- 28. 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
- 29. CTP Method
- 30. Code Caves?
- 31. Code Caves? A code cave is an area of bytes in a binary that contain a null byte pattern (x00) greater than two bytes.
- 32. How are code caves created? • Not sure, so I did some research… • Or went on a quest…
- 33. 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!!!
- 34. 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/
- 35. How are code caves created? Tested the following x32 compilers: • G++ - GNU C++ • Cl.exe – MS compiler linker. • Lcc-win32 • Mingw32-c++
- 36. 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.
- 37. Find Code Caves Demo Code: http://github.com/secretsquirrel/the-backdoor-factory Binaries: http://live.sysinternals.com
- 38. 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
- 39. How Are Code Caves Created? • Remember this line of code: – int array[600] = {0}; • Not one had a cave of at least 600 bytes.
- 40. 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
- 42. 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
- 43. 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
- 44. 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
- 45. 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
- 47. Original Way BDF Worked
- 48. Now You Can Do This
- 49. Or This
- 50. 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)
- 51. 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
- 52. 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
- 53. DEMO - Mass backdooring (directory)
- 54. DEMO - Prototyping shellcode
- 55. DEMO – Injector Module • Injector is the hunt and backdoor binary of doom. • Use responsibly
- 56. 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)
- 57. 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
- 58. Mitigations • UPX encoding • Self Validation • AVs • EMET 4.0+ • Hash verification • White Listing
- 59. 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?
- 60. Mitigations - Self Validation • Team Viewer • Round Robin Checking • Find the check, patch it
- 61. Mitigations – Anti-Virus’ • I broke the “rule” and uploaded my samples to Virustotal for this presentation • It really doesn’t matter • AV is dead
- 62. MSFVENOM keep vs MSVENOM non-keep vs BDF Cave Jumping MSFVENOM –k –t exe Hash: 6d0cb53a4fa983287310260f5c8659ab6c3a761ef8dbd147cf2cfd9e971f4295
- 63. MSFVENOM keep vs MSVENOM non-keep vs BDF Cave Jumping MSFVENOM –t exe Hash: 6d0cb53a4fa983287310260f5c8659ab6c3a761ef8dbd147cf2cfd9e971f4295
- 64. MSFVENOM keep vs MSVENOM non-keep vs BDF Cave Jumping BDF Cave jumping Hash: 5620ba8c64ff0d9cde65eda4156fbb85186f2bd0f16636cded5c9a0d8024d4e9
- 65. win32 BDF vs win64 BDF ZoomIt.exe vs ZoomIt64.exe
- 66. 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!
- 67. 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:
- 68. 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)
- 69. 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…
- 70. 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
- 71. Progress on x64 Stager
- 72. Questions?
Editor's Notes
- 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.