Understand MalOp Detection Logic - Use Case

In this use case, we explain how Cybereason uses multiple events to generate the Malicious use of PowerShell MalOp.

This example demonstrates a portion of the full detection rule logic behind the MalOp. However, in your environment, you may not see all of the suspicions or evidence discussed in this example as the associated suspicions or evidence for the Malicious use of PowerShell MalOp because the Cybereason platform may trigger different suspicions and evidence in different scenarios and environments.

PowerShell MalOp logic explained

The Malicious use of PowerShell MalOp may include four suspicions.

These suspicions detect behaviors such as:

• Obfuscation of PowerShell commands

• Encoded and compressed command lines

• Presence of malicious PowerShell frameworks

• Use of specific PowerShell commands

• PowerShell performing downloads

• PowerShell opened by other processes, such as Word processes

PowerShell suspicion logic explained

The Malicious use of PowerShell suspicion may include (for example) the following three evidences:

The Malicious use of PowerShell suspicion the following three evidences:

Obfuscated PowerShell command evidence	This evidence indicates that the process in question is a PowerShell process, and the PowerShell command line uses obfuscation techniques.
Malicious PowerShell framework	This evidence indicates that the process is a PowerShell process, and is found to be a malicious PowerShell framework.
PowerShell executed by Word process	This evidence indicates that the process is a PowerShell process and the parent process is Microsoft Word.

How does this detection logic help me?

First, all AI Hunting MalOps require multiple conditions. Any individual threat requires additional detections (such as certain suspicions and evidence), so that a MalOp shows a pattern of behavior, not just an isolated malicious incident. In this example, the Malicious use of PowerShell Malop may include four different suspicions, including the Malicious use of PowerShell suspicion and three additional suspicions.

Second, suspicions and evidence are usually also multi-faceted, and are based on events and properties. In this example, the Malicious use of PowerShell suspicion may include three different evidences:

• Obfuscated PowerShell command evidence:

• Malicious PowerShell framework:

• PowerShell executed by Word process:

Because suspicions and evidence are based on events and properties, some suspicions and evidence are not necessarily malicious and must be analyzed further. Because these suspicions and evidence involve a smaller number of events that may not be malicious, these events together do not fit the MalOp definition of multiple confirmed events indicating definite malicious behavior.

When the platform combines multiple behaviors into a single MalOp alert, however, you can see the larger context and consider the attack as a whole instead of chasing single detected events.

Customize detection and alert behavior

Cybereason creates MalOps for a number of behaviors by default. However, some of these behaviors might be benign in your environment. Additionally, some behaviors that Cybereason classifies as benign might be malicious in your environment.

To avoid false positives and detect specific behaviors, you can use the features of the Cybereason platform to better detect and exclude certain behaviors:

• Create investigation queries to uncover specific behaviors.

• Create custom detection rules that trigger an evidence, a suspicion, or a MalOp when specific behavior occurs.

• Add items to your environment’s allowlist to allow specific behaviors.

• Add items to your environment’s blocklist to prevent specific behaviors.

When you create “custom” MalOps or use custom investigation queries, carefully consider each behavior that you want the Cybereason platform to detect so that your custom rules do not create many “false positive” MalOps, or prevent machines in your environment from functioning correctly.