Troubleshooting Unexpected Blocks
search cancel

Troubleshooting Unexpected Blocks

book

Article ID: 292504

calendar_today

Updated On:

Products

Carbon Black Cloud Endpoint Standard

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

Table of Contents


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 Technical Support and provide:

  • The alert ID / Observation ID of the block event
  • An export of the event(s) from the Alert page
  • 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
Powered by Wolken Software