Noise Gates: Platform Noise vs 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

The first ten gates shipped in the 2026-07-03 / 04 hardening pass; four more (folder-as-ZIP, single-large-file, Office-Online device, and service-account-within-baseline) shipped in the 2026-07-05 / 06 pass and are grouped at the end.

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, or working with an expired password. The IP is legitimate, the failures are user error.
• Burrow's handling: demoted when the same users who failed also sign in successfully from that IP, or when the IP belongs to a network already learned as shared office / VPN egress on Known Networks. Kept sharp on IPs that are neither - an outside attacker still fires at full severity.

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.

Added in the 2026-07-05 / 06 pass

Folder downloaded as a ZIP

• What it looks like: "150 manual downloads" firing deviation, velocity, and sensitive-extension alerts at once.
• What it actually is: one click on Download against a SharePoint folder. The platform fetches every file in the folder individually to build the zip - one audit event per file - for a single user action.
• Burrow's handling: the folder-zip packager is recognised and reported as "downloaded an entire folder as a ZIP: one click packaged N files" (floor: 5 files or more). The download itself stays visible, because a whole-folder copy is a genuine exfil route worth verifying against the user's role - but the co-firing deviation / velocity / sensitive-extension alerts demote to low.

Dominant single large file

• What it looks like: a "40× baseline" data_exfiltration or behavioral_deviation byte spike.
• What it actually is: the user downloaded one large file - a CAD model, a training video, a meeting recording - that accounts for 80% or more of the day's bytes. One big file is not the shape of exfiltration.
• Burrow's handling: demoted to low, with the dominant file named. A genuine multi-file bulk pull, where the volume is spread across many files, is unaffected.

Office-Online editing reported as unmanaged device

• What it looks like: "unmanaged device access" on labelled files, matching unmanaged_device_access.
• What it actually is: Excel / Word Online render-farm and co-authoring requests (the MSWAC / MSOCS clients). They report "unmanaged device" because there is literally no device in the request path - the work happens in Microsoft's browser render farm.
• Burrow's handling: MSWAC / MSOCS requests no longer count toward unmanaged-device rules. Real BYOD traffic from an actual unenrolled device still does.

Service account within its own baseline

• What it looks like: "CRITICAL: ransomware signature" or "mass deletion" on the tenant's own document-pipeline service principals.
• What it actually is: the document-pipeline automation doing its normal bulk download / delete / replace work, which legitimately pattern-matches ransomware and mass-deletion.
• Burrow's handling: when a service principal (identified by identity shape - app@sharepoint, SHAREPOINT\system - not a hardcoded name) is within its own established baseline, the alert demotes to low with an explanation. It never silently disappears, and a service account operating far outside its own norm still fires at full severity. In the weekly briefing these accounts are separated out of the human risk ranking entirely.

Added in the 2026-07-09 pass

Site provisioning burst

• What it looks like: three separate admin alerts fire at once on a normal user - permission_escalation (medium), site_collection_admin_grant (critical), and tenant_policy_change (critical) - three emails from one action.
• What it actually is: the user created a Team or a Plan. Microsoft's provisioning pipeline automatically stamps the new site with a SiteCollectionCreated → SiteCollectionAdminAdded (the site's own Owners group) → SharingPolicyChanged (default site sharing) burst - and it stamps those automatic operations with the creating user's identity, so the earlier service-principal gate (which keys on Microsoft's own service actors) does not catch it.
• Burrow's handling: the alerts are correlated by site. When every admin / policy / permission operation in the window is on a site that was created this same window, and the site-admin grant is to that site's own …Owners group, Burrow recognises the provisioning burst: permission_escalation and tenant_policy_change are suppressed, and a single low site_collection_admin_grant record is kept for the cluster (visible in Burrow, no email). A real admin grant to a specific person, or any grant on a pre-existing site, is untouched and stays critical.

This is the first noise gate that keys on a real user's activity rather than a service actor - the discriminator is the correlation (all ops on a just-created site, grant to the Owners group), not the identity.

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.