Look Ma, No IDA! Malware Analysis Without Reverse Engineering

The talk challenges the idea that malware analysis must start with reverse engineering. The speaker argues that disassembly is the most conclusive method but also the slowest, and that many goals, such as naming a malware family or pulling indicators across a network, do not require it. Because many common threats use scripting languages rather than compiled code, assembly is often the wrong starting point.

The middle section covers foundations that responders and intel analysts often already have: knowing what each tool reports and where it fails, picking one scripting language, and reading basic file properties such as signers, section names, and entropy. It then shows how familiar work, like EDR telemetry or sandbox output, leads naturally into malware analysis. Tools covered include YARA, FLOSS for strings, CyberChef recipes, and AssemblyLine. Three case studies follow: an obfuscated JavaScript file, a .NET sample tied to AsyncRAT through configuration extraction and code comparison, and corroboration across online databases and sandboxes.

The closing points stress caution. Sandboxes can miss commands a remote access trojan receives later, or behavior gated behind arguments and anti-analysis checks, and capability tools report behaviors without explaining intent. Analysts should record which tool or rule supports each conclusion. A disassembler becomes necessary when anti-analysis blocks progress or attribution depends on software design.