Real-Time Threat Detection and Response: a Private K-12 School

Executive Summary

The CmdNOC MSP Control Center continuously monitors security events across all 28 JBE Systems client sites via the Meraki API. At Private K-12 School, the portal's Security Intelligence page — fed by the Meraki MX450's IDS/IPS engine — detected and blocked multiple active threat actors targeting the school's network infrastructure. Using the portal's one-click IP block capability, threats that would traditionally require manual firewall access were neutralized in seconds, directly from the NOC dashboard.

The Environment

The the school security stack monitored by the portal includes:

• Meraki MX450 production firewall with IDS/IPS in prevention mode
• Balanced ruleset covering thousands of Snort signatures
• 28 client sites monitored simultaneously via Meraki API
• Real-time security event polling every 5 minutes
• One-click IP block capability via Meraki L3 firewall API
• Known attackers database maintained in portal PostgreSQL

The Threat Landscape

Over the course of active monitoring the portal detected a consistent pattern of external threat actors targeting the school's network. These weren't random background noise — they were active, repeated, targeted attacks against specific vulnerabilities:

Each of these threat actors was identified not through manual log review — but through the portal's automated security event feed pulling live data from the Meraki MX450's IDS/IPS engine.

How the Portal Detects Threats

The CmdNOC MSP Control Center's Security Intelligence page polls the Meraki API every 5 minutes:

GET /organizations/{orgId}/appliance/security/events

Returns: IDS/IPS events including:
- Source IP and destination
- Attack signature matched
- Severity classification
- Protocol and port
- Timestamp
- Action taken (detect/block)

Events are parsed, classified, and stored in the portal database. The Security page displays them in a live feed with:

• Color-coded severity (Critical/High/Medium/Low)
• Attack description from the IDS signature
• Source IP with geolocation context
• Click-to-expand detail modal
• One-click block button per event

Case: The RealTek Injection Attack

Detection

The portal's security feed began showing repeated IDS/IPS alerts from 176.65.139.81:

[CRITICAL] IDS Alert — Meraki MX450
Source:      176.65.139.81 (Unknown ASN)
Target:      the school network
Signature:   RealTek SDK miniigd UPnP SOAP
             command injection attempt
Protocol:    TCP/UDP
Action:      Detected by IDS/IPS
Repeated:    Multiple times across poll cycles

The RealTek SDK vulnerability (CVE-2014-8361 and variants) targets routers and IoT devices running RealTek's miniigd UPnP daemon. A successful exploit gives the attacker remote code execution on the target device — a serious threat in an environment with hundreds of network-connected devices.

Investigation via Cora

The NOC engineer opened the Cora AI console:

"Cora, we're seeing repeated IDS alerts from 176.65.139.81 for RealTek SDK injection attempts. How serious is this and what should we do?"

Cora responded:

"RealTek SDK injection (CVE-2014-8361 and related) is a serious threat targeting the miniigd UPnP daemon in RealTek-based routers and IoT devices. A successful exploit gives the attacker remote code execution. Given that the network has a large IoT footprint — IP cameras, smart classroom devices, and network infrastructure — this warrants immediate blocking. The MX450's IDS/IPS is detecting the attempts, which means prevention mode is catching them at the perimeter. However, blocking the source IP outright via L3 firewall rules eliminates the attack surface entirely and stops consuming IDS processing cycles. Recommendation: Block 176.65.139.81 bidirectionally via the portal's one-click block feature. This creates NOC-BLOCK-IN and NOC-BLOCK-OUT rules at the top of the MX450's L3 rule list, ensuring the IP is denied before any other rules are evaluated."

One-Click Block

From the Security Intelligence page, the NOC engineer clicked the Block IP button on the threat event. The portal executed the block via the Meraki API:

// Portal creates bidirectional block rules
POST /networks/{networkId}/appliance/firewall/l3FirewallRules

Rules created:
[deny] NOC-BLOCK-IN:  176.65.139.81/32 → Any
[deny] NOC-BLOCK-OUT: Any → 176.65.139.81/32

Positioned: TOP of rule list
Priority:   Evaluates before all other rules

Time from detection to block: under 60 seconds.

The IP was simultaneously added to the portal's known-attackers database:

