OrangeCyberDefense Sandbox (P2A) ›P2A Sandbox Doc Reference

Processes to analyze

  • follow_process: Process names
      A comma-separated list of executables names to monitor
      default: cmd.exe,powershell.exe
    • More details

      Using Process Monitoring

      The follow_process option enables you to specify a comma-separated list of executable names that you want to monitor during analysis. p2a will focus its monitoring efforts on these specified executables, capturing their behavior and interactions with the analysis environment.

      Considerations and Recommendations

      When using the follow_process option:

    • Targeted Analysis: This option is useful for focusing on specific executables that are suspected of carrying out potentially malicious behavior.
    • Reduced Noise: By monitoring only selected executables, you can reduce the amount of data collected and focus on the most relevant information.

      • For optimal results:

    • Understand the behavior and potential risks associated with the executables you want to monitor.
    • Experiment with different combinations of monitored processes to capture different behaviors during analysis.
    • Combine this option with other relevant configuration settings to create a comprehensive analysis environment.

      • Example Use Case

      Consider analyzing a suspicious executable that is suspected of launching potentially malicious processes. By setting the follow_process option to include the names of these processes, you can closely monitor their interactions with the analysis environment. This focused monitoring approach allows you to identify any malicious behaviors or communication patterns exhibited by these specific processes, aiding in the detection of potential threats.

Executable parameters

  • extra_args: Custom parameters
      Custom parameters for the executable to analyze
      default:
    • More details

      Using Custom Parameters

      The extra_args option allows you to specify custom parameters to be passed to the executable during analysis. These additional parameters can modify the behavior of the executed file, enabling you to tailor the analysis environment according to your specific requirements.

      Considerations and Recommendations

      When using the extra_args option:

    • Behavior Modification: Use custom parameters to modify the way the executable behaves during analysis, potentially revealing different aspects of its behavior.
    • Advanced Analysis: Custom parameters can help you capture specific behaviors or interactions that are crucial for your analysis objectives.

      • For optimal results:

    • Understand the purpose and expected impact of the custom parameters before specifying them.
    • Experiment with different combinations of parameters to capture various behaviors of the file during analysis.
    • Combine this option with other relevant configuration settings to create a comprehensive analysis environment.

      • Example Use Case

      Suppose you are analyzing a potentially malicious script that interacts with a specific server. By using the extra_args option to specify the IP address or domain name of the server, you can modify the script's behavior to interact with your controlled server. This customization allows you to monitor the communication between the script and the server, capturing valuable information about potential malicious activities or communication patterns.

Custom command line

  • custom_command_line: Command line {filename}
      Commanline to execute instead of the default behavior
      default:
    • More details

      Using Custom Command Line

      The custom_command_line option enables you to specify a custom command line to be executed instead of the default behavior when launching a file for analysis. This option allows you to tailor the execution parameters to better suit your analysis requirements.

      Considerations and Recommendations

      When using the custom_command_line option:

    • Targeted Analysis: This option is useful for fine-tuning the execution parameters to focus on specific behaviors or actions of the file being analyzed.
    • Advanced Analysis: Customize the command line to capture detailed information, behaviors, or interactions that are critical for your analysis objectives.

      • For optimal results:

    • Ensure that you have a clear understanding of the desired analysis objectives before specifying a custom command line.
    • Experiment with different command line options to capture different aspects of the file's behavior during analysis.
    • Consider using this option in conjunction with other relevant configuration settings to create a comprehensive analysis environment.

      • Example Use Case

      Imagine analyzing a suspicious executable that is suspected of performing network communication. By setting the custom_command_line option to include network monitoring parameters, you can capture detailed network interactions of the executable during analysis. This custom approach enables you to focus specifically on the networking behavior of the executable, providing valuable insights into potential malicious connections or communication patterns.

