Amber v3.2: 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, the 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 a fixed image base. From this point, Amber payload is completed. The 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.

In 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, the delta value is added to every entry inside the relocation table. In the fourth phase, the Amber stub will place the file mapping to the previously allocated space, moving the mapped 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 the stub will jump inside an infinite loop that will stall the current thread while the malware thread successfully runs.

Changelog v3.2

– Major loader update!
– Added TLS callback support
– Added forwarded imports support
– Removed GetProcAddress and LoadLibrary WinAPI usage
– Switched to NTDLL WinApi functions
– Wiper code improved
– Added lite loader option for appending PE files on the fly!
– Added experimental raw syscall loader
– Added static build flags in makefile
– File name bug fixed
– Dockerfile updated
– Github workflows added
– README updated

Usage

amber [options] file.exe

    OPTIONS:

    -k, -keysize                Size of the encryption key in bytes (Max:255/Min:8)

    -r, -reflective             Generated a reflective payload

    -i, -iat                    Uses import address table entries instead of export address table

    -s, -scrape                 Scrape the PE header info (May break some files)

    -no-resource                Don't add any resource data

    -ignore-integrity           Ignore integrity check errors

    -v, -verbose                Verbose output mode

    -h, -H                      Show this massage

    EXAMPLE:

    (Default settings if no option parameter passed)

    amber -k 8 file.exe

Download

Demo

Copyright (c) 2017 Ege Balcı

Source: https://github.com/EgeBalci/