Detecting Zyxel GS1900 Compromise: Management Plane, Config, and Traffic Checks
Nearly a thousand Zyxel GS1900 switches were hijacked in the wild. This is the detection side of that story: how to work out whether one of them was yours. The public reporting I have is headline-level, so this video is careful about what it claims. No exploitation primitive, no CVE, no per-model firmware matrix. What it does give you is a set of read-only checks that hold regardless of which bug opened the door, because root-equivalent access to a switch's management plane means the attacker had to touch config, accounts and forwarding state. What the video covers: - Inventory and reachability: know how many switches you own, and which subnets can actually open the admin UI. - Accounts and boot time: local admins ops did not create, and reboots outside a change window. - Config diffing: strip volatile lines, store snapshots, diff daily. - The diff shortlist, ranked: mirror and SPAN sessions, management access ACLs, local users, SNMP, NTP and DNS, syslog destinations. - The fix: cut management access to your jump host, version the configs, alert on change. One framing note from the post: a switch compromise is a trust anchor problem, and most organizations run zero telemetry on that trust anchor. A server gives an attacker a foothold; a switch gives them the terrain. Patching closes the reported hole, but it does not fix the reason the switch was reachable and unobserved in the first place. The CLI snippets shown are representative, not verified syntax for every GS1900 model and firmware branch. Check the CLI reference guide for your build before pasting anything into production. Everything demonstrated is read-only, defensive and lab-scoped. Full write-up with the checks in order: https://hackyjs.com/posts/detecting-zyxel-gs1900-compromise-management-plane-config-and-traffic-checks