diff --git a/rules/integrations/freeipa/collection_freeipa_ldap_mass_data_exfiltration.toml b/rules/integrations/freeipa/collection_freeipa_ldap_mass_data_exfiltration.toml new file mode 100644 index 00000000000..4570ba5c1fc --- /dev/null +++ b/rules/integrations/freeipa/collection_freeipa_ldap_mass_data_exfiltration.toml @@ -0,0 +1,104 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies LDAP search operations against the FreeIPA 389 Directory Server that return an unusually large number of +entries in a single query. Large result sets from subtree searches against the domain base DN indicate bulk directory +data exfiltration. SSSD clients typically perform targeted searches returning small result sets. +""" +false_positives = [ + """ + Legitimate LDAP replication, backup tools, or directory synchronization agents may perform large queries. + Exclude known replication manager DNs and backup service IPs. SSSD clients performing group cache refreshes + may return moderately large result sets but typically stay well below 500 entries per query. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA LDAP Mass Data Exfiltration" +note = """## Triage and analysis + +### Investigating FreeIPA LDAP Mass Data Exfiltration + +Large LDAP searches against FreeIPA can expose user details, group memberships, SSH public keys, sudo rules, HBAC policies, and other sensitive directory data. An attacker with authenticated LDAP access can dump the entire directory for offline analysis. + +### Possible investigation steps + +- Check `freeipa.directory.bind_dn` to identify the account performing the search. +- Review `freeipa.directory.base_dn`, `freeipa.directory.scope`, and `freeipa.directory.filter` to understand what was queried. +- Check `freeipa.directory.entries_returned` to quantify the exposure. +- Correlate with `source.ip` to identify the origin. +- Determine if the bind DN is a legitimate service account, replication manager, or a compromised user. + +### Response and remediation + +- Block the source IP if unauthorized. +- Reset credentials for the bind DN if compromised. +- Review LDAP ACIs to restrict the maximum entries returned per query. +- Implement `nsslapd-sizelimit` to cap LDAP result sizes for non-admin users. +""" +references = [ + "https://attack.mitre.org/techniques/T1213/", + "https://specterops.io/blog/2019/12/04/attacking-freeipa-part-ii-enumeration/", +] +risk_score = 47 +rule_id = "f8a1b2c3-4d5e-6f7a-8b9c-0d1e2f3a4b5c" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - 389DS access: `/var/log/dirsrv/slapd-*/access` (directory_access data stream) +""" +severity = "medium" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA Directory Server", + "Use Case: Threat Detection", + "Tactic: Collection", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.directory_access-* +| where freeipa.directory.operation == "RESULT" + and freeipa.directory.entries_returned >= 500 +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1213" +name = "Data from Information Repositories" +reference = "https://attack.mitre.org/techniques/T1213/" + + +[rule.threat.tactic] +id = "TA0009" +name = "Collection" +reference = "https://attack.mitre.org/tactics/TA0009/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "freeipa.directory.bind_dn", + "freeipa.directory.base_dn", + "freeipa.directory.scope", + "freeipa.directory.filter", + "freeipa.directory.entries_returned", +] diff --git a/rules/integrations/freeipa/credential_access_freeipa_api_password_reset.toml b/rules/integrations/freeipa/credential_access_freeipa_api_password_reset.toml new file mode 100644 index 00000000000..e82742489b0 --- /dev/null +++ b/rules/integrations/freeipa/credential_access_freeipa_api_password_reset.toml @@ -0,0 +1,105 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies a FreeIPA API password reset command (passwd) executed by a principal that is not the target user. An +adversary who has compromised an account with password reset privileges can use this to take over other accounts +without knowing their current password. Self-service password changes are expected and excluded. +""" +false_positives = [ + """ + Helpdesk staff or administrators performing authorized password resets will trigger this rule. Exclude known + admin principals if they routinely perform password resets. Automated password rotation systems that use a + service account to reset passwords may also trigger this rule. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA Password Reset by Another User" +note = """## Triage and analysis + +### Investigating FreeIPA Password Reset by Another User + +FreeIPA's `passwd` API command allows privileged users to reset another user's password. While this is a legitimate helpdesk operation, it is also a common post-compromise action — an attacker with admin or helpdesk privileges can reset target account passwords to gain access. + +### Possible investigation steps + +- Identify the actor by examining `user.name` and `user.id` — this is the principal who performed the reset. +- Identify the target account from `freeipa.api.parameters` — this is the account whose password was changed. +- Verify the reset was authorized through a ticket system or change management workflow. +- Check `source.ip` to determine where the reset originated. +- Review the actor's recent API activity for other suspicious commands (role changes, group modifications). +- Check if the target account had subsequent authentication activity from a new or suspicious source. + +### Response and remediation + +- If unauthorized, immediately reset the target account's password again and revoke all active sessions. +- Investigate the actor's account for compromise — reset their credentials and review their permissions. +- Review who has password reset privileges and apply least privilege principles. +- Consider requiring OTP/2FA for password reset operations. +""" +references = [ + "https://attack.mitre.org/techniques/T1098/", + "https://www.freeipa.org/page/V4/OTP", +] +risk_score = 73 +rule_id = "5a2c9b06-b1b2-4552-9b82-19646a8bc3ad" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - IPA API: `/var/log/httpd/error_log` (ipa_api data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA API", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.ipa_api-* +| where event.action == "passwd" and event.outcome == "success" +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1098" +name = "Account Manipulation" +reference = "https://attack.mitre.org/techniques/T1098/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "user.id", + "source.ip", + "event.action", + "event.outcome", + "freeipa.api.parameters", +] diff --git a/rules/integrations/freeipa/credential_access_freeipa_kerberos_brute_force.toml b/rules/integrations/freeipa/credential_access_freeipa_kerberos_brute_force.toml new file mode 100644 index 00000000000..e83340c5604 --- /dev/null +++ b/rules/integrations/freeipa/credential_access_freeipa_kerberos_brute_force.toml @@ -0,0 +1,116 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies a high number of Kerberos pre-authentication failures for a single principal from a single source IP, +indicative of a password guessing attack against a FreeIPA KDC. Adversaries may attempt to brute-force Kerberos +credentials to gain initial access to the domain. The default threshold of 25 failures in 5 minutes should be tuned +to match the target environment's normal authentication patterns and lockout policy. +""" +false_positives = [ + """ + Misconfigured clients or services with expired credentials may generate repeated pre-authentication failures. + Tune the threshold to match the environment's account lockout policy. Exclude known service accounts or + monitoring systems that perform frequent authentication checks. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA Kerberos Brute Force Attempt" +note = """## Triage and analysis + +### Investigating FreeIPA Kerberos Brute Force Attempt + +FreeIPA uses MIT Kerberos for authentication. When a user provides incorrect credentials, the KDC responds with a PREAUTH_FAILED error. A high volume of these errors for a single principal indicates a password guessing attack. This rule uses a threshold that should be tuned to the environment — review the domain's password lockout policy and set the threshold below the lockout limit to catch attacks before lockout occurs. + +### Possible investigation steps + +- Identify the targeted principal from `freeipa.kdc.client_principal` and determine if it is a high-value account (admin, service account, etc.). +- Check `source.ip` and `source.geo` to determine the origin of the attack. External IPs are higher risk. +- Query for any successful authentication (`event.outcome:success`) for the same principal around the same time window to check if the brute force succeeded. +- Check if the account was locked out by looking for `freeipa.kdc.error_code:LOCKED_OUT` events for the same principal. +- Correlate with the `directory_access` data stream for LDAP bind failures from the same `source.ip`. +- Review whether other principals were also targeted from the same source (indicating password spraying rather than targeted brute force). + +### Response and remediation + +- If the source is external, block the IP at the firewall or network perimeter. +- If the account was compromised (successful auth observed), reset the password immediately and revoke active Kerberos tickets. +- Review and enforce account lockout policies via `ipa pwpolicy-mod`. +- Consider enabling FreeIPA OTP/2FA for targeted high-value accounts. +- Monitor for follow-up activity from the source IP across all data streams. +""" +references = [ + "https://attack.mitre.org/techniques/T1110/001/", + "https://specterops.io/blog/2019/11/25/attacking-freeipa-part-i-authentication/", + "https://book.hacktricks.xyz/linux-hardening/freeipa-pentesting", +] +risk_score = 73 +rule_id = "814d541d-24fd-464f-b6a4-38988a18ba55" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - KDC: `/var/log/krb5kdc.log` (kdc data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA KDC", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.kdc-* +| where event.outcome == "failure" + and freeipa.kdc.client_principal not like "*/*" +| stats Esql.failure_count = count(*) by freeipa.kdc.client_principal, source.ip +| where Esql.failure_count >= 25 +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1110" +name = "Brute Force" +reference = "https://attack.mitre.org/techniques/T1110/" +[[rule.threat.technique.subtechnique]] +id = "T1110.001" +name = "Password Guessing" +reference = "https://attack.mitre.org/techniques/T1110/001/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "source.geo.country_name", + "freeipa.kdc.client_principal", + "freeipa.kdc.error_code", + "freeipa.kdc.request_type", + "event.outcome", + "Esql.failure_count", +] diff --git a/rules/integrations/freeipa/credential_access_freeipa_kerberos_password_spraying.toml b/rules/integrations/freeipa/credential_access_freeipa_kerberos_password_spraying.toml new file mode 100644 index 00000000000..24551d48f46 --- /dev/null +++ b/rules/integrations/freeipa/credential_access_freeipa_kerberos_password_spraying.toml @@ -0,0 +1,115 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies Kerberos pre-authentication failures across many distinct principals from a single source IP, indicative of +a password spraying attack against a FreeIPA KDC. Adversaries use password spraying to test common passwords across +many accounts while staying below per-account lockout thresholds. The default threshold of 15 unique principals in 5 +minutes should be tuned to the environment's size and authentication patterns. +""" +false_positives = [ + """ + Jump hosts or bastion servers that authenticate on behalf of many users may trigger this rule. Exclude known + bastion or proxy IPs. Automated provisioning systems that validate credentials for many accounts in batch may + also cause false positives. Tune the cardinality threshold based on the environment. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA Kerberos Password Spraying Attempt" +note = """## Triage and analysis + +### Investigating FreeIPA Kerberos Password Spraying Attempt + +Password spraying targets many accounts with a small set of commonly used passwords, staying below per-account lockout thresholds. This rule detects a single source IP generating pre-authentication failures for many distinct Kerberos principals. The cardinality threshold should be tuned — small environments with few users need a lower threshold, while large environments may need a higher one. + +### Possible investigation steps + +- Review the `source.ip` and `source.geo` fields to determine the origin. External IPs are high risk. +- List all targeted principals by querying `freeipa.kdc.error_code:PREAUTH_FAILED AND source.ip:` in the same time window. +- Check if any of the targeted principals had a successful authentication (`event.outcome:success`) shortly after the spray — this indicates a compromised account. +- Look for `LOCKED_OUT` events to assess the blast radius of the attack. +- Correlate with LDAP bind failures in the `directory_access` data stream from the same source. +- Check the `freeipa.kdc.request_type` field — AS_REQ spraying is initial access; TGS_REQ spraying against service principals suggests kerberoasting. + +### Response and remediation + +- Block the source IP at the network perimeter. +- Force password resets for any accounts that had successful authentications from the attacking source. +- Review password policy strength via `ipa pwpolicy-show` and consider increasing minimum length or complexity. +- Enable OTP/2FA for admin and service accounts. +- Review account lockout policy settings to ensure they are appropriate. +""" +references = [ + "https://attack.mitre.org/techniques/T1110/003/", + "https://specterops.io/blog/2019/11/25/attacking-freeipa-part-i-authentication/", +] +risk_score = 73 +rule_id = "56ab69e7-29cf-4e84-88bd-23ed7d826544" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - KDC: `/var/log/krb5kdc.log` (kdc data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA KDC", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.kdc-* +| where event.outcome == "failure" and freeipa.kdc.error_code == "PREAUTH_FAILED" +| stats Esql.failure_count = count(*), Esql.unique_principals = count_distinct(freeipa.kdc.client_principal) by source.ip +| where Esql.failure_count >= 10 and Esql.unique_principals >= 15 +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1110" +name = "Brute Force" +reference = "https://attack.mitre.org/techniques/T1110/" +[[rule.threat.technique.subtechnique]] +id = "T1110.003" +name = "Password Spraying" +reference = "https://attack.mitre.org/techniques/T1110/003/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "source.geo.country_name", + "freeipa.kdc.client_principal", + "freeipa.kdc.error_code", + "freeipa.kdc.request_type", + "event.outcome", + "Esql.failure_count", + "Esql.unique_principals", +] diff --git a/rules/integrations/freeipa/credential_access_freeipa_ldap_brute_force.toml b/rules/integrations/freeipa/credential_access_freeipa_ldap_brute_force.toml new file mode 100644 index 00000000000..747d21c0087 --- /dev/null +++ b/rules/integrations/freeipa/credential_access_freeipa_ldap_brute_force.toml @@ -0,0 +1,114 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies a high number of LDAP simple bind failures from a single source IP against the FreeIPA 389 Directory Server, +indicative of a credential stuffing or brute force attack over LDAP. LDAP simple binds transmit credentials in +cleartext (unless protected by TLS) and are less common than SASL/GSSAPI in properly configured FreeIPA environments. +The default threshold of 20 failures in 5 minutes should be tuned to the environment. +""" +false_positives = [ + """ + Legacy applications using LDAP simple bind with misconfigured or expired credentials may generate repeated + failures. Exclude known application service IPs. SSSD clients use SASL/GSSAPI by default and should not + trigger this rule. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA LDAP Bind Brute Force Attempt" +note = """## Triage and analysis + +### Investigating FreeIPA LDAP Bind Brute Force Attempt + +FreeIPA's 389 Directory Server supports LDAP BIND operations for authentication. Simple binds send credentials directly, while SASL/GSSAPI uses Kerberos. A high volume of simple bind failures from one source indicates credential guessing. Simple bind is less common in healthy FreeIPA environments since SSSD uses GSSAPI, so any significant volume of simple bind failures warrants investigation. + +### Possible investigation steps + +- Review the `source.ip` to determine if the source is internal or external. +- Check `freeipa.directory.bind_dn` to identify which accounts are being targeted. +- Look at `freeipa.directory.ssl` to determine if the binds are encrypted (TLS) or cleartext. +- Query for successful BIND results (`freeipa.directory.result_code:0`) from the same source to check if any credentials were guessed correctly. +- Correlate with the `kdc` data stream for Kerberos authentication failures from the same source. +- Check if the source IP appears in other data streams (ipa_api, ca_audit) for post-exploitation activity. + +### Response and remediation + +- Block the source IP at the network perimeter. +- If any binds succeeded, reset passwords for those accounts immediately. +- Restrict LDAP simple bind to TLS-only connections or disable it entirely in favour of SASL/GSSAPI. +- Review 389DS access control to restrict bind operations from untrusted networks. +""" +references = [ + "https://attack.mitre.org/techniques/T1110/001/", + "https://specterops.io/blog/2019/11/25/attacking-freeipa-part-i-authentication/", +] +risk_score = 73 +rule_id = "a217ee15-b11c-4529-bb46-1531a22846d6" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - 389DS access: `/var/log/dirsrv/slapd-*/access` (directory_access data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA Directory Server", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.directory_access-* +| where freeipa.directory.operation == "RESULT" + and freeipa.directory.tag_number == 97 + and freeipa.directory.result_code >= 1 +| stats Esql.failure_count = count(*) by source.ip +| where Esql.failure_count >= 20 +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1110" +name = "Brute Force" +reference = "https://attack.mitre.org/techniques/T1110/" +[[rule.threat.technique.subtechnique]] +id = "T1110.001" +name = "Password Guessing" +reference = "https://attack.mitre.org/techniques/T1110/001/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "freeipa.directory.bind_dn", + "freeipa.directory.bind_method", + "freeipa.directory.result_code", + "freeipa.directory.ssl", + "Esql.failure_count", +] diff --git a/rules/integrations/freeipa/credential_access_freeipa_ldap_credential_search.toml b/rules/integrations/freeipa/credential_access_freeipa_ldap_credential_search.toml new file mode 100644 index 00000000000..da504fa9034 --- /dev/null +++ b/rules/integrations/freeipa/credential_access_freeipa_ldap_credential_search.toml @@ -0,0 +1,119 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +min_stack_comments = "ES|QL LOOKUP JOIN requires 8.19+ for GA support with lookup-mode indices." +min_stack_version = "8.19.0" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Detects LDAP searches for credential attributes (userPassword, krbPrincipalKey, ipaNTHash, krbMKey) by non-internal +users. These attributes contain password hashes, Kerberos keys, and NT hashes that can be cracked offline. Uses +LOOKUP JOIN with the latest_bind transform to identify the authenticated identity and exclude internal FreeIPA +operations such as Directory Manager and Kerberos subsystem searches. +""" +false_positives = [ + """ + FreeIPA internal processes (ipa-kdb, certmonger) may search for credential attributes during normal operations. + These use bind DNs under cn=kerberos or cn=Directory Manager and are excluded. Custom LDAP scripts performing + password auditing may trigger this rule — add their bind DNs to the exclusion list. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA LDAP Credential Attribute Search by External User" +note = """## Triage and analysis + +### Investigating FreeIPA LDAP Credential Attribute Search by External User + +FreeIPA stores credential material in LDAP attributes that are normally ACL-protected. Searches explicitly requesting these attributes indicate an attempt to extract password hashes or Kerberos keys for offline cracking. Internal FreeIPA processes access these attributes routinely, but any external user or non-standard bind DN doing so is highly suspicious. + +### Possible investigation steps + +- Identify the authenticated user from `freeipa.directory.bind_dn` — this is the account performing the search. +- Check `freeipa.directory.filter` to understand exactly which credential attributes were requested. +- Review `source.ip` to determine where the search originated. +- Check if the bind DN has been compromised by reviewing recent authentication events for that principal. +- Look for follow-up activity indicating offline cracking succeeded — new authentications for the targeted accounts from unusual sources. + +### Response and remediation + +- Immediately reset the password for the bind DN performing the search. +- Rotate Kerberos keys for any principals whose krbPrincipalKey was exposed. +- Review LDAP ACIs to ensure credential attributes are not readable by non-admin users. +- Block the source IP if external or unauthorized. +- Consider enabling audit logging for sensitive attribute access in 389 DS. +""" +references = [ + "https://attack.mitre.org/techniques/T1552/001/", + "https://specterops.io/blog/2019/12/04/attacking-freeipa-part-ii-enumeration/", +] +risk_score = 99 +rule_id = "fb49e9de-f62b-41ad-9a37-40fed994c491" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - 389DS access: `/var/log/dirsrv/slapd-*/access` (directory_access data stream) + +This rule requires the `latest_bind` transform to be running. Verify the transform is running: `GET _transform/logs-freeipa-latest-bind/_stats`. The destination index must use `index.mode: lookup`. See the integration README for setup instructions. +""" +severity = "critical" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA Directory Server", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.directory_access-* +| where freeipa.directory.operation == "SRCH" + and freeipa.directory.scope == "sub" + and freeipa.directory.filter == "(userPassword=*)" +| LOOKUP JOIN freeipa-lookup-bind ON freeipa.directory.connection_id + | KEEP @timestamp, freeipa.*, source.ip, user.*, observer.*, host.name, event.action, event.outcome, event.kind, event.category, event.type, event.module +| where not freeipa.directory.bind_dn in ("cn=Directory Manager", "cn=directory manager") + and not freeipa.directory.bind_dn like "*cn=kerberos,*" +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1552" +name = "Unsecured Credentials" +reference = "https://attack.mitre.org/techniques/T1552/" +[[rule.threat.technique.subtechnique]] +id = "T1552.001" +name = "Credentials In Files" +reference = "https://attack.mitre.org/techniques/T1552/001/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "freeipa.directory.bind_dn", + "freeipa.directory.connection_id", + "freeipa.directory.filter", + "freeipa.directory.base_dn", + "freeipa.directory.scope", +] diff --git a/rules/integrations/freeipa/credential_access_freeipa_new_s4u2proxy_delegation.toml b/rules/integrations/freeipa/credential_access_freeipa_new_s4u2proxy_delegation.toml new file mode 100644 index 00000000000..b2919760d76 --- /dev/null +++ b/rules/integrations/freeipa/credential_access_freeipa_new_s4u2proxy_delegation.toml @@ -0,0 +1,115 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Detects the first time a constrained delegation (S4U2Proxy) is used to impersonate a particular client for a +particular service. New delegation relationships that haven't been seen in the past 14 days may indicate abuse of +delegation privileges. Constrained delegation allows a service to request tickets on behalf of a user, and +unauthorized new delegation pairs can enable lateral movement and privilege escalation. +""" +false_positives = [ + """ + Legitimate constrained delegation occurs in environments using web applications with Kerberos SSO (e.g., HTTP + services delegating to LDAP or CIFS). New delegation pairs may appear when new services are deployed or when + users access delegated services for the first time. Review the service principal's delegation configuration. + """, +] +from = "now-9m" +index = ["logs-freeipa.kdc-*"] +language = "kuery" +license = "Elastic License v2" +name = "FreeIPA New Constrained Delegation (S4U2Proxy) for Client" +note = """## Triage and analysis + +### Investigating FreeIPA New Constrained Delegation (S4U2Proxy) for Client + +Constrained delegation (S4U2Proxy) allows a service principal to request Kerberos tickets on behalf of a user for specific target services. This is configured via msDS-AllowedToDelegateTo or its FreeIPA equivalent. If an attacker gains control of a service principal with delegation privileges, they can impersonate any user to the allowed target services. A new client-service delegation pair that hasn't been seen before may indicate abuse. + +### Possible investigation steps + +- Identify the impersonated client from `freeipa.kdc.s4u_client` and the target service from `freeipa.kdc.service_principal`. +- Verify the service principal's delegation configuration matches the observed delegation pair. +- Check if the s4u_client is a high-value target (admin, service account with elevated privileges). +- Review who modified the service principal's delegation settings recently via IPA API events. +- Correlate with other activity from the service principal's host to determine if it has been compromised. + +### Response and remediation + +- If unauthorized, remove the delegation privilege from the service principal using `ipa service-mod`. +- Revoke active tickets for both the service principal and the impersonated client. +- Investigate the service principal's host for signs of compromise. +- Review all constrained delegation configurations in the domain with `ipa service-find --with-delegation`. +""" +references = [ + "https://attack.mitre.org/techniques/T1550/003/", + "https://www.thehacker.recipes/ad/movement/kerberos/delegations/constrained", +] +risk_score = 73 +rule_id = "27304633-f55a-42dc-92bb-05aba996bfe7" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - KDC: `/var/log/krb5kdc.log` (kdc data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA KDC", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "new_terms" + +query = ''' +event.dataset: "freeipa.kdc" and freeipa.kdc.s4u_client: * +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1550" +name = "Use Alternate Authentication Material" +reference = "https://attack.mitre.org/techniques/T1550/" +[[rule.threat.technique.subtechnique]] +id = "T1550.003" +name = "Pass the Ticket" +reference = "https://attack.mitre.org/techniques/T1550/003/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "freeipa.kdc.s4u_client", + "freeipa.kdc.service_principal", + "freeipa.kdc.client_principal", + "freeipa.kdc.request_type", + "event.outcome", +] + +[rule.new_terms] +field = "new_terms_fields" +value = ["freeipa.kdc.s4u_client", "freeipa.kdc.service_principal"] + +[[rule.new_terms.history_window_start]] +field = "history_window_start" +value = "now-14d" diff --git a/rules/integrations/freeipa/credential_access_freeipa_slow_brute_force.toml b/rules/integrations/freeipa/credential_access_freeipa_slow_brute_force.toml new file mode 100644 index 00000000000..c85b1549673 --- /dev/null +++ b/rules/integrations/freeipa/credential_access_freeipa_slow_brute_force.toml @@ -0,0 +1,115 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Detects a high number of Kerberos authentication failures for a single principal from a single source IP over a +24-hour period. This catches patient brute force attacks that stay below the per-interval threshold of the standard +brute force rule by spreading attempts across hours. The 24-hour bucket aggregation reveals slow-and-low credential +guessing that would otherwise evade shorter detection windows. +""" +false_positives = [ + """ + A misconfigured service with an expired or incorrect keytab may generate sustained low-rate authentication + failures over 24 hours. Identify and fix the misconfigured service or exclude its source IP and principal. + """, +] +from = "now-25h" +interval = "1h" +language = "kuery" +license = "Elastic License v2" +name = "FreeIPA Slow Kerberos Brute Force Over 24 Hours" +note = """## Triage and analysis + +### Investigating FreeIPA Slow Kerberos Brute Force Over 24 Hours + +Sophisticated attackers spread brute force attempts over long periods to avoid detection by short-window threshold rules. By aggregating failures into 24-hour buckets, this rule catches patient attacks that generate fewer than 25 failures per 5-minute window but accumulate significantly over a day. This is a common technique to stay below account lockout thresholds. + +### Possible investigation steps + +- Identify the targeted principal from `freeipa.kdc.client_principal` and determine its value (admin, service account, regular user). +- Check `source.ip` and `source.geo` for the origin. External sources are high risk. +- Review the distribution of failures over the 24-hour period — evenly spread failures suggest automated tooling, while clustered failures suggest manual attempts. +- Check if any successful authentication occurred for the same principal from the same source, indicating the brute force may have succeeded. +- Compare with the standard brute force rule to confirm this was below the short-window threshold. + +### Response and remediation + +- Block the source IP at the network perimeter. +- Reset the targeted principal's password if there is any chance of compromise. +- Review and lower account lockout thresholds if the current policy allows too many attempts. +- Enable FreeIPA OTP/2FA for the targeted account if it is high-value. +- Monitor for follow-up activity from the source IP. +""" +references = [ + "https://attack.mitre.org/techniques/T1110/001/", + "https://specterops.io/blog/2019/11/25/attacking-freeipa-part-i-authentication/", +] +risk_score = 73 +rule_id = "449a8017-a606-4c89-a678-c4369c218a02" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - KDC: `/var/log/krb5kdc.log` (kdc data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA KDC", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +index = ["logs-freeipa.kdc-*"] +type = "threshold" + +query = ''' +event.dataset: "freeipa.kdc" and event.outcome: "failure" +''' + + + +[rule.threshold] +field = ["freeipa.kdc.client_principal", "source.ip"] +value = 50 + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1110" +name = "Brute Force" +reference = "https://attack.mitre.org/techniques/T1110/" +[[rule.threat.technique.subtechnique]] +id = "T1110.001" +name = "Password Guessing" +reference = "https://attack.mitre.org/techniques/T1110/001/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "source.geo.country_name", + "freeipa.kdc.client_principal", + "freeipa.kdc.error_code", + "event.outcome", + "Esql.failure_count", + "day_bucket", +] diff --git a/rules/integrations/freeipa/credential_access_freeipa_slow_password_spray.toml b/rules/integrations/freeipa/credential_access_freeipa_slow_password_spray.toml new file mode 100644 index 00000000000..d150816bfb1 --- /dev/null +++ b/rules/integrations/freeipa/credential_access_freeipa_slow_password_spray.toml @@ -0,0 +1,120 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Detects a high number of Kerberos authentication failures across many distinct principals from a single source IP +over a 24-hour period. This catches patient password spraying that stays below the per-interval threshold by +distributing attempts across hours. The combination of high failure count and high principal diversity from one +source is a strong indicator of spray activity. +""" +false_positives = [ + """ + A NAT gateway or proxy aggregating authentication from many users may appear as a single source IP with + failures across multiple principals. Exclude known NAT/proxy IPs or increase the unique principal threshold + to account for the expected user population behind the gateway. + """, +] +from = "now-25h" +interval = "1h" +language = "kuery" +license = "Elastic License v2" +name = "FreeIPA Slow Password Spray Over 24 Hours" +note = """## Triage and analysis + +### Investigating FreeIPA Slow Password Spray Over 24 Hours + +Password spraying tries a small number of common passwords against many accounts to avoid lockout. Sophisticated attackers spread spray attempts over 24 hours, staying below short-window detection thresholds. This rule aggregates by day to catch the cumulative pattern — a single source IP generating failures across 10 or more distinct principals with at least 50 total failures. + +### Possible investigation steps + +- Check `source.ip` and `source.geo` to determine the origin. External sources are high risk. +- Review `Esql.unique_principals` to understand the breadth of the spray. +- Examine the individual `freeipa.kdc.client_principal` values to determine if specific account types were targeted (admins, service accounts, specific naming patterns). +- Check for any successful authentications from the same source IP during the same period — a success amid many failures strongly suggests the spray found a valid credential. +- Correlate with the standard password spraying rule to confirm this was below the short-window threshold. + +### Response and remediation + +- Block the source IP at the network perimeter immediately. +- Force password resets for any principals that had successful authentications from the source IP during the spray window. +- Review password policy complexity requirements via `ipa pwpolicy-show`. +- Enable FreeIPA OTP/2FA for high-value accounts. +- Monitor for follow-up lateral movement from any successfully compromised accounts. +""" +references = [ + "https://attack.mitre.org/techniques/T1110/003/", + "https://specterops.io/blog/2019/11/25/attacking-freeipa-part-i-authentication/", +] +risk_score = 73 +rule_id = "eec14b69-b4dd-4a35-bae5-83b2bf6fe303" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - KDC: `/var/log/krb5kdc.log` (kdc data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA KDC", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +index = ["logs-freeipa.kdc-*"] +type = "threshold" + +query = ''' +event.dataset: "freeipa.kdc" and event.outcome: "failure" +''' + + + +[rule.threshold] +field = ["source.ip"] +value = 50 +[[rule.threshold.cardinality]] +field = "freeipa.kdc.client_principal" +value = 10 + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1110" +name = "Brute Force" +reference = "https://attack.mitre.org/techniques/T1110/" +[[rule.threat.technique.subtechnique]] +id = "T1110.003" +name = "Password Spraying" +reference = "https://attack.mitre.org/techniques/T1110/003/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "source.geo.country_name", + "freeipa.kdc.client_principal", + "freeipa.kdc.error_code", + "event.outcome", + "Esql.failure_count", + "Esql.unique_principals", + "day_bucket", +] diff --git a/rules/integrations/freeipa/defense_evasion_freeipa_bulk_cert_revocation.toml b/rules/integrations/freeipa/defense_evasion_freeipa_bulk_cert_revocation.toml new file mode 100644 index 00000000000..1ec68c734b0 --- /dev/null +++ b/rules/integrations/freeipa/defense_evasion_freeipa_bulk_cert_revocation.toml @@ -0,0 +1,107 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies multiple certificate revocation events from the FreeIPA Dogtag CA in a short time window. Bulk certificate +revocation may indicate an adversary covering their tracks after certificate theft, sabotaging service authentication, +or causing a denial of service against certificate-dependent services. +""" +false_positives = [ + """ + Planned certificate rotation that involves revoking old certificates in bulk may trigger this rule. CA + administrators decommissioning hosts may also revoke multiple certificates. Verify against a change management + record. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA Bulk Certificate Revocation" +note = """## Triage and analysis + +### Investigating FreeIPA Bulk Certificate Revocation + +Certificate revocation in FreeIPA is normally a rare, individual operation. Multiple revocations in a short window may indicate sabotage (breaking service-to-service authentication), covering tracks after certificate theft, or a compromised CA admin account. + +### Possible investigation steps + +- Identify the actor from `user.id` and verify they are a CA administrator. +- Review `freeipa.ca.serial_number` and `freeipa.ca.subject_dn` for the revoked certificates to understand the impact. +- Check `freeipa.ca.revocation_reason` — unusual reasons like "Key Compromise" or "CA Compromise" indicate a declared incident. +- Look for preceding certificate request events that might indicate the adversary obtained certificates before revoking old ones. +- Check for service disruptions caused by the revocations. + +### Response and remediation + +- If unauthorized, reissue certificates for affected services immediately. +- Investigate the CA admin account for compromise. +- Review CA admin access controls and audit recent CA configuration changes. +- Consider implementing approval workflows for certificate revocation. +""" +references = [ + "https://attack.mitre.org/techniques/T1562/", +] +risk_score = 73 +rule_id = "5b728f48-7f4d-4ceb-ba7e-461c40fac410" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - Dogtag CA: `/var/log/pki/pki-tomcat/ca/signedAudit/ca_audit` (ca_audit data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA CA", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.ca_audit-* +| where freeipa.ca.event_type in ("CERT_STATUS_CHANGE_REQUEST_PROCESSED", "CERT_REVOKED") + and event.outcome == "success" +| stats Esql.revocation_count = count(*) by user.id +| where Esql.revocation_count >= 5 +''' + + +[[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.investigation_fields] +field_names = [ + "@timestamp", + "user.id", + "source.ip", + "freeipa.ca.event_type", + "freeipa.ca.serial_number", + "freeipa.ca.subject_dn", + "freeipa.ca.revocation_reason", + "event.outcome", + "Esql.revocation_count", +] diff --git a/rules/integrations/freeipa/defense_evasion_freeipa_ldap_config_modified.toml b/rules/integrations/freeipa/defense_evasion_freeipa_ldap_config_modified.toml new file mode 100644 index 00000000000..912a6fc7f1b --- /dev/null +++ b/rules/integrations/freeipa/defense_evasion_freeipa_ldap_config_modified.toml @@ -0,0 +1,114 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +min_stack_comments = "ES|QL LOOKUP JOIN requires 8.19+ for GA support with lookup-mode indices." +min_stack_version = "8.19.0" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Detects LDAP modifications to the 389 Directory Server configuration (cn=config). This includes changes to ACLs, +logging configuration, and security settings. An attacker with Directory Manager or equivalent access may modify +cn=config to disable audit logging, weaken ACLs, or alter security settings to facilitate further attacks. The +LOOKUP JOIN identifies who made the change. +""" +false_positives = [ + """ + FreeIPA installers and upgrade scripts modify cn=config during installation and patching. Legitimate administrators + may also tune performance settings or logging levels. Correlate with scheduled maintenance windows and verify + the bind DN is an authorized administrator. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA LDAP Server Configuration Modified" +note = """## Triage and analysis + +### Investigating FreeIPA LDAP Server Configuration Modified + +The 389 Directory Server cn=config subtree controls ACLs, logging, security parameters, and plugin configuration. Modifications to this subtree are rare in production and can have severe security implications — disabling access logging eliminates visibility, weakening ACLs grants unauthorized access, and modifying security settings can downgrade encryption. + +### Possible investigation steps + +- Identify the authenticated user from `freeipa.directory.bind_dn`. +- Review `freeipa.directory.target_dn` to determine which specific configuration entry was modified. +- Check 389 DS audit log (`/var/log/dirsrv/slapd-*/audit`) for the exact attribute changes if available. +- Determine if the change coincides with a scheduled maintenance window or FreeIPA upgrade. +- Review subsequent directory activity for signs of exploitation — new binds with elevated privileges, disabled logging, or ACL bypass. + +### Response and remediation + +- If unauthorized, revert the configuration change immediately. +- If logging was disabled, re-enable it and investigate what occurred during the gap. +- Reset credentials for the bind DN if compromised. +- Review who has modify access to cn=config and restrict it to the minimum necessary accounts. +""" +references = [ + "https://attack.mitre.org/techniques/T1562/002/", + "https://www.port389.org/docs/389ds/design/logging.html", +] +risk_score = 73 +rule_id = "888a3074-6eba-4d40-bd43-13eb8ddc9deb" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - 389DS access: `/var/log/dirsrv/slapd-*/access` (directory_access data stream) + +This rule requires the `latest_bind` transform to be running. Verify the transform is running: `GET _transform/logs-freeipa-latest-bind/_stats`. The destination index must use `index.mode: lookup`. See the integration README for setup instructions. +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA Directory Server", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.directory_access-* +| where freeipa.directory.operation == "MOD" + and freeipa.directory.target_dn like "*cn=config*" +| LOOKUP JOIN freeipa-lookup-bind ON freeipa.directory.connection_id + | KEEP @timestamp, freeipa.*, source.ip, user.*, observer.*, host.name, event.action, event.outcome, event.kind, event.category, event.type, event.module +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1562" +name = "Impair Defenses" +reference = "https://attack.mitre.org/techniques/T1562/" +[[rule.threat.technique.subtechnique]] +id = "T1562.002" +name = "Disable Windows Event Logging" +reference = "https://attack.mitre.org/techniques/T1562/002/" + + +[rule.threat.tactic] +id = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "freeipa.directory.bind_dn", + "freeipa.directory.connection_id", + "freeipa.directory.operation", + "freeipa.directory.target_dn", +] diff --git a/rules/integrations/freeipa/defense_evasion_freeipa_trust_modification.toml b/rules/integrations/freeipa/defense_evasion_freeipa_trust_modification.toml new file mode 100644 index 00000000000..f2903b028a5 --- /dev/null +++ b/rules/integrations/freeipa/defense_evasion_freeipa_trust_modification.toml @@ -0,0 +1,107 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies FreeIPA API commands that create, modify, or delete Active Directory trust relationships. Trust relationships +enable cross-realm Kerberos authentication between FreeIPA and AD domains. Modifying trust configurations can enable +lateral movement to AD environments or weaken the security boundary between domains. +""" +false_positives = [ + """ + Initial trust setup or trust reconfiguration during planned AD integration changes may trigger this rule. + Trust modifications are extremely rare in production and should always correspond to a change management + record. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA Active Directory Trust Modified" +note = """## Triage and analysis + +### Investigating FreeIPA Active Directory Trust Modified + +FreeIPA supports trust relationships with Active Directory, enabling cross-realm Kerberos authentication. Trust modifications are infrastructure-level changes that affect the security boundary between domains. An adversary with admin access can create trusts to attacker-controlled AD domains, modify existing trusts to weaken security, or delete trusts to cause service disruption. + +### Possible investigation steps + +- Identify the actor from `user.name` and verify they are authorized to manage trust relationships. +- Check `event.action` for the specific operation (trust_add, trust_mod, trust_del, trust_fetch_domains). +- Review `freeipa.api.parameters` to identify the target AD domain. +- For trust_add, verify the target domain is legitimate and the trust was planned. +- For trust_del, assess the impact on cross-realm authentication and service availability. +- Verify the operation against a change management record. + +### Response and remediation + +- If unauthorized, immediately remove any rogue trust relationships. +- Investigate the actor's account for compromise. +- Review trust configuration to ensure it follows the principle of least privilege. +- Check for cross-realm ticket activity that may indicate exploitation of the modified trust. +""" +references = [ + "https://attack.mitre.org/techniques/T1484/002/", + "https://www.freeipa.org/page/Active_Directory_trust_setup", +] +risk_score = 73 +rule_id = "ca89c58e-3087-4744-bf33-6896af4cd3d9" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - IPA API: `/var/log/httpd/error_log` (ipa_api data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA API", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.ipa_api-* +| where event.action in ("trust_add", "trust_mod", "trust_del", "trustdomain_add", "trustdomain_del") +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1484" +name = "Domain or Tenant Policy Modification" +reference = "https://attack.mitre.org/techniques/T1484/" +[[rule.threat.technique.subtechnique]] +id = "T1484.002" +name = "Trust Modification" +reference = "https://attack.mitre.org/techniques/T1484/002/" + + +[rule.threat.tactic] +id = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "source.ip", + "event.action", + "event.outcome", + "freeipa.api.parameters", +] diff --git a/rules/integrations/freeipa/discovery_freeipa_anonymous_ldap_enumeration.toml b/rules/integrations/freeipa/discovery_freeipa_anonymous_ldap_enumeration.toml new file mode 100644 index 00000000000..7baef6ebca3 --- /dev/null +++ b/rules/integrations/freeipa/discovery_freeipa_anonymous_ldap_enumeration.toml @@ -0,0 +1,111 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Detects anonymous LDAP sessions returning large numbers of entries by joining RESULT events with the latest_bind +transform to identify sessions that authenticated anonymously. Anonymous binds should not be performing bulk directory +queries. A high total entry count across multiple RESULT events from an unauthenticated session indicates directory +enumeration without credentials. +""" +false_positives = [ + """ + Some legacy LDAP monitoring tools or health checks may perform anonymous binds and read rootDSE or schema entries. + These typically return small result sets. Tune the threshold if anonymous monitoring is expected in the environment. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA Anonymous LDAP Enumeration" +note = """## Triage and analysis + +### Investigating FreeIPA Anonymous LDAP Enumeration + +Anonymous LDAP access to FreeIPA exposes directory data without any authentication. While FreeIPA restricts anonymous access by default, misconfigurations or legacy settings may allow it. An attacker exploiting anonymous access can enumerate users, groups, hosts, and policies without credentials. + +### Possible investigation steps + +- Review `source.ip` to identify the origin of the anonymous queries. +- Check whether anonymous access is intentionally enabled on the 389 Directory Server by reviewing `nsslapd-allow-anonymous-access` in cn=config. +- Examine the `freeipa.directory.base_dn` and `freeipa.directory.filter` from correlated SRCH events on the same connection to understand what was queried. +- Check `Esql.total_entries` to quantify the volume of data exposed. +- Investigate whether the source IP has performed any other activity (Kerberos auth attempts, IPA API calls). + +### Response and remediation + +- Disable anonymous LDAP access by setting `nsslapd-allow-anonymous-access: rootdse` in cn=config. +- Block the source IP if it is external or unauthorized. +- Audit directory ACIs to ensure sensitive attributes are not exposed to anonymous users. +""" +references = [ + "https://attack.mitre.org/techniques/T1087/002/", + "https://specterops.io/blog/2019/12/04/attacking-freeipa-part-ii-enumeration/", +] +risk_score = 47 +rule_id = "1e811e78-ea98-4a14-a135-ffa42bb8ff52" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - 389DS access: `/var/log/dirsrv/slapd-*/access` (directory_access data stream) + +This rule requires the `latest_bind` transform to be running. Verify the transform is running: `GET _transform/logs-freeipa-latest-bind/_stats`. The destination index must use `index.mode: lookup`. See the integration README for setup instructions. +""" +severity = "medium" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA Directory Server", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.directory_access-* +| where freeipa.directory.operation == "BIND" + and freeipa.directory.bind_method == "SIMPLE" + and freeipa.directory.bind_dn == "" +| stats Esql.anon_bind_count = count(*) by source.ip +| where Esql.anon_bind_count >= 3 +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1087" +name = "Account Discovery" +reference = "https://attack.mitre.org/techniques/T1087/" +[[rule.threat.technique.subtechnique]] +id = "T1087.002" +name = "Domain Account" +reference = "https://attack.mitre.org/techniques/T1087/002/" + + +[rule.threat.tactic] +id = "TA0007" +name = "Discovery" +reference = "https://attack.mitre.org/tactics/TA0007/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "freeipa.directory.bind_dn", + "freeipa.directory.connection_id", + "freeipa.directory.entries_returned", + "Esql.total_entries", +] diff --git a/rules/integrations/freeipa/discovery_freeipa_ldap_enumeration_non_service.toml b/rules/integrations/freeipa/discovery_freeipa_ldap_enumeration_non_service.toml new file mode 100644 index 00000000000..8fc662aeb8f --- /dev/null +++ b/rules/integrations/freeipa/discovery_freeipa_ldap_enumeration_non_service.toml @@ -0,0 +1,122 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +min_stack_comments = "ES|QL LOOKUP JOIN requires 8.19+ for GA support with lookup-mode indices." +min_stack_version = "8.19.0" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Detects authenticated LDAP sessions returning large numbers of entries where the bind DN is not a service account +(Directory Manager, host principals, or Kerberos services). SSSD and internal FreeIPA processes use host principals +or Directory Manager; human-initiated enumeration uses user principals. A high total entry count from a user principal +indicates potential directory reconnaissance. +""" +false_positives = [ + """ + Legitimate administrative tools or custom LDAP scripts run under user principals may query large portions of the + directory. Add known administrative user DNs to the exclusion list if they routinely perform bulk queries. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA Mass LDAP Enumeration by Non-Service Account" +note = """## Triage and analysis + +### Investigating FreeIPA Mass LDAP Enumeration by Non-Service Account + +Service accounts and internal FreeIPA processes legitimately perform large LDAP queries for replication, cache refreshes, and policy evaluation. When a regular user principal performs bulk queries returning hundreds of entries, it typically indicates manual directory reconnaissance — either by an attacker with stolen credentials or an insider threat. + +### Possible investigation steps + +- Identify the user from `freeipa.directory.bind_dn` and determine if they have a legitimate need for bulk directory access. +- Review `Esql.total_entries` and `Esql.query_count` to understand the scale and pattern of the enumeration. +- Check `source.ip` to determine if the queries originate from the user's expected workstation or an unusual location. +- Examine correlated SRCH events on the same connection to understand what base DNs, scopes, and filters were used. +- Look for follow-up activity from the same user — privilege escalation, credential access, or lateral movement. + +### Response and remediation + +- If unauthorized, reset the user's credentials and revoke active Kerberos tickets. +- Review LDAP ACIs and consider implementing `nsslapd-sizelimit` for non-admin users. +- Determine what data was exposed and assess the impact. +- Block the source IP if it is not a legitimate workstation. +""" +references = [ + "https://attack.mitre.org/techniques/T1087/002/", + "https://specterops.io/blog/2019/12/04/attacking-freeipa-part-ii-enumeration/", +] +risk_score = 47 +rule_id = "6ab88d87-ffed-477a-9752-c2f6d7c7d4c8" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - 389DS access: `/var/log/dirsrv/slapd-*/access` (directory_access data stream) + +This rule requires the `latest_bind` transform to be running. Verify the transform is running: `GET _transform/logs-freeipa-latest-bind/_stats`. The destination index must use `index.mode: lookup`. See the integration README for setup instructions. +""" +severity = "medium" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA Directory Server", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.directory_access-* +| where freeipa.directory.operation == "RESULT" + and freeipa.directory.entries_returned > 50 +| LOOKUP JOIN freeipa-lookup-bind ON freeipa.directory.connection_id + | KEEP @timestamp, freeipa.*, source.ip, user.*, observer.*, host.name, event.action, event.outcome, event.kind, event.category, event.type, event.module +| where freeipa.directory.bind_dn is not null + and freeipa.directory.bind_dn != "" + and not freeipa.directory.bind_dn like "*cn=Directory Manager*" + and not freeipa.directory.bind_dn like "fqdn=*" + and not freeipa.directory.bind_dn like "krbprincipalname=*" +| stats Esql.total_entries = sum(freeipa.directory.entries_returned), + Esql.query_count = count(*) by freeipa.directory.bind_dn +| where Esql.total_entries > 200 +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1087" +name = "Account Discovery" +reference = "https://attack.mitre.org/techniques/T1087/" +[[rule.threat.technique.subtechnique]] +id = "T1087.002" +name = "Domain Account" +reference = "https://attack.mitre.org/techniques/T1087/002/" + + +[rule.threat.tactic] +id = "TA0007" +name = "Discovery" +reference = "https://attack.mitre.org/tactics/TA0007/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "freeipa.directory.bind_dn", + "freeipa.directory.connection_id", + "freeipa.directory.entries_returned", + "Esql.total_entries", + "Esql.query_count", +] diff --git a/rules/integrations/freeipa/impact_freeipa_kerberos_account_lockout_storm.toml b/rules/integrations/freeipa/impact_freeipa_kerberos_account_lockout_storm.toml new file mode 100644 index 00000000000..a176b322bbc --- /dev/null +++ b/rules/integrations/freeipa/impact_freeipa_kerberos_account_lockout_storm.toml @@ -0,0 +1,118 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies multiple distinct Kerberos principals being locked out in a short time window. A lockout storm across +many accounts indicates either a large-scale password spraying attack that has hit lockout thresholds, or a +deliberate denial of service attack designed to lock out legitimate users. +""" +false_positives = [ + """ + A misconfigured batch job or monitoring system that authenticates with expired credentials across many + accounts could trigger lockouts. This should be rare and traceable to a specific source IP. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA Kerberos Account Lockout Storm" +note = """## Triage and analysis + +### Investigating FreeIPA Kerberos Account Lockout Storm + +LOCKED_OUT errors from the KDC indicate that an account has exceeded the maximum failed authentication attempts defined in the password policy. Multiple accounts being locked out simultaneously is inherently abnormal and indicates either a widespread spray attack or deliberate lockout abuse. + +### Possible investigation steps + +- List all locked-out principals by querying `freeipa.kdc.error_code:LOCKED_OUT` in the alert time window. +- Determine if the lockouts originate from a single `source.ip` (targeted attack) or many IPs (distributed attack). +- Check for preceding PREAUTH_FAILED events from the same source(s) to confirm a spray preceded the lockouts. +- Assess the operational impact — how many users are unable to authenticate. +- Determine if any accounts had successful authentication before being locked out (indicating the attacker guessed a password). + +### Response and remediation + +- Block the source IP(s) at the network perimeter. +- Unlock affected accounts via `ipa user-unlock ` after verifying they are legitimate. +- Force password resets for any accounts that had successful authentications from the attacking source before lockout. +- Review lockout policy thresholds to balance security with operational resilience. +""" +references = [ + "https://attack.mitre.org/techniques/T1110/", + "https://attack.mitre.org/techniques/T1531/", +] +risk_score = 73 +rule_id = "ee6f2d52-a4b5-4c1e-9d8c-8f3b2a7e1f04" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - KDC: `/var/log/krb5kdc.log` (kdc data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA KDC", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Tactic: Impact", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.kdc-* +| where freeipa.kdc.error_code == "LOCKED_OUT" +| stats Esql.lockout_count = count(*), Esql.unique_principals = count_distinct(freeipa.kdc.client_principal) by source.ip +| where Esql.lockout_count >= 3 and Esql.unique_principals >= 3 +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1110" +name = "Brute Force" +reference = "https://attack.mitre.org/techniques/T1110/" + + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1531" +name = "Account Access Removal" +reference = "https://attack.mitre.org/techniques/T1531/" + + +[rule.threat.tactic] +id = "TA0040" +name = "Impact" +reference = "https://attack.mitre.org/tactics/TA0040/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "freeipa.kdc.client_principal", + "freeipa.kdc.error_code", + "event.outcome", + "Esql.lockout_count", + "Esql.unique_principals", +] diff --git a/rules/integrations/freeipa/impact_freeipa_mass_account_disable_delete.toml b/rules/integrations/freeipa/impact_freeipa_mass_account_disable_delete.toml new file mode 100644 index 00000000000..8166226d19e --- /dev/null +++ b/rules/integrations/freeipa/impact_freeipa_mass_account_disable_delete.toml @@ -0,0 +1,104 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies a burst of FreeIPA API commands that disable or delete user or host accounts. Mass account manipulation +indicates either a destructive attack (sabotage, denial of service) or a compromised admin account performing +unauthorized cleanup to cover tracks. +""" +false_positives = [ + """ + Planned decommissioning of hosts or offboarding of users may generate multiple disable/delete commands. + Verify against an HR or infrastructure change management record. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA Mass Account Disable or Deletion" +note = """## Triage and analysis + +### Investigating FreeIPA Mass Account Disable or Deletion + +Bulk account disabling or deletion in FreeIPA causes widespread authentication failures across the domain. This can be used as sabotage (denying access to legitimate users) or to cover tracks by removing compromised accounts. Even accidental mass deletion has severe impact. + +### Possible investigation steps + +- Identify the actor from `user.name` and verify they are authorized to manage accounts. +- List all affected accounts from the `freeipa.api.parameters` field across the matched events. +- Determine if the operations target users, hosts, or both. +- Check if any affected accounts were recently compromised or flagged. +- Verify against an HR offboarding list or infrastructure decommissioning plan. + +### Response and remediation + +- If unauthorized, re-enable or recreate affected accounts immediately. +- Reset credentials for the actor's account and revoke their sessions. +- Investigate the actor's account for compromise. +- Review admin access controls and consider implementing approval workflows for bulk operations. +""" +references = [ + "https://attack.mitre.org/techniques/T1531/", +] +risk_score = 73 +rule_id = "7d576109-d0cf-45d8-bc19-5145bc04beda" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - IPA API: `/var/log/httpd/error_log` (ipa_api data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA API", + "Use Case: Threat Detection", + "Tactic: Impact", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.ipa_api-* +| where event.outcome == "success" + and event.action in ("user_del", "user_disable", "host_del", "host_disable") +| stats Esql.action_count = count(*) by user.name +| where Esql.action_count >= 5 +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1531" +name = "Account Access Removal" +reference = "https://attack.mitre.org/techniques/T1531/" + + +[rule.threat.tactic] +id = "TA0040" +name = "Impact" +reference = "https://attack.mitre.org/tactics/TA0040/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "source.ip", + "event.action", + "event.outcome", + "freeipa.api.parameters", + "Esql.action_count", +] diff --git a/rules/integrations/freeipa/initial_access_freeipa_kerberos_auth_new_source_ip.toml b/rules/integrations/freeipa/initial_access_freeipa_kerberos_auth_new_source_ip.toml new file mode 100644 index 00000000000..b4ca93974b3 --- /dev/null +++ b/rules/integrations/freeipa/initial_access_freeipa_kerberos_auth_new_source_ip.toml @@ -0,0 +1,115 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Detects the first time a Kerberos principal authenticates from a particular source IP. This may indicate credential +theft, CCACHE ticket reuse, or keytab abuse from a new location. Uses 14-day history to establish baseline. Normal +user behavior involves authentication from a small set of known workstations; a new source IP warrants investigation. +""" +false_positives = [ + """ + Users legitimately authenticating from new workstations, VPN endpoints, or after IP address changes will trigger + this rule. Environments with dynamic DHCP addressing may see frequent new source IPs for the same principal. + Consider tuning the history window or excluding known VPN address ranges. + """, +] +from = "now-9m" +index = ["logs-freeipa.kdc-*"] +language = "kuery" +license = "Elastic License v2" +name = "First FreeIPA Kerberos Authentication from New Source IP" +note = """## Triage and analysis + +### Investigating First FreeIPA Kerberos Authentication from New Source IP + +When a Kerberos principal authenticates from a source IP that has not been seen in the past 14 days, it may indicate credential theft. Attackers who steal keytabs, CCACHE files, or passwords can authenticate from their own infrastructure. This is especially concerning for service principals and admin accounts that should authenticate from fixed locations. + +### Possible investigation steps + +- Identify the principal from `freeipa.kdc.client_principal` and determine if it is a user, host, or service principal. +- Check `source.ip` and `source.geo` to determine if the new location is expected (e.g., a known office, VPN, or cloud provider). +- For service principals and host keytabs, verify the source IP matches the expected host — any deviation is highly suspicious. +- Review recent activity for the principal across all data streams (KDC, IPA API, directory_access). +- Check if the principal's credentials were recently changed or if there are signs of credential theft. + +### Response and remediation + +- For compromised service principals, regenerate the keytab on the legitimate host. +- For compromised user accounts, reset the password and revoke active tickets. +- Block the suspicious source IP if it is external. +- Review CCACHE file permissions on the principal's expected hosts. +""" +references = [ + "https://attack.mitre.org/techniques/T1078/002/", + "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/linux-active-directory#ccache-ticket-reuse", +] +risk_score = 47 +rule_id = "7a5d8b04-ec31-4a51-884c-f936b083d465" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - KDC: `/var/log/krb5kdc.log` (kdc data stream) +""" +severity = "medium" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA KDC", + "Use Case: Threat Detection", + "Tactic: Initial Access", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "new_terms" + +query = ''' +event.dataset: "freeipa.kdc" and event.action: "kdc_tgt_grant" +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1078" +name = "Valid Accounts" +reference = "https://attack.mitre.org/techniques/T1078/" +[[rule.threat.technique.subtechnique]] +id = "T1078.002" +name = "Domain Accounts" +reference = "https://attack.mitre.org/techniques/T1078/002/" + + +[rule.threat.tactic] +id = "TA0001" +name = "Initial Access" +reference = "https://attack.mitre.org/tactics/TA0001/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "source.geo.country_name", + "freeipa.kdc.client_principal", + "freeipa.kdc.service_principal", + "freeipa.kdc.request_type", + "event.action", + "event.outcome", +] + +[rule.new_terms] +field = "new_terms_fields" +value = ["freeipa.kdc.client_principal", "source.ip"] + +[[rule.new_terms.history_window_start]] +field = "history_window_start" +value = "now-14d" diff --git a/rules/integrations/freeipa/persistence_freeipa_admin_group_member_added.toml b/rules/integrations/freeipa/persistence_freeipa_admin_group_member_added.toml new file mode 100644 index 00000000000..ec18acff532 --- /dev/null +++ b/rules/integrations/freeipa/persistence_freeipa_admin_group_member_added.toml @@ -0,0 +1,103 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies when a user or group is added to the FreeIPA admins group via the IPA API. The admins group grants full +domain administrator privileges. Adding members to this group is a direct privilege escalation path that should be +rare and closely monitored. +""" +false_positives = [ + """ + Authorized admin onboarding or emergency access provisioning may trigger this rule. Verify the operation + matches an approved change request. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA Admin Group Member Added" +note = """## Triage and analysis + +### Investigating FreeIPA Admin Group Member Added + +The FreeIPA `admins` group provides full administrative control over the domain, including user management, policy changes, and Kerberos configuration. Adding a member to this group is the most direct privilege escalation in FreeIPA. This should be an extremely rare operation. + +### Possible investigation steps + +- Identify the actor from `user.name` and `source.ip`. +- Identify the newly added member from `freeipa.api.parameters`. +- Verify the change was authorized through a change management process. +- Check if the actor's account shows signs of compromise — unusual login times, new source IPs, or other API calls. +- Review the new admin member's subsequent activity for signs of abuse. + +### Response and remediation + +- If unauthorized, immediately remove the added member from the admins group via `ipa group_remove_member admins --users=`. +- Reset credentials for both the actor and the newly added member. +- Investigate the actor's account for compromise. +- Review who has permission to modify the admins group and restrict it. +""" +references = [ + "https://attack.mitre.org/techniques/T1098/", + "https://specterops.io/blog/2019/12/04/attacking-freeipa-part-ii-enumeration/", +] +risk_score = 73 +rule_id = "6f77eb93-0f3e-4dea-8870-de70c49973af" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - IPA API: `/var/log/httpd/error_log` (ipa_api data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA API", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.ipa_api-* +| where event.action == "group_add_member" + and event.outcome == "success" + and freeipa.api.parameters like "*admins*" +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1098" +name = "Account Manipulation" +reference = "https://attack.mitre.org/techniques/T1098/" + + +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "source.ip", + "event.action", + "event.outcome", + "freeipa.api.parameters", +] diff --git a/rules/integrations/freeipa/persistence_freeipa_ca_role_assumed.toml b/rules/integrations/freeipa/persistence_freeipa_ca_role_assumed.toml new file mode 100644 index 00000000000..b1bad9653f8 --- /dev/null +++ b/rules/integrations/freeipa/persistence_freeipa_ca_role_assumed.toml @@ -0,0 +1,101 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies a ROLE_ASSUME event in the FreeIPA Dogtag CA audit log, indicating that a user assumed a CA administrative +role. CA admin roles provide the ability to issue, revoke, and manage certificates. Unauthorized role assumption +enables full control over the PKI infrastructure. +""" +false_positives = [ + """ + CA administrators performing routine maintenance or certificate operations will trigger this rule. + FreeIPA internal processes (RA_AGENT) also assume roles during normal operation. Exclude known internal + role assumptions if they are too noisy. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA CA Administrative Role Assumed" +note = """## Triage and analysis + +### Investigating FreeIPA CA Administrative Role Assumed + +The Dogtag CA uses role-based access control for certificate operations. ROLE_ASSUME events indicate a user has taken on a CA administrative role, granting them certificate management capabilities. While some internal processes assume roles routinely, unexpected role assumptions may indicate a compromised account gaining PKI control. + +### Possible investigation steps + +- Identify the user from `user.id` and determine if they are an authorized CA administrator. +- Check `freeipa.ca.role` to identify which role was assumed (e.g., Certificate Manager Agent, CA Administrator). +- Review `source.ip` to determine the origin of the request. +- Look for subsequent certificate operations (issuance, revocation) performed after the role assumption. +- Verify the role assumption against expected CA maintenance windows. + +### Response and remediation + +- If unauthorized, revoke any certificates issued during the session and investigate the user account. +- Review CA subsystem ACLs and restrict role assumption to authorized accounts. +- Audit all CA operations performed after the role assumption. +""" +references = [ + "https://attack.mitre.org/techniques/T1098/", +] +risk_score = 47 +rule_id = "065c4b8d-2382-4ffc-ae96-d7626e3cbd8a" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - Dogtag CA: `/var/log/pki/pki-tomcat/ca/signedAudit/ca_audit` (ca_audit data stream) +""" +severity = "medium" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA CA", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.ca_audit-* +| where freeipa.ca.event_type == "ROLE_ASSUME" + and not user.name in ("ipara", "pkidbuser") +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1098" +name = "Account Manipulation" +reference = "https://attack.mitre.org/techniques/T1098/" + + +[rule.threat.tactic] +id = "TA0004" +name = "Privilege Escalation" +reference = "https://attack.mitre.org/tactics/TA0004/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.id", + "source.ip", + "freeipa.ca.event_type", + "freeipa.ca.role", + "event.outcome", +] diff --git a/rules/integrations/freeipa/persistence_freeipa_first_api_command_for_user.toml b/rules/integrations/freeipa/persistence_freeipa_first_api_command_for_user.toml new file mode 100644 index 00000000000..804caa2b6e3 --- /dev/null +++ b/rules/integrations/freeipa/persistence_freeipa_first_api_command_for_user.toml @@ -0,0 +1,108 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Detects the first time a user performs a specific administrative IPA API command. A user who has never managed sudo +rules suddenly creating one, or a user who has never modified groups adding members, may indicate a compromised +account being used for privilege escalation. Uses 14-day history to establish each user's normal command repertoire. +""" +false_positives = [ + """ + Newly promoted administrators or users granted new roles will naturally perform API commands for the first time. + Correlate with recent role or privilege assignments to distinguish legitimate new access from suspicious activity. + """, +] +from = "now-9m" +index = ["logs-freeipa.ipa_api-*"] +language = "kuery" +license = "Elastic License v2" +name = "First FreeIPA Administrative API Command for User" +note = """## Triage and analysis + +### Investigating First FreeIPA Administrative API Command for User + +FreeIPA administrators develop patterns of API usage based on their role. A user who typically only manages passwords suddenly adding sudo rules or modifying trust relationships is behaving outside their baseline. This can indicate credential compromise, privilege abuse, or an insider threat. + +### Possible investigation steps + +- Identify the user from `user.name` and the new command from `event.action`. +- Determine if the user was recently granted a new role or permission that would explain the new command. +- Review `source.ip` to check if the command originated from the user's expected location. +- Examine the `freeipa.api.parameters` to understand what was created or modified. +- Check for other anomalous activity from the same user — unusual login times, new source IPs, or failed commands. + +### Response and remediation + +- If the activity is unauthorized, revert the change made by the API command. +- Reset the user's credentials and revoke active sessions. +- Review the user's role assignments and remove any unauthorized privileges. +- Investigate how the user obtained the ability to execute the command. +""" +references = [ + "https://attack.mitre.org/techniques/T1098/", + "https://freeipa.org/page/V4/IPA_API_Audit", +] +risk_score = 47 +rule_id = "d9bc8754-b35c-47fb-b79d-c2c3edcfe2ac" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - IPA API: `/var/log/httpd/error_log` (ipa_api data stream) +""" +severity = "medium" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA API", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "new_terms" + +query = ''' +event.dataset: "freeipa.ipa_api" and event.outcome: "success" and event.action: (user_mod or group_add_member or role_add_member or sudorule_add or hbacrule_add or otptoken_add or otptoken_del or pwpolicy_mod or trust_add or permission_add or privilege_add_permission) +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1098" +name = "Account Manipulation" +reference = "https://attack.mitre.org/techniques/T1098/" + + +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "source.ip", + "event.action", + "event.outcome", + "freeipa.api.parameters", +] + +[rule.new_terms] +field = "new_terms_fields" +value = ["user.name", "event.action"] + +[[rule.new_terms.history_window_start]] +field = "history_window_start" +value = "now-14d" diff --git a/rules/integrations/freeipa/persistence_freeipa_new_host_enrollment_new_source.toml b/rules/integrations/freeipa/persistence_freeipa_new_host_enrollment_new_source.toml new file mode 100644 index 00000000000..9a958624e85 --- /dev/null +++ b/rules/integrations/freeipa/persistence_freeipa_new_host_enrollment_new_source.toml @@ -0,0 +1,114 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Detects host enrollment (host_add) from a source IP that has not previously enrolled hosts. Rogue host registration +from unexpected locations may indicate an attacker expanding their foothold by adding unauthorized machines to the +FreeIPA domain. Uses 30-day history to establish which source IPs normally enroll hosts. +""" +false_positives = [ + """ + Legitimate host enrollment from new infrastructure (new data center, cloud region, or provisioning server) will + trigger this rule. Correlate with change management records. Automated provisioning systems that rotate IPs may + also trigger — consider excluding known provisioning subnets. + """, +] +from = "now-9m" +index = ["logs-freeipa.ipa_api-*"] +language = "kuery" +license = "Elastic License v2" +name = "FreeIPA New Host Enrollment from New Source IP" +note = """## Triage and analysis + +### Investigating FreeIPA New Host Enrollment from New Source IP + +Host enrollment in FreeIPA creates a host principal and keytab, granting the host authenticated access to domain services. In mature environments, host enrollment typically occurs from a small set of provisioning servers or management workstations. Enrollment from a new source IP may indicate an attacker registering rogue hosts to establish persistence. + +### Possible investigation steps + +- Identify the user performing the enrollment from `user.name` and the source from `source.ip`. +- Review `freeipa.api.parameters` to identify the hostname being enrolled. +- Verify the enrolled host is a legitimate machine in your inventory. +- Check if a one-time password (OTP) was used for enrollment, which would indicate pre-authorized enrollment. +- Investigate the source IP — is it a known provisioning server, jump box, or an unexpected location? + +### Response and remediation + +- If the enrollment is unauthorized, immediately delete the host with `ipa host-del `. +- Revoke the host's keytab and Kerberos principal. +- Block the source IP if it is unauthorized. +- Review who has host enrollment permissions and restrict them. +- Audit recently enrolled hosts for other unauthorized additions. +""" +references = [ + "https://attack.mitre.org/techniques/T1136/002/", + "https://freeipa.org/page/V4/Host_Enrollment", +] +risk_score = 47 +rule_id = "382dd854-3253-4ecc-9566-e58e7ba74b8e" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - IPA API: `/var/log/httpd/error_log` (ipa_api data stream) +""" +severity = "medium" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA API", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "new_terms" + +query = ''' +event.dataset: "freeipa.ipa_api" and event.action: "host_add" and event.outcome: "success" +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1136" +name = "Create Account" +reference = "https://attack.mitre.org/techniques/T1136/" +[[rule.threat.technique.subtechnique]] +id = "T1136.002" +name = "Domain Account" +reference = "https://attack.mitre.org/techniques/T1136/002/" + + +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "source.ip", + "event.action", + "event.outcome", + "freeipa.api.parameters", +] + +[rule.new_terms] +field = "new_terms_fields" +value = ["source.ip"] + +[[rule.new_terms.history_window_start]] +field = "history_window_start" +value = "now-30d" diff --git a/rules/integrations/freeipa/persistence_freeipa_otp_token_manipulation.toml b/rules/integrations/freeipa/persistence_freeipa_otp_token_manipulation.toml new file mode 100644 index 00000000000..f106ad9928d --- /dev/null +++ b/rules/integrations/freeipa/persistence_freeipa_otp_token_manipulation.toml @@ -0,0 +1,124 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies FreeIPA API commands that add, delete, or modify OTP tokens. Adversaries who compromise a helpdesk or admin +account can create new OTP tokens for target users to bypass two-factor authentication, or delete existing tokens to +downgrade authentication to password-only. OTP token operations are rare and always security-relevant. +""" +false_positives = [ + """ + Legitimate helpdesk operations for OTP token provisioning or replacement will trigger this rule. Verify that + the operation corresponds to an authorized support ticket or enrollment workflow. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA OTP Token Created, Modified, or Deleted" +note = """## Triage and analysis + +### Investigating FreeIPA OTP Token Created, Modified, or Deleted + +FreeIPA supports OTP two-factor authentication via TOTP and HOTP tokens. Creating a new token for a user effectively gives the creator a valid second factor. Deleting a user's last active token may downgrade them to password-only authentication. Both are high-value actions for an adversary with helpdesk privileges. + +### Possible investigation steps + +- Identify the actor from `user.name` — determine if they have helpdesk or admin privileges. +- Identify the target user from `freeipa.api.parameters`. +- Check `event.action` to determine the specific operation (otptoken_add, otptoken_del, otptoken_mod). +- Verify the operation was authorized through a support ticket or enrollment process. +- For token deletions, check if the target user still has active OTP tokens — deletion of the last token is the highest risk. +- Review the actor's recent API activity for other suspicious operations. + +### Response and remediation + +- If unauthorized, immediately provision a new OTP token for the affected user and invalidate any tokens created by the attacker. +- Investigate the actor's account for compromise. +- Review who has the `Manage OTP Tokens` permission and apply least privilege. +- Consider restricting OTP token management to require a separate approval workflow. +""" +references = [ + "https://www.freeipa.org/page/V4/OTP", + "https://attack.mitre.org/techniques/T1556/006/", +] +risk_score = 73 +rule_id = "7be500eb-c743-44a3-bedf-3c6816837251" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - IPA API: `/var/log/httpd/error_log` (ipa_api data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA API", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Credential Access", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.ipa_api-* +| where event.action in ("otptoken_add", "otptoken_del", "otptoken_mod") +''' + + +[[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.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 = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "source.ip", + "event.action", + "event.outcome", + "freeipa.api.parameters", +] diff --git a/rules/integrations/freeipa/privilege_escalation_freeipa_password_policy_weakened.toml b/rules/integrations/freeipa/privilege_escalation_freeipa_password_policy_weakened.toml new file mode 100644 index 00000000000..60f98c918e6 --- /dev/null +++ b/rules/integrations/freeipa/privilege_escalation_freeipa_password_policy_weakened.toml @@ -0,0 +1,99 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies a FreeIPA API pwpolicy_mod command that modifies a password policy. Adversaries with admin privileges can +weaken password policies to reduce minimum length, disable lockout, or lower complexity requirements, making brute +force attacks more feasible. +""" +false_positives = [ + """ + Authorized password policy changes during security policy reviews or compliance adjustments may trigger this + rule. Password policy modifications should be rare and always go through a change management process. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA Password Policy Modified" +note = """## Triage and analysis + +### Investigating FreeIPA Password Policy Modified + +FreeIPA password policies control minimum length, complexity, lockout thresholds, and history. Weakening these policies enables brute force attacks, password reuse, and reduces the effectiveness of lockout-based defenses. + +### Possible investigation steps + +- Identify the actor from `user.name` and verify they are authorized to modify password policies. +- Review `freeipa.api.parameters` to determine which policy was modified and what settings changed. +- Compare the new policy values against organizational security requirements. +- Determine if the change makes accounts more vulnerable (reduced minlength, lower maxfail, shorter lockouttime). +- Verify the change against a security policy review or change management record. + +### Response and remediation + +- If unauthorized, restore the password policy to its previous values. +- Investigate the actor's account for compromise. +- Force password resets for any accounts that may have been set with weak passwords during the policy gap. +""" +references = [ + "https://attack.mitre.org/techniques/T1484/", +] +risk_score = 47 +rule_id = "1777f05d-6ef7-4cc6-856f-a684418e3faf" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - IPA API: `/var/log/httpd/error_log` (ipa_api data stream) +""" +severity = "medium" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA API", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.ipa_api-* +| where event.action == "pwpolicy_mod" and event.outcome == "success" +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1484" +name = "Domain or Tenant Policy Modification" +reference = "https://attack.mitre.org/techniques/T1484/" + + +[rule.threat.tactic] +id = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "source.ip", + "event.action", + "event.outcome", + "freeipa.api.parameters", +] diff --git a/rules/integrations/freeipa/privilege_escalation_freeipa_role_privilege_assignment.toml b/rules/integrations/freeipa/privilege_escalation_freeipa_role_privilege_assignment.toml new file mode 100644 index 00000000000..eef66fd1cdc --- /dev/null +++ b/rules/integrations/freeipa/privilege_escalation_freeipa_role_privilege_assignment.toml @@ -0,0 +1,101 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies FreeIPA API commands that assign members to roles, add permissions to privileges, or create new permissions. +FreeIPA's RBAC model uses roles containing privileges containing permissions. Modifying this hierarchy is a privilege +escalation path that should be closely monitored. +""" +false_positives = [ + """ + Authorized RBAC configuration changes during initial deployment or organizational restructuring may trigger + this rule. Verify the operation against a change management record. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA RBAC Role or Privilege Modification" +note = """## Triage and analysis + +### Investigating FreeIPA RBAC Role or Privilege Modification + +FreeIPA implements a three-tier RBAC model: roles contain privileges, and privileges contain permissions. Permissions define the actual LDAP operations allowed. An adversary who can modify this hierarchy can grant themselves any level of access without directly adding themselves to the admins group. + +### Possible investigation steps + +- Identify the actor from `user.name` and determine if they have legitimate RBAC management privileges. +- Check `event.action` to determine the specific operation performed. +- Review `freeipa.api.parameters` to identify which role, privilege, or permission was modified and what was added. +- Determine if the change grants access to sensitive operations (user management, password resets, certificate issuance). +- Verify the change against a change management record. + +### Response and remediation + +- If unauthorized, revert the RBAC change using the corresponding remove command (e.g., `role_remove_member`, `privilege_remove_permission`). +- Investigate the actor's account for compromise. +- Review the RBAC delegation model and ensure only a minimal set of principals can modify roles and privileges. +""" +references = [ + "https://attack.mitre.org/techniques/T1098/", + "https://specterops.io/blog/2019/12/04/attacking-freeipa-part-ii-enumeration/", +] +risk_score = 73 +rule_id = "16ff2674-a156-4e49-83b6-ec9e785d84ac" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - IPA API: `/var/log/httpd/error_log` (ipa_api data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA API", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.ipa_api-* +| where event.outcome == "success" + and event.action in ("role_add_member", "privilege_add_permission", "permission_add", "privilege_add_member") +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1098" +name = "Account Manipulation" +reference = "https://attack.mitre.org/techniques/T1098/" + + +[rule.threat.tactic] +id = "TA0004" +name = "Privilege Escalation" +reference = "https://attack.mitre.org/tactics/TA0004/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "source.ip", + "event.action", + "event.outcome", + "freeipa.api.parameters", +] diff --git a/rules/integrations/freeipa/privilege_escalation_freeipa_user_auth_type_downgrade.toml b/rules/integrations/freeipa/privilege_escalation_freeipa_user_auth_type_downgrade.toml new file mode 100644 index 00000000000..0aaef4f76f8 --- /dev/null +++ b/rules/integrations/freeipa/privilege_escalation_freeipa_user_auth_type_downgrade.toml @@ -0,0 +1,108 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies a FreeIPA API user_mod command that changes a user's authentication type. Adversaries with admin privileges +can downgrade a user from OTP (two-factor) to password-only authentication, making the account vulnerable to +single-factor credential attacks. This is a high-value persistence and defense evasion technique. +""" +false_positives = [ + """ + Legitimate auth type changes during OTP token replacement or troubleshooting may trigger this rule. + Verify against a support ticket or change request. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA User Authentication Type Modified" +note = """## Triage and analysis + +### Investigating FreeIPA User Authentication Type Modified + +FreeIPA supports per-user authentication types including password, OTP (TOTP/HOTP), PKINIT, and RADIUS. Changing a user's auth type from OTP to password-only effectively disables their two-factor authentication, making the account vulnerable to password-only attacks. This is particularly dangerous for admin accounts. + +### Possible investigation steps + +- Identify the actor from `user.name` and the target user from `freeipa.api.parameters`. +- Determine what the auth type was changed to — look for `password` in the parameters, which indicates a downgrade. +- Check if the target user is a high-privilege account (admin, helpdesk, service account). +- Verify the change was authorized through a support ticket or change management process. +- Look for subsequent authentication activity for the target user from unusual sources. + +### Response and remediation + +- If unauthorized, restore the user's auth type to OTP via `ipa user-mod --user-auth-type=otp`. +- Investigate the actor's account for compromise. +- Reset the target user's password as a precaution. +- Review who has the permission to modify user auth types and restrict it. +""" +references = [ + "https://www.freeipa.org/page/V4/OTP", + "https://attack.mitre.org/techniques/T1556/006/", +] +risk_score = 73 +rule_id = "7a4a0414-a388-4d55-a81a-3c2e98126bff" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - IPA API: `/var/log/httpd/error_log` (ipa_api data stream) +""" +severity = "high" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA API", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Persistence", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.ipa_api-* +| where event.action == "user_mod" + and event.outcome == "success" + and freeipa.api.parameters like "*ipauserauthtype*" +''' + + +[[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 = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "source.ip", + "event.action", + "event.outcome", + "freeipa.api.parameters", +] diff --git a/rules/integrations/freeipa/reconnaissance_freeipa_kerberos_principal_enumeration.toml b/rules/integrations/freeipa/reconnaissance_freeipa_kerberos_principal_enumeration.toml new file mode 100644 index 00000000000..5a8f99bcd60 --- /dev/null +++ b/rules/integrations/freeipa/reconnaissance_freeipa_kerberos_principal_enumeration.toml @@ -0,0 +1,108 @@ +[metadata] +creation_date = "2026/03/28" +integration = ["freeipa"] +maturity = "development" +updated_date = "2026/03/28" + +[rule] +author = ["Elastic"] +description = """ +Identifies a high number of Kerberos AS_REQ failures with CLIENT_NOT_FOUND from a single source IP, indicating +username enumeration against the FreeIPA KDC. Adversaries probe for valid Kerberos principals before attempting +credential attacks. The CLIENT_NOT_FOUND error is not produced by normal SSSD operations and is inherently suspicious +in volume. +""" +false_positives = [ + """ + Misconfigured applications referencing deleted or renamed principals may generate occasional CLIENT_NOT_FOUND + errors. A sustained burst from a single source is unlikely to be benign. + """, +] +from = "now-9m" +interval = "5m" +language = "esql" +license = "Elastic License v2" +name = "FreeIPA Kerberos Principal Enumeration" +note = """## Triage and analysis + +### Investigating FreeIPA Kerberos Principal Enumeration + +Adversaries enumerate valid Kerberos principals by sending AS_REQ for candidate usernames and observing whether the KDC returns CLIENT_NOT_FOUND (principal does not exist) or PREAUTH_FAILED (principal exists, wrong password). A burst of CLIENT_NOT_FOUND indicates the reconnaissance phase of a credential attack. + +### Possible investigation steps + +- Review `source.ip` and `source.geo` to determine the origin. External sources are high risk. +- Examine the `freeipa.kdc.client_principal` values to understand what usernames are being probed — common patterns include admin, root, test, or sequential usernames. +- Check if the same source IP later generates PREAUTH_FAILED events (indicating it found valid principals and moved to password guessing). +- Correlate with LDAP anonymous bind activity from the same source in the `directory_access` data stream. + +### Response and remediation + +- Block the source IP at the network perimeter. +- Review whether the FreeIPA KDC is exposed to untrusted networks and restrict access if possible. +- Monitor for follow-up brute force or spraying activity from the same or related sources. +""" +references = [ + "https://attack.mitre.org/techniques/T1589/001/", + "https://specterops.io/blog/2019/12/04/attacking-freeipa-part-ii-enumeration/", +] +risk_score = 47 +rule_id = "b8b7abbf-3669-453a-b79d-a17f7c7ec409" +setup = """## Setup + +This rule requires the FreeIPA integration to be installed and configured to collect logs from FreeIPA servers. + +### FreeIPA Integration Setup +1. Install the FreeIPA integration in Kibana Fleet. +2. Add the integration to an Elastic Agent policy deployed on your FreeIPA server(s). +3. Ensure the relevant log paths are accessible: + - KDC: `/var/log/krb5kdc.log` (kdc data stream) +""" +severity = "medium" +tags = [ + "Domain: Identity", + "Data Source: FreeIPA", + "Data Source: FreeIPA KDC", + "Use Case: Threat Detection", + "Tactic: Reconnaissance", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-freeipa.kdc-* +| where freeipa.kdc.error_code == "CLIENT_NOT_FOUND" +| stats Esql.enumeration_count = count(*) by source.ip +| where Esql.enumeration_count >= 10 +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1589" +name = "Gather Victim Identity Information" +reference = "https://attack.mitre.org/techniques/T1589/" +[[rule.threat.technique.subtechnique]] +id = "T1589.001" +name = "Credentials" +reference = "https://attack.mitre.org/techniques/T1589/001/" + + +[rule.threat.tactic] +id = "TA0043" +name = "Reconnaissance" +reference = "https://attack.mitre.org/tactics/TA0043/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "source.geo.country_name", + "freeipa.kdc.client_principal", + "freeipa.kdc.error_code", + "freeipa.kdc.request_type", + "event.outcome", + "Esql.enumeration_count", +]