shows the table of contents for a PDF report generated by running a file through GFI Sandbox’s automated analysis. The malware report includes a variety of details on the malware, such as the network activity it performs, the files it creates, the results of scanning with VirusTotal, and so on., as follows:The Analysis Summary section lists static analysis information and a high-level overview of the dynamic analysis results.
The File Activity section lists files that are opened, created, or deleted for each process impacted by the malware.
The Created Mutexes section lists mutexes created by the malware.
The Registry Activity section lists changes to the registry.
The Network Activity section includes network activity spawned by the malware, including setting up a listening port or performing a DNS request.
The VirusTotal Results section lists the results of a VirusTotal scan of the malware.
Malware sandboxes do have a few major drawbacks. For example, the sandbox simply runs the executable, without command-line options. If the malware executable requires command-line options, it will not execute any code that runs only when an option is provided. In addition, if your subject malware is waiting for a command-and-control packet to be returned before launching a backdoor, the backdoor will not be launched in the sandbox.
The sandbox also may not record all events, because neither you nor the sandbox may wait long enough. For example, if the malware is set to sleep for a day before it performs malicious activity, you may miss that event. (Most sandboxes hook the Sleep function and set it to sleep only briefly, but there is more than one way to sleep, and the sandboxes cannot account for all of these.)
Other potential drawbacks include the following:
Malware often detects when it is running in a virtual machine, and if a virtual machine is detected, the malware might stop running or behave differently. Not all sandboxes take this issue into account.
Some malware requires the presence of certain registry keys or files on the system that might not be found in the sandbox. These might be required to contain legitimate data, such as commands or encryption keys.
If the malware is a DLL, certain exported functions will not be invoked properly, because a DLL will not run as easily as an executable.
The sandbox environment OS may not be correct for the malware. For example, the malware might crash on Windows XP but run correctly in Windows 7.
A sandbox cannot tell you what the malware does. It may report basic functionality, but it cannot tell you that the malware is a custom Security Accounts Manager (SAM) hash dump utility or an encrypted keylogging backdoor, for example. Those are conclusions that you must draw on your own.
The Analysis Summary section lists static analysis information and a high-level overview of the dynamic analysis results.
The File Activity section lists files that are opened, created, or deleted for each process impacted by the malware.
The Created Mutexes section lists mutexes created by the malware.
The Registry Activity section lists changes to the registry.
The Network Activity section includes network activity spawned by the malware, including setting up a listening port or performing a DNS request.
The VirusTotal Results section lists the results of a VirusTotal scan of the malware.
Malware sandboxes do have a few major drawbacks. For example, the sandbox simply runs the executable, without command-line options. If the malware executable requires command-line options, it will not execute any code that runs only when an option is provided. In addition, if your subject malware is waiting for a command-and-control packet to be returned before launching a backdoor, the backdoor will not be launched in the sandbox.
The sandbox also may not record all events, because neither you nor the sandbox may wait long enough. For example, if the malware is set to sleep for a day before it performs malicious activity, you may miss that event. (Most sandboxes hook the Sleep function and set it to sleep only briefly, but there is more than one way to sleep, and the sandboxes cannot account for all of these.)
Other potential drawbacks include the following:
Malware often detects when it is running in a virtual machine, and if a virtual machine is detected, the malware might stop running or behave differently. Not all sandboxes take this issue into account.
Some malware requires the presence of certain registry keys or files on the system that might not be found in the sandbox. These might be required to contain legitimate data, such as commands or encryption keys.
If the malware is a DLL, certain exported functions will not be invoked properly, because a DLL will not run as easily as an executable.
The sandbox environment OS may not be correct for the malware. For example, the malware might crash on Windows XP but run correctly in Windows 7.
A sandbox cannot tell you what the malware does. It may report basic functionality, but it cannot tell you that the malware is a custom Security Accounts Manager (SAM) hash dump utility or an encrypted keylogging backdoor, for example. Those are conclusions that you must draw on your own.
Войти в систему
Войти с помощью соц. сетей:
