Configure Destination
Navigate to Reflector UI and open Configure Destination page.
This page lists all the destinations, both internal and external, that the events are sent to.
Note: the first three destinations in the configuration interface are reserved for use by Snare Central internally, and cannot be modified. These internal destinations are marked with padlock icon.
View Destinations List
Destinations tab contains two panels:
Left Panel - List of all the destinations and their status indicators
Right panel - Details of the destination selected from the list on the left
Destinations List contains a user-defined name of the destination, or, alternatively, "Destination #" if the name was not provided, and the following status indicators.
Status Indicators in Destinations List
Each destination is shown with the following color-coded status indicators:
Destination Status
- status is Connected or Sending
- status is Connecting
- status is Disconnected
no heart is displayed for Disabled destinations
Destination Enabled
- destination is Enabled
- destination is Disabled. No events will be sent to this destination.
Destination is a Priority
- destination is a Priority. See Destination Details section below for more info.
- destination is Not a Priority
Destination is Locked
- destination is reserved for use by Snare Central internally, and cannot be modified.
Add Destination
Select + Add Destination tab on the Reflector > Configure Destination page.
Aggregation section is displayed only if Aggregation is enabled in General Settings.
Destination details
Define the following Destination details:
Name - Unique user-friendly name of the destination, used for display purposes. Name can contain alphanumeric characters (a-z, A-Z, 0-9), special characters (
~!@$%^()_+=-#) and spaces are allowed.Enable - Indicates whether sending events to this destination is currently enabled
Priority - Indicates whether this destination is considered a Priority destination
A destination can be marked as a priority-delivery queue by switching the Priority ON.
Priority destinations will be allocated both a memory and disk cache to provide a reasonable level of assurance that events will not be lost if the target destination is offline for a short period of time. Non-priority destinations will be allocated a memory cache only.
If any priority destination event queue becomes full, the Snare Reflector will introduce flow control to slow down or stop the rate of event delivery from clients, to ensure events are not discarded when high EPS conditions are occurring. This applies to any destination SIEM systems that may struggle to keep up with the rate of events sent from the Reflector.
It is highly recommended to not use UDP protocol on priority destinations as this protocol does not guarantee delivery due to lack of the receival acknowledgement.
Click near the Priority switch for more information.
IP/Hostname - An IP address or a hostname to which the Snare Reflector should direct log data
Port - The target port on the destination server to send log data to.
Enter port 6161 if sending data to a Snare Server, unless sending encrypted data.
Enter port 514 to send data to a syslog server, unless the syslog server on the destination listens on a non standard TCP/UDP port.Destination Format - Events will be converted to the selected format before being sent to this destination
Snare Server 7.1+ - Logs will be sent using a Snare Central internal format
Syslog RFC 5424 - Logs will be sent using the latest generation of the syslog protocol, with fields parsed from the source log included within the RFC5424 structuredData element.
Syslog RFC 3164 - Logs will be sent using the older generation of the syslog protocol. Note that some information (such as the 'year' in which the log was generated) will be lost, when using this format
QRadar - Syslog RFC 3164 format, but the Reflector will attempt to remove the first tab-delimited field supplied with the incoming event, as long as it does not include internal spaces, in order to work around a QRadar processing issue
RSA Envision - Syslog RFC 3164 format, but the Reflector will prefix a header to the syslog message, which includes the originating IP address, and the date/time in seconds-since-epoch format that the event arrived at the server
RAW - no conversion - No format conversion will be performed
Generic JSON - Both header and event content information is represented in a single-line JSON format. NOTE: field remapping is now supported for this destination format as of v8.8.0 which by default is set to “None”. For more details about field remapping please refer here.
Elasticsearch bulk delivery - Snare internal format for SATI. Events will be batched up and delivered in groups via a HTTP POST upload to elastic. Logs can also be sent to multiple external Elasticsearch installs and Amazon Opensearch (fork of Elasticsearch) installs with different ports, addresses and filtering.
Syslog 5424 JSON - Syslog RFC 5424 header, with JSON payload. In the event that a Snare V2 format log is received, it will be forwarded in the original format, with any extra enhancements inserted as key/value pairs into the Event/Data/SnareDataMap key. NOTE: field remapping is now supported for this destination format as of v8.8.0 which by default is set to “None”. For more details about field remapping please refer here.
Syslog RFC5424 - no structuredData - Logs will be sent using the latest generation of the syslog protocol, but will explicitly avoid injecting field data into the structuredData component of RFC5424, if the source event does not already include structuredData.
CEF - The event will be converted to CEF format, where each event field, will be either implemented as a vendor CEF field in the CEF Extension area, or will be mapped to baseline CEF fields. As at the date of this document, the logs from Snare for Windows agents will include the advanced CEF field mapping.
CEF Syslog RFC3164 - CEF format as discussed above, with a Syslog RFC3164 header
Splunk HEC - Format for delivery to Splunk HTTP Event Collector (HEC) over HTTP/HTTPS protocol
Snare Legacy Realtime Delivery - Snare internal legacy format
Snare v8 Data Exchange (JSON) - Snare internal format and also for use from Snare Central to Snare Central forwarding. NOTE: this can only be used to other 8.4.0+ destinations
Microsoft Sentinel - Format for delivery to Microsoft Sentinel over HTTPS protocol
Securonix Syslog - Syslog RFC 3164 format, but the Reflector will attempt to remove the first tab-delimited field if it is a duplication of hostname in the event header
CEF Example
In general, CEF format will generate data of the following format:
Jan 11 12:25:39 hostname CEF:Version|Device Vendor|Device Product|Device Event Class ID|Name|Severity|[Extension]
eg:
Jan 11 12:25:39 snareserver CEF:0|Snare|SnareReflector|3.2|WinSecurity:4830|2|dvc=snare,SnareReflectorTable=WinSecurity,SnareReflectorUser=Fred
Selecting Splunk HEC format will display additional fields for configuring HTTP/HTTPS connection to Splunk HEC.
For details, please Refer to Sending Logs to Splunk HEC page in this User Guide.
Selecting Microsoft Sentinel format will display additional fields for configuring HTTPS connection to Splunk HEC.
For details, please Refer to Sending Logs to Microsoft Sentinel page in this User Guide.
Protocol - Select one of the following network protocols for data delivery. Note: available options may change based on the selected Destination Format
TCP
UDP
TLS - TCP with TLS encryption. Please ensure the destination system supports the TLS protocol
TLS_AUTH - TCP with TLS encryption and authentication
TLS_AUTH is a Snare proprietary protocol that overlays the TLS connection with authentication between source and destination. The same TLS authentication key needs to be configured on this page and in the Snare Central destinationMTLS - mutual TLS (mTLS) protocol. Select this option when receiver also supports mTLS protocol, for example, when sending events to Devo Syslog ELB
HTTP - HTTP delivery to REST APIs provided by the receiver (available with relevant Destination Formats, such as Elasticsearch bulk delivery and Splunk HEC)
HTTPS - HTTPS delivery to REST APIs provided by the receiver (available with relevant Destination Formats, such as Elasticsearch bulk delivery, Splunk HEC and Microsoft Sentinel)
Selecting MTLS protocol will display additional fields for setting mTLS certificate.
For details, please Refer to Sending Logs to Devo and Manage Certificates page in this User Guide.
If an existing destination with a similar configuration is found, the new destination will still be added, but a warning will be displayed indicating a potential duplicate and showing the name of the existing destination with a similar configuration.
Similar destination configurations are checked based on the following criteria:
General Configuration: Shares the same IP/Hostname, Port, and Protocol.
Microsoft Sentinel Configuration: Shares the same IP/Hostname, Port, Protocol, DCR ImmutableID, and DCR StreamName.
Splunk HEC Configuration: Shares the same IP/Hostname, Port, Protocol, and HEC Index.
Filters
User can define Filters to only forward matching events to the destination.
By default, no filters are applied, and all the events received by Snare Central are forwarded to the destination.
In the Filters section select Add Filter to add a filter. Multiple filters can be added if required.
In each filter, you can use the following selectors to define which events should be sent to the destination.
Systems | Filter by Systems that generated the events. By default, All systems will match the filter Click the selector and use check boxes to choose systems of interest. Use the Search system... field on top of the drop-down to quickly find a system by host name or IP address. |
Log Types | Filter by Log Types. By default, all log types will match the filter Click the selector and use check boxes to choose from available log types. Use the Search Log Type... field on top of the drop-down to quickly find a log type. |
Search Text | Filter by content in any event field, use the Search input field.
|
Filter Mode | Specify whether to INCLUDE or EXCLUDE the events that match the filter. |
Multiple Filters
In some cases user may want to add additional filters to describe multiple rules with different combinations of parameters.
Click Add Filter icon in the Filters section header to add additional filter row
Click Remove Filter icon in the filter row to remove it
Click Move Down and Move Up icons to reorder the filters.
If an event matches both an INCLUDE and EXCLUDE rule, then the last matching rule will be applied. See Example 4 below.
The default behavior for events that do not match any filter depends on the first filter:
If the first filter is set to INCLUDE, then only events that match the filters will be sent to the destination.
If the first filter is set to EXCLUDE, then all events will be sent to the destination, except for those that are specifically excluded by the subsequent filters.
Filter Examples
Example 1
Send only "LinuxAudit" events from selected Ubuntu machines, containing string "login":
Example 2
Send all events, excluding "AgentHeartBeat" log type:
Example 3
Send only events that match the "WinSecurity" log type OR that contain the substring "1234" delimited by tabs for "All Log Types":
Example 4
Send "WinSecurity" events, except events that contain the event ID substring 5156 or 4663 delimited by tabs:
Search Replace
The Snare Reflector can be configured to modify events on the fly per destination, between reception and retransmission.
You can either do the search and replace in the event data based on the incoming format (before converting it to the destination format), or based on the outgoing format (after converting it to the destination format), by simply setting the toggle button to "Apply Search-Replace filters to events in INCOMING format" or "Apply Search-Replace filters to events in OUTGOING format".
Search terms should be specified as RE2 regular expression matches, with optional round brackets, to denote string sub-matches.
Replacement terms can be specified as normal strings, or as a string compatible with the formats specified in ECMA-262, ECMAScript Language Specification, Chapter 15 part 5.4.11 String.prototype.replace. (FWD.1)
Multiple Search-Replace Filters
In some cases user may want to add additional filters to describe multiple Search-Replace rules.
Click Add Filter icon in the Search Replace section header to add a Search-Replace filter row
Click Remove Filter icon in the filter row to remove it
Click Move Down and Move Up icons to reorder the Search-Replace filters.
It is important to note that search-replacements are cumulative. If multiple search-replace rules are defined for a destination, each will operate on the result of the previous search-replace action.
Search-replace actions are case-sensitive.
Search-Replace Filter Examples
A common use for search and replace filters, is to convert delimiters from one character to another.
Example 1
The following displays the command to change the event data delimiters from "\t" (tab) to "|" (pipe) based on the format as it arrives in the Snare Central, then after the changes are made, it will then be converted to the destination format:
Example 2
The following will convert the event data to the destination format first, then after the format conversion, it will then change the event data delimiters from "\t" (tab) to"|" (pipe):
Remapping Template
Fields Remapping in Snare Reflector enables users to transform Snare-native log fields into the specific schema needed by the destination platform. This is achieved by defining a remapping template that translates fields from the original Snare format—such as DATETIME, SYSTEM, EVENTID, or key-value pairs under SNAREDATAMAP—into target-compatible field names like time, host, EventCode and etc.
Remapping Template sample
This option is only applicable to some JSON-based destination formats like Microsoft Sentinel, Splunk HEC, Syslog 5424 JSON, and Syslog JSON and by default is set to None.
For more details about field remapping please refer here.
Aggregation
The Log Aggregation feature in Reflector, available from version 8.8.0, provides the capability for aggregation of similar/duplicate events. It facilitates reflection of duplicate events, received within a defined time period, as a single aggregated event to the configured destination, as shown in the below example.
Duplicate Events:
-----------------
<134>1 2026-03-17T13:00:00.010955+10:30 myagent.snare.test SnareReflector - MSWinEventLog2 - 1 {"Event":{"Data":{"EventLogCounter":"487","LogString":"[SDP Volume] Volume query returned volume GUID {yyyy2222-yy22-yy22-yy22-yyyyyy222222}, drive letter C, label , is clustered? false."},"System":{"Channel":"Microsoft-Windows-SystemDataArchiver/Diagnostic","Computer":"myagent.snare.test","Correlation":{"ActivityID":"{f5adbb21-97a2-416d-9494-430d0a707a27}"},"EventID":"2050","EventRecordID":"67262494","Execution":{"ProcessID":"1788","ThreadID":"4996"},"Keywords":"0x8000000000000000","Level":"4","Opcode":"0","Provider":{"Guid":"{xxxx1111-xx11-xx11-xx11-xxxxxx111111}","Name":"Microsoft-Windows-SystemDataArchiver"},"Security":{"UserID":"S-1-5-19"},"Task":"0","TimeCreated":{"LocalTime":"2026-03-17T13:00:00.010955+10:30","SystemTime":"2026-03-17T02:30:00.0109558Z"},"Version":"0"},"xmlns":"http://schemas.microsoft.com/win/2004/08/events/event"}}
<134>1 2026-03-17T13:03:00.013227+10:30 myagent.snare.test SnareReflector - MSWinEventLog2 - 1 {"Event":{"Data":{"EventLogCounter":"570","LogString":"[SDP Volume] Volume query returned volume GUID {yyyy2222-yy22-yy22-yy22-yyyyyy222222}, drive letter C, label , is clustered? false."},"System":{"Channel":"Microsoft-Windows-SystemDataArchiver/Diagnostic","Computer":"myagent.snare.test","Correlation":{"ActivityID":"{f5adbb21-97a2-416d-9494-430d0a707a27}"},"EventID":"2050","EventRecordID":"67262694","Execution":{"ProcessID":"1788","ThreadID":"4996"},"Keywords":"0x8000000000000000","Level":"4","Opcode":"0","Provider":{"Guid":"{xxxx1111-xx11-xx11-xx11-xxxxxx111111}","Name":"Microsoft-Windows-SystemDataArchiver"},"Security":{"UserID":"S-1-5-19"},"Task":"0","TimeCreated":{"LocalTime":"2026-03-17T13:03:00.013227+10:30","SystemTime":"2026-03-17T02:33:00.0132270Z"},"Version":"0"},"xmlns":"http://schemas.microsoft.com/win/2004/08/events/event"}}
<134>1 2026-03-17T13:04:00.014469+10:30 myagent.snare.test SnareReflector - MSWinEventLog2 - 1 {"Event":{"Data":{"EventLogCounter":"599","LogString":"[SDP Volume] Volume query returned volume GUID {yyyy2222-yy22-yy22-yy22-yyyyyy222222}, drive letter C, label , is clustered? false."},"System":{"Channel":"Microsoft-Windows-SystemDataArchiver/Diagnostic","Computer":"myagent.snare.test","Correlation":{"ActivityID":"{f5adbb21-97a2-416d-9494-430d0a707a27}"},"EventID":"2050","EventRecordID":"67262762","Execution":{"ProcessID":"1788","ThreadID":"4996"},"Keywords":"0x8000000000000000","Level":"4","Opcode":"0","Provider":{"Guid":"{xxxx1111-xx11-xx11-xx11-xxxxxx111111}","Name":"Microsoft-Windows-SystemDataArchiver"},"Security":{"UserID":"S-1-5-19"},"Task":"0","TimeCreated":{"LocalTime":"2026-03-17T13:04:00.014469+10:30","SystemTime":"2026-03-17T02:34:00.0144695Z"},"Version":"0"},"xmlns":"http://schemas.microsoft.com/win/2004/08/events/event"}}
Aggregated Event:
-----------------
<134>1 2026-03-17T13:00:00.010955+10:30 myagent.snare.test SnareReflector - MSWinEventLog2 - 1 {"Event":{"Aggregation":{"Occurrences":"3","Window":"5 min"},"Data":{"EventLogCounter":"487","LogString":"[SDP Volume] Volume query returned volume GUID {yyyy2222-yy22-yy22-yy22-yyyyyy222222}, drive letter C, label , is clustered? false."},"System":{"Channel":"Microsoft-Windows-SystemDataArchiver/Diagnostic","Computer":"myagent.snare.test","Correlation":{"ActivityID":"{f5adbb21-97a2-416d-9494-430d0a707a27}"},"EventID":"2050","EventRecordID":"67262494","Execution":{"ProcessID":"1788","ThreadID":"4996"},"Keywords":"0x8000000000000000","Level":"4","Opcode":"0","Provider":{"Guid":"{xxxx1111-xx11-xx11-xx11-xxxxxx111111}","Name":"Microsoft-Windows-SystemDataArchiver"},"Security":{"UserID":"S-1-5-19"},"Task":"0","TimeCreated":{"LocalTime":"2026-03-17T13:00:00.010955+10:30","SystemTime":"2026-03-17T02:30:00.0109558Z"},"Version":"0"},"xmlns":"http://schemas.microsoft.com/win/2004/08/events/event"}}By configuring this functionality, you can reduce disk space usage at the destination, particularly for events that recur frequently or can be considered as noisy. Thus, Snare Reflector can be configured to optimize the handling of recurring events with minimal forensic value.
Log Aggregation should be defined for each destination, through what is called an Aggregation Rule. Each rule defines the criteria that determine which events should be considered for aggregation, along with the associated aggregation window. When an incomming event matches the specified criteria, it is processed further by the aggregator. Duplicate or similar events arrived within the aggregation window time frame, are grouped together and forwarded to the destination as a single aggregated event, along with the aggregation data carrying occurrence count and time window. The time window is reset after the aggregated events are sent to the destination on the window expiry and the next window is restarted.
Aggregation Configuration
Turn on Enable Aggregation in General Settings to be able to configure event aggregation rules.
To configure event aggregation, the following fields must be defined. This will allow you to specify how events are grouped and forwarded to the destination.
Exclude Aggregation Data - Indicates whether the aggregated event, while sending to this destination, will carry the occurrence count and time window. Aggregation data is added to the event by default. Toggle this option ON to exclude additional aggregation data.
Aggregation Rule - Rule that defines the the criteria for events to be considered for aggregation.
Aggregation Rule
User can configure an Aggregation Rule to define event criteria for aggregation. By default, no rules are applied, and all the events received by Snare Central are forwarded to the destination as individual event, without being processed for aggregation.
In the Aggregation section, select Add Aggregation to add an aggregation rule. Multiple rules can be added if required.
In each Aggregation Rule, you can use the following selectors to define which events should be considered for aggregation while sending to the destination.
Log Types | Select events for aggregation by Log Types. By default, no log type will match the rule. Click the selector and use check boxes to choose from available log types. Use the Search Log Type... field on top of the drop-down to quickly find a log type. |
Filter Type
| Select type of selector to be used for identifying events for aggregation. By default, EventID is set to be the Filter Type. Click the selector and use check boxes to choose from available filter types - EventID and EventFields. |
EventID
| If you select EventID in Filter Type, add EventID which identifies the events to be considered for aggregation. Multiple values are supported. Minimum of 1 event ID must be added and maximum of 10 event IDs can be added. |
Event Fields
| If you select Event Fields in Filter Type, add one or more event fields which identifies the events to be considered for aggregation. Specify the text that should appear in specific event field by clicking the Event Fields selector. A filter can be used to quickly find a field of interest. Click > to reveal an input field, and enter your criteria in the field. Multiple values are supported. |
Aggregation Window | Specify the Aggregation Window in minutes, which defines the time period within which duplicate or similar incoming events are aggregated as a single event. |
Aggregation Rule with Filter Type EventID
If you select EventID as Filter Type, match of specified EventIDs, identifies the events to be considered for aggregation. You can specify one or more Event IDs, pressing Enter after each value. If an incoming event matches one of the EventIDs from the list, it will be considered for aggregation.
Aggregation Rule with Filter Type Event Fields
If you select Event Fields in Filter Type, match for specified text in the selected event fields, identifies the events to be considered for aggregation. One or more Event Fields can be selected from the drop down list and a text must be specified for each field type. Each configured event field must exactly match the corresponding value in the incoming event, regardless of case. Multiple values are supported for each event field, and at least one of these values must match the event.
Multiple Aggregation Rules
In some cases user may want to add additional rules to describe multiple aggregation criteria with different combinations of parameters.
Click Add Aggregation Rule icon in the Aggregation section header to add additional rule.
Click Remove Aggregation Rule icon in the aggregation rule row to remove it.
If an event matches multiple aggregation rule, then the first matching rule will be applied.
Events with Aggregation Data
When duplicate/similar events are reflected to the destination, the event is appended with aggregation data, which contains the time window of the aggregation and the occurrence count of the event within the time period. The event received at the destination is a single event which is the first of the duplicate events arrived within the window period, matching the defined configuration and is appended with the aggregation data. The appended aggregation data is in one of the following formats, depending on the outgoing and incoming formats, such as SNARE and SNAREV2.
Example of Aggregation Data accross various formats:
Aggregation={"Occurrences":"100","Window":"3 min"}
"Aggregation":{"Occurrences":"90","Window":"3 min"}
Aggregation/Occurrences=84 Aggregation/Window=3
Log Aggregation is not supported at this stage, when incoming event to the Reflector is in SYSLOG format.
Events with Aggregation Data Example
Operational Considerations
The following limitations should be considered when configuring aggregation rules to ensure optimal performance and reliability.
Maximum Event IDs per Aggregation Rule
The Reflector performs additional processing for each configured Event ID within a rule. As the number of Event IDs increases, the processing load per event also increases.
To maintain balanced Events Per Second (EPS) performance, each Aggregation Rule supports a maximum of 10 Event IDs.
Number of Aggregation Rules per Destination
Each additional Aggregation Rule configured for a destination increases the processing overhead for incoming events. To ensure optimal EPS performance, it is recommended to limit the number of Aggregation Rules per destination.
Service Shutdown Behaviour
During a graceful shutdown of the Snare Reflector service, the following behavior applies.
If an aggregation window has not yet expired, the partially aggregated event will be handled on the next service start-up. Upon service restart, the Reflector will send the partially aggregated event to the destination.
The event will include the actual elapsed aggregation window (for example, 5 minutes instead of a configured 10 minutes if shutdown occurred midway), an the total number of event occurrences recorded during that time.
This behaviour applies only to priority destinations. For non-priority destinations, any partially aggregated events at the time of shutdown will be lost.
Add Destination and Restart Reflector
After entering all the destination details, click ADD DESTINATION at the bottom of the dialog.
Snare Reflector needs to be restarted for the changes in destination configuration to take effect. Events received via UDP connection may be lost during service restart.
Confirmation screen is displayed:
Select ADD AND RESTART to save the new destination and restart the Snare Reflector service
or
Select ADD WITHOUT RESTART to save the new destination without restarting the Snare Reflector service. This may be useful if several destinations need to be added/modified prior to restarting the service.
or
Select CANCEL to cancel the saving operation and return to Add Destination dialog.
Reflector can be restarted at a later stage.
If the changes were saved without restarting, the following banner will be shown at the top of all the Reflector configuration pages:
Click RESTART SNARE REFLECTOR to apply the changes at any convenient time.
View Destination Details
Select Destinations tab on the Reflector > Configure Destination page.
In the left panel select the destination you are interested in. The destination details will be presented in the right panel.
The header of the right panel contain the following information: Destination Name | Destination Status | Filtering information
Aggregation section is displayed only if Aggregation is enabled in General Settings.
For detailed description of all the destination parameters, see Add Destination section above.
Modify Destination
Only user-defined destinations can be modified.
First 3 destinations are reserved for internal use by Snare Central, and cannot be modified. These internal destinations are marked with padlock icon.
Select Destinations tab on the Reflector > Configure Destination page.
In the left panel select the destination that needs to be modified.
Edit any fields of the destination, add/remove filters and search-replace rules as required.
For detailed description of all the destination parameters, see Add Destination section above.
Select Update to save the settings.
Snare Reflector needs to be restarted for the changes in destination configuration to take effect. Events received via UDP connection may be lost during service restart.
Confirmation screen is displayed:
Select UPDATE AND RESTART to update the destination and restart the Snare Reflector service
or
Select UPDATE WITHOUT RESTART to update the destination without restarting the Snare Reflector service. This may be useful if several modifications need to be done prior to restarting the service.
or
Select CANCEL to cancel the update operation and close this confirmation screen
Enable/Disable Destination
Select Destinations tab on the Reflector > Configure Destination page.
Click on the destination to see its details in the right panel.
Use Enable toggle in the right panel to enable/disable the destination.
Select Update to save the settings.
Snare Reflector needs to be restarted for the changes in destination configuration to take effect.
Select UPDATE AND RESTART in the confirmation dialog to proceed.
Note: Events received via UDP connection may be lost during service restart.
The disabled destination will not be displayed on the dashboard.
If an existing destination with a similar configuration is found, the modified destination details will still be saved, but a warning will be displayed indicating a potential duplicate and showing the name of the existing destination with a similar configuration.
Similar destination configurations are checked based on the following criteria:
General Configuration: Shares the same IP/Hostname, Port, and Protocol.
Microsoft Sentinel Configuration: Shares the same IP/Hostname, Port, Protocol, DCR ImmutableID, and DCR StreamName.
Splunk HEC Configuration: Shares the same IP/Hostname, Port, Protocol, and HEC Index.
Delete Destination
Select Destinations tab on the Reflector > Configure Destination page.