offensive-z-wave skill
Z-Wave attack methodology — sniffing with Z-Force / EZ-Wave / RTL-SDR + ZniffMobile, S0 (legacy) network-key derivation flaw and key reuse, S2 (modern) ECDH commissioning analysis, replay/injection on unauthenticated nodes, default-key brute-force on test deployments, and home-automation hub pivots. Use when targeting Z-Wave smart home devices (door locks, sensors, garage controllers) — common in mid-2010s smart home deployments still in production.
Is the offensive-z-wave skill safe?
Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.
No findings.
Install the offensive-z-wave skill
A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.
git clone --depth 1 https://github.com/SnailSploit/Claude-Red.git /tmp/Claude-Red mkdir -p ~/.claude/skills cp -r /tmp/Claude-Red/Skills/wireless/offensive-z-wave ~/.claude/skills/offensive-z-wave
In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub
The instructions your agent would load
SKILL.md as published, without the frontmatter. Read it on GitHub
Z-Wave Attacks
Z-Wave runs in the 800/900 MHz ISM band (US: 908 MHz, EU: 868 MHz). Older networks used the S0 security scheme with a fixed-derivation network key — long-known to be flawed. S2 (mandatory for Z-Wave Plus v2 since 2017) uses ECDH commissioning and is significantly stronger.
Quick Workflow
- Identify region (US 908 MHz / EU 868 MHz) — adapter frequency must match
- Sniff inclusion (commissioning) traffic — that's where keys are exchanged
- Determine S0 vs S2 from frame format
- For S0: derive/replay; for S2: analyze ECDH and look for implementation flaws
Hardware
Sniffing
# EZ-Wave (HackRF firmware-based)
git clone https://github.com/cureHsu/EZ-Wave
ezwave-sniff -f 908.4MHz -o capture.pcap
# Wireshark with the Z-Wave dissector parses captured frames
wireshark capture.pcapLook for the inclusion phase (controller adding new device) — that's where the network key is exchanged.
S0 Security Flaw
S0 derives the network key from a fixed all-zero PSK during the inclusion of the first device. That fixed material is well-known — any S0 network you sniff during inclusion can be decrypted offline.
S0 commissioning:
1. New node joins → controller sends key with zero-PSK encryption
2. Attacker sniffs commissioning frame → derives session key
3. All future S0 traffic on that network is decryptableIf you can:
- Trigger inclusion (factory-reset a node, or wait for legitimate inclusion)
- Sniff during the ~2-second key-exchange window
You own the network key for that mesh.
S2 (Z-Wave Plus / S2 Authenticated)
S2 fixes S0 by using ECDH for commissioning:
- Each device has a Curve25519 keypair
- Inclusion uses DSK (Device Specific Key) verified out-of-band (sticker/QR)
- Network key never traverses the air in plaintext
S2 attack surface is mostly implementation:
- Inclusion-mode-always-open (controller misconfig)
- Firmware bugs in S2 verification
- Side-channel on ECDH on resource-constrained chips
- DSK printed on a sticker → physical access yields it
Replay / Injection on Unauthenticated Nodes
Many low-end Z-Wave devices (older sensors, basic switches) don't enforce S0 or S2 — they accept commands in cleartext.
# scapy-zwave (community fork) for crafted frames
from scapy.contrib.zwave import *
frame = ZWave(home_id=0x12345678)/ZWaveBasic(set_value=0xff)
sendp(frame, iface='ezwave0')This unlocks doors / switches lights / unarms sensors when the target lacks authentication.
Key Brute-Force
For old test deployments using default home IDs / network keys:
# Try default home IDs
for hid in 0x00000000 0x12345678 ...; do
ezwave-test --home-id $hid --target-node 1
doneHit rate on production is low; useful only for default-config IoT lab gear.
Hub Pivots
Z-Wave devices are typically controlled by a hub (SmartThings, Hubitat, Vera, Home Assistant, Z-Wave JS UI). The hub is a Linux device with the Z-Wave PSK in plaintext storage:
- SmartThings Hub: previously cloud-only credentials; modern v3 stores network key locally
- Home Assistant: ~/.homeassistant/zwave_js.json typically contains keys
- Hubitat: web UI with default password on older versions
Compromise the hub → walk away with the Z-Wave PSK + every paired device's command authority. See offensive-iot for hub firmware extraction.
Engagement Cheatsheet
# 1. Identify region + frequency
# US: 908.4 MHz; EU: 868.4 MHz; CN: 868.4 MHz
# 2. Sniff
ezwave-sniff -f 908.4MHz -o cap.pcap
wireshark cap.pcap # filter zwave
# 3. Identify S0 vs S2 from frame format
# 4. For S0: capture inclusion → derive key → decrypt history + control devices
# 5. For S2: focus on hub compromise / DSK theft / implementation bugs
# 6. Test unauthenticated cleartext devices with crafted framesDetection
- Most Z-Wave deployments have no IDS comparable to Wi-Fi/Zigbee monitoring
- Hub may log unexpected commands but UI rarely surfaces these to users
- Inclusion-mode-open is visible in hub UI but ignored by inattentive admins
Reporting
- Identify chipset / firmware revision per device (ZW0500 series, ZW7000 series)
- Map S0 vs S2 per node — note any S0 left on a network with S2-capable nodes
- Document hub compromise paths separately
Key References
- EZ-Wave: github.com/cureHsu/EZ-Wave (HackRF-based)
- "Z-Force and the Z-Wave Sniffer" — original research
- Silicon Labs Z-Wave 700-series spec
- Source: https://github.com/SnailSploit/offensive-checklist/blob/main/wireless.md
More skills from SnailSploit/Claude-Red
- Aoffensive-active-directoryActive Directory attack methodology for internal network red team engagements. Covers reconnaissance (BloodHound, PowerView, ADExplorer), credential abuse (Kerberoasting, ASREProasting, NTLM relay, LLMNR/NBT-NS poisoning), privilege escalation (ACL abuse, GPO abuse, unconstrained/constrained delegation), lateral movement (Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, WMI/WinRM/PsExec), persistence (Golden/Silver/Diamond Tickets, DCSync, DCShadow, AdminSDHolder, Skeleton Key), forest trust attacks, ADCS abuse (ESC1-ESC15), and modern MDI/Defender for Identity evasion. Use when assessing on-prem AD, hybrid AD/Entra ID environments, or ADCS deployments.
- Aoffensive-advanced-redteamComprehensive red team operations methodology covering full engagement lifecycle from planning through reporting. Addresses engagement scoping and rules of engagement negotiation, multi-tier C2 infrastructure design with redirectors and domain fronting, malleable traffic profiles and beacon tradecraft, OPSEC discipline including attribution avoidance and indicator management, EDR and AMSI evasion techniques using direct syscalls and unhooking, data collection with chain-of-custody controls, and structured reporting with purple team debrief workflows. Covers assumed-breach, external-to-internal, insider threat, and hybrid physical-cyber engagement scenarios with MITRE ATT&CK mapping throughout. Targets operators planning or executing adversary simulation engagements against mature defenders.
- Coffensive-ai-security
- Aoffensive-anti-forensicsAnti-forensics and evidence destruction techniques for red team operators conducting authorized engagements. Covers log clearing on Windows (wevtutil, Clear-EventLog, ETW provider patching) and Linux (journal truncation, utmp/wtmp binary editing, syslog manipulation), timestamp manipulation via Timestomp and SetMACE to defeat timeline analysis, filesystem-level anti-forensics including NTFS Alternate Data Streams for payload hiding and secure deletion with sdelete/shred, memory artifact removal to counter live forensics, disk artifact manipulation targeting MFT entries and USN journal records, network forensics evasion through encrypted C2 channels and DNS-over-HTTPS tunneling, and anti-VM/sandbox detection to avoid dynamic analysis environments. Tools: Timestomp, wevtutil, sdelete, shred, MimiPenguin, Invoke-Phant0m. Aligns to MITRE ATT&CK T1070 (Indicator Removal), T1027 (Obfuscated Files or Information), T1497 (Virtualization/Sandbox Evasion). Each technique includes the forensic artifact it targets, the destruction or manipulation method, and the defender perspective so operators understand detection gaps they must account for.
- Aoffensive-api-abuseAdvanced API exploitation methodology focused on business logic abuse and sophisticated attack patterns that bypass traditional security controls. Covers business logic bypass through API call chaining and workflow manipulation. Addresses GraphQL-specific attacks including batching for credential brute-force, query depth exploitation, and introspection abuse. Includes pagination exploitation for data exfiltration, webhook hijacking for SSRF and data interception, and resource exhaustion through algorithmic complexity attacks. Covers race conditions in API transactions using parallel request techniques. Provides comprehensive JWT manipulation including algorithm confusion, kid injection, jku/x5u abuse, and claim tampering. Details API key leakage detection across source repositories, client-side code, and error messages. Covers undocumented endpoint discovery through predictable naming, debug routes, and source map analysis. Tooling includes Arjun, ParamSpider, jwt_tool, and GraphQL Voyager. Designed for authorized penetration testers targeting business logic layers that automated scanners miss.
- Aoffensive-api-securityComprehensive API security testing methodology covering REST, gRPC, and WebSocket attack surfaces. Addresses the full OWASP API Security Top 10 2023 including BOLA/IDOR, broken authentication, excessive data exposure, rate limiting bypass, BFLA, mass assignment, SSRF, and security misconfiguration. Includes REST-specific attacks such as HTTP verb tampering, content-type switching, and parameter pollution. Covers gRPC exploitation through protobuf interception, reflection API enumeration, and metadata injection. Addresses WebSocket vulnerabilities including origin bypass, message injection, and cross-site WebSocket hijacking. Provides tooling guidance for Burp Suite, Postman, grpcurl, websocat, and mitmproxy. Each technique includes detection signatures and defensive indicators so you understand what artifacts your testing leaves behind. Designed for authorized penetration testing engagements against API-driven architectures.
- Aoffensive-bluetooth-bleBluetooth Low Energy (BLE) attack methodology — GATT enumeration, characteristic read/write without auth, pairing downgrade (Just Works forced), LE Secure Connections bypass, MITM via active relay, sniffing with Sniffle (TI CC1352) / Ubertooth / Frontline, encryption key extraction (LE Legacy Pairing crackable, LE Secure Connections strong), proximity authentication abuse (cars, locks), and companion-app trust analysis. Use for IoT BLE devices, smart locks, fitness trackers, medical devices, BLE beacons, or any device pairing over BLE.
- Aoffensive-bluetooth-classicBluetooth Classic (BR/EDR) attack methodology — device discovery, service enumeration via SDP, LMP/L2CAP layer attacks, legacy PIN cracking (BlueBorne / KNOB), Bluetooth file-transfer abuse (BlueSnarfing legacy), unauthenticated profile abuse (HSP, HFP, OPP), and modern relevance against older industrial / automotive / accessory targets. Use when in-scope devices use Bluetooth Classic (Bluetooth ≤ 4.0 BR/EDR) — common in legacy car kits, industrial sensors, older medical devices, and audio accessories.
- Aoffensive-bug-identification
- Aoffensive-business-logicBusiness logic vulnerability testing for web/mobile/API engagements. Covers workflow bypass, state machine violations, multi-step process abuse, price/quantity/discount manipulation, currency confusion, coupon stacking, refund/chargeback abuse, race conditions on logic boundaries, parameter tampering for hidden flows, role/tenant boundary violations, time-of-check vs use, anti-automation defeat, fraud-detection evasion, and subscription/quota abuse. Use when scoping an application after surface-level OWASP Top 10 has been covered, or when the asset is a transactional/marketplace/fintech/e-commerce/SaaS app where logic flaws produce direct financial impact.
- Aoffensive-c2-frameworksCommand and Control framework deployment, configuration, and operational tradecraft for red team engagements. Covers Cobalt Strike (malleable C2 profiles, Beacon types HTTP/HTTPS/DNS/SMB, Beacon Object Files for in-memory execution, sleep and jitter tuning, named pipe pivoting), Sliver (implant generation across mTLS/WireGuard/DNS transport, operator multiplayer mode, armory extensions), Mythic (agent ecosystem with Apollo/Poseidon/Medusa, C2 profile configuration, translation containers), Havoc (Demon agent with sleep obfuscation via Ekko/Zilean, indirect syscalls, dotnet inline execution), Metasploit (msfvenom payload generation, multi/handler staging, Meterpreter post-exploitation modules), redirector architecture using Apache mod_rewrite and Nginx, domain fronting through CDN providers, DNS-based C2 for restrictive network egress, and TLS certificate management for infrastructure OPSEC. Tools: Cobalt Strike, Sliver, Mythic, Havoc, Metasploit Framework. Aligns to MITRE ATT&CK T1071 (Application Layer Protocol), T1573 (Encrypted Channel), T1090 (Proxy/Connection Proxy).
- Doffensive-cicd-pipelineComprehensive CI/CD pipeline exploitation methodology covering GitHub Actions injection vectors (expression injection via PR titles and issue bodies, workflow_run event abuse, GITHUB_TOKEN over-scoping, composite action supply chain compromise), Jenkins attack paths (Groovy sandbox escapes, script console remote code execution, Java remoting deserialization, credential store dumping, shared library injection), GitLab CI exploitation (YAML anchor injection, runner registration token abuse, CI variable extraction, protected branch bypass via merge request pipelines), and Azure DevOps pipeline agent compromise with service connection theft. Includes artifact poisoning techniques across all platforms, tooling guidance for gato and jenkins-attack-framework, and maps to MITRE ATT&CK T1195.002 (Supply Chain Compromise: Compromise Software Supply Chain). Covers enumeration of pipeline configurations, privilege escalation from contributor to code execution, lateral movement through pipeline trust boundaries, and persistence via modified workflow definitions. Each technique section provides working exploitation code, detection indicators, and defensive countermeasures.