Why is disabling 2FA treated as critical on its own?

Because it has no benign emergency use. Turning off an organization's 2FA requirement makes every account in the org easier to compromise and easier to retain access to after a password reset — it is a deliberate weakening of the recovery path. Legitimate policy changes are planned, announced, and ticketed. An unannounced one is either a compromised owner account or an insider, and both warrant an immediate response.

Why does the rule require persistence and exfiltration together, but treat 2FA and destruction alone?

Adding an org member and creating a webhook are both common in normal operations — teams onboard people and wire up CI constantly, so alerting on either alone would be unusable. Seeing both inside 30 minutes is far more specific: it is the shape of establishing access and then a data channel. Disabling 2FA and destroying a repository have no routine equivalent, so they stand alone.

How does a webhook become an exfiltration channel?

An organization or repository webhook fires on every push and can be pointed at any URL the attacker controls. Once planted, it quietly streams commit contents and metadata out of your org for as long as it exists — no cloning, no unusual API traffic, nothing that resembles a bulk download. It survives password resets and often outlives the incident response, which is why hook.create belongs in a takeover detection rather than being treated as routine configuration.

Does this cover compromised GitHub Actions or malicious dependencies?

Only partially. This rule targets organization-level administrative takeover. Workflow tampering and dependency poisoning are related supply-chain techniques (also T1195.002) but appear as different actions — workflow file changes and package publication events — and need their own detections. The integration_installation.create selection here does cover a malicious GitHub App being installed, which is a common bridge between the two.

Detect GitHub Organization Takeover and Backdooring in Audit Logs

Sigma Rule

title: GitHub Organization Takeover and Backdoor Persistence
id: 9e2f7b58-4c31-42a6-b7d9-05e8a1c36f4d
status: experimental
description: >
  Detects the action sequence of a GitHub organization takeover. An attacker who
  compromises an owner account disables the 2FA requirement to weaken recovery,
  adds a backdoor member for persistence, plants a webhook to exfiltrate source
  on every push, and may destroy repositories to cover tracks or extort. Each
  action is individually rare and administratively significant.
references:
  - https://attack.mitre.org/techniques/T1098/
  - https://attack.mitre.org/techniques/T1195/002/
author: LogTriage
date: 2026/08/04
logsource:
  product: github
  service: audit
detection:
  mfa_weakened:
    action:
      - 'two_factor_authentication.disabled'
      - 'org.disable_two_factor_requirement'
  persistence_added:
    action:
      - 'org.add_member'
      - 'org.update_member'
      - 'org.invite_member'
  exfil_channel:
    action:
      - 'hook.create'
      - 'integration_installation.create'
  destructive:
    action:
      - 'repo.destroy'
      - 'org.remove_member'
  timeframe: 30m
  condition: (mfa_weakened or destructive) or (persistence_added and exfil_channel)
falsepositives:
  - Planned org security-policy change during a migration (ticketed, by an owner)
  - Legitimate CI/CD webhook setup pointing at a known internal endpoint
  - Repository archival or cleanup during offboarding
level: critical
tags:
  - attack.persistence
  - attack.t1098
  - attack.defense_evasion
  - attack.t1562.001
  - attack.initial_access
  - attack.t1195.002

What this rule detects

A GitHub organization takeover is not one event, it is a short sequence — and the sequence is remarkably consistent because the attacker’s goals are always the same: keep access, get the source out, and make recovery hard.

The rule watches four action groups:

Group	Actions	Attacker goal
MFA weakened	`two_factor_authentication.disabled`, `org.disable_two_factor_requirement`	Make recovery harder, keep access after a reset
Persistence	`org.add_member`, `org.update_member`, `org.invite_member`	A backdoor account that survives the original compromise
Exfil channel	`hook.create`, `integration_installation.create`	Stream source code out on every push
Destructive	`repo.destroy`, `org.remove_member`	Cover tracks, deny access, or extort

Detection logic

The condition is deliberately asymmetric:

(mfa_weakened or destructive) or (persistence_added and exfil_channel)

Disabling 2FA or destroying a repository fires alone. Neither has a routine equivalent. There is no emergency that requires turning off an org’s 2FA requirement, and repository destruction is never a surprise in a healthy organization.

Adding a member or creating a webhook needs a partner. Both happen constantly during normal work — onboarding, CI setup, integrations. Alerting on either alone would drown you. But together, within 30 minutes, they form a recognisable shape: establish access, then establish a data channel.

That asymmetry is the whole design. Rules that treat every administrative action as equally suspicious get muted within a week.

Validated against a real sample

Validated against github_audit_attack.json (shipped with LogTriage), which contains the full chain from actor attacker-bot across two source IPs in under four minutes:

repo.destroy on corp-org/critical-infra from 185.220.101.42
two_factor_authentication.disabled from the same IP one minute later
org.add_member creating new-backdoor-account — note the switch to 45.142.212.100
hook.create on corp-org/main-app, planting the exfiltration channel

Every branch of the condition is exercised: destruction and MFA-weakening each fire independently, and the member-plus-webhook pair fires as a correlated pattern.

The rule stays silent on the matching benign log, which contains routine repository and member activity — zero occurrences of any of the four monitored actions.

False positives

The recurring benign cases all share one property: they are planned. A 2FA policy change during a migration, a CI integration adding a webhook, repository archival during offboarding — each is legitimate and each should correlate with a ticket and a known actor.

That makes the triage question simple, and it is not really about the log: was this change expected, and was it made by someone who should be making it? An unannounced administrative change to an org is worth a phone call even when it turns out to be legitimate.

Frequently Asked Questions

Why is disabling 2FA treated as critical on its own?: Because it has no benign emergency use. Turning off an organization's 2FA requirement makes every account in the org easier to compromise and easier to retain access to after a password reset — it is a deliberate weakening of the recovery path. Legitimate policy changes are planned, announced, and ticketed. An unannounced one is either a compromised owner account or an insider, and both warrant an immediate response.
Why does the rule require persistence and exfiltration together, but treat 2FA and destruction alone?: Adding an org member and creating a webhook are both common in normal operations — teams onboard people and wire up CI constantly, so alerting on either alone would be unusable. Seeing both inside 30 minutes is far more specific: it is the shape of establishing access and then a data channel. Disabling 2FA and destroying a repository have no routine equivalent, so they stand alone.
How does a webhook become an exfiltration channel?: An organization or repository webhook fires on every push and can be pointed at any URL the attacker controls. Once planted, it quietly streams commit contents and metadata out of your org for as long as it exists — no cloning, no unusual API traffic, nothing that resembles a bulk download. It survives password resets and often outlives the incident response, which is why hook.create belongs in a takeover detection rather than being treated as routine configuration.
Does this cover compromised GitHub Actions or malicious dependencies?: Only partially. This rule targets organization-level administrative takeover. Workflow tampering and dependency poisoning are related supply-chain techniques (also T1195.002) but appear as different actions — workflow file changes and package publication events — and need their own detections. The integration_installation.create selection here does cover a malicious GitHub App being installed, which is a common bridge between the two.

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs