Noise Gates: How Burrow Separates Platform Mechanics from Human Intent

A large share of what Microsoft 365 audit shows as "user activity" is generated by the platform itself — SharePoint rendering pages, Office web viewers fetching documents, service actors provisioning sites — or by routine business logistics that pattern-match to attack techniques. Burrow encodes those distinctions as noise gates: deterministic filters that demote or exclude the platform-generated pattern so the alert queue reflects human intent.

Every gate's reasoning is written into the alert's Trigger Why text, so a demotion is always auditable — you can see exactly why a rule chose not to fire at full severity. Demoted alerts stay visible in the dashboard at low severity and still count toward the daily escalation score; they are removed from your inbox, not from the record.

The catalog

All gates below shipped in the 2026-07-03 / 04 hardening pass.

Thumbnail / preview / renderer fetches

• What it looks like: bulk downloads, potentially gigabytes of transferred content, spread across many files in seconds.
• What it actually is: SharePoint generating preview thumbnails, or Office web renderers fetching document content for display. Actors like ODMTADemand-Transform_* and the Office*CA family are Microsoft's own service processes.
• Burrow's handling: excluded from download counts entirely. They do not contribute to data_exfiltration metrics.

Office web viewer file fetches

• What it looks like: "Downloaded 523 MB 5x" — one file counted as several downloads over a short window.
• What it actually is: the user opened a document in Office Online (Word / PowerPoint / Excel). The web viewer fetches the file's underlying bytes several times as pages render — none of those bytes ever leave the tenant.
• Burrow's handling: excluded from manual-download counting. The investigation digest explicitly labels them "NOT a download to a device".

Site-icon fetches

• What it looks like: "Accessed 15 new sites in one minute" — matching the new_site_access pattern.
• What it actually is: the SharePoint start page rendering site cards. Each card fetches a __siteIcon__ resource, which lands in audit as a site-access event.
• Burrow's handling: __siteIcon__ fetches are excluded from site-access tracking. new_site_access counts distinct sites the user actually navigated into.

Browser PDF-viewer chunk fetches

• What it looks like: "63 downloads of one file" — apparent burst of the same document being pulled repeatedly.
• What it actually is: viewing a large PDF inline in the browser. The PDF viewer fetches the file in chunks — one audit event per chunk — over the same file.
• Burrow's handling: if the fetch-per-file ratio is at least 10x across three or fewer files, the pattern is demoted. Real exfil looks like many distinct files at ratio ~1.

Org-wide share fanout

• What it looks like: "6 org-wide links created" after a single share operation.
• What it actually is: clicking Share once creates the link, plus bookkeeping and initial-open events — 4 to 6 audit events per user-visible action.
• Burrow's handling: the risky_sharing.org_links rule now counts distinct files newly shared org-wide, not the raw event stream. See the rule catalog entry for risky_sharing.

Office egress IP "password spray"

• What it looks like: "5 users failing sign-in from one IP" — matches aad_password_spray.
• What it actually is: colleagues sharing an office egress (typical NAT) each mistyping their password once or twice. The IP is legitimate, the failures are user error.
• Burrow's handling: demoted when the same users who failed also sign in successfully from the same IP. Kept sharp on IPs where no one has ever succeeded.

Stale-session retries

• What it looks like: "7 failed sign-ins in one second" — matches enumeration or spray.
• What it actually is: a device with an expired token retrying automatically. The Microsoft error code is FlowTokenExpired (or similar).
• Burrow's handling: stale-token retries are excluded from enumeration and spray counters. They do not count toward aad_username_enumeration or aad_password_spray.

Deletions matched by uploads or moves in one site

• What it looks like: "Deleted 63 files" — matches mass_deletion_med.
• What it actually is: folder reorganisation or SharePoint's Move operation, which shows as a delete + upload in each affected file within a single site.
• Burrow's handling: demoted when the delete count is closely matched by an upload / move count in the same site. ransomware_signature still evaluates the same raw combination independently — this gate does not blind the ransomware rule.

Microsoft provisioning identities granting site admin

• What it looks like: "CRITICAL: site collection admin granted" — matches site_collection_admin_grant.
• What it actually is: automatic Teams / site provisioning. The service actors Microsoft\ServiceOperator and SHAREPOINT\system grant themselves the necessary role during setup — no human is behind the action, and neither identity can be impersonated externally.
• Burrow's handling: these two identities are demoted to low when they grant site admin or set site policy. Any other identity granting site admin still fires at full severity.

Passive off-hours browsing

• What it looks like: "Unusual-hour activity" — matches unusual_hour_activity.
• What it actually is: an early or late login that only reads pages — zero downloads, edits, deletes, or shares.
• Burrow's handling: demoted. An off-hours session that touches data (downloads or edits) still fires at full severity.

Why this matters

Without these gates, the day-to-day Burrow inbox would be dominated by rendering, provisioning, and viewer traffic — activity that is real in the audit log but not actionable for a human analyst. Each gate is a translation of one specific way the platform generates noise, so the SOC queue can reflect human intent.

The gates are deterministic. There is no AI judging what is or is not machinery. The rules describe machinery patterns explicitly, and the Trigger Why text on any demoted alert names the specific gate that applied.

When a gate misfires

If a gate demotes an alert that should have paged:

1. Open the alert on the Alerts page — demoted alerts stay visible at low severity.
2. Read the Trigger Why text to see which gate applied.
3. If the gate was wrong for your case, raise a support ticket with the alert key, the gate name from Trigger Why, and one line of context on why the pattern is not what the gate assumed. Rule tuning happens ongoing.

See also

• Rule catalog — the rules these gates modify.
• Investigation digest — where "the platform did it" gets labelled in plain English.
• Reading the evidence box — where the Trigger Why text lives in the drawer.
• Postures, overrides, and disabled rules — for whole-rule tuning, when a rule is systematically noisy in your tenant.

Need help? support@smikar.com.