Upcoming Carbon Black Cloud Data Forwarder Changes for Netconns and Moduleloads

Back to Blogs

Upcoming Carbon Black Cloud Data Forwarder Changes for Netconns and Moduleloads

Posted on March 12, 2021

The CBC Data Forwarder is making a change to how it handles endpoint.event.netconn and endpoint.event.moduleload events to provide additional visibility for customers on March 22nd.

Netconn

For customers who are using an HTTP proxy, we’re making a change to endpoint.event.netconn events that will use the same approach that the Platform Search API uses to emit netconn & netconn_proxy events:

For organizations whose endpoints do not have an HTTP proxy configured, there will be no change - all netconn events will continue to emit as endpoint.event.netconn type
For organizations with one or more endpoint whose applications are configured to use an HTTP proxy, those endpoints' netconn events will be split into endpoint.event.netconn and endpoint.event.netconn_proxy types
Such proxy-enabled applications make an initial connection to the proxy server to establish communications; all subsequent requests are sent through the proxy server to their ultimate destination.
- That first connection per application will be reported as an endpoint.event.netconn event, whose netconn_remote_ip or netconn_remote_domain are the address of the proxy server
- The subsequent proxied requests for that application will be reported as endpoint.event.netconn_proxy events

Moduleload

The endpoint.event.moduleload events will be split to more granularly report the activity of script hosts that load and execute one or more scripts, as well as the execution of a set of fileless scripted instructions. This will create new event types of either endpoint.event.scriptload or endpoint.event.fileless_scriptload. Scriptload events will be available for both NGAV and EDR event_origin while moduleload and fileless_scriptload will only be available for EDR event_origin.

The moduleload events will be subdivided on the values in the action field:

Moduleload
- ACTION_LOAD_MODULE
- ACTION_LOADED_MODULE_DISCOVERED
- ACTION_UNLOAD_MODULE
- ACTION_INVALID
Scriptload
- ACTION_LOAD_SCRIPT
- ACTION_AMSI_CONTENT_SCAN
Fileless Scriptload
- ACTION_LOAD_FILELESS_SCRIPT

All events will continue to be forwarded, however the expected volume of endpoint.event.netconn and endpoint.event.moduleload events will decrease as some of those events will instead be emitted as endpoint.event.netconn_proxy, endpoint.event.scriptload, or endpoint.event.fileless_scriptload events.

If you have an Data Forwarder enabled with filtering by event type, or your downstream application conditionally operates on event types, you may have to adjust to compensate. We will automatically update any Data Forwarder configurations on behalf of any of our customers who have enabled a filter that specifies the endpoint.event.netconn or endpoint.event.moduleload type, so that such filters also appropriately include endpoint.event.netconn_proxy, endpoint.event.scriptload, or endpoint.event.fileless_scriptload.

What new data comes with this change?

Three new fields will be emitted in endpoint.event.netconn_proxy events: netconn_proxy_ip, netconn_proxy_port and netconn_proxy_domain. These fields will report the address of the proxy server. At the same time, the remote_ip, netconn_domain and remote_port will also be populated in the netconn_proxy events. The contents of these fields will reflect the actual destination requested by the application.

The new fields that are available with endpoint.event.modload, endpoint.event.scriptload, and endpoint.event.fileless_scriptload will provide greater insight into what was loaded or executed. The exact properties can be found in the table below.

The following new fields will be available for each of the corresponding events indicated below.

Event Type	Existing Fields	New Fields
`endpoint.event.netconn`	remote_ip remote_port local_port local_ip netconn_domain netconn_inbound netconn_protocol	N/A
`endpoint.event.netconn_proxy`	N/A	netconn_proxy_ip netconn_proxy_port netconn_proxy_domain And existing fields for `endpoint.event.netconn`
`endpoint.event.moduleload`	modload_name	modload_action modload_count modload_effective_reputation modload_hash modload_publisher
`endpoint.event.scriptload`	N/A	process_loaded_script_hash process_loaded_script_name scriptload_content scriptload_content_length scrip load_count scriptload_effective_reputation scriptload_hash scriptload_name scriptload_publisher scriptload_reputation
`endpoint.event.fileless_scriptload`	N/A	fileless_scriptload_cmdline fileless_scriptload_cmdline_length fileless_scriptload_hash

Examples

Previous netconn behavior

