Amadey Malware: A Comparative Study of Static Detection vs Memory-Based Detection

PDF

• Open (new tab): /files/Memory_Doesn_t_Lie.pdf

If the PDF does not render, open it here: /files/Memory_Doesn_t_Lie.pdf

Related Video

Structural Differences Between Static Detection and Memory-Based Detection

Static detection analyzes the malware file on disk and identifies it using known patterns or signatures. For example, antivirus engines compare unique byte signatures or strings in a malicious binary against a database. However, modern malware such as Amadey evades static signature detection by encrypting or obfuscating files. In Amadey, strings inside the payload are double-encoded (custom encoding + Base64), making static analysis and detection difficult.[1] Static detection is weak against malware wrapped by packers or encryption, and reliance on file hashes or fixed signatures makes it difficult to catch polymorphic variants.[2][3] In practice, Amadey is distributed in many obfuscated variants as MaaS, and surface-level hashes or string signatures can miss variants.

By contrast, memory-based detection directly scans process memory at runtime to identify malicious behavior. It captures the real payload revealed when malware decrypts itself or is loaded into another process. For example, polymorphic malware eventually appears in memory as decrypted code at execution time, so memory forensics can bypass obfuscation and expose the true payload.[4] Memory detection can also catch code injection or process hollowing. If malware spawns a legitimate process and replaces its memory image (process hollowing), the disk contains only a benign file, making static detection ineffective. Memory-based detection, however, can compare the in-memory image with the on-disk image to find inconsistencies and spot code replacement artifacts.[5] In short, static detection focuses on what the file looks like, while memory detection focuses on what the process actually does at runtime.[4][6]

To summarize, static detection is fast and efficient but weak against packing and obfuscation, while memory detection is more resource intensive but captures the real malware revealed at runtime, making evasion harder. This is especially effective against loader or dropper families that unpack in memory (e.g., Amadey, SmokeLoader).[4]

Runtime Invariants in Memory and Why Evasion Is Hard

A malware runtime invariant is a core code or data pattern that must exist to perform malicious actions, even across variants or obfuscation. It reflects a shared algorithmic signature that attackers can change at the file level but cannot avoid at execution time. In Amadey, command strings are decrypted for C2 communication, and multiple fixed 32-byte hex strings used as decryption keys appear in memory.[7] The binary also contains a likely developer path string, "\Amadey\Release\Amadey.pdb", which can still surface in memory after repacking.[8] These artifacts are encrypted at rest, but must be decrypted at runtime, so memory analysis can capture them.

Such runtime invariants reflect fundamental behavior that is hard to replace.[9] For example, in ransomware, no matter how the code changes, file encryption routines and key output remain invariant.[9] Similarly, infostealers must access browser cookies and account data, so strings like “cookies.sqlite” or “installedBrowsers” inevitably appear in memory.[10] Memory analysis of a RedLine variant found common strings such as DownloadAndExecuteUpdate, StringDecrypt, ChromeGetRoamingName, and SystemInfoHelper, indicating persistent behavior across variants.[10] Unless attackers rewrite the core logic every time, these strings and API patterns remain detectable in memory.

Why these invariants are hard to evade boils down to two factors. First, functional constraints: the malware’s objectives (e.g., Amadey’s system info collection and C2 communication) are fixed, so the core logic and data structures remain partly unchanged.[9] Second, cost: removing invariants would require metamorphic engines that fully transform code on each execution, or JIT compiler or interpreter approaches that generate code in real time.[11][12] These techniques are extremely complex and introduce significant runtime overhead. Even simple operations would need random re-implementation each time, increasing resource use and the risk of errors.[13] Most malware, especially MaaS families like Amadey or RedLine, reuses core logic for development efficiency. Emotet, for example, generated thousands of variants daily but kept similar behavior, relying mainly on polymorphic packing rather than deep payload redesign.[3][14] In short, removing invariants costs more than it yields, so stable memory patterns remain and can be used as long-lived detection anchors.

Technical example: A memory dump analysis of an Amadey variant revealed distinct function call sequences. The following x86 instruction flow is a consistent routine in Amadey:

// Example code sequence extracted from an Amadey memory dump
$sequence_0 = { 89 45 F4 83 7D F4 08 74 4F 8D 85 E8 FD FF FF 89 04 24 E8 ?? ?? ?? ?? C7 04 24 ?? ?? ?? ?? }

