Session CRT-20260720 — 20 July 2026

I want to start with the decision, not the CVE label.

The SOC has a real trade-off tonight: hunt first for JSP webshells across Cisco Unified CM and preserve evidence of a possible pre-patch intrusion, or patch immediately and accept that we may lose the traces needed to prove scope. One path extends exposure. The other may erase the crime scene.

Before we anchor on either, I want the room to resolve three questions:

First: is there enough evidence of active exploitation to justify treating this as incident response, not routine vulnerability management?

Second: can we do a fast, evidence-safe collection that does not meaningfully extend the exposure window?

Third: what does the SOC shift lead tell leadership tonight — “we patched,” “we hunted,” or “we preserved and patched in sequence”?

Alex, I’ll want exploitability and what artifacts matter most. Lena, I’ll want confidence on exploitation and actor behavior. James, you’re the closer on the operational sequence. Pierre and Sofia, stay close: voice-stack downtime and evidence preservation both have business and regulatory consequences.

What changed here is that the room now has a much sharper distinction between “all Cisco Unified CM systems” and the narrower but urgent exposure: Unified CM or Unified CM SME nodes with WebDialer enabled and reachable from untrusted networks. Alex and Lena both converged on the same operational picture: if WebDialer is exposed, the priority is not a leisurely patch cycle. It is immediate containment, rapid preservation of volatile evidence, then upgrade. The key reason is that the reported chain is not just theoretical SSRF; the corpus describes file write, rogue Axis/JSP components, and command webshell behavior, with evidence that public PoC logic was quickly replayed in the wild.

The confidence level also tightened. Lena is comfortable saying active exploitation is real, and moderately confident that the pattern looks opportunistic and automated, including Tor-based sweeps. But she rightly held the line against overclaiming: we do not have enough in this packet to call it one named campaign, to assign a specific actor, or to say that every exposed enterprise is already persistently backdoored. The webshell capability proves follow-on access potential; it does not prove the final objective.

Alex gave us useful hunting anchors for Cisco: WebDialer and Axis paths, suspicious WSDL/service-listing activity, encoded hostname or file-style payloads, traversal indicators, recent JSP/JWS writes, Axis descriptors, and filesystem changes under relevant platform-services or Axis webapp locations. Just as important, he flagged fragility. Logs may rotate, service restarts and patching may overwrite application trees, and attacker cleanup can erase the compromise story. That means “patch now” and “preserve enough first” are not contradictory; they have to be sequenced tightly.

One issue needs correction before we rely on the runbook. James was asked for the Cisco Unified CM shift-lead sequence, but his answer pivoted into SimpleHelp, OIDC, technician sessions, and CVE-2026-48558. That may be a valid runbook for a different incident, but it cannot be accepted as the Cisco decision procedure as written. The next step is therefore to challenge that mismatch directly and force the runbook back onto CVE-2026-20230, WebDialer, Unified CM evidence preservation, isolation, patching, hunting, and credential rotation.

The important correction is that James has pulled the runbook back onto the actual Cisco Unified CM issue. The earlier SimpleHelp/OIDC material is out of scope for this roundtable and should not be carried forward into decisions on CVE-2026-20230. For tonight’s CUCM/SME decision, the working sequence is now: contain exposure first, preserve evidence quickly, then move to the Cisco fixed release path — with a lower threshold for treating the host as potentially compromised if WebDialer was exposed.

The operational shape is also clearer. The first move is not to start with deep hunting while the service remains reachable. It is to block internet access to CUCM/SME, restrict access to trusted admin or VPN ranges, or disable WebDialer if edge filtering cannot be done cleanly. Then the SOC has a short preservation window: snapshot if possible, collect CUCM and platform logs, Tomcat/web access data, WebDialer activity, Axis artifacts, JSPs and hashes, suspicious web paths, process and listener state, outbound connections, and recent file writes. After that, patch to the relevant Cisco fixed release path: 14SU6 for release 14, or 15SU5 / COP1 path for release 15.

The caveat is that this is a corrected defensive sequence, not proof that any specific CUCM node is compromised. But James’s escalation criteria are intentionally strict: internet-facing WebDialer, missing logs, unknown Axis services, new JSPs, suspicious files under platform-services, webshell-like command execution, or unexplained outbound traffic all push the team away from “routine patch” and toward “isolate, preserve, patch or rebuild, and investigate as compromised.”

That tees up the next layer of the discussion. We now need Maya to be very specific about what evidence matters before it disappears, Pierre to translate the containment choice into business impact for voice operations, and Sofia to clarify what legal or regulatory risk is created if a team patches first and only later realizes it may have overwritten evidence.

What sharpened here is that “patch now” and “preserve evidence” are not competing slogans; they are a sequencing problem under pressure. Maya’s key point is that if the reported exploitation chain has already landed a JSP webshell under /platform-services/axis2-web/, then fixing CVE-2026-20230 may close the original WebDialer SSRF path but not remove the attacker’s later command-execution foothold. That makes the pre-patch evidence window valuable: VM snapshot if feasible, logs, file metadata, hashes, and suspicious JSPs copied without opening or executing them.

Pierre framed the business side in a useful way: blocking external access or disabling WebDialer should normally be treated as a bounded feature/access interruption, not an assumed collapse of enterprise telephony. There may be helpdesk noise, remote-user friction, and click-to-call or call-center workflow degradation, and we still need local data to quantify that. But his risk comparison is clear: temporary WebDialer disruption is easier to justify than leaving an unscoped webshell on a Unified CM system, especially with public PoC code and active exploitation reported.

Sofia added the legal-evidence discipline that should sit beside the technical response. The organization needs enough contemporaneous documentation to later explain what it knew, when it knew it, what it preserved, what it changed, and why. That means timelines, system state, WebDialer exposure, patch records, log exports, configuration backups, suspicious paths, artifact hashes, and a clear emergency-change rationale. The caveat is important: none of this says the team must delay containment indefinitely. It says that if preservation is limited, the reason should be documented rather than discovered later as a gap.

The next question is the necessary counterweight. We have heard the preserve-first case; now we need to define the exception case. Alex is going to argue when the SOC should skip pre-patch JSP hunting and patch immediately, even if that means some forensic traces may be lost.

The trade-off just got more explicit: there are conditions where evidence preservation has to yield to exposure reduction. Alex’s argument is that if WebDialer is enabled, the CUCM node is reachable from untrusted networks, and the team cannot isolate it quickly, then the priority should shift from “hunt first” to “patch or disable immediately.” The reason is technical, not just operational anxiety: if the reported chain really includes active public exploitation, SSRF through WebDialer, rogue Axis deployment, JSP writing, and command webshells, then every minute spent carefully looking for artifacts may also be a minute in which the file-write path remains available.

The hard triggers he named are useful because they move this away from vague urgency. Inbound activity against WebDialer, WSDL, or Axis endpoints from unknown sources; file:// or encoded-hostname patterns; suspicious writes under platform-services or Axis locations; unexpected JSP or JWS files; new Axis service descriptors; unexplained CUCM outbound traffic; missing or rotated logs; and, importantly, no ability to block untrusted access inside roughly five to ten minutes — any of those can justify closing the door before completing a careful JSP sweep. We should preserve the caveat: the packet cites CyberBrief, CISA KEV, Cisco, and NVD as the basis for active exploitation and WebDialer dependency, but we have not independently validated every reported attacker technique in this room. Still, for decision-making, Alex is saying the combination is enough to act when exposure is live.

The practical middle ground is not “collect nothing.” If there are only ten minutes, the room is converging on a minimum viable evidence mindset: capture the obvious indicators, relevant logs, file listings or metadata for suspicious Axis/WebDialer paths, hashes or copies if safe, and network context — but do not let that become a reason to leave the exploit path open. That leads directly into the next problem: in the ugly real-world case with no clean snapshot, WebDialer enabled, internet exposure, and only two SOC people on shift, what sequence actually balances containment, patching, and enough evidence to support later investigation?

James has now turned the abstract incident-response dilemma into a clock-driven runbook. In the worst case — no clean snapshot, WebDialer enabled, some internet exposure, and only two SOC analysts — his answer is not “forensics first” or “patch first” as a slogan. It is: reduce reachability immediately, grab only the artifacts most likely to prove or disprove the reported chain, and keep reassessing containment at each time marker.

The important refinement is the split-team first ten minutes. One person narrows inbound access at the firewall or load balancer to trusted admin or VPN ranges, and if that cannot happen quickly, disables WebDialer. The other performs a lightweight evidence pull: CUCM version, WebDialer state, admin and user changes, active sessions and processes, listening ports, recent outbound connections, and recursive file listings with hashes and timestamps under the Axis, JSP, and platform-services web paths. That is a practical compromise: it preserves evidence tied to the alleged WebDialer SSRF, rogue Axis service, JSP writer, and webshell path without leaving the door open for a long forensic collection.