{
  "ip": "176.65.139.81",
  "description": "RealTek injection attempt",
  "blockedAt": "2026-05-04",
  "blockedBy": "Captain"
}

Case: The Active Intrusion — 143.14.200.165

Detection

On May 4, 2026, the portal detected an escalating pattern from 143.14.200.165 — not just probing, but active multi-vector intrusion attempts:

[CRITICAL] Active Attack Detected
Source:      143.14.200.165
Target:      the school network
Pattern:     Multiple signatures firing
             simultaneously
Signatures:  Web application attacks,
             credential stuffing,
             protocol anomalies
Action:      IDS prevention blocking
             individual attempts
Status:      ACTIVE — ongoing attack

Unlike the RealTek probes which were periodic, this actor was actively attempting to breach the perimeter in real time. The Meraki MX450's IDS/IPS was blocking individual attack vectors — but the source IP remained active and persistent.

Immediate Response

No investigation was needed — the pattern was unambiguous. The NOC engineer used the portal's one-click block from the Security page:

[deny] NOC-BLOCK-IN:  143.14.200.165/32 → Any
[deny] NOC-BLOCK-OUT: Any → 143.14.200.165/32

Block applied: 2026-05-04
Status: ACTIVE ✅

The attack stopped immediately. No further events from this IP appeared in subsequent poll cycles.

The One-Click Block Architecture

The portal's firewall block capability was purpose-built for exactly this use case:

NOC Engineer clicks "Block IP"
           ↓
Portal calls merakiFirewall.js
           ↓
GET current L3 rules (read-modify-write)
           ↓
Prepend NOC-BLOCK-IN + NOC-BLOCK-OUT
at top of rule list
           ↓
PUT updated rule list to MX450
           ↓
Save to blocked_ips database table
           ↓
Add to known-attackers.json
           ↓
Block confirmed — under 60 seconds

Safety mechanisms built in:

• Read-modify-write preserves all existing rules
• New rules prepended — never inserted mid-list
• Full snapshot available for rollback
• Database record with timestamp and operator
• Known-attackers.json updated for future reference

Blocked Threats Summary

As of May 7, 2026, the following threat actors have been blocked on the the MX450:

Key Observations

1. Speed of Response

Traditional threat response requires logging into the firewall dashboard, navigating to firewall rules, manually creating deny rules, and verifying the change. The portal reduces this to a single click — under 60 seconds from detection to block.

2. Consistency and Safety

Every block follows the same read-modify-write pattern. There is no risk of accidentally deleting existing rules, no risk of rule ordering errors, and no risk of operator mistakes under pressure. The portal enforces correct procedure every time.

3. Institutional Memory

Every blocked IP is recorded in the portal database with timestamp, operator, and reason. The known-attackers.json file maintains a persistent threat intelligence database that survives portal restarts and migrations. Future sessions have full context on why each IP was blocked.

4. Cross-Site Potential

The same one-click block infrastructure that protects the school can be extended to all 28 JBE Systems clients simultaneously via Meraki's Action Batches API — a single block operation propagated to every client site in one atomic API call. This is on the portal's development roadmap.

5. Defense in Depth

The portal doesn't replace the MX450's IDS/IPS — it complements it. IDS/IPS catches and blocks individual attack attempts at the signature level. The portal's L3 block eliminates the threat actor entirely, reducing IDS processing load and closing the attack surface permanently.

Remaining Opportunities

Conclusion

The CmdNOC MSP Control Center transforms security event monitoring from a reactive, manual process into a proactive, automated workflow. Threats that would previously require a NOC engineer to:

1. Notice an alert in a separate system
2. Log into the Meraki dashboard
3. Navigate to firewall settings
4. Manually create deny rules
5. Verify the change

…are now handled in a single click from a unified dashboard that already has full context on the threat, the network, and the recommended response.

At Private K-12 School — a target-rich environment with 1,500 students, hundreds of IoT devices, and a high-value Microsoft 365 infrastructure — this capability isn't a convenience. It's a critical operational requirement.

"The difference between a security incident and a security event is how fast you respond."

JBE Systems — CmdNOC MSP Control Center v1.7.1 Powered by Meraki + WyeBot + Cisco + Datto + Cora AI noc.commandnoc.com

Case study prepared May 7, 2026 Classification: Internal / Client Shareable