GitHub MFA Requirement Disabled

Description

Detects when the two-factor authentication (2FA) requirement is disabled for a GitHub organization or enterprise. Removing the requirement downgrades every member in scope to password-only authentication and allows new members to be added without 2FA. Following an account takeover, an adversary may disable the requirement to preserve password-based access, reduce friction for enrolling attacker-controlled accounts, and lower the organization's overall account-takeover resistance, making this a high-impact identity-control change.

Query · esql

from logs-github.audit-* metadata _id, _index, _version
| where
  event.module == "github" and data_stream.dataset == "github.audit"
    and event.action in ("business.disable_two_factor_requirement", "org.disable_two_factor_requirement")
| keep
    _id,
    _index,
    _version,
    @timestamp,
    event.action,
    user.name,
    github.org,
    github.repo,
    github.actor_ip,
    github.hashed_token,
    github.programmatic_access_type,
    github.user_agent,
    github.business

Investigation fields

Pivot points the source recommends for triage.

  • @timestamp
  • event.action
  • user.name
  • github.org
  • github.repo
  • github.actor_ip
  • github.hashed_token
  • github.programmatic_access_type
  • github.user_agent
  • github.business

Known false positives

  • Emergency access during an IdP outage. This should be rare, ticketed, and re-enabled immediately.

Analyst notes

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating GitHub MFA Requirement Disabled

This rule triggers on business.disable_two_factor_requirement and org.disable_two_factor_requirement, which turn off the enforced two-factor authentication (2FA) requirement for an entire GitHub enterprise or organization. Removing the requirement downgrades every member in scope to password-only authentication and permits new members to be invited without 2FA. An adversary who has taken over an owner or enterprise-admin account may disable the requirement to preserve password-based access, reduce friction for adding attacker-controlled accounts, and lower the organization's account-takeover resistance before pursuing persistence, privilege escalation, or data theft.

Possible investigation steps

  • Identify the actor from user.name, github.actor_ip, github.user_agent, and github.programmatic_access_type, and confirm whether they legitimately hold organization owner or enterprise admin privileges.
  • Determine the scope of the change from event.action (org.disable_two_factor_requirement vs business.disable_two_factor_requirement) and the affected github.org/github.business, and verify whether it was approved in change-management records.
  • Review authentication context for the actor around the event time for signs of takeover, such as sign-ins from new github.actor_ip addresses, unfamiliar user agents, or token-based access (github.programmatic_access_type) in place of normal interactive activity.
  • Correlate for other high-impact identity changes near the same timestamp, including owner or member additions, PAT or OAuth app grants, SSH/GPG key additions, SSO/SAML changes, and IP allow-list modifications.
  • If the change is unauthorized, re-enable the 2FA requirement before continuing the investigation to limit exposure.

False positive analysis

  • A documented break-glass procedure during an identity-provider or 2FA outage may require temporarily disabling the requirement; this should be rare, ticketed, time-bounded, and followed by immediate re-enablement.
  • A planned governance or migration change (for example, consolidating organizations or adjusting enrollment policy) performed by a known administrator can generate this event as expected activity.

Response and remediation

  • Re-enable the required 2FA setting for the affected organization or enterprise as soon as the change is confirmed unauthorized.
  • Force sign-out of active sessions and audit the member list for accounts not enrolled in 2FA, requiring enrollment or suspending them.
  • Rotate credentials and tokens created or used after the requirement was disabled, including PATs, OAuth app grants, and SSH keys.
  • Review org and enterprise audit logs for other changes made by the actor after the disable event, and revert any unauthorized modifications.
  • Escalate to incident response if the actor is unknown or unauthorized, or if the disable event is accompanied by new owner additions, token grants, or sign-ins from unfamiliar infrastructure.
  • Harden by enforcing 2FA at the enterprise level, restricting who can change organization security settings, and alerting on future changes to the 2FA requirement.
Raw source GitHub MFA Requirement Disabled · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified. 
[metadata]
creation_date = "2026/11/02"
integration = ["github"]
maturity = "production"
updated_date = "2026/11/03"

