CVE-2023-4346

KNX Protocol Connection Authorization Option 1 Overly Restrictive Account Lockout (CVE-2023-4346)

Detects potential exploitation of CVE-2023-4346, an overly restrictive account lockout mechanism (CWE-645) in the KNX Association's KNX Protocol Connection Authorization Option 1 used in KNX building automation / ICS environments. The flaw allows an attacker to repeatedly attempt authorization against a KNX secure connection without being effectively locked out, enabling brute-force guessing of the connection authorization key/password used to gate access to building automation devices (HVAC, lighting, access control, alarm systems). This CVE is listed in CISA KEV and is subject to BOD 26-04 prioritized remediation timelines. Detection relies on identifying repeated failed KNX/IP secure authorization attempts from a single source against a KNX interface/gateway, or repeated connection requests bypassing expected lockout thresholds, observed via network telemetry, firewall/IDS logs, or KNXnet/IP gateway logs.

Vulnerability Intelligence

KEV — Known Exploited

What is CVE-2023-4346 KNX Protocol Connection Authorization Option 1 Overly Restrictive Account Lockout (CVE-2023-4346)?

KNX Protocol Connection Authorization Option 1 Overly Restrictive Account Lockout (CVE-2023-4346) (CVE-2023-4346) maps to the Initial Access and Credential Access and Lateral Movement and Impact tactics — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for KNX Protocol Connection Authorization Option 1 Overly Restrictive Account Lockout (CVE-2023-4346), covering the data sources and telemetry it touches: Firewall/IDS logs (CommonSecurityLog), Network flow logs, KNXnet/IP gateway syslog forwarded to Sentinel. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access Credential Access Lateral Movement Impact
Microsoft Sentinel / Defender
kusto
let threshold = 5;
let timeWindow = 5m;
CommonSecurityLog
| where DeviceVendor has "KNX" or Message has "KNXnet" or DestinationPort == 3671
| where Activity has_any ("AUTH_FAIL", "Connection Authorization", "CONNECT_REQUEST", "Secure Session")
| summarize AttemptCount = count(), Ports = make_set(DestinationPort), Devices = make_set(DestinationIP) by SourceIP, bin(TimeGenerated, timeWindow)
| where AttemptCount >= threshold
| project TimeGenerated, SourceIP, AttemptCount, Devices, Ports
| order by AttemptCount desc

Detects repeated KNX/IP secure connection authorization attempts from a single source IP within a short window, indicative of brute-force exploitation of the overly restrictive/ineffective account lockout mechanism in KNX Protocol Connection Authorization Option 1.

high severity medium confidence

Data Sources

Firewall/IDS logs (CommonSecurityLog) Network flow logs KNXnet/IP gateway syslog forwarded to Sentinel

Required Tables

CommonSecurityLog

False Positives

  • Legitimate ETS commissioning tool performing bulk device reconfiguration
  • Network scanning/asset discovery tools probing UDP/3671 as part of authorized ICS asset inventory
  • Building management system polling multiple KNX/IP gateways for health checks
  • Misconfigured client repeatedly reconnecting due to network instability rather than credential guessing

Sigma rule & cross-platform mapping

The detection logic for KNX Protocol Connection Authorization Option 1 Overly Restrictive Account Lockout (CVE-2023-4346) (CVE-2023-4346) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Simulate KNX/IP Connection Authorization Brute-Force (Linux)

    Expected signal: Repeated outbound UDP packets to port 3671 with short intervals, captured in network flow logs/firewall logs and (if forwarded) in KNX gateway connection logs as multiple CONNECT_REQUEST or authorization events from the same source IP.

  2. Test 2Simulate KNX/IP Connection Authorization Brute-Force (Windows)

    Expected signal: Windows Firewall/Defender network connection logs and network flow monitoring should show repeated outbound UDP/3671 connections to the lab gateway IP in rapid succession.

  3. Test 3Simulate KNX/IP Connection Authorization Brute-Force (macOS)

    Expected signal: Outbound UDP/3671 network connections logged by host firewall (pf) and any network monitoring taps, showing repeated authorization-style packets to the lab gateway within a short window.


Response Playbook

Triage

  1. Identify the source IP(s) generating repeated KNX/IP secure connection authorization attempts and correlate against known asset inventory to determine if the source is an authorized engineering workstation (e.g., running ETS) or unrecognized/external.
  2. Review KNXnet/IP gateway logs (if available) for the specific device ID(s)/individual addresses targeted and check whether any authorization attempts ultimately succeeded, indicating potential compromise rather than failed brute-force.
  3. Determine whether the affected KNX gateway/interface is reachable from outside the OT network segment (e.g., exposed to IT network, VPN, or internet) — this significantly raises exploitation likelihood given the KEV listing.
  4. Check gateway/firmware version against KNX Association advisories to confirm whether a patched firmware or mitigating configuration (e.g., disabling Connection Authorization Option 1, enabling stronger secure session limits) has been applied.

Containment

  1. If the source is unauthorized or external, block the offending source IP/segment at the OT firewall or network access control layer immediately.
  2. If the gateway is exposed beyond the intended OT segment, restrict network access to KNX/IP UDP/3671 to only trusted engineering workstations via ACLs/VLAN segmentation.
  3. Rotate KNX secure connection passwords/keys on the affected interface if there is any indication of successful unauthorized authorization.

Evidence Collection

  1. Export KNXnet/IP gateway authentication/connection logs covering the detection window, including source IPs, timestamps, and authorization outcomes.
  2. Capture full packet captures (PCAP) of UDP/3671 traffic to/from the affected gateway for offline analysis of the authorization attempt pattern.
  3. Collect firewall/IDS logs showing all traffic from the offending source IP to identify reconnaissance or lateral movement preceding the brute-force attempts.

Escalation Criteria

  • ! Escalate to the OT/ICS security team and building facilities stakeholders immediately if any authorization attempt against the KNX gateway succeeded from an unrecognized source, since this could grant control over physical building systems (HVAC, lighting, access control, alarms).
  • ! Escalate per CISA BOD 26-04 prioritization guidance if the affected KNX device is internet-facing or reachable from an untrusted network segment, given this CVE's KEV status and mandated remediation timelines.

Investigation Guide

Forensic Artifacts

  • > KNXnet/IP gateway authentication and connection logs (source IP, individual address, timestamp, success/failure)
  • > Network packet captures of UDP/3671 traffic showing repeated CONNECT_REQUEST/authorization frames
  • > Firewall/IDS session logs correlating source IPs with sustained connection attempts to the KNX gateway

Tuning Guidance

Baseline normal KNX/IP traffic patterns for each environment before enabling this detection in blocking/alerting mode, since ETS engineering tools and BMS polling can legitimately generate bursts of connection attempts. Start with a higher threshold (e.g., 10+ attempts in 5 minutes) in environments with active commissioning activity, and tune down toward 5 attempts once known-good sources (ETS workstations, BMS servers) are allowlisted or excluded. Prioritize alerting on sources external to the OT network segment, which carry substantially higher risk given this vulnerability's CISA KEV status.


Hunting Queries

Hunts for KNX gateways receiving an unusually high volume of connection attempts over a 1-hour window, potentially indicating sustained brute-force campaigns against the weak lockout mechanism across multiple sources.

Hunting — KQL
kql
CommonSecurityLog
| where DestinationPort == 3671
| summarize TotalAttempts=count(), DistinctSources=dcount(SourceIP) by DestinationIP, bin(TimeGenerated, 1h)
| where TotalAttempts > 20
| order by TotalAttempts desc
Hunting — SPL
spl
index=ics_network dest_port=3671
| bin _time span=1h
| stats count as total_attempts, dc(src_ip) as distinct_sources by dest_ip, _time
| where total_attempts > 20
| sort - total_attempts

Atomic Red Team Tests

Test 1 Simulate KNX/IP Connection Authorization Brute-Force (Linux)
linux

Uses a simple UDP flood script to simulate repeated connection authorization requests to a lab KNX/IP gateway simulator on port 3671, mimicking brute-force attempts against the weak lockout mechanism.

Command

bash
for i in $(seq 1 10); do printf '\x06\x10\x02\x05\x00\x06\x00\x00\x00\x00' | nc -u -w1 <lab_knx_gateway_ip> 3671; sleep 1; done

Cleanup

bash
No persistent state is created on the attacking host; no cleanup required beyond terminating any lingering nc processes with 'pkill nc' if the loop is interrupted.

Expected Telemetry

Repeated outbound UDP packets to port 3671 with short intervals, captured in network flow logs/firewall logs and (if forwarded) in KNX gateway connection logs as multiple CONNECT_REQUEST or authorization events from the same source IP.

Expected Detection

KQL/SPL rules summarizing connection authorization events by source IP over a 5-minute window should trigger once the attempt count reaches the configured threshold (default 5).

Test 2 Simulate KNX/IP Connection Authorization Brute-Force (Windows)
windows

Uses PowerShell to send repeated UDP packets simulating KNX/IP secure connection authorization requests to a lab KNX gateway simulator, testing detection of brute-force patterns.

Command

powershell
1..10 | ForEach-Object { $u=New-Object System.Net.Sockets.UdpClient; $b=[byte[]](0x06,0x10,0x02,0x05,0x00,0x06,0x00,0x00,0x00,0x00); $u.Send($b,$b.Length,'<lab_knx_gateway_ip>',3671); $u.Close(); Start-Sleep -Seconds 1 }

Cleanup

powershell
No persistent artifacts remain on the host; the UdpClient object is closed within the script loop.

Expected Telemetry

Windows Firewall/Defender network connection logs and network flow monitoring should show repeated outbound UDP/3671 connections to the lab gateway IP in rapid succession.

Expected Detection

Detection logic aggregating UDP/3671 connection attempts by source over a short time window should flag the host as exceeding the brute-force threshold.

Test 3 Simulate KNX/IP Connection Authorization Brute-Force (macOS)
macos

Uses a bash loop with nc to send repeated simulated KNX/IP authorization request packets to a lab gateway simulator, validating detection coverage on macOS-originated OT engineering workstations.

Command

bash
for i in $(seq 1 10); do printf '\x06\x10\x02\x05\x00\x06\x00\x00\x00\x00' | nc -u -w1 <lab_knx_gateway_ip> 3671; sleep 1; done

Cleanup

bash
No persistent state created; terminate any residual nc processes via 'pkill -f "nc -u"' if the loop is manually interrupted.

Expected Telemetry

Outbound UDP/3671 network connections logged by host firewall (pf) and any network monitoring taps, showing repeated authorization-style packets to the lab gateway within a short window.

Expected Detection

Aggregation-based detections (KQL/SPL/EQL) monitoring for repeated UDP/3671 connection attempts per source should alert once the attempt count crosses the configured brute-force threshold.

Related Detections