Skip to main content

​
Microsoft Sentinel

Beacon v0.0.32 added Microsoft Sentinel support for teams that want Beacon endpoint events in Log Analytics and Sentinel hunting workflows. Beacon remains the local JSONL producer and writes one source of truth, the active runtime JSONL log. Azure Monitor Agent tails that file and sends new records through a Data Collection Rule (DCR) into a custom Log Analytics table. Use this path when you want Sentinel ingestion without storing Azure tenant IDs, client secrets, workspace IDs, DCR identifiers, or ingestion endpoints in Beacon endpoint configuration.

​
Runtime log paths

ModeRuntime log
User mode~/.beacon/endpoint/logs/runtime.jsonl
System mode/var/log/beacon-agent/runtime.jsonl
Use system mode for MDM deployments so Azure Monitor Agent can tail /var/log/beacon-agent/runtime.jsonl without per-user home directory permissions.

​
Prerequisites

  • Beacon endpoint installed and writing local JSONL.
  • A Log Analytics workspace, with Microsoft Sentinel enabled if you want Sentinel hunting and analytics workflows.
  • Azure Monitor Agent installed or deployed to the endpoint.
  • A custom Log Analytics table named BeaconRuntime_CL.
  • A Data Collection Rule associated with the endpoint and workspace.

​
Install the Sentinel pack

Generate the Sentinel content pack for a managed system-mode deployment: 
sudo /opt/beacon/bin/beacon endpoint sentinel install-pack \
  --system \
  --output ./beacon-sentinel-pack
The pack includes:
  • README.md with setup and validation steps
  • table-schema.json for the BeaconRuntime_CL custom table
  • dcr-template.json for Azure Monitor Agent custom text log collection
  • dcr-transform.kql for parsing each Beacon JSONL line
  • queries.kql with validation and starter hunting queries
  • detections.kql with example analytics rule logic
  • sample-event.jsonl with Beacon endpoint sample events
If you use a custom Beacon log path, generate the pack with --log-path /path/to/runtime.jsonl. The generated DCR template uses the selected path.

​
Sentinel setup

Set up Microsoft Sentinel ingestion from the Azure Portal. If Sentinel is already enabled for your Log Analytics workspace, skip the Sentinel enablement step.

​
1. Enable Sentinel if needed

If the workspace does not already have Microsoft Sentinel enabled, open the Azure Portal, search for Microsoft Sentinel, click Create, select the agent-beacon-instance workspace, and click Add. Sentinel uses that Log Analytics workspace as its backend.
Azure Portal showing Microsoft Sentinel workspace selection with agent-beacon-instance selected.

​
2. Create the Data Collection Endpoint

Create a Data Collection Endpoint in the same region as the Log Analytics workspace. For the example workspace shown here, use:
FieldValue
Namedce-agent-beacon-runtime
Resource groupagent-beacon
RegionEast US
If Azure says no Data Collection Endpoint exists during the custom log wizard, create this endpoint first, then return to the wizard.
Azure Portal Data collection endpoints page showing no endpoints and the Create button.
Azure Portal form creating dce-agent-beacon-runtime in the agent-beacon resource group and East US region.

​
3. Create the Beacon custom table

Open your Log Analytics workspace, such as agent-beacon-instance, then go to Settings > Tables. If you do not see Tables, use the search box inside the workspace left navigation and search for Tables. Click Create > New custom log (DCR-based). Use:
FieldValue
Table nameBeaconRuntime
DescriptionAgent Beacon endpoint runtime telemetry
Table planAnalytics
Data collection ruledcr-agent-beacon-runtime
Data collection endpointdce-agent-beacon-runtime
Enter the table name as BeaconRuntime, not BeaconRuntime_CL. Azure adds the _CL suffix automatically, so the final Log Analytics table is BeaconRuntime_CL. If you enter BeaconRuntime_CL, Azure may create BeaconRuntime_CL_CL.
Azure Portal showing the agent-beacon-instance Log Analytics workspace Tables page.
Azure Portal custom log wizard with BeaconRuntime table details, Analytics plan, dcr-agent-beacon-runtime DCR, and dce-agent-beacon-runtime endpoint.

