Cheat Sheet for Analyzing Malicious Software

This cheat sheet presents tips for analyzing and reverse-engineering malware. It outlines the steps for performing behavioral and code-level analysis of malicious software. To print it, use the one-page PDF version; you can also edit the Word version to customize it for you own needs.

Overview of the Malware Analysis Process

  1. Use automated analysis sandbox tools for an initial assessment of the suspicious file.
  2. Set up a controlled, isolated laboratory in which to examine the malware specimen.
  3. Examine static properties and meta-data of the specimen for triage and early theories.
  4. Emulate code execution to identify malicious capabilities and contemplate next steps.
  5. Perform behavioral analysis to examine the specimen's interactions with its environment.
  6. Analyze relevant aspects of the code statically with a disassembler and decompiler.
  7. Perform dynamic code analysis to understand the more difficult aspects of the code.
  8. If necessary, unpack the specimen.
  9. Repeat steps 4-8 above as necessary (the order may vary) until analysis objectives are met.
  10. Augment your analysis using other methods, such as memory forensics and threat intel.
  11. Document findings, save analysis artifacts and clean-up the laboratory for future analysis.

Behavioral Analysis

Ghidra for Static Code Analysis

Go to specific destinationg
Show references to selected instructionCtrl+Shift+f
Insert a comment;
Follow jump or callEnter
Return to previous locationAlt+Left
Go to next viewAlt+Right
UndoCtrl+z
Define data typet
Add a bookmarkCtrl+d
Text searchCtrl+Shift+e
Add or edit a labell
Disassemble selected valuesd

x64dbg/x32dbg for Dynamic Code Analysis

Run the codeF9
Step into/over instructionF7 / F8
Execute until selected instructionF4
Execute untill next returnCtrl+F9
Show previous/next executed instruction- / +
Return to previous view*
Go to specific expressionCtrl+g
Insert comment/label; / :
Show current function as a graphg
Set software breakpoint on specific instructionSelect instruction » F2
Set software breakpoint on APIGo to Command prompt » SetBPX API Name
Highlight all occurrences of the keyword in disassemblerh » Click on keyword
Assemble instruction in place of selected oneSelect instruction » Spacebar
Edit data in memory or instruction opcodeSelect data or instruction » Ctrl+e
Extract API call referencesRight-click in disassembler » Search for » Current module » Intermodular calls

Unpacking Malicious Code

  • Determine whether the specimen is packed by using Detect It Easy, Exeinfo PE, Bytehist, peframe, etc.
  • To try unpacking the specimen quickly, infect the lab system and dump from memory using Scylla.
  • For more precision, find the Original Entry Point (OEP) in a debugger and dump with OllyDumpEx.
  • To find the OEP, anticipate the condition close to the end of the unpacker and set the breakpoint.
  • Try setting a memory breakpoint on the stack in the unpacker's beginning to catch it during cleanup.
  • To get closer to the OEP, set breakpoints on APIs such as LoadLibrary, VirtualAlloc, etc.
  • To intercept process injection set breakpoints on VirtualAllocEx, WriteProcessMemory, etc.
  • If cannot dump cleanly, examine the packed specimen via dynamic code analysis while it runs.
  • Rebuild imports and other aspects of the dumped file using Scylla and pe_unmapper.

Bypassing Other Analysis Defenses

  • Decode obfuscated strings statically using FLOSS, xorsearch, Balbuzard, etc.
  • Decode data in a debugger by setting a breakpoint after the decoding function and examining results.
  • Conceal x64dbg/x32dbg via the ScyllaHide plugin.
  • To disable anti-analysis functionality, locate and patch the defensive code using a debugger.
  • Look out for tricky jumps via TLS, SEH, RET, CALL, etc. when stepping through the code in a debugger.
  • If analyzing shellcode, use scdbg and runsc
  • Disable ASLR via setdllcharacteristics and CFF Explorer.

Post-Scriptum

If you have suggestions for improving this cheat sheet, please let me know. Creative Commons v3 "Attribution" License for this cheat sheet version 2.2.

Updated

About the Author

Lenny Zeltser develops products and programs that use security to achieve business results. He is the CISO at Axonius and Faculty Fellow at SANS Institute. Lenny has been leading efforts to establish resilient security practices and solve hard security problems for over two decades. A respected author and practitioner, he has been advancing tradecraft and contributing to the community. His insights build upon real-world experience, a Computer Science degree from the University of Pennsylvania, and an MBA degree from MIT Sloan.

Learn more