{ "id": "0bd95c0b-e0ad-469c-96d6-d6920c470989", "created_at": "2026-04-06T00:20:13.034509Z", "updated_at": "2026-04-10T03:32:34.588305Z", "deleted_at": null, "sha1_hash": "2b0f644da3e22c2f616f5c728024193a582dabfe", "title": "Hunting In Memory", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 55799, "plain_text": "Hunting In Memory\r\nBy Joe Desimone\r\nPublished: 2022-06-21 · Archived: 2026-04-05 13:45:02 UTC\r\nThreat Hunters are charged with the difficult task of sifting through vast sources of diverse data to pinpoint\r\nadversarial activity at any stage in the attack lifecycle. To be successful, hunters must continually hone their\r\nsubject matter expertise on the latest attacker techniques and detection methods. Memory resident malware, which\r\npresents itself in many forms, is an attacker technique that has existed for over a decade. The popularity of\r\nmemory resident malware has steadily increased over time, possibly resulting from the proliferation of code and\r\nknowledge of in memory techniques. More likely, its popularity reflects the success of memory-based techniques\r\nto evade detection by security products and practitioners. Once limited to advanced adversaries, memory resident\r\ntechniques are now commonplace for all levels of adversary sophistication. I will examine the most common of\r\nthese memory based attacker techniques, and walk through our team’s research to craft a scalable, low noise\r\napproach to hunting for adversaries that are hiding in memory.\r\nAttacker Techniques\r\nBefore I address memory hunting methods to detect adversaries in your network, it is helpful to understand the\r\ncommon forms of memory resident malware. These techniques include shellcode injection, reflective DLL\r\ninjection, memory module, process and module hollowing, and Gargoyle (ROP/APC).\r\nSHELLCODE INJECTION\r\nShellcode injection is the most basic in-memory technique and has also been around the longest. The basic\r\n‘recipe’ for shellcode injection is a four step process. These steps are: 1) open a target process (OpenProcess); 2)\r\nallocate a chunk of memory in the process (VirtualAllocEx); 3) write the shellcode payload to the newly allocated\r\nsection (WriteProcessMemory); and 4) create a new thread in the remote process to execute the shellcode\r\n(CreateRemoteThread). The venerable Poison Ivy malware uses this technique, which is a big reason why so\r\nmany APT groups were drawn to it over the years.\r\nIf you pull up a Poison Ivy samplewith x64dbg and set a breakpoint on VirtualAllocEx, you will soon locate the\r\nchunk of code responsible for the injection.\r\nShellcode Injection\r\nShellcode Injection\r\nShellcode Injection\r\nShellcode Injection\r\nIn the first image, the push 40 instruction preceding the call to VirtualAllocEx corresponds to page access\r\nprotection value of PAGE_EXECUTE_READWRITE. In the following screenshot from ProcessHacker of the\r\nmemory layout of a Poison Ivy implant, you can see it allocates a number of these RWX sections.\r\nhttps://www.endgame.com/blog/technical-blog/hunting-memory\r\nPage 1 of 5\n\nPoison Ivy Implant\r\nPoison Ivy Implant\r\nTypical code sections are of type ‘Image’ and map to a file on disk. However, these are type ‘Private’ and do not\r\nmap to a file on disk. They are therefore referred to as unbacked executable sections or floating code. Threads\r\nstarting from these types of memory regions are anomalous and a good indicator of malicious activity.\r\nProcessHacker can also show you the call stack of the malware threads. There are multiple functions in the call\r\nstack which do not map to memory associated with loaded modules.\r\nProcessHacker\r\nProcessHacker\r\nREFLECTIVE DLL INJECTION\r\nReflective DLL injection, originally developed by Steven Fewer, is another type of in memory attacker technique.\r\nMetasploit’s Meterperter payload was one of the first attempts to fully weaponize the technique, but many\r\nmalware families use it today. Reflective DLL injection works by creating a DLL that maps itself into memory\r\nwhen executed, instead of relying on the Window’s loader. The injection process is identical to shellcode injection,\r\nexcept the shellcode is replaced with a self-mapping DLL. The self-mapping component added to the DLL is\r\nresponsible for resolving import addresses, fixing relocations, and calling the DllMain function. Attackers benefit\r\nfrom the ability to code in higher level languages like C/C++ instead of assembly.\r\nClassic reflective DLL injection, such as that used by Meterpreter, is easy for hunters to find. It leaves large RWX\r\nmemory sections in the process, even when the meterpreter session is closed. The start of these unbacked\r\nexecutable memory sections contain the full MZ/PE header, as shown in the images below. However, keep in\r\nmind that other reflective DLL implementations could wipe the headers and fix the memory leak.\r\nUnbacked executable memory sections\r\nUnbacked executable memory sections\r\nunbacked executable memory sections\r\nunbacked executable memory sections\r\nThe DLLs loaded in memory also conveniently export a self-describing function called ReflectiveLoader().\r\nReflective Loader\r\nReflective Loader\r\nMEMORY MODULE\r\nMemory module is another memory resident attacker technique. It is similar to Reflective DLL injection except\r\nthe injector or loader is responsible for mapping the target DLL into memory instead of the DLL mapping itself.\r\nEssentially, the memory module loader re-implements the LoadLibrary function, but it works on a buffer in\r\nmemory instead of a file on disk. The original implementation was designed for mapping in the current process,\r\nbut updated techniques can map the module into remote processes. Most implementations respect the section\r\npermissions of the target DLL and avoid the noisy RWX approach.\r\nhttps://www.endgame.com/blog/technical-blog/hunting-memory\r\nPage 2 of 5\n\nNetTraveler is one malware family that uses a memory module style technique. When NetTraveler starts, it\r\nunpacks the core functionality and maps it into memory. The page permissions more closely resemble a legitimate\r\nDLL, however the memory regions are still private as opposed to image.\r\nNetTraveler page permissions\r\nNetTraveler page permissions\r\nThe active threads have start addresses at these private regions. The callstack also reveals these malicious sections.\r\nendgame-callstack-malicious-sections.png\r\nendgame-callstack-malicious-sections.png\r\nWinnti is yet another malware sample that uses the Memory Module technique. They had a minor slip on the\r\nsection permissions of the first page, as you can see below.\r\nendgame-section-permissions.jpg\r\nendgame-section-permissions.jpg\r\nHowever, the Winnti sample was notable because the MZ/PE headers in the DLL were erased, making it more\r\ndifficult to detect.\r\n_endgame-DLL.jpg\r\n_endgame-DLL.jpg\r\nPROCESS HOLLOWING\r\nProcess hollowing is another technique attackers use to prevent their malware from being detected by security\r\nproducts and hunters. It involves creating a suspended process, unmapping (hollowing) the original executable\r\nfrom the process, allocating and writing a new payload to the process, redirecting the execution of the original\r\nthread to the new payload with SetThreadContext, and finally calling ResumeThread to complete. More stealthy\r\nvariants use Create/Map section APIs to avoid WriteProcessMemory. Others modify the entry point with a jump\r\ninstead of using SetThreadContext.\r\nDarkComet is one of many malware families that use process hollowing techniques. Several artifacts can be used\r\nto detect process hollowing. One dead giveaway for this activity is a process being spawned with the\r\nCREATE_SUSPENDED flag, as shown in the following screenshot from a DarkComet sample.\r\n_endgame-darkcomet-sample.jpg\r\n_endgame-darkcomet-sample.jpg\r\nMODULE OVERWRITING\r\nSo far, all techniques discussed have led to the execution of non-image backed code, and were therefore fairly\r\nstraightforward to detect. Module overwriting, on the other hand, avoids this requirement, making it much more\r\ndifficult to detect. This technique consists of mapping an unused module into a target process and then overwriting\r\nthe module with its own payload. Flame was the first widely publicized malware family to use this technique.\r\nhttps://www.endgame.com/blog/technical-blog/hunting-memory\r\nPage 3 of 5\n\nMore recently, Careto and Odinaff malware families have used module overwriting techniques. Various techniques\r\ncan be used to reliably detect module overwriting, which involves comparing memory to associated data on disk.\r\nGARGOYLE\r\nGargoyle is a proof of concept technique for memory resident malware that can evade detection from many\r\nsecurity products. It accomplishes this feat by laying dormant with read-only page protections. It then periodically\r\nwakes up, using an asynchronous procedure call, and executes a ROP chain to mark its payload as executable\r\nbefore jumping to it. After the payload finishes executing, Gargoyle again masks its page permissions and goes\r\nback to sleep. One way to detect this attacker technique is to examine threads and user APCs for evidence of ROP\r\nchains.\r\nDetecting In-Memory Attacks\r\nGiven the proliferation and accessibility of these techniques, security personnel must be vigilant for memory-based attacker techniques and proactively hunt for them on their networks. However, most products cannot\r\ngenerically detect in-memory attacks at scale, leaving defenders with an enormous gap in their ability to protect\r\nagainst these attacks. Endgame has done significant research to bring low-noise detection capabilities into our\r\nproduct for each method mentioned above.\r\nGiven the immense size and impact of this detection gap, it is important to raise all boats, not just those of our\r\ncustomers. For this reason, we collaborated with Jared Atkinson on his powershell tool called Get-InjectedThreads, which implements a relatively low-noise method of detecting in memory threats. It scans active\r\nthreads on the system for suspicious start addresses. Hunters leverage it to scan hosts in their networks and\r\nquickly identify many memory resident malware techniques. The script works by querying each active thread with\r\nthe NtQueryInformationThread function to retrieve its start address. The start address is then queried with the\r\nVirtualQueryEx function to determine the associated section properties. If the memory region where the thread\r\nstarted is unbacked and executable (i.e. not image type and has execute bit set), then the thread is considered\r\ninjected. The following screenshot shows a sample detection when run on a system infected with a 9002 RAT\r\nsample.\r\n_endgame-RAT-sample.jpg\r\n_endgame-RAT-sample.jpg\r\nThe script will catch a variety of malware families leveraging the shellcode injection, reflective DLL, memory\r\nmodule, and some process hollowing techniques. However, it is no replacement for security products that\r\ncomprehensively prevent in-memory attacks, such as Endgame.\r\nEnterprise In-Memory Detection at Scale\r\nEndgame has built detections for each of these techniques (and many more) into our enterprise security platform,\r\noffering best in market capabilities to locate in-memory threats. We do not simply rely on naïve approaches like\r\nmonitoring well-known system call sequences for process injection, but efficiently analyze memory to find all\r\nknown evasion capabilities. This provides our users with thread-level visibility on injected code, as well as\r\nsophisticated follow-on actions like examining the injected code and suspending only a malicious injected thread\r\nhttps://www.endgame.com/blog/technical-blog/hunting-memory\r\nPage 4 of 5\n\nto remediate the threat. Our platform is effective both in stopping injection as it is happening in real time as well\r\nas locating already resident adversaries hiding in memory, locating threats across tens of thousands of hosts in\r\nseconds.\r\nLike any signatureless detection technique, false positives (FPs) are an important consideration. As we researched\r\nand implemented our technique-based preventions for each adversary technique described above, we initially\r\nencountered FPs at every step of the way. Handling these correctly in our product is of paramount importance.\r\nMost FPs are related to security software, Just-In-Time (JIT) compiled code, or DRM protected/packed\r\napplications. Security products sometimes inject code to some or all processes on the system to enhance their\r\nbehavioral detection capabilities. The downside is if the product is sloppy in its methods, it can actually harm the\r\nsecurity of the system and make hunting for real in memory threats more difficult. JIT code, another potential area\r\nfor false positives, generates assembly code at runtime which lives in unbacked or floating memory regions. .NET\r\nor Java applications are a couple of examples which use JIT techniques. Fortunately, this type of code is easier to\r\nidentify and filter than rogue security products. Lastly, applications packed or protected with Digital Rights\r\nManagement (DRM) schemes should be kept in mind. These applications may decrypt or deobfuscate their core\r\nfunctionality in memory to deter debugging and reverse engineering. However, the same techniques are used by\r\nmalware to evade detection and deter analysis from security practitioners.\r\nThrough careful design decisions and extensive testing, we have managed to achieve very low false positive rates,\r\nallowing Endgame users to root out in-memory threats rapidly.\r\nConclusion\r\nAdversaries will continue to innovate new techniques to avoid detection and accomplish their objectives. Memory\r\nresident techniques are no exception, and have been a thorn in the side of endpoint security defenders for over a\r\ndecade. Fortunately, by understanding the latest techniques, we can turn the tables and use this knowledge to\r\ndevelop new high fidelity detection methods. At Endgame, our comprehensive approach to these attacks have led\r\nus to a market leading position for fileless attack detection (adding to our other key technologies). For more on\r\nhunting for in-memory attacks, check out our slides from our SANS Threat Hunting and IR Summit presentation.\r\nSource: https://www.endgame.com/blog/technical-blog/hunting-memory\r\nhttps://www.endgame.com/blog/technical-blog/hunting-memory\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.endgame.com/blog/technical-blog/hunting-memory" ], "report_names": [ "hunting-memory" ], "threat_actors": [ { "id": "67bf0462-41a3-4da5-b876-187e9ef7c375", "created_at": "2022-10-25T16:07:23.44832Z", "updated_at": "2026-04-10T02:00:04.607111Z", "deleted_at": null, "main_name": "Careto", "aliases": [ "Careto", "The Mask", "Ugly Face" ], "source_name": "ETDA:Careto", "tools": [ "Careto" ], "source_id": "ETDA", "reports": null }, { "id": "808d8d52-ca06-4a5f-a2c1-e7b1ce986680", "created_at": "2022-10-25T16:07:23.899157Z", "updated_at": "2026-04-10T02:00:04.782542Z", "deleted_at": null, "main_name": "NetTraveler", "aliases": [ "APT 21", "Hammer Panda", "NetTraveler", "TEMP.Zhenbao" ], "source_name": "ETDA:NetTraveler", "tools": [ "Agent.dhwf", "Destroy RAT", "DestroyRAT", "Kaba", "Korplug", "NetTraveler", "Netfile", "PlugX", "RedDelta", "Sogu", "TIGERPLUG", "TVT", "Thoper", "TravNet", "Xamtrav" ], "source_id": "ETDA", "reports": null }, { "id": "4d5f939b-aea9-4a0e-8bff-003079a261ea", "created_at": "2023-01-06T13:46:39.04841Z", "updated_at": "2026-04-10T02:00:03.196806Z", "deleted_at": null, "main_name": "APT41", "aliases": [ "WICKED PANDA", "BRONZE EXPORT", "Brass Typhoon", "TG-2633", "Leopard Typhoon", "G0096", "Grayfly", "BARIUM", "BRONZE ATLAS", "Red Kelpie", "G0044", "Earth Baku", "TA415", "WICKED SPIDER", "HOODOO", "Winnti", "Double Dragon" ], "source_name": "MISPGALAXY:APT41", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "f5bf6853-3f6e-452c-a7b7-8f81c9a27476", "created_at": "2023-01-06T13:46:38.677391Z", "updated_at": "2026-04-10T02:00:03.064818Z", "deleted_at": null, "main_name": "Careto", "aliases": [ "The Mask", "Ugly Face" ], "source_name": "MISPGALAXY:Careto", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "2a24d664-6a72-4b4c-9f54-1553b64c453c", "created_at": "2025-08-07T02:03:24.553048Z", "updated_at": "2026-04-10T02:00:03.787296Z", "deleted_at": null, "main_name": "BRONZE ATLAS", "aliases": [ "APT41 ", "BARIUM ", "Blackfly ", "Brass Typhoon", "CTG-2633", "Earth Baku ", "GREF", "Group 72 ", "Red Kelpie ", "TA415 ", "TG-2633 ", "Wicked Panda ", "Winnti" ], "source_name": "Secureworks:BRONZE ATLAS", "tools": [ "Acehash", "CCleaner v5.33 backdoor", "ChinaChopper", "Cobalt Strike", "DUSTPAN", "Dicey MSDN", "Dodgebox", "ForkPlayground", "HUC Proxy Malware (Htran)" ], "source_id": "Secureworks", "reports": null }, { "id": "254f2fab-5834-4d90-9205-d80e63d6d867", "created_at": "2023-01-06T13:46:38.31544Z", "updated_at": "2026-04-10T02:00:02.924166Z", "deleted_at": null, "main_name": "APT21", "aliases": [ "HAMMER PANDA", "TEMP.Zhenbao", "NetTraveler" ], "source_name": "MISPGALAXY:APT21", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434813, "ts_updated_at": 1775791954, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/2b0f644da3e22c2f616f5c728024193a582dabfe.pdf", "text": "https://archive.orkl.eu/2b0f644da3e22c2f616f5c728024193a582dabfe.txt", "img": "https://archive.orkl.eu/2b0f644da3e22c2f616f5c728024193a582dabfe.jpg" } }