{
	"id": "7d787e4d-6081-4145-8a51-70e6a0dc968f",
	"created_at": "2026-04-06T00:13:49.773622Z",
	"updated_at": "2026-04-10T13:12:38.845729Z",
	"deleted_at": null,
	"sha1_hash": "a7b8bb2032c78306b37a17bfd092f1a486fba30e",
	"title": "Andromeda’s Five Star Custom Packer – Hackers’ Tactics Analyzed",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4005292,
	"plain_text": "Andromeda’s Five Star Custom Packer – Hackers’ Tactics\r\nAnalyzed\r\nBy Roy Moshailov\r\nArchived: 2026-04-05 20:06:42 UTC\r\nIntroduction\r\nPacker-based malware is malware which is modified in the runtime memory using different and sophisticated\r\ncompression techniques. Such malware is hard to detect by known malware scanners and anti-virus solutions. In\r\naddition, it is a cheap way for hackers to recreate new signatures for the same malware on the fly simply by\r\nchanging the encryption/packing method. Packers themselves are not malware; attackers use this tactic to\r\nobfuscate the code’s real intention.\r\nFor security solutions to be effective, they will need to augment their solutions with in-memory capabilities in\r\norder to monitor/hook the behavior of the malware after unpacking is completed.\r\nThis document describes a sophisticated Andromeda/Gamarue Custom Packer. Andromeda first appeared in 2011\r\nand still remains popular. Since the Andromeda attack chain has been described previously, this analysis instead\r\nfocuses on the packer and deobfuscation, which happens before the malware downloads or executes its next stage\r\nmalicious payload. The recent version of the custom packer we obtained (originating June 2016), has noteworthy\r\nand innovative functionality.\r\nDoes Morphisec stop this attack? Of course, even these new tricks can’t get past Morphisec, which prevents\r\nthis attack before it can drop its load.\r\nTechnical Analysis: Andromeda/Gamarue Custom Packer\r\nNowadays most malware employs anti-analysis techniques to make their code harder to analyze by security\r\nresearchers. Just like legitimate software developers protect their proprietary work, hackers use obfuscation\r\ntechniques to protect their code from being reverse-engineered or debugged.\r\nThe malware sample in our analysis is packed by a custom packer. To be able to get to the actual code, we first\r\nneed to unpack it.\r\nHow can you recognize a packed malware?\r\nThe sample usually comes with a resource section (in this example RC data contains some encrypted\r\ncontent).\r\nTypically, the compressed file is very large.\r\nBy looking at the import table – It might have only a few imports and many times these include\r\nLoadLibrary and/or GetModuleHandleW as those functions are used for the initial unpacking procedure.\r\nhttp://blog.morphisec.com/andromeda-tactics-analyzed\r\nPage 1 of 9\n\nNo readable static strings as the strings are encrypted.\r\nHigh entropy in sections for higher efficiency of information storage.\r\nA large portion of the code is inside the .data section (although there are newer versions with code inside\r\ntext).\r\nThe program has abnormal section sizes, such as .data and .rsrc sections. The RawDataSize is lower\r\nthan VirtualSize and usually also the section names themselves may indicate a particular packer.\r\nHow to unpack a packed malware\r\nIn forensic analysis, there are different ways to handle the unpacking process. While there are automatic tools for\r\ndifferent popular packers, it is more difficult to handle custom packers, which require some manual work and a\r\ndeeper knowledge of the different anti-debugging obstacles. Moreover, custom packers usually also involve\r\nstripping off multiple packing layers.\r\nThe Packer – Detailed\r\nLooking at Andromeda’s top-layer packer, we start by noticing an interesting, relatively high entropy in one of the\r\nsections (e.g. entropy of .rsrc is 7.376) which gives us the first indication that it is a packer.\r\nDetermining a point in time for which we know the malicious code was already unpacked, we identify the use of\r\nws2_32.dll (responsible for communication API). This means we can assume that the malicious code will start\r\ncommunication after it is unpacked. This is of high probability for downloaders or C\u0026C based malware.\r\nAs shown in the image below, there are two unnamed modules with RWE (read write execute) access rights –\r\nthose are indicators for the unpacked executable shellcode (the code will write and execute from the same\r\nlocation).\r\nAdditionally, we can see now strings which are typical to Andromeda.\r\nhttp://blog.morphisec.com/andromeda-tactics-analyzed\r\nPage 2 of 9\n\nIt is noticeable that those modules are still not a PE file (do not start with PE header) – those are executable\r\nshellcodes.\r\nWe also notice that the code starting from the entry point of the executable was modified, which reminds us of\r\nProcess Hollowing/ RunPE techniques.\r\nhttp://blog.morphisec.com/andromeda-tactics-analyzed\r\nPage 3 of 9\n\nRunPE techniques are designed to evade AV mitigation methods.\r\nHere are RunPE characteristics, as described in an Andromeda Bot Analysis by Infosec Institute:\r\nUnpack or decrypt the original EXE file in memory.\r\nCall CreateProcess on a target EXE using the CREATE_SUSPENDED flag. This maps the executable into\r\nmemory and it’s ready to execute, but the entry point hasn’t executed yet.\r\nNext, Call GetThreadContext on the main thread of the newly created process. The returned thread context\r\nwill have the state of all general-purpose registers. The EBX register holds a pointer to the Process\r\nhttp://blog.morphisec.com/andromeda-tactics-analyzed\r\nPage 4 of 9\n\nEnvironment Block (PEB), and the EAX register holds a pointer to the entry point of the innocent\r\napplication. In the PEB structure, at an offset of eight bytes, is the base address of the process image.\r\nCall NtUnmapViewOfSection to unmap and free up the virtual address space used by the new process.\r\nCall VirtualAllocEx to re-allocate the memory in the process’ address space to the correct size (the size of\r\nthe new EXE).\r\nCall WriteProcessMemory to write the PE headers and each section of the new EXE (unpacked in Step 1)\r\nto the virtual address location they expect to be (calling VirtualProtextEx to set the protection flags that\r\neach section needs).\r\nThe loader writes the new base address into the PEB and calls SetThreadContext to point EAX to the new\r\nentry point.\r\nFinally, the loader resumes the main thread of the target process with ResumeThread and the windows PE\r\nloader will do its magic. The executable is now mapped into memory without ever touching the disk.\r\nAlso in our case, the packer decrypts the executable memory space and replaces previously encrypted memory\r\nwith the functional code. The packer also updates the entry point to the new functional code start.\r\nForensic analysts will usually stop at this stage and dump the first layer decrypted code for further static analysis\r\nusing different tools like IDA.\r\nBased on the resemblance to RunPE methodology, we will execute the malware again, although now we set a\r\nbreakpoint on VirtualAlloc functions (used to allocate memory). Other similar functions are VirtualAlloc,\r\nVirtualAllocEx, or ZwAllocateVirtualMemory – also part of the Process Hollowing/RunPE method) called to\r\nreserve some RWX memory.\r\nWe get the VirtualAlloc function from PEB-\u003eKernel32.EAT\r\nhttp://blog.morphisec.com/andromeda-tactics-analyzed\r\nPage 5 of 9\n\nAfter identifying the RWE buffer address, we set a memory breakpoint on write to this buffer -\u003e the written code\r\nis actually the unpacker/decode function.\r\nhttp://blog.morphisec.com/andromeda-tactics-analyzed\r\nPage 6 of 9\n\nAfter the unpacking function finishes execution, its execution is redirected to the first shellcode:\r\nEAX address shellcode start = 0x003D0000\r\nhttp://blog.morphisec.com/andromeda-tactics-analyzed\r\nPage 7 of 9\n\nFrom inside the shellcode, VirtualAlloc is called again. We set a memory breakpoint on write to the new buffer\r\none more time, get a new PE and are redirected to a second shellcode, the unpacked PE.\r\nFrom this stage on, we get the regular Andromeda Loader which is described in detail by the Avast Threat\r\nIntelligence Team.\r\nConclusion\r\nThis article describes a single custom packer for Andromeda, one of the most popular malware delivery\r\nframeworks. Packers are a major concern for current security solutions. Packers allow attackers to penetrate\r\nnetwork solutions, file scanning solutions and, in many cases, behavior or AI based solutions.\r\nThe use of custom packers will only increase, as will the need for in-memory solutions that can block these types\r\nof attacks.\r\nA number of popular sandbox dynamic scanning services have some basic in-memory defenses, however these\r\nimpose severe performance penalties. Moreover, they frequently are not even effective as many packers, such as\r\nin our case, include techniques to identify sandbox environments. Morphisec’s Moving Target Defense based\r\ntechnology wins the malware packer battle without monitoring, hooking or using any other methods that affect\r\nendpoint performance.\r\nHash: 7b45c0141cca16fc14d4c81c653d4f22eb282cbbc4f913c9e830acf6e9d12b86\r\nhttp://blog.morphisec.com/andromeda-tactics-analyzed\r\nPage 8 of 9\n\nAbout the author\r\nRoy Moshailov\r\nSource: http://blog.morphisec.com/andromeda-tactics-analyzed\r\nhttp://blog.morphisec.com/andromeda-tactics-analyzed\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"http://blog.morphisec.com/andromeda-tactics-analyzed"
	],
	"report_names": [
		"andromeda-tactics-analyzed"
	],
	"threat_actors": [],
	"ts_created_at": 1775434429,
	"ts_updated_at": 1775826758,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a7b8bb2032c78306b37a17bfd092f1a486fba30e.pdf",
		"text": "https://archive.orkl.eu/a7b8bb2032c78306b37a17bfd092f1a486fba30e.txt",
		"img": "https://archive.orkl.eu/a7b8bb2032c78306b37a17bfd092f1a486fba30e.jpg"
	}
}