Hooks to enable

  • hooks: Hooks groups
      All hooks types to be enabled
    • hook_network : Network hooks
      default: True
    • hook_file : File hooks
      default: True
    • hook_memory : Memory hooks
      default: True
    • hook_process : Process hooks
      default: True
    • hook_registry : Registry hooks
      default: True
    • hook_exception : Exception hooks
      default: True
    • hook_hash : Hash hooks
      default: True
    • hook_mutex : Mutex hooks
      default: True
    • hook_namedpipe : Namedpipe hooks
      default: True
    • hook_semaphore : Semaphore hooks
      default: True
    • hook_events : Events hooks
      default: True
    • hook_locales : Locales hooks
      default: True
    • hook_outputdebugstring : Outputdebugstring hooks
      default: True
    • hook_resources : Resources hooks
      default: True
    • hook_service : Service hooks
      default: True
    • hook_systeminfo : Systeminfo hooks
      default: True
    • hook_additional : Additional hooks
      default: True
    • hook_print : Print functions hooks
      default: True
    • More details

      Using Hooks Groups

      To specify which hook types should be enabled during analysis, modify the configuration of your sandbox environment and adjust the hooks option. This option allows you to define the types of hooks that will be active, capturing specific behaviors and interactions within the sandbox environment.

      Example Use Case

      Consider analyzing a potentially malicious executable that is suspected of performing network communication and interacting with files and the Windows registry. By adjusting the hooks option and including hook_network,hook_file,hook_registry, you can enable specific hooks to capture and monitor these behaviors. This customization allows you to focus on the relevant aspects of the executable's behavior, providing valuable insights into its interactions and potential threats.

  • disable_hooks: Disable all hooks
      default: False
    • More details

      Disabling All Hooks

      To disable all hooks during analysis, modify the configuration of your sandbox environment and adjust the disable_hooks option. This option allows you to globally deactivate all hooks, preventing any hooks from capturing behaviors and interactions within the sandbox environment.

      Example Use Case

      Imagine conducting a high-level analysis of an application that requires minimal monitoring of its interactions and behavior. By setting the disable_hooks option to true, you can bypass all hook monitoring and focus solely on the application's execution without capturing detailed interactions. This can be useful for scenarios where you want to quickly assess an application's general functionality without extensive behavior tracking.

Counter-measures

  • anti_anti_vm: Use anti anti-VMs
      Some malwares use anti-VM techniques to avoid sandbox analyses, this option, if set, bypasses such techniques
      default: True
    • More details

      Using Anti Anti-VM

      The anti_anti_vm option enhances the capabilities of p2a virtual machines to counteract anti-VM techniques employed by malware. When enabled, p2a employs mechanisms to bypass anti-VM tactics used by malware, ensuring a more accurate and comprehensive analysis environment.

      Considerations and Recommendations

      When using the anti_anti_vm option:

    • Malware Evasion Countermeasure: This option is particularly useful for analyzing malware that employs anti-VM techniques to evade sandbox analyses.
    • Accurate Analysis: By bypassing anti-VM tactics, you can obtain a clearer understanding of the malware's behavior without interference from evasion techniques.

      • For optimal results:

    • Enable this option when analyzing malware samples known to utilize anti-VM techniques.
    • Combine this option with other relevant configuration settings to create a robust analysis environment.

      • Example Use Case

      Consider analyzing a malware sample that actively detects and evades virtual environments to avoid analysis. By enabling the anti_anti_vm option in your p2a configuration, you can effectively neutralize the malware's attempts to detect the sandbox environment. This ensures that the malware's evasion tactics are overridden, allowing you to analyze its behavior accurately and identify potential threats or malicious actions.

  • anti_fingerprint: Use anti VM fingerprinting
      If set, this enables p2a to randomize certain aspects of its virtual machines to prevent them from being fingerprinted.
      default: True
    • More details

      Using Anti Fingerprint

      The anti_fingerprint option enhances the stealthiness of p2a virtual machines by randomizing certain aspects to prevent fingerprinting attempts by malware. When enabled, p2a takes measures to make its virtual machines more challenging to be identified by malware that attempts to fingerprint the analysis environment.

      Considerations and Recommendations

      When using the anti_fingerprint option:

    • Anti-Malware Evasion: This option is especially useful when dealing with malware that employs advanced techniques to identify virtual environments.
    • Stealthier Analysis: By evading fingerprinting attempts, you can conduct more accurate and reliable analysis of malware behavior.

      • For optimal results:

    • Enable this option when analyzing sophisticated malware that employs anti-analysis tactics.
    • Combine this option with other relevant configuration settings to create a comprehensive and resilient analysis environment.

      • Example Use Case

      Imagine analyzing a malware sample that actively tries to detect virtual environments to evade detection. By enabling the anti_fingerprint option in your p2a configuration, you can counteract these detection techniques. This ensures that the malware's attempts to identify the analysis environment are thwarted, allowing you to conduct a thorough analysis of the malware's behavior without interference from its evasion tactics.

