Gearbox

Detailed View

INFO GB-DISC-001 — Live Host Discovered

Description: A host was confirmed active on the network by responding to one or more probe types (ICMP, TCP SYN, ARP, or UDP), expanding the known attack surface.

Remediation: Reconcile all discovered hosts against the authorised asset inventory and investigate any unexpected or unregistered hosts.

INFO GB-DISC-002 — Open Port Discovered

Description: A TCP or UDP port was confirmed open on the target host, indicating an exposed service that contributes to the overall network attack surface.

Remediation: Inventory all open ports against expected service requirements; close or restrict access to ports that serve no legitimate business purpose via host-based or network firewall rules.

INFO GB-DISC-003 — Service Version Identified

Description: A specific software version was identified from a service banner or nmap version detection. This information can be cross-referenced against CVE databases to identify known vulnerabilities.

Remediation: Suppress version information where possible. Keep all identified services up to date.

INFO GB-DISC-004 — DHCP Lease Assigned to Device

Description: The device successfully obtained a DHCP lease from the gearbox DHCP server. The assigned IP address and MAC address are documented for the assessment.

Remediation: No action required; informational record.

HIGH GB-DISC-005 — LLMNR/NBT-NS Broadcast Poisoning Possible

Description: LLMNR and/or NBT-NS broadcast name resolution is active on the network, allowing an attacker to poison responses with Responder and capture NTLMv1/v2 hashes for offline cracking or relay.

Remediation: Disable LLMNR and NetBIOS-NS via Group Policy (Network > DNS Client) and enforce DNS-only name resolution across all hosts.

HIGH GB-DISC-006 — LLMNR/NBT-NS Broadcast Poisoning Possible

Description: LLMNR and/or NBT-NS broadcast name resolution is active on the network, allowing an attacker to poison responses with Responder and capture NTLMv1/v2 hashes for offline cracking or relay.

Remediation: Disable LLMNR and NetBIOS-NS via Group Policy (Network > DNS Client) and enforce DNS-only name resolution across all hosts.

CRITICAL GB-CRED-001 — NTLM Hash Captured via Responder

Description: Responder successfully captured an NTLMv1 or NTLMv2 challenge-response hash in response to a poisoned LLMNR/NBT-NS reply. The captured hash can be subjected to offline dictionary or brute-force cracking or used directly in NTLM relay attacks.

Remediation: Disable LLMNR and NBT-NS as described in GB-DISC-005/006. Enforce SMB signing. Implement network segmentation. Use strong, unique passwords resistant to offline cracking.

CRITICAL GB-CRED-002 — Cleartext Credentials in Traffic Capture

Description: Cleartext credentials (username/password) were observed in captured network traffic. The device transmitted authentication information over an unencrypted protocol (e.g., HTTP Basic Auth, FTP, Telnet, SNMP v1/v2c).

Remediation: Replace all cleartext authentication protocols with encrypted equivalents. Use TLS for web, SSH for remote management, SNMPv3 for SNMP.

CRITICAL GB-CRED-003 — Weak or Default Credentials Accepted

Description: The target accepted well-known default or factory-set credentials, granting unauthorised access.

Remediation: Replace all default credentials with strong, unique secrets and enforce a password policy prior to any deployment.

CRITICAL GB-VULN-001 — Nessus Critical Vulnerability

Description: Nessus Professional identified a critical severity vulnerability (CVSS ≥ 9.0). This typically represents unauthenticated remote code execution, authentication bypass with full system impact, or a well-known exploit with active weaponisation.

Remediation: Apply vendor patch immediately. If no patch is available, implement network isolation and document as an accepted risk with a defined remediation timeline.

HIGH GB-VULN-002 — Nessus High Vulnerability

Description: Nessus Professional identified a high severity vulnerability (CVSS 7.0–8.9). Often exploitable by local or adjacent attackers with limited prerequisites.

Remediation: Patch within the defined SLA for high-severity findings. Apply compensating controls if immediate patching is not feasible.

MEDIUM GB-VULN-003 — Nessus Medium Vulnerability

Description: Nessus Professional identified a medium severity vulnerability (CVSS 4.0–6.9). May require special conditions to exploit but presents meaningful risk.

Remediation: Schedule remediation within the standard patch cycle.

LOW GB-VULN-004 — Nessus Low / Informational Finding

Description: Nessus Professional identified a low-severity or informational finding. May represent configuration observations or version disclosures without direct exploitability.

Remediation: Include in routine hardening backlog.

HIGH GB-VULN-005 — CVE-Matched Service Banner

Description: The service banner matched a known CVE in the NVD or OSV.dev database. The software version identified in the banner is listed as affected by a publicly disclosed vulnerability with an available CVSS score.

Remediation: Update the affected software to a patched version. Cross-reference the specific CVE for vendor-recommended mitigations.

HIGH GB-VULN-006 — End-of-Life Software Detected

Description: A service banner or version string indicates software that has passed its vendor end-of-life date. No further security patches will be issued, and any future vulnerabilities will be permanently unaddressed.

Remediation: Upgrade to a supported version. If upgrade is constrained, apply network isolation and create a formal remediation plan.

HIGH GB-VULN-007 — End-of-Life Operating System Detected

Description: The operating system identified from banners or Nessus output has passed its vendor support end-of-life date. The OS will not receive security patches for newly discovered vulnerabilities.

Remediation: Upgrade to a supported OS version. If the device cannot be upgraded, implement network isolation as a compensating control.

HIGH GB-VULN-008 — Nuclei Template Match — CVE

Description: Nuclei matched a CVE-tagged template against the target. The response pattern confirms the service is exhibiting behaviour consistent with the disclosed vulnerability.

Remediation: Apply the vendor patch for the matched CVE. Verify remediation by re-running the nuclei scan.

MEDIUM GB-VULN-009 — Nuclei Template Match — Misconfiguration

Description: Nuclei identified a security misconfiguration (exposed admin panel, default path, misconfigured CORS, insecure HTTP method, etc.).

Remediation: Correct the specific misconfiguration. Harden the service configuration against the ProjectDiscovery misconfiguration template library.

HIGH GB-VULN-010 — Nuclei Template Match — Exposed Panel

Description: Nuclei identified an exposed administrative or management panel accessible without prior authentication (e.g., Grafana, Jenkins, Kibana, phpMyAdmin, device management UI).

Remediation: Restrict access to administrative panels by IP allowlist, VPN, or disable public access entirely.

HIGH GB-TLS-001 — SSL/TLS Certificate: Expired

Description: The server's TLS certificate has passed its expiry date, causing browser trust errors and indicating a breakdown in certificate lifecycle management.

