Malware analysis

<h2 id="use-cases">Use cases</h2>
<p>There are three typical use cases that drive the need for malware analysis:
</p>
<ul><li><a href="/facts/Computer_security_incident_management/dGj4fdBn">Computer security incident management</a>: If an organization discovers or suspects that some malware may have gotten into its systems, a response team may wish to perform malware analysis on any potential samples that are discovered during the investigation process to determine if they are malware and, if so, what impact that malware might have on the systems within the target organizations' environment.</li>
<li><a href="/facts/Malware_research/4j5PjlGQ">Malware research</a>: Academic or industry malware researchers may perform malware analysis simply to understand how malware behaves and the latest techniques used in its construction.</li>
<li><a href="/facts/Indicator_of_compromise/oHwlcRJX">Indicator of compromise</a> extraction: Vendors of software products and solutions may perform bulk malware analysis in order to determine potential new indicators of compromise; this information may then feed the security product or solution to help organizations better defend themselves against attack by malware.</li></ul>
<h2 id="types">Types</h2>
<p>The method by which malware analysis is performed typically falls under one of two types:
</p>
<ul><li>Static malware analysis: Static or <a href="/facts/Code_analysis/b56nr6QM">Code Analysis</a> is usually performed by dissecting the different resources of the binary file <i>without executing it</i> and studying each component. The binary file can also be disassembled (or <a href="/facts/Reverse_engineering/pmJCV7J7">reverse engineered</a>) using a disassembler such as IDA or Ghidra. The machine code can sometimes be translated into assembly code which can be read and understood by humans: the malware analyst can then read the assembly as it is correlated with specific functions and actions inside the program, then make sense of the assembly instructions and have a better visualization of what the program is doing and how it was originally designed. Viewing the assembly allows the malware analyst/reverse engineer to get a better understanding of what is supposed to happen versus what is really happening and start to map out hidden actions or unintended functionality. Some modern malware is authored using evasive techniques to defeat this type of analysis, for example by embedding syntactic code errors that will confuse disassemblers but that will still function during actual execution.<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a></li>
<li>Dynamic malware analysis: Dynamic or Behavioral analysis is performed by observing the behavior of the malware while it is actually running on a host system. This form of analysis is often performed in a <a href="/facts/Sandbox_(computer_security)/WEm2u7oG">sandbox environment</a> to prevent the malware from actually infecting production systems; many such sandboxes are virtual systems that can easily be rolled back to a clean state after the analysis is complete. The malware may also be debugged while running using a <a href="/facts/Debugging_tool/mCe6UsWj">debugger</a> such as <a href="/facts/GNU_Debugger/nTs958uC">GDB</a> or <a href="/facts/WinDbg/7lfD8X9R">WinDbg</a> to watch the behavior and effects on the host system of the malware step by step while its instructions are being processed. Modern malware can exhibit a wide variety of evasive techniques designed to defeat dynamic analysis including testing for virtual environments or active debuggers, delaying execution of malicious payloads, or requiring some form of interactive user input.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a></li></ul>
<h2 id="stages">Stages</h2>
<p>Examining malicious software involves several stages, including, but not limited to the following:
</p>
<ul><li>Manual Code Reversing</li>
<li>Interactive Behavior Analysis</li>
<li>Static Properties Analysis</li>
<li>Fully-Automated Analysis</li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>"International Journal of Advanced Research in Malware Analysis" (PDF). ijarcsse. Archived from the original (PDF) on 2016-04-18. Retrieved 2016-05-30. <a href="https://web.archive.org/web/20160418151823/http://www.ijarcsse.com/docs/papers/Volume_3/4_April2013/V3I4-0371.pdf" target="_blank">https://web.archive.org/web/20160418151823/http://www.ijarcsse.com/docs/papers/Volume_3/4_April2013/V3I4-0371.pdf</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>"Malware Definition". Retrieved 2016-05-30. <a href="http://searchmidmarketsecurity.techtarget.com/definition/malware" target="_blank">http://searchmidmarketsecurity.techtarget.com/definition/malware</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
<li id="fn:3"><p>Honig, Andrew; Sikorski, Michael (February 2012). Practical Malware Analysis. No Starch Press. ISBN 9781593272906. Retrieved 5 July 2016. <a href="9781593272906" target="_blank">9781593272906</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li>
<li id="fn:4"><p>Keragala, Dilshan (January 2016). "Detecting Malware and Sandbox Evasion Techniques". SANS Institute. <a href="https://www.sans.org/reading-room/whitepapers/forensics/detecting-malware-sandbox-evasion-techniques-36667" target="_blank">https://www.sans.org/reading-room/whitepapers/forensics/detecting-malware-sandbox-evasion-techniques-36667</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li>
</ol>

Malware analysis open-in-new

Malware analysis