Amber v3.0: Reflective PE packer for bypassing security products and mitigations
Amber is a proof of concept packer for bypassing security products and mitigations. It can pack regularly compiled PE files into reflective payloads that can load and execute itself like a shellcode. It enables stealthy in-memory payload deployment that can be used to bypass anti-virus, firewall, IDS, IPS products and application white-listing mitigations.
For generating the actual Amber payload first packer creates a memory mapping image of the malware, generated memory mapping file contains all sections, optional PE header and null byte padding for unallocated memory space between sections.
After obtaining the mapping of the malware, packer checks the ASLR compatibility of the supplied EXE, if the EXE is ASLR compatible packer adds the related Amber stub if not it uses the stub for EXE files that have fixed image base. From this point, Amber payload is completed. Below image describes the Amber payload inside the target process
This memory space will be the new base of malware after the relocation process. In the second phase, Amber stub will resolve the addresses of functions that are imported by the malware and write the addresses to the import address table of the mapped image of malware. Address resolution phase is very similar to the approach used by the PE loader of Windows, Amber stub will parse the import table entries of the mapped malware image and load each DLL used by the malware by calling the LoadLibraryA windows API function, each _IMAGE_IMPORT_DESCRIPTOR entry inside import table contains pointer to the names of loaded DLL’s as string, stub will take advantage of existing strings and pass them as parameters to the LoadLibraryA function, after loading the required DLL Amber stub saves the DLL handle and starts finding the addresses of imported functions from the loaded DLL with the help of GetProcAddress windows API function, _IMAGE_IMPORT_DESCRIPTOR structure also contains a pointer to a structure called import names table, this structure contains the names of the imported functions in the same order with import address table(IAT), before calling the GetProcAddress function Amber stub passes the saved handle of the previously loaded DLL and the name of the imported function from import name table structure. Each returned function address is written to the malwares import address table (IAT) with 4 padding byte between them. This process continues until the end of the import table, after loading all required DLL’s and resolving all the imported function addresses the second phase is complete.
At the third phase Amber stub will start the relocation process by adjusting the addresses according to the address returned by the VirtualAlloc call, this is almost the same approach used by the PE loader of the windows itself, stub first calculates the delta value with the address returned by the VirtualAlloc call and the preferred base address of the malware, delta value is added to every entry inside the relocation table. In the fourth phase, Amber stub will place the file mapping to the previously allocated space, moving the mapped an image is done with a simple assembly loop that does a byte by byte move operation.
At the final phase, Amber stub will create a new thread starting from the entry point of the malware by calling the CreateThread API function. The reason for creating a new thread is to create a new growable stack for the malware and additionally executing the malware inside a new thread will allow the target process to continue from its previous state. After creating the malware thread stub will restore the execution with returning to the first caller or stub will jump inside an infinite loop that will stall the current thread while the malware thread successfully runs.
- Entire codebase rewritten from scratch
- No external dependency 🎉
- Much more evasive PE loader
- New generation SGN encoder
- New CRC32 based API resolvers
- Much smaller C++ stub
- Simplified usage
Copyright (c) 2017 Ege Balcı