EDR: What are the Details Behind the Event Collection Types?
search cancel

EDR: What are the Details Behind the Event Collection Types?


Article ID: 287899


Updated On:


Carbon Black EDR (formerly Cb Response)


What are the Details Behind the Event Collection Types?


  • EDR Console: All Versions
  • EDR Sensor: All Versions
  • Microsoft Windows: All Supported Versions
  • macOS: All Supported Versions
  • Linux: All Supported Versions


Process Events

Process Information:
  • Collects process metadata such as starts, stops and process id (PID)
Process User Context:
  • Collects the user name associated with the events
File Modifications (Filemods):
VMware Carbon Black EDR captures four types of file system activity: 
  • File creation – the creation of a new file. 
  • File Write – the first time a file is written to after being opened or created. 
  • File Write Complete – the closing of a file that was written to.
    • This event includes both the file path and also the MD5/SHA256 of the written file. The event is only captured for binaries (Windows PE files such as EXE, DLL and drivers), Adobe Docs (PDF), OfficeXML docs (docx, doc, xlsx, xls, pptx, ppt)  and zip archives (zip) that are smaller than 10MB in size.
    • Can be enabled or disabled independently of filemod collection by deselecting "Non-binary file writes"
    • Not available on macOS and Linux sensors
  • File deletion – the deletion of an existing file. 
Binary Module Loads (Modloads):
  • Reported as a result of LoadImageNotify kernel callback, triggered when a binary is mapped into memory.
  • This is the only spot in the binary load/execution chain Windows provides a supported interface to register for notifications
  • There are conditions where a binary is mapped but not subsequently executed. For example: LoadLibaryEx() where dwFlags parameter included LOAD_LIBRARY_AS_IMAGE_RESOURCE or DONT_RESOLVE_DLL_REFERENCES. Windows does not provide a supporting mechanism to distinguish between binaries loaded for execution and binaries loaded as a resource
Network Connections (Netconns):
VMware Carbon Black EDR captures network connections with the following characteristics: 
  • Both TCP over IPv4 or UDP over IPv4 connections 
  • Both inbound and outbound connections 
    • Network connections record TCP or UDP protocol, the remote IPv4 address, port and the domain name associated with the remote IPv4 Address
    • Inbound connections capture the local port. If the sensor is installed on a typically configured web server, the reported port is 80. 
    • Outbound connections capture the remote port
    • Outbound connections made after DNS resolution the name that resolves to the captured IPV4 address is also reported
    • The sensor utilizes a passive sensing approach to capturing the domain name, so no additional network traffic is generated in order to capture the name
    • For DNS/DHCP servers, high CPU and/or memory can be seen due to the high number of netconn events. Rather than disabling all netconns, disable DNS capture on that machine. CB Response: Windows Sensor Causing High CPU/memory Utilization on Netconn Intense Server

Windows Events

Cross Process Events (Crossproc):
  • VMware Carbon Black EDR provides a cross-process event type that records an occurrence of a process that crosses the security boundary of another process.
  • While some of these events are benign, others can indicate an attempt to change the behavior of the target process by a malicious process. 
Registry Modifications (Regmods): 
VMware Carbon Black EDR captures four types of registry activity: 
  • Registry key creation – the creation of a new registry key 
  • Registry key deletion – the deletion of an existing registry key 
  • Registry value modification – the creation or modification of a registry value of any type (REG_SZ, REG_DWORD, REG_BINARY, etc.) 
  • Registry value deletion – the deletion of an existing registry value 
Activity is captured from both the machine (HKEY_LOCAL_MACHINE, or HKLM) and user (HKEY_USERS or HKU) registry hives. 

EMET Events:
  • Utilized in conjunction with the EMET Protection feed to report EMET events on the endpoint
  • EMET must be installed on the Windows endpoint, at installation the sensor installer will check for the EMET registry
  • Recent OS's replaced EMET with Defender Exploit Protection, this is currently not supported.

Binary / Module / Storefile Events

Binaries (Physical Storefiles):
  • VMware Carbon Black EDR collects binary files, such as Windows PE files (EXEs, DLLs, SYS), OSX binaries, and Linux ELF binaries. 
  • In the case of binaries that are greater than 25MB in size, the first 25MB of the binary is captured. 
  • Binaries are compressed prior to transmission to the Carbon Black Server. The Carbon Black server only stores one copy of each unique binary collected deployment-wide. 
Binary Info (Binary Metadata):
VMware Carbon Black EDR captures metadata about binaries observed to be executed on the endpoint. This metadata includes: 
  • Size in bytes 
  • Internal version information (file version, product version, etc.) 
  • Digital Signature information (signature status, digital signer, revocation status, etc.) 
  • Icon (if present) 

Additional Information

  • Disabling Process Events or Windows Event types can cause an "Event Loss" message in the console as the sensor will count this as a dropped event, binaries will not cause this