Remediation: Renew the certificate immediately and implement automated renewal (e.g., ACME/Let's Encrypt) to prevent future expiry.

MEDIUM GB-TLS-002 — SSL/TLS Certificate: Self-Signed

Description: The server presented a self-signed TLS certificate that is not anchored to a publicly trusted CA, preventing clients from verifying the server's identity and enabling trivial MITM attacks.

Remediation: Replace self-signed certificates with certificates issued by a trusted CA; use ACME/Let's Encrypt for cost-free automation.

HIGH GB-TLS-003 — SSL/TLS — Protocol Version Below TLS 1.2

Description: TLS 1.0 or TLS 1.1 is accepted. These protocol versions are deprecated by RFC 8996 and vulnerable to BEAST, POODLE, and RC4 downgrade attacks.

Remediation: Disable TLS 1.0, TLS 1.1, and all SSL versions. Accept only TLS 1.2 and TLS 1.3.

MEDIUM GB-TLS-004 — SSL/TLS — Weak Cipher Suite Accepted

Description: The TLS server accepts cipher suites providing less than 128-bit security, null encryption, or anonymous key exchange.

Remediation: Configure the server to accept only AEAD cipher suites with forward secrecy (ECDHE-ECDSA-AES256-GCM-SHA384, TLS_CHACHA20_POLY1305_SHA256, etc.).

MEDIUM GB-TLS-005 — SSL/TLS — CRIME / BEAST / LUCKY13 Vulnerability

Description: The TLS configuration is susceptible to a compression-based oracle (CRIME), cipher-block chaining attack (BEAST), or timing side-channel (LUCKY13). Specific vulnerability depends on testssl.sh output.

Remediation: Disable TLS compression. Migrate to TLS 1.2+ with AES-GCM-only cipher suites. Apply server-side BEAST mitigation (RC4 disabled, prefer AES-GCM).

LOW GB-TLS-006 — SSL/TLS — Missing HSTS Header

Description: The HTTPS service does not return a Strict-Transport-Security header. Clients may be susceptible to SSL stripping attacks.

Remediation: Add Strict-Transport-Security: max-age=31536000; includeSubDomains; preload to all HTTPS responses.

MEDIUM GB-TLS-007 — SSL/TLS — Weak Certificate Signature Algorithm

Description: The TLS certificate is signed with a deprecated algorithm such as MD5 or SHA-1. These algorithms are vulnerable to collision attacks that could allow certificate forgery.

Remediation: Reissue the certificate using SHA-256 or SHA-384 as the signature algorithm.

MEDIUM GB-TLS-008 — SSL/TLS — Certificate Hostname Mismatch

Description: The Common Name or Subject Alternative Names in the TLS certificate do not match the host being connected to. Clients will receive a certificate warning or reject the connection.

Remediation: Reissue the certificate with the correct Subject Alternative Names matching all DNS names and IP addresses used to access the service.

MEDIUM GB-SSH-001 — SSH Weak Configuration (Ciphers / Legacy Protocol / Credential Auth)

Description: The SSH service is configured with one or more weaknesses including weak ciphers/MACs, SSHv1 support, permitted root login, or password-based authentication, increasing exposure to brute-force and protocol-level attacks.

Remediation: Harden sshd_config to disable SSHv1, restrict ciphers and MACs to strong algorithms, disable root login, disable password authentication, and require public-key authentication only.

HIGH GB-SSH-002 — SSH Weak Configuration (Ciphers / Legacy Protocol / Credential Auth)

Description: The SSH service is configured with one or more weaknesses including weak ciphers/MACs, SSHv1 support, permitted root login, or password-based authentication, increasing exposure to brute-force and protocol-level attacks.

Remediation: Harden sshd_config to disable SSHv1, restrict ciphers and MACs to strong algorithms, disable root login, disable password authentication, and require public-key authentication only.

MEDIUM GB-SSH-003 — SSH Weak Configuration (Ciphers / Legacy Protocol / Credential Auth)

Description: The SSH service is configured with one or more weaknesses including weak ciphers/MACs, SSHv1 support, permitted root login, or password-based authentication, increasing exposure to brute-force and protocol-level attacks.

Remediation: Harden sshd_config to disable SSHv1, restrict ciphers and MACs to strong algorithms, disable root login, disable password authentication, and require public-key authentication only.

MEDIUM GB-SSH-004 — SSH Weak Configuration (Ciphers / Legacy Protocol / Credential Auth)

Description: The SSH service is configured with one or more weaknesses including weak ciphers/MACs, SSHv1 support, permitted root login, or password-based authentication, increasing exposure to brute-force and protocol-level attacks.

Remediation: Harden sshd_config to disable SSHv1, restrict ciphers and MACs to strong algorithms, disable root login, disable password authentication, and require public-key authentication only.

MEDIUM GB-SSH-005 — SSH Weak Configuration (Ciphers / Legacy Protocol / Credential Auth)

Description: The SSH service is configured with one or more weaknesses including weak ciphers/MACs, SSHv1 support, permitted root login, or password-based authentication, increasing exposure to brute-force and protocol-level attacks.

Remediation: Harden sshd_config to disable SSHv1, restrict ciphers and MACs to strong algorithms, disable root login, disable password authentication, and require public-key authentication only.

HIGH GB-SMB-001 — SMB Signing Disabled or Not Required

Description: SMB packet signing is not enforced on the server, allowing an attacker positioned between client and server to relay or tamper with SMB authentication and data.

Remediation: Enable and require SMB signing via Group Policy (RequireSecuritySignature=1) on all Windows systems to prevent NTLM relay attacks.

CRITICAL GB-SMB-002 — SMB Share Accessible Without Authentication

Description: One or more SMB shares are accessible without valid credentials, allowing unauthenticated users to read or write files and potentially enumerate domain information.

Remediation: Require authentication on all SMB shares, disable null-session and guest access, and enforce least-privilege ACLs on every share.

CRITICAL GB-SMB-003 — SMB Share Accessible Without Authentication

Description: One or more SMB shares are accessible without valid credentials, allowing unauthenticated users to read or write files and potentially enumerate domain information.

Remediation: Require authentication on all SMB shares, disable null-session and guest access, and enforce least-privilege ACLs on every share.

CRITICAL GB-WEB-001 — Web — Default Credentials Accepted

Description: The web management interface accepted default manufacturer credentials. An attacker can gain full administrative access without any reconnaissance.

Remediation: Enforce mandatory credential change on first boot or provisioning. Implement account lockout after failed attempts.

MEDIUM GB-WEB-002 — Directory Listing Enabled

Description: The web server is configured to display a browsable directory index, exposing file structure and potentially sensitive files to unauthenticated users.

Remediation: Disable directory indexing (e.g., Options -Indexes in Apache; autoindex off in nginx) and ensure every directory contains an explicit index document.

LOW GB-WEB-003 — Web — Missing Security Headers

Description: One or more recommended HTTP security headers are absent: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.

Remediation: Add all recommended security headers to HTTP responses. Review shcheck output for the specific missing headers.

LOW GB-WEB-004 — Information Disclosure: Server Header

Description: The HTTP Server response header reveals the web server software name and version, reducing the attacker's reconnaissance effort needed to identify version-specific vulnerabilities.

Remediation: Remove or genericise the Server response header in the web server configuration (e.g., ServerTokens Prod in Apache; server_tokens off in nginx).

MEDIUM GB-WEB-005 — Web — HTTP Exposed (No HTTPS Redirect)

Description: The web application is accessible over plaintext HTTP and does not redirect to HTTPS. Credentials and session tokens transmitted over HTTP are observable to network attackers.

Remediation: Redirect all HTTP traffic to HTTPS. Enable HSTS to prevent downgrade attacks.

MEDIUM GB-WEB-006 — Web — Insecure Cookie Attributes

Description: Session or authentication cookies are missing the Secure, HttpOnly, or SameSite attributes. This exposes them to theft via JavaScript, plaintext transmission, or CSRF.

Remediation: Set Secure, HttpOnly, and SameSite=Strict (or Lax) attributes on all authentication and session cookies.

HIGH GB-NET-001 — Unencrypted Service: Telnet

Description: A Telnet service is accessible on the network, transmitting all data including authentication credentials in cleartext, enabling passive interception or active MITM attacks.

Remediation: Disable the Telnet daemon and replace it with SSH for all remote administration; block port 23 at the network perimeter.

HIGH GB-NET-002 — SNMP Default Community String Accepted

Description: The SNMP service accepts a well-known default community string (e.g., public/private), allowing unauthenticated read (and potentially write) access to device configuration data.

Remediation: Change all SNMP community strings to random high-entropy values, restrict SNMP access by source IP, and migrate to SNMPv3 with authentication and encryption.

HIGH GB-NET-003 — FTP Anonymous Login Permitted

Description: The FTP service accepts the anonymous username without credentials, potentially exposing hosted files or allowing unauthenticated file upload.

Remediation: Disable anonymous FTP in the server configuration; migrate file transfer to SFTP/FTPS and enforce authentication for all access.

HIGH GB-NET-004 — NFS World-Readable Export

Description: An NFS export is accessible to all hosts (wildcard * or 0.0.0.0/0 in /etc/exports). Any host on the network can mount and read the exported filesystem.

Remediation: Restrict NFS exports by client IP. Use root_squash and nosuid mount options. Disable NFS if not required.

MEDIUM GB-NET-005 — Deprecated or Weak Protocol in Use

Description: A deprecated or inherently weak network protocol was identified (e.g., RPC portmapper, rsh, rlogin, finger, X11 without auth, TFTP). These protocols provide no confidentiality or authentication.

Remediation: Disable deprecated protocol services. Replace with modern, authenticated, encrypted equivalents.

LOW GB-NET-006 — mDNS / Bonjour Service Announcement

Description: The device is broadcasting mDNS (Multicast DNS / Bonjour / Avahi) service announcements. These expose device capabilities, hostname, model information, and available services to all hosts on the local segment.

Remediation: Disable mDNS service announcement on production devices if not required for operation. Apply network segmentation to prevent mDNS traffic crossing boundaries.

HIGH GB-RFID-001 — RFID Card UID Captured

Description: Proxmark3 successfully read the UID of an RFID credential within range of the device reader. Systems relying solely on UID for access control are vulnerable to cloning attacks.

Remediation: Implement mutual authentication (MIFARE DESFire EV2/EV3 with AES). Do not rely on UID alone.

HIGH GB-RFID-002 — RFID Card Data Payload Read

Description: The RFID card data blocks were successfully read without authentication. Sensitive data stored in card memory (employee ID, access level, personal data) may be exposed.

Remediation: Enable sector access conditions on MIFARE Classic cards. Migrate to DESFire with application-level encryption.

CRITICAL GB-RFID-003 — RFID Replay Attack Successful

Description: A captured RFID credential was successfully replayed to the reader and accepted. No anti-replay protection is in place.

Remediation: Replace credential infrastructure with challenge-response or rolling code systems. Audit physical access logs for anomalous events.

HIGH GB-USB-001 — USB HID Keyboard Injection Accepted

Description: The device accepted keystroke injection from an emulated HID keyboard without any restriction or rate-limiting. A pre-programmed HID device can execute OS-level commands on device insertion.

Remediation: Implement USB HID device allowlisting. Disable USB HID enumeration on production devices where not required.

HIGH GB-USB-002 — USB Bash Bunny Payload Executed

Description: A Bash Bunny HID payload was executed by the device. The injected keystrokes were processed without restriction.

Remediation: Apply USB device policy and application whitelisting. Review autorun and HID handling in the OS.

MEDIUM GB-USB-003 — USB Abnormal Power Draw

Description: Abnormal USB power characteristics were detected, potentially indicating a rogue charging cable or peripheral with embedded circuitry.

Remediation: Deploy USB power-only data-blockers on charging ports. Restrict USB host mode to known-good peripherals.

MEDIUM GB-HW-001 — HDMI CEC Command Injection Accepted

Description: Injected HDMI CEC commands were accepted and processed. An attacker with HDMI port access can issue remote control commands or exploit CEC stack vulnerabilities.

Remediation: Disable CEC in firmware if not required. Apply command filtering to reject unauthorised CEC commands.

MEDIUM GB-HW-002 — HDMI HDCP Not Enforced

Description: HDCP content protection is not enforced on the HDMI interface. Video/audio streams can be captured in cleartext.

Remediation: Enable HDCP enforcement in device firmware.

MEDIUM GB-HW-003 — HDMI DDC-CI Unauthorised Control

Description: DDC-CI commands accepted over HDMI allow monitor control (brightness, OSD) without physical interaction with the display.

Remediation: Disable DDC-CI in display firmware if remote monitor control is not required.

INFO GB-HW-004 — EDID Information Disclosure

Description: EDID data was successfully read, disclosing monitor model, serial number, manufacturer, and capabilities.

Remediation: No action required if EDID is functioning normally. Consider custom EDID for high-security deployments.

HIGH GB-SERIAL-001 — Unauthenticated Serial Console

Description: A serial console (UART, RS-232) provided an interactive unauthenticated shell or bootloader prompt on connection.

Remediation: Password-protect the serial console in firmware. Disable UART console in production builds.

INFO GB-SERIAL-002 — Serial Console Baud Rate Identified

Description: The serial port baud rate was auto-detected. The presence and configuration of a serial console is documented.

Remediation: Review whether the console is accessible in production and restrict access if appropriate.

INFO GB-CAN-001 — CAN Bus Frame Captured

Description: CAN bus frames were captured from the device. Frame IDs and data payloads are documented for replay and fuzzing analysis.

Remediation: Ensure CAN bus access is physically restricted. Document observed frame IDs against expected device behaviour.

HIGH GB-CAN-002 — CAN Bus Injected Frame Accepted

Description: An injected CAN frame was accepted and processed by the device. CAN has no built-in authentication; any node on the bus can transmit arbitrary messages.

Remediation: Implement a CAN firewall or gateway. Consider SecOC (ISO 21434) for safety-critical systems. Apply physical access controls to CAN connectors.

HIGH GB-ZIGBEE-001 — Zigbee Traffic Captured

Description: Zigbee frames were captured from the device. Depending on the security profile, payloads may disclose network keys, sensor data, or command traffic.

Remediation: Enable Zigbee AES-128 network and link layer encryption (Zigbee 3.0). Rotate network keys periodically.

MEDIUM GB-ZIGBEE-002 — Zigbee Flooding / Denial of Service

Description: The Zigbee network showed signs of packet flooding tolerance (or lack thereof). Injection of excessive frames caused degraded responsiveness.

Remediation: Implement rate-limiting on Zigbee join and message handling. Apply Zigbee channel scanning and jamming detection.

INFO GB-CONF-001 — ARP / DHCP Traffic Reveals Network Configuration

Description: Passive ARP or DHCP traffic captured during the ConfigDiscovery phase revealed network configuration details: default gateway, DNS servers, existing DHCP leases, and VLAN membership.

Remediation: Informational — expected behaviour. Review whether observed network configuration aligns with intended design.

MEDIUM GB-CONF-002 — Plaintext Protocol in Boot Traffic

Description: Traffic captured during device boot revealed cleartext protocols (Telnet, HTTP, FTP, TFTP) carrying potentially sensitive data including configuration pulls or update checks.

Remediation: Replace plaintext boot-time protocols with TLS-protected equivalents. Use HTTPS for firmware update checks, SFTP for configuration retrieval.

MEDIUM GB-CONF-003 — Plaintext Protocol in Shutdown Traffic

Description: Traffic captured during device shutdown contained plaintext protocol traffic, potentially including final state synchronisation or credential exchange.

Remediation: Review and encrypt all shutdown-phase network communication.

CRITICAL GB-CAN-003 — CAN Replay Attack

Description: A previously captured CAN frame was successfully replayed and accepted as a legitimate message by one or more nodes on the bus. CAN provides no built-in authentication or sequence numbering, meaning any captured frame can be retransmitted at will to reproduce an action — such as unlocking a door, disabling a safety system, or triggering an actuator — without knowledge of the originating system. This class of attack is particularly dangerous in automotive and industrial control environments where CAN commands directly affect physical state.

Remediation: Implement SecOC (Secure Onboard Communication, ISO 21434 / AUTOSAR) for safety-critical CAN signals to add freshness counters and message authentication codes. Apply a CAN firewall or gateway to rate-limit and filter frames by ID and frequency. Physically restrict access to OBD-II ports and CAN bus connectors. Log and alert on unexpected frame repetition patterns.

MEDIUM GB-TLS-009 — SSL/TLS Vulnerability: BEAST

Description: The TLS server accepts TLS 1.0 connections using CBC (Cipher Block Chaining) cipher suites, making it susceptible to the BEAST (Browser Exploit Against SSL/TLS) attack. BEAST exploits a chosen-plaintext vulnerability in the way TLS 1.0 initialises IV values for CBC, allowing an attacker with MITM position and the ability to inject chosen plaintext to perform a blockwise chosen-boundary attack and recover session cookies or other short secrets. While practical exploitation requires both network position and JavaScript injection into the victim's browser, the condition is easily avoided by disabling TLS 1.0.

Remediation: Disable TLS 1.0 and TLS 1.1 on the server; accept only TLS 1.2 and TLS 1.3. Prefer AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) over CBC modes. If TLS 1.0 must remain enabled for legacy clients, configure server-side mitigation by preferring RC4 (deprecated) or — better — use TLS_FALLBACK_SCSV and enforce cipher order.

MEDIUM GB-TLS-010 — SSL/TLS Vulnerability: LUCKY13

Description: The TLS configuration accepts CBC cipher suites that are vulnerable to the LUCKY13 timing side-channel attack. LUCKY13 exploits a timing discrepancy in the MAC verification step of MAC-then-encrypt CBC cipher suites: the number of compression function calls differs based on where padding ends, allowing a statistical timing oracle to decrypt TLS records byte by byte. The attack requires many connections and precise timing measurements but has been demonstrated against real-world TLS stacks including OpenSSL.

Remediation: Migrate to TLS 1.3 or configure TLS 1.2 to use only AEAD cipher suites (AES-128-GCM, AES-256-GCM, CHACHA20-POLY1305), which do not use MAC-then-encrypt and are inherently immune to LUCKY13. Remove all CBC cipher suites from the server's cipher preference list.

MEDIUM GB-TLS-011 — SSL/TLS Vulnerability: SWEET32

Description: The TLS server negotiates cipher suites using 64-bit block ciphers such as 3DES (Triple-DES) or Blowfish, making it vulnerable to the SWEET32 birthday attack. After approximately 2^32 blocks (~32 GB of data over a single TLS session), the birthday bound is reached and an attacker can exploit block collisions in CBC mode to recover plaintext. While 32 GB may seem large, long-lived TLS sessions — such as those in web applications with keep-alive or WebSocket connections — can reach this volume in hours.

Remediation: Disable all 3DES and Blowfish cipher suites from the server configuration. Ensure no cipher suite using DES, 3DES, IDEA, or Blowfish appears in the negotiated cipher list. Prefer 128-bit or 256-bit block ciphers (AES-GCM). Upgrade to TLS 1.3 where possible to eliminate legacy cipher negotiation entirely.

LOW GB-TLS-012 — SSL/TLS Certificate: Expiring Soon

Description: The server's TLS certificate has a remaining validity of fewer than 30 days, placing it at imminent risk of expiry. Upon expiry, browser and client connections will be rejected with a certificate trust error, causing a service outage that appears indistinguishable from a site being down. In environments without automated certificate renewal, short expiry windows frequently result in user-facing downtime and may indicate a weak certificate lifecycle management process.

