Hey folks, Sedat here. If your coffee is ready, we’re going to swim in some 'dangerous' waters today—but we won’t forget to bring our life jackets (sandboxes) along.
Back in the day, everything in the cybersecurity world was much more linear. A file would arrive, you’d check its hash (MD5/SHA256), and if it was flagged as 'malicious' in the database, you’d kick it out. Done, right? Nope. Nowadays, no one trusts simple 8-character passwords, but what about complex 16-character ones? If even those aren't enough on their own anymore, how logical is it to call a file 'safe' just by looking at its name or hash value?
Today, polymorphic structures, obfuscation techniques, and 'Living Off The Land' (attacking using system tools) methods used by attackers—whether they are our friends on the red team or actual threat actors—push us defenders deeper into the world of Malware Analysis. Let’s dissect this beast through a case simulation we encountered at testCompany.
1. Static Analysis: Taking an X-Ray
The first rule when analyzing a file is this: Never double-click immediately. Static analysis is the art of examining the file’s code, structure, internal strings, and imported libraries without actually executing it. Think of it like using an X-ray machine to look inside a bomb before trying to defuse it.
One of the first places we look is the Strings—literal text sequences. No matter how much a malware author tries to hide their code, they sometimes forget to clean up IP addresses, file paths, or error messages.
Example (Defanged): When examining a PE (Portable Executable) file, we might see output similar to this:
http[://]example[.]com/api/v1/collect
C:\Windows\System32\drivers\etc\hosts
cmd.exe /c powershell.exe -ExecutionPolicy Bypass -File ...
CreateRemoteThread
WriteProcessMemory
If we see API functions like CreateRemoteThread and WriteProcessMemory, our suspicion should rise. This guy is likely trying to inject code into another process.
2. Dynamic Analysis: Controlled Explosion
Sometimes static analysis isn't enough because the code might be 'packed'—meaning it's compressed or encrypted. In this case, we need to run the file in an isolated environment (Sandbox). But watch out! Modern malware is 'smart' now. If they realize they’re in a virtual machine (VM)—for instance, if the CPU core count is low or the graphics drivers are standard VM drivers—they won't show any malicious activity.
To monitor a malware's behavior on the network, we use tools like Wireshark or FakeNet-NG.
Mock Dynamic Analysis Scenario:
The moment the malware runs, is it sending a 'beacon' to 127.0.0.1 (in reality, hxxp[://]malicious-site[.]com)? Does it add itself under the Run key in the Registry?
# Checking registry persistence (Mock)
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Run