DEV Community

OnaEiuspkz
OnaEiuspkz

Posted on

Visibility Before Detection: What the GeoServer Case Teaches About Out-of-Band Telemetry

#security #geoserver #cve202436401 #attacksurface

Visibility Before Detection: What the GeoServer Case Teaches About Out-of-Band Telemetry

The most quoted number in CISA advisory AA25-266A is the dwell time: about three weeks of malicious activity before the agency's endpoint detection tool raised alerts. The more instructive detail is why the alerts arrived when they did, and which public-facing systems produced no alerts at all.

How the activity finally surfaced

The advisory states that detection came from an endpoint tool generating alerts on a SQL server, where a suspicious file had been transferred. That alert prompted containment, an investigation, a request for CISA assistance, and the eventual discovery that an earlier compromise had occurred on a public-facing application host. The application host itself had not produced the signal; the downstream server did.
The advisory also notes that one public-facing system lacked endpoint protection, and that alerts were not continuously reviewed. Either condition is sufficient to explain a long dwell time. Together they explain why a compromised public service remained invisible while an attacker used it as a bridgehead.

The visibility problem is an exposure problem

Coverage gaps are easiest to find when the asset list is trustworthy. The same scanning approach that measures exposure can be used to test whether every public-facing service is covered by a logging and detection control, because an incomplete inventory guarantees an incomplete coverage map.
Current measurements show how much public-facing surface exists in this product family alone:
| Query | Exact count |
| --- | --- |
| app="GeoServer" | 57,663 |
| app="GeoServer" && service="http" | 47,664 |
| app="GeoServer" && port="8080" | 9,770 |
| app="GeoServer" && port="8443" | 625 |
The relevant subsets for a coverage review are not countries or ports but ownership: which of these services, scaled to your own estate, are production, which are test, and which are simply forgotten. A forgotten host is the most likely place to find both an uncovered log source and an unpatched component.

Building the telemetry the advisory implies

  • Centralise and aggregate logs out of band. The advisory recommends this explicitly, for a practical reason: an attacker who controls an application host can alter or delete logs stored on that host. Storage elsewhere preserves the record.
  • Log verbosely where it matters. Web server access logs, application errors and authentication events on public listeners are the raw material for reconstructing a reconnaissance-to-exploitation sequence.
  • Ensure every public-facing service has an endpoint or host-level detection control, and that the control's alerts reach a queue someone reads.
  • Retain web logs long enough to cover your dwell-time assumption. Three weeks of activity is unremarkable for an intrusion, and log retention shorter than that makes the same reconstruction impossible.

What detection would have looked like

The advisory describes the activity that was later reconstructed: scanning of the public application, exploitation to gain code execution, download of open-source tooling, and lateral movement. Each step had an observable artefact on a host that should have been instrumented. The gap was not analytical difficulty; it was the absence of a sensor positioned to see the traffic.

Conclusion

Detection is downstream of visibility, and visibility is downstream of inventory. The three-week gap in this case is not a story about sophisticated tradecraft. It is a story about a public-facing service with no endpoint protection, alerts that were not continuously reviewed, and logs that were not aggregated where an attacker could not reach them. All three are fixable without new technology, and all three start with knowing which hosts you are defending.

References

Top comments (0)