Troubleshooting Unexpected Blocks By the Carbon Black Cloud Sensor

Products

• Carbon Black Cloud Endpoint Standard (formerly Cb Defense)

Issue/Introduction

This article details how to review an Alert to determine what was blocked and why.

Environment

• Carbon Black Cloud Console: All Versions
  • Endpoint Standard

Resolution

Gather the initial details

1. From the Alerts tab, find the relevant block event using the available filters or search terms. Example:

   device_name:DEVPC01 AND sensor_action:*

2. Expand the alert to see the Alert Details by using the " > " button
3. Under the "WHAT TRIGGERED THIS ALERT?" section, see if there is a specific "Rule" listed (e.g. Privilege Escalation).

If there IS a rule listed under "WHAT TRIGGERED THIS ALERT?"

This indicates that the file was blocked because of a Core Prevention rule. See Configuring Exclusions for Core Prevention Rules to create an exception.

If there IS NOT a rule listed under "WHAT TRIGGERED THIS ALERT?"

1. Open the Alert Triage for the relevant Alert. Note: In the interactive process tree window, any tiles with a red shield tag are processes the Sensor applied a Deny or Terminate action on.
2. Scroll to the bottom of the webpage and find the Observations section.
3. A Policy Terminate or Policy Deny tag will be assigned to any Observation where either blocking action took place.
4. Expand the Observation for the relevant block event to see the Observation Details.
5. For the process and child process (if applicable) involved, note the Effective Reputation and TTPs assigned to each. Example:
   • Process: C:\Windows\System32\cmd.exe
   • Process Effective Reputation: TRUSTED_WHITE_LIST
   • TTPs: RUN_UNKNOWN_APP
   • Child Process: D:\Dev\GitHub\CustomFile.exe
   • Child Process Effective Reputation: NOT_LISTED
   • TTPs: UNKNOWN_APP, PACKED_CALL
6. At this point it's important to note that the block is going to be caused by a Blocking and Isolation Rule. We can use the data collected from step 5 to determine which rule caused the block.
   • If the block event states "A Deny Policy Action was applied", then that indicates it is matching a "Deny Operation" Blocking and Isolation rule.
   • If the block event states "A Terminate Policy Action was applied" then that indicates it is matching a "Terminate Process" Blocking and Isolation rule.
7. In a second browser tab, navigate to Enforce > Policy > [Policy Name] > Prevention > Expand "Blocking and Isolation".
   
   1. Compare the effective reputation of the process and child process (if applicable) to the below table. Blocking and Isolation rules can block files if they match one of the following reputations:
      

      Reputation	Blocking and Isolation Name
      KNOWN_MALWARE	Known Malware
      COMPANY_BLACK_LIST	Application on the company banned list
      RESOLVING	Unknown application or process
      ADWARE PUP	Adware or PUP
      SUSPECT_MALWARE HEURISTIC	Suspected malware
      NOT_LISTED	Not listed application

      
      Note: If a file's reputation has been determined to be the cause of the block, adding the file to the approved list, approving the certificate, utilizing an IT Tools approval, creating a path-based permission rule, or creating a Event Reporting and Sensor Operation Exclusion may be appropriate.  See the Reputation Priority table to understand how these approval mechanisms come into play.
      
      
   2. Check if the File Path (including filename) of the process and child process (if applicable) match the File Path of any Blocking and Isolation rules.
      
      Note: If a path-based Blocking & Isolation rule has been determined to be the cause of the block, creating a path-based permission rule, creating a Event Reporting and Sensor Operation Exclusion, or removing the offending rule may be appropriate.
      
      
   3. Check if the TTPs of the blocked process to see if it aligns with the below operation attempts:
      

      TTP:	Operation Attempt:
      NETWORK_ACCESS ATTEMPTED_SERVER ATTEMPTED_CLIENT	Communicates over the network
      RAM_SCRAPING READ_SECURITY_DATA	Scrapes memory of another process
      SUSPICIOUS_BEHAVIOR PACKED_CALL	Executes code from memory
      KNOWN_RANSOMWARE DATA_TO_ENCRYPTION SET_SYSTEM_FILE KERNEL_ACCESS	Performs ransomware-like behavior
      INJECT_CODE HAS_INJECTED_CODE COMPROMISED_PROCESS PROCESS_IMAGE_REPLACED MODIFY_PROCESS MODIFY_PROCESS_EXECUTION HOLLOW_PROCESS	Injects code or modifies memory of another process
      FILELESS	Executes a fileless script

8. Using the example data from step 5 we can see the following would be matched:
   • File path: **\cmd.exe > Invokes an untrusted process > Deny operation
     • This would match because the process is CMD.exe and the child process is UNKNOWN

If the issue persists, open a case with Support and provide:

• The alert ID / Observation ID of the block event
• Full page screenshot of the observation detail of the block event (step 4)
• Sensor logs from a machine that most recently blocked the file(s) in question

Additional Information

• Permission rules take precedence over all Blocking & Isolation rules
• The rule "Invokes an untrusted process" triggers when the child process is NOT_LISTED, UNKNOWN, or ADAPTIVE_WHITE_LIST
• The Allow rules in Permissions don't cover "Invokes an untrusted process" but Bypass rules do
• If a block event shows the file SHA256 value but no filename then virustotal can be used in some cases to lookup the potential filename this can occur if the sensor reported only the hash of the file but didn't full report the path and filename