Detecting Zyxel GS1900 Compromise: Management Plane, Config, and Traffic Checks

Introduction

Detection, Not a News Recap

By now you have probably seen the headline: Zyxel patched a zero-day in its GS1900 switch line after attackers used it against close to a thousand devices. The reports in my source material are dated 2026-11-04 and 2026-11-05, and the news links are at the bottom. This post is about the part that decides whether you had a bad month: how to detect a Zyxel GS1900 compromise by reading the management plane, diffing configuration, and watching the traffic paths a switch owns.

That is the gap. Most teams can tell you what their servers did last Tuesday. Almost none can tell you what their switches did. And when the compromised asset is the thing forwarding your traffic, your usual evidence sources go soft, because the device that should have logged the anomaly is the device lying to you.

The checks below are read-only where possible, ordered by signal value, and designed to run without buying a commercial NDR.

The Position, In One Line

A switch compromise is a trust-anchor problem, and most organizations run zero telemetry on that trust anchor. Patching the firmware closes the reported hole. It does not fix the reason the switch was reachable and unobserved in the first place. I would rather see management-plane exposure cut today than sit through an argument about patch windows.

Everything below is written from that stance.

What the Public Reporting Actually Establishes

The Confirmed Claim Set

The public reporting I have is headline-level, so I will be precise about what I can stand behind. From the three reports in the source material:

That is the whole set I will assert.

What the Reporting Does Not Give Us

The snippets carry no exploitation primitive, no CVE identifier, no CVSS score, no per-model firmware matrix, and no list of which management interfaces were involved. Web UI? An SNMP path? A hardcoded credential? Something in the CLI-over-Telnet handling? I do not know, and I am not going to dress a guess up as fact — inventing a primitive is how a detection post turns into misinformation.

Worth separating too: "nearly 1,000 switches compromised" is not "nearly 1,000 organizations." One flat network with a mismanaged management VLAN can contribute a dozen devices to that number. The count says the campaign had reach. It says nothing about the size of a typical victim.

How I Handle That Gap

I frame the mechanics sections as what switch-plane compromise generally looks like — the classes of artifact a management-plane compromise leaves behind on hardware in this family, whoever's bug opened the door. That framing is honest, and more usefully, it survives the next GS1900 bug. Which is the point.

The checks hold regardless of the primitive: root-equivalent access to a switch's management plane means the attacker had to touch config, accounts, and forwarding state. Three surfaces. Look there.

Why a Hijacked Switch Is Worse Than a Hijacked Server

The Management Plane Is the Trust Anchor

A switch's management plane is where the network's own decisions get authored: VLAN membership, management access ACLs, SNMP communities, NTP and DNS servers, port mirroring, and sometimes the 802.1X or ACL policy for the whole access layer.

Think about what that buys an attacker. You no longer need to break into the endpoint — you own the substrate the endpoint trusts. NTP shifts and certificate validation windows get interesting. DNS changes redirect more quietly than any host-based redirect ever could. And the switch's own configuration is the evidence you would use to detect the change, which is now attacker-controlled.

That is why I rank switch compromise above server compromise at the same privilege level. A server gives an attacker a foothold. A switch gives them the terrain.

Flat L2 Reality

Most access networks I audit are flatter than the diagram says. The management VLAN exists in the design doc, and the helpdesk can still reach the admin UI from the user subnet because someone opened a rule during an incident three years ago.

On a flat L2 segment, one owned switch buys a lot:

• Transparent redirection — ARP and gateway behavior is a forwarding decision, and forwarding decisions are what you now own.
• Mirroring — a SPAN session pointed at an attacker-reachable port turns your switch into a free TAP. No agent, no EDR alert, no host artifact.
• Quiet DHCP/DNS interference — if the switch is also the gateway or the DHCP relay, responses are just configuration.

None of it requires the endpoint to run anything the endpoint was not already running.

The Detection Asymmetry

Servers have EDR, auditd, CloudTrail, and someone on call who has actually opened a dashboard this quarter. Switches have a syslog stream into a collector whose single alert rule is "disk above 80%."

The practical problem is not that switch compromise is undetectable. It is that nobody was ever assigned the detection work. Every check below is something a competent network or security engineer can run without buying a product, and most of it automates in an afternoon.

Management-Plane Checks You Can Run This Week

Inventory First

Get the denominator before you go anomaly hunting. You cannot spot a rogue switch if you do not know how many you own.

Collect, per device: model, firmware string, uptime, serial, management IP, and which VLAN that IP lives on. Cross-check against your DHCP leases, ARP tables, and switch MAC tables for GS1900 OIDs you never inventoried. A switch with an undocumented management IP is the single most interesting thing you can find in this exercise.

Reachability sweep for anything answering on switch-like management ports in your management ranges:

nmap -Pn -sV -p 22,23,80,443,161,162,830 --open 10.20.10.0/24

Keep that output. It becomes your baseline for the reachability audit.

Reachability Audit

Per switch, one question: which subnets can actually open the admin UI?

If the answer includes your general user VLAN, your VPN pool, or — worse — anything routed from the internet, you have a finding that outranks the CVE. A management interface reachable from a thousand laptops is an authentication problem that password policy cannot fully solve.

Map it two ways: from the network side (firewall rules and ACLs on the management SVI), and empirically (from a user-VLAN host, hit the UI and confirm you get a reset rather than a login page). Run the empirical test. Design documents lie, and an ACL applied in the wrong direction is a classic.

Account and Session Review

Pull the local user table and look for anything you did not create:

• local accounts at the highest privilege level
• accounts with no recorded last-login
• session source addresses that are not your jump host
• authentication from a subnet that should never originate management traffic

show users
show running-config | include username
show logging | include login

Treat "an account exists that ops did not create" as a confirmed finding, not a maybe. There is no benign explanation for an undocumented admin on an access switch.

Uptime Resets as a Signal

A reboot is the cheapest way to clear volatile state, so a switch that rebooted outside a maintenance window deserves a config diff immediately. Convert uptime to a boot timestamp and compare it against your change calendar.

show system
show version

Write the boot timestamp down. If the device claims nine days of uptime and your last change window was two months ago, something else restarted it.

Configuration and Firmware Tampering Checks

The Config Diff Shortlist

Once you have a baseline, diff these fields first, in this order:

Why Mirroring and ACL Edits Top the List

Mirroring is the quietest useful change on that list. It does not alter a single packet's path, it produces no user-visible symptom, and it turns your switch into a collection point. Nothing else gives persistent passive visibility with zero operational noise.

Management ACL edits come second because they remove a restriction rather than add anything. Nobody notices the absence of a deny rule. And whoever made the change usually controls the syslog destination too, so it may not be logged anywhere you can see.

Firmware and Boot Integrity

Confirm the running image string, not the image string in a ticket. Then compare against the build Zyxel names in its advisory for your specific model.

show version

Record two things: the running firmware version, and the boot/image filename if your firmware exposes it. A device reporting the expected version but booting an unexpected image name is a different problem than an outdated device, and it is worth knowing which one you have.

I have not verified the patched version strings for each GS1900 model — the reporting I have does not name them. Get those from the vendor advisory, not from any blog post, including this one.

A Baseline-and-Diff Workflow

What matters is not a one-off dump. It is: pull config, normalize, store, diff against yesterday.

Two implementation notes that save you a week of noise:

1. Normalize first. Strip or mask volatile lines (uptime, timestamps, counters, session IDs). Without that, every snapshot differs and you will mute the alert within two days.
2. Use your actual transport. If your firmware exposes SSH, use it. If it only offers a web UI config backup, drop that file into the same directory structure — the diff is the deliverable, the transport is an implementation detail.

Watching the Wire: Indicators Without Endpoint Agents

SPAN/Mirror Abuse

A mirror session has a destination port. That port should be a monitoring appliance, and it should sit on a monitoring VLAN. If the destination is a random access port in a user-facing IDF, you just found your exfiltration path.

Check: list mirror sessions, then identify what is on the destination port physically or via the MAC table. An unknown MAC on a mirror destination is a high-confidence indicator.

MAC Table and ARP Drift

Two signatures worth baselining:

• The same MAC on two access ports within a short window — a forwarding anomaly or a duplicated device.
• Gateway MAC changing — duplicate-gateway symptoms that users report as "the network is flaky." They get intermittent failures; you get a ticket with no reproducible cause.

Baseline MAC counts per port. A port suddenly carrying ten times its historical MAC count is either a new downstream switch (ask) or something doing forwarding tricks (worry).

Management Traffic From the Wrong Direction

Management traffic has a direction: jump host to management VLAN. Anything else is a question.

The highest-value check here is SNMP. Enumerate community strings and v3 users, then compare against the source addresses your collector actually polls from. Any polling source you did not authorize is a confirmed problem.

