Full Rule Catalog (with MITRE Mapping)

51 min read · Last updated 14 August 2026 · Page version 29

The full reference for every detection rule Burrow ships with. Each rule has a category name (the identifier that appears on every alert), a MITRE ATT&CK technique mapping, a severity, the conditions under which it fires, the configurable knobs and their defaults across postures, common false-positive patterns, and tuning advice.

Defaults shown are as of June 2026; the Rules page in your dashboard is the source of truth.

The posture columns are P (Permissive), R (Relaxed), B (Balanced - the default), S (Strict), X (Paranoid).

For an overview of how postures and overrides interact, see Postures, overrides, and disabled rules.

Ransomware and destruction

`ransomware_signature`

MITRE: T1486 (Data Encrypted for Impact)
Severity: Critical

Fires on any of three sub-patterns:

Crypto-locker extension match - files touched in the window carry an extension on the operator-curated ransomware extension list (.locked, .crypted, etc.).
Encrypt-and-replace - modify + delete + upload pattern in the same window beyond the configured thresholds. Crypto-locker behaviour: delete original, upload encrypted copy.
Encrypt-in-place burst - high modification volume across many distinct files with a low modifies-per-file ratio. The ratio gate is the Office co-authoring filter: real ransomware touches many files at ratio ~1, Office co-authoring touches few files at ratio 10+.

Tunable knobs:

Knob	P	R	B	S	X
`ransom_ext_events`	1	1	1	1	1
`modified_burst`	400	250	150	100	75
`modified_burst_min_files`	250	150	100	75	50
`max_modifies_per_file`	2.0	2.5	2.5	3.0	3.0
`combo_deleted`	200	100	50	25	15
`combo_uploaded`	200	100	50	25	15

Encrypt-in-place: baseline-gated demotion (2026-07-08). A large modify burst with zero renames, deletes, or ransomware extensions - on a managed device via the OneDrive sync client - is the exact shape of both (a) a legitimate migration or bulk sync and (b) encrypt-in-place ransomware acting on a synced folder. The sync client alone is not proof of benign, so Burrow gates the demotion on the account's own history:

Within the account's established file-spread (at least 7 days of baseline, and today's distinct-file count no more than about 1.5× its 30-day daily high-water mark) → demoted to Low. This is routine migration / sync churn and does not email.
Novel or above baseline → stays Medium and emails. A first-time or unusually large burst is never silently demoted - no blind spot.
Any corroboration (a ransomware extension, a rename, a delete, or an unmanaged device) or a non-sync client → no demotion, stays Critical.

Upload-dominated bursts are content ingest, not encryption (2026-07-23). A modify burst where the number of new uploads meets or exceeds the modifications, with no deletes, renames, or ransomware extensions, is new content arriving rather than existing files being rewritten in place. The classic case is a phone's camera roll bulk-uploading through the OneDrive mobile app - each photo upload also registers a file-modified event for its thumbnail, so it reads as a big modify burst. Because that comes from an unmanaged personal device, the baseline-gated demotion above deliberately won't apply, but the upload dominance is device-independent proof it isn't encryption, so the alert is demoted to Low. Genuine encrypt-in-place rewrites existing files and creates almost no uploads, so it can never trip this test.

Cross-site file move: the encrypt-and-replace demotion (2026-07-10). SharePoint has no "move between sites" operation, so when a person re-files a folder from one site to another it shows up as download from site A → upload into site B → delete the originals in site A - which is exactly the encrypt-and-replace shape, and it satisfies the multi-site spread gate by construction. Burrow now recognises a genuine cross-site move and demotes it to Low (hard-capped) only when all of these hold:

No ransomware-extension events in the window.
The delete sites and the upload sites are completely separate. Real ransomware rewrites files inside each site (delete and re-upload in the same place); a move deletes in one site and uploads in another.
At least 80% of the uploaded file names match files downloaded or deleted in the same window - the same content moved, not novel encrypted payloads.

When all three hold, the alert's summary leads with "NOT ransomware - a user is re-filing content" instead of "isolate the account". If any one fails - overlapping sites, unmatched names, or a ransomware extension - it stays Critical.

The cross-site-move verdict now demotes the delete-spike rules too (2026-07-12). A single re-filing used to be caught here but still tripped the other rules that key on the delete burst - mass_deletion, behavioral_deviation, and intraday_velocity_burst - producing several alerts across three rules that the incident correlator would bundle into one "prioritise this" incident. The same cross-site-move verdict is now shared with those rules, so all of them demote to Low automatically. Net effect: a genuine cross-site move produces at most one low record, never an incident. A genuine wipe (deletes with no matching uploads elsewhere) is untouched.

More encrypt-and-replace demotions (2026-07-22). The delete-and-upload arm demotes to Low in two more shapes that look like encryption but aren't, as long as there is no encryption evidence (any ransomware-extension hit vetoes the demotion):

Embedded-database churn - the deleted names are an application's internal data-folder files (.sst, MANIFEST, LOCK and similar) syncing in, not documents being destroyed.
Content turnover - zero ransomware extensions and more uploads than deletes. Encrypt-and-replace deletes an original and uploads its encrypted copy roughly one-for-one; adding more files than you removed, with no encryption signal, is the opposite - ordinary bulk document management or re-filing (real case: 61 old PDFs recycled and 103 new, differently-named PDFs uploaded across four document libraries).

False positives: Office co-authoring on small file sets generates many modifications on few files. Mitigated by the max_modifies_per_file ratio gate. Bulk migrations / sync churn are handled by the baseline-gated demotion above.

Tuning advice: rarely raise ransom_ext_events above 1 - the extension list is curated to be unambiguous. If the burst pattern fires on bulk-edit tooling, raise modified_burst_min_files rather than modified_burst.

When to disable: almost never.

`mass_deletion_high` / `mass_deletion_med`

MITRE: T1485 (Data Destruction)
Severity: High / Medium

Fires when deleted-file count crosses the threshold.

Tunable knobs:

Knob	P	R	B	S	X
`mass_deletion_high.deleted`	500	200	100	50	25
`mass_deletion_med.deleted`	150	60	30	15	8

Reorganisation gate (2026-07-03). When the delete count is closely matched by an upload or move count within a single site, the alert is demoted - this is the shape of a SharePoint Move operation or folder reorganisation, not destruction. ransomware_signature still evaluates the raw combination independently, so the reorganisation gate does not blind ransomware detection.

Cross-site move gate (2026-07-12). The single-site reorganisation gate above only recognises same-site churn. A cross-site re-filing (delete in one site, upload the same files into another) is now also demoted - the shared cross-site-move verdict applies to this rule too, so a folder move across sites no longer fires mass_deletion alongside the deviation and velocity rules. A genuine wipe - deletes with no matching uploads elsewhere - is untouched.

