Verifying a Vendor’s Answer Key the Hard Way: Threat-Modeling a Siemens S7–1200 PLC

Most introductions to vulnerability assessment treat it as a lookup problem: find the device, search a database, copy the CVE ID into a report. Working through a full threat model of a Siemens S7–1200 PLC as part of the CyManII OT Cybersecurity Bootcamp showed why that's not enough — and why the verification step matters more than the search itself.

The Device

The target was a SIMATIC S7–1200 CPU 1212C AC/DC/Relay (part number 6ES7212–1BE40–0XB0), running firmware V4.4. On paper it's a small, unremarkable industrial controller: 75 KB of work memory, a single PROFINET port with no integrated switch, and support for S7 Communication, Modbus, OPC UA, and a built-in web server.

That single detail — no integrated switch — turned out to matter more than any single protocol. With one physical interface and no internal isolation between services, every protocol the device exposes shares the same trust boundary. Whatever segmentation exists has to come entirely from the network around it, not from the device itself.

Classifying an Attack Surface Isn't as Obvious as It Sounds

The first real task was sorting every extracted spec into "physical" or "logical" attack surface. The first pass got two things wrong.

Firmware version and programming package were initially marked as physical attributes — they're not. They don't grant access to anything; they determine which CVEs even apply. That's a logical property, not a physical one.

The network interface caused a second problem. The RJ45 port itself is physical hardware, sure. But "single port, no integrated switch" isn't a hardware fact so much as a topology fact — it defines a trust-boundary implication that has nothing to do with touching the device. That single spec had to be split across both categories.

A third issue surfaced once memory (work, load, retentive) came up: it doesn't fit either category, because it isn't an entry point at all. It describes what happens after an attacker is already in — whether a change survives a reboot — not how they got in. That distinction needed its own category: Impact/Persistence.

The general lesson here isn't really about PLCs. It's that "attack surface" answers how does someone get in, and conflating that with what happens once they're in produces a classification that looks tidy but is quietly wrong.

The CVE List Wasn't What It First Appeared to Be

Two candidate CVEs — CVE-2022–31802 and CVE-2021–32974 — were the starting point for the vulnerability research phase. Both are real, published CVEs. Neither one turned out to apply to this device.

Direct verification against NVD showed CVE-2022–31802 actually describes a CODESYS Gateway Server issue, and CVE-2021–32974 belongs to a Moxa NPort serial device server — two completely different vendors, unrelated to the Siemens S7–1200. Both were dropped from the assessment.

This is the part of the process that's easy to skip and expensive to skip badly: a CVE ID resolving successfully in a database is not, by itself, confirmation that it applies to the device sitting in front of you. It's a reminder that the "product" field in an advisory deserves as much scrutiny as the CVE number itself — especially when working from a secondhand reference rather than a primary source.

The two CVEs that survived direct verification told a more specific story:

• CVE-2024–47100 — a cross-site request forgery flaw in the web interface (CWE-352) that lets an unauthenticated attacker alter the CPU's operating mode, provided a legitimate authenticated user is tricked into the interaction. CVSS 7.1. Affects firmware below V4.7 — this device's V4.4 is in range.

• CVE-2025–24812 — malformed S7comm/ISO-TSAP packets on port 102/tcp causing denial of service (CWE-1286). CVSS 6.5. Same affected-firmware window.

Both were confirmed against the exact part number listed in each advisory — not just the product family name, but the specific 6ES7212–1BE40–0XB0.

Mapping to MITRE ATT&CK Meant Rejecting the Obvious-Sounding Options First

Mapping CVE-2024–47100 to a MITRE ATT&CK for ICS technique looked simple until several plausible-sounding candidates turned out to be wrong on closer reading: Brute Force I/O (concerns physical I/O values, not CPU mode), Modify Firmware (describes replacing firmware entirely, not toggling a mode), Modify Parameter (concerns process setpoints, not operating state). The correct match was T0858 — Change Operating Mode, under the Execution tactic.

CVE-2025–24812 had a similar near-miss: Denial of Control looked right at first — it's filed under "Inhibit Response Function," which matches the tactic — but its actual definition describes an operator being locked out of a still-running process, not a device becoming unresponsive. The correct technique was T0814 — Denial of Service, still under Inhibit Response Function, just not the first one considered.

The pattern across both cases: technique names that sound alike often describe meaningfully different attacker behaviors, and only the definition paragraph — not the label — should decide the match.

Three Risks, Not Just Two CVEs

The final risk assessment deliberately included a third risk that didn't come from any CVE at all: the absence of an integrated switch. A report built only from patchable CVEs implies that patching solves the problem, which isn't true here — some risks are architectural and persist regardless of firmware version.

Risk Evidence Mitigation Unauthenticated CSRF can change CPU RUN/STOP stateCVE-2024–47100, CVSS 7.1Update to firmware V4.7+; until then, restrict web interface access to trusted engineering workstations Malformed S7comm packets cause DoSCVE-2025–24812, CVSS 6.5Deploy ICS-aware intrusion detection (e.g. Zeek with S7comm signatures) on port 102/tcpNo internal segmentation between exposed protocolsDatasheet — single interface, no switchExternal VLAN/firewall segmentation, plus the device's own built-in Read/Write access protection

What This Actually Taught

The recurring lesson wasn't about Siemens specifically — it was about process discipline. A CVE ID resolving in a database doesn't confirm relevance; the product association needs independent verification. Attack surface and impact are different questions and get confused easily. And a datasheet-only assessment has to state its own limitation explicitly — it describes the device, not how it's actually deployed, and any conclusion drawn from it should carry that caveat rather than imply false certainty.

This assessment was conducted as part of the CyManII OT Cybersecurity Bootcamp. No exploitation was performed against a live system — all findings are based on datasheet review and cross-referenced public vulnerability advisories from CISA and NVD.