Suppose I am doing malware analysis. How can I recognize if, during the analysis process, a piece of malware dropped a file in my system, and if so, the path of the file?

What are the procedures, apart from using sandboxes? I mean how can I do this manually?

  • 2
    That would be completely dependent on which malware. Usually malware tries to hide its files. Sep 21, 2012 at 11:23
  • Are you asking, what is the typical generic process used to investigate malware, in general (i.e. a "forensic" methodology)...? If so, it does sound as perhaps a bit wide and open-ended. Can you narrow your question?
    – AviD
    Sep 23, 2012 at 16:01
  • Polynomial answer was perfect
    – n1kita
    Sep 24, 2012 at 7:59

3 Answers 3


There are generally three ways:

  1. Sandboxing (which you said you don't want to do)
  2. Tools like Process Monitor can display all file and registry activity on the system, but this approach is limited - rootkits would hide the changes, or the malware might notice procmon and change its behaviour.
  3. Snapshot comparison. Take a snapshot of the filesystem, then run the malware, then take another snapshot and compare them. You'll be able to see what files were created and changed.

Even though this is an older question, I believe this will be relevant and added value. So, here it goes.

Assuming an NTFS file system, the $UsnJrnl and $Logfile record changes made to the file system. File creation can be detected through these artifacts. There are many articles online that explain this process and the tools better than I can. However, I will say that because these files are used internally by the NTFS file system, you will need specialized tools to gain access to them. One free option is FTK Imager (full install) or FTK Imager Lite (portable executable).


Here are a few articles explaining these artifacts, their value, and how to parse them:








Use an API Monitor. I suggest : http://www.rohitab.com/apimonitor which is a splendid piece of software and will be useful to monitor what you ask. Simply look for CreateFile() WINAPI call. This is of course assuming that the malware uses CreateFile() function to create the file. If it does not, then you might have to look at some other functions. What happens next is that, whenever the malware calls the function, the parameters that are passed to that function are shown on the right frame. With this you can determine the file that was dropped, since the call to CreateFile() contains the path.

P.S: I would advise you to use a debugger to step through the calls one by one and monitor it on API monitor. There is a slight learning curve when using API monitor, but if you do this a lot, its worth the time spent !

Reference: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx

  • API monitors can only identify user-mode calls. If a kernel exploit is utilised, it can drop a rootkit and you'll never know. Plus you have to have a process on the test box, so the malware might identify it and change its behaviour.
    – Polynomial
    Sep 21, 2012 at 15:23
  • Wouldn't you say atleast 50% of malware in existence today relies on dropping plain old files into system folders with the use of user-mode calls ? In that case, API monitor would be helpful. But I haven't considered your scenario, API monitor wont work in that case.
    – sudhacker
    Sep 21, 2012 at 15:36
  • Possibly. But the second part of the scenario is the important point - you have to run a process on the box, which the malware can detect and either kill or work around.
    – Polynomial
    Sep 21, 2012 at 17:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .