Hello,
A version field has been added to a number of scan feeds. Please note that in most cases the version field will be different from the device_version/product.version.
The version field will list technologies identified by a version present in the product stack. This may reflect the device_version but have multiple technologies identified in addition. For example, PHP version or Apache version such as "apache:1.3.41;php:4.4.9".
Regards,
Jason
Hi Jason,
It would be nice to have this version field documented in the affected feeds on the Shadowserver feed info pages (under https://www.shadowserver.org/what-we-do/network-reporting). There are many feeds that do have a device_version/product_version documented, but if this new version field appears alongside in the alerts, it can be quite confusing to our clients. Among them, the level of skills and expertise vary a lot.
E.g., a sample of our today's Accessible Rsync report contained:
"extra.version": "33.0 sha512 sha256 sha1 md5 md4"
I'm a bit reluctant to send this out to our clients since I can only give an educated guess on what the hash algorithm abbreviations in the list mean in the context of the version number.
Br, Mika
________________________________ From: elsif via IntelMQ-dev intelmq-dev@lists.cert.at Sent: Thursday, 29 October 2026 20.51 To: Developer mailing list for intelmq: https://github.com/certtools/intelmq intelmq-dev@lists.cert.at Subject: [IntelMQ-dev] Shadowserver IntelMQ schema - version field additions
Hello,
A version field has been added to a number of scan feeds. Please note that in most cases the version field will be different from the device_version/product.version.
The version field will list technologies identified by a version present in the product stack. This may reflect the device_version but have multiple technologies identified in addition. For example, PHP version or Apache version such as "apache:1.3.41;php:4.4.9".
Regards,
Jason
_______________________________________________ IntelMQ-dev mailing list -- intelmq-dev@lists.cert.at To unsubscribe send an email to intelmq-dev-leave@lists.cert.at
The information in this email may be confidential and is intended solely for the use of the individual or entity to whom it is intended. If you are not the intended recipient of this message, please delete the message and notify the sender immediately. For information on how we process personal data and our contact information, please see CSC's website: Privacyhttps://csc.fi/en/privacy
T?m?n s?hk?postin tiedot voivat olla luottamuksellisia ja ne on tarkoitettu yksinomaan sen henkil?n tai yhteis?n k?ytt??n, jolle ne on osoitettu. Jos et ole viestiss? tarkoitettu vastaanottaja, tuhoa viesti ja ilmoita asiasta v?litt?m?sti viestin l?hett?j?lle. Tietoja henkil?tietojen ja yhteystietojen k?sittelyst? l?yd?t CSC:n verkkosivuilta: Tietosuojahttps://csc.fi/tietosuoja
On 30/10/2026 11:19, Mika Silander via IntelMQ-dev wrote:
E.g., a sample of our today's Accessible Rsync report contained:
"extra.version": "33.0 sha512 sha256 sha1 md5 md4"
I'm a bit reluctant to send this out to our clients since I can only give an educated guess on what the hash algorithm abbreviations in the list mean in the context of the version number.
Thanks for sharing the example data.
I'm also sceptical about it, particularly the wording. 'Version' can have various meanings, so it's unclear what it refers to here. For example, 'version' could refer to the data format or the version of the IoC event. Why not call it 'application_version'? This would be similar to the convention of application_protocol/transport_protocol.
Sebastian
Hi Sebastian & al.,
You're welcome.
I went through all our configurations affected by the addition of "extra.version". Quite a job, but now, for the moment, these are not sent within investigations (yes, RT::IR, what else?) to our clients. The values of this field will however, show up in incidents and incident reports, so we (the team) can see their contents in case a client would ask for further details.
If someone else needs the list of feeds changed, see the attachment. It's generated based on this week's updates to intelmq.json:
git clone https://github.com/The-Shadowserver-Foundation/report_schema.git cd report_schema git diff bc02e3c5c4a9d045eaad44aa13f98f67d8515e7d bf5e6791b3bad836154aab411aa6333502babb70 -- intelmq.json
... and the list can of course contain errors, my apologies.
Have a nice weekend, Mika
________________________________ From: Sebix via IntelMQ-dev intelmq-dev@lists.cert.at Sent: Friday, 30 October 2026 17.20 To: Developer mailing list for intelmq: https://github.com/certtools/intelmq intelmq-dev@lists.cert.at Subject: [IntelMQ-dev] Re: Shadowserver IntelMQ schema - version field additions
On 30/10/2026 11:19, Mika Silander via IntelMQ-dev wrote: E.g., a sample of our today's Accessible Rsync report contained:
"extra.version": "33.0 sha512 sha256 sha1 md5 md4"
I'm a bit reluctant to send this out to our clients since I can only give an educated guess on what the hash algorithm abbreviations in the list mean in the context of the version number.
Thanks for sharing the example data.
I'm also sceptical about it, particularly the wording. 'Version' can have various meanings, so it's unclear what it refers to here. For example, 'version' could refer to the data format or the version of the IoC event. Why not call it 'application_version'? This would be similar to the convention of application_protocol/transport_protocol.
Sebastian
-- Institute for Common Good Technology gemeinnütziger Kulturverein - nonprofit cultural society https://commongoodtechnology.org/ ZVR 1510673578
The information in this email may be confidential and is intended solely for the use of the individual or entity to whom it is intended. If you are not the intended recipient of this message, please delete the message and notify the sender immediately. For information on how we process personal data and our contact information, please see CSC's website: Privacyhttps://csc.fi/en/privacy
Tämän sähköpostin tiedot voivat olla luottamuksellisia ja ne on tarkoitettu yksinomaan sen henkilön tai yhteisön käyttöön, jolle ne on osoitettu. Jos et ole viestissä tarkoitettu vastaanottaja, tuhoa viesti ja ilmoita asiasta välittömästi viestin lähettäjälle. Tietoja henkilötietojen ja yhteystietojen käsittelystä löydät CSC:n verkkosivuilta: Tietosuojahttps://csc.fi/tietosuoja