Prior to this enhancement, both the first and all subsequent netconn events are nearly indistinguishable:

First netconn

{
  "type": "endpoint.event.netconn",
  "local_ip": "192.166.0.63",
  "local_port": 49905,
  "process_pid": 1336,
  "netconn_domain": "",
  "remote_ip": "192.166.0.246",
  "remote_port": 3128
}

Subsequent netconn

{
  "type": "endpoint.event.netconn",
  "local_ip": "192.166.0.63",
  "local_port": 49905,
  "process_pid": 1336,
  "netconn_domain": "",
  "remote_ip": "192.166.0.246",
  "remote_port": 3128
}

New netconn behavior

The first netconn-oriented event for each process will still be sent as an endpoint.event.netconn:

{
  "type": "endpoint.event.netconn",
  "local_ip": "192.166.0.63",
  "local_port": 49905,
  "process_pid": 1336,
  "netconn_domain": "companyA.com",
  "remote_ip": "192.166.0.246",
  "remote_port": 3128
}

All subsequent events from that process will be sent as an endpoint.event.netconn_proxy:

{
  "type": "endpoint.event.netconn_proxy",
  "local_ip": "192.166.0.63",
  "local_port": 49905,
  "process_pid": 1336,
  "netconn_domain": "www.google.com",
  "remote_ip": "209.85.145.113",
  "remote_port": 443,
  "netconn_proxy_ip": "192.166.0.246",
  "netconn_proxy_port": 3128,
  "netconn_proxy_domain": "companyA.com"
}

Previous moduleload behavior

Prior to this enhancement, all moduleload events are classified as endpoint.event.moduleload and only include the name of the loaded module. If the event is a fileless scriptload action then the moduleload_name would not be present.

{
  "moduleload_name": "example.dll"
}

New moduleload behavior

Moduleload events will now include more information to provide greater context for the module that was loaded. A module is a separate unit of software - typically a library of supporting code such as .dll or .lib files on Windows. Moduleload events are only supported when event_origin is EDR.

{
  "moduleload_name": "example.dll",
  "modload_action": "ACTION_LOAD_MODULE",
  "modload_count": 1,
  "modload_effective_reputation": "REP_LOCAL_WHITE",
  "modload_hash": "22b3a7293fd146baa4761e956b687fdea355627181c8d3de346f4cb2acdc9b22",
  "modload_publisher": [
    {
      "name": "Microsoft Windows",
      "state": "FILE_SIGNATURE_STATE_CATALOG_SIGNED | FILE_SIGNATURE_STATE_OS"
    }
  ]
}

Scriptload events will include information about the script that was loaded, similar to moduleload. A script differs from a module by the fact that the code can be executed directly using an interpreter such as powershell or bash.

The following event sample is an endpoint.event.scriptload from the NGAV event_origin which is generated by Windows sensors version 3.6+ with Endpoint Standard enabled.

{
  "scriptload_hash": "c6a9a37fd7073d83c6a8e70a7731faa21a48c7aa3a6ce739733aa5726cce3cc1",
  "scriptload_name": "/Users/john.doe/Desktop/example.sh",
  "scriptload_count": 1
}

The following event sample is an endpoint.event.scriptload from the EDR event_origin.

{
  "scriptload_hash": "c6a9a37fd7073d83c6a8e70a7731faa21a48c7aa3a6ce739733aa5726cce3cc1",
  "scriptload_name": "/Users/john.doe/Desktop/example.sh",
  "scriptload_publisher": [
    {
      "name": "VMware, Inc.",
      "state": "FILE_SIGNATURE_STATE_CATALOG_SIGNED | FILE_SIGNATURE_STATE_OS"
    }
  ]
}

A fileless scriptload event will include information about the command line that was either attempted or executed on the endpoint. A fileless script is a set of instructions which are not saved to a file, but instead are loaded within memory without first appearing on the filesystem (e.g. directly downloaded from a C&C server). Fileless scriptload events are only supported when event_origin is EDR.

{
  fileless_scriptload_cmdline: function Invoke-Mimikatz …,
  fileless_scriptload_cmdline_length: 65535,
  fileless_scriptload_hash: 6147b731a5b5cd4a86db01885ea46e0c59a13e121d100c5e67b37c98a7f6006f
}

For further information, please refer to the Data Forwarder Data Guide for the complete reference on forward-able events data.