Disassembling the sequence reveals logic that compares a local variable, branches, allocates a buffer, and calls a function (e.g., mov [ebp-0xC], eax; cmp [ebp-0xC], 8; je …; lea eax, [ebp-0x218]; …).[15] Even complex byte sequences represent specific functional logic, and Amadey variants show similar control flow patterns that can be used for detection.[16][17] Evading this would require a core algorithm rewrite, which hurts reliability and raises development cost. Thus runtime invariants in memory are an unavoidable weakness for attackers.

YARA Rules: Efficiency and Generalization of Memory-Based Detection

Manual memory detection is difficult, which is why YARA is widely used for pattern matching. YARA defines text or binary patterns to identify malware families, and it can be applied to memory dumps or process memory as well as static files.[4][18] Because YARA uses generalized patterns rather than hashes, it is well suited for invariant-based detection against polymorphic variants.[9]

Efficiency of memory-based YARA detection is often demonstrated as high detection rate and low false positives. A well-designed YARA rule can identify many samples within a malware family.[9] For example, CloudSEK published an Amadey detection rule that checks the “MZ” header and then looks for Amadey-specific PDB path strings or decryption key patterns, enabling detection across variants once unpacked.[7][19] This is a static rule in form but effectively targets core identity elements (module name and key patterns), which act as invariants. Tools like YARA-Signator can also auto-extract unique byte sequences from memory dumps or unpacked files to generate YARA rules.[20] These rules can include API calls, control flow patterns, and constant references, making them hard to evade with simple byte substitutions.[[15]][21] YARA-Signator based Amadey rules include multiple 5-7 instruction sequences as strings, reused across variants as unique signatures.[16][22]

In terms of generalization, memory-based detection depends on how universal the extracted invariant is. If a rule is tied too closely to one sample, minor changes can break detection. YARA-Signator’s author notes that rules generated from a single Malpedia sample may have limited generality.[23] implying ongoing updates and validation are necessary. In practice, memory YARA design often compares multiple variant memory dumps to extract shared patterns or selects combined string and code signatures tied to behavior to maximize coverage. Fortunately, commercial malware like Amadey and RedLine usually retains stable core logic, so one or two rules can cover many variants.[9] For example, a RedLine YARA rule classifies malware when 6 of 8 strings match, combining path strings, function names, protocols, and database filenames to reduce false positives while detecting most variants.[10][24]

Overgeneralization can increase false positives, so memory YARA often includes process context conditions or size constraints. For example, Mandiant’s memory-only downloader PEAKLIGHT rule triggers only if 4 of 7 PowerShell-like patterns are present and script size is under 10 KB.[25][26] These added conditions make generalized patterns fire only in malicious scenarios, improving precision.

The table below summarizes the comparison:

As the table shows, static detection is easy to evade even with simple string encoding,[1] while memory detection requires fundamental algorithm changes, raising evasion difficulty. As a result, memory-based detection using YARA is effective and generalizable for modern malware defense, and many security vendors use sandbox execution plus memory scanning to classify malware families.[4][27]

Memory Convergence Across Malware Families (Amadey vs RedLine vs FormBook vs SmokeLoader)

Now let’s examine whether other malware families also show memory convergence (shared runtime patterns) beyond Amadey. Memory convergence refers to different variants ending up with similar shapes or behaviors in memory. This usually reflects shared malicious objectives within a family.

• Amadey (trojan/loader) - As discussed, string decryption routines, key patterns, mutex creation, and C2 thread creation code appear consistently in memory.[7][28] As a MaaS botnet, Amadey collects system info and downloads additional payloads, so HTTP POST routines that send OS version and usernames are consistently present across variants.[29][30] The network communication structure and string decoding show strong memory convergence.

• RedLine (infostealer) - A widely sold infostealer that steals browser passwords, autofill data, and crypto wallets.[31] RedLine is often written in .NET and obfuscated, but memory reveals browser profile paths, SQLite cookie DB paths (“cookies.sqlite”), and target application lists in plaintext.[32] It also contains hardcoded FTP/IM client names and wallet keywords, which remain invariant in memory. Because targets and methods are similar across versions, memory convergence is high and a single YARA rule can detect many variants.[33]

• FormBook (infostealer/loader) - Known for process injection and its unique RunPE crypter called “Babushka Crypter.”[34] It encrypts payloads in multiple layers and then executes them inside another process’s memory, leaving consistent injection patterns. The flow of CreateProcess, writing PE headers and sections, then jumping to OEP is invariant. This can be detected through API call patterns (e.g., VirtualAllocEx, WriteProcessMemory, SetThreadContext, ResumeThread) and is often reflected in FormBook detection YARA rules.[34] In short, despite multilayer encryption, memory-level injection behavior converges.

