Detection rules › Elastic
Potential SIP REGISTER Brute Force
Identifies repeated SIP REGISTER authentication rejection responses for one or more extensions from a client to a VoIP server within five minutes. The rule distinguishes repeated failures from the single 401 or 407 challenge expected in a normal digest-authentication flow. Attackers brute-force extension credentials to register rogue endpoints for toll fraud, call interception, or registration hijacking.
Known false positives
- Misconfigured phones, expired credentials, or provisioning errors can generate repeated REGISTER failures from a single device. Validate the client, affected extensions, and registration state before escalating.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Credential Access |
Rule body
[metadata]
creation_date = "2026/07/31"
integration = ["network_traffic"]
maturity = "production"
min_stack_comments = "Requires ES|QL JSON_EXTRACT on _source to read SIP fields across current and legacy schemas."
min_stack_version = "9.4.0"
updated_date = "2026/07/31"
[rule]
author = ["Elastic"]
description = """
Identifies repeated SIP REGISTER authentication rejection responses for one or more extensions from a client to a VoIP
server within five minutes. The rule distinguishes repeated failures from the single 401 or 407 challenge expected in a
normal digest-authentication flow. Attackers brute-force extension credentials to register rogue endpoints for toll
fraud, call interception, or registration hijacking.
"""
false_positives = [
"""
Misconfigured phones, expired credentials, or provisioning errors can generate repeated REGISTER failures from a
single device. Validate the client, affected extensions, and registration state before escalating.
""",
]
from = "now-9m"
language = "esql"
license = "Elastic License v2"
max_signals = 5
name = "Potential SIP REGISTER Brute Force"
note = """## Triage and analysis
### Investigating Potential SIP REGISTER Brute Force
SIP REGISTER authenticates endpoints to a PBX or SBC. Attackers iterate extensions and passwords, producing many 401 Unauthorized, 403 Forbidden, or 407 Proxy Authentication Required responses from one external or internal client. A single 401 or 407 challenge is expected during normal digest authentication, so this rule requires either ten failures for one extension or a broader spray affecting at least five repeatedly challenged extensions.
### Possible investigation steps
- Determine whether `Esql.client_ip` is an expected phone, gateway, proxy, or external attacker address and confirm that `Esql.server_ip` is the intended PBX or SBC.
- Review `Esql.sample_extensions`, `Esql.total_failures`, and `Esql.max_failures_per_extension` to distinguish a targeted password attack from a broader extension spray.
- Review REGISTER requests corresponding to the rejection responses and confirm whether credentials were supplied after the initial digest challenge.
- Check for a successful REGISTER (2xx response) from the same client and extension shortly after the burst. Multiple failures followed by success should be escalated as possible credential compromise.
- Inspect CDR/billing records for anomalous outbound calls if a registration succeeded.
### False positive analysis
- A single misconfigured phone repeatedly attempting REGISTER with a stale password can trigger the targeted-failure branch. Lower severity when only one extension is affected and the client maps to a known device.
- NAT gateways and SIP proxies can represent many legitimate phones behind one address. The rule requires repeated challenges per extension to reduce alerts caused by one normal digest challenge from each phone.
### Response and remediation
- Block or rate-limit the offending `Esql.client_ip` at the SBC and enforce strong SIP credentials.
- Rotate compromised extension passwords and audit active registrations for rogue contact bindings.
- Enable geo-blocking or IP allowlists for REGISTER if the PBX is internal-only.
"""
references = ["https://attack.mitre.org/techniques/T1110/"]
risk_score = 47
rule_id = "1ca59146-7386-4033-a010-1c32717e9321"
setup = """## Setup
This rule requires the Elastic **network_traffic** integration with the **SIP** protocol module enabled on a sensor that
observes VoIP REGISTER signaling to or from the PBX/SBC.
The rule requires decoded SIP headers and responses. SIP over TLS (commonly TCP 5061) is not visible unless the sensor
receives decrypted traffic or observes plaintext SIP after TLS termination. SRTP encryption does not affect this rule
when SIP signaling remains visible.
"""
severity = "medium"
tags = [
"Domain: Network",
"Use Case: Threat Detection",
"Use Case: Network Security Monitoring",
"Tactic: Credential Access",
"Data Source: Network Packet Capture",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"
query = '''
from logs-network_traffic.sip-*, packetbeat-* metadata _source
| eval
Esql.method = TO_UPPER(COALESCE(
JSON_EXTRACT(_source, "network_traffic.sip.cseq.method"),
JSON_EXTRACT(_source, "sip.cseq.method"),
JSON_EXTRACT(_source, "network_traffic.sip.method"),
JSON_EXTRACT(_source, "sip.method")
)),
Esql.sip_type = TO_LOWER(COALESCE(
JSON_EXTRACT(_source, "network_traffic.sip.type"),
JSON_EXTRACT(_source, "sip.type")
)),
Esql.code = COALESCE(
JSON_EXTRACT(_source, "network_traffic.sip.code"),
JSON_EXTRACT(_source, "sip.code")
),
Esql.client_ip = COALESCE(client.ip, destination.ip),
Esql.server_ip = COALESCE(server.ip, source.ip),
Esql.extension = COALESCE(
JSON_EXTRACT(_source, "network_traffic.sip.to.uri.username"),
JSON_EXTRACT(_source, "sip.to.uri.username")
)
| where
Esql.method == "REGISTER" and
Esql.sip_type == "response" and
Esql.code in ("401", "403", "407") and
Esql.client_ip is not null and
Esql.server_ip is not null and
Esql.extension is not null
| eval Esql.time_window = DATE_TRUNC(5 minutes, @timestamp)
| stats
Esql.failures_per_extension = COUNT(*)
by Esql.time_window, Esql.client_ip, Esql.server_ip, Esql.extension
| eval Esql.repeated_extension = CASE(Esql.failures_per_extension >= 2, 1, 0)
| stats
Esql.total_failures = SUM(Esql.failures_per_extension),
Esql.max_failures_per_extension = MAX(Esql.failures_per_extension),
Esql.distinct_extensions = COUNT_DISTINCT(Esql.extension),
Esql.repeated_extensions = SUM(Esql.repeated_extension),
Esql.sample_extensions = MV_SLICE(VALUES(Esql.extension), 0, 20)
by Esql.time_window, Esql.client_ip, Esql.server_ip
| where
Esql.max_failures_per_extension >= 10 or
(
Esql.total_failures >= 25 and
Esql.distinct_extensions >= 5 and
Esql.repeated_extensions >= 5
)
| keep Esql.*
'''
[[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.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.alert_suppression]
group_by = ["Esql.client_ip", "Esql.server_ip"]
missing_fields_strategy = "suppress"
[rule.alert_suppression.duration]
unit = "h"
value = 1
Stages and Predicates
Stage 1: from
from logs-network_traffic.sip-*, packetbeat-* metadata _source
Stage 2: eval
| eval
Esql.method = TO_UPPER(COALESCE(
JSON_EXTRACT(_source, "network_traffic.sip.cseq.method"),
JSON_EXTRACT(_source, "sip.cseq.method"),
JSON_EXTRACT(_source, "network_traffic.sip.method"),
JSON_EXTRACT(_source, "sip.method")
)),
Esql.sip_type = TO_LOWER(COALESCE(
JSON_EXTRACT(_source, "network_traffic.sip.type"),
JSON_EXTRACT(_source, "sip.type")
)),
Esql.code = COALESCE(
JSON_EXTRACT(_source, "network_traffic.sip.code"),
JSON_EXTRACT(_source, "sip.code")
),
Esql.client_ip = COALESCE(client.ip, destination.ip),
Esql.server_ip = COALESCE(server.ip, source.ip),
Esql.extension = COALESCE(
JSON_EXTRACT(_source, "network_traffic.sip.to.uri.username"),
JSON_EXTRACT(_source, "sip.to.uri.username")
)
Stage 3: where
| where
Esql.method == "REGISTER" and
Esql.sip_type == "response" and
Esql.code in ("401", "403", "407") and
Esql.client_ip is not null and
Esql.server_ip is not null and
Esql.extension is not null
Stage 4: eval
| eval Esql.time_window = DATE_TRUNC(5 minutes, @timestamp)
Stage 5: stats
| stats
Esql.failures_per_extension = COUNT(*)
by Esql.time_window, Esql.client_ip, Esql.server_ip, Esql.extension
Stage 6: eval
| eval Esql.repeated_extension = CASE(Esql.failures_per_extension >= 2, 1, 0)
Esql.repeated_extension =if
Esql.failures_per_extension >= 21else
0Stage 7: stats
| stats
Esql.total_failures = SUM(Esql.failures_per_extension),
Esql.max_failures_per_extension = MAX(Esql.failures_per_extension),
Esql.distinct_extensions = COUNT_DISTINCT(Esql.extension),
Esql.repeated_extensions = SUM(Esql.repeated_extension),
Esql.sample_extensions = MV_SLICE(VALUES(Esql.extension), 0, 20)
by Esql.time_window, Esql.client_ip, Esql.server_ip
Stage 8: where
| where
Esql.max_failures_per_extension >= 10 or
(
Esql.total_failures >= 25 and
Esql.distinct_extensions >= 5 and
Esql.repeated_extensions >= 5
)
Stage 9: keep
| keep Esql.*
Indicators
These rows show field, operator, and value matches.
Output fields
These fields are emitted when the rule matches.
| Field | Source |
|---|---|
Esql.* | KEEP Esql.* |