Office VLAN bridged to prod-mgmt — SNMP communities and SMBv1 broadcasts visible

From: Incident Response Lead (SOC on-call)
To: IT Leadership · Network Operations · Infrastructure Security · On-call SOC
Subject: [SEV-2][INC-NET-VLAN99] Office VLAN exposed to prod-mgmt traffic — SNMP community exposure and trunk rollback in progress

Incident: INC-NET-VLAN99 · SEV-2 / P2
Status: Investigating — containment and credential rotation in progress
Classification: Cyber × Network Fusion · VLAN Segmentation Violation · Cleartext Management Credential Exposure
Affected asset: `DIST-A Po2` + prod-mgmt SNMP communities · High criticality
Detected: 2026-04-22 09:32 UTC

SITUATION & SUMMARY

SOC L2 and Network Operations identified a segmentation violation where office workstations on the office segment are seeing traffic from the production management network.

Evidence shows that `VLAN 99`, the prod-mgmt VLAN, was added to `DIST-A Po2` approximately four days ago as part of a trunk allowed-VLAN change. The previous configuration allowed only VLANs `10,20,30`, while the current configuration allows `10,20,30,99`.

A packet capture from an office workstation shows prod-mgmt traffic visible from the office segment, including SNMPv1/v2c traffic with communities `public` and `acme-mgmt`, SMBv1 browse announcements from `PROD-MGMT-JUMP01`, and ARP entries for prod-mgmt IPs appearing on the office workstation. This should be treated as both a network segmentation failure and a cleartext management credential exposure.

SEVERITY & PRIORITY

This is rated SEV-2 / P2 because a high-criticality production management VLAN was exposed to a less-trusted office network, and cleartext SNMP community strings were visible on that segment.

Even if this was caused by a configuration mistake rather than an attacker, the SNMP communities must be treated as exposed. If `acme-mgmt` has write capability, the risk is higher because the capture shows an SNMP set request.

IMMEDIATE CONTAINMENT

* Roll back the `DIST-A Po2` allowed-VLAN list to remove `VLAN 99` from the office trunk path.
* Preserve the current and previous trunk configuration before making changes.
* Confirm `VLAN 99` is no longer present on office-facing trunks after rollback.
* Verify office workstations can no longer see ARP, SNMP, or SMB traffic from the prod-mgmt subnet.
* Temporarily block or restrict office-to-prod-mgmt traffic at Layer 3 controls while validation is in progress.
* Treat SNMP communities `public` and `acme-mgmt` as exposed and begin credential rotation.
* Disable or remove the `public` SNMP community where present.
* If possible, move management monitoring from SNMPv1/v2c to SNMPv3 with authentication and encryption.

NETWORK INVESTIGATION

* Review the change record from four days ago that modified `DIST-A Po2`.
* Determine why `VLAN 99` was added and whether the change was approved, mistyped, or copied from another trunk.
* Identify all trunks where `VLAN 99` is currently allowed and confirm it is only present on intended management paths.
* Check for similar allowed-VLAN drift on other distribution and access switches.
* Review STP, trunk, VTP, native VLAN, and allowed-VLAN state for the affected path.
* Search NetFlow, firewall, switch logs, and management-plane logs for office hosts accessing prod-mgmt systems during the exposure window.
* Review SNMP logs on prod-mgmt routers and devices for GET or SET activity from office VLAN sources.
* Determine whether any office user or host captured, used, or attempted to use the exposed SNMP community strings.

CREDENTIAL / MANAGEMENT PLANE RESPONSE

* Rotate the `acme-mgmt` SNMP community across affected prod-mgmt devices.
* Remove or disable `public` SNMP community strings.
* Confirm whether any SNMP community had read-write privileges.
* Review configuration changes on prod-mgmt devices during the four-day exposure window.
* Check whether the observed SNMP set request was legitimate monitoring activity or unauthorized management activity.
* Validate management ACLs so SNMP is accepted only from approved monitoring hosts.
* Consider SNMPv3 migration for sensitive management devices.

EVIDENCE PRESERVATION

* Preserve the current `DIST-A Po2` configuration and the pre-change configuration.
* Preserve the packet capture showing SNMP communities, SMBv1 broadcast traffic, and prod-mgmt ARP entries visible on the office segment.
* Preserve ARP output from the office workstation showing prod-mgmt IPs on `Vlan10`.
* Preserve change-management records and timestamps for the trunk modification.
* Preserve relevant switch logs, AAA logs, SNMP logs, NetFlow, and firewall records for the four-day exposure window.

RECOVERY & NEXT STEPS

* Validate that office VLAN segmentation is restored and prod-mgmt traffic is no longer visible from office endpoints.
* Complete SNMP community rotation and remove legacy/default communities.
* Disable SMBv1 on prod-mgmt systems where possible.
* Update trunk configuration standards so management VLANs are not allowed on office-facing trunks.
* Add configuration compliance checks for high-risk VLANs such as prod-mgmt.
* Add alerting for management VLANs appearing on unauthorized trunks.
* Review change-control procedures for trunk allowed-VLAN updates.

STAKEHOLDER COMMUNICATION

* Notify Network Operations that this is an active segmentation violation requiring rollback and validation.
* Notify Infrastructure Security that SNMP communities were visible on a less-trusted segment and should be treated as exposed.
* Notify IT Leadership that this appears to be a configuration-driven exposure, but credential rotation and management-plane review are required.
* Notify system owners if any prod-mgmt devices show suspicious SNMP or SMB access during the exposure window.

DO NOT

* Do not only flush ARP entries on office workstations and close the incident.
* Do not assume this is harmless because it appears to be a misconfiguration.
* Do not leave `VLAN 99` allowed on office-facing trunks during investigation.
* Do not rotate SNMP communities without first preserving evidence of what was exposed.
* Do not continue using `public` or cleartext SNMPv1/v2c communities for prod-mgmt devices.
* Do not ignore the SMBv1 broadcast exposure; it indicates legacy management traffic is visible outside the intended segment.