• SmokeLoader (loader) - Active since 2011, SmokeLoader uses minimal on-disk footprint and in-memory loading. Recent variants use a “stager” module that obfuscates itself and then injects the main payload into explorer.exe.[35] In memory, you consistently find modules loaded in explorer that do not exist on disk. Memory forensics can detect abnormal loaded code regions. SmokeLoader also performs persistence (registry Run keys), beaconing to C2, and loading extra modules.[36] These behaviors show convergent API call sequences (e.g., startup copy, periodic remote contact). After a 2024 takedown, SmokeLoader returned in 2025 with protocol tweaks but core logic intact,[37] which means memory-based detection rules can still be effective.

Taken together, Amadey, RedLine, FormBook, and SmokeLoader show that even with different distribution methods or implementations, core malicious behavior converges in memory. This means that once a memory-based detection strategy is built for a family, it can be extended across variants and sometimes across similar families. For example, generalized YARA rules for loader behavior (process hollowing, code injection patterns) can catch new loader malware with reasonable coverage. Invariant-focused memory detection can enable cross-family detection and supports more generalized defense.[9]

Attacker Evasion Attempts and Their Costs (Performance and Development Complexity)

Because memory-based detection is effective, attackers may try to neutralize it, but such attempts carry significant cost. Key evasion approaches and their limits include:

• Metamorphic code transformation - Attackers can add metamorphic engines to reconstruct code on each execution. For example, they can implement the same behavior using different instructions and orderings,[12] randomize register usage, and insert junk code. This changes memory-level byte patterns, making fixed YARA signatures less reliable. However, this is the most complex approach. Generating functionally equivalent code paths requires compiler-grade logic, and bugs or crashes are common.[11][38] Ensuring correctness is difficult and can trigger new AV detections. Maintaining such a system is expensive, and historically only high-end malware or APTs have used it.[3][39]

• Continuous code encrypt/decrypt (in-memory encryption) - Another method is to keep code encrypted in memory and decrypt only briefly when needed, then erase or re-encrypt. This can reduce detection windows but introduces significant performance costs. Frequent encryption/decryption increases CPU usage and slows execution, while constant memory changes increase instability. EDRs also track memory allocation and protection changes, so frequent RWX region flips can raise alerts. This approach makes malware slower and more fragile without guaranteeing evasion.

• Execution inside a VM or interpreter - Advanced attackers may convert payloads into custom VM bytecode and run them via an in-memory interpreter. In that case, only the interpreter is visible, and the payload logic is hidden. However, the interpreter itself becomes a new signature. A large VM engine in memory is unusual and can be detected. If reverse engineered, defenders can produce stronger signatures. This approach also adds execution overhead, and building and maintaining a custom VM is costly.

• Other evasion tactics - Some anti-memory-scan techniques include pretending to be a debugger to block OpenProcess, or manipulating page permissions to crash scanners. These can interfere with normal operation and can be bypassed by API hooking or kernel-level EDR. Attackers generally settle for stronger packing and frequent variant churn to shorten static IOC lifetimes.[40][41] Few attackers invest in full memory evasion, and when they do, the tradeoff is steep.

In conclusion, fully evading memory-based detection requires massive development complexity and operational instability. This favors defenders: invariant-based memory detection is hard to neutralize quickly, and any attacker response shifts cost and risk onto the attacker. If Amadey developers were to rewrite core code to avoid detection, their service continuity would suffer and the changes would likely be noticed by the security community. Therefore, memory-based detection is a durable defensive approach. In practice, layered security combines static, dynamic, behavioral, and memory forensics to improve coverage against new threats.[42][43] As the Amadey case shows, memory does not lie, and that truth is a powerful key for defenders.

References

• 【1】 Splunk Threat Research Team - “Amadey Threat Analysis and Detections” (2023)[1][29]

• 【6】 CloudSEK Research - “Amadey with AV Disabler drops RedLine - YARA rules” (2023)[7][20]

• 【11】 InventiveHQ - “Why Hash Lookup Fails Against Polymorphic Malware (Memory-Based Detection)” (2026)[4][5]

• 【13】 InventiveHQ - Same source as above[4][44]

• 【29】 Amr Ashraf - “RedLine Stealer Analysis - YARA rule” (2023)[32][33]

• 【14】 Malpedia - “Formbook - unique RunPE crypter behavior”[34]

• 【34】 TheHackerNews - “SmokeLoader Returns with New Changes” (2025)[35][37]