The reorganisation check is now day-aware (2026-07-21). Deletes are only destruction if content actually went away, so the rule demotes to Low when the deletes are really content turnover: a comparable-or-greater number of uploads on the same day, a folder restructure (folders both created and removed), a cross-site move, or moves and renames making up most of the "deletes". The key change is that this now looks at the whole day's uploads and folder operations, not just the short detection window - so a OneDrive sync where the delete burst and the matching re-upload land at different moments of the day is still recognised as a reorganisation. (Real case: a user re-syncing a re-organised image dataset produced 374 deletes in one burst but 3,128 uploads and 10 folders created across the day - correctly demoted.) A genuine wipe (many deletes, no uploads, no folder operations) stays High, and any ransomware-extension hit vetoes the demotion. When a demotion applies, the alert carries a reorganisation verdict in its evidence explaining why.

The alert copy no longer cries ransomware on a plain delete (2026-07-09). Deletion and encrypt-in-place are different things - the latter has its own ransomware_signature rule. A mass_deletion alert now only mentions ransomware when there is an actual encryption signal (a ransomware-extension event). A plain recycle reads as what it is: "no encryption signature - recycled, not rewritten - recoverable from the recycle bin; confirm the delete was intended." A bulk delete of 170 files to the recycle bin is a recoverable action to verify, not an encryption event.

False positives: project archive cleanup, retention-policy execution, bulk list cleanup. Service accounts doing scheduled deletes are the biggest source.

Tuning advice: add service-account exceptions before raising thresholds (a real deleted=200 from a human is meaningful; do not blunt the rule for everyone to mute one account).

When to disable: never globally - use per-user exceptions.

Exfiltration

`data_exfiltration_high` / `data_exfiltration_med`

MITRE: T1567.002 (Exfiltration to Cloud Storage)
Severity: High / Medium

Fires when ANY of four envelope thresholds is crossed: total bytes downloaded, manual downloads (sync excluded), manual downloads of labelled files, or total labelled-file count.

Names the sensitivity label (2026-07-09). When labelled files are involved, the alert now names the label(s) rather than reporting a bare count - "1 sensitivity-labelled file(s) were touched (Confidential)" instead of just "1 sensitivity-labelled file(s)". The label is the thing that makes a download matter, so it belongs in the headline.

Office-web-viewer exclusion (2026-07-03). Documents opened in Word / PowerPoint / Excel Online are fetched repeatedly by Microsoft's own viewer service - none of those bytes leave the tenant. Those fetches are excluded from downloaded_manual counts entirely and labelled as "NOT a download to a device" in the investigation digest. A user viewing a large PDF in the browser will no longer show up as an exfil suspect.

SharePoint Embedded app-storage exclusion (2026-07-20). Activity on /contentstorage/ sites - the hidden containers behind Designer, Loop, Copilot Pages, and Forms - is the app's own backend churning working files, not user downloads, and never counts toward the exfiltration thresholds. This joins the existing exclusion list (page rendering, preview / thumbnail generation, Office web viewers, workflow service, search indexer, migration tooling, internal service accounts). Each alert still carries a Server-side events count showing how many events were excluded.