Remediation: Renew the certificate immediately to restore a full validity window. Implement automated certificate renewal using the ACME protocol (Let's Encrypt with certbot, acme.sh, or Caddy) to eliminate manual renewal dependency. Configure monitoring alerts when certificate expiry is within 30 and 14 days.

LOW GB-TLS-013 — SSL/TLS - Overly Long Certificate Expiry

Description: The TLS certificate has a validity period exceeding 398 days, in violation of the CA/Browser Forum baseline requirements adopted by all major browsers since September 2020. Certificates with excessively long lifetimes present elevated risk: compromised private keys or mis-issuance cannot be remediated without active revocation (which is poorly enforced by clients), and the certificate may outlive the cryptographic assumptions under which it was issued. Major browsers now hard-fail on certificates exceeding 398 days issued after the policy effective date.

Remediation: Reissue the certificate with a validity period of 398 days or fewer. Transition to automated ACME-based 90-day renewal (Let's Encrypt) to align with current CA/B Forum best practices and reduce reliance on long-lived credentials.

HIGH GB-NET-007 — FTP Bounce Attack Possible

Description: The FTP server accepts the PORT command with arbitrary destination IP addresses, enabling FTP bounce attacks. In a bounce attack, an attacker directs the FTP server to open a data connection to a third-party host on any specified port, effectively using the FTP server as a TCP proxy to port-scan internal hosts, bypass egress filtering, or connect to services that would otherwise reject connections from the attacker's source address. This technique can also be used to transfer files to or from third-party machines without direct connectivity.

Remediation: Configure the FTP server to reject PORT commands where the specified IP address does not match the client's source address (disable FTP bounce in daemon configuration). Consider migrating from FTP to SFTP or FTPS. Apply firewall rules to restrict outbound connections from the FTP server to known-good destination addresses.

HIGH GB-NET-008 — NFS Export Points Enumerated — Potentially Unauthenticated Access

Description: The NFS server responded to showmount queries, exposing a list of exported filesystem paths and their allowed client specifications. Depending on export configuration, an unauthenticated or low-privilege host on the network may be able to mount one or more of these exports and read or write files directly. Even read-only access to NFS exports can expose sensitive configuration files, SSH keys, or application data that facilitates further compromise.

Remediation: Restrict NFS exports to specific, authorised client IP addresses or subnets in /etc/exports; remove wildcard (*) or overly broad CIDR grants. Require Kerberos authentication (sec=krb5p) for sensitive exports. Disable the rpcbind/mountd showmount response if export enumeration by arbitrary clients is not required. Apply host-based and network firewall rules to limit NFS port access to authorised clients only.

HIGH GB-NET-009 — NFS Insecure Export Options

Description: One or more NFS exports are configured with insecure options that increase the risk of unauthorised access or privilege escalation. Common insecure settings include no_root_squash (which allows root on the client to act as root on the server), rw on broad CIDR ranges, no_all_squash, or insecure (allowing connections from non-privileged ports). A client with rw and no_root_squash access can write arbitrary files — including SUID binaries or SSH authorised_keys entries — that enable full host compromise.

Remediation: Audit /etc/exports and apply root_squash, all_squash, and nosuid to all exports. Remove no_root_squash unless there is a documented and approved use case. Prefer ro (read-only) where write access is not operationally required. Apply the most restrictive client specifier possible (explicit host or /32 CIDR).

HIGH GB-NET-010 — Industrial/OT Protocol Exposure

Description: An industrial or operational technology (OT) protocol was detected on the network, including but not limited to Modbus/TCP (502), BACnet/IP (47808), EtherNet/IP (44818), DNP3, or IEC 60870-5-104. These protocols were designed for deterministic, low-latency communication in isolated control environments and provide no authentication, integrity protection, or confidentiality. Exposure of these services to untrusted network segments allows an attacker to read sensor data, issue arbitrary control commands, or disrupt physical processes.

Remediation: Segment OT/ICS networks from corporate IT networks using firewalls or unidirectional security gateways (data diodes). Apply application-layer firewalls that understand industrial protocol specifics to whitelist expected command sets and source addresses. Disable unused protocol services on PLCs, RTUs, and HMIs. Monitor for anomalous command patterns.

MEDIUM GB-NET-011 — Unencrypted Protocol Detected

Description: A network service communicating over a cleartext protocol was identified, including one or more of: FTP (21), Telnet (23), HTTP (80), TFTP (69), rsh (514), rlogin (513), rexec (512), or finger (79). Cleartext protocols transmit all data — including authentication credentials, session tokens, and sensitive application data — in a form readable by any attacker with network access, whether via passive interception on a shared segment or an active man-in-the-middle position.

Remediation: Replace cleartext protocols with encrypted equivalents: SSH for remote administration, SFTP/FTPS for file transfer, HTTPS for web services, SNMPv3 for network management. If cleartext protocols cannot be immediately replaced, apply network segmentation and access control to limit exposure, and implement monitoring for credential interception.

LOW GB-WEB-007 — Missing Secure Cookie Attribute: HttpOnly

Description: A session or sensitive cookie was identified without the HttpOnly attribute. Without this flag, the cookie value is accessible to JavaScript running in the page context, making it directly extractable by any cross-site scripting (XSS) vulnerability on the same domain. An attacker who finds a reflected or stored XSS flaw can trivially read the session cookie via document.cookie and hijack the authenticated session without needing to exploit the TLS layer.

Remediation: Set the HttpOnly flag on all session, authentication, and sensitive cookies in the application or web server configuration. This flag prevents client-side scripts from accessing the cookie value while still allowing the browser to include it in HTTP requests.

LOW GB-WEB-008 — Missing Secure Cookie Attribute: Secure

Description: A session or sensitive cookie was identified without the Secure attribute. Without this flag, the browser will transmit the cookie over both HTTPS and plaintext HTTP connections. If the application supports or redirects through any HTTP endpoint — even briefly — the session cookie will be included in the cleartext request and is visible to network attackers. This condition is commonly exploited via SSL stripping attacks that downgrade HTTPS to HTTP before the Secure cookie check takes effect.

Remediation: Set the Secure flag on all session, authentication, and sensitive cookies. Combined with a site-wide HTTPS redirect and HSTS, this ensures cookies are never transmitted over unencrypted channels.

LOW GB-WEB-009 — Missing Secure Cookie Attribute: SameSite

Description: A session or sensitive cookie was identified without a SameSite attribute. Cookies without SameSite are sent by the browser in all cross-site requests, including those initiated by third-party web pages. This exposes the application to cross-site request forgery (CSRF) attacks, where an attacker's page silently makes authenticated requests to the target application using the victim's browser-stored session cookie, potentially triggering state-changing actions without user consent.

Remediation: Set SameSite=Strict for cookies used in purely same-origin contexts, or SameSite=Lax as a minimum to prevent cookie transmission in cross-origin subresource requests while allowing top-level navigations. Avoid SameSite=None unless the cookie must be shared in cross-site embedded contexts, in which case the Secure attribute is also mandatory.

LOW GB-WEB-010 — Misconfigured Secure Cookie Attribute: SameSite

Description: A session or sensitive cookie was identified with the SameSite attribute set to an insecure value. Setting SameSite=None without also setting the Secure attribute causes the cookie to be rejected by modern browsers or sent over HTTP, while SameSite=Lax may be insufficient for applications requiring CSRF protection on all state-changing requests that can be triggered via cross-origin navigations. Misconfigured SameSite values indicate an incomplete implementation of the cookie security policy.

Remediation: If SameSite=None is required for cross-site embedding, the Secure attribute must also be present. Evaluate whether SameSite=Strict is appropriate; if so, upgrade from Lax to Strict. Review all state-changing endpoints to confirm they are protected by either SameSite=Strict or an additional CSRF token mechanism.

CRITICAL GB-SERIAL-003 — Serial Port Allows Remote Access

Description: A serial console interface is accessible to an unauthenticated party via an exposed physical connector, a network-bridged serial server, or a serial-over-LAN (SOL) interface that is reachable from the assessment network. Remote serial access without authentication provides a root-level interactive session or bootloader prompt equivalent to physical presence at the device, bypassing all operating system access controls, disk encryption unlock prompts, and network-layer security.

Remediation: Password-protect the serial console in device firmware and configure an inactivity timeout. Disable network bridging of serial interfaces unless strictly required; if required, protect access with authenticated VPN and firewall rules. In production firmware builds, disable UART console output and bootloader access entirely or require a hardware-present jumper to unlock.

INFO GB-HW-005 — HDMI CEC Bus Device Enumeration

Description: HDMI CEC bus enumeration was performed and active devices on the CEC bus were successfully identified without any authentication requirement. Discovered information includes logical and physical addresses, device type (TV, playback device, audio system), vendor OUI, and OSD name strings. While this finding is informational, it establishes the device topology and may support more targeted CEC command injection or denial-of-service attacks.

Remediation: No immediate action required if CEC is a necessary product feature. Review whether CEC device information could aid targeted attack chains and consider disabling CEC in firmware for devices where it serves no operational purpose.

MEDIUM GB-HW-006 — DDC/CI Display Control Channel Accessible

Description: The DDC/CI (Display Data Channel Command Interface) channel over HDMI or DisplayPort is accessible and accepts control commands without authentication. An attacker with physical or software access to the video source can issue DDC/CI commands to adjust brightness, contrast, input selection, colour profiles, and power state of the connected display, or to read monitor asset information (MCCS capabilities). In environments with strict physical security requirements, uncontrolled display manipulation represents a tangible risk.

Remediation: Disable DDC/CI in display firmware or OSD settings where remote monitor control is not operationally required. Apply application-layer access controls to software DDC/CI tools (e.g., ddcutil on Linux). For high-security deployments, use video switches that do not forward DDC/CI signals.

CRITICAL GB-VULN-011 — Heartbleed (CVE-2014-0160) Vulnerability Detected

Description: The target is running a version of OpenSSL affected by CVE-2014-0160 (Heartbleed). The TLS heartbeat extension implementation in OpenSSL 1.0.1 through 1.0.1f fails to validate the length field in the heartbeat request, allowing an unauthenticated remote attacker to read up to 64 kilobytes of server memory per request without leaving a trace in standard access logs. Repeated requests allow an attacker to recover private TLS keys, session tokens, passwords, and other secrets from server memory over time.

Remediation: Upgrade OpenSSL to 1.0.1g or later (or 1.0.2 / 1.1.0+ for current branches). After patching, rotate all TLS private keys and certificates, revoke the old certificates, invalidate all active sessions, and reset any passwords that may have been in server memory during the exposure window. Verify remediation by re-running the Heartbleed check.

CRITICAL GB-CRED-004 — Cleartext Credentials Captured

Description: A username and password pair was observed in plaintext within captured network traffic. The credentials were transmitted over an unencrypted protocol such as HTTP Basic Authentication, FTP, Telnet, SMTP AUTH (without STARTTLS), or SNMP v1/v2c, and are fully recoverable without any cryptographic attack. Captured credentials may be valid for the target service, other systems on the network, VPN access, or cloud console login if the user has reused them.

Remediation: Immediately replace the protocol in use with an encrypted equivalent: HTTPS for web services, SSH for remote administration, SFTP/FTPS for file transfer, SMTPS or SMTP with enforced STARTTLS for mail. Rotate the captured credentials and investigate whether they are reused across other systems. Conduct a broader credential reuse assessment across the environment.

INFO GB-DISC-007 — Discovery: Hostname Identified

Description: A DNS hostname or NetBIOS name was resolved for a target IP address, providing a human-readable label for the host. Hostnames frequently encode information about the device's function, location, operating system, or network segment (e.g., dc01.corp.example.com, router-dmz-01, dev-sql-server). This information reduces the attacker's reconnaissance burden by allowing service correlation without port scanning and aids in target prioritisation during an assessment.

Remediation: Ensure DNS naming conventions do not disclose sensitive infrastructure details. Restrict reverse-DNS resolution (PTR records) for internal hosts from being accessible to external resolvers. Disable NetBIOS name service (NBT-NS) where not required.

INFO GB-001 — CEC Bus Devices Discoverable Without Authentication — {self.ctx.instance_key}

INFO GB-002 — CEC Devices Enumerated — {self.ctx.instance_key}

INFO GB-003 — CEC Power State Exposed — Unauthorised Control Possible — {self.ctx.instance_key}

INFO GB-004 — CEC Scan Complete — No Devices Responded — {self.ctx.instance_key}

INFO GB-005 — Cleartext Credential Captured — {user}

INFO GB-006 — Cleartext Credentials Captured — {user}

INFO GB-007 — DDC/CI Display Control Channel Accessible — {self.ctx.instance_key}

INFO GB-008 — DDC/CI Interface Accessible — {self.ctx.instance_key}

INFO GB-009 — Default Page Detected — {label} ({url})

INFO GB-010 — Default/Test Page Exposed — {label} at {url}

INFO GB-011 — Devices Discovered via DHCP — {self.ctx.instance_key}

INFO GB-012 — DHCP Leases Issued — {self.ctx.instance_key}

INFO GB-013 — Display Info Retrieved — {self.ctx.instance_key}

INFO GB-014 — EDID Data Retrieved — {self.ctx.instance_key}

INFO GB-015 — EDID Extension Blocks Present — {self.ctx.instance_key}

INFO GB-016 — Ethernet Link Detected — {self.ctx.instance_key}

INFO GB-017 — Ethernet Port Disabled — {self.ctx.instance_key}

INFO GB-018 — FTP Bounce Attack Possible — {ip}:{port}

INFO GB-019 — FTP Service Analysis — {ip}:{port}

INFO GB-020 — HDCP Negotiation Incomplete — {self.ctx.instance_key}

INFO GB-021 — HDCP Not Enforced — {self.ctx.instance_key}

INFO GB-022 — HDCP Status Not Readable — {self.ctx.instance_key}

INFO GB-023 — HDCP Status Read — {self.ctx.instance_key}

INFO GB-024 — HID Attack Device Executed Payload — {self.ctx.instance_key}

INFO GB-025 — Interesting Protocols Detected — {self.ctx.instance_key}

INFO GB-026 — Keyboard Shortcut Access — {self.ctx.instance_key}

INFO GB-027 — Local File Inclusion - {body}

INFO GB-028 — Local File Inclusion - {software}

INFO GB-029 — Missing Security Header: {_hdr}

INFO GB-030 — Missing Security Header: {header_name}

INFO GB-031 — Network Configuration Established — {self.ctx.instance_key}

INFO GB-032 — Network Configuration via DHCP — {self.ctx.instance_key}

INFO GB-033 — NFS Enumeration — {ip}

INFO GB-034 — NFS Insecure Export Options — {ip}

INFO GB-035 — NFS Share Exposed — {ip}

INFO GB-036 — Responder Capture Log — {self.ctx.instance_key}

INFO GB-037 — RFID Credential Replay Successful — {self.ctx.instance_key}

INFO GB-038 — RFID Scan Results — {self.ctx.instance_key}

INFO GB-039 — Robots.txt File Found ({fip}:{fprt})

INFO GB-040 — Screenshot Captured — {url}

INFO GB-041 — screenshot_{safe_tag}

INFO GB-042 — Security Headers Analysis — {url}

INFO GB-043 — Security Headers Check — {url}

INFO GB-044 — Service Banner — {ip}:{port} ({svc})

INFO GB-045 — SMB Service Analysis — {ip}:{port}

INFO GB-046 — SSH Audit — {ip}:{port}

INFO GB-047 — SSH Service Analysis — {ip}:{port}

INFO GB-048 — SSL Certificate Issuer — {issuer}

INFO GB-049 — SSL/TLS - {proto} Enabled

INFO GB-050 — SSL/TLS Assessment — {ip}:{port}

INFO GB-051 — TLS Certificate — {url}

INFO GB-052 — Traffic Capture — Boot Sequence ({self.ctx.instance_key})

INFO GB-053 — Traffic Capture — Running Operation ({self.ctx.instance_key})

INFO GB-054 — Traffic Capture — Shutdown Sequence ({self.ctx.instance_key})

INFO GB-055 — Unencrypted Protocol Detected: {_proto_name} — {_hip}:{_portid}

INFO GB-056 — USB HID Keyboard Accepted — {self.ctx.instance_key}

INFO GB-057 — USB Mass Storage Accepted — {self.ctx.instance_key}

INFO GB-058 — USB Mass Storage Partially Accepted — {self.ctx.instance_key}

INFO GB-059 — Web Assessment — {url}

INFO GB-060 — Web Links Extracted — {url}

INFO GB-061 — Web Spider Results — {url}

INFO GB-062 — Zigbee Device Susceptible to Flooding on {self.ctx.instance_key}

INFO GB-063 — __FP_SKIP__

INFO GB-064 — Certificate Hostname Mismatch

INFO GB-065 — Data Leakage: Serial Traffic Sniffable

INFO GB-066 — DB9 Port: No Active Protocol Detected —

INFO GB-067 — NTLMv2 Hash Captured via Responder

INFO GB-068 — Plaintext CAN Traffic Captured

INFO GB-069 — Responder Captured NTLMv1 Hashes

INFO GB-070 — screenshot

INFO GB-071 — Serial Port Responds to Commands —

INFO GB-BT-001 — Bluetooth Device Discovered

Description: A Bluetooth (BR/EDR or BLE) device was detected during zero-knowledge scanning, along with its advertising data (address, address type, RSSI, name, service UUIDs, manufacturer data).

Impact: Confirms a live wireless attack surface and provides the address and advertised metadata needed to target every subsequent enumeration, pairing, and exploitation test.

Remediation: Reconcile every discovered radio against the authorised asset inventory; disable or shield Bluetooth interfaces that are not required.

INFO GB-BT-002 — BLE GATT Service Enumerated

Description: The GATT server of a BLE device was enumerated without prior knowledge, revealing its services, characteristics, handles and properties (read/write/notify).

Impact: Discloses device function and defines the read/write/subscribe attack surface; unauthenticated enumeration is the first step toward characteristic abuse.

Remediation: Where the GATT layout itself is sensitive, require an encrypted, bonded link before service discovery is permitted.

INFO GB-BT-003 — Classic Bluetooth SDP Service Enumerated

Description: Classic Bluetooth (BR/EDR) SDP service records were enumerated (RFCOMM/L2CAP channels, profiles such as SPP/DUN/PAN).

Impact: Exposed SDP records widen the BR/EDR attack surface and can reveal legacy profiles (PAN/BNEP, DUN) with their own vulnerability history.

Remediation: Disable unused BR/EDR profiles; restrict SDP exposure and require authentication for sensitive services.

MEDIUM GB-BT-004 — Static or Public Bluetooth Address — Device Trackable

Description: The device advertises with a Public or Static-Random Bluetooth address that does not rotate, rather than a rotating Resolvable Private Address (RPA).

Impact: A stable address lets any passive listener track and correlate a body-worn or clinical device (and by extension a patient) across time and location, and leaks the OUI/vendor.

Remediation: Enable LE Privacy with frequently-rotating Resolvable Private Addresses; distribute the IRK only to bonded peers.

HIGH GB-BT-005 — Sensitive Identifier Broadcast in Advertising Data

Description: The device broadcasts a serial number, patient identifier, or other per-unit token in its advertising name or manufacturer-specific data, in the clear.

Impact: A stable unique identifier in advertising defeats address privacy (the string becomes the tracking key) and discloses asset/patient information to any passive listener in range.

Remediation: Remove serials and patient identifiers from the advertised device name and manufacturer data; expose per-unit IDs only via an authenticated, bonded GATT read; consider BT 5.4 Encrypted Advertising Data.

HIGH GB-BT-006 — Just Works Pairing — No MITM Protection

Description: The device negotiated Just Works pairing (SMP MITM-protection bit = 0, or an IO capability of NoInputNoOutput on either side), which provides no man-in-the-middle protection.

Impact: An active attacker in radio range can interpose during pairing and relay or modify the entire connection, because Just Works authenticates neither party.

Remediation: Provision real IO capability and set the MITM bit (LESC Numeric Comparison or Passkey Entry); where no IO exists, use OOB pairing or an app-layer authenticated channel.

NIST 800-53: IA-2, SC-8

HIGH GB-BT-007 — LE Legacy Pairing — Passively Decryptable

Description: The device negotiated LE Legacy pairing (SMP Secure Connections bit = 0). Legacy derives the session key from a weak Temporary Key (Just Works TK=0; Passkey Entry TK is a ~20-bit value).

Impact: A passively-sniffed pairing can be decrypted offline with crackle, recovering the Long-Term Key and all past and future bonded traffic for that pair.

Remediation: Require LE Secure Connections (ECDH P-256); reject SC=0 on any hardware that supports LESC (BLE 4.2+).

NIST 800-53: SC-8, SC-13

HIGH GB-BT-008 — Static or Reused BLE Passkey

Description: The device authenticates LE Secure Connections pairing with a static or reused 6-digit passkey — printed on the enclosure, embedded in firmware/manual, or identical across units — rather than a fresh random per-pairing value.

Impact: A hard-coded or shared passkey defeats the MITM protection of LESC Passkey Entry: anyone who can read the printed/documented value can complete an authenticated man-in-the-middle relay, reducing LESC to Just Works in practice.

Remediation: Use a fresh, random, per-pairing passkey that is never hard-coded, printed, or reused across units; prefer Numeric Comparison or OOB where the UI allows.

NIST 800-53: IA-5

HIGH GB-BT-009 — Bluetooth Pairing Method Confusion

Description: A man-in-the-middle can negotiate Numeric Comparison with one device and Passkey Entry with the other in the same ceremony; both use a 6-digit value, so the user reads the number one device shows and enters it into the other, completing a stable MITM even under LESC.

Impact: Defeats the highest LESC/MITM security level via the human factor (CERT VU#534195): the attacker holds a persistent interposed position while both devices report a successful pairing.

Remediation: Pin the negotiated association model, present an unambiguous 'enter' vs 'compare' UI, and prefer OOB pairing.

HIGH GB-BT-010 — Bluetooth Pairing Security Downgrade Accepted

Description: The device completed pairing after a forced downgrade offer (Secure Connections cleared, IO capability set to NoInputNoOutput, and/or a reduced key size), instead of aborting.

Impact: A device that silently accepts SC=0 / Just Works / a short key when it can support stronger security is exploitable via an active downgrade man-in-the-middle in range.

Remediation: Enforce a security floor (SC=1, MITM for sensitive functions, 16-byte key) and abort pairing on any weaker offer; re-verify the negotiated level before exposing sensitive GATT.

NIST 800-53: SC-8, IA-2

HIGH GB-BT-011 — Short Bluetooth Encryption Key Negotiated

Description: The device negotiated a maximum encryption key size below 16 bytes (BLE floor is 7). Short keys reduce brute-force cost and are the BLE analogue of the KNOB attack.

Impact: A negotiated key near the 7-byte floor allows an attacker to brute-force the session key and decrypt or inject traffic.

Remediation: Enforce a 16-byte encryption key floor and abort pairing/connection on any shorter negotiated size.

NIST 800-53: SC-12, SC-13

MEDIUM GB-BT-012 — Bluetooth ECDH Public Key Not Validated (CVE-2018-5383)

Description: The pairing stack does not validate the peer's ECDH public key (Y-coordinate) during Secure Simple Pairing / LE Secure Connections, allowing a fixed-coordinate invalid-curve attack.

Impact: An in-range MITM present during pairing can force the shared secret into a small subgroup and recover the session key (~50% per attempt, retryable), fully compromising the session.

Remediation: Update to post-2018 firmware/OS that mandates ECDH public-key on-curve validation.

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

HIGH GB-BT-013 — KNOB — Bluetooth Encryption Key Entropy Downgrade (CVE-2019-9506)

Description: The BR/EDR encryption key-entropy negotiation (LMP) is not integrity-protected, letting a MITM force both devices to a 1-byte (8-bit) key.

Impact: The reduced-entropy key is brute-forced in real time, allowing an in-range attacker with no pairing or user interaction to decrypt and inject traffic on the link.

Remediation: Patch the host to enforce a minimum encryption key entropy (>=7 octets BR/EDR, 16 for LESC) and abort shorter negotiations.

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

HIGH GB-BT-014 — BLUFFS — Bluetooth Forward/Future Secrecy Weakness (CVE-2023-24023)

Description: Weaknesses in BR/EDR session-key derivation (Core Spec 4.2-5.4) permit unilateral, repeatable session-key derivation, breaking forward and future secrecy; combined with key-length downgrade it enables MITM and impersonation across sessions.

Impact: An in-range attacker can force reuse of a weak session key, decrypting captured traffic and impersonating a device across multiple sessions.

Remediation: Reject low negotiated key lengths, adopt the SIG key-derivation fix, and operate in Secure Connections Only mode.

HIGH GB-BT-015 — BIAS — Bluetooth Impersonation (CVE-2020-10135)

Description: BR/EDR authentication does not mandate mutual authentication; via role-switch and SC-to-legacy downgrade an attacker impersonates a previously-paired master or slave without possessing the link key.

Impact: An attacker in range who knows the victim BD_ADDR can impersonate a trusted, previously-bonded device without any key material.

Remediation: Enable Secure Connections Only mode and require mutual authentication in both directions.

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

MEDIUM GB-BT-016 — BLURtooth — Cross-Transport Key Overwrite (CVE-2020-15802)

Description: In dual-mode devices supporting Cross-Transport Key Derivation (spec 4.2/5.0 before 5.1), an unauthenticated attacker in range can trigger CTKD to overwrite an authenticated bonding key with an unauthenticated or lower-entropy one.

Impact: The paired relationship can be silently weakened without user interaction, enabling MITM on a link the user believes is securely bonded.

Remediation: Apply BT 5.1 CTKD restrictions that forbid overwriting authenticated keys or downgrading key strength.

HIGH GB-BT-017 — BLESA — BLE Reconnection Spoofing (CVE-2020-9770)

Description: BLE reconnection authentication is optional and often not enforced by the client, so a central accepts spoofed data from an impersonated peripheral without re-authentication after the first bonding.

Impact: An attacker spoofing the peripheral BD_ADDR can feed forged data (e.g. medical telemetry) to the consuming device on reconnect, with no user interaction.

Remediation: Enforce mandatory authenticated and encrypted reconnection before accepting any data from a previously-bonded peer.

HIGH GB-BT-018 — Unauthenticated GATT Characteristic Read

Description: One or more GATT characteristics returned data over an unpaired, unencrypted link (ATT Read Response with a value and no 0x05/0x0F/0x08 security error).

Impact: Any listener in range can read the exposed data with no credential; where it is PHI, telemetry, or configuration the confidentiality impact is severe.

Remediation: Set encryption/authentication-required permissions on sensitive characteristics; gate PHI behind LESC-authenticated bonding.

OWASP API: API1:2023 Broken Object Level Authorization

NIST 800-53: AC-3, SC-8

CRITICAL GB-BT-019 — Unauthenticated GATT Characteristic Write

Description: A GATT write to a device characteristic succeeded over an unpaired, unencrypted link (ATT Write Response with no security error).

Impact: Unauthenticated write access permits configuration change, actuation, factory reset, or firmware/OTA abuse with no credential — the highest-impact GATT finding, and safety-critical on a medical device.

Remediation: Require an authenticated, encrypted, bonded link (LESC + MITM) for all writes; add application-layer authorization (signed / challenge-response commands) to control points and OTA.

Effort: Moderate

OWASP API: API5:2023 Broken Function Level Authorization

NIST 800-53: AC-3, SI-10, SC-8

HIGH GB-BT-020 — Unauthenticated GATT Notification/Indication Stream

Description: On an unpaired link the device granted a large ATT MTU and started notifications/indications after a CCCD write, streaming data without authentication.

Impact: Sensitive telemetry or PHI is exposed to any in-range listener without pairing; a large pre-auth MTU on a sensitive stream aggravates the leak.

Remediation: Require encryption on the CCCD and its source characteristic; do not start notifications before authenticated bonding.

NIST 800-53: AC-3, SC-8

HIGH GB-BT-021 — SweynTooth BLE SoC Vulnerability Surface

Description: The device's BLE System-on-Chip belongs to a vendor/part with known SweynTooth firmware vulnerabilities in the Link Layer, L2CAP, SMP or ATT (crash, deadlock, or the Telink Zero-LTK Installation security bypass).

Impact: Depending on the SoC and SDK version, an in-range attacker can crash or deadlock the device (DoS, may require power-cycle) or, on affected Telink parts, install an all-zero LTK for arbitrary read/write — safety-relevant per FDA/CISA advisory ICS-ALERT-20-063-01.

Remediation: Update the BLE controller firmware/SDK to a patched release; where the SoC is end-of-life, apply architectural mitigations (restrict pairing, disable unused profiles, physical/RF controls).

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

HIGH GB-BT-022 — BrakTooth BR/EDR SoC Vulnerability Surface

Description: The device's BR/EDR System-on-Chip belongs to a vendor/part with known BrakTooth LMP/Baseband vulnerabilities (V1-V16), ranging from crashes and deadlocks to Espressif ESP32 arbitrary code execution.

Impact: An in-range attacker can crash, deadlock, or (on ESP32) execute code on the controller; several affected parts (e.g. TI CC2564C, Qualcomm CSR8811/8510) were 'no fix planned', leaving only architectural mitigation.

Remediation: Update the Bluetooth controller firmware to a patched release; for end-of-life SoCs, disable unused profiles, restrict connectability, and apply physical/RF controls.

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

HIGH GB-BT-023 — BleedingTooth Linux BlueZ Kernel Vulnerability Surface

Description: The Linux host behind the Bluetooth controller runs an unpatched BlueZ kernel (< 5.9), exposing the BleedingTooth family: BadKarma (L2CAP heap type-confusion), BadChoice (info leak), BadVibes (BLE ext-advertising heap overflow).

Impact: BadKarma chains to zero-click kernel remote code execution over BR/EDR from radio range; BadVibes needs only that the victim is scanning, with no BD_ADDR required.

Remediation: Patch the kernel to 5.9+ (or vendor backport); set CONFIG_BT_HS=n to remove the A2MP path; rfkill unused radios.

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

HIGH GB-BT-024 — BlueBorne Bluetooth Stack Vulnerability Surface

Description: The host Bluetooth stack (Linux BlueZ, Android, Windows, or old iOS) predates the 2017 BlueBorne patches, exposing SDP/BNEP/L2CAP flaws that require only that Bluetooth is powered on.

Impact: An attacker in range can achieve remote code execution or MITM with no pairing and no user interaction; 'non-discoverable' is not a mitigation because the address is recoverable by sniffing.

Remediation: Apply the 2017-09+ vendor security patches; disable Bluetooth when unused.

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

INFO GB-BT-025 — LE Secure Connections Confirmed (Passively Uncrackable)

Description: The device completed LE Secure Connections pairing (ECDH P-256), confirmed on the wire by the Pairing Public Key / DHKey Check PDUs and/or a crackle result of 'LE Secure Connections'.

Impact: Positive assurance that the session key never crosses the air and the pairing is not passively crackable; residual risk shifts to implementation flaws (static passkey, debug keys, downgrade acceptance).

Remediation: Maintain LESC; additionally verify per-pairing random passkeys, no debug keys, and rejection of downgrade offers.

MEDIUM GB-BT-026 — BlueSmack / L2CAP Echo Denial of Service

Description: The device degraded or reset under a bounded L2CAP echo / l2ping flood (BlueSmack), indicating it does not bound or rate-limit oversized echo requests.

Impact: An in-range attacker who knows the BD_ADDR can hang or reboot the device, denying service — critical for a safety or clinical device.

Remediation: Patch the stack for input-length validation; rate-limit/throttle L2CAP echo and connection requests; make the radio non-connectable when unused.

NIST 800-53: SC-5

MEDIUM GB-BT-027 — Bluetooth Connection Exhaustion / l2ping Flood

Description: Rapid L2CAP/ACL connection opens or a sustained l2ping flood exhausted the device's connection slots, causing it to refuse or reset connections.

Impact: An in-range attacker can deny service to legitimate centrals by consuming all available connection resources.

Remediation: Rate-limit inbound connection requests, cap concurrent connections, and recover gracefully; make the radio non-connectable when idle.

NIST 800-53: SC-5

HIGH GB-BT-028 — Bluetooth Link-Layer Malformed-PDU Crash

Description: The device crashed or deadlocked when sent a malformed Link-Layer / HCI PDU (the generic class covering SweynTooth/BrakTooth-style firmware defects and Android BlueFrag CVE-2020-0022).

Impact: A malformed advertising/connect/control PDU — often broadcast with no BD_ADDR required — crashes the target and can escalate to remote code execution on vulnerable stacks.

Remediation: Update controller firmware and host stack (PDU length/format validation, buffer bounding); disable unused profiles; rate-limit.

INFO GB-BT-029 — Bluetooth Testing SKIPPED — No Adapter or Sniffer Available

Description: No Bluetooth adapter or sniffer was selected/available for the instance, so Bluetooth/BLE testing was not performed.

Impact: The Bluetooth attack surface of the device was not assessed; the absence of findings does not indicate the interface is secure.

Remediation: Attach a BlueZ adapter for active GATT/pairing work, or flash a sniffer board via Quiver (Sniffle / nRF Sniffer / ButteRFly / Ubertooth) for passive capture, then re-run the module.

INFO GB-WIFI-001 — Wi-Fi Network Discovered

Description: An 802.11 access point was detected during zero-knowledge scanning, along with its beacon/RSN metadata (SSID, BSSID, channel, privacy/cipher/AKM suites, associated clients).

Impact: Confirms a live wireless attack surface and provides the BSSID, channel and encryption details needed to target every subsequent per-AP encryption, WPS, PMKID/handshake, PMF and evil-twin test.

Remediation: Reconcile every discovered SSID/BSSID against the authorised wireless inventory; disable or shield any access point or wireless interface that is not required for the device under test.

Effort: Easy

MITRE ATT&CK: T1595 (Reconnaissance)

NIST 800-53: CM-8, SI-4

PCI DSS 4: 11.2.1

HIGH GB-WIFI-002 — Open Wi-Fi Network — No Encryption

Description: The access point provides no link-layer encryption (open authentication). All frames to and from associated devices are transmitted in cleartext.

Impact: Any listener in radio range can passively read all traffic and actively inject or modify frames, capturing PHI/telemetry and hijacking sessions without any credential.

Remediation: Deploy WPA3-SAE (or at minimum WPA2-CCMP/Enterprise) with 802.11w PMF required; never operate a medical or clinical device on an open SSID.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

MITRE ATT&CK: T1040 (Credential Access)

NIST 800-53: SC-8, SC-13, AC-18

PCI DSS 4: 4.2.1, 2.2.7

CRITICAL GB-WIFI-003 — WEP Encryption in Use

Description: The access point uses WEP, a cryptographically broken cipher whose RC4/IV key can be recovered from captured traffic using statistical (PTW), chopchop, or fragmentation attacks.

Impact: An attacker can recover the WEP key in minutes from ordinary captured traffic, then decrypt all traffic and join the network — a total loss of confidentiality, integrity, and access control.

Remediation: Immediately replace WEP with WPA3-SAE (or WPA2-CCMP with a strong passphrase) and 802.11w PMF; WEP has no secure configuration and must be decommissioned.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

MITRE ATT&CK: T1040 (Credential Access)

NIST 800-53: SC-13, SC-8, AC-18

PCI DSS 4: 4.2.1, 2.2.7

MEDIUM GB-WIFI-004 — WPA/WPA2-PSK Handshake Capturable

Description: The WPA/WPA2-PSK 4-way EAPOL handshake was captured (passively, or after a bounded deauth), providing a verifiable offline oracle for the pre-shared key.

Impact: The captured handshake can be attacked offline at full GPU speed with dictionaries and rules; a weak, default, or reused passphrase is recovered, granting full access to the wireless network.

Remediation: Use a long (>15 char) random WPA passphrase or migrate to WPA3-SAE, which resists offline handshake cracking; require 802.11w PMF to raise the cost of forcing a re-handshake.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

MITRE ATT&CK: T1110.002 (Credential Access)

NIST 800-53: IA-5, SC-13, AC-18

PCI DSS 4: 2.2.7, 8.3.6

MEDIUM GB-WIFI-005 — WPA PMKID Capturable (Clientless)

Description: An RSN PMKID was solicited and captured from the AP with a single association request and no connected client (hcxdumptool -> hcxpcapngtool, hashcat mode 22000).

Impact: Because the PMKID is derived from the PMK, the WPA/WPA2-PSK passphrase can be recovered offline without ever capturing a client handshake; a weak or default passphrase is trivially cracked, granting full network access.

Remediation: Use a long random WPA passphrase or migrate to WPA3-SAE (not PMKID-crackable); disable PMKID/OKC caching on the AP where the platform allows.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

MITRE ATT&CK: T1110.002 (Credential Access)

NIST 800-53: IA-5, SC-13, AC-18

PCI DSS 4: 2.2.7, 8.3.6

MEDIUM GB-WIFI-006 — WPS Enabled

Description: The access point advertises Wi-Fi Protected Setup. The 8-digit registrar PIN is validated in two independently-checkable halves, collapsing the effective keyspace to roughly 11,000 attempts.

Impact: An attacker can brute-force the WPS PIN online (hours) and recover the WPA passphrase regardless of its strength, unless the AP enforces a robust failed-attempt lockout.

Remediation: Disable WPS entirely (external-registrar and PIN methods). If push-button is operationally required, ensure the PIN method is off and an AP-side lockout throttles failed registrar attempts.

Effort: Easy

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

MITRE ATT&CK: T1110 (Credential Access)

NIST 800-53: AC-18, IA-2, CM-7

PCI DSS 4: 2.2.7, 8.3.6

HIGH GB-WIFI-007 — WPS Pixie-Dust Vulnerable

Description: The WPS registrar generates predictable/low-entropy E-S1/E-S2 Diffie-Hellman nonces, allowing the WPS PIN to be recovered offline from a single M1-M3 exchange (the pixie-dust attack).

Impact: The WPS PIN — and therefore the WPA passphrase — is recovered offline in seconds with no online guessing, granting full network access regardless of passphrase strength.

Remediation: Disable WPS entirely; the underlying nonce-generation weakness cannot be configured away. Rotate the WPA passphrase after disabling, as it must be considered compromised.

Effort: Easy

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

MITRE ATT&CK: T1110 (Credential Access)

NIST 800-53: AC-18, IA-2, SC-13

PCI DSS 4: 2.2.7, 8.3.6

MEDIUM GB-WIFI-008 — Missing 802.11w Management Frame Protection

Description: The network does not require 802.11w Management Frame Protection (the MFPR bit is clear in the RSN capabilities), so deauthentication and disassociation frames are unauthenticated.

Impact: An in-range attacker can forge management frames to evict clients on demand (availability loss) and force EAPOL re-handshakes for offline PSK cracking — a reliable DoS and handshake-harvesting primitive against a wireless-dependent device.

Remediation: Set Protected Management Frames to 'required' (802.11w MFPR) on the AP and device; WPA3-SAE mandates PMF. Where clients cannot support it, at minimum enable PMF-capable and prioritise a WPA3 migration.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

MITRE ATT&CK: T1498 (Impact)

NIST 800-53: SC-5, AC-18, SC-8

PCI DSS 4: 2.2.7

MEDIUM GB-WIFI-009 — WPA3 Transition Mode Downgrade

Description: The AP advertises WPA3 in transition (mixed) mode, offering both SAE (WPA3) and PSK (WPA2) AKM suites on the same SSID.

Impact: A rogue AP advertising only WPA2-PSK forces a supplicant to fall back to the crackable WPA2 4-way handshake (Dragonblood transition-mode downgrade); the SAE upgrade provides no protection while WPA2 fallback is accepted.

Remediation: Move to WPA3-only (SAE) mode with PMF required once all clients support it; disable the WPA2 transition fallback for sensitive networks so a downgraded handshake cannot be solicited.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

MITRE ATT&CK: T1557 (Credential Access)

NIST 800-53: SC-13, AC-18, SC-8

PCI DSS 4: 2.2.7, 4.2.1

HIGH GB-WIFI-010 — Rogue Access Point / Evil Twin Feasible

Description: The device under test associated with a rogue access point cloning the target SSID (optionally PMF-less / WPA2-only) instead of authenticating the genuine AP.

Impact: Without server-certificate validation, PMF, or mutually-authenticated association, an evil twin in range captures the device onto an attacker-controlled network to intercept and modify its traffic and harvest credentials (captive-portal or EAP relay).

Remediation: Require WPA3-SAE with PMF (mutual authentication), or for Enterprise validate the RADIUS server certificate and pin the CA on the client so a rogue AP cannot complete association.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

MITRE ATT&CK: T1557 (Credential Access)

NIST 800-53: AC-18, IA-3, SC-8

PCI DSS 4: 11.2.1, 2.2.7

MEDIUM GB-WIFI-011 — Wi-Fi Deauthentication Denial of Service

Description: A bounded burst of forged deauthentication/disassociation frames disconnected the device under test from its network, confirming that unauthenticated management frames are honoured (no 802.11w PMF required).

Impact: Any in-range attacker can persistently deny the wireless-dependent device network connectivity by spoofing management frames — a serious availability risk for a medical or clinical device that relies on wireless data or control.

Remediation: Enable 802.11w Protected Management Frames as REQUIRED (mandatory under WPA3-SAE) so forged deauth/disassoc frames are rejected; add wired or failover connectivity for safety-critical functions.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

MITRE ATT&CK: T1498 (Impact)

NIST 800-53: SC-5, AC-18

PCI DSS 4: 2.2.7

INFO GB-WIFI-012 — Wi-Fi Testing SKIPPED — No Wireless Adapter or Toolkit Available

Description: 802.11 testing was not performed for this instance because no monitor-mode adapter was selected, a non-capture device (e.g. WiFi Duck) was selected, or the aircrack-ng suite was not installed.

Impact: The device's wireless attack surface was not assessed; open/WEP encryption, WPS/pixie-dust, capturable handshakes/PMKID, missing PMF, and evil-twin exposure remain unverified until the module is re-run with proper hardware and tooling.

Remediation: Attach an Alfa AWUS036ACM/NEH/H (or drive the WiFi Pineapple Mark VII) and install the aircrack-ng suite (plus hcxdumptool/hcxtools, reaver, iw), then re-run the WiFi module to complete 802.11 coverage.

Effort: Easy

NIST 800-53: CA-8

PCI DSS 4: 11.2.1

INFO GB-RF-001 — Sub-GHz Signal Detected

Description: An active sub-GHz (300-928 MHz) transmission from the device under test was detected and/or decoded during a zero-knowledge spectrum survey.

Impact: The presence of a sub-GHz radio link expands the device's remotely-reachable attack surface; a listener in RF range can begin characterising and targeting the channel.

Remediation: Inventory the emitter, band, and modulation; determine whether the transmission is in scope and whether it carries device data or control.

Effort: Easy

MITRE ATT&CK: T0887 (Collection)

MEDIUM GB-RF-002 — Unencrypted Sub-GHz Telemetry Decoded

Description: rtl_433 decoded the device's sub-GHz sensor/telemetry frames in the clear, recovering payload fields with no key, which proves the link carries device data with no transport encryption.

Impact: Any passive attacker in radio range can read, log, and correlate the device's telemetry over time, disclosing operational state and potentially sensitive (PHI/asset) data without ever touching the device.

Remediation: Encrypt the RF payload with an authenticated cipher, or carry sensitive telemetry over an authenticated encrypted channel; never transmit patient or asset data as cleartext RF.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

MITRE ATT&CK: T0887 (Collection)

HIGH GB-RF-003 — Fixed-Code Sub-GHz Remote — Replayable

Description: A fixed-code (static OOK/ASK) sub-GHz remote or command protocol was decoded, meaning the device transmits the identical code on every actuation with no changing element.

Impact: A single captured frame can be re-transmitted verbatim to reproduce the command (garage/gate/relay/keyfob class); the captured static code IS the credential, so anyone who records one press controls the device.

Remediation: Replace fixed-code remotes with a rolling-code scheme or, preferably, an authenticated challenge-response link with anti-replay counters; treat the transmitted code as a credential, not an identifier.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

MITRE ATT&CK: T0831 (Impair Process Control)

LOW GB-RF-004 — Rolling-Code Sub-GHz Remote Detected

Description: A rolling-code (KeeLoq/HCS/Security+ class) sub-GHz remote was detected — a positive control that defeats naive single-frame replay.

Impact: Rolling codes still fall to jam-and-capture ('RollJam') and, for some legacy KeeLoq/fixed-seed variants, to key/seed-recovery attacks, so the control is not absolute and should be validated for counter-window and cipher strength.

Remediation: Keep firmware current, enforce a tight rolling-counter resync window, prefer AES-based rolling schemes over legacy KeeLoq, and consider bidirectional authenticated pairing.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N

MITRE ATT&CK: T0831 (Impair Process Control)

HIGH GB-RF-005 — Sub-GHz Replay Attack Feasible

Description: A captured sub-GHz command was re-transmitted (operator-confirmed, benign) and the device under test acted on it, confirming a working replay attack with no rolling counter, nonce, or authentication preventing frame reuse.

Impact: An attacker who records one legitimate transmission can reproduce the command at will — unlocking, actuating, or otherwise controlling the device remotely without any credential.

Remediation: Adopt authenticated, anti-replay commanding (rolling counter plus MAC, or challenge-response); reject any frame whose counter or nonce has already been observed.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

MITRE ATT&CK: T0831 (Impair Process Control)

HIGH GB-RF-006 — Unauthenticated Sub-GHz Command Channel (OOK/FSK)

Description: The device's sub-GHz control channel accepts commands with no authentication of the sender — the demodulated OOK/FSK frame is a bare command carrying no signature or nonce.

Impact: Any attacker able to transmit on the band can craft and inject commands the device will act on, achieving unauthenticated remote control of the device's functions.

Remediation: Require signed/authenticated commands (HMAC or public-key) with a monotonic counter or nonce, and reject any unauthenticated or malformed frame at the receiver.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

MITRE ATT&CK: T0860 (Initial Access)

MEDIUM GB-RF-007 — Missing Message Authentication on Sub-GHz Link

Description: No message-integrity or authentication field (MAC/signature) was observed on the device's sub-GHz frames, so their contents cannot be verified as genuine or unmodified.

Impact: Frame contents can be forged, altered, or replayed and the device cannot tell the difference, undermining the trustworthiness of every command and telemetry value on the link.

Remediation: Add per-message authentication (an AEAD tag or digital signature) and reject frames that fail integrity verification.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

MITRE ATT&CK: T0860 (Initial Access)

MEDIUM GB-RF-008 — Sub-GHz Jamming Susceptibility

Description: Under a controlled, operator-observed bench test the device's sub-GHz link was disrupted by narrowband jamming, denying legitimate commands and telemetry.

Impact: Low-power ISM control channels have no inherent jamming resistance, so an attacker can deny the device's RF link (and, via jam-and-capture, harvest rolling codes); if the channel is safety-critical the availability loss may have physical consequences.

Remediation: Add loss-of-link / jamming detection with a defined fail-safe state, use frequency agility or a diverse secondary channel for safety-critical control, and alert on sustained RF interference.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

MITRE ATT&CK: T0814 (Inhibit Response Function)

INFO GB-RF-009 — Sub-GHz Testing SKIPPED — No SDR/Radio Hardware Available

Description: No sub-GHz radio or host CLI toolchain was available for this instance, so 300-928 MHz RF testing was not performed and this interface was not assessed.

Impact: The device's sub-GHz attack surface remains unassessed; fixed-code, replay, cleartext-telemetry, and jamming weaknesses cannot be ruled out until a radio is attached and the module re-run.

Remediation: Attach an RTL-SDR or HackRF for spectrum survey and rtl_433 decode, or a YARD Stick One / CatSniffer / Flipper Zero for capture-and-replay, then re-run the SubGHz module.

Effort: Easy

INFO GB-UWB-001 — UWB Device Detected

Description: A UWB (IEEE 802.15.4z / 802.15.4a) device was detected during passive capture, along with the frame types observed (blink, poll/response/final ranging) and its transmitted address.

Impact: Confirms a live UWB ranging/RTLS attack surface (asset-tracking tag/anchor or secure-access ranging peer) and provides the address and frame context needed to target subsequent ranging-security tests.

Remediation: Reconcile every discovered UWB anchor/tag against the authorised asset inventory; disable or shield UWB interfaces that are not required.

Effort: Easy

NIST 800-53: CM-8

INFO GB-UWB-002 — UWB Testing SKIPPED — No Sniffer or UWB Hardware Available

Description: Gearbox attempted UWB assessment but no UWB sniffer board was selected and no sniffer binary or capture file was available, so UWB testing was NOT performed.

Impact: No assurance can be given about the UWB ranging/RTLS interface — its secure-ranging posture is unknown until a sniffer is flashed (Heltec / DWM3001CDK / DWM3000EVB) or a DW3000/UCI capture is imported and the module is re-run.

Remediation: Flash a UWB sniffer via Quiver or import a DW3000/UCI capture, then re-run the UWB module to complete the assessment.

Effort: Easy

HIGH GB-UWB-003 — UWB Ranging Without Scrambled Timestamp Sequence (STS)

Description: The UWB ranging exchange does not carry a Scrambled Timestamp Sequence (STS mode 0 / disabled, or a legacy 802.15.4a device). STS is the IEEE 802.15.4z cryptographic PHY field that binds the ranging timestamp to a secret.

Impact: Without STS the time-of-flight measurement is unauthenticated and can be forged, so relay, replay and distance-reduction attacks against proximity-based access control or RTLS are not cryptographically prevented.

Remediation: Enable IEEE 802.15.4z HRP secure ranging with STS (FiRa OWR/PDoA or DS-TWR with STS) provisioned via a per-session key; disable legacy 802.15.4a ranging.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

NIST 800-53: SC-8, SC-13, IA-9

HIGH GB-UWB-004 — Unauthenticated UWB Ranging Exchange

Description: Ranging frames are exchanged without cryptographic authentication of the timestamp, so a receiver cannot verify that a poll/response/final frame actually originated from the claimed peer at the measured distance.

Impact: Unauthenticated ranging is the root enabler of relay and distance-reduction attacks: any device can participate in or forge a ranging round, spoofing presence and distance for access control or asset tracking.

Remediation: Require STS-authenticated secure ranging and reject ranging rounds that omit or fail STS verification; bind the ranging result to an authenticated session.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

NIST 800-53: IA-3, IA-9

HIGH GB-UWB-005 — UWB Ranging Susceptible to Distance-Reduction (Ghost Peak) Attack

Description: Without enforced STS integrity, an over-the-air adversary can inject an early cipher-guessed STS/preamble to make the ranging peer measure a shorter-than-actual distance (the 'Ghost Peak' attack, USENIX Security 2022, demonstrated on Apple U1, NXP SR040/SR150 and Qorvo DW3000).

Impact: Where UWB gates physical access or presence (secure entry, unlock-on-approach, RTLS geofencing), an attacker can appear 'in range' from outside the intended zone and defeat proximity-based security.

Remediation: Enforce STS with a minimum acceptable STS quality/figure-of-merit, reject ranging with low STS confidence, and add an application-layer distance bound and multi-anchor cross-check.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

NIST 800-53: SC-8, IA-9

HIGH GB-UWB-006 — UWB Ranging Susceptible to Relay Attack

Description: An attacker relaying UWB ranging frames between a genuine tag and anchor can make a far peer appear in proximity. STS-based secure ranging binds the timing to a secret and is the defined mitigation; its absence leaves proximity guarantees unenforced.

Impact: Relay of the ranging exchange spoofs proximity for access control and RTLS, letting an attacker unlock/authorise or misplace a tracked asset from outside the intended range.

Remediation: Enable STS secure ranging and bind the ranging result to an authenticated session; never treat a UWB distance as trustworthy without STS verification.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

NIST 800-53: SC-8, IA-9

HIGH GB-UWB-007 — Replay of UWB Ranging Frames Accepted

Description: Previously-captured UWB ranging frames (poll/response/final or blink) were replayed and accepted by the ranging peer, showing the exchange lacks a per-session freshness guarantee (fresh STS / nonce / counter).

Impact: Replayable ranging enables spoofed presence and distance in RTLS and access-control use — a recorded exchange can be reused to re-assert proximity at will.

Remediation: Derive a fresh STS per ranging session from a monotonic counter/nonce and reject frames whose STS does not match the current session.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

NIST 800-53: SC-8, IA-9

MEDIUM GB-UWB-008 — Cleartext UWB Positioning or Payload Data

Description: Positioning data (measured distance/coordinates) or a MAC-layer payload was observed in the clear in the UWB capture, with no application-layer encryption of the ranging result or asset identifier.

Impact: Cleartext RTLS position data discloses the location of tracked assets (and, in a clinical setting, potentially staff or patients) to any passive UWB listener, defeating location privacy.

Remediation: Encrypt and authenticate the ranging-result and any MAC payload at the application layer; do not broadcast resolved positions or asset identifiers in cleartext.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

NIST 800-53: SC-8

PCI DSS 4: 4.2.1

MEDIUM GB-UWB-009 — UWB Static or Non-Rotating Ranging Key (STS Reuse)

Description: STS is present but appears to be derived from a static or reused seed/key rather than rotated per ranging session (observable as a repeating STS pattern), or a fixed STS_KEY/STS_IV is shipped in firmware.

Impact: A predictable or repeating STS erodes the integrity guarantee it is meant to provide, moving the system back toward replay and distance-manipulation exposure.

Remediation: Provision a per-session STS from a rotating key (FiRa dynamic STS / per-session key derivation); never ship a fixed STS_KEY/STS_IV in firmware.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

NIST 800-53: SC-12, IA-5

MEDIUM GB-UWB-010 — UWB Ranging Susceptible to Jamming / Denial of Service

Description: Under a co-channel UWB jammer (UWBAD-class attack with COTS chips) the DUT's ranging was denied, confirming a denial-of-service exposure of the ranging link.

Impact: Loss of ranging can drop safety/asset-tracking (RTLS goes blind) or push a UWB access-control system into an unsafe fail state (fail-open or fail-closed).

Remediation: Define a safe fail state on ranging loss, add jam/interference detection and alerting, and avoid using UWB ranging as the sole gate for safety-critical access.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

NIST 800-53: SC-5, SI-4

MEDIUM GB-UWB-011 — UWB Legacy (Pre-802.15.4z) Ranging — No Secure Ranging Support

Description: The device supports only pre-802.15.4z (802.15.4a HRP) ranging, which has no secure-ranging (STS) capability at all and cannot be made secure by configuration.

Impact: A legacy-only UWB part offers no cryptographic protection for ranging, so any security-relevant proximity/distance use is inherently spoofable and the part must be replaced rather than reconfigured.

Remediation: Replace legacy 802.15.4a-only UWB parts with 802.15.4z STS-capable silicon (e.g. DW3000-class) for access control or safety-critical asset tracking.

Effort: Significant

NIST 800-53: SA-4, SC-13

MEDIUM GB-UWB-012 — UWB Device Trackable via Static Address in Blink Frames

Description: UWB blink/ranging frames broadcast a stable device address (EUI-64 or fixed 16-bit short address) in every transmission, with no privacy-preserving address rotation.

Impact: A tag that emits a fixed address in every blink can be tracked and correlated to the asset (or person) it is attached to by any passive UWB receiver, defeating location privacy for the RTLS deployment.

Remediation: Rotate the tag's transmitted address/identifier (privacy-preserving randomised addressing) and expose the stable identity only under an authenticated session.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

NIST 800-53: SC-8

INFO GB-SC-001 — Smart Card Detected

Description: A smart card was detected in a PC/SC reader during zero-knowledge scanning, along with its Answer-To-Reset (ATR).

Impact: Confirms a live smart-card authentication surface and provides the ATR/reader context needed to target every subsequent fingerprint, APDU, and key test.

Remediation: Reconcile every detected card against the authorised asset inventory; disable unused card-based authentication paths.

Effort: Easy

INFO GB-SC-002 — Smart Card Reader Detected

Description: A PC/SC (CCID) smart-card reader was enumerated on the test host, providing the contact/contactless channel used for card assessment.

Impact: Establishes the reader interface used to reach the card; benign on its own but scopes the physical attack surface.

Remediation: No action required for the reader itself; ensure reader firmware is current and only authorised readers are attached to production hosts.

Effort: Easy

INFO GB-SC-003 — Smart Card ATR Fingerprinted

Description: The card's Answer-To-Reset (ATR) was captured and analysed, disclosing the card platform, chip, and card operating system.

Impact: The ATR reveals the exact card OS/chip, letting an attacker select platform-specific attacks (known default keys, applet exploits, CVM weaknesses) and defines the surface tested in later phases.

Remediation: ATR disclosure is inherent to ISO-7816 and cannot be suppressed; compensate by ensuring the identified platform is fully patched and its default keys/PINs are rotated.

Effort: Easy

LOW GB-SC-004 — Predictable Smart Card Serial Number

Description: The card serial/UID returned by the card is low-entropy, sequential, or otherwise predictable rather than cryptographically random.

Impact: A guessable or sequential serial lets an attacker enumerate valid card identities, forge enrolment records, or correlate a card to a holder, undermining any control that trusts the serial as an identifier.

Remediation: Issue cards with cryptographically-random, high-entropy serial/UID values; never derive the identifier from a sequential batch counter.

Effort: Moderate

NIST 800-53: IA-4

HIGH GB-SC-005 — Weak or Absent Cardholder Verification Method

Description: The card served sensitive file content in response to raw READ BINARY APDUs with no Cardholder Verification Method enforced (no PIN required; the card did not answer 0x6982 'security status not satisfied').

Impact: With no CVM, mere possession of the card is sufficient to access protected data and operations — there is effectively no authentication, so a lost or briefly-borrowed card yields full access.

Remediation: Define and enforce a CVM (PIN, PACE, or on-card biometric) access condition on every protected file and command; verify the card returns 0x6982 for unauthenticated access.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

NIST 800-53: IA-2, AC-3

PCI DSS 4: 8.3.1

HIGH GB-SC-006 — Unauthenticated APDU Access to Sensitive File

Description: An elementary file was read via a raw READ BINARY APDU that returned 0x9000 with data without any prior VERIFY/cardholder verification being presented.

Impact: Any party with brief physical access to the card and a low-cost reader can extract the file's contents (asset data, credentials, holder identifiers) directly, with no PIN or key.

Remediation: Protect sensitive elementary files with a CVM access condition and enforce it in the card OS access rules; require secure messaging for READ BINARY on protected files.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

MITRE ATT&CK: T1052 (Exfiltration)

NIST 800-53: AC-3, AC-6

CRITICAL GB-SC-007 — Default GlobalPlatform Card Manager Keys

Description: The card's GlobalPlatform Issuer Security Domain authenticated an SCP secure channel using the default test key set (40..4F / 404142434445464748494A4B4C4D4E4F).

Impact: An attacker with the card can open the same authenticated channel to install, delete, or replace applets and read/rotate keys — a full compromise of the card manager and everything the card protects.

Remediation: Rotate the ISD keys (ENC/MAC/KEK) to unique, per-card random values before deployment via GlobalPlatform PUT KEY; never ship cards on the 40..4F default key set.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

NIST 800-53: IA-5, SC-12, CM-6

PCI DSS 4: 2.2.1, 8.3.1

MEDIUM GB-SC-008 — Cleartext Data Object Readable on Smart Card

Description: Data read from the card without authentication contains cleartext printable strings (asset, holder, or configuration information stored and returned in the clear).

Impact: Sensitive data objects returned in the clear disclose asset/holder/configuration information to anyone who can read the card, aiding cloning, social engineering, or privacy compromise.

Remediation: Store sensitive data objects encrypted or behind a CVM; do not return holder/asset identifiers from unauthenticated files.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

NIST 800-53: SC-28, MP-4

HIGH GB-SC-009 — Default or Known Smart Card PIN Accepted

Description: The card accepted a well-known factory default PIN via an ISO-7816 VERIFY command (SW 0x9000) during an operator-confirmed, single-attempt test.

Impact: Anyone in possession of the card can satisfy cardholder verification with a published default PIN and unlock CVM-protected files and operations, defeating the PIN control entirely.

Remediation: Force a PIN change away from all factory defaults at first use; enforce PIN complexity and a low retry counter with a secure unblock (PUK) procedure.

Effort: Easy

CVSS Vector: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

NIST 800-53: IA-5

PCI DSS 4: 8.3.5, 8.3.9

MEDIUM GB-SC-010 — Insecure GlobalPlatform Card Lifecycle State

Description: The GlobalPlatform card lifecycle state is OP_READY or INITIALIZED rather than SECURED, meaning the card manager was never transitioned to its locked production state.

Impact: A card left in a pre-issuance lifecycle state permits card-content management and key-setup operations that should be closed off once the card is issued, widening the window for applet/key tampering.

Remediation: Transition the card to the SECURED lifecycle state (and lock the card manager) as part of issuance so pre-personalisation management commands are no longer accepted.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:P/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L

NIST 800-53: CM-6, CM-7

MEDIUM GB-SC-011 — No Secure Messaging — Cleartext APDU Channel

Description: The card returned sensitive file data over a cleartext (plain) APDU channel with no secure messaging (C-MAC/C-ENC) applied.

Impact: A passive USB-CCID or contactless interceptor can capture the command/response exchange verbatim, recovering sensitive data and enabling replay of the observed commands.

Remediation: Mandate GlobalPlatform / ISO-7816 secure messaging (C-MAC + C-ENC) for all commands that carry or return sensitive data.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

MITRE ATT&CK: T1557 (Collection)

NIST 800-53: SC-8, SC-13

INFO GB-SC-012 — SmartCard Testing SKIPPED — No PC/SC Reader or Tools Available

Description: Smart-card testing was not performed because the required PC/SC toolchain (pcsc_scan / opensc-tool) or reader was unavailable; the module honestly recorded that no card test ran.

Impact: No assurance can be drawn about the device's smart-card authentication posture — the interface remains untested until a reader and the PC/SC tools are present.

Remediation: Connect an Identiv SCR3310 (or any PC/SC) reader, install pcsc-tools, opensc, and GlobalPlatformPro (gp), start pcscd, and re-run the SmartCard module.

Effort: Easy

INFO GB-ZW-001 — Z-Wave Device Detected

Description: A Z-Wave network was detected during passive sub-GHz (868/908 MHz) capture, along with its cleartext frame header data (HomeID and one or more NodeIDs).

Impact: Confirms a live Z-Wave mesh within RF range and provides the HomeID/NodeID needed to target every subsequent enumeration and security test.

Remediation: Reconcile every discovered Z-Wave HomeID/NodeID against the authorised asset inventory; disable or shield Z-Wave interfaces that are not required.

Effort: Easy

MITRE ATT&CK: T1200 (Initial Access)

NIST 800-53: CM-8, PM-5

INFO GB-ZW-002 — Z-Wave Network Enumerated

Description: The Z-Wave mesh was enumerated passively from cleartext frame headers, disclosing the HomeID, the set of NodeIDs, and the command-class traffic exchanged between the controller and its slaves.

Impact: Maps the controller/slave topology and per-node command-class usage, letting an attacker identify locks, switches, and sensors and plan targeted forge/replay attacks against specific nodes.

Remediation: Z-Wave frame headers are inherently cleartext; minimise information leakage by enforcing S2 on all traffic and physically limiting RF exposure of the mesh.

Effort: Moderate

MITRE ATT&CK: T1592 (Reconnaissance)

NIST 800-53: CM-8

HIGH GB-ZW-003 — Unencrypted Z-Wave Control Frames

Description: Actionable Z-Wave control traffic (e.g. Binary Switch, Multilevel Switch, Door Lock, Alarm) was observed in the clear, with no S0 (CC 0x98) or S2 (CC 0x9F) encapsulation.

Impact: Any passive listener can read device state, and any attacker with a TX-capable radio can forge or replay commands — unlocking doors, toggling actuators, or suppressing alarms — with no key required.

Remediation: Enforce S2 (Security_2) on every node, remove nodes that cannot be securely included, and never operate actuators or locks over unencrypted command classes.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

MITRE ATT&CK: T1040 (Credential Access)

NIST 800-53: SC-8, SC-13

PCI DSS 4: 4.2.1

MEDIUM GB-ZW-004 — Z-Wave S0 Legacy Security Class in Use

Description: The network uses the legacy S0 Security command class (CC 0x98), which relies on AES-OFB/CBC-MAC with a network key exchanged at inclusion under a hardcoded all-zero temporary key and lacks S2's anti-replay and forward-secrecy protections.

Impact: An attacker who captures a device inclusion recovers the S0 network key and can decrypt and forge all S0 traffic; S0 also permits replay that S2 would reject.

Remediation: Migrate all nodes to S2; retire S0-only devices. If S0 is unavoidable, perform inclusion inside a shielded enclosure so the key exchange cannot be sniffed.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

MITRE ATT&CK: T1600 (Defense Evasion)

NIST 800-53: SC-13, SC-12

PCI DSS 4: 4.2.1

HIGH GB-ZW-005 — Z-Wave S0 Network Key Extractable on Inclusion

Description: Because the network uses S0, its network key is derivable by any attacker who captures a device inclusion: the Network Key Set frame is encrypted only under the well-known temporary key 0x00000000000000000000000000000000, so the S0 network key can be extracted offline.

Impact: Recovering the S0 network key lets an attacker decrypt every past and future S0 frame and forge authenticated commands (unlock doors, actuate devices); a node re-included after a power loss re-exposes the key.

Remediation: Use S2 (ECDH-authenticated key exchange with out-of-band DSK) so the network key is never sent under a hardcoded key; shield any required S0 inclusion.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

MITRE ATT&CK: T1557 (Credential Access)

NIST 800-53: SC-12, IA-5

PCI DSS 4: 3.6.1

HIGH GB-ZW-006 — Z-Wave S2 Security Downgrade to S0 Accepted

Description: During inclusion the controller accepted a downgrade of the negotiated security class from S2 to the legacy S0 command class (the 'Z-Shave' attack), because S2-only inclusion is not enforced.

Impact: An attacker in RF range at inclusion time can force S0, recover the network key via the hardcoded all-zero temporary key, and take control of the device despite S2 support being present.

Remediation: Enforce S2-only inclusion with no S0 fallback; reject any KEX_REPORT that requests a lower security class; require out-of-band DSK verification at inclusion.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

MITRE ATT&CK: T1600.001 (Defense Evasion)

NIST 800-53: SC-13, SC-12

PCI DSS 4: 4.2.1

HIGH GB-ZW-007 — Z-Wave Command Replay Accepted

Description: A previously captured unencrypted (or S0) Z-Wave command frame was retransmitted and the device acted on it, confirming no effective anti-replay protection.

Impact: An attacker can record a legitimate command (lock/unlock, on/off) and replay it later to actuate the device without ever possessing the network key.

Remediation: Enforce S2, whose Singlecast nonce/SPAN sequencing rejects replayed frames; never operate actuators over unencrypted or S0 command classes.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

MITRE ATT&CK: T1557 (Credential Access)

NIST 800-53: SC-8, SC-23

PCI DSS 4: 4.2.1

INFO GB-ZW-008 — Z-Wave S2 Secure Class Confirmed

Description: The network was observed using the S2 Security_2 command class (CC 0x9F), which performs an ECDH (Curve25519) authenticated key exchange with an out-of-band DSK and provides per-frame nonce-based anti-replay.

Impact: S2 traffic is not passively decryptable or trivially replayable; this is the desired posture, though it must be confirmed for ALL nodes with no S0 fallback permitted.

Remediation: Confirm every node is S2 (no S0-only devices) and that the controller enforces S2-only inclusion with no S0 fallback; verify DSK out-of-band at inclusion.

Effort: Easy

NIST 800-53: SC-13

MEDIUM GB-ZW-009 — Z-Wave S0 NonceGet Denial-of-Service Exposure

Description: The Z-Wave gateway accepts unauthenticated S0 NonceGet requests, allowing an attacker to flood NonceGet frames (the 'S0-No-More' attack) and exhaust the gateway's nonce state so legitimate S0 encryption is blocked.

Impact: A denial-of-service that halts the whole S0 mesh — including safety-relevant devices such as locks and sensors — requiring only RF range and a valid included NodeID.

Remediation: Migrate off S0 to S2; rate-limit NonceGet handling; drop NonceGet requests from NodeIDs that are not actively transacting.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

MITRE ATT&CK: T1498 (Impact)

NIST 800-53: SC-5

INFO GB-ZW-010 — Z-Wave Testing SKIPPED — No SDR or Sniffer Available

Description: Z-Wave testing was not performed because no SDR/sniffer was selected, no capture CLI was installed, or no Z-Wave traffic was observed on the selected frequency. This is an honesty marker so the operator is not misled into thinking the interface was assessed.

Impact: The Z-Wave attack surface remains unassessed; any unencrypted control, S0 key-exchange, downgrade, or replay weakness would go undetected until the module is re-run with working capture hardware.

Remediation: Attach a HackRF One (EZ-Wave / scapy-radio), a CatSniffer with Sub-GHz firmware, or an RTL-SDR (waving-z / rtl_433), install the Z-Wave capture tooling, and re-run the module to actually assess the interface.

Effort: Easy

INFO GB-LORA-001 — LoRa Transmission Detected

Description: LoRa radio transmissions were captured on the device's regional ISM band (433/868/915 MHz) during passive scanning, including frame count and observed MHDR MType(s).

Impact: Confirms a live LoRa wireless attack surface and provides the frames needed to target the subsequent LoRaWAN activation, key, replay, and payload tests.

Remediation: Reconcile the transmitting radio against the authorised asset inventory; disable or shield LoRa interfaces that are not required and document expected channels/spreading factors.

Effort: Easy

MITRE ATT&CK: T1040 (Discovery)

INFO GB-LORA-002 — LoRaWAN Network Traffic Detected

Description: LoRaWAN protocol traffic (Join and/or MAC data frames identifiable by their MHDR/FHDR structure and DevAddr) was identified in the passive capture.

Impact: Confirms a LoRaWAN network is in range and reachable to a passive listener, exposing DevAddr and frame-counter metadata used to assess replay and key-management weaknesses.

Remediation: Confirm the LoRaWAN deployment is authorised and inventoried; ensure the network server enforces monotonic frame counters and secure join handling.

Effort: Easy

MITRE ATT&CK: T1040 (Discovery)

HIGH GB-LORA-003 — Raw LoRa Payload Transmitted Without Encryption

Description: A proprietary (non-LoRaWAN) LoRa frame carried an application payload that decodes to printable/structured cleartext, indicating the payload is transmitted with no encryption or message integrity check.

Impact: Any passive listener in radio range reads sensor/telemetry data directly, and — absent a MIC — can forge or replay commands to the device, undermining confidentiality and integrity of the RF link.

Remediation: Encrypt and authenticate the application payload (AES-CTR/GCM with a per-device key and a monotonic counter/nonce), or adopt LoRaWAN and rely on its MIC and FRMPayload encryption.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

MITRE ATT&CK: T1040 (Discovery)

NIST 800-53: SC-8, SC-13

PCI DSS 4: 4.2.1

HIGH GB-LORA-004 — LoRaWAN ABP Activation — Static Session Keys

Description: The device is activated by ABP (Activation By Personalization), so the NwkSKey and AppSKey are provisioned as static, long-lived key material instead of being derived per session by an OTAA join.

Impact: On a device reset the frame counter returns to zero while the keys are unchanged, so the AES-CTR keystream/IV is reused across sessions — enabling known-plaintext / crib-dragging recovery of payloads and replay of previously captured uplinks.

Remediation: Prefer OTAA so fresh session keys are derived per join; where ABP is mandatory, persist frame counters across reboots (never reset them) and rotate the ABP session keys on a defined schedule.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

MITRE ATT&CK: T1040 (Discovery), T1557 (Credential Access)

NIST 800-53: SC-12, IA-5

PCI DSS 4: 3.6.1

HIGH GB-LORA-005 — LoRaWAN OTAA Join Replay — Missing DevNonce Tracking

Description: The device uses OTAA under LoRaWAN 1.0.x, where the end device cannot detect a repeated Join-Accept and the network server only remembers a bounded number of recent DevNonce values, so a captured Join-Request can be replayed after that window rolls over.

Impact: An attacker replays a captured Join-Request to force a re-join and session-key reset, enabling denial-of-service against the node or pinning it to attacker-observable key material derived from replayed nonces.

Remediation: Upgrade to LoRaWAN 1.1, which enforces a monotonic DevNonce counter and join-server nonce tracking; where 1.0.x is required, persist the full DevNonce history per device and reject any repeat.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L

MITRE ATT&CK: T1040 (Discovery), T1557 (Credential Access)

NIST 800-53: SC-23, IA-2

PCI DSS 4: 8.3.1

CRITICAL GB-LORA-006 — LoRaWAN Default or Weak AppKey

Description: The device's LoRaWAN root AppKey (OTAA) or session keys (ABP) are default, all-zero, sequential, vendor-shared, or derivable from the public DevEUI — i.e. a hard-coded or guessable credential.

Impact: Recovering the AppKey lets an attacker derive the session keys, decrypt every FRMPayload, forge a valid MIC, and fully impersonate the device — collapsing the entire LoRaWAN security model for that node and any others sharing the key.

Remediation: Provision a unique, random, secret AppKey per device at manufacture; never print, log, share, or derive it from public identifiers; store it in a secure element and rotate immediately on suspected compromise.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

MITRE ATT&CK: T1040 (Discovery), T1557 (Credential Access)

NIST 800-53: IA-5, SC-12

PCI DSS 4: 3.6.1, 8.3.1

HIGH GB-LORA-007 — LoRaWAN Missing Frame-Counter Validation

Description: The network accepted a LoRaWAN uplink whose frame counter (FCnt) was equal to or lower than a previously-seen value — observed as a repeated FCnt in the capture, or confirmed by an authorized replay — indicating frame-counter validation is not strictly enforced.

Impact: Without strict monotonic frame-counter checks an attacker replays captured uplinks to re-trigger device actions or mask live telemetry with stale readings, defeating the protocol's core replay protection.

Remediation: Enforce strict monotonic frame-counter validation at the network server (reject any FCnt <= last seen), enable 32-bit frame counters, and alert on counter resets or rollovers.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L

MITRE ATT&CK: T1040 (Discovery), T1557 (Credential Access)

NIST 800-53: SC-23, SI-10

PCI DSS 4: 6.2.4

MEDIUM GB-LORA-008 — LoRaWAN Cleartext Application Payload

Description: The captured FRMPayload decodes to printable/structured data and the application relies solely on LoRaWAN's session-key FRMPayload encryption, with no independent end-to-end application-layer encryption.

Impact: Any holder of the session keys — the network server, a compromised join server, or an attacker who recovered a weak/default key — reads the plaintext, and for raw or misconfigured payloads a passive listener may read it directly.

Remediation: Add end-to-end application-layer encryption/authentication (e.g. AES-GCM with a key held only by the device and the application server) so LoRaWAN network operators cannot read or forge sensitive payloads.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

MITRE ATT&CK: T1040 (Discovery)

NIST 800-53: SC-8, SC-13

PCI DSS 4: 4.2.1

MEDIUM GB-LORA-009 — LoRaWAN 1.0.x — No Join-Request Replay Protection

Description: The network operates LoRaWAN 1.0.x, in which Join-Request messages carry no replay protection prior to the 1.1 monotonic DevNonce counter — a protocol-version exposure applying to every OTAA device on the network.

Impact: The version gap leaves all OTAA joins susceptible to nonce reuse and Join-Request replay, providing a standing foothold for denial-of-service and session-reset attacks independent of any single observed replay.

Remediation: Migrate the network server and end devices to LoRaWAN 1.1, which adds monotonic DevNonce handling and join-server nonce tracking; until then, maximise the DevNonce cache and monitor for repeated joins.

Effort: Significant

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

MITRE ATT&CK: T1040 (Discovery), T1557 (Credential Access)

NIST 800-53: SC-23

PCI DSS 4: 6.2.4

INFO GB-LORA-010 — LoRa Testing SKIPPED — No SDR or LoRa Radio Available

Description: Gearbox attempted LoRa / LoRaWAN assessment but no usable radio was available: either no hardware was selected, the LoRa32 sniffer board exposed no serial port, or neither rtl_433 nor urh_cli was on PATH.

Impact: LoRa / LoRaWAN was NOT tested for this interface, so any radio-layer, key-management, or replay weakness remains unverified and unreported until a capture-capable radio is provided.

Remediation: Flash a Heltec LoRa32 v3 or LilyGo LoRa32 with single-channel-sniffer firmware via Quiver, or attach an RTL-SDR / HackRF with rtl-433 and universal-radio-hacker installed, then re-run the module.

Effort: Easy

HIGH GB-BT-030 — BLE LESC Passkey Recovered from Passive Capture

Description: The 6-digit LE Secure Connections Passkey Entry passkey was recovered offline from a passively-captured pairing. In LESC Passkey Entry each of the 20 passkey bits is committed with f4 (AES-CMAC over the cleartext ECDH public keys, the revealed per-round nonce, and one passkey bit); once the nonce is revealed the single bit is brute-forced by matching the captured Pairing Confirm, and the recovery is confirmed independently from the initiator and responder halves.

Impact: An attacker who passively sniffs ONE pairing recovers the passkey with no active MITM and no physical access to the printed value. If the passkey is static or reused it authenticates every future session and every unit that shares it, collapsing LESC Passkey Entry to Just Works — full man-in-the-middle and session compromise.

Remediation: Use a fresh, random, single-use passkey per pairing that is never printed, hard-coded, or reused; a passkey a single sniffed pairing reveals provides no MITM protection under LESC.

Effort: Moderate

NIST 800-53: IA-5, SC-8, SC-13

LOW GB-SSH-006 — SSH Password Authentication Enabled

Description: The SSH server accepts password-based authentication methods (password and/or keyboard-interactive) alongside public key authentication. Password authentication is susceptible to brute-force attacks and does not enforce multi-factor authentication.

Impact: An attacker can attempt password brute-force attacks against the SSH service. Even with strong passwords, password authentication lacks the cryptographic assurance of key-based authentication and is incompatible with most MFA implementations. Compliance frameworks including CIS Benchmarks and DISA STIGs mandate public-key-only SSH authentication.

Remediation: Disable PasswordAuthentication and ChallengeResponseAuthentication in /etc/ssh/sshd_config. Require public key authentication exclusively. CIS Benchmark and DISA STIG both mandate disabling password-based SSH login.

Effort: Low

CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

MITRE ATT&CK: T1110 (Credential Access), T1078 (Initial Access)

NIST 800-53: IA-2, IA-5, CM-6

PCI DSS 4: 8.3.1, 2.2.4

MEDIUM GB-SSH-007 — SSH Password-Only Authentication (No Public Key)

Description: The SSH server accepts only password-based authentication methods (password and/or keyboard-interactive) with no public key authentication available. This is a significant security weakness — the server cannot accept key-based authentication at all, making brute-force the only barrier to unauthorized access.

Impact: Without public key authentication, the SSH server relies entirely on password strength for security. An attacker can mount online brute-force or credential-stuffing attacks with no cryptographic barrier. This configuration violates CIS Benchmark and DISA STIG requirements for SSH hardening.

Remediation: Enable public key authentication and disable PasswordAuthentication and ChallengeResponseAuthentication in /etc/ssh/sshd_config. Generate and deploy SSH key pairs for all authorized users.

Effort: Moderate

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

MITRE ATT&CK: T1110 (Credential Access), T1078 (Initial Access)

NIST 800-53: IA-2, IA-5, CM-6

PCI DSS 4: 8.3.1, 2.2.4