admin管理员组

文章数量:1654384

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:

  • 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"
First I checked the Stack Summary of Zeus. I know my Zeus sample had executed a process injection on Winlogon.exe. The Stack summary (Fig. 1) shows many <unknown> thread frame entries which definitely need more attention.

 
(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.

本文标签： MonitorProcessidentifyInjectionCode

版权声明：本文标题：Using Process Monitor to identify possible code injection 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://m.elefans.com/dongtai/1729650763a1209011.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。