GitHub SAML SSO Disabled

Detects when SAML single sign-on (SSO) is disabled for a GitHub enterprise or organization. SAML SSO delegates authentication to an external identity provider (IdP) and lets administrators enforce IdP-side controls such as MFA, conditional access, and centralized deprovisioning. Disabling it removes those controls and allows members to authenticate with GitHub credentials alone. Following an account takeover, an adversary may disable SSO to evade IdP-enforced access policies and maintain access that survives IdP-side session revocation and deprovisioning, making this a high-impact identity-control change.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/11/02"
  3integration = ["github"]
  4maturity = "production"
  5updated_date = "2026/11/02"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects when SAML single sign-on (SSO) is disabled for a GitHub enterprise or organization. SAML SSO delegates
 11authentication to an external identity provider (IdP) and lets administrators enforce IdP-side controls such as MFA,
 12conditional access, and centralized deprovisioning. Disabling it removes those controls and allows members to
 13authenticate with GitHub credentials alone. Following an account takeover, an adversary may disable SSO to evade
 14IdP-enforced access policies and maintain access that survives IdP-side session revocation and deprovisioning, making
 15this a high-impact identity-control change.
 16"""
 17false_positives = [
 18    """
 19    Planned identity provider (IdP) migration or SAML reconfiguration performed during an approved change window.
 20    Confirm the change against a ticket, keep a second owner session active, and re-enable SSO as soon as the new
 21    provider is ready.
 22    """,
 23]
 24from = "now-9m"
 25language = "esql"
 26license = "Elastic License v2"
 27name = "GitHub SAML SSO Disabled"
 28note = """## Triage and analysis
 29
 30> **Disclaimer**:
 31> 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.
 32
 33### Investigating GitHub SAML SSO Disabled
 34
 35This rule triggers on `business.disable_saml` and `org.disable_saml`, which record the disabling of SAML single sign-on at the enterprise or organization level. SAML SSO delegates authentication to an external identity provider (IdP) and lets administrators enforce IdP-side controls such as MFA, conditional access, and centralized deprovisioning. Disabling it removes those controls and allows members to authenticate with GitHub credentials alone, which is a common defense-evasion and persistence step after an owner account is compromised: it severs IdP-enforced policy and keeps access alive even if the IdP later revokes sessions or deprovisions the user. These events only apply to enterprises/orgs that have SAML configured and will not fire on a personal-account GHEC trial without SSO.
 36
 37### Possible investigation steps
 38
 39- Identify the actor from `user.name`, `github.actor_ip`, `github.user_agent`, and `github.programmatic_access_type`, and confirm whether they legitimately hold enterprise or organization owner privileges.
 40- Determine the scope from `event.action` (`org.disable_saml` vs `business.disable_saml`) and the affected `github.org`/`github.business`, and verify whether the change was approved in an IdP-migration or SAML-reconfiguration change ticket.
 41- Pivot on `github.hashed_token` and `github.programmatic_access_type` to determine whether the change was made interactively in the UI or via a token, and treat token-driven changes as a stronger compromise signal.
 42- Check for correlated account-takeover indicators in the same window: recovery-code usage, new owner or member additions, PAT grants, OAuth App authorizations, 2FA requirement changes, and sign-ins from unusual IPs or ASNs.
 43- Review membership, access, and credential changes made while SSO was disabled, since members could authenticate without IdP enforcement during that period.
 44- If the change is unauthorized, re-enable SAML SSO before continuing the investigation to restore IdP-enforced access control.
 45
 46### False positive analysis
 47
 48- A planned IdP cutover or SAML provider reconfiguration performed within an approved change window; this should be ticketed, keep a second owner session active, and re-enable SSO as soon as the new provider is ready.
 49- A governance or migration change (for example, consolidating organizations under an enterprise) performed by a known administrator can generate this event as expected activity.
 50
 51### Response and remediation
 52
 53- Re-enable SAML SSO and require SSO for all members as soon as the change is confirmed unauthorized.
 54- Invalidate active sessions and force re-authentication through the IdP so that access is re-gated by IdP-enforced controls.
 55- Review and reverse any membership, access, or credential changes made while SSO was disabled, and revoke tokens created during that period.
 56- Review org and enterprise audit logs for other changes made by the actor after the disable event, and revert any unauthorized modifications.
 57- Escalate to incident response if the actor is unknown or unauthorized, or if the disable event is accompanied by new owner additions, token grants, recovery-code usage, or sign-ins from unfamiliar infrastructure.
 58- Harden by requiring SSO for all members, restricting who can change enterprise/organization authentication settings, and alerting on future changes to the SAML configuration.
 59"""
 60references = [
 61    "https://docs.github.com/en/enterprise-cloud@latest/admin/identity-and-access-management/using-saml-for-enterprise-iam/configuring-saml-single-sign-on-for-your-enterprise",
 62]
 63risk_score = 73
 64rule_id = "b60d3944-7ef3-4267-9a18-2f1114b066cb"
 65severity = "high"
 66tags = [
 67    "Domain: Cloud",
 68    "Domain: SaaS",
 69    "Platform: GitHub",
 70    "Use Case: Threat Detection",
 71    "Tactic: Credential Access",
 72    "Tactic: Defense Evasion",
 73    "Tactic: Persistence",
 74    "Data Source: Github",
 75    "Data Source: GitHub Audit Logs",
 76    "Rule Type: ES|QL",
 77    "Resources: Investigation Guide",
 78]
 79timestamp_override = "event.ingested"
 80type = "esql"
 81
 82query = '''
 83from logs-github.audit-* metadata _id, _index, _version
 84| where
 85  event.module == "github" and data_stream.dataset == "github.audit"
 86    and event.action in ("business.disable_saml", "org.disable_saml")
 87| keep
 88    _id,
 89    _index,
 90    _version,
 91    @timestamp,
 92    event.action,
 93    user.name,
 94    github.org,
 95    github.repo,
 96    github.actor_ip,
 97    github.hashed_token,
 98    github.programmatic_access_type,
 99    github.user_agent,
100    github.business
101'''
102
103
104[[rule.threat]]
105framework = "MITRE ATT&CK"
106[[rule.threat.technique]]
107id = "T1562"
108name = "Impair Defenses"
109reference = "https://attack.mitre.org/techniques/T1562/"
110
111
112[rule.threat.tactic]
113id = "TA0005"
114name = "Defense Evasion"
115reference = "https://attack.mitre.org/tactics/TA0005/"
116[[rule.threat]]
117framework = "MITRE ATT&CK"
118[[rule.threat.technique]]
119id = "T1556"
120name = "Modify Authentication Process"
121reference = "https://attack.mitre.org/techniques/T1556/"
122[[rule.threat.technique.subtechnique]]
123id = "T1556.007"
124name = "Hybrid Identity"
125reference = "https://attack.mitre.org/techniques/T1556/007/"
126
127
128[rule.threat.tactic]
129id = "TA0006"
130name = "Credential Access"
131reference = "https://attack.mitre.org/tactics/TA0006/"
132[[rule.threat]]
133framework = "MITRE ATT&CK"
134[[rule.threat.technique]]
135id = "T1556"
136name = "Modify Authentication Process"
137reference = "https://attack.mitre.org/techniques/T1556/"
138[[rule.threat.technique.subtechnique]]
139id = "T1556.007"
140name = "Hybrid Identity"
141reference = "https://attack.mitre.org/techniques/T1556/007/"
142
143
144[rule.threat.tactic]
145id = "TA0003"
146name = "Persistence"
147reference = "https://attack.mitre.org/tactics/TA0003/"
148
149[rule.investigation_fields]
150field_names = [
151    "@timestamp",
152    "event.action",
153    "user.name",
154    "github.org",
155    "github.repo",
156    "github.actor_ip",
157    "github.hashed_token",
158    "github.programmatic_access_type",
159    "github.user_agent",
160    "github.business",
161]

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 SAML SSO Disabled

This rule triggers on business.disable_saml and org.disable_saml, which record the disabling of SAML single sign-on at the enterprise or organization level. SAML SSO delegates authentication to an external identity provider (IdP) and lets administrators enforce IdP-side controls such as MFA, conditional access, and centralized deprovisioning. Disabling it removes those controls and allows members to authenticate with GitHub credentials alone, which is a common defense-evasion and persistence step after an owner account is compromised: it severs IdP-enforced policy and keeps access alive even if the IdP later revokes sessions or deprovisions the user. These events only apply to enterprises/orgs that have SAML configured and will not fire on a personal-account GHEC trial without SSO.

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 enterprise or organization owner privileges.
  • Determine the scope from event.action (org.disable_saml vs business.disable_saml) and the affected github.org/github.business, and verify whether the change was approved in an IdP-migration or SAML-reconfiguration change ticket.
  • Pivot on github.hashed_token and github.programmatic_access_type to determine whether the change was made interactively in the UI or via a token, and treat token-driven changes as a stronger compromise signal.
  • Check for correlated account-takeover indicators in the same window: recovery-code usage, new owner or member additions, PAT grants, OAuth App authorizations, 2FA requirement changes, and sign-ins from unusual IPs or ASNs.
  • Review membership, access, and credential changes made while SSO was disabled, since members could authenticate without IdP enforcement during that period.
  • If the change is unauthorized, re-enable SAML SSO before continuing the investigation to restore IdP-enforced access control.

False positive analysis

  • A planned IdP cutover or SAML provider reconfiguration performed within an approved change window; this should be ticketed, keep a second owner session active, and re-enable SSO as soon as the new provider is ready.
  • A governance or migration change (for example, consolidating organizations under an enterprise) performed by a known administrator can generate this event as expected activity.

Response and remediation

  • Re-enable SAML SSO and require SSO for all members as soon as the change is confirmed unauthorized.
  • Invalidate active sessions and force re-authentication through the IdP so that access is re-gated by IdP-enforced controls.
  • Review and reverse any membership, access, or credential changes made while SSO was disabled, and revoke tokens created during that period.
  • 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, recovery-code usage, or sign-ins from unfamiliar infrastructure.
  • Harden by requiring SSO for all members, restricting who can change enterprise/organization authentication settings, and alerting on future changes to the SAML configuration.

References

Related rules

to-top