Time

  • time_system_use_peheader_time: System time = PE timestamp
      If set, use the PE timestamp as System time
      default: True
    • More details

      Using PE Header Time for System Time

      The time_system_use_peheader_time option allows you to synchronize the system time of the p2a virtual machine with the timestamp found in the PE headers of executables. When enabled, the system time within the virtual machines will be set to match the PE header timestamp of the executed executables.

      Considerations and Recommendations

      When using the time_system_use_peheader_time option:

    • Behavior Dependencies: This option can be particularly useful for uncovering behavior that is dependent on specific timestamps within executables.
    • Scenario Replication: Enabling this option allows you to replicate the exact time conditions that the malware expects, enhancing the accuracy of your analysis.

      • For optimal results:

    • Ensure that you have a clear understanding of the behavior associated with specific timestamps within executables before using this option.
    • Combine this option with other relevant configuration settings to create a comprehensive analysis environment.
    • Keep the time_system_new_date option set to 0 to ensure the effectiveness of this synchronization.

      • Example Use Case

      Consider analyzing a malware sample that relies on specific timestamps within executable files for evasive behavior. By enabling the time_system_use_peheader_time option in your p2a configuration and setting time_system_new_date to 0, you can create an analysis environment where the system time matches the timestamps of executed executables. This allows you to simulate the same time-based conditions as the malware's intended runtime environment, uncovering potential behavior that is dependent on specific timestamps.