​
4. Configure schema and transformation

In the Schema and transformation step, upload sample-event.jsonl from the generated Sentinel pack. Do not paste table-schema.json into the portal wizard; use it as the reference for the expected columns. Paste the contents of dcr-transform.kql into the transformation editor and confirm the output columns match the table-schema.json schema. The key columns are:
ColumnColumnColumn
TimeGeneratedVendorProduct
SchemaVersionEventKindEventAction
EventCategorySeverityHostName
UserNameHarnessNameSessionId
ToolNameCommandLineRepository
BranchMessageContentRetention
RawData
The DCR uses Custom Text Logs because Beacon writes newline-delimited JSON. The transform parses each RawData line with todynamic(RawData), projects common hunting columns, preserves the original Beacon event in RawData, and routes output to BeaconRuntime_CL.

​
5. Choose the ingestion path

Azure Monitor Agent cannot directly tail Beacon logs from macOS endpoints. For macOS fleets, use a small customer-managed forwarder or relay that reads Beacon JSONL records and posts them to the Azure Monitor Logs Ingestion API. For supported Windows or Linux testing, install Azure Monitor Agent on the machine, add a custom text log source pointing to the Beacon runtime log path, usually /var/log/beacon-agent/runtime.jsonl, apply the Beacon DCR transform, route output to BeaconRuntime_CL, and associate the DCR with the machine. The generated table schema includes columns such as Vendor, Product, EventAction, Severity, HostName, UserName, HarnessName, SessionId, ToolName, CommandLine, Repository, Branch, Message, ContentRetention, and RawData.

​
Validate forwarding

Confirm the Beacon runtime log exists and has recent endpoint events: 
sudo /opt/beacon/bin/beacon endpoint status --system --json
sudo test -r /var/log/beacon-agent/runtime.jsonl
Write a Sentinel validation event: 
sudo /opt/beacon/bin/beacon endpoint sentinel validate --system
After Azure Monitor Agent ships the new line, validate in Microsoft Sentinel or Log Analytics: 
BeaconRuntime_CL
| where TimeGenerated > ago(24h)
| where Message has "Beacon endpoint Sentinel validation event"
| order by TimeGenerated desc
If the validation query does not return data, check the DCR association, Azure Monitor Agent health state, configured file path, and table schema. The target table must exist before the DCR can route transformed records to it.

​
Hunting content

Use queries.kql for validation and starter hunting queries, including recent Beacon events, command execution, sensitive file edits, high tool-call volume, and new or rare agent runtimes. Use detections.kql as example analytics rule logic. Review and tune thresholds, repository names, content retention policy, and severity mappings before enabling alerts in production.

​
CEF, Syslog, and direct APIs

Microsoft Sentinel can also collect CEF and Syslog through Azure Monitor Agent, but the generated Beacon pack uses custom logs because Beacon events are rich structured JSON with prompts, tool calls, commands, files, runtime metadata, and optional raw fields. Flattening those events into CEF loses useful context. The Azure Monitor Logs Ingestion API can be useful for a centralized customer-managed forwarder, but it should not be configured directly in Beacon endpoint agent state. Direct API forwarding requires Microsoft Entra credentials, DCR identifiers, ingestion endpoints, batching, retries, and network failure handling. Keep those concerns outside Beacon’s local endpoint collector unless you are building a separate managed forwarder.

​
Content retention

Beacon content retention controls what can be written to runtime.jsonl and forwarded to Microsoft Sentinel. Use metadata or redacted for stricter deployments: 
sudo /opt/beacon/bin/beacon endpoint install --system --content-retention metadata
Use full only when prompt text, tool input, command output, and retained content match your approved telemetry collection policy.

beacon endpoint sentinel

Review Microsoft Sentinel command syntax, flags, and examples.

SIEM forwarding

Review forwarding patterns across Wazuh, Splunk HEC, Falcon LogScale, Elastic, Datadog, Sumo Logic, Rapid7, Microsoft Sentinel, and customer-managed pipelines.

Endpoint event schema

Review normalized Beacon JSONL fields and example events.

Supported surfaces

Review supported agent harnesses, deployment modes, storage, and forwarding.