Export Alerts to Microsoft Sentinel (New)

Integrate Corelight Investigator with Microsoft Sentinel using the Azure Monitor Logs Ingestion API. Investigator streams network alerts to a Data Collection Endpoint (DCE), where a Data Collection Rule (DCR) routes them into a custom table in your Log Analytics workspace, making network data available for analysis alongside your other security telemetry.

Important

This integration replaces the deprecated Microsoft Sentinel integration that used the Azure Log Analytics HTTP Data Collector API (which ceases to function on September 14, 2026).

Prerequisites

Before you begin, ensure you have the following:

• Azure: An active Azure subscription and a Log Analytics workspace, plus:

  • A Data Collection Endpoint (DCE) and a Data Collection Rule (DCR) with a custom table and stream for the Corelight alerts — Step 1 walks through creating these. See Microsoft Learn: Data collection endpoints and Data collection rules.

  • A Microsoft Entra app registration (service principal) granted the Monitoring Metrics Publisher role on the DCR. See Microsoft Learn: Logs Ingestion API.

• Corelight: An operational Corelight Investigator instance.

• Permissions:

  • In Azure: Rights to read the DCE/DCR properties and manage the app registration and its role assignment.

  • In Investigator: Administrator privileges to configure data exporters. Analyst- and viewer-level users can only view existing configurations.

Step 1: Create the custom table, DCR, and DCE in Azure

The Azure portal can create the custom table, its Data Collection Rule, the stream declaration, and the schema in a single wizard, inferring the column list from a sample Corelight alert. Do this before configuring Investigator.

The Log Analytics workspace, the DCR, and the DCE (if you use one) must all be in the same Azure region.

1a. Create a Data Collection Endpoint

1. In the Azure portal, go to Monitor → Data Collection Endpoints → Create.

2. Choose the subscription, resource group, and the region of your Log Analytics workspace, and give it a name (for example, corelight-dce).

3. Select Review + create → Create.

4. Open the DCE and copy the Logs ingestion URI from Overview.

Note

A dedicated DCE is optional. A DCR created with kind: Direct exposes its own logsIngestion endpoint, which you can use in place of a DCE URI — Investigator accepts either, as long as the host ends in .ingest.monitor.azure.com, .ingest.monitor.azure.us, or .ingest.monitor.azure.cn. A DCE is required if your workspace uses Private Link. A DCE cannot be added to an existing DCR afterwards; you would have to create a replacement DCR.

1b. Prepare the sample alert payload

Save the following as corelight-alert-sample.json. It is one representative alert as Investigator sends it.

[
  {
    "alert_entity": {
      "entity_category": "source",
      "entity_id": "IP192.168.56.10",
      "entity_name": "192.168.56.10",
      "entity_type": "IP"
    },
    "alert_id": "e26114cb-002c-41d5-b389-9326f9024f73",
    "alert_info": {
      "alert_name": "ET EXPLOIT_KIT KaiXin Landing M5 1 Oct 05 2015",
      "alert_type": "suricata_corelight",
      "content_id": "SURI-2021905"
    },
    "alert_timestamp_observed": 1783472315,
    "alert_to_detection_url": "https://investigator.corelight.com/alert-to-detections/e26114cb-002c-41d5-b389-9326f9024f73",
    "event_ids": [
      "f4a0f7f4f0ecd2b54815b3d6d3d0cfde"
    ],
    "message": "{\"tenant\":\"protomolecule\",\"sensor\":\"corelight-sensor-02\",\"src_ip\":\"10.12.4.87\",\"dst_ip\":\"203.0.113.45\",\"dst_port\":443,\"proto\":\"tcp\",\"category\":\"Command and Control\",\"mitre\":[\"T1071.001\"],\"alert_timestamp\":{\"start\":\"2026-07-22T14:01:40.000Z\",\"end\":\"2026-07-22T14:02:58.000Z\"}}",
    "score": 6
  }
]

Investigator promotes the alert identity, entity, scoring, and timing fields to the top level and leaves everything else as a JSON-encoded string in message, so this shape is stable across alert types.

1c. Create the table and DCR from the sample

1. Go to your Log Analytics workspace → Tables → Create → New custom log (DCR-based).

2. Enter a Table name — for example, CorelightAlerts. The portal appends the _CL suffix automatically, producing CorelightAlerts_CL. Table names appear in billing records, so do not put sensitive information in them.

3. Leave Table plan as Analytics (Basic and Auxiliary plans restrict querying and add ingestion constraints).

4. Select Create a new data collection rule, then set its Subscription, Resource group, and Name (for example, corelight-alerts-dcr).

5. Select the Data Collection Endpoint from step 1a, then click Next.

6. On the Schema and transformation page, click Browse for files and upload corelight-alert-sample.json.

7. Confirm the inferred schema matches the table in step 1d.

8. Click on Transformation editor to make changes outlined in step 1e, or set TimeGenerated to current timestamp.

9. Finish the wizard after reviewing the settings, and creating the table.

The wizard writes a stream declaration named Custom-CorelightAlerts_CL into the DCR. Copy that name verbatim from the DCR’s JSON View — it is the Stream Name you enter in Investigator, and it is matched exactly.

Note

Stream declaration names must begin with Custom-. The stream name and the table name are independent: the stream identifies the incoming schema, while the DCR’s outputStream (Custom-CorelightAlerts_CL) selects the destination table.

1d. Expected schema

