General Sandbox Architecture - Research Paper Example

? CWsandbox used for Dynamic Malware Analysis 6 November Introduction: The information about bots and malware application can be acquired through several ways. One of these methods is to perform a behavioral analysis of a suspected malware by letting it execute in a determined environment i.e. sandbox. A sandbox is computer security application software that creates a monitored environment for execution of such programs that arise from unknown, unidentified or unverified sources. The behavioral analysis of a malware that is conducted inside the constrained environment of sandbox is expected to reveal the information regarding the internal mechanisms, working and communication infrastructure of suspected code. General Sandbox Architecture: A sandbox is deployed to secure a computer system from external attacks that are attempted through malware (malicious program). According to Hoopes (2009), the approaches used are either to block the critical accessibility of a malware or to introduce a simulated environment with completely virtual computing resources like CPU, file system and the memory. This virtual environment enables the program to get executed in a completely isolated environment which is disconnected from the real execution environment within which it resides. The main idea is to monitor the accessibility of program (under observation) to system resources. This way the system can be brought back into the safe state after complete behavioral analysis of the suspected program. The fringe benefit of this approach is the usage of a lighter security protocol for the underlying system that improves its working efficiency. The behavioral analysis keeps the execution environment intact. This gives it an edge over instruction level analysis (basically done using debuggers or dis-assemblers). CWSandbox architecture and functioning: CW sandbox is one the sandbox applications that are in use. Every sandbox application has its own mechanism to secure the computer system environment. CWSandbox comprise of two executable files namely cwsandbox.exe and cwmonitor.dll. The former is the central application that initiates the malware and manages the complete process of analysis. The latter on the other hand is a DLL (Dynamic Link Library). This library is introduced into all processes in the malware that are under observation. This way the malware is actually executed and being interacted by the sandbox along with its own execution. The function of the DLL file is to catch each API critical call from malware and to inform the central application (cwsandbox.exe) about it. The sandbox (main application) then takes some time to analyze the call in order to either delegate the control to the required API (in case of safe conclusion) or to answer the call with a virtual error message (in opposite case). Along with the keeping an eye on every malware call, the DLL also makes it certain that the sandbox is kept informed about other malware activities like injecting a code into an already executing process or creating a child process. In both cases the DLL is instantiated again to be injected into the child process or the already running process. Figure 1.0 below, elaborates the described functioning. The CWSandbox uses the native execution environment unlike other sandbox schemes. This in turn reduces the delay caused by the analysis mechanism. Enormous communication exists between the main application (executable) and planted instances of DLLs. Each notification call from a DLL to sandbox contains a lot of information that requires a formal and reliable mechanism of communication between processes. In order to fulfill this requirement the sandbox is usually equipped with high efficiency IPC (Inter Process Communication) mechanism. Figure 1.0. Sandbox Instance using CWSandbox (Source: Hoopes J. 2009. Virtualization for Security) CWSandbox Malware Handling and Analysis Mechanism: The mechanisms that are performed by a sandbox can be distinguished into three parts. These parts may be categorized as follows: The Phase of Initialization-Phase 1 The first part commences by the initialization of the sandbox and the setting up of the process of malware. The DLL is injected by the sandbox. Some initial information and settings are then exchanged. The malware process is re initiated if everything works well. This paves way for the onset of the second phase. If everything does not go well the malware created is ceased by the sandbox and the sandbox gets terminated itself too. The Phase of Execution- Phase 2 This phase continues to go on as long as the malware continues to run. The sandbox has the ability to terminate the phase in advance before the malware itself ends. This provision is present with the sandbox so as to assist in situations where a sudden timeout may occur or a critical processing may need the malware to end. The cwmonitor.dll of each running process and cwsandbox.exe communicate intensely during the second phase. The Phase of Analysis and Detection – Phase 3 This phase performs the analyzing of the collected data. There are multiple standards of figuring out a malware behavior and different sandboxes have different identification protocols. The output of the phase is a XML analysis report. According to Fu (2012), in general the data regarding the API calls from a suspected malware is analyzed for general suspicious functioning or calls like access to secure data structures or self unpacking capabilities etc. As per Litux (2011) CWSandbox generally exposes the malware to a virtual process thread and let it freely interact with that process in order to analyze its prospective behavior with other processes. GFI (2012), states that the comparison of known malware behaviors with the behavior of suspected program usually assists in clearly revealing the malware nature. The current sandbox analysis/detection standards are constantly improvising. They thus do not ensure 100 percent correct analysis/detection or ultimate protection against malware. However, the overall situation becomes quite secure with the inception of sandbox mechanism with a minimum collateral damage. Cwmonitor. DLL Gets Implemented Each process created or injected by the malware is injected with cwmonitor.dll. The sandbox injects the DLL file. The DLL establish the API hooks, interact with the sandbox and also identify the hook functions. A DLL file lives in a manner similar to the sandbox. Its lifecycle can also be divided into three phases named initialization, execution and ceasing. The DLL main function handles the initial and the culminating phases while the execution phase is taken care of by the hook functions that are several in numbers. The commencing and the culminating phases are the only two phases that handle the DLL operations. Every execution of the DLL operation also leads to the calling of one of the API functions. The Hooked API Functions Sandbox exercises one rule universally with respect to API functions. Its main emphasis lies on the fact that the entire variety of API functions should get hooked on level that is nearest to hardware. Exceptions to this rule may occur at specific instances where it is required that the higher levels are looked up. CONCLUSION Conclusively it may be said that CWsandbox has proven to be a very effective technology in malware removal. It has the ability to run on native systems that curbs the execution delay which may occur if it is being run as an isolated system. References Hoopes, J. (2009). Virtualization for security: Including sandboxing, disaster recovery, high availability, forensic analysis, and honeypotting. Burlington, MA: Syngress Pub. Fu, X. (2012). Dr. Fu’s Security Blog. Retrieved from http://fumalwareanalysis.blogspot.com/2012/10/malware-analysis-tutorial-34-evaluation.html Litux. (2011). Analyzing Malware with CWSandbox. Retrieved from http://books.gigatux.nl/mirror/honeypot/final/ch12lev1sec3.html GFI. (2012). Dynamic Malware Analysis. GFI. Retrieved from http://www.gfi.com/malware-analysis-tool Jon, O. (2012). Detecting and evading CWSandbox. JON.OBERHEIDE.ORG Retrieved from http://jon.oberheide.org/blog/2008/01/15/detecting-and-evading-cwsandbox/ International Conference on Information Systems, Technology, and Management, & Prasad, S. K. (2010). Information systems, technology and management: 4th international conference. ICISTM 2010, Bangkok, Thailand, March 11 - 13, 2010: proceedings. Berlin: Springer. IFIP TC11 WG11.5 Working Conference on Integrity and Internal Control in Information Systems, Gertz, M., Guldentops, E., & Strous, L. (2002). Integrity, internal control and security in information systems: Connecting governance and technology: IFIP TC11/WG11.5 Fourth Working Conference on Integrity and Internal Control in Information Systems, November 15-16, 2001, Brussels, Belgium. Boston: Kluwer Academic Publishers International Conference on Information Systems Security, Prakash, A., & Gupta, I. S. (2009). Information systems security. Berlin: Springer. Brian J., Loeven, C. (2012). Automating Malware Threat Analysis. Sunbelt CWSandbox. Retrieved from https://www.sans.org/webcasts/92729.pdf Lehrstuhl. (2012). Malware Analysis System CWSandbox :: Technical Details. University of Erlangen-Nuremberg Retrieved from http://mwanalysis.org/?site=1&page=techdetails Dan, A. (1997). Chakra Vyuha (CV): A sandbox operating system environment for controlled execution of alien code. Yorktown Heights, N.Y: IBM T.J. Watson Research Center. Read More