Monitoring

  • env: Specific launch environment
      Forces the virtual machine to use a specific environment for the analysis(defaults empty-> chooses best env).
      Should be one of the followings:
    • : AUTO
    • ArjEnvironment : Arj
    • BatchEnvironment : Batch
    • BrowserEnvironment : Browser
    • BrowserEnvironmentFile : BrowserFile
    • Bzip2Environment : Bzip2
    • CabEnvironment : Cab
    • ChmEnvironment : Chm
    • CpioEnvironment : Cpio
    • CustomEnvironment : Custom
    • DebEnvironment : Deb
    • DllEnvironment : Dll
    • EmlEnvironment : Eml
    • ExcelEnvironment : Excel
    • ExeEnvironment : Exe
    • FreemodeEnvironment : Freemode
    • GzipEnvironment : Gzip
    • IsoEnvironment : Iso
    • JScriptEnvironment : JScript
    • JarEnvironment : Jar
    • LHarcEnvironment : LHarc
    • LnkEnvironment : Lnk
    • MsiEnvironment : Msi
    • NsisEnvironment : Nsis
    • OnenoteEnvironment : Onenote
    • PdfEnvironment : Pdf
    • PowerPointEnvironment : PowerPoint
    • PowerShellEnvironment : PowerShell
    • RarEnvironment : Rar
    • RpmEnvironment : Rpm
    • RtfEnvironment : Rtf
    • ScriptEnvironment : Script
    • SevenZEnvironment : SevenZ
    • TarEnvironment : Tar
    • VbsEnvironment : Vbs
    • WimEnvironment : Wim
    • WordEnvironment : Word
    • WsfEnvironment : Wsf
    • ZEnvironment : Z
    • ZipEnvironment : Zip
      • default: (AUTO)
    • More details

      Using Specific Launch Environments

      To specify a specific launch environment for the virtual machine during analysis, modify the configuration of your p2a sandbox environment and adjust the env option. This option allows you to force the virtual machine to use a predefined environment, catering to the type of analysis required.

      Considerations and Recommendations

      When selecting a specific launch environment:

    • Behavior Variation: Different environments can yield varying behaviors during analysis. Choose the environment that best aligns with the type of analysis you want to conduct.
    • Scenario Compatibility: Ensure that the chosen environment is compatible with the behavior of the file you are analyzing.

      • For optimal results:

    • Review the available launch environments and their associated behaviors to select the most suitable one for your analysis.
    • Experiment with different environments to capture a comprehensive understanding of the file's behavior.
    • For general analysis, consider using the AUTO option to allow p2a to intelligently choose the appropriate environment.

      • Example Use Case

      Suppose you are analyzing a potentially malicious PDF file. By setting the env option to PdfEnvironment, you can ensure that p2a launches the virtual machine in a PDF-specific environment, closely replicating the conditions required for analyzing PDF-related behavior. This targeted environment selection allows you to capture accurate insights into how the PDF file behaves and interacts with the analysis environment.

  • monitor_heap_execute: Monitor heap executes
      If set, whenever there is a code execution on the heap, the corresponding memory region will be monitored.
      default: True
    • More details

      Using Monitor Heap Executes

      The monitor_heap_execute option enables the monitoring of code execution that occurs on the heap. When this option is enabled, p2a will track and monitor memory regions where code execution takes place in the heap.

      Considerations and Recommendations

      When using the monitor_heap_execute option:

    • Memory Analysis: This option is particularly useful for capturing code execution activities that occur within memory regions allocated on the heap.
    • Behavior Insights: Monitoring heap execution can provide insights into how a file manipulates memory structures and executes code dynamically.

      • For optimal results:

    • Understand the significance of monitoring heap execution in the context of your analysis objectives.
    • Combine this option with other relevant configuration settings to create a comprehensive analysis environment.

      • Example Use Case

      Imagine analyzing a suspicious executable that is suspected of dynamically generating and executing code within memory. By enabling the monitor_heap_execute option, you can monitor and track the memory regions where code execution takes place on the heap. This enables you to capture the behavior of the executable that involves dynamic code generation and execution, providing insights into potentially malicious or unauthorized activities.

  • monitor_pe_headers: Monitor In Memory PE headers
      Monitor In Memory PE headers
      default: False
    • More details

      Using Monitor In Memory PE Headers

      The monitor_pe_headers option enables the monitoring of Portable Executable (PE) headers that are loaded in memory. When this option is enabled, p2a will track and monitor the in-memory PE headers of executable files.

      Considerations and Recommendations

      When using the monitor_pe_headers option:

    • PE Header Analysis: This option is useful for gaining insights into how executable files' PE headers are manipulated and utilized during runtime.
    • Header Modifications: Monitoring PE headers can reveal any modifications or alterations made to headers within memory, potentially indicating code injections or tampering.

      • For optimal results:

    • Understand the relevance of monitoring in-memory PE headers in the context of your analysis goals.
    • Combine this option with other relevant configuration settings to create a comprehensive analysis environment.

      • Example Use Case

      Consider analyzing a suspicious executable that is suspected of tampering with its own PE headers to evade detection. By enabling the monitor_pe_headers option, you can monitor and track any modifications or manipulations of the PE headers that occur in memory. This allows you to identify any unauthorized modifications to the headers, potentially indicating malicious or unauthorized actions taken by the executable.

