VMware’s Carbon Black Cloud workload protection security capabilities are now fully integrated into the world’s leading cloud management platform for complete data center visibility and protection. It combines vSphere and VMware Carbon Black Cloud in a purpose-built, operationally simple solution with minimal overhead and performance impact.
VMware Carbon Black Cloud Workload Protection solution is the only vSphere vCenter workload protection platform for enterprise virtualization and security teams that delivers the most secure virtual infrastructure, while also providing the same visibility and capabilities within the public cloud as well. The Carbon Black Cloud Workload Protection solution reduces the attack surface by giving Infrastructure, DevOps and Security teams visibility into operating system and application vulnerabilities right from within the vCenter Management plane as well as within the Carbon Black Cloud Management Console.
VMware Carbon Black Cloud Workload Protection contains two Carbon Black Cloud Workload Protection components that are integrated into vCenter:
- Carbon Black Cloud Workload Protection Plug-in in vCenter
- Carbon Black Cloud Management Console
In this walkthrough we are going to cover our workload solution and integration with vCenter. By following a simple methodology of identifying risk, then preventing that risk and lastly detecting and responding to that risk as shown in the image below.
We will start by identifying a high severity exploitable vulnerability that has been categorized by our Risk Score. This score is a metric that accurately represents the risk of a given vulnerability in your data center (the actual exploitability of the CVE). It does so by combining CVSS information with proprietary threat data and advanced modeling from Kenna Security.
Once we Identify the exploit and its severity level, we will then show how that exploit was leveraged to compromise the machines in our environment. We will then show how we can how we can detect and respond to these types of attacks with Carbon Black Workload Protection.
- Section 1: Accessing the vSphere vCenter Environment
- Section 2: Walkthrough of vSphere vCenter with Carbon Black Cloud Workload Protection Plug-in
- Section 3: Identifying Risks with vCenter Carbon Black Cloud Workload Plug-in
- Section 4: Identifying Risks with Carbon Black Cloud Security Console
- Section 5: Detecting and Responding to Attacks with Carbon Black Workload Protection
- Section 6: Alerts
Before you Begin
In order to complete this product walkthrough please make sure you have the following:
- A valid account in the VMware TestDrive environment, sign up here if you do not have one.
- TCP & UDP ports 80, 443, 8443; and if using PCoIP, both TCP & UDP 4172
- An Horizon Client installed on your machine.
Section 1: Accessing the vSphere Environment
To login to the vSphere environment, perform the following steps.
Enter your TestDrive Username and Password and select ENTER.
Next, locate the Carbon Black product under the Intrinsic Security tab.
Click LAUNCH and LAUNCH VIA WORKSPACE ONE.
A new tab will open with Workspace ONE. Enter your TestDrive Username, then hit Next.
On the next screen, enter your TestDrive Password then hit Sign in.
Next, search for the Carbon Black Cloud desktop. Click to open into the desktop either via HTML access or Horizon Client access.
Now you'll be on the Carbon Black Cloud RDSH desktop. At this point you can begin the walkthrough steps listed below.
Section 2: Walkthrough of vSphere with the Carbon Black Cloud Workload Plug-in
The Carbon Black Cloud Workload Plug-in for vSphere integrates carbon black security capabilities directly in the vSphere Client.
2.1 Accessing the Carbon Black Cloud Workload Plug-in
On the desktop, launch on the shortcut named “vCenter Server”.
Log in with the following credentials:
- Username: (listed in text file Carbon_Black_Demo_Credentials.txt on the Carbon Black desktop)
- Password: (listed in text file Carbon_Black_Demo_Credentials.txt on the Carbon Black desktop)
Once logged in, to view the Carbon Black Cloud Workload Plug-in, click Menu at the top then the Carbon Black icon in the menu or in the left navigation pane in the Menu > Shortcuts of the vSphere Client.
Note: If you receive error "Unable to fetch appliance details, please contact the administrator", hit the Chrome browser Refresh button.
The Carbon Black Cloud Workload Plug-in dashboard or the Summary tab displays different widgets for a quick overview of the health and inventory status. You can also view vulnerabilities affecting your assets and critical product vulnerabilities.
- Go to the Inventory > Not Enabled tab to enable Carbon Black for your data center inventory.
- Use the Inventory > Enabled tab to view the list of assets protected by Carbon Black, and to update or disable Carbon Black for a selection of your data center inventory.
- Go to the Vulnerabilities tab to view vulnerabilities affecting your assets.
You can go to the individual VMs Summary or Configure tab and enable or update Carbon Black. You can go to the individual VMs Monitor tab and view VM-specific OS or application level vulnerabilities.
- Sensor Statuses and Details
The Status column on the Carbon Black Cloud Workload Plug-in Inventory > Enabled tab indicates the installation or active state of the sensor, and any admin actions taken on the sensor. [Read more]
As a vCenter Server administrator, you want to have visibility of known vulnerabilities in your environment to understand your security posture and schedule maintenance windows for patching and remediation. With the help of vulnerability assessment, you can proactively minimize the risk in your environment. You can now monitor known vulnerabilities from the Carbon Black Cloud Workload Plug-in. You can discover vulnerabilities from the plug-in Summary tab or from the Vulnerabilities tab and coordinate with your teams to schedule maintenance windows for patches or updates. To view the vulnerability assessment feature, you must enable Carbon Black in your datacenter. After enabling Carbon Black, you can typically view vulnerability data within a few minutes. To read more about our vulnerability feature click here [Read more]
NOTE: These features are only enabled after the Carbon Black appliance is Deployed in vCenter. The Carbon Black Cloud Workload appliance is deployed as a virtual appliance (packaged as an OVA file) on any ESXi host in your vCenter Server environment. After the appliance is deployed, you must register the appliance with the vCenter Server. You must then configure the appliance to establish a connection between the Carbon Black Cloud console and the on-premises appliance deployed in the vCenter Server. After the connection is established, the appliance imports the virtual machine inventory data to the Carbon Black Cloud console. You can then enable Carbon Black on Windows and Linux VMs. For instructions on how to deploy the appliance follow this guide - How to Install Carbon Black Appliance.
Section 3: Identifying Risks with vCenter Carbon Black Cloud Workload Plug-in
VMware Carbon Black Cloud Workload Protection consolidates multiple datacenter security capabilities with an agentless deployment experience on vSphere and a single lightweight sensor for your workload environment. By leveraging the agentless deployment capability within vCenter, we are eliminating the management headaches and console thrashing required when responding to potential incidents by providing security built into the platform and providing native security capabilities as a service that IT infrastructure owners can provide. Thus, minimizing downtime when responding to incidents, always having the latest security capabilities and returning critical CPU cycles back to the business.
While logged into vCenter, click on the Menu button at the top of vCenter and then navigate to and click on the Carbon Black plug-in.
This will bring you to the Workload protection overview pane.
Workload protection has already been deployed on numerous workloads within the TestDrive vCenter environment prior to this guide being written. This allows us to discover and view any risks that have been identified by our vulnerability assessment capability. With this capability there is no scanning involved, because we are already collecting the data, we are leveraging the same single data stream to query and populate this data within the vCenter management plane.
For this part of the walkthrough we are going to focus our attention to the two panes at the bottom of the plug-in screen. Affected Assets and Critical Product Vulnerabilities.
As a vCenter Server administrator, you want to have visibility of known vulnerabilities in your environment to understand your security posture and schedule maintenance windows for patching and remediation. With the help of vulnerability assessment, you can proactively minimize the risk in your environment. You can now monitor known vulnerabilities from the Carbon Black Cloud Workload Plug-in. You can discover vulnerabilities from the plug-in Summary tab or from the Vulnerabilities tab and coordinate with your teams to schedule maintenance windows for patches or updates. To view the vulnerability assessment feature, you must enable Carbon Black in your data center. After enabling Carbon Black, you can typically view vulnerability data within a few minutes.
Carbon Black looks into vulnerabilities related to:
- Operating System (OS) of a virtual machine.
- Windows OS: Displays OS-level vulnerabilities for Windows VMs. The system looks for OS details and the security patches applied on each VM. When the security patch associated with the vulnerability is not applied, the VM is flagged as vulnerable.
- Linux OS: Displays OS-level vulnerabilities for Linux VMs. The system looks for OS details with the list of all installed packages. System determines the vulnerable packages installed on the VM and reports the CVEs against those packages.
- Applications installed on the virtual machine.
- Windows Apps: Displays application-level vulnerabilities for the Windows VMs.
- Linux Apps: Displays application-level vulnerabilities for the Linux VMs.
Critical severity is the default in the preview pane, this is done to highlight where risk mitigation should take place first. We can either click and navigate to the assets with the most severe CVE’s or we can click on the critical product vulnerabilities to understand what high-risk vulnerabilities exist in the environment.
For this exercise lets click on VIEW ALL under the Critical Product Vulnerabilities.
You will be brought to the main Vulnerabilities page in vCenter, with it always defaulting to the Critical View category.
To go to the list of all vulnerabilities available on the Vulnerabilities tab, click All. The total vulnerabilities are the count of all vulnerabilities across all monitored assets and products (OS, applications, versions).
Depending on how you want to view the vulnerability data, you can either view the Asset View tab or the Vulnerability View tab. Use the Asset View tab to view which assets have known vulnerabilities. Use the Vulnerability View tab to view the list of all vulnerabilities on all the assets.
Each VM can have multiple vulnerabilities and each vulnerability can have different risk scores. Based on the risk score, vulnerabilities are filtered on the level of severity such as critical, important, moderate, and low. The higher the risk score, the higher the severity. The highest risk score is considered as a critical vulnerability.
How VMware Carbon Black Measures Risk
Carbon Black Cloud partners with Kenna Security to leverage the largest database of vulnerability, exploit, and event threat data in the industry. This data is distilled into three main measures of risk:
- Active Internet Breach: Presence of a near-real-time exploitation.
- Malware Exploitable: Availability of an exploit module in a weaponized exploit kit.
- Easily Exploitable: Availability of a recorded exploit.
There are metrics defined for Common Vulnerability Scoring System (CVSS). A few of the metrics are about the attack method itself, whereas the others depend on how the application assesses impact - the direct consequence of a successful exploit. To learn more about CVSS, visit https://www.first.org/cvss/specification-document.
Every vulnerability is assigned a risk score of between 0.0 (no risk) and 10.0 (maximum risk). The risk score range and severity are defined as follows.
To learn more about how the risk is calculated, refer the Kenna Security documentation available at https://cdn.www.carbonblack.com/wp-content/uploads/VMWCB-Whitepaper-Understanding-the-Kenna-Security-Vulnerability-Risk-Score.pdf.
Now that we understand how risk is measured let’s go ahead and view a critical high severity vulnerability. Click on Critical at the top of the vulnerability page then click on the vulnerability view at the bottom of the page.
We should now see only Critical High-Risk score CVE’s, these are CVE’s that are actually exploitable with in this environment. This means an attacker (external or internal) could gain access to a workload by leveraging one of these CVE’s in an attack if discovered. For this walk through we are going to focus on one of the most critical CVE’s on this list, CVE-2020-1472. Click on the drop-down arrow on the left to get additional details on the CVE.
This view gives us critical details as to the description of the vulnerability, what assets (workloads) have this critical CVE, our risk score details, as well as the related CVSS details.
CVE-2020-1472 is a vulnerability that could allow an attacker to spoof an active directory domain controller account that could then be used to steal domain credentials and take over the domain.
Depending on your role in the organization, there are a few different ways we can now help mitigate this highly exploitable CVE in our environment.
But first we need to ask ourselves a few questions:
- Has this exploit been leveraged in my environment?
- How can I mitigate this risk?
- How else can I verify this risk exists in my environment?
- What does my security team know about this risk?
In this part of the walkthrough where are going to take the part of the Infrastructure operator / admin that has patching responsibilities to the guest operating systems and focus on question #2 .
The Fixed By KB article link provides detailed information directly from Microsoft on what set of patches resolve this particular CVE.
Once the patch has been applied, we can click on an affected asset in which we will then be redirected to the individual workload monitor page where all application and OS vulnerabilities will be displayed for that specific workload. We can now click on the REASSESS NOW link to verify that the critical CVE has been patched for that specific workload. The CVE’s that have been resolved will no longer appear in the list if it has been resolved properly.
Section 4: Identifying Risks with Carbon Black Cloud Security Console
Ok, now let’s switch roles and put on our security hat. As a security administrator / operator our role is to focus on policy, identification of risk and how we can mitigate risk from a security perspective when patching can’t take place that very moment.
Security should be asking the same set of questions just as the IT administrator has asked:
- Has this exploit been leveraged in my environment?
- How can I mitigate this risk?
- How else can I verify this risk exists in my environment?
- What does my IT team know about this risk?
Let’s first start by logging into the Carbon Black Cloud security console
On the desktop, launch the shortcut named “Carbon Black Cloud”.
Log in with the credentials below.
Username: (listed in text file Carbon_Black_Demo_Credentials.txt on the Carbon Black desktop)
Password: (listed in text file Carbon_Black_Demo_Credentials.txt on the Carbon Black desktop)
When you log in to the Carbon Black Cloud, you will first see a Dashboard containing a visualized snapshot of key information about your organization’s environment. The dashboard provides a high-level overview of your environment and enables you to quickly navigate to items of interest. You can customize the dashboard tiles and display data for specific time periods and policies.
The Dashboard has been configured to give my security team and me the relevant security information as it pertains to my environment. For this exercise let's click on Vulnerabilities on the left pane, but you can also click on the vulnerabilities on the dashboard to bring you to the same page.
The security team now has near real time visibility as to what assets have present critical vulnerabilities in their vCenter environment. This visibility provided is the same visibility that has been given to the IT team to allow for better conversation on how these risks can be mitigated. Because our focus is on CVE-2020-1472 ( ZeroLogon) lets get a better understanding of what assets are affected inside of this view.
Click on the arrow on the right to get additional details about the specific CVE.
We can see similar details about the CVE risk as well as the KB made available by Microsoft. If we click on the arrow next to critical (10) in the risk section we will get expanded details of the CVE and its risk.
Now as a security practitioner I understand the criticality of this CVE. Let’s see what assets are affected by this CVE within the Carbon Black console.
Click on the ( X ) to the right of the risk assessment. And let’s click on the arrow next to affected assets.
Security now has an identified list of assets that contain this critical vulnerability. Now vulnerability at the time of this walkthrough is only available for vCenter provisioned workloads but we can also query our other workloads that are non vCenter provisioned such as in the public cloud or a physical workload that has the same sensor deployed in the server OS.
Let's click on the X to close the Affected Assets window.
In the left pane let's click on the Live Query section.
Then click on New Query.
We are now going to leverage our live query capability. Live Query allows the security operator or an IT administrator to inspect endpoints / workloads in real time and quickly identify areas for improved security and IT hygiene. You can Run a query, you can also get and run recommended queries created by CB security experts. Craft advanced queries using SQL Query Schedule queries to run daily, weekly, or monthly.
Some of the query use cases that can be leveraged are as follows.
Query Use Cases
IT Hygiene: Provides a list of SQL queries that we recommend you run in Live Query to help with your organization's IT Hygiene.
Compliance: Provides a list of SQL queries that we recommend you run in Live Query to help manage Compliance across your organization.
Incident Response: Provides a list of SQL queries that we recommend you run in Live Query to help during an investigation.
Vulnerability Management: Provides a list of SQL queries that we recommend you run in Live Query to help with Vulnerability Management in your organization.
Help Desk Operations: Provides a list of SQL queries that we recommend you run in Live Query to help with Help Desk items.
Container Support: Provides a list of SQL queries that we recommend you run in Live Query to help with your organization's Container Support.
For this exercise we are going to leverage a pre-built and tested query for this particular exploit that’s has been created by our VMware TAU Team (Threat Analysis Unit). This is one of the benefits of leveraging the VMware Carbon Black Cloud, the ability to leverage a large threat team and the data to be able to identify configurations that identify known critical risks.
Let’s search for the particular identified CVE we have discovered inside of vCenter and see if we have other assets that are susceptible to this attack. Type in "CVE-2020-1472" and hit Enter.
You will be shown a list of queries tied to this particular CVE.
Now lets go ahead and schedule a query for our environment to get a better understanding of what additional workloads may be susceptible to this vulnerability by querying our OS’s for particular settings that have been identified by our threat team that leaves the OS exposed to that particular threat.
We can then click on our Query Results and see what additional workloads have been identified.
Let’s click on the query results that we just scheduled.
We are now given the query results of all of the workloads that have not enabled the registry enforcement for net logons potentially mitigating the exploit via a registry setting. Let’s search for the workload that has been identified via our vulnerability capability. In the search bar we can see the query was run on the same workload that displayed the same vulnerability in the previous section.
We have now Identified in multiple ways how we can identify a risk in our environment.
Section 5: Detecting and Responding to Attacks with Carbon Black Workload Protection
As we proceed to this next section on Detecting and responding to specific attacks, we are going to continue to focus on our ZeroLogon exploit ( CVE-2020-1472) .
Let’s ask ourselves the next question: Has this vulnerability been exploited in my environment?
Because we are collecting all of the data on a single data stream, we can look for indicators of compromise in a few different areas. Let’s focus on a specific workload where we know the asset is an in production active directory workload that is critical to our infrastructure.
Click on Inventory on the left pane then click on VM Workloads and in the search bar type in CBW. Let's click on CBWLTD\App-tier-2-l
When we click on the workload, we will be brought into our investigate page.
This page allows us to see every execution being done by the workload. We can search a vast amount of data and criteria to see if there is anything anomalous occurring within the workload. Being that we understand that this workload is vulnerable to the CVE we have identified earlier, let's click over to the Processses tab and see if there have been any identified suspicious hits on this workload that we may want to investigate. We are able to see two alerts.
These alerts have been flagged by our watchlists.
What are Watchlists?
Watchlists provide custom detection that monitors your environment for potential threats and suspicious activity.
How do Watchlists work?
Watchlists include threat reports that track specific incidents of compromise (IOCs). The watchlist detects the presence of the report’s IOCs in your environment.
How do I view results?
Select a watchlist to view and take action on hits detected in your environment. Click Reports for detail on each report in the watchlist. Click the report name to tune the IOCs.
How do I add Watchlists?
You can subscribe to watchlists curated by security experts or build your own by combining threat reports. Click “Add Watchlists” to view available watchlists and reports.
Because of the level of complexity of this attack and the way this exploit is carried out, we can see and search for additional anomalous activity tied to a framework such as MITRE or other TTP’s (Tactics , Techniques and Procedures ) Carbon Black sensors capture and analyze TTPs (MITRE ATT&CK® is a globally-accessible knowledge base of tactics and techniques).
First let's click on Enforce on the left pane, then we will want to navigate to Watchlists and then click on the 1st watch list ATT&CK Framework.
We then want to navigate to the investigate button on the right of the watchlists.
This will bring us to every watchlist hit that has been seen in the platform tied to any sensor that the organization has been deployed.
Next, let’s enter some search criteria in order to narrow down our workload any any events that may seem suspicious.
We are going to put in the search bar device_name:CBWLTD
This will give us all the results for that particular device and any behavior that may be tied to a potential malicious behavior described in the Mitre framework. We are then going to narrow our search further. Because we know that our exploit gains administrative privileges during the exploitation, we are going to only want to see anything that has been flagged as being executed by the administrator. Proceed to click on the left pane under Username and select CBWLTD\Administrator.
This will show all executions by administrator executing CMD.exe.
At this point we can see CMD has been executed multiple times within the span of a few seconds. Click on the box on the right to dive into the process analysis of that execution.
After we click on the process analysis tree, we are brought into a detailed view of how and where these processes were executed and what services executed those processes tied to an account.
Select any of the CMD.exe’s and take note of what the command line arguments are at the top or on the right of the process tree.
We can see on the cmd.exe we have selected in this walkthrough the command line arguments are shown here.
This gives us a pretty good idea that something malicious has executed and is most likely the ZERO logon exploit currently being actively exploited in this environment.
We have successfully hunted down an attack that was exploited in our environment.
5.1 Responding to a Discovered Attack
Once we have discovered the attack, what are some of the next steps we can take to mitigate this attack in real time and potentially stop the attack from happening without disrupting our production AD environment?
As we dive deeper into mitigating this exploit within the same page as above, we are going to view a detailed event log and try to figure out how we can prevent this execution from taking place so that this exploit will fail and still be alerted. So let us take a look.
The section below the process analysis tree is the timeline of events that show an event log of what happened during the execution of CMD.exe.
Notice we have a file-mod. We can now take what we have discovered and do two things. We can create a watchlist for this specific exploit and set an alert severity and we can also possibly create a prevention rule that would mitigate this type of attack as it relates to zero logon.
Note: Keep in mind this is just one way this exploit can be used and in a real-world scenario you would want to ultimately patch your environment. This exercise here is to demonstrate a proactive approach to ensuring critical exploits are not active in your environment and ways you could potentially mitigate an exploit until patching can be done.
Creating a Custom Watchlist
So now that we understand what we are looking for we can create a watchlist for this type of behavior and be alerted should this be seen in our environment.
For the purposes of this walkthrough the custom watchlist has already been created. To view the custom watchlist, click on Watchlists in the left pane of the Carbon Black Cloud console. Click on ZeroLogon then click on Reports.
Then click on the highlighted blue link CVE-2020-1472 Zerologon.
You will then see the actual query that was built to detect the exploit.
We can further verify this detection is functioning correctly by clicking on the investigate to the right of the query and edit button.
Section 6: Alerts
Alerts indicate known threats and suspicious behavior across workloads. Turn group alerts ON to efficiently manage and dismiss alerts across multiple devices. Turn group alerts OFF to manage alerts individually.
Click on Alerts from the left hand side of the Carbon Black Cloud Console.
For this guide there is a set of pre-generated attacks that we will walkthrough. Please ensure that your time frame is set to a 3hr window.
Once the time frame has been set to 3 hours you should see 2 alerts in the alerts dashboard for either for app-tier-1-v or app-tier-2-v.
Click on the > sign under the Actions column to expand and view additional information, including the TTPs associated with the alert.
Alerts are separated into two categories, indicated by the color of the alert:
- Threat: Coded with the color red, located in the Priority filter. These alerts are highly likely to be malicious activity.
- Observed: Coded with the color yellow, located in the Other activity filter. These alerts are a set of behavioral data that have not been raised to the level that requires a response, but do have interesting behavior.
Alert severity indicates the relative importance of an alert; you can use this to identify events that might require rapid triage and response. Alert severity is loosely mapped to the Attack Stages Panel on the dashboard.
Level 1 and 2 alerts: Detect activities such as port scans, malware drops, changes to system configuration files, persistence, etc.
Level 3, 4, and 5 alerts: Detect activities such as malware running, generic virus-like behavior, monitoring user input, potential memory scraping, password theft, etc.
Level 6+ alerts: Typically an active exploit, reverse command shells, process hollowing, destructive malware, hidden processes and tool sets, applications that talk on the network but should not, etc.
Report severity indicates the relative importance of a threat report alert; you can use this to identify watchlist hits that might require response. The severity of a report is determined by the creator of the report. If you create your own report, you can determine the report's severity, with 1 being the least severe, and 10 being the most severe.
The target value acts as a multiplier when calculating the threat level for detected issues and resulting alerts. Target values are defined by the policy to which a device belongs.
Low Target Value: Results in a lower threat level.
Medium Target Value: Represents the baseline/default (no multiplier).
High/Mission Critical Target Values: Both values increase the threat level under the same circumstances. You may see two or more alerts with identical descriptions but with different alert severities.
Click the Alert Triage icon to access a visualization of your selected event or process.
Alert Triage - visualizing alerts
Access a visualization, or process tree, of your alerts by clicking the Alert Triage icon from the Alerts page. Each event in the attack stream (process, file, or network connection) is shown in the process tree as a node with the attack origin displayed on the left and each subsequent event shown from left to right as the attack progressed. Click a node to view additional information and take action in the Selected Node collapsible panel.
- Operating System/Root Node: The root node at the far left of the process tree represents the host device on which the original activity took place. The root node icon represents the operating system that was running on the device.
- Gears/Processes: Processes that have run or are still running.
- Documents/Files: Files that were created on disk.
- Network Connections/IP addresses: IP addresses are shown as network connection icons.
Note: If an operation is denied, an exclamation point (!) displays next to the denied process. If a process is terminated, an X displays next to the terminated process.
- Invoked: A solid line indicates that one process invoked another process, file, or network connection.
- Injected: A dashed line indicates that one process injected code into another process.
- Read Memory: A dotted and dashed line indicates that one process attempted to read the virtual memory of another process (but did not inject into the process).
- Accessed Target: A dotted line indicates that one process attempted to enter another process (but did not inject into the process).
The Actual Attack
In viewing each of the executed processes on the selected node you get a detailed view on how that process was executed during the that phase of the attack / execution.
On the right had side you will get additional details on the policy action , the reputation and the actual command line arguments of the process.
Enriched events are events that have been determined to be of interest. The Carbon Black Cloud analyzes unfiltered data on all endpoints / workloads to highlight events that may be of interest based on types of behavior more likely to be associated with malicious activity, including 110+ core behaviors known to be leveraged by attackers.
For example, look at this event:
Certutil.exe downloading content from a suspicious website. We are able to do DNS resolution when available as well as show the command line execution along with the alert severity and TTP’s tied to this event.
This concludes our walkthrough. Thank you for your time come back soon and try another walkthrough.