[!NOTE] This article approaches malware analysis from an offensive perspective: analyzing your own tools to understand how defenders and EDR solutions perceive them.

The best Red Team operators are often competent Reverse Engineers. Why? Because you cannot bypass a control you do not understand. If you compile a payload, throw it at a target, and it gets blocked, you need to know why. Was it the file signature? The Import Address Table (IAT)? A heuristic behavior trigger?

To build better malware, you must disassemble malware. This guide covers the basics of static and dynamic analysis to help you “self-audit” your payloads before they ever touch a customer’s disk.

Static Analysis: The “At Rest” View

Static analysis examines the file without executing it. This is the first line of defense for Antivirus (AV) and EDR.

1. The PE Header & Metadata

The Portable Executable (PE) header contains the roadmap for the OS loader.

  • TimeDateStamp: Is it from 1992 or 2099? Anomalous timestamps are a red flag.
  • Rich Header: Contains meta-information about the compiler (Visual Studio version). Attackers often strip this, but absence of a Rich Header can also be suspicious.
  • Sections: Standard sections are .text (code), .data (variables), .rsrc (resources). If you see sections named randomly or standard sections with non-standard permissions (e.g., a .text section that is Writable and Executable RWX), that screams “shellcode injection.”

2. Imports and the IAT

The Import Address Table (IAT) is a list of API functions the executable needs from the OS.

  • Suspicious Imports: A simple “Notepad” clone shouldn’t be importing VirtualAllocEx, WriteProcessMemory, or CreateRemoteThread. These are classic injection markers.
  • Missing Imports: If a complex tool has zero imports, it is likely packed or acting as a simple loader for shellcode.

[!TIP] Offensive Countermeasure: Use API Hashing or Dynamic Resolution (GetProcAddress) to hide your imports. Keep your IAT clean or innocuous.

3. Strings

strings.exe never lies. If your payload contains plain text IP addresses (192.168.1.5), URLs (http://evil.com/beacon), or error messages (Error injecting shellcode), you have failed basic OPSEC.

  • PDB Paths: Debug symbols often leak usernames: C:\Users\xX_Hacker_Xx\Projects\BestMalware\Release\beacon.pdb.

4. Entropy

Entropy measures randomness on a scale of 0 to 8.

  • Standard Code: ~4.0 - 6.0
  • Packed/Encrypted Code: ~7.5 - 8.0 High entropy indicates that data is compressed or encrypted. EDRs hate high entropy because they can’t see inside. “Packing” a binary (using UPX or custom packers) is often a guarantee of detection, not evasion.

Tools for Static Analysis:

  • PEStudio: The gold standard for initial triage.
  • Capa: Mandiant’s tool that detects capabilities (e.g., “contains logic to parse HTTP”).
  • Strings: Sysinternals classic.

Dynamic Analysis: The “Behavioral” View

Dynamic analysis involves running the malware in a controlled environment (sandbox) to watch what it does.

1. API Monitoring (Hooking)

EDRs inject their own DLLs into every running process (Userland Hooking) to intercept API calls.

  • The Hook: When you call CreateFile, the EDR sees arguments, context, and the return address.
  • The Check: If powershell.exe tries to access lsass.exe memory, the hook triggers an alert.

2. Network Activity

Sandboxes look for:

  • DNS Requests: Looking up domains (DGA or oddly named).
  • HTTP Traffic: Beaconing intervals (jitter).
  • Non-Standard Ports: traffic on 4444 or 8080.

3. Persistence Mechanisms

  • Registry Keys: Run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run).
  • Services: Creating new services.
  • Scheduled Tasks: A common persistence method.

Tools for Dynamic Analysis:

The Feedback Loop

As a Red Teamer, your development lifecycle should look like this:

  1. Develop: Write your tool/payload.
  2. Audit (Static): Run clean-up. Remove PDB paths. Encrypt strings. Check IAT. Measure Entropy.
  3. Audit (Dynamic): Run in a local VM with ProcMon. Does it touch files you didn’t expect? Does it crash?
  4. Test: Run against a dev/lab instance of the target EDR.
  5. Deploy: Only now is it ready for the engagement.

Conclusion

Malware analysis is simply Reverse Engineering applied to malicious code. By learning the techniques of the Blue Team, you improve the quality of your Red Team tradecraft. Don’t just rely on pre-compiled tools from GitHub. Analyze them. Understand them. Modify them. Own them.

UncleSp1d3r