[rule]
author = ["Elastic"]
description = """
Detects when the two-factor authentication (2FA) requirement is disabled for a GitHub organization or enterprise.
Removing the requirement downgrades every member in scope to password-only authentication and allows new members to be
added without 2FA. Following an account takeover, an adversary may disable the requirement to preserve password-based
access, reduce friction for enrolling attacker-controlled accounts, and lower the organization's overall
account-takeover resistance, making this a high-impact identity-control change.
"""
false_positives = [
    "Emergency access during an IdP outage. This should be rare, ticketed, and re-enabled immediately.",
]
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "GitHub MFA Requirement Disabled"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating GitHub MFA Requirement Disabled

This rule triggers on `business.disable_two_factor_requirement` and `org.disable_two_factor_requirement`, which turn off the enforced two-factor authentication (2FA) requirement for an entire GitHub enterprise or organization. Removing the requirement downgrades every member in scope to password-only authentication and permits new members to be invited without 2FA. An adversary who has taken over an owner or enterprise-admin account may disable the requirement to preserve password-based access, reduce friction for adding attacker-controlled accounts, and lower the organization's account-takeover resistance before pursuing persistence, privilege escalation, or data theft.

### Possible investigation steps

- Identify the actor from `user.name`, `github.actor_ip`, `github.user_agent`, and `github.programmatic_access_type`, and confirm whether they legitimately hold organization owner or enterprise admin privileges.
- Determine the scope of the change from `event.action` (`org.disable_two_factor_requirement` vs `business.disable_two_factor_requirement`) and the affected `github.org`/`github.business`, and verify whether it was approved in change-management records.
- Review authentication context for the actor around the event time for signs of takeover, such as sign-ins from new `github.actor_ip` addresses, unfamiliar user agents, or token-based access (`github.programmatic_access_type`) in place of normal interactive activity.
- Correlate for other high-impact identity changes near the same timestamp, including owner or member additions, PAT or OAuth app grants, SSH/GPG key additions, SSO/SAML changes, and IP allow-list modifications.
- If the change is unauthorized, re-enable the 2FA requirement before continuing the investigation to limit exposure.

### False positive analysis

- A documented break-glass procedure during an identity-provider or 2FA outage may require temporarily disabling the requirement; this should be rare, ticketed, time-bounded, and followed by immediate re-enablement.
- A planned governance or migration change (for example, consolidating organizations or adjusting enrollment policy) performed by a known administrator can generate this event as expected activity.

### Response and remediation

- Re-enable the required 2FA setting for the affected organization or enterprise as soon as the change is confirmed unauthorized.
- Force sign-out of active sessions and audit the member list for accounts not enrolled in 2FA, requiring enrollment or suspending them.
- Rotate credentials and tokens created or used after the requirement was disabled, including PATs, OAuth app grants, and SSH keys.
- Review org and enterprise audit logs for other changes made by the actor after the disable event, and revert any unauthorized modifications.
- Escalate to incident response if the actor is unknown or unauthorized, or if the disable event is accompanied by new owner additions, token grants, or sign-ins from unfamiliar infrastructure.
- Harden by enforcing 2FA at the enterprise level, restricting who can change organization security settings, and alerting on future changes to the 2FA requirement.
"""
references = [
    "https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization",
    "https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise",
]
risk_score = 73
rule_id = "e148c3cc-89f7-4a0c-a2f9-2d8fbe23e443"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Platform: GitHub",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Defense Evasion",
    "Data Source: Github",
    "Data Source: GitHub Audit Logs",
    "Rule Type: ESQL",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-github.audit-* metadata _id, _index, _version
| where
  event.module == "github" and data_stream.dataset == "github.audit"
    and event.action in ("business.disable_two_factor_requirement", "org.disable_two_factor_requirement")
| keep
    _id,
    _index,
    _version,
    @timestamp,
    event.action,
    user.name,
    github.org,
    github.repo,
    github.actor_ip,
    github.hashed_token,
    github.programmatic_access_type,
    github.user_agent,
    github.business
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"


[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"
[[rule.threat.technique.subtechnique]]
id = "T1556.006"
name = "Multi-Factor Authentication"
reference = "https://attack.mitre.org/techniques/T1556/006/"


[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.action",
    "user.name",
    "github.org",
    "github.repo",
    "github.actor_ip",
    "github.hashed_token",
    "github.programmatic_access_type",
    "github.user_agent",
    "github.business",
]

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.