What did SnortML actually see?
Our earlier PHP2Shell mitigation analysis raised a basic question: can an intrusion policy inspect an exploit when the HTTP transaction is encrypted at the firewall? In our Cisco Secure Firewall lab, TLS Decrypt (Resign) made the traffic visible to Snort. We then asked a harder question: what would SnortML detect when a real PHP2Shell proof of concept crossed that inspected path?
The answer deserves more than a success badge or a failure label. SnortML produced verified alerts for SQL-style inputs and a verified block in a separate SQL control. Talos signatures produced verified blocks for two specific PHP2Shell-associated patterns. A working PHP2Shell proof of concept still reached our vulnerable target, and none of its inspected connections generated a SnortML event. That result is a useful demonstration of why Cisco provides several layers of detection and prevention—and why patching remains the finish line.
Three results, one inspected path
lsp-rel-20261028-1849, managed by cloud-delivered FMC. Connection records showed the intended access rule, LAB-NAP-SNORTML, and actual TLS action Decrypt (Resign). The model, policy and traffic path were therefore observable rather than assumed.411:1:13 intrusion events. Under a separate Block policy, a 133-byte multipart SQL-style control produced an actual Block event; clean controls completed without 411:1 events.www-data. In two Alert runs, its nine connections produced no 411:1 event. An unchanged SQL positive control alerted in each same test window. Increasing SnortML’s client body depth from 4,096 to 524,288 bytes did not change that observed PoC result.Local test Talos signatures enforced the tested PHP2Shell patterns. In separate synthetic fixtures, 1:67360:2 blocked the eleventh rate-qualified request, and 1:67375:1 blocked a response-cookie pattern. Those results establish enforcement of those exact rule conditions, not prevention of every PHP2Shell variant.
What we can say: Cisco Secure Firewall exposed the HTTPS traffic to inspection, SnortML demonstrably detected and blocked our SQL-style controls, and Talos rules demonstrably blocked their tested PHP2Shell-associated patterns. We did not demonstrate SnortML detection or prevention of this working PHP2Shell PoC.
The full analysis documents the TLS path, SnortML controls, Talos signatures, real exploit test and claim boundaries.
GO DEEPER · COMPLETE ARTICLEFull technical analysisTLS inspection, SnortML, Talos and the working PoCOpenCollapse
A working PHP2Shell exploit, a reliable SQL control, and the case for Cisco’s layered defenses
Evidence labels: Local test — recorded lab observations; Published — linked vendor documentation.
One path, several ways to recognize a threat
Local test The firewall sat between a lab client and a lab origin. The client connected to an HTTPS virtual address; FTD decrypted the TLS 1.3 session, inspected the HTTP transaction and resigned the connection toward the client. The client verified the presented hostname and signing chain. The origin-facing connection used its own certificate. The decryption rule’s certificate-status match was set to Any for rule selection; certificate verification was not disabled.
We scoped the custom Network Analysis Policy to the lab client and origin host objects and their respective security zones. The SnortML inspector was enabled, and the intrusion policy exposed its verdict through rule 411:1:13. This matters because an enabled access rule or a successful HTTP response alone cannot establish that the ML inspector saw the transaction. We correlated source ports across the client trace, FMC connection and intrusion records, and target logs.
Cisco documents SnortML as a neural-network-based HTTP exploit detector. On Secure Firewall 10.1, it evaluates URL queries, URL-encoded POST data and multipart form data. Cisco also documents a multipattern filter ahead of ML inference and a cache of prior scan results. Those details help explain why inspection depth and an effective NAP matter, but they do not let us infer the internal reason for a missing event from an FMC record alone. Cisco SnortML inspector reference
The 1210CE, interface names and addresses were our lab choices. Supported FTD models and either cloud-delivered or self-hosted FMC can be used for the same validation method, with the interfaces, host objects and routing adapted to the reader’s environment.
SnortML earned its place in the stack
Local test Our first tests calibrated 411:1:13 at Alert against clean and SQL-style requests. Multiple SQL-style candidates produced actual intrusion events, while the paired benign controls did not. Repeated requests did not always yield identical event timing, so we used isolated runs and source-port correlation rather than treating a single quiet request as a product verdict.
We then changed the only enabled rule in a dedicated policy to Block. In the corrected multipart control run, the 133-byte SQL-style request completed TLS and uploaded its bytes but received no HTTP response. FMC recorded 411:1:13 with actual action Block, LAB-NAP-SNORTML, and TLS status Decrypt (Resign). The clean requests before and after returned normally and had no 411:1 intrusion event. A second bracketed Block comparison produced two SQL positive events while the synthetic PHP candidate and its negatives completed without 411:1 events.
These are synthetic SQL-injection-style inputs. We did not use a vulnerable SQL application, so the result is detection and inline enforcement of the tested input, not proof that a database compromise was prevented. It is still a meaningful operational result: Cisco’s ML verdict appeared as a named Snort rule with an event and an effective policy action that we could verify.
Talos gave us targeted PHP2Shell coverage
Published Talos published Snort SIDs 67359, 67360 and 67375 for the disclosed PHP core flaws. We exercised two of those signatures with fixed, non-exploit fixtures over the same decrypted HTTPS path. Cisco Talos PHP2Shell advisory
For 1:67360:2, the installed rule matched a multipart request containing PHP’s default session-upload-progress marker. Its detection filter required more than ten matching requests from a source within five seconds. The first ten matching lab requests completed; the eleventh received no HTTP response, and FMC recorded Block. The rule worked as configured, with a rate condition that must be included in any coverage claim. Snort rule 1:67360
For 1:67375:1, we tested a synthetic server response with the relevant PHPSESSID cookie pattern. The origin wrote the candidate header, but the client received no application response, and FMC recorded a server-to-client Block event. Clean and near-miss cookie responses reached the client without that event. This demonstrated enforcement on the response path. Snort rule 1:67375
Those controls are a strong example of Talos translating threat research into specific, inspectable rules. They do not establish that either signature blocked the later real proof of concept. We ran that PoC under SnortML Alert to observe ML behavior, and we did not perform a separate real-PoC prevention run with the Talos rules.
A real exploit changed the article’s conclusion
Local test To move beyond synthetic bytes, we ran a pinned public PHP2Shell PoC against a disposable ARM64 target using the official vulnerable php:8.4.26-apache image. The target had an internal Docker network, a single Apache worker, a bounded HTTPS listener and a writable proof directory. Its vulnerable runtime and PHP settings were checked before the run. We kept the client and origin traffic inside the isolated lab path.
The PoC process reported that its attempts had failed because it did not see its proof through the client-side channel. The target evidence told a different and more decisive story: each of the two repeat runs produced a new proof file owned by www-data, containing uid=33(www-data). We therefore treat the target-side result as observed code execution. A client-side exit code of 1 did not negate it.
In the first repeat Alert run, nine PoC connections used LAB-NAP-SNORTML and actual Decrypt (Resign). None generated 411:1; a separate SQL control in the same window generated a verified 411:1:13 Alert. We then deployed an increased client_body_depth of 524,288 bytes, up from 4,096, and repeated the bounded test. Again, all nine PoC connections used the intended NAP and Resign rule, the target produced command-execution proof, none of the PoC ports generated 411:1, and the SQL control alerted. The increased depth did not produce a PoC event. It does not show whether the documented filter skipped some input, whether the model scored it below threshold, or whether another inspector behavior mattered.
That is a precise result for this PoC, this PHP build, these policies and these deployed content versions. It is not a statement that SnortML can never detect PHP2Shell or that another payload variation would behave the same way. Cisco’s documented model and inspector settings can change with LSP updates. Cisco SnortML inspector reference
The value of layers you can verify
Local test This lab showed several strengths in Cisco Secure Firewall’s design. TLS Resign made the application bytes inspectable. SnortML supplied a class-oriented detector that produced both Alert and Block outcomes for our SQL-style controls. Talos supplied vulnerability-oriented rules with concrete request and response conditions. FMC exposed the effective NAP, decryption action, Snort ID and actual intrusion action, so we could distinguish an enforced block from a client timeout or an origin write.
The real PoC also showed why none of these layers should be treated as a universal promise. A classifier can remain quiet on a working exploit. A signature can be narrow, directional or rate-qualified. Decryption must match the actual traffic. Talos explicitly recommends upgrading to fixed PHP releases and says temporary controls do not provide comprehensive protection. Cisco Talos PHP2Shell advisory
For defenders, the useful sequence is straightforward: patch the vulnerable runtime; put the actual application path through a correctly deployed inspection policy; validate TLS decryption and effective NAP on a real flow; test Alert and Block with positive and negative controls; read the installed rule conditions; and correlate the client, firewall and origin evidence before making a prevention claim. That is a favorable Cisco story because the layers are concrete, configurable and auditable. It is also a trustworthy one because we can name exactly where our test found a boundary.
Leave a Reply