Verify the wizard inferred these columns and types. Nested objects and arrays must land as dynamic; if the wizard typed any of them as string, correct it in the DCR’s stream declaration.

Column	Type	Contents
TimeGenerated	datetime	Required by every Log Analytics table. Derived/set in the transformation (see 1e).
alert_id	string	Alert GUID. Declare as string, not guid — stream declarations do not accept guid, and GUIDs are stored and queried as strings regardless.
alert_info	dynamic	alert_name, alert_type, content_id.
alert_entity	dynamic	entity_category, entity_id, entity_name, entity_type.
alert_timestamp_observed	long	Observation time as Unix epoch seconds. Must be long (or real), never datetime — an integer posted into a datetime column fails to parse.
alert_to_detection_url	string	Deep link back into Investigator.
event_ids	dynamic	Array of contributing event IDs.
message	string	Remaining alert payload, JSON-encoded. Keep as string unless you parse it in the transformation (see 1e).
score	int	Alert score.

Stream declarations accept only string, int, long, real, boolean, dynamic, and datetime. Column names must start with a letter, contain only letters, digits, and underscores, and be 2–45 characters long.

1e. Optional transformation adjustments

Because the sample alert does not include a field named timestamp, the wizard generates a default transformKql of source | extend TimeGenerated = now(), which sets TimeGenerated to the ingestion time. You will see a warning banner on the Schema and transformation page: “There was no timestamp field found in the sample provided. The transformation was updated to populate TimeGenerated column with the timestamp of data ingestion.” This default is fine if you want ingestion time. Two optional adjustments are worth considering; edit transformKql in the DCR’s JSON View or via the Transformation editor in the wizard.

If desired (but not required - customer use case dependent), you can use the alert observation time as TimeGenerated. By default TimeGenerated reflects when the table received the record, which is different from when the alert was observed:

source
| extend TimeGenerated = datetime(1970-01-01) + tolong(alert_timestamp_observed) * 1s

Azure Monitor transformations support only an enumerated subset of KQL, and unixtime_seconds_todatetime() is not in it — the datetime arithmetic above is the supported way to convert epoch seconds. Use * 1ms for epoch milliseconds.

If desired, expand message into a queryable column. Change the message column in both the table schema and the stream declaration to dynamic, then:

source
| extend message = parse_json(message)

This lets you query nested values directly (for example, message.src_ip) instead of parsing at query time.

1f. Grant the app registration access to the DCR

1. In the Azure portal, open Monitor → Data collection rules and select your DCR.

2. Select Access control (IAM) → Add → Add role assignment.

3. Assign the Monitoring Metrics Publisher role to your Microsoft Entra app registration.

Step 2: Collect Azure values

Gather the following values from the Azure portal. Each maps to a field you will enter in Investigator.

Investigator field	What it is	Where to find it in Azure
Data Collection Endpoint	The DCE’s logs-ingestion URI. Example: https://my-dce-abcd.eastus-1.ingest.monitor.azure.com	Data Collection Endpoint → Overview → Logs ingestion URI
DCR Immutable ID	The DCR’s immutableId. Example: dcr-00112233445566778899aabbccddeeff	Data Collection Rule → JSON View (or Properties) → immutableId
Stream Name	The custom stream declared in the DCR (from Step 1c). Example: Custom-CorelightAlerts_CL	Data Collection Rule → JSON View → streamDeclarations key
Directory (tenant) ID	The Entra tenant GUID for the app registration	App registration → Overview → Directory (tenant) ID
Application (client) ID	The app registration’s client GUID	App registration → Overview → Application (client) ID
Client secret	A client secret for the app registration (shown only once at creation)	App registration → Certificates & secrets → Client secrets

Note

The endpoint you provide determines the Azure cloud. For Commercial/Default or US Government clouds, use a DCE whose host ends in .ingest.monitor.azure.com or .ingest.monitor.azure.us respectively; Investigator infers the cloud from the endpoint. For Chinese Clouds, .ingest.monitor.azure.cn is supported.

Step 3: Configure the exporter in Investigator

Use the values gathered from Azure to set up the connection in the Investigator UI.

1. Log in to the Corelight Investigator instance using valid credentials.

2. From System Settings in the left navigation, choose Integration and click the Alert Exports tab.

3. Click the MS Sentinel (Logs Ingestion) tile.

4. Toggle the Enabled switch to the On position.

5. Provide a Name for the exporter.

6. Enter the Data Collection Endpoint you collected in Step 2.

7. Enter the DCR Immutable ID.

8. Enter the Stream Name.

9. Enter the app registration’s Directory (tenant) ID, Application (client) ID, and Client secret.

10. Click Save to finalize the configuration.

Note

The Client secret is sensitive. Like the Shared key in the previous integration, it is write-only in the UI — it is not displayed again after you save.

Step 4: Verify Investigator is sending events to Azure

1. Log in to the Azure portal and navigate to your Log Analytics workspace.

2. Click Logs in the left sidebar.

3. Run a KQL query against the custom table backing your stream. For a stream named Custom-CorelightAlerts_CL, the table should be CorelightAlerts_CL:

   CorelightAlerts_CL
   | take 50
   

4. Verify that events from Corelight appear in the results.

Important

Alerts may not appear in the custom table immediately. Allow for a latency period of several minutes to a couple of hours depending on system load.

Note

This integration is the successor to the deprecated HTTP Data Collector API integration. Ensure your network allows Investigator to communicate with the Azure Data Collection Endpoint.