Skip to content

[Defender Intel Synchronizer] Performance degradation, Hostname not created, various other issues #5161

@blauwers

Description

@blauwers

Description

The microsoft-defender-intel-synchronizer connector exhibits multiple production-impacting defects that make it slow and unreliable on larger TAXII feeds and cause some indicators to be silently skipped. Documentation and samples also do not reflect current behavior or supported configuration.

Main symptoms:

  • Very slow ingestion on large TAXII collections. Syncs can take many minutes and place excessive load on the OpenCTI backend.
  • Hostname indicators are not created in Defender even when confidence and score are high.
  • passive_only mode does not consistently prevent modifying calls in all code paths and preflight logs are misleading.
  • README, docker-compose, and config samples omit supported configuration for per-collection overrides and show a legacy login URL.

Environment

  1. OS (where OpenCTI server runs): Ubuntu 22.04 (containers)
  2. OpenCTI version: 6.8.x
  3. OpenCTI client: connector container microsoft-defender-intel-synchronizer (rolling)
  4. Other environment details:

Reproducible Steps

Steps to create the smallest reproducible scenario:

  1. Deploy the connector with two sizable TAXII collections and default configuration (CSV list).
  2. Include at least one indicator with a Hostname observable (e.g., pattern [hostname:value = 'example.bad']) and score/confidence 100.
  3. Run a sync on the current rolling connector.
  4. Optionally set MICROSOFT_DEFENDER_INTEL_SYNCHRONIZER_PASSIVE_ONLY=true and run preflight + sync again.

Expected Output

  • Sync completes quickly enough to be operational on large feeds.
  • Hostname indicators are handled as domain names and created in Defender.
  • In passive_only=true, no modifying API requests are sent, and preflight logs clearly indicate that write checks were skipped.
  • Docs and samples describe per-collection overrides for TAXII collections and reference the correct login URL.

Actual Output

  • Sync is slow on large feeds and increases backend load.
  • Hostname indicators are silently skipped and never appear in Defender.
  • In passive_only=true, modifying requests can still be attempted in some paths, and preflight reports a successful write check even when no write should occur.
  • Docs and samples do not show advanced per-collection overrides and list https://login.microsoft.com instead of https://login.microsoftonline.com.

Additional information

  • Long runtimes and heavy backend queries make regular synchronization impractical at scale.
  • Teams cannot rely on Hostname indicators being enforced in Defender.
  • Passive runs intended for audit can still appear to perform writes due to inconsistent guards and logging.

Screenshots (optional)

Metadata

Metadata

Assignees

No one assigned

    Labels

    buguse for describing something not working as expectedneeds triageuse to identify issue needing triage from Filigran Product team

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions