Analyzing the Antivirus Evasion Tactics Hidden Within Asgard Malware Protector    

Chapter 1: TTP #1 — Hiding in Plain Sight with Dynamic API Resolution

The first and most fundamental evasion technique is to hide the malware's true capabilities from static analysis. A simple tool can look at a program's Import Address Table (IAT) to see the Windows functions it uses. If it sees `CreateRemoteThread` or `WriteProcessMemory`, it's an immediate red flag.

Asgard avoids this by using **Dynamic API Resolution**. It does not link to these dangerous functions at compile time. Instead, at runtime, it programmatically finds the base address of `kernel32.dll` in memory, parses its export table to find the address of the `GetProcAddress` function, and then uses that to find the addresses of all the other dangerous functions it needs. To a static analysis tool, the malware looks benign because none of its malicious capabilities are explicitly declared.

Chapter 2: TTP #2 — Blinding the Analyst with String Encryption

A malware analyst often starts by running the `strings` command on a binary to look for clues like C2 domains, filenames, or registry keys. The Asgard binary is packed with a custom encryption routine. All critical strings—including C2 server hostnames, names of processes to inject into, and mutex names—are stored in an encrypted format. The program only decrypts a string in memory for the few milliseconds it is needed, and then immediately erases it. This blinds a simple static analysis and forces the researcher to perform a much more time-consuming dynamic analysis in a debugger to uncover the malware's true intent.

Chapter 3: TTP #3 — Outsmarting the Sandbox with Evasion Checks

To defeat automated analysis, Asgard is packed with anti-sandbox and anti-VM checks. Before executing its main payload, it performs a series of checks on its environment:

• **Hardware Checks:** It queries for the MAC address of the network card, looking for prefixes belonging to VMware or VirtualBox.
• **Username/Hostname Checks:** It checks for common sandbox usernames like "admin," "test," or "sandbox."
• **Timing Checks:** It uses timing-based evasion, measuring the time it takes to perform a certain number of operations. In a sandboxed environment, which often has CPU emulation overhead, this can take longer than on bare metal.

If any of these checks fail, the program immediately terminates or enters a benign, infinite loop, fooling the sandbox into thinking it is harmless.

Chapter 4: The Defender's Playbook — Hunting the Behavior, Not the Signature

These three techniques make it clear that a defense based on file signatures (IOCs) is useless against a modern, evasive threat. The only way to win is to move up the stack and detect the malicious *behavior* (**IOAs**).

This requires a modern **Endpoint Detection and Response (EDR)** platform.

How to Hunt These TTPs:

• **Hunt for API Resolution:** Your EDR should be able to log or alert on a process that is manually walking the PEB to find DLLs or using `GetProcAddress` to resolve sensitive APIs.
• **Hunt with Memory Scanning:** An advanced EDR can periodically scan the memory of running processes. This is the only way to find the decrypted C2 strings or other indicators that the malware tries to hide.
• **Hunt for Sandbox Evasion:** The evasion checks themselves are a powerful Indicator of Attack. A legitimate program has no reason to check if it's running in a VM. An EDR can be configured to alert on any process that makes these suspicious environmental queries.