Notes from Lenny Zeltser's Practical Malware Analysis Essential for Incident Responders

In Lenny Zeltser's presentation (full video linked below), Practical Malware Analysis Essential for Incident Responders at the RSA Conference 2019, he highlighted key aspects of malware analysis that can greatly aid incident responders. The goal is to understand what we can discover while analysing malware:

• Is the file a threat?
• What are the file’s capabilities?
• How can we detect this in the future?
• What does the file reveal about the adversary?

To conduct effective malware analysis, we need to consider the stages involved. From easiest to hardest, they are:

1. Fully-automated analysis
2. Static properties analysis
3. Interactive behaviour analysis
4. Manual code reversing

Fully-automated Analysis

Fully-automated analysis is the initial step, where we use sandboxes such as Hybrid Analysis or Cuckoo Sandbox to run the malware and observe its behaviour automatically. However, modern malware has become sophisticated enough to recognise when it is being executed in such controlled environments. As a result, malware may not execute or behave differently when run in a sandbox because it detects the analysis environment. This can also occur if the malware determines it is running on a virtual machine (VM), based on factors like current processes, and thus avoids execution to prevent analysis.

Static Properties Analysis

The next stage is static properties analysis. Lenny praised PEStudio as an excellent tool for understanding more about a malware sample without executing it. PEStudio provides a list of artifacts such as:

• Hashes
• Strings
• Libraries
• Imports

In PEStudio, you can also check the file against the VirusTotal database through its VirusTotal tab. If PEStudio isn't connected to VirusTotal, you can manually check the file’s hash on the VirusTotal website.

Strings: Examining strings in a program can reveal insightful information, but often, malware obfuscates strings using encoding schemes like Base64. If strings appear unreadable, this raises suspicion.

Libraries/Imports: Typically, malware will have a few libraries and a long list of imported functions. If this is not the case in your analysis, it might indicate something unusual. For instance, Lenny highlighted the 'VirtualAlloc' import in his example, which raises concerns as it is used to request additional memory, often associated with packing, where the malware is compressed to avoid detection.

Indicators of Compromise (IOCs)/Signatures: Identifying IOCs is crucial for determining if other systems are infected. Look for:

• Hashes
• Registry keys used for persistence
• C2 (Command and Control) server domain names

Initial Behaviour Analysis

Following static analysis, we conduct initial behaviour analysis. This involves observing the malware’s actions in a controlled environment, using tools like Process Hacker, Process Monitor, or ProcDOT on a Windows machine, while Wireshark can be used on a Linux system to monitor network activity.

Steps:

1. Set up the environment: Prepare the necessary tools, such as Process Monitor, Process Hacker, and Wireshark.
2. Clear logs and start recording: Reset the logs in Process Monitor and begin recording.
3. Execute the malware: Run the malware sample and allow it to operate for a while to observe any malicious activity. To further conceal the analysis environment, Lenny recommends opening and closing applications like File Explorer or Notepad to simulate typical user behaviour.

Wireshark: Use Wireshark to monitor network traffic and look for unusual IP addresses or connections. Investigate these IPs further using tools like VirusTotal.

Process Monitor: After stopping the data logging in Process Monitor, export the data as a CSV file. You can load this CSV into Excel and filter columns to identify anything suspicious. Use ProcDOT to clean and visualise the logs.

Process Hacker: Run this tool alongside the malware to observe changes upon execution. For example, Lenny noted that in his demonstration, javaw.exe started running and turned purple in Process Hacker, indicating that the process had unpacked itself, which suggests potential malicious activity. Process Hacker can also extract strings from memory space. In Lenny's case, a suspicious IP (previously seen in Wireshark) was found, along with a URL and URI, providing further insight into the malware and potentially identifying the malware family.

Analysing Handles

Handles are crucial when examining how a process interacts with other processes or registry keys. When a process requires access to these elements, it creates a handle. A particular focus should be on mutant handles, which, although used in legitimate software, can also indicate potentially malicious activity. These handles, among other functions, can help reduce CPU usage spikes, which allows malware to remain stealthy. More on mutex handles can be found at: https://www.sans.org/blog/looking-at-mutex-objects-for-malware-discovery-indicators-of-compromise/

Original Presentation can be found on YouTube below: