Hi,
We received one sinkhole http referer event that got flagged as not belonging to our constituency. At a closer look, it turned out that intelmq's destination.ip field (see event4_sinkhole_http_referer in https://github.com/The-Shadowserver-Foundation/report_schema/blob/main/intel...https://github.com/The-Shadowserver-Foundation/report_schema/blob/main/intelmq.json) contains the IP the malware tried to access (?) and then the IP of the machine possibly infected by the malware ended up in extra.http_referer_ip. Everything fine and coherent with the feed's documentation, no complaints.
To deduce to whom in our constituency an event belongs, we have a bot that first looks at the source.ip field and if this does not match, then we try the destination.ip field. This heuristic works fine with all feeds but in the above case it fails.
Is there a chance the report field http_referer_ip gets mapped one day in intelmq.json to intelmq's source.ip field (like in the majority of other feeds) instead of extra.http_referer_ip? Just asking since I'd like to keep things simpler and avoid work-arounds.
Br, Mika
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
Hi Mika
I agree with you. As per IntelMQ's guidelines/documentation (https://docs.intelmq.org/latest/user/event/#meaning-of-source-and-destinatio...) the data we care about is always in the source part, and the IP address in source.ip.
Jason, can you please adapt the mapping?
best regards Sebastian
On 3/31/25 10:08 AM, Mika Silander via IntelMQ-dev wrote:
Hi,
We received one sinkhole http referer event that got flagged as not belonging to our constituency. At a closer look, it turned out that intelmq's destination.ip field (see event4_sinkhole_http_referer in https://github.com/The-Shadowserver-Foundation/report_schema/blob/main/intel... https://github.com/The-Shadowserver-Foundation/report_schema/blob/main/intelmq.json) contains the IP the malware tried to access (?) and then the IP of the machine possibly infected by the malware ended up in extra.http_referer_ip. Everything fine and coherent with the feed's documentation, no complaints.
To deduce to whom in our constituency an event belongs, we have a bot that first looks at the source.ip field and if this does not match, then we try the destination.ip field. This heuristic works fine with all feeds but in the above case it fails.
Is there a chance the report field http_referer_ip gets mapped one day in intelmq.json to intelmq's source.ip field (like in the majority of other feeds) instead of extra.http_referer_ip? Just asking since I'd like to keep things simpler and avoid work-arounds.
Br, Mika
/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: Privacy https://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: Tietosuoja https://csc.fi/tietosuoja /
IntelMQ-dev mailing list --intelmq-dev@lists.cert.at To unsubscribe send an email tointelmq-dev-leave@lists.cert.at
I also agree with that, I expect our constituency IP (which we should take care about) to be always in source.ip
Best regards
// Kamil Mańkowski mankowski@cert.at - T: +43 676 898 298 7204 // CERT Austria - https://www.cert.at/ // CERT.at GmbH, FB-Nr. 561772k, HG Wien
On 3/31/25 10:43, Sebix via IntelMQ-dev wrote:
Hi Mika
I agree with you. As per IntelMQ's guidelines/documentation (https://docs.intelmq.org/latest/user/event/#meaning-of-source-and-destinatio...) the data we care about is always in the source part, and the IP address in source.ip.
Jason, can you please adapt the mapping?
best regards Sebastian
On 3/31/25 10:08 AM, Mika Silander via IntelMQ-dev wrote:
Hi,
We received one sinkhole http referer event that got flagged as not belonging to our constituency. At a closer look, it turned out that intelmq's destination.ip field (see event4_sinkhole_http_referer in https://github.com/The-Shadowserver-Foundation/report_schema/blob/main/intel... https://github.com/The-Shadowserver-Foundation/report_schema/blob/main/intelmq.json) contains the IP the malware tried to access (?) and then the IP of the machine possibly infected by the malware ended up in extra.http_referer_ip. Everything fine and coherent with the feed's documentation, no complaints.
To deduce to whom in our constituency an event belongs, we have a bot that first looks at the source.ip field and if this does not match, then we try the destination.ip field. This heuristic works fine with all feeds but in the above case it fails.
Is there a chance the report field http_referer_ip gets mapped one day in intelmq.json to intelmq's source.ip field (like in the majority of other feeds) instead of extra.http_referer_ip? Just asking since I'd like to keep things simpler and avoid work-arounds.
Br, Mika
/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: Privacy https://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: Tietosuoja https://csc.fi/tietosuoja /
IntelMQ-dev mailing list --intelmq-dev@lists.cert.at To unsubscribe send an email tointelmq-dev-leave@lists.cert.at
-- Institute for Common Good Technology gemeinnütziger Kulturverein - nonprofit cultural society https://commongoodtechnology.org/ ZVR 1510673578
IntelMQ-dev mailing list -- intelmq-dev@lists.cert.at To unsubscribe send an email to intelmq-dev-leave@lists.cert.at
The schema has been updated:
*************** *** 13,18 **** --- 13,23 ---- "validate_to_none" ], [ + "source.ip", + "http_referer_ip", + "validate_ip" + ], + [ "malware.name", "infection", "validate_to_none" *************** *** 33,43 **** ], [ "extra.", - "http_referer_ip", - "validate_ip" - ], - [ - "extra.", "http_referer_port", "convert_int" ],
On 3/31/25 1:43 AM, Sebix wrote:
Hi Mika
I agree with you. As per IntelMQ's guidelines/documentation (https://docs.intelmq.org/latest/user/event/#meaning-of-source-and-destinatio...) the data we care about is always in the source part, and the IP address in source.ip.
Jason, can you please adapt the mapping?
best regards Sebastian
On 3/31/25 10:08 AM, Mika Silander via IntelMQ-dev wrote:
Hi,
We received one sinkhole http referer event that got flagged as not belonging to our constituency. At a closer look, it turned out that intelmq's destination.ip field (see event4_sinkhole_http_referer in https://github.com/The-Shadowserver-Foundation/report_schema/blob/main/intel... https://github.com/The-Shadowserver-Foundation/report_schema/blob/main/intelmq.json) contains the IP the malware tried to access (?) and then the IP of the machine possibly infected by the malware ended up in extra.http_referer_ip. Everything fine and coherent with the feed's documentation, no complaints.
To deduce to whom in our constituency an event belongs, we have a bot that first looks at the source.ip field and if this does not match, then we try the destination.ip field. This heuristic works fine with all feeds but in the above case it fails.
Is there a chance the report field http_referer_ip gets mapped one day in intelmq.json to intelmq's source.ip field (like in the majority of other feeds) instead of extra.http_referer_ip? Just asking since I'd like to keep things simpler and avoid work-arounds.
Br, Mika
/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: Privacy https://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: Tietosuoja https://csc.fi/tietosuoja /
IntelMQ-dev mailing list --intelmq-dev@lists.cert.at To unsubscribe send an email tointelmq-dev-leave@lists.cert.at
-- Institute for Common Good Technology gemeinnütziger Kulturverein - nonprofit cultural society https://commongoodtechnology.org/ ZVR 1510673578
Thank you!!
On 01.04.2025, at 21:26, elsif via IntelMQ-dev intelmq-dev@lists.cert.at wrote:
The schema has been updated:
*** 13,18 **** --- 13,23 ---- "validate_to_none" ], [
"source.ip","http_referer_ip","validate_ip"],[ "malware.name", "infection", "validate_to_none"
*** 33,43 **** ], [ "extra.",
"http_referer_ip","validate_ip"],["extra.", "http_referer_port", "convert_int" ],On 3/31/25 1:43 AM, Sebix wrote:
Hi Mika
I agree with you. As per IntelMQ's guidelines/documentation (https://docs.intelmq.org/latest/user/event/#meaning-of-source-and-destinatio...) the data we care about is always in the source part, and the IP address in source.ip.
Jason, can you please adapt the mapping?
best regards Sebastian
On 3/31/25 10:08 AM, Mika Silander via IntelMQ-dev wrote:
Hi,
We received one sinkhole http referer event that got flagged as not belonging to our constituency. At a closer look, it turned out that intelmq's destination.ip field (see event4_sinkhole_http_referer in https://github.com/The-Shadowserver-Foundation/report_schema/blob/main/intel...) contains the IP the malware tried to access (?) and then the IP of the machine possibly infected by the malware ended up in extra.http_referer_ip. Everything fine and coherent with the feed's documentation, no complaints.
To deduce to whom in our constituency an event belongs, we have a bot that first looks at the source.ip field and if this does not match, then we try the destination.ip field. This heuristic works fine with all feeds but in the above case it fails.
Is there a chance the report field http_referer_ip gets mapped one day in intelmq.json to intelmq's source.ip field (like in the majority of other feeds) instead of extra.http_referer_ip? Just asking since I'd like to keep things simpler and avoid work-arounds.
Br, Mika
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: 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: Tietosuoja
IntelMQ-dev mailing list -- intelmq-dev@lists.cert.at
To unsubscribe send an email to intelmq-dev-leave@lists.cert.at
-- Institute for Common Good Technology gemeinnütziger Kulturverein - nonprofit cultural society
https://commongoodtechnology.org/
ZVR 1510673578
IntelMQ-dev mailing list -- intelmq-dev@lists.cert.at To unsubscribe send an email to intelmq-dev-leave@lists.cert.at
Hi Sebastian & all,
One minimal request more related to this: the source.ip field in intelmq.json is now grouped into "optional" and I think it should be among the ones that are required. My thanks beforehand to the one who moves this field to required in the feeds event[46]_sinkhole_http_referer.
Br, Mika ________________________________ From: elsif elsif@shadowserver.org Sent: Tuesday, 1 April 2025 22.26 To: Sebix sebix@sebix.at; intelmq-dev@lists.cert.at intelmq-dev@lists.cert.at Cc: Mika Silander mika.silander@csc.fi Subject: Re: [IntelMQ-dev] A question on Shadowserver's Sinkhole HTTP Referer Events feed
The schema has been updated:
*************** *** 13,18 **** --- 13,23 ---- "validate_to_none" ], [ + "source.ip", + "http_referer_ip", + "validate_ip" + ], + [ "malware.name", "infection", "validate_to_none" *************** *** 33,43 **** ], [ "extra.", - "http_referer_ip", - "validate_ip" - ], - [ - "extra.", "http_referer_port", "convert_int" ],
On 3/31/25 1:43 AM, Sebix wrote:
Hi Mika
I agree with you. As per IntelMQ's guidelines/documentation (https://docs.intelmq.org/latest/user/event/#meaning-of-source-and-destinatio...) the data we care about is always in the source part, and the IP address in source.ip.
Jason, can you please adapt the mapping?
best regards Sebastian
On 3/31/25 10:08 AM, Mika Silander via IntelMQ-dev wrote: Hi,
We received one sinkhole http referer event that got flagged as not belonging to our constituency. At a closer look, it turned out that intelmq's destination.ip field (see event4_sinkhole_http_referer in https://github.com/The-Shadowserver-Foundation/report_schema/blob/main/intel...https://github.com/The-Shadowserver-Foundation/report_schema/blob/main/intelmq.json) contains the IP the malware tried to access (?) and then the IP of the machine possibly infected by the malware ended up in extra.http_referer_ip. Everything fine and coherent with the feed's documentation, no complaints.
To deduce to whom in our constituency an event belongs, we have a bot that first looks at the source.ip field and if this does not match, then we try the destination.ip field. This heuristic works fine with all feeds but in the above case it fails.
Is there a chance the report field http_referer_ip gets mapped one day in intelmq.json to intelmq's source.ip field (like in the majority of other feeds) instead of extra.http_referer_ip? Just asking since I'd like to keep things simpler and avoid work-arounds.
Br, Mika
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
_______________________________________________ IntelMQ-dev mailing list -- intelmq-dev@lists.cert.atmailto:intelmq-dev@lists.cert.at To unsubscribe send an email to intelmq-dev-leave@lists.cert.atmailto:intelmq-dev-leave@lists.cert.at
-- Institute for Common Good Technology gemeinnütziger Kulturverein - nonprofit cultural society https://commongoodtechnology.org/ ZVR 1510673578