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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/07/31"
  3integration = ["network_traffic"]
  4maturity = "production"
  5min_stack_comments = "Requires ES|QL JSON_EXTRACT on _source to read SIP fields across current and legacy schemas."
  6min_stack_version = "9.4.0"
  7updated_date = "2026/07/31"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Identifies repeated SIP REGISTER authentication rejection responses for one or more extensions from a client to a VoIP
 13server within five minutes. The rule distinguishes repeated failures from the single 401 or 407 challenge expected in a
 14normal digest-authentication flow. Attackers brute-force extension credentials to register rogue endpoints for toll
 15fraud, call interception, or registration hijacking.
 16"""
 17false_positives = [
 18    """
 19    Misconfigured phones, expired credentials, or provisioning errors can generate repeated REGISTER failures from a
 20    single device. Validate the client, affected extensions, and registration state before escalating.
 21    """,
 22]
 23from = "now-9m"
 24language = "esql"
 25license = "Elastic License v2"
 26max_signals = 5
 27name = "Potential SIP REGISTER Brute Force"
 28note = """## Triage and analysis
 29
 30### Investigating Potential SIP REGISTER Brute Force
 31
 32SIP 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.
 33
 34### Possible investigation steps
 35
 36- 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.
 37- Review `Esql.sample_extensions`, `Esql.total_failures`, and `Esql.max_failures_per_extension` to distinguish a targeted password attack from a broader extension spray.
 38- Review REGISTER requests corresponding to the rejection responses and confirm whether credentials were supplied after the initial digest challenge.
 39- 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.
 40- Inspect CDR/billing records for anomalous outbound calls if a registration succeeded.
 41
 42### False positive analysis
 43
 44- 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.
 45- 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.
 46
 47### Response and remediation
 48
 49- Block or rate-limit the offending `Esql.client_ip` at the SBC and enforce strong SIP credentials.
 50- Rotate compromised extension passwords and audit active registrations for rogue contact bindings.
 51- Enable geo-blocking or IP allowlists for REGISTER if the PBX is internal-only.
 52"""
 53references = ["https://attack.mitre.org/techniques/T1110/"]
 54risk_score = 47
 55rule_id = "1ca59146-7386-4033-a010-1c32717e9321"
 56setup = """## Setup
 57
 58This rule requires the Elastic **network_traffic** integration with the **SIP** protocol module enabled on a sensor that
 59observes VoIP REGISTER signaling to or from the PBX/SBC.
 60
 61The rule requires decoded SIP headers and responses. SIP over TLS (commonly TCP 5061) is not visible unless the sensor
 62receives decrypted traffic or observes plaintext SIP after TLS termination. SRTP encryption does not affect this rule
 63when SIP signaling remains visible.
 64"""
 65severity = "medium"
 66tags = [
 67    "Domain: Network",
 68    "Use Case: Threat Detection",
 69    "Use Case: Network Security Monitoring",
 70    "Tactic: Credential Access",
 71    "Data Source: Network Packet Capture",
 72    "Resources: Investigation Guide",
 73]
 74timestamp_override = "event.ingested"
 75type = "esql"
 76
 77query = '''
 78from logs-network_traffic.sip-*, packetbeat-* metadata _source
 79| eval
 80    Esql.method = TO_UPPER(COALESCE(
 81        JSON_EXTRACT(_source, "network_traffic.sip.cseq.method"),
 82        JSON_EXTRACT(_source, "sip.cseq.method"),
 83        JSON_EXTRACT(_source, "network_traffic.sip.method"),
 84        JSON_EXTRACT(_source, "sip.method")
 85    )),
 86    Esql.sip_type = TO_LOWER(COALESCE(
 87        JSON_EXTRACT(_source, "network_traffic.sip.type"),
 88        JSON_EXTRACT(_source, "sip.type")
 89    )),
 90    Esql.code = COALESCE(
 91        JSON_EXTRACT(_source, "network_traffic.sip.code"),
 92        JSON_EXTRACT(_source, "sip.code")
 93    ),
 94    Esql.client_ip = COALESCE(client.ip, destination.ip),
 95    Esql.server_ip = COALESCE(server.ip, source.ip),
 96    Esql.extension = COALESCE(
 97        JSON_EXTRACT(_source, "network_traffic.sip.to.uri.username"),
 98        JSON_EXTRACT(_source, "sip.to.uri.username")
 99    )
100| where
101    Esql.method == "REGISTER" and
102    Esql.sip_type == "response" and
103    Esql.code in ("401", "403", "407") and
104    Esql.client_ip is not null and
105    Esql.server_ip is not null and
106    Esql.extension is not null
107| eval Esql.time_window = DATE_TRUNC(5 minutes, @timestamp)
108| stats
109    Esql.failures_per_extension = COUNT(*)
110  by Esql.time_window, Esql.client_ip, Esql.server_ip, Esql.extension
111| eval Esql.repeated_extension = CASE(Esql.failures_per_extension >= 2, 1, 0)
112| stats
113    Esql.total_failures = SUM(Esql.failures_per_extension),
114    Esql.max_failures_per_extension = MAX(Esql.failures_per_extension),
115    Esql.distinct_extensions = COUNT_DISTINCT(Esql.extension),
116    Esql.repeated_extensions = SUM(Esql.repeated_extension),
117    Esql.sample_extensions = MV_SLICE(VALUES(Esql.extension), 0, 20)
118  by Esql.time_window, Esql.client_ip, Esql.server_ip
119| where
120    Esql.max_failures_per_extension >= 10 or
121    (
122      Esql.total_failures >= 25 and
123      Esql.distinct_extensions >= 5 and
124      Esql.repeated_extensions >= 5
125    )
126| keep Esql.*
127'''
128
129
130[[rule.threat]]
131framework = "MITRE ATT&CK"
132[[rule.threat.technique]]
133id = "T1110"
134name = "Brute Force"
135reference = "https://attack.mitre.org/techniques/T1110/"
136[[rule.threat.technique.subtechnique]]
137id = "T1110.001"
138name = "Password Guessing"
139reference = "https://attack.mitre.org/techniques/T1110/001/"
140
141[[rule.threat.technique.subtechnique]]
142id = "T1110.003"
143name = "Password Spraying"
144reference = "https://attack.mitre.org/techniques/T1110/003/"
145
146
147
148[rule.threat.tactic]
149id = "TA0006"
150name = "Credential Access"
151reference = "https://attack.mitre.org/tactics/TA0006/"
152
153[rule.alert_suppression]
154group_by = ["Esql.client_ip", "Esql.server_ip"]
155missing_fields_strategy = "suppress"
156
157[rule.alert_suppression.duration]
158unit = "h"
159value = 1

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

Related rules

to-top