By thirty minutes, James makes containment the pivot. If exposure is controlled, collection continues into CUCM application, security, system, and web logs, suspicious JSPs, Axis descriptors, and recently modified files. If exposure is not controlled, collection gives way to disabling WebDialer. By sixty minutes, the direction is toward the fixed CUCM release path — 14SU6 for release 14, or the appropriate fixed path for release 15 — or maintaining WebDialer disabled where patching cannot yet be completed. We should note that this is still a response model based on the reported exploit chain, not a fully verified finding from this room that every listed artifact will exist in every compromise.

That sets up the next question cleanly: if someone argues this should remain a preserve-first, patch-second case, they now have to answer Alex and James’s shared exception. When WebDialer is enabled and reachable from untrusted networks, does preserving evidence still justify delaying exposure reduction, or has that condition crossed the line into immediate containment?

Maya has narrowed the disagreement in a useful way: “preserve first” is not a universal rule here. It only applies if the team can immediately remove untrusted reachability while preserving evidence. If WebDialer remains exposed and the SOC cannot isolate it inside that five-to-ten-minute window, her position now aligns with Alex and James: containment takes priority, meaning disable WebDialer or patch immediately, then investigate what may already have been planted.

The important caveat is that patching is not cleanup. Maya’s malware lens keeps the room from confusing “entry path closed” with “host trusted again.” The reported chain includes unauthenticated WebDialer SSRF, public PoC-driven activity, automated Tor-routed sweeps, rogue Apache Axis deployment, JSP file-writer staging, and command JSP webshells, with CVE-2026-20230 also in CISA KEV. Those facts support urgency, but they also raise the likelihood that the compromise evidence may live outside the vulnerable code path. So the practical compromise is not evidence versus containment; it is “do not let evidence collection delay containment, but grab the highest-value artifacts if they are immediately available.”

That gives the SOC a cleaner operating rule for this incident: isolate first if that can be done right away; otherwise disable or patch now. After that, preserve and inspect the likely persistence locations and logs — especially web and application logs, /platform-services/axis2-web/, unexpected JSP or Axis artifacts, hashes, ownership, and timestamps. The room should also keep the uncertainty intact: seeing exposure and active exploitation pressure does not automatically prove this CUCM instance is compromised, but it is enough to justify urgent containment and targeted artifact review.

The next question naturally moves from technical triage to escalation discipline. If the SOC disables or patches under pressure and then finds indicators that could imply access, persistence, or data exposure, the shift lead needs to know whether Legal and privacy get paged tonight or whether this can wait for a morning briefing. Sofia, that threshold is where we turn next.

Sofia has turned the escalation question into a practical overnight decision rule: Legal and privacy do not need to be paged merely because CUCM was exposed or probed, but they should be paged tonight as soon as the facts move from “attempted exploitation” toward probable unauthorized access, personal-data impact, or evidence-loss risk.

The strongest trigger is evidence of webshell or command execution on CUCM. In her framing, that is no longer just vulnerability management; it is a probable unauthorized-access event. The same applies if call-detail records were touched in a suspicious way — queried, exported, deleted, or accessed by an unusual process or account — because CDRs can reveal callers, callees, extensions, timestamps, and communication patterns. Authentication and administrative logs also matter: a new admin account, privilege change, successful suspicious login, service-account misuse, impossible travel, failed-then-successful pattern, unknown source, or log clearing should move the shift lead from routine documentation to immediate Legal/privacy involvement.

The important nuance is that Sofia also treats evidence preservation as an escalation trigger. If patching, rebooting, log rotation, or rebuilding could destroy relevant logs or snapshots before they are exported, then Legal/privacy should be brought in even before breach confirmation. That keeps the team from waiting for perfect certainty while losing the very material needed to make a defensible determination.

Where the record stays limited to failed probes, no successful suspicious authentication or admin activity, no webshell execution, no suspicious CDR or database access, preserved logs, and a documented patch/change record, Sofia’s threshold allows the SOC to document overnight and brief Legal/privacy in the morning. That gives us a cleaner operational boundary for the final synthesis: containment still comes first when exposure is live, but escalation depends on whether there is evidence of execution, data access, suspicious administrative activity, or imminent loss of evidence.