Brute Force Protection - critical settings manipulated

title: Brute Force Protection - critical settings manipulated
id: 8281291e-51b4-46a9-8012-955e20406efd
status: experimental
description: |
    Detect when Brute Force Protection has been disabled at all or set to a monitoring mode where no blocking occurs.
    This can allow malicious actors to continue brute force attacks without being detected and blocked.
author: Okta
date: 2025-07-11
modified: 2025-08-04
logsource:
    product: auth0
detection:
    selection:
        data.type: sapi
        data.description:
            - Update Brute-force settings
    filter_1:
        data.details.response.body.enabled: false
    filter_2:
        data.details.response.body.shields{}: 'block'
    condition: (selection and filter_1) or (selection and not filter_2)
explanation: >
    The query filters for modifications of the Brute Force Protection feature.
    It returns records when the feature is completely disabled, i.e. the "shields" attribute does not contain "block"
    or set into a monitoring mode by disabling all responses.
    The Splunk query below considers only the last modification and summarises a modifying IP, what mode is enabled,
    i.e. blocking an account just this IP or regardless, the state of user notifications.
splunk: |
    index=auth0 data.tenant_name="{your-tenant-name}"
    data.type=sapi data.description = "Update Brute-force settings"
    ``` Excluding white-listed IPs```
    ``` NOT data.ip IN ("{white-listed-IPs}")```
    | fields _time, data.ip, data.details.response.body.shields{}, data.details.response.body.enabled,
    data.details.response.body.mode
    ```Take only the last change of configurations that reflects the current settings```
    | sort - _time
    | head 1
    | rename data.details.response.body.shields{} as shields
    | rename data.details.response.body.enabled as brute_force_enabled
    | rename data.details.response.body.mode as brute_force_blocking_mode
    ``` Encoding the logic to define what flows' protection have been disabled and enabled```
    | eval brute_force_blocking = if(isnotnull(mvfind(shields, "block")), "true", "false")
    | eval brute_force_user_notifications_on = if(isnotnull(mvfind(shields, "user_notification")), "true", "false")
    ```Both responses are on```
    | eval brute_force_both_responses_on = if(match(brute_force_blocking_mode,"^count_per_identifier$") AND match(brute_force_blocking, "true"), "true", "false")
    ```Only "Block brute force login" is on, i.e. account is blocked from a concrete IP only```
    | eval brute_force_only_ip_specific_blocking = if(match(brute_force_blocking_mode,"count_per_identifier_and_ip") AND match(brute_force_blocking, "true"), "true", "false")
    ```"Lockout account" regardless IP is on, i.e. account is blocked from all IPs```
    | eval brute_force_regardless_ip_blocking = if(match(brute_force_blocking, "false") AND match(brute_force_blocking_mode,"^count_per_identifier$"), "true", "false")
    | eval brute_force_all_responses_disabled = if ((brute_force_only_ip_specific_blocking = "false" AND brute_force_regardless_ip_blocking = "false"), "true", "false")
    ```Alert when brute force is completely disabled or both responses are disabled```
    | where brute_force_enabled = "false" OR (brute_force_enabled="true" AND brute_force_all_responses_disabled="true")
    ```Display the information in a table```
    | table _time, data.ip, brute_force_enabled, brute_force_only_ip_specific_blocking, brute_force_regardless_ip_blocking,
     brute_force_user_notifications_on, brute_force_all_responses_disabled
comments:
    - The Splunk query above shall be tuned to reflect a valid tenant name.
    - Limit the detection to actions conducted from not white-listed IPs and/or particular users.
    - Additionally, you can also alert when user notifications are turned off indicated by 'brute_force_user_notifications_on = "false"''
      by modifying a respective "where" clause.
    - This detection can be used for reporting of all changes of the brute force protection settings by removing the "where" and "head" clauses.
tenant_logs: |
    type: "sapi" AND description: "Update Brute-force settings"
prevention:
    - Control tenant admins, i.e. "Admin", as this role has permissions to modify any application.
    - Enforce MFA for tenant admins to reduce the risk of an adversary gaining access.
    - Control Management API scopes that allow modification of attack protection features - update:attack_protection.
    - Control usage of Management API from only trusted IPs by applying Network ACL scoped to "management".
falsepositives:
    - Legitimate updates by an administrator. This rule is designed for threat hunting and to be a starting point for further investigation.
level: medium
tags:
    - attack.defense-evasion
    - attack.t1562
    - attack.t1562.007