Infragard Sept08


Published on

A presentation I was invited to give on unpacking malware at an Infraguard meeting in September 2008.

  • Be the first to comment

  • Be the first to like this

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

No notes for slide

Infragard Sept08

  1. 1. Unpacking Malicious Binaries InfraGard September 2008
  2. 2. - In Windows, all executables use a common format known as a portable executable - PEs are based off the Common Object File Format (COFF) used in UNIX - The PE format is also used for .dll, .obj, and .sys files in Windows Portable Executables (PEs)‏
  3. 3. PE Format - All PE files will follow this same format, regardless of the version of Windows
  4. 4. - Packing an executable essentially encapsulates one PE inside of another PE - The inner PE is our original code (in our case, the malicious code) and the outer PE is the newly packed executable that is produced - There are two categories of packers, generic packers and custom packers Packing
  5. 5. - Custom packers are unique packing algorithms invented by the malware author for that specific piece (or group) of malware - Can be more difficult to unpack, because no documentation, information, or tutorials about the packer can be found, because it was custom made - Custom packers may not be as robust, or contain all of the extra features that a generic packer might include, and once you figure out how to unpack one custom packed binary, you can usually unpack all of its related binaries (ie different versions of Storm)‏ Custom vs Generic packers
  6. 6. - Generic packers can be easier to unpack than custom made packers, because information and tutorials can be found online where people have already reverse engineered these packers - Methods of unpacking stay consistent with the packer used, in other words, all malware packed with UPX can be unpacked the same way - However, many contain extra features such as antidebugging (won't run in a debugger) or anti VMware (won't run in a virtual machine)‏ Custom vs Generic packers
  7. 7. <ul><li>UPX </li></ul><ul><li>ASpack </li></ul><ul><li>PECompact </li></ul><ul><li>Armadillo </li></ul><ul><li>Themida </li></ul><ul><li>Yoda </li></ul><ul><li>CryptX </li></ul><ul><li>MEW </li></ul>Examples of generic packers: <ul><li>MoleBox </li></ul><ul><li>Morphine </li></ul><ul><li>PEspin </li></ul><ul><li>TElock </li></ul><ul><li>WinUPack </li></ul><ul><li>VCrypt </li></ul><ul><li>ExECryptor </li></ul><ul><li>eXPressor </li></ul>
  8. 8. - Obfuscation of the malicious code. The original executable can't be analyzed or reverse engineered until it has been unpacked - Makes the malware harder to detect for AV products - Makes the executable compressed/smaller in size - Can make the same (or similar) pieces of malware appear to be different Why bother packing?
  9. 9. - Peid, a program used to detect which packer was used on an executable - Ollydbg, with the Ollydump plugin, for disassembling and debugging the executable - ImpRec, for reconstructing the IAT - Strings, to pull strings from the unpacked binary - Procexplorer, to tell when you've accidentally infected yourself Tools used for unpacking
  10. 10. - Unpacking allows analysis and reverse engineering of a piece of malware - Allows us to find information that we otherwise might not find, for example what compiler was used, strings that hint at what the malware does, IP addresses, etc. - Allows us to show that 2 pieces of malware are related, when they otherwise don't appear to be Advantages of unpacking
  11. 11. - In order to unpack a PE, we must use a disassembler and debugger to step through the outer PE, until we reach the original entry point (OEP) of the inner binary (our malware)‏ - From there, we can dump the binary starting at that OEP, which now gives us an unpacked version of that inner PE - If we want to execute the PE, we must repair its import address table (IAT)‏ - A lot of unpacking is Trial and Error The unpacking process
  12. 12. - Using PEID, this is a good place to start, but this method is fairly unreliable, and doesn't ID custom packers - Looking at the section headers of a PE can also give hints about which packer was used Identifying the Packer
  13. 13. - Running strings on an executable, some strings can give hints about which packer was used - Ollydbg is pretty reliable on determining if a binary is packed, though not what it was packed with Identifying the Packer
  14. 14. - Refers to a trick commonly used by unpackers. Can be used to unpack many generic packers - Many generic packers start with the instruction “ PUSHAD”, this pushes all information in the processor's registers onto the stack, thus allowing the packer to use the registers without risk of overwriting important information in those registers (if for example, the unpacked binary will later need to reference those values)‏ The ESP trick
  15. 15. The ESP trick - ESP refers to the register that holds the stack pointer
  16. 16. - After executing the PUSHAD, the next time the executable references the stack pointer (ESP) is when it is popping everything off the stack - The executable isn't going to pop everything off the stack until it is done using the registers, or in other words, when it is finished unpacking The ESP trick - The next JMP after the POPAD will be our OEP
  17. 17. - Execute the PUSHAD at the start of the packed executable - Set a breakpoint on the stack pointer ESP - Let the program run until it hits the breakpoint - Execute the program one line at a time until you hit the next JMP statement, this will be the unpacked executable's OEP The ESP trick
  18. 18. - Live demo of video.exe
  19. 19. Video.exe screens
  20. 20. Video.exe screens
  21. 21. - Live demo of Colonial Digital Certificates
  22. 22. Digital cert spam screens
  23. 23. Digital cert spam screens
  24. 24. Questions?