In the past, especially learnt from
SANS FOR610
, I use many tools in performing behavioural analysis of malware. It is good to have all kinds of
tools
available in my tailor made virtual machine, but sometimes these tools may create lot of noises that interfere the other tools. My current favour is to install only limited tools to perform a detail behavioural analysis. Here are my current picks:
If I can only pick one tool out of the above named, Process Monitor should be my best choice.
In the past month, I have been asked to give lectures to local university students about malware analysis, especially give introduction to them about the usage of these tools in performing behavioural analysis. Hence, I reread the tool's documentations and try using their functions for my training materials. I tested run all of them on some malware. The results are good for detecting most of malicious activities, especially the interactive graph generated by ProcDot from the log captured by Process Monitor. It shortened in many analysis processes and I don’t need to making use of Lenny's filters and highlights to identify the key activities of these malicious processes (actually, I am quite enjoy in reading through millions of Process Monitor log for identifying what had the malware performed).
However, I always want to see if I can identify a possible process injection by using these tools. I do have a strong feeling that the Process Monitor can show something because ProcDot sometimes show me a new thread was created from a legitimate process, such as Winlogon or Explorer.exe. I re-read the whole chapter in Windows Sysinternals Administrator Reference (the “ Book ”) and found no clear hint (of course, the book provides many good tips and mentioned on a topic of how to detect buffer overflow)
In order to verify my assumption, I found two malware, Zeus and Poison Ivy, then run them in a VM. I go through the Process Monitor logs (millions of records…) I found the answer is contained inside the Stack tab of the Event Properties.
According to the Book, the Stack tab “displays the thread call stack when the event was recorded. Each row represents one stack frame, which consists of:
After such encouraging findings, I checked the Stack Summary of Poison Ivy. I had performed a detailed code analysis of an APT sample, which dropped Poison Ivy RAT as its weapon for espionage. I know this sample will first inject itself to svchost.exe, then performed a second injection to explorer.exe and then performed a final injection to IExplorer.exe. (It is a multistage malware). I checked my OllyDbg log again and found in the stage 3 injection (i.e. the explorer.exe injection) the malicious code was injected and executed at virtual address space around ox150000. (Fig. 2)
I reopened the Process Monitor log ( here ) and checked the Stack Summary of IExplorer.exe. (Fig. 3) When I expand the injected iexplorer.exe call stack, I found couple stack frames were called at the virtual address around the same section of ox150000.
This interesting findings indicate we can identify possible code injection activities by checking the Process Monitor’s Stack frames.
- FileAlyzer: to perform a basic code check, aka “basic static analysis” mentioned by the book, Practical Malware Analysis
- PEStudio: a malware PE parser that can provide you helpful IOCs
- FakeNet: to answer fakeDNS and simulate all well know network requests (don’t forget to configure it to dumpoutput)
- CaptureBAT: a tool that captures process, registry, file system and network activities on a Windows host
- Autoruns: a Sysinternal tool for identifying malware’s persistence mechanism
- Process Monitor: a Sysinternal tool that shows real-time file system, registry and process/thread activities
- ProcDot: a visualization tool to plot the process monitor log and pcap capture as an interactive graph
If I can only pick one tool out of the above named, Process Monitor should be my best choice.
In the past month, I have been asked to give lectures to local university students about malware analysis, especially give introduction to them about the usage of these tools in performing behavioural analysis. Hence, I reread the tool's documentations and try using their functions for my training materials. I tested run all of them on some malware. The results are good for detecting most of malicious activities, especially the interactive graph generated by ProcDot from the log captured by Process Monitor. It shortened in many analysis processes and I don’t need to making use of Lenny's filters and highlights to identify the key activities of these malicious processes (actually, I am quite enjoy in reading through millions of Process Monitor log for identifying what had the malware performed).
However, I always want to see if I can identify a possible process injection by using these tools. I do have a strong feeling that the Process Monitor can show something because ProcDot sometimes show me a new thread was created from a legitimate process, such as Winlogon or Explorer.exe. I re-read the whole chapter in Windows Sysinternals Administrator Reference (the “ Book ”) and found no clear hint (of course, the book provides many good tips and mentioned on a topic of how to detect buffer overflow)
In order to verify my assumption, I found two malware, Zeus and Poison Ivy, then run them in a VM. I go through the Process Monitor logs (millions of records…) I found the answer is contained inside the Stack tab of the Event Properties.
According to the Book, the Stack tab “displays the thread call stack when the event was recorded. Each row represents one stack frame, which consists of:
- Frame with frame number (K for kernel-mode and U for user-mode)
- Module with the name of the file containing the code
- Location with the specific location within the module where the code is executing. If symbols are available, … the offset from the beginning of the location…)
- Address with the virtual address space of the executing process
- Path with the full path of the file identified"
(Fig. 1 Stack Summary of Zeus)
After such encouraging findings, I checked the Stack Summary of Poison Ivy. I had performed a detailed code analysis of an APT sample, which dropped Poison Ivy RAT as its weapon for espionage. I know this sample will first inject itself to svchost.exe, then performed a second injection to explorer.exe and then performed a final injection to IExplorer.exe. (It is a multistage malware). I checked my OllyDbg log again and found in the stage 3 injection (i.e. the explorer.exe injection) the malicious code was injected and executed at virtual address space around ox150000. (Fig. 2)
(Fig 2. my code analysis log during debugging)
I reopened the Process Monitor log ( here ) and checked the Stack Summary of IExplorer.exe. (Fig. 3) When I expand the injected iexplorer.exe call stack, I found couple stack frames were called at the virtual address around the same section of ox150000.
(Fig 3. Stack Summary of Poison Ivy)
This interesting findings indicate we can identify possible code injection activities by checking the Process Monitor’s Stack frames.