Debug

  • error_break_on_werfault: Assume FAIL if windows error reporting dialog appears
      default: False
    • More details

      Using Error Break on Windows Error Reporting

      The error_break_on_werfault option allows p2a to respond to the appearance of the Windows Error Reporting (WER) dialog. When this option is enabled, if the WER dialog appears during analysis, p2a will assume that the analysis has failed and terminate the analysis process.

      Considerations and Recommendations

      When using the error_break_on_werfault option:

    • Error Handling: This option helps p2a automatically handle situations where the Windows Error Reporting dialog interferes with analysis.
    • Automation: Enabling this option can prevent manual intervention in cases where the WER dialog would otherwise interrupt the analysis.

      • For optimal results:

    • Understand that enabling this option will terminate analysis if the WER dialog appears, assuming that the analysis cannot continue accurately.
    • Consider using this option in scenarios where it is more important to automate analysis termination than to handle possible false positives caused by the WER dialog.

      • Example Use Case

      Imagine you are running an automated malware analysis pipeline, and one of the challenges is dealing with the interruption caused by the Windows Error Reporting dialog. By enabling the error_break_on_werfault option, you can ensure that the analysis process automatically terminates if the WER dialog appears. This helps maintain the smooth flow of your automated analysis pipeline by promptly handling such interruptions without manual intervention.

  • error_break_on_uncatched_exceptions: Assume FAIL if an uncatched exception is thrown by a monitored process
      default: False
    • More details

      Using Error Break on Uncatched Exceptions

      The error_break_on_uncatched_exceptions option enables p2a to respond to unhandled exceptions thrown by monitored processes during analysis. When this option is enabled, if a monitored process throws an unhandled exception, p2a will assume that the analysis has failed and terminate the analysis process.

      Considerations and Recommendations

      When using the error_break_on_uncatched_exceptions option:

    • Error Handling: This option helps p2a automatically handle analysis failures caused by unhandled exceptions.
    • Automation: Enabling this option can prevent analysis from continuing in cases where unhandled exceptions could lead to inaccurate results.

      • For optimal results:

    • Understand that enabling this option will terminate analysis if a monitored process throws an unhandled exception, assuming that the analysis cannot continue accurately.
    • Consider using this option in scenarios where it is more important to automate analysis termination than to handle possible false positives caused by unhandled exceptions.

      • Example Use Case

      Suppose you are analyzing a potentially malicious executable that frequently throws unhandled exceptions during execution. These exceptions may impact the accuracy of the analysis. By enabling the error_break_on_uncatched_exceptions option, you can ensure that the analysis process automatically terminates if a monitored process throws an unhandled exception. This helps maintain the integrity of the analysis results by handling potentially disruptive exceptions effectively.

  • trace_api_calls: Trace EVERY API call in log file (very slow and error prone)
      default: False
    • More details

      Using Trace API Calls

      The trace_api_calls option allows you to trace every API call made by the monitored processes and record them in a log file. This option provides a detailed record of all API calls made during analysis, but it comes with potential drawbacks, such as increased execution time and potential errors.

      Considerations and Recommendations

      When using the trace_api_calls option:

    • Detailed Logging: This option offers a comprehensive log of API calls, which can be helpful for in-depth analysis of process behavior.
    • Performance Impact: Enabling this option can significantly slow down the analysis process due to the extensive logging of API calls.
    • Error Prone: Increased logging can lead to larger log files and potential errors, especially when dealing with large-scale analysis.

      • For optimal results:

    • Consider enabling this option only when you need an exhaustive record of API calls for specific analysis scenarios.
    • Use this option judiciously, especially in performance-critical or time-sensitive analysis scenarios.
    • Balance the benefits of detailed logging against potential performance overhead and potential error risks.

      • Example Use Case

      Imagine you are conducting advanced behavior analysis of a complex executable suspected of exhibiting unique malicious behaviors. By enabling the trace_api_calls option, you can capture an extensive log of API calls made during the execution of the executable. This detailed trace can provide you with a deeper understanding of the executable's behavior, enabling you to identify specific API calls associated with potentially malicious actions.

  • trace_com_calls: Trace EVERY Windows COM call in log file (slow)
      default: False
    • More details

      Using Trace COM Calls

      The trace_com_calls option allows you to trace every Windows Component Object Model (COM) call made by the monitored processes and record them in a log file. This option provides a detailed record of all COM calls made during analysis, but it comes with a potential performance impact.

      Considerations and Recommendations

      When using the trace_com_calls option:

    • Detailed Logging: This option offers a comprehensive log of COM calls, which can be helpful for in-depth analysis of interactions involving COM objects.
    • Performance Impact: Enabling this option can slow down the analysis process due to the extensive logging of COM calls.

      • For optimal results:

    • Consider enabling this option only when you need detailed insights into interactions involving COM objects during analysis.
    • Use this option judiciously, especially in performance-critical or time-sensitive analysis scenarios.
    • Balance the benefits of detailed logging against potential performance overhead.

      • Example Use Case

      Suppose you are analyzing a complex executable that interacts with various COM objects as part of its behavior. By enabling the trace_com_calls option, you can capture a comprehensive log of COM calls made during the execution of the executable. This detailed trace can provide you with valuable information about how the executable interacts with COM objects, helping you understand its behavior and potential implications.

  • verbosity_level: Log verbosity
      default: 5
      range: [0, 7]
    • More details

      Using Log Verbosity

      The verbosity_level option allows you to control the level of detail in the logs generated during analysis. You can specify the verbosity level based on your preference for detailed or concise log output.

      Considerations and Recommendations

      When using the verbosity_level option:

    • Log Detail: A higher verbosity level generates more detailed logs, providing deeper insights into the analysis process.
    • Log Volume: Higher verbosity levels can result in larger log files, potentially affecting storage and analysis efficiency.

      • For optimal results:

    • Choose a verbosity level that aligns with your analysis objectives and the level of detail you require.
    • Consider lower verbosity levels for quicker analysis and reduced log file sizes, especially when storage and performance are a concern.
    • Increase the verbosity level for detailed analysis or when you need to troubleshoot specific issues.

      • Example Use Case

      Imagine you are conducting an in-depth analysis of a complex executable. To thoroughly understand its behavior, you decide to set the verbosity_level option to its highest value. This generates highly detailed logs that include intricate information about various events, function calls, and interactions within the analysis environment. This level of detail aids in your comprehensive analysis, enabling you to identify subtle behaviors and interactions that might not be evident in less detailed logs.

  • fast_exit_confidence: Exit as soon as a possible after a confidente guess
      default: False
    • More details

      Using Fast Exit on Confidence

      The fast_exit_confidence option allows p2a to exit the analysis process as soon as a confident guess about the sample's nature is made. When this option is enabled, if p2a reaches a level of confidence in its analysis, it will terminate the analysis process promptly, saving time.

      Considerations and Recommendations

      When using the fast_exit_confidence option:

    • Time Efficiency: Enabling this option can lead to faster analysis results when p2a confidently identifies the sample.
    • Confidence Threshold: Understand the confidence threshold that triggers the fast exit and how it aligns with your analysis goals.

      • For optimal results:

    • Consider enabling this option when you prioritize time efficiency and are confident that p2a can accurately identify the nature of the sample.
    • Use this option judiciously, as premature exits based on lower confidence levels could lead to incorrect conclusions.
    • Adjust the confidence threshold if necessary, based on the characteristics of the samples you are analyzing.

      • Example Use Case

      Suppose you are conducting a large-scale analysis of diverse samples, and many of them are benign files that can be identified with high confidence in a short time. By enabling the fast_exit_confidence option with an appropriate confidence threshold, you can expedite the analysis process for these samples, reducing the overall analysis time. This ensures efficient resource utilization and allows you to focus more time on samples that require in-depth analysis.