# Static Malware Analysis: Methodology Before we dive in, remember - there's no "*right*" way to do this. Everyone develops their own style of analysis, kind of like how every detective has their own way of solving cases. Think of this guide as your starter kit - you'll develop your own favourite techniques as you go along! Static analysis is the foundation of malware reverse engineering - it's where we begin to understand what makes malware tick without actually running it. Think of it as dissecting the code, examining its structure, and uncovering its potential behaviours, all while it sits harmlessly on disk. Whether you're analysing potential threats, developing signatures, or just curious about how malware works, mastering static analysis techniques is your first step into the fascinating world of malware research. ## The Detective's Toolkit First things first - you'll need some tools of the trade. Think of these as your detective's kit, each with its own special purpose: ### The Basic Tools (Your Magnifying Glass) - **PowerShell**: Before we dive into the deep end, PowerShell helps us get some quick intel about our sample. It's built right into Windows and perfect for those initial checks: ```powershell # Let's get those file hashes - they're like fingerprints for our files Get-FileHash malware_sample.exe -Algorithm SHA256 Get-FileHash malware_sample.exe -Algorithm MD5 ``` - **Strings/FLOSS**: These tools are brilliant for peeking at the text hidden inside our samples. FLOSS (from FireEye) is particularly clever - it can even spot strings that malware authors tried to hide: ```shell # Time to see what strings are hiding in our sample floss malware_sample.exe ``` - **PEView/PE Bear**: These are your go-to tools for cracking open PE files and seeing what makes them tick. Want to check out those headers, sections, and imports? These tools have got you covered. - **PEStudio**: This application is small but magic... It takes all those individual checks we'd normally do separately and bundles them into one neat package. It'll show you: - All those hashes we'd normally grab with PowerShell - Strings that might be hiding in the file, and flags the suspicious ones for you... always worth checking strings for yourself too - A really nice view of the Import Address Table (with helpful flags for suspicious APIs), remember we have great tools like https://malapi.io which can help us identify suspicious APIs. - Weird section headers that don't quite look right (you know, when you see something other than the usual .text, .data, or .rdata sections - if you're curious about what these sections normally look like, check out [[PE File Format Foundations]] and [[PE Files Going Deep]]). Want to really understand what those imports and exports are telling you? Pop over to [[Understanding Import & Export Tables]] - it's a real eye-opener! ### The Advanced Kit (Your CSI Lab) >[!tip] Remember to set up these tools in a safe environment! Check out [[Azure Malware Lab Design]] if you haven't built your secure lab yet. We don't want any escaped specimens! 🧪 Now we're getting into the heavy-duty tools. While some of these are often associated with dynamic analysis (actually running the code), they've got some brilliant features for static analysis too: - **IDA Pro/Ghidra**: These are your powerhouse disassemblers and decompilers. They'll help you: - Convert machine code back into assembly language - Generate function graphs to understand code flow - Identify and analyse code patterns without execution - Reveal potential code paths and logic structures Want to know more about reading the assembly code these tools generate? Pop over to [[Assembly Language Patterns]]! - **Hex Editors (HxD/010 Editor)**: Perfect for examining the raw binary content of files: - Spot patterns in the raw data - Look for embedded files or resources - Find encrypted or encoded content - Examine file structure anomalies They're particularly handy when working with custom file formats or when malware's trying to hide things in unusual places. - **Debuggers (x64dbg/WinDbg)**: While they're primarily dynamic analysis tools, they've got some great static analysis features: - View disassembled code without execution - Analyse PE headers and sections - Examine import/export tables - Map out function references Just remember - in static analysis, we're using these tools to look at the code, **not run it**! ## The Investigation Process ### Step 1: Getting the Basics (Starting your Report) First, let's get some basic info about our digital suspect: ```powershell # Getting those fingerprints... Get-FileHash malware.exe # SHA256 - the gold standard Get-FileHash -Algorithm MD5 malware.exe # Some old-school systems still use this ``` ### Step 2: Background Check Time to see if anyone else has encountered our suspect: - Check VirusTotal (like checking police records) - Look for existing analysis reports (has anyone else caught this perp?) - Browse [MITRE ATT&CK](https://attack.mitre.org/) (known criminal behaviours) ### Step 3: Interrogating the Strings This is where it gets fun! We're looking for anything the malware might be saying: - URLs (where's it planning to phone home?) - File paths (what's it trying to mess with?) - Error messages (what might make it fail?) - API calls (what Windows functions is it planning to use?) ### Step 4: The Deep Dive (PE Analysis) Now we're getting into the real forensics! Fire up PEView and let's look at: #### The ID Badge (Magic Numbers) Looking for those magic numbers in our Hex editor. <div style="font-family: monospace;"> <strong style="color: #A8B4F3;">4D 5A (MZ)</strong> - <span style="color: #F2CF85;"># That's our PE file signature!</span><br> <span style="color: #F2CF85;"># Think of it like the "Police Department" badge - if it's legit, it'll have this.</span> </div> #### The File's Story - **Compilation Time**: This timestamp can tell us when the sample was created - though don't take it at face value! Some interesting quirks to watch for: - Timestamps from the far future or distant past (definitely suspicious) - Always check for 1992 timestamps - this often indicates compilation with Borland Delphi - Some malware authors deliberately modify these timestamps to confuse analysts Remember, while compilation times can provide valuable insights, they're one of the easiest things for attackers to manipulate. - **Section Sizes**: If the Virtual Size is way bigger than Raw Data Size, our suspect might be wearing a disguise (packed) (check the .text header for this) #### The Company It Keeps (Import Analysis) Time to check out what [[Windows API Basics|Windows API]] functions it's planning to use: - File operations (planning to steal or encrypt files?) - Network activity (trying to phone home?) - Process manipulation (looking to hijack other programs?) ## Red Flags (Things That Make You Go "Hmm... 🤔") ### Suspicious Stuff to Watch For 1. **Weird Section Names** - Normal ones: .text, .data, .rdata (the law-abiding citizens) - Suspicious ones: random or gibberish names (the sketchy characters) 2. **Size Issues** - If Virtual Size is way bigger than Raw Size, something's hiding! - Unexpectedly large sections (is it smuggling something?) 3. **Suspicious API Imports** - Process injection (planning a jailbreak?) - Raw sockets (setting up secret communication channels?) - Crypto functions (planning to hold files for ransom?) ## Types of Evidence We're Looking For ### Host-Based Clues Think of these as fingerprints left on the victim's computer: - Registry changes (messing with Windows settings) - File operations (creating, deleting, encrypting) - Process shenanigans (creating new processes or injecting code) ### Potential Network Indicators >[!tip] Make note of any network indicators you find during static analysis - they'll help you configure your monitoring tools when you move to dynamic analysis! During static analysis, we can identify potential network indicators that might be used when the malware executes: - Embedded IP addresses or domains in the binary (strings will help us here) - URLs hidden in string references - Network-related API imports, particularly functions from: - `ws2_32.dll`: Look for raw socket operations like `socket()`, `connect()`, `send()`, `recv()` - `wininet.dll`: Internet functions like `InternetOpen()`, `InternetConnect()`, `HttpOpenRequest()` - `urlmon.dll`: URL functions like `URLDownloadToFile()` - `winhttp.dll`: HTTP functions like `WinHttpOpen()`, `WinHttpConnect()` - `iphlpapi.dll`: Network configuration functions like `GetAdaptersInfo()` - `mswsock.dll`: Extended socket functions - Encrypted or encoded network configurations Remember though - we won't see actual network traffic until we move to dynamic analysis. That's when tools in our [[Azure Malware Lab Flare|Flare VM]] and [[Azure Malware Lab REMnux|REMnux]] environments come into play: - Wireshark for packet analysis - TCPdump for network capture - INetSim for simulating network services ## Want to Level Up Your Skills? Ready to dive deeper? Check out: - [[PE File Format Foundations]] for the nitty-gritty of PE files - [[Windows API Malware Patterns]] to learn the tricks malware uses - [[Advanced Register Techniques]] when you're ready for the really technical stuff ## Pro Tips! 🌟 - Document everything - your future self will thank you! - Don't trust timestamps (malware authors are sneaky) - Look for patterns but expect surprises - When stuck, ask for help - even Sherlock had Watson! Remember, every analysis is like solving a new puzzle. Sometimes the pieces fit perfectly, sometimes they don't - and that's okay! The fun is in the investigation. 🔍 Keep at it! And if you run into anything particularly interesting, the cybersecurity community loves a good war story. 😉