2.2.5. Threat Indicators and Custom Log Tables

💡 First Principle: Two kinds of data don't fit the standard connectors: knowledge about attackers (threat indicators such as malicious IPs, domains, and file hashes) and your own organization's unique logs. Threat indicators become valuable when matched against your telemetry; custom logs become valuable when they have a well-defined table that rules and queries can rely on.

Threat intelligence ingestion has several paths:

• Microsoft Defender Threat Intelligence connector: one-click Microsoft indicators (standard tier with public and open-source intelligence; premium adds Microsoft's own indicators).
• Threat Intelligence - TAXII connector: imports STIX 2.0 or 2.1 intelligence from a TAXII 2.x server (you supply the API root and collection ID). This is the standard way to consume a commercial or industry sharing feed.
• Threat Intelligence upload API: a REST API that accepts STIX objects directly, with no connector; the calling app needs Microsoft Sentinel Contributor. It replaces the legacy Threat Intelligence Platform connector, which is being deprecated.
• Manual creation in the threat intelligence management interface, for one-off indicators and objects (threat actors, attack patterns, relationships).

Indicators land in the ThreatIntelIndicators table, with other STIX objects in ThreatIntelObjects. The older ThreatIntelligenceIndicator table stopped receiving data in 2025; queries and rules should reference the new tables. Ingested indicators are only half the job; they detect nothing until threat intelligence matching happens, either through the built-in indicator-matching analytics rule templates or the Microsoft Defender Threat Intelligence analytics rule (2.5).

Custom log tables hold data no built-in table covers. You create them in the workspace's Tables blade as DCR-based custom tables: name the table (the _CL suffix is added for you), choose a plan, upload a sample JSON record to infer the schema, and optionally write a transformation, a KQL query that filters or reshapes each record before it's stored. Every table needs a TimeGenerated column; if your data lacks one, the transformation adds it. Data then arrives through the Logs Ingestion API (your application posts to a data collection endpoint using an Entra app registration) or through AMA collecting text or JSON log files from machines. Creating tables needs workspace write permissions such as Log Analytics Contributor. Changing a table's schema later doesn't update the DCRs that feed it; you must update them yourself.

⚠️ Exam Trap: Importing indicators does not create alerts by itself. "You ingested a TAXII feed but no alerts fire when a listed IP connects" means no threat intelligence matching rule is enabled. A related trap: queries against the legacy ThreatIntelligenceIndicator table return nothing new; use ThreatIntelIndicators.

Reflection Question: Your developers want an in-house HR application's termination events in Sentinel so a rule can detect logins by recently terminated staff. Walk through the pieces you'd create (table, rule, ingestion path) and the role the transformation plays.