Folder-as-ZIP gate (2026-07-05). When a user clicks Download on a SharePoint folder, the platform fetches every file in it individually to build the zip - which used to read as "150 manual downloads" and fire several alerts. Burrow now recognises the folder-zip packager and reports it as "downloaded an entire folder as a ZIP: one click packaged N files". The download stays visible (a whole-folder copy is a genuine exfil route - verify the contents suit the user's role), but the co-firing deviation / velocity / sensitive-extension alerts demote to low. The reframing floor is 5 files or more.

Dominant-single-file gate (2026-07-05). A day whose byte spike is essentially one large file - a CAD model, a training video, a meeting recording, where a single file is 80% or more of the day's bytes - demotes to low and names the file, rather than firing a dramatic "40× baseline" exfiltration alert. A genuine multi-file bulk pull is unaffected. This is a share-based / dominance gate, not a raw count.

Re-fetch loop is not exfiltration (2026-07-24). When the entire "volume" is one distinct file fetched over and over - a stuck or retrying download of a single large file, e.g. a 277 MB PDF re-pulled dozens of times in a few minutes - the alert demotes and the AI triage is told plainly that this is a re-fetch loop, not data theft. Fetching the same file again just moves the same bytes again; nothing new leaves. Genuine exfiltration moves many distinct files, so the count of distinct files downloaded - not the raw byte total - is the discriminator.

Tunable knobs (high):

Knob	P	R	B	S	X
`bytes_downloaded`	5 GB	2 GB	1 GB	512 MB	256 MB
`downloaded_manual`	2500	1000	500	250	100
`downloaded_manual_with_labels`	1000	400	200	100	50
`labeled_files`	25	20	10	5	3

Tunable knobs (med):

Knob	P	R	B	S	X
`bytes_downloaded`	1 GB	512 MB	256 MB	128 MB	64 MB
`downloaded_manual`	1000	400	200	100	50
`distinct_files`	5000	2000	1000	500	250
`distinct_files_downloaded_manual`	250	100	50	25	10

False positives: legitimate large pulls (project hand-offs, M&A due diligence, data scientists pulling datasets). OneDrive sync is already excluded. Backup tooling.

Tuning advice: the Med tier fires more than High; raise data_exfiltration_med.bytes_downloaded first if Med is the noisy one. If only the labelled-files signal is firing, that is a significant signal worth keeping at low volume. Use entity exceptions for known data-engineer accounts.

When to disable: never - use exceptions.

`sensitive_ext_exfil`

MITRE: T1567.002
Severity: Critical

Fires on downloads of files with extensions in a curated high-risk list (credential vaults, mailbox archives, database dumps, system backups). Extension-based, not MIP-label-based - the cheap heuristic that complements the labelled-content rules.

Tunable knobs:

Knob	P	R	B	S	X
`sensitive_ext_dl`	50	20	10	5	3

False positives: legitimate ops people pulling backups, IT migrating mailboxes. Use entity exceptions for known operational accounts.

When to disable: never.

`risky_sharing` family (`_anon` / `_external` / `_external_partner` / `_orgwide`)

MITRE: T1530 (Data from Cloud Storage)
Severity: High (risky_sharing_anon - anonymous links); Medium, rising to High for risky_sharing_external when the share reaches 2 or more distinct external recipients or carries an anonymous-link / label co-signal; Low for org-wide / company links and for partner-demoted external shares.

Fires on: anonymous link creation, external shares, or org-wide link events above threshold. Each condition is its own named variant so the reason is visible on the alert:

risky_sharing_anon - any anonymous share link created (no sign-in required to open).
risky_sharing_external_untrusted - the external variant after an untrusted escalation (2026-08-14). When any recipient domain is on your Untrusted domains list - personal freemail being the usual case - severity is raised to the level you chose, and the rule name changes so the escalation is visible rather than an unexplained bump. It never lowers an alert, and a share mixing partner and untrusted recipients always escalates, because the partner discount requires every recipient to be a partner.
risky_sharing_external - a share to a non-internal domain. Medium for a single recipient, High for two or more distinct external recipients or when an anonymous link / label co-signal is present.
risky_sharing_external_partner - the external variant after the partner discount (see below).
risky_sharing_orgwide - org-wide / company link events; Low, because reach is limited to people already inside the tenant.

Tunable knobs (org-wide):

Knob	P	R	B	S	X
`risky_sharing_orgwide.org_links`	25	10	5	3	1

As of 2026-07-03: the org_links counter now counts distinct files newly shared org-wide, not the raw audit event stream. Clicking Share once creates 4 to 6 audit events (link creation + bookkeeping + initial opens), and the previous counter treated each event as a separate share - so a single business-as-usual click could trip the rule. Counting distinct files reflects the operator's actual intent: how many files became broadly shareable.

Org-wide / company links are internal - Low, and no sensitive-site escalation (2026-07-08). An org-wide or company-wide link is reachable only inside the tenant - it is internal sharing, and often automation (Logic Apps, media-transform services) rather than a person. On their own, these alerts now sit at Low, and the sensitive-site tier bump no longer escalates a pure-internal-sharing alert to high or critical. The anonymous-link (risky_sharing_anon) and external-share (risky_sharing_external) variants are unchanged - those reach outside the tenant and remain High / Medium.

The external-share alert now names the recipient (2026-07-09). A risky_sharing_external alert's headline and digest name the actual external recipient (de-mangled from Microsoft's #EXT# encoding), falling back to the domain - never a generic "external recipients" placeholder. In the investigation digest the external recipients are listed individually and flagged, while internal recipients are collapsed into a single "also shared internally with N colleague(s)" line, so a benign internal fan-out cannot bury the external lead. For the standing inventory of all external sharing, see the External Sharing report.

Trusted-partner demotion (2026-07-15). When every external recipient on a share is a domain you have marked as an External Partner (your auditor, a contractor, a JV partner), the external-share alert becomes risky_sharing_external_partner and is demoted per the policy you chose (lower one tier, straight to Low, or lower-and-can-hide). The share is still recorded and still appears on the External Sharing report - only the alert severity drops, cutting routine partner-sharing noise. The demotion is narrow: a mixed share (a partner plus an unknown outside party) is not discounted, and any co-occurring anonymous link or sensitivity-label downgrade keeps its own undemoted severity.

False positives: modern collaboration uses sharing heavily. Internal teams use org-wide links for tenant-wide announcements. SharePoint News uses them. The Low severity for internal links above keeps these out of your inbox while leaving them on the record.

Tuning advice: correlate with site sensitivity - the high-value alerts are ones where the shared files carry a sensitivity label. If specific sites legitimately broadcast, add a sensitive-site exception rather than a user exception.

When to disable: never - tune thresholds and use exceptions.

Recon and discovery

`search_enumeration_high` / `search_enumeration_med` / `search_enumeration_targeted`

MITRE: T1083 (File and Directory Discovery)
Severity: High / Medium / Low (_targeted)

Fires when search-query count crosses threshold. Service apps run at 5x the thresholds (crawlers and indexers legitimately search at scale).

Retrieval vs reconnaissance (2026-07-20). When at least 70% of the distinct search terms are specific document identifiers - single tokens containing digits, such as invoice, PO, or document numbers - the burst is treated as targeted retrieval of known files rather than enumeration, and fires as search_enumeration_targeted at Low. Broad, wildcard, or keyword searches keep full severity. The sampled terms are attached to every variant so you can see what was actually searched.

Tunable knobs:

Knob	P	R	B	S	X
`search_enumeration_high.searches_performed`	1000	400	200	100	50
`search_enumeration_med.searches_performed`	375	150	75	40	20

False positives: legitimate research, librarians, knowledge-base maintainers, heavy SharePoint adopters.

Tuning advice: the sensitive_search rule is the better signal - if a user does 50 searches all matching sensitive-keyword patterns, that is reconnaissance regardless of volume. Tune search_enumeration_* up and rely on sensitive_search for the signal.

When to disable: if your tenant does not have a SharePoint search culture, consider disabling at the posture-default level and re-enabling only when reconnaissance is a known risk.

`sensitive_search`

MITRE: T1083
Severity: High

Fires on search queries matching the operator-configured sensitive keywords list. (Previously named sensitive_search.)

Tunable knobs:

Knob	P	R	B	S	X
`sensitive_searches`	50	20	10	5	3

False positives: security team enumeration, audit / compliance scans.

Tuning advice: add an entity exception for known security / compliance users. Do not raise the threshold - the rule's value is its sensitivity to low-volume targeted recon.

When to disable: never.

`new_site_access` (UEBA)

MITRE: T1083
Severity: High

Fires when a user accesses sites they have never accessed in their recent history (default 14-day baseline window). Configurable minimum-new-site count per posture.

Tunable knobs (as of 2026-07-02):

Knob	P	R	B	S	X
`new_sites_min`	20	15	10	5	3

The Balanced default was raised from 2 to 10 on 2026-07-02 after operator feedback that the low threshold was firing on ordinary intranet browsing sessions. __siteIcon__ resource fetches (SharePoint start-page site cards) are now also excluded from site-access tracking, so the count more accurately reflects sites the user actually navigated into.

False positives: project pivots (legitimate new-project ramp-up touches many new sites at once), people moving teams.

Tuning advice: high-signal for insider recon and lateral movement once the threshold is right for your tenant. If 10 is still noisy on Balanced, raise the override - 15 or 20 works well for large tenants where users legitimately touch many project sites per day.

Authentication and identity

`disabled_account_activity`

MITRE: T1078.004 (Cloud Accounts)
Severity: High. Activity in the first hour after Burrow observes the disable is Low instead - see the propagation window below.

Fires when an account that is disabled in your directory performs any SharePoint activity at all.

There is no volume threshold, on purpose. Every other rule in this catalog asks "is this more than normal?". This one does not, because a disabled account has no normal - it should be doing nothing, so a single event is already wrong. Deliberate operations (manual downloads, sharing, deletions, permission changes) are called out in the alert text, and activity on a sensitive site escalates it further.

Why it matters. This is the leaver with lingering access case. Disabling an account does not instantly kill what is already running: existing sessions stay alive, cached tokens keep working, and app passwords keep authenticating. Activity after a disable means one of those is still live - or somebody else is using the account. It is the kind of thing an offboarding checklist is assumed to have handled and often has not.

The disable-propagation window. For the first hour after Burrow sees the account disabled, the alert drops to Low. When IT disables someone mid-session their open Office applications keep autosaving and OneDrive keeps syncing for a short tail. That is machinery draining, not a person acting, so it is visible without paging anyone. After that hour, continued activity is the real signal and fires at High.

Evidence: the event count, how many were deliberate operations, and when the disable was first observed.

Microsoft's own compliance engine does not count as the account acting (2026-08-05). When someone is offboarded, Purview continues processing their content server-side - DLP re-evaluation, label and retention operations - and Microsoft attributes those events to the now-disabled account. They are not a person; they are cleanup. Burrow recognises them by the fact that they carry no device address and excludes them from the count. The same operation performed from a real device still counts as the account acting.

This matters because Purview cleanup runs for essentially every leaver. Without the distinction, routine offboarding would produce a High alert per departure - which is precisely the noise that teaches people to ignore a rule.

False positives: the propagation tail (handled by the Low lane), and resource or service accounts that are deliberately kept sign-in-disabled but driven by automation. If you have one of those, add an entity exception for it.

Tuning advice: none needed at healthy volume - on a large tenant only a couple of disabled accounts a day show any activity at all. If one specific automation account keeps appearing, that is an exception, not a threshold change.

When to disable: never. And when it fires, check the account's active sessions and app passwords rather than just dismissing the alert - the alert is telling you the disable did not fully take effect.

`account_compromise` (SharePoint impossible-travel)

MITRE: T1078.004 (Cloud Accounts)
Severity: High

Fires when a user's SharePoint activity in the window spans several geographies AND at least one of them is new for that user versus their own baseline. (An earlier version of this rule read the datacenter region hosting your content rather than the user's location; it has since been rebuilt to use each user's real per-user geography baseline, the same way the Entra ID sign-in rules do.)

The account_compromise_new_country arm (2026-07-20). Alongside the multi-geography case above, this rule now has a dedicated new-country arm that fires on the first-ever registered country for an account's client IPs - the SharePoint-activity mirror of the Entra ID sign-in rule aad_new_country_signin. It uses the same infrastructure and proxy filtering and the same tenant-footprint gate, and follows the same New-country sign-in sensitivity setting: on Tenant-aware, a country that is new for this user but already established elsewhere in your tenant is demoted to Low (visible, no email), while a country new for the whole tenant stays High. Since 2026-08-05 the shipped default is the more sensitive setting, where new-for-the-user fires High regardless of the tenant footprint. Countries are shown by name with the ISO code.

A short visit from a new country is no longer missed (2026-08-05). The new-country check reads countries the routine background pass has already resolved. That meant a brief burst of activity from a genuinely new country could begin and end before that country had been resolved, and the alert would never fire at all. The check can now resolve a small, strictly bounded number of unseen addresses during the pass itself, so a short visit is caught in the same cycle rather than only if the activity continues. The bound is deliberate - it is what keeps a slow external lookup from ever delaying detection.

A demoted new-country alert is not re-escalated by a sensitive site (2026-07-21). When the new-country arm has been demoted to Low, a touch on a sensitive site does not bump it back up - the geography is not the concern here, so it stays dashboard-visible and off email. A genuinely risky co-signal is unaffected: an external share of a labelled file, for example, still fires and escalates under its own category.

Tunable knobs:

Knob	P	R	B	S	X
`n_geos`	3	2	2	2	2

Shared-egress suppression on the new-country arm (2026-07-13). The "new country" part of this rule now uses the same learned corporate-egress intelligence as the sign-in rules, shown on the Known Networks page. A country reached only through a learned shared-egress network (an office gateway, VPN, or cloud proxy such as Zscaler) is ignored, so a user editing documents while their traffic exits through a foreign proxy node no longer trips this rule. Because cloud proxies scatter users across many address ranges, a range too new to be flagged shared on its own is still recognised as corporate egress when a neighbouring range in the same block is already known shared for that country. A genuinely new country reached from an unrelated network still fires.

False positives: mobile users on flights or long trips, users with home and office in different geographies (border regions). Corporate proxy / VPN egress is now handled automatically by the shared-egress suppression above.

Tuning advice: prefer the Entra ID impossible_travel_signin rule as the primary location signal - sign-in events have cleaner timing data - and use this SharePoint rule as supporting evidence. If a legitimate proxy country still trips it, confirm the egress network is listed on Known Networks; it suppresses automatically once that network crosses the shared-user threshold.

`impossible_travel_signin` (Entra ID)

MITRE: T1078.004
Severity: High

Fires when a user's Entra ID sign-ins come from two countries too far apart for the elapsed time to be real travel. Rebuilt 2026-07-05 to baseline each entity's own connection countries from their actual client sign-in IPs - the earlier version measured tenant data residency and effectively could not tell where a user was.

Split-tunnel handling: a user who legitimately connects from two places at once (for example Australia direct plus a US proxy egress) baselines both countries and stays silent. The rule fires on genuinely implausible transitions, not on stable dual-homing.

Arm-up period: the per-entity country baseline needs roughly 7 days of sign-in history to become meaningful. On a fresh deployment, expect the first genuine firings from about a week after go-live.

False positives: legitimate travel where the sign-in interval is unrealistically short; new VPN egress adoption before the baseline catches up.

`aad_new_country_signin` (Entra ID)

MITRE: T1078.004 (Cloud Accounts)
Severity: context-dependent - High for a genuinely novel country, Low for a benign one (see the sensitivity control below)

New rule (2026-07-05). Fires on an Entra ID sign-in from a country the user has never signed in from before. This is the earliest point at which stolen credentials show up - the attacker authenticates from their own location before doing anything in SharePoint, so catching it at the auth layer beats waiting for downstream file activity. Each country is learned after it fires once (alert-once), so you are not re-alerted on the same country.

Each entity's set of known countries is learned from their own historical sign-in IPs. Split-tunnel and multi-country users baseline every country they genuinely use, so a stable second or third country does not fire - only a first-ever appearance does.

Infrastructure and shared-egress exclusion (2026-07-12). For a global company on a cloud proxy and Microsoft 365, most sign-ins egress through Microsoft or proxy infrastructure, not the user's actual location - which used to make this rule cry wolf. Two exclusions now apply before the rule considers a sign-in's country:

Microsoft's own infrastructure IPs and known cloud proxies are ignored - they are Microsoft or your proxy vendor, not the user. Each source IP's network owner is resolved live from the internet registry (not from a maintained IP list), so Microsoft and the major secure-web-gateway vendors (Zscaler, Cloudflare, Netskope, iboss, Forcepoint, and similar) are recognised by owner, and a vendor adding or moving ranges needs no update on your side.
Shared corporate egress is auto-detected. When enough distinct users sign in from the same network, Burrow classifies it as shared infrastructure (office gateway, VPN, proxy) and excludes its country from every user's baseline. There is no proxy list to maintain - it is learned per tenant from your own sign-in patterns. These learned networks are visible on the read-only Known Networks page, which exists so an analyst can see why Burrow stayed quiet on a given egress. Because a cloud proxy scatters users across many address ranges, a range too new to have crossed the shared-user threshold on its own is still treated as corporate egress when a neighbouring range in the same block is already known shared for that country.

The net effect: the rule now fires only on a residential or mobile IP in a genuinely new country - the real account-takeover signal - instead of on proxy egress.

Countries are named, not just coded (2026-07-20). The alert text, key metrics, and per-IP rows show the country name with its ISO code - "Maldives (MV)", not a bare "MV" - so you do not have to look up an unfamiliar code. This applies both here and in the SharePoint account_compromise new-country arm.

New for the user vs new for the tenant - the sensitivity control (2026-07-15). A globally-distributed organisation gets many benign "new country" sign-ins as staff connect from their home offices. Burrow can tell the difference between a country that is new for this user but already established across your tenant (a colleague already works from that office - almost certainly a legitimate employee) and a country novel for the entire tenant (genuinely anomalous). You choose how the former is treated in Settings → New-country sign-in sensitivity:

Tenant-aware - a country already known elsewhere in your tenant is Low (visible, no email); a country new for the whole tenant is High. This cuts routine global-staff noise while keeping genuinely novel countries loud.
Alert on every new country (current default) - every first-time country fires High. The earliest possible warning, at the cost of more noise.
Auto - follows your posture: Strict / Paranoid behave like "alert on every", otherwise Tenant-aware.

The default changed to the more sensitive setting (2026-08-05). New deployments now ship with the tenant-footprint discount off: a country new for the user fires High even when a colleague already works from that country. Previously it was demoted to Low. This is a deliberate choice of sensitivity over quiet, and it means a noticeable increase in new-country email on a globally distributed tenant - the alerts that used to sit at Low and never email now cross the threshold. If that volume is not what you want, switch Settings → New-country sign-in sensitivity to Tenant-aware to restore the previous behaviour; it takes effect on the next detection pass.

Either way, if a demoted (Low) sign-in is followed by risky activity, the daily escalation re-escalates the combined picture - so you never go blind on an account that is actually acting.

Arm-up period: like impossible_travel_signin, the country baseline needs about 7 days of per-user history to be trustworthy. Genuine firings begin roughly a week after deployment; before that the rule is intentionally quiet rather than flagging every country as "new", and accuracy improves as baselines deepen.

False positives: genuine first-time travel to a new country. (Proxy / VPN egress is handled by the exclusions above; routine global-staff noise is handled by the tenant-aware sensitivity.) Correlate with impossible_travel_signin and the user's travel calendar.

Tuning advice: high-value at the auth layer - do not disable. If you are a global company drowning in benign new-country alerts, set the sensitivity to Tenant-aware (this is no longer the default - see above). If you are a smaller, single-region organisation where any new country is worth knowing about immediately, use Alert on every new country (or a Strict / Paranoid posture). For a single globe-trotting executive who fires it often, a per-user entity exception is better than blunting the rule tenant-wide.

`mfa_fatigue` (Entra ID)

MITRE: T1621 (MFA Request Generation)
Severity: High

Fires on many MFA prompts to the same user in a short window - the attacker pattern of spam-prompting hoping for accidental approval.

`aad_password_spray` (Entra ID)

MITRE: T1110.003 (Brute Force: Password Spraying)
Severity: High

Fires when a single source IP produces credential-guess failures against five or more distinct valid accounts in the window - the textbook low-and-slow spray that per-user thresholds cannot see, because each individual account only gets one or two attempts. The alert's entity is the IP (not a user), since the users are the targets. Enrichment shows the offending IP, the affected usernames, and the error breakdown.

Credential-guess only counting (2026-07-03). The rule now counts only true credential-guess failures - bad password, disabled account, MFA-required-but-not-supplied. Stale-session token retries (FlowTokenExpired) are excluded because a device with an expired token auto-retries and generates apparent "failures" that were never a human guess. See noise gates for details.

Two independent demotion lanes. Either one on its own drops the alert to Low (with a note explaining which applied); the IP stays flagged either way.

Successes in the same window (2026-07-03). The failing users also successfully sign in from that same IP during the window - the shared-office-NAT pattern, colleagues behind one egress each mistyping once or twice.
Learned corporate egress (2026-07-28). The source IP belongs to a network Burrow has already learned is shared office, VPN, or proxy infrastructure - the Known Networks list. This lane exists because lane 1 only samples the current window: a large office can easily produce a window where too few of the targeted users happen to sign in successfully, which used to re-fire the same known network as critical day after day. The alert's evidence names the learned network when this lane applies.

Failed sign-ins from a network that is not on the Known Networks list are unaffected - an outside attacker still raises the alert at full severity.

False positives: shared office / VPN egress with a mixed user population, and staff working with an expired password. The two lanes above handle the common cases.

Tuning advice: treat elevated (non-demoted) alerts as real - the gates above filter the routine noise.

`aad_password_spray_lockout` (Entra ID)

MITRE: T1110.003
Severity: Critical

Fires when the spray pattern above additionally causes account lockouts. Separate rule because lockout is a much stronger signal - the attacker's guessing has crossed Microsoft's lockout threshold on at least one account.

`aad_username_enumeration` (Entra ID)

MITRE: T1589.002 (Gather Victim Identity Information: Email Addresses)
Severity: dynamic - High for pure reconnaissance (every attempt hits a non-existent username, error code UserNotFound only), Critical when the error mix includes anything other than UserNotFound (attacker has found a valid username and is now guessing credentials). In paranoid posture every alert is Critical regardless.

Fires when a single source generates many failed sign-in attempts against distinct usernames in a short window. Enrichment shows the source location (Microsoft's geo field), an error-code breakdown ("UserNotFound × 6, InvalidPassword × 2"), and a UserNotFound only flag that drives the severity decision.

False positives: legacy applications with stale credentials retrying against renamed accounts, migrated tenants with old service-account references.

Tuning advice: the severity split is designed to elevate mixed-error alerts because that shape means the attacker crossed from recon into credential guessing. Do not blunt the critical-severity behaviour - a valid-username-plus-wrong-password sequence is the highest-value early signal.

`oauth_consent_grant` (Entra ID)

MITRE: T1528 (Steal Application Access Token)
Severity: Medium / High (severity scales with scope sensitivity)

Fires when an application is granted OAuth scopes on the operator-curated sensitive-scopes list.

Tuning advice: review the sensitive-scopes list periodically - Microsoft adds new scopes regularly.

`site_collection_admin_grant`

MITRE: T1078.004
Severity: High

Fires on any SharePoint site-collection-admin role grant.

Microsoft provisioning gate (2026-07-03). The service identities Microsoft\ServiceOperator and SHAREPOINT\system are demoted to Low when they grant themselves site admin or set site policy. Both are internal automated provisioners that cannot be impersonated externally - the grant is Teams/site setup running its normal course. Any other identity granting site admin still fires at full severity. See noise gates for details.

Site-provisioning burst gate (2026-07-09). When a real user creates a Team or Plan, Microsoft's pipeline stamps the automatic SiteCollectionCreated → SiteCollectionAdminAdded (Owners group) → SharingPolicyChanged burst with the user's own identity - so it slips past the service-actor gate above and used to fire three separate emails (permission_escalation + site_collection_admin_grant + tenant_policy_change). Burrow now correlates these by site: when every admin/policy/permission op is on a site created in the same window and the grant is to that site's own Owners group, permission_escalation and tenant_policy_change are suppressed and a single Low site_collection_admin_grant record is kept for the cluster (no email). A grant to a specific person, or on a pre-existing site, is untouched and stays Critical. See noise gates.

False positives: legitimate admin onboarding new site owners.

Tuning advice: none - investigate every non-demoted firing.

When to disable: never.

`external_user_group_add`

MITRE: T1098 (Account Manipulation)
Severity: Medium

Fires on guest account additions to security or distribution groups.

Names the guest (2026-07-09). Adding an external guest to a group is standing access, not a single-file share, and the alert treats it that way. The investigation digest now names the guest and the site - "Added EXTERNAL guest t.brennan@northwind-audit.example directly to a SharePoint group on /sites/Finance - standing access" - with the address de-mangled from Microsoft's #EXT# encoding, instead of a generic "shared an item" line. Group adds also show up in the External Sharing report under the "Guest → group" type.

Counts people, not events (2026-07-10). Microsoft can log a single guest addition as many separate add-events, which used to read as "added 12 Guest user(s)" when it was really one person. The alert now counts distinct guests in the headline and keeps the raw event count as context - "added external guest r.calder@northwind-audit.example (12 add events)" - and names each guest rather than reporting a bare number.

Untrusted guest adds escalate (2026-08-14). The mirror of the partner policy: if the added guest is from a domain on your Untrusted domains list, the alert is recorded as external_user_group_add_untrusted and its severity is raised to your chosen level. Standing access granted to a personal-mail identity is the riskiest shape this alert takes - no expiry, everything the group can reach, held by an address outside any organisation's control. This never lowers an alert, and it cannot collide with the partner discount because the two lists are not allowed to overlap.

The partner discount is now available here, but you have to ask for it (2026-08-05). Guest additions record the guest's domain, so an add from a domain on your External Partners list carries that fact into the alert and the AI reasons from it. Whether it also reduces severity is an admin choice, and the default is no.

The reasoning: adding a guest to a group grants standing access - no expiry, everything the group can reach, harder to revoke than a sharing link - so it is a bigger grant than a share and worth a look even from a known partner. Quieter treatment is therefore opt-in rather than automatic, which is why it is a separate selector from the sharing policy.

If routine partner onboarding is noisy for you, set "When guests added to groups are all partners" on the Internal Domains page to one of the reduction levels. It applies only when every added guest is from a partner domain - one unknown guest keeps full severity - and the reduced severity is capped so co-occurring signals cannot silently re-escalate a grant you have declared expected. When it applies, the alert is recorded as external_user_group_add_partner, so the two cases stay separable in review.

For noise from one specific onboarding account rather than a whole partner domain, an entity exception is still the better tool.

False positives: legitimate guest onboarding for partner projects.

Tuning advice: correlate with risky_sharing - guest add followed by immediate external share is more suspicious than guest add alone.

Device and IP

`unmanaged_device_access`

MITRE: T1078
Severity: High

Fires when both gates trip: unmanaged-device event count crosses threshold AND labelled-file count crosses threshold. Pure unmanaged volume without labelled-file involvement does not fire.

Tunable knobs:

Knob	P	R	B	S	X
`unmanaged_events`	500	200	100	50	20
`labeled_files`	25	20	10	5	1

Office-Online guard (2026-07-05). Excel and Word Online render-farm and co-authoring requests (the MSWAC / MSOCS clients) report "unmanaged device" because there is literally no device in the request path - the work happens in Microsoft's browser render farm. Those requests no longer count toward this rule. Real BYOD traffic from an actual unenrolled device still does.

False positives: mobile-app access on personal devices, BYOD users with unenrolled devices doing routine work.

Tuning advice: if your tenant does not enforce device compliance broadly, this rule will be noisy. Either disable it or add OU-scoped exceptions.

When to disable: if your tenant has no MIP labelling rollout (the rule relies on label presence to fire meaningfully).

`anonymizer_access_high` / `anonymizer_access_critical`

MITRE: T1090.003 (Multi-hop Proxy)
Severity: High on any Tor-sourced event; escalates to Critical at the volume threshold (sustained access)

Fires on access from Tor exit-node IPs - High on a single event, since legitimate users do not browse SharePoint over Tor, rising to Critical once the volume threshold is crossed. The Tor exit list is refreshed from a public source on every detection pass.

False positives: essentially zero. Tor to SharePoint is not a legitimate access pattern.

Tuning advice: keep at default. If a known security-team red-team exercise is in progress, add a temporary exception with an expiry note in the reason text.

When to disable: never.

`malicious_ip_access_high` / `malicious_ip_access_critical`

MITRE: T1071 (Application Layer Protocol)
Severity: High on any event from a listed IP; escalates to Critical at the volume threshold (sustained access)

Fires on access from IPs on a public threat-intelligence list (botnets, brute-forcers, scanners) - High on a single event, rising to Critical at sustained volume. The list is refreshed each detection pass.

False positives: the threat-intel list occasionally includes cloud-provider IP space. Verify any single-IP repeat alert.

When to disable: never.

`anon_link_used`

MITRE: T1567 (Exfiltration Over Web Service)
Severity: High

New rule (2026-07-20). Fires when someone actually uses an anonymous link to access content. This is distinct from risky_sharing_anon, which fires on link creation: creating a link is exposure, but using it is the actual exfiltration event - an unauthenticated party outside your tenant has just fetched the file.

Evidence: what was accessed and from where.

False positives: rare - a colleague opening an anonymous link while signed out, or a scanner following a link. The linked file and source IP usually settle it.

Tuning advice: per-label overrides can escalate it - for example, anonymous use of a Confidential-labelled file to Critical. Pair with the External Sharing report to find and remove the underlying link.

When to disable: never - if anonymous links are blocked tenant-wide it simply never fires.

`malware_in_library`

MITRE: T1204.002 (User Execution: Malicious File)
Severity: Critical (always)

New rule (2026-07-20). Fires when Microsoft Defender for SharePoint marks a file in a library as malware. Burrow does not scan files itself - it surfaces Defender's verdict with the who / where context so it is not lost in the admin-center noise.

False positives: effectively none - Defender has already convicted the file. The open question is how it got there and who touched it, which is what the alert's context answers.

Tuning advice: none needed. This rule is exempt from every downgrade and corroboration pass - a confirmed-malware event is never demoted.

When to disable: never.

`dlp_policy_bypass`

MITRE: T1078 (Valid Accounts - DLP policy override)
Severity: Critical

New rule (2026-07-20). Fires when a user clicks override on a Data Loss Prevention policy block. By default only external-recipient overrides fire - overriding to share a flagged file with a colleague is poor hygiene, not exfiltration. Compliance-minded tenants can alert on every override (any recipient) via a per-rule override on the Rules page.

Evidence: the override count (total / external / internal), what the DLP policy matched, and the details of each override.

False positives: users who legitimately override a too-broad DLP policy - but the override intent is explicit and loud, which is why it stays Critical and is exempt from downgrade passes.

When to disable: if you have no DLP policies configured in Microsoft 365, it never fires anyway.

Anti-forensics

`audit_tampering`

MITRE: T1562.008 (Disable Cloud Logs)
Severity: Critical

Fires on any single audit-config modification event.

False positives: legitimate admin reconfiguration of audit policy. Should be rare and traceable to a named admin.

Tuning advice: none - investigate every firing.

When to disable: never.

`label_tampering`

MITRE: T1562 (Impair Defenses)
Severity: High

Fires when a sensitivity label is downgraded or removed from a file. The rule honours a per-tenant watchlist - it only fires when the changed label is one you have marked as sensitive on the Sensitive Labels page. Empty watchlist = fire on all label changes (backward-compat default).

Approving a label on the Sensitive Labels page bulk-promotes sites carrying it as sensitive AND arms label_tampering for that label at the same time. Dismissing removes both. One list of "labels I care about" drives site categorisation and tampering alerts together.

The Rules page shows the current scope on the label_tampering row: either "Currently firing on ALL label changes" (empty watchlist) or "Currently gated to N labels" (with a jump-link to the Sensitive Labels page).

Evidence rendering: the alert detail shows the old label and new label on the affected file when the Microsoft audit event carries them. Some audit variants omit the label fields - in that case, the detail reads (not in audit event) → (removed) so the operator can at least see that a label change occurred and what happened to it.

False positives: legitimate re-labelling as documents move between projects, users mis-clicking the label picker, automated tooling adjusting labels during migration.

Tuning advice: start with an empty watchlist to establish the baseline volume, then add your critical labels (Highly Confidential, Restricted, industry-regulated categories) to focus alerts. Broad watchlists produce noise; the rule is highest-signal when scoped to labels whose removal is genuinely policy-violating.

When to disable: never - narrow the watchlist instead.

`recyclebin_restore_high` / `recyclebin_restore_med`

MITRE: T1070 (Indicator Removal)
Severity: High / Medium

Fires on recycle-bin restore burst - many file restorations in a short window.

Tunable knobs:

Knob	P	R	B	S	X
`recyclebin_restore_high.recyclebin_restored`	500	200	100	50	25
`recyclebin_restore_med.recyclebin_restored`	150	60	30	15	8

False positives: legitimate undo of a bulk delete, retention-policy reversal, project resurrection.

Tuning advice: correlate with prior delete activity. If the same user has a high mass_deletion_* alert in the same day, the restore is meaningful (could be cover-up or oops). Standalone, more often benign.

UEBA family - baseline-relative deviation rules

These rules do not have numeric posture knobs the way the deterministic rules above do. Each compares today vs the user's own prior days. Common gates: minimum baseline-days required before the rule can fire, and minimum events-per-baseline-day for a day to count toward the baseline.

User-active operations gate (family-wide). Every UEBA rule in this section requires a minimum count of human-initiated operations (modify / download / upload / delete / move / copy) before it can fire, regardless of how many passive events (view / preview / access / page render) occurred. This gate stops content-heavy SharePoint page rendering from tripping exfil-shaped alerts on users who merely browsed - the alerts still show 300+ file-touches in Top Evidence, but if none of them were downloads or modifies, no alert fires. The Operation breakdown line on each alert exposes both counts so the operator can see what the user actually did.

Cross-site move gate (2026-07-12). When a delete spike is really a cross-site file move (delete in one site, the same files uploaded into another), the shared cross-site-move verdict demotes the delete-spike UEBA rules - behavioral_deviation and intraday_velocity_burst - to Low, so a folder re-filing no longer fires a stack of behavioural alerts on top of the deletion rules.

`behavioral_deviation`

MITRE: T1078
Severity: scales with magnitude (Medium for a strong deviation, High for an extreme one)

Fires when today's spike on a specific metric (distinct files, downloads, deletes, etc.) is far above the user's own typical day AND is at least twice that typical day. The alert summary leads with which metric spiked: e.g. distinct_files spiked: today=576 vs typical day=33 (17x). The metrics grid shows the spiked metric, today's value, and the typical-day value as their own tiles.

Robust baseline: median instead of mean (2026-07-21). The "typical day" is now measured with robust statistics - the median of the user's daily history and how much a normal day varies around it - rather than a mean and standard deviation. This fixes two long-standing failure modes on the bursty, uneven day-counts real people produce: a near-zero average no longer inflates one ordinary day into a huge "15-sigma" spike, and one wild historical day no longer widens the spread so much that a genuinely anomalous later day scores low. Because a single outlier day barely moves the median, a compromised account can no longer quietly fold its own attack into the baseline.

Single-file byte-spike demotion (2026-07-05). When the byte spike driving the deviation is essentially one large file (80% or more of the day's bytes in a single file), the alert demotes to low and names the file, instead of firing a dramatic "40x baseline" deviation. Downloading one big CAD model or video is not the shape of exfiltration. Multi-file spikes are unaffected.

Slow-drift guard (2026-07-26). The baseline adapts to genuine behaviour changes, which in principle lets a patient insider ramp their volume slowly enough that each day still looks "normal" against a baseline that is quietly climbing with them. The guard defends against that: Burrow keeps a second, slow reference built only from days at least 14 days old (a recent ramp can't touch it) and compares the user's recent normal against it. If the recent normal has climbed past essentially every established day and reached at least twice the established median, the alert flags that the baseline itself has been ramping and additionally scores today against the long-term reference - so a slow ramp never buys invisibility. The guard only ever adds detection: accounts whose recent and long-term behaviour agree are untouched. When it fires, the alert carries a baseline-drift note so an analyst (and the AI) don't wave it off as "in line with their recent normal".

False positives: users returning from leave and seasonal-spike work - both materially reduced by the median approach, since absence days pull a mean down but leave the median honest for a mostly-active user.

Tuning advice: raise the minimum baseline-days gate to reduce cold-start noise.

`unusual_hour_activity`

MITRE: T1078
Severity: Medium / High (scales with how far outside typical hours)

Fires when events occur in hours where the user's baseline shows minimal activity. Requires at least a week of baseline.

Passive-browsing gate (2026-07-03). An off-hours session that only reads pages - zero downloads, edits, deletes, uploads, or shares - is now demoted. An early or late login by someone catching up on documents no longer pages the SOC. Off-hours sessions that touch data still fire at full severity. See noise gates for the rationale.

Timezone awareness (2026-07-25). "Typical hours" are learned from each user's own observed activity, so a consistently Australia- or Chile-based user's normal working day never flags regardless of the server's timezone. Burrow also infers each user's likely timezone from their activity pattern and shows their typical hours in local terms - e.g. "09:00-17:00 local (UTC+10)" - on the identity dossier and in the AI explanation, so an alert note no longer describes someone's ordinary local morning as "outside usual hours".

False positives: shift workers, on-call rotation, end-of-quarter crunch, travel across timezones.

Tuning advice: the passive-browsing gate already cuts most legitimate off-hours reading. For remaining noise, add per-user exceptions for known late-shift staff or raise the baseline-maturity gate.

`weekend_posture_drift`

MITRE: T1078
Severity: High

Fires on weekend activity for a user whose baseline shows no weekend activity.

Local-weekend aware (2026-07-25). "Weekend" is judged in the user's own local time, hour by hour - a day only counts as their weekend when most of its activity fell on their local Saturday or Sunday. An Australian user's Monday morning (which lands in the server's Sunday) no longer fires this rule, and their weekend baseline is built from their local weekends.

False positives: on-call, deadline weekend work.

Tuning advice: respects baseline - a user who regularly works weekends will not fire. If still noisy, increase the baseline-maturity gate.

`dow_drift`

MITRE: T1078
Severity: Medium

Fires when a user is active on a weekday they are historically silent on. Weekends are owned by weekend_posture_drift and skipped here - a weekday worker active on a Saturday no longer double-alerts on both rules.

Rollup-day scoring (2026-07-03). The comparison is against the day the alert rolled up under, not the current wall-clock day. Previously an alert generated late Sunday for a Friday-day pattern could score against Sunday's baseline (usually zero) and always trip. Rollup-day scoring compares Friday's activity against Friday's baseline - the intended behaviour.

Local-day aware (2026-07-25). The day-of-week is judged in the user's own local day (inferred from their activity pattern), not the server's - so an Australian user's Monday-morning work counts as Monday history, not a Sunday anomaly, and both today and the baseline are classified the same way.

False positives: conference travel, deadline crunch, mid-week catch-up after a day off.

Tuning advice: noisy - one of the first rules many operators downgrade. Either accept as audit data only or raise the active-percentage threshold.

`ua_anomaly`

MITRE: T1078
Severity: Medium - High when the new user-agent carries an attacker-tool fingerprint (python-requests, curl, PowerShell, and the like)

Fires when a user-agent string appears that was not in the user's baseline UA set. Requires at least 3 days of UA baseline.

Built-in noise suppression (three layers, 2026-07-20). This rule used to be one of the noisiest; three layers now keep it quiet by default:

Version-blind comparison. Version numbers and build IDs are stripped before the never-seen check, so a version bump of a client the user already runs (Edge 130 to 131, a OneDrive sync client minor version, and so on) does not fire.
Machinery is never a "new client". Server-side SharePoint / Office machinery user-agents (page-render and thumbnail/preview services) and Microsoft first-party client rollouts (OneDrive, Office, Teams) are structurally ineligible. This matters because some Microsoft service user-agents embed the build date in their version string, so every M365 platform rollout used to mint a tenant-wide wave of "never-before-seen UA" alerts.
Attacker-tool user-agents are always eligible regardless of the above, and fire at High.

False positives: a genuinely new personal device, mobile UA drift.

Tuning advice: with the suppression above, this rule is quiet by default. It is highest-confidence paired with another signal (UA anomaly + impossible-travel = real signal; a lone UA anomaly on an ordinary browser is usually noise).

`intraday_velocity_burst`

MITRE: T1078
Severity: scales with the size of the overshoot - Low for 1.10–1.50× the user's historical max, Medium for 1.50–2.00×, High for ≥ 2.00×.

Fires when today's value on a metric exceeds the user's historical daily maximum by at least 10 %. The 10 % floor is a rule-hard gate - a one-file overshoot (today=74 vs max=73) will not fire. The alert summary leads with the percentage overshoot in plain language ("exceeds max by 47 %") and the metrics include historical_max, over_max, and max_ratio.

False positives: batch jobs, automated sync, bulk-edit sessions.

Tuning advice: for users who legitimately batch-work above their prior max, raise the required ratio via override - 1.20 or 1.50 as a floor takes small overshoots off the board without disabling the rule.

`unmanaged_baseline_spike`

MITRE: T1078
Severity: High

Fires when unmanaged-device event count spikes vs baseline.

`search_baseline_deviation`

MITRE: T1083
Severity: High

Fires on search-query volume spike vs baseline.

Tuning advice: correlate with sensitive_search for high-confidence signals.

`peer_group_deviation`

MITRE: T1078
Severity: High

Fires when a user's metric (distinct files, downloads, etc.) is far above the median of their peer group AND far above the peer-group median in robust statistical terms (MAD-z). Peer group is auto-derived by class (human, service-app).

False positives: users in atypical roles misclassified into the wrong peer group.

Tuning advice: if a known IT user keeps firing, add an entity exception. The peer-class assignment is automated.

Meta and correlation

`daily_pattern_escalation`

MITRE: varies (cumulative)
Severity: maximum of constituent alert severities + 1 tier

Fires when a user's cumulative day score crosses a threshold. The score weights severity x category diversity x time spread x slope. When this fires, Burrow sends ONE meta-alert for the user's day instead of N raw per-alert emails for the rest of the day.