Full Rule Catalog (with MITRE Mapping)

33 min read

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.

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.

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 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.

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.

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_critical`

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` / `risky_sharing_orgwide`

MITRE: T1530 (Data from Cloud Storage)
Severity: High (anonymous links), Medium (external shares), Low (org-wide / company links)

Fires on three sub-conditions: anonymous link creation, external shares, or org-wide link events above threshold.

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.

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`

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

Fires when search-query count crosses threshold.

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_high 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_high 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_high`

MITRE: T1083
Severity: High

Fires on search queries matching the operator-configured sensitive keywords list.

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

`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.)

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 are ignored - they are Microsoft, not the user.
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 such as Zscaler) 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.

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 (default under most postures) - 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 - every first-time country fires High. The earliest possible warning, at the cost of more noise. This is the default under a Strict or Paranoid posture.
Auto - follows your posture: Strict / Paranoid behave like "alert on every", otherwise Tenant-aware.

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, leave the sensitivity on Tenant-aware. 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 failed sign-in attempts against multiple distinct accounts in a short window. Enrichment shows the offending IP, the affected usernames, and error codes.

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.

Known-good-IP guard (2026-07-03). When the failing users also successfully sign in from the same IP in the same window, the alert is demoted - this is the shared-office-NAT pattern (colleagues behind one egress each mistyping once or twice). The IP stays flagged; the alert drops from High to Low so it does not page. When no one on the IP has ever succeeded, severity is unchanged.

False positives: shared office / VPN egress with mixed user population. The known-good-IP guard handles the common case.

Tuning advice: treat elevated (non-demoted) alerts as real - the two 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 vinh.tran@claconnect.com 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 audrilia.parsa@pwc.com (12 add events)" - and names each guest rather than reporting a bare number.

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_critical`

MITRE: T1090.003 (Multi-hop Proxy)
Severity: Critical

Fires on access from Tor exit-node IPs. 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_critical`

MITRE: T1071 (Application Layer Protocol)
Severity: Critical

Fires on access from IPs on a public threat-intelligence list (botnets, brute-forcers, scanners).

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

When to disable: never.

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 >= 4 sigma, High for >= 6 sigma, Critical for >= 10 sigma)

Fires when today's spike on a specific metric (distinct files, downloads, deletes, etc.) is far above the user's own mean in standard deviations. The alert summary leads with which metric spiked: e.g. distinct_files spiked: today=576 vs 21-day baseline avg=33 (17.3x, 4.4sigma). The metrics grid shows the spiked-metric, today's value, and the baseline average as their own tiles.

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 "40× baseline" deviation. Downloading one big CAD model or video is not the shape of exfiltration. Multi-file spikes are unaffected.

False positives: users returning from leave (their mean includes zeros for absence days), users in seasonal-spike work.

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.

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.

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.

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

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.

False positives: browser updates, OS updates, new device, app version bumps, mobile UA drift.

Tuning advice: very noisy. Pair with another signal for higher confidence (UA anomaly + impossible-travel = real signal; UA anomaly alone = 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_high 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.