## Read-only sanity poll; replace community with a value from your vault
snmpwalk -v2c -c "$COMMUNITY" 10.20.10.11 1.3.6.1.2.1.1.3.0
snmpwalk -v2c -c "$COMMUNITY" 10.20.10.11 1.3.6.1.2.1.17.4.3.1.2

The first OID is sysUpTime — useful for the reboot check across a whole fleet at once. The second is the bridge forwarding table port column, which lets you spot a MAC showing up on unexpected ports. SNMPv1/v2c hands you this data with no authentication beyond the community string, which is exactly why that string deserves the same treatment as a password.

Symptom to Check Mapping

Building a Repeatable Check Instead of a One-Off Hunt

Pull, Commit, Diff

The smallest useful automation for a switch fleet is a cron job and a git repo. Hourly is fine. Daily is fine. It just has to actually run.

#!/usr/bin/env bash
## Scoped config snapshotter for a switch fleet.
## Requires: ssh key auth to the management plane, git repo initialised at $REPO.
set -euo pipefail

REPO="${REPO:-$HOME/switch-configs}"
STAMP="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
OUT="$REPO/snapshots/$STAMP"

SWITCHES=(
"10.20.10.11"
"10.20.10.12"
"10.20.10.13"
)

mkdir -p "$OUT"
cd "$REPO"

for sw in "${SWITCHES[@]}"; do
# Transport varies by firmware; adjust the remote command to your CLI.
if ssh -o BatchMode=yes -o ConnectTimeout=10 "netops@${sw}"      "show running-config" > "$OUT/${sw}.raw" 2> "$OUT/${sw}.err"; then
  # Normalise: drop volatile lines so diffs stay meaningful.
  grep -viE 'uptime|current time|last (login|reset)|session id'     "$OUT/${sw}.raw" > "$OUT/${sw}.cfg"
  rm -f "$OUT/${sw}.raw"
else
  echo "FETCH_FAILED $sw $(date -u +%FT%TZ)" >> "$OUT/fetch.log"
fi
done

git add "snapshots/$STAMP"
if git diff --cached --quiet; then
echo "no config changes at $STAMP"
else
git commit -q -m "switch config snapshot $STAMP"
fi

Why bash and git: the audit trail is free, review is free, and git log -p on a config file beats most commercial network config managers I have used.

What you want out of this is a diff a human reads in five seconds. A suspicious one looks like this — illustrative, not captured from a live device:

--- a/snapshots/2026-11-08T02:00:00Z/10.20.10.11.cfg
+++ b/snapshots/2026-11-09T02:00:00Z/10.20.10.11.cfg
@@ mirror @@
-mirror session 1 destination interface 1/0/24
+mirror session 1 destination interface 1/0/23
+mirror session 1 source interface 1/0/1-1/0/12 both
@@ snmp @@
-snmp-server host 10.20.10.50 traps version 2c netmon
+snmp-server host 10.20.99.7 traps version 2c netmon
@@ users @@
+username svc-backup privilege 15 encrypted <redacted>

Any single line there is worth a phone call. All three in one snapshot is an incident.

Alert Rules Worth Keeping

Alert on these and almost nothing else:

• config hash changed outside a change window
• a new local user, or a privilege level change
• mirror session added or destination changed
• management ACL modified
• SNMP community, v3 user, or trap destination changed
• syslog destination changed
• boot timestamp moved backwards
• a management IP answered from a source subnet outside the allowlist

Everything else — port up/down flapping, link errors, counter drift — gets muted within a week. Flapping is a monitoring problem, not a compromise problem, and mixing the two is how your compromise alert ends up in the muted channel.

Response Order When You Think a Switch Is Owned

Sequence Matters

1. Preserve. Capture running config, startup config, show version, boot timestamp, user list, and the syslog buffer if the device keeps one. Copy, do not move.
2. Isolate management access. Not the data plane — the management plane. Cut the ACL down to your jump host, or disable remote management entirely and go console.
3. Then patch.

Patching first feels productive and destroys your evidence. A rebooted, upgraded switch has fresh uptime, a possibly rewritten config, and no sessions to review. If the attacker left persistence in the form of a local account or a mirror session, patching the bug does not remove it — and now you cannot prove what was there.

What Not To Do

• Do not treat the device's own logs as sole proof. The compromised device is a hostile witness. Corroborate with your collector, your firewall, and your jump host records.
• Do not reboot before capturing the running config. The running config is the state; the startup config may not match it.
• Do not assume the config you see is what was running during the compromise window. Diff against your last known-good snapshot instead — which is why the git baseline above matters so much.

Credential Rotation Scope

Rotate everything that authenticated to that management plane, not just the switch's local account:

• local switch accounts
• the SNMP communities and v3 credentials used by that device
• RADIUS/TACACS+ shared secrets if the device used them
• any credential in a script, Ansible vault, or RMM tool that touches that fleet
• jump host credentials used for the same fleet

The usual failure is rotating the switch password and leaving the automation service account — often privilege 15 — untouched.

Post-Patch Hardening That Actually Reduces Repeat Risk

Get the Management UI Off General-Purpose VLANs

A management VLAN plus a jump host plus a deny-by-default rule is the highest-value change on this list. It is also the one most likely to get blocked politically, because it breaks the helpdesk's habit of clicking the switch UI from their desks. Do it anyway, and give them a jump host.

Concretely: management SVI in a dedicated VLAN, no routing from user or VPN subnets, access through a bastion with session recording. Then verify from a user-VLAN host that the UI is unreachable — not just that a firewall rule exists.

Disable or Tighten Legacy Management Protocols

• Telnet off. SSH with key auth where the firmware supports it.
• SNMPv1/v2c off if you can; if you cannot, treat the community string as a password, unique per device, and restrict the polling source in an ACL.
• HTTP off, HTTPS on, and check the certificate — a self-signed cert on a management plane is a downgrade the attacker can use.
• Disable any cloud or remote-management convenience feature you are not actively using.

Every one of those is authenticated-and-logged access, which is the property that matters. If you cannot tell who logged in and from where, you have no detection story.

My Ranking, With Reasoning

1. Management-plane exposure reduction. Highest leverage, because it addresses the precondition for the whole class. A switch nobody can reach is a switch nobody can own remotely. It also survives the next zero-day.
2. Firmware currency. Necessary, and the reporting says a fix exists — but patching is a per-CVE race you eventually lose. It is a control, not a strategy.
3. Monitoring. Valuable, but a config diff on a fleet you cannot patch is a stream of bad news you have no resources to act on. Build it after you have narrowed the blast radius.

If you can only do one thing this quarter, narrow the reachability. Firmware patching without reachability reduction means you are one advisory behind forever, and GS1900 shows what that costs.

What I Confirmed vs What I Did Not Test

Confirmed

• Public reporting dated 2026-11-04 and 2026-11-05 describes a Zyxel GS1900 zero-day exploited in the wild, affecting nearly 1,000 switches, with a vendor firmware fix available.
• The architecture claims — that a switch management plane holds config, auth, and forwarding state, and that SPAN, ACL, SNMP, and NTP/DNS changes are the high-signal fields to diff — are standard switch behavior, not specific to this incident.
• The SNMP OIDs above are standard MIB-II and BRIDGE-MIB objects, not vendor extensions.
• The bash snapshot script is logic I run in substance on comparable fleets; the remote command string is the part that varies by firmware.

Inferred, Not Verified

• That the exploited primitive was reachable from a broad network position. Likely, given the volume, but unconfirmed.
• That mirroring or config tampering was used post-exploitation. It is a general pattern for switch compromise; I have no evidence it happened here.
• That the affected population skews toward devices with exposed management interfaces. I suspect so, but the reporting does not say.

Explicitly Untested

• The actual exploitation primitive. I do not know it, and my source material does not describe it.
• The affected firmware range and the exact patched version per GS1900 model.
• Whether in-the-wild activity continued after the fix shipped, or whether the same actor holds follow-on access in victim networks.
• Whether the ~1,000 figure counts devices or victims, and how it was measured.

Do not promote any of the inferred items to fact when you write your own incident notes. If you need those answers, go to the vendor advisory and your own device telemetry.

Further Reading

• Vendor advisories (primary source): Zyxel Security Advisories — check the GS1900 entry for the affected-model and patched-firmware matrix. I have deliberately not reproduced version numbers here because I could not verify them against the advisory.
• Vendor firmware and documentation: Zyxel Support / Download — GS1900 firmware images plus the per-model CLI reference guides. The CLI reference for your exact build is the authority for the command syntax I flagged as representative.
• Incident reporting: BleepingComputer, "Zyxel fixes zero-day exploited to hack nearly 1,000 network switches," 2026-11-04 — report link.
• Additional reporting: CyberSecurityNews, "Hackers Exploit Zyxel GS1900 Zero-Day in the Wild to Hijack Network Switches," 2026-11-04 — additional report link.
• SNMPv3 framework (spec): RFC 3411 — the architecture behind the "turn off v1/v2c" recommendation; handy when you have to justify it to a vendor whose NMS only speaks community strings.