Plum Island: Searing Spring Release

This release is focused on a simple operational question: once you scan continuously, how do you turn the results into information you can observe, search, qualify, and reuse?

Plum Island is not meant to be only a job dispatcher or a scan result viewer. Its value is in building a structured memory of exposed services over time. This version improves that memory: what Plum extracts, how observations are indexed, and how operators can build meaningful signals.

From scans to observations

Raw scan output is useful, but it is difficult to query at scale and need knowledge. Plum turns recurring scan results into structured observations:

• Open ports;
• Service banners;
• HTTP titles and server headers;
• Selected HTTP header names and values;
• Favicon hashes/names;
• TLS certificate informations (subjects, issuers, SANs, and fingerprints);
• Computed tags.

This is the difference between “we scanned this IP” and “we can answer what is exposed, where, since when, and with which indicators”.

This version makes this observation layer richer.

HTTP headers as searchable signals

The largest visible improvement is HTTP header acquisition.

Thank’s to Dominique Righetto maintaining this excellent ressources for OWASP https://owasp.org/www-project-secure-headers, Plum now collects curated HTTP header names and values, with 86 headers supported in this release. These headers are not stored as passive decoration. They become searchable fields in the structured index you may also add your own since the collection since the configuration is totally flexible.

That matters because many useful exposure signals are not only in ports, titles, or banners. They are often found in many headers like:

• Authentication headers;
• Framework and CMS headers;
• Reverse proxy and gateway markers;
• Product-specific response headers.

With this release, operators can search for header presence:

Tags turn indicators into vocabulary

This version is shipped with 844 tag rules.

Tags are how Plum converts low-level indicators into a vocabulary that analysts can use. A banner, favicon hash, title, certificate issuer, authentication realm, or HTTP header can become a structured label.

Examples of the normalized taxonomy are:

• vendor:*
• product:*
• type:*
• proto:*
• vuln:*

A tag rule can combine several weak or strong indicators into one operational label. For example, this rule identifies Cisco router surfaces through a favicon hash, a Cisco IOS server header, or authentication realms often exposed by router interfaces:

description: Cisco Router
query: http_favicon_mmhash:-299287097 OR http_headval:www-authenticate:'Basic realm="level_15_access"' OR http_headval:www-authenticate:'Basic realm="level_15 or view_access"' OR http_server:cisco-IOS
tags:
- vendor:cisco
- type:router
- product:cisco-router
- product:ios
version: 20260520T133458Z

When used matching observations can be searched with the resulting vocabulary instead of repeating the full detection logic each time.

This makes results easier to query and compare:

tag:proto:ssh
tag:product:wordpress
tag:type:firewall
tag:vuln:opendir

The release adds and improves detections for SSH, FTP, SIP, RTSP, BGP, Telnet, HTTP protocol markers, certificate issuers, default certificate subjects, favicons, web titles, authentication realms, and product-specific banners.

The practical effect is that Plum can answer questions such as:

• which exposed services look like SSH for the domain CIRCL.lu?
• where do we see WordPress indicators on this range?
• which assets expose firewall or VPN surfaces of this brand?

domain_requested:example.org tag:proto:ssh

As before, search can still be used, it can be exact, prefix-based, substring-based, or grouped with OR. Time filters let teams focus on recent observations or historical windows. This makes Plum useful not only for finding something once, but for repeatedly checking whether an exposure is still present.

Reports

Reports is a feature also introduced recently, it turn the same structured search language into recurring summaries. Instead of manually running a query every month, an operator can define a scope, qualify it with tags or rules, and let Plum generate a Markdown report for that perimeter.

This is useful for monthly exposure tracking. A report can show which ports are currently open in the selected scope, which ports appeared during the period. The result is not just a list of raw scan outputs: it is a scoped view of exposed services, enriched with tags, requested FQDNs, open ports, and scan history.

For example, a team can build a monthly report for a business unit, an IP range, or a domain. This makes reports a way to follow change over time: new open ports, recurring services, and qualified exposure indicators that deserve review.

The next steps

The Searing Spring release is making Plum better at turning recurring scans into usable knowledge. More HTTP headers, richer tag rules, clearer taxonomy, structured search, port-centric observations help operators understand what is exposed, how services identify themselves, which product or protocol they likely belong to, when they were seen, and how to find them again.

Since the basics are in place, next, we will expand Plum Island to support more scanners, more protocols and a stronger reindexing workflow. New Detections rules are also welcome: if you have useful indicators, product fingerprints, protocol patterns, or operational rules, do not hesitate to submit them so they can benefit the wider community, they will have soon they own repository.

Release page: https://github.com/D4-project/Plum-Island/releases/tag/v0.2606.0

Disclaimer

Co-funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the granting authority can be held responsible for them.