In the Event Collection section of the Create Group or Edit Group panel, you can define which types of events to record for the sensors in this group by selecting/deselecting event types.

Disabling event collection impacts visibility, but can improve sensor and server performance. Disabling Process Events or Windows Events can cause an "Event Loss" message in the console.

The Event Collection options are explained here:

  • Process information – Collects process metadata such as starts, stops, and process id (PID).

  • Process user context – Enables the sensor to record the user name that is associated with each running process. This associates endpoint activity with the operating system user account.

  • File modifications (Filemods) – 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 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. This option can be enabled or disabled independently of filemod collection by deselecting Non-binary file writes. This option is not available with macOS or Linux sensors.

    • File deletion – the deletion of an existing file.

  • Binary module loads (Modloads)

    • Reported as a result of LoadImageNotify kernel callback and triggered when a binary is mapped into memory.

    • This is the only place in the binary load/execution chain where Windows provides a supported interface to register for notifications.

    • There are conditions where a binary is mapped, but is not subsequently executed. For example: LoadLibaryEx() where the dwFlags parameter includes LOAD_LIBRARY_AS_IMAGE_RESOURCE or DONT_RESOLVE_DLL_REFERENCES. Windows does not distinguish between binaries that are loaded for execution and binaries that are loaded as a resource.

  • Network connections (Netconns) – Carbon Black EDR captures network connections that have the following characteristics:

    • TCP over IPv4 or UDP over IPv4 connections.

    • Inbound and outbound connections:

      Network connections record TCP or UDP protocol, the remote IPv4 address, port and the domain name associated with the remote IPvAddress.

      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.

      For outbound connections that are 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.

      For DNS/DHCP servers, high CPU and/or memory can be seen due to the high number of netconn events. Instead of disabling all netconn events, disable DNS capture on that machine.

  • Fileless script loads – Collection of fileless_scriptload events through an integration with Microsoft Antimalware Scan Interface (AMSI). Forwarding of these events through the Event Forwarder was introduced in Carbon Black EDR Server 7.2.0 and Carbon Black EDR Windows Sensor 7.1. However, full support of this event type, including storage, console display, and API support, is available in Carbon Black EDR Server 7.6.0. The fileless_scriptload event represents each occasion when the sensor detects PowerShell script content that was executed by any process on a supported endpoint. For more information about AMSI, see the Carbon Black EDR Integration Guide.

  • Cross process events – Enables the sensor to record instances when a process crosses the security boundary of another process. Although some of these events are benign, others might indicate an attempt to change the behavior of the target process by a malicious process.

    Certain limitations exist on the cross process events that are reported by the sensor:

    • Parent processes that create cross process events to their children are not reported.

    • Cross process events that are part of the normal OS behaviors are ignored. For example, no cross process events are recorded for the Windows process csrss.exe .

    • Cross process events are not reported for macOS or Linux sensors.

    • Cross process, open process, and open thread events are not supported on Windows XP and Windows 2003.

  • Registry modifications – Carbon Black EDR captures four types of registry activity from both the machine (HKEY_LOCAL_MACHINE or HKLM) and user (HKEY_USERS or HKU) registry hives:

    • Registry key creation

    • Registry key deletion

    • Registry value modification – the creation or modification of a registry value of any type

    • Registry value deletion

  • EMET events

    • Used in conjunction with the EMET Protection feed to report EMET events on the endpoint.

    • EMET must be installed on the Windows endpoint. Recent operating systems replace EMET with Defender Exploit Protection; this is not currently supported.

  • Binaries (physical storefiles) – Carbon Black EDR collects binary files, such as Windows PE files (EXEs, DLLs, SYS), OSX binaries, and Linux ELF binaries. For binaries that are larger than 25MB, the first 25MB of the binary is captured. Binaries are compressed before they are transmitted to the Carbon Black EDR Server. The server stores one copy of each unique binary.

  • Binary info (binary metadata) – Carbon Black EDR captures metadata about binaries that are 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