Hi @ylandovskyy,
I set up the Google TI connector this week and I've been testing it alongside the Mandiant connector. The DTM works as expected but I'm having issues with the ASM connector.
2 events came in today for Mandiant ASM but they were not alerted on when using the Google TI connector. Do you know why this disparity would be occurring?
TIA
@_K_O ,
It's most likely tied to the fact that you are running them in parallel and the alerts are created with the same Alert ID, which means that our ETL dismisses duplicates, but I will check with the internal team.
@_K_O ,
It's most likely tied to the fact that you are running them in parallel and the alerts are created with the same Alert ID, which means that our ETL dismisses duplicates, but I will check with the internal team.
Thank you! Please keep me updated 🙂
Thank you! Please keep me updated 🙂
@_K_O
Have an update. The reason for potential discrepancy is tied to the fact that in Mandiant ASM and GTI connectors the filter query is built slightly different.
In Mandiant ASM the query looks like this:
https://virustotal.com/api/v3/asm/search/issues/first_seen_after:2025-06-20T04:52:44Z last_seen_after:last_refresh severity_lte:1 status_new:open
While in GTI, it's like this:
https://www.virustotal.com/api/v3/asm/search/issues/last_seen_after:2025-06-20T05:02:07Z last_seen_before:2025-06-20T11:02:07Z status_new:open severity_lte:1
The difference is in the fact that inside Mandiant ASM integration, we were working with first_seen_time, while in GTI - last_seen_time.
The impact of this difference is that in Mandiant ASM, the connector was only ingesting issues that were created AFTER connector was configured, while in GTI the connector will pick up any issue that was updated, even if this issue was created a year ago, but was updated with new information.
From my perspective the new logic is better, but let me know your thoughts. Additionally, in GTI connector, to improve the stability of the connector, we process data in 6 hour batches until we reach current time.
This means that if you set a big "Max Hours Backwards" value, it will take some time before it will get to current time.
What was the configuration for the GTI connector?
@_K_O
Have an update. The reason for potential discrepancy is tied to the fact that in Mandiant ASM and GTI connectors the filter query is built slightly different.
In Mandiant ASM the query looks like this:
https://virustotal.com/api/v3/asm/search/issues/first_seen_after:2025-06-20T04:52:44Z last_seen_after:last_refresh severity_lte:1 status_new:open
While in GTI, it's like this:
https://www.virustotal.com/api/v3/asm/search/issues/last_seen_after:2025-06-20T05:02:07Z last_seen_before:2025-06-20T11:02:07Z status_new:open severity_lte:1
The difference is in the fact that inside Mandiant ASM integration, we were working with first_seen_time, while in GTI - last_seen_time.
The impact of this difference is that in Mandiant ASM, the connector was only ingesting issues that were created AFTER connector was configured, while in GTI the connector will pick up any issue that was updated, even if this issue was created a year ago, but was updated with new information.
From my perspective the new logic is better, but let me know your thoughts. Additionally, in GTI connector, to improve the stability of the connector, we process data in 6 hour batches until we reach current time.
This means that if you set a big "Max Hours Backwards" value, it will take some time before it will get to current time.
What was the configuration for the GTI connector?
Hi @ylandovskyy,
Thank you for the information!
The configuration is the same as the Mandiant ASM configuration. We still haven't had any events come through via the GTI connector at this point.
Hi @ylandovskyy,
Thank you for the information!
The configuration is the same as the Mandiant ASM configuration. We still haven't had any events come through via the GTI connector at this point.
@_K_O,
Can you enable logging and check that there are no errors?
@_K_O,
Can you enable logging and check that there are no errors?
@ylandovskyy, The logs are not very verbose, it just says that it failed to fetch data:
When I run the connector test, I get this:
@ylandovskyy, The logs are not very verbose, it just says that it failed to fetch data:
When I run the connector test, I get this:
@_K_O Okay, this is the reason why the alerts were not ingested. Is there a traceback for this error or only this message?
I've tried to replicate the issue, but everything works correctly on my side.
@_K_O Okay, this is the reason why the alerts were not ingested. Is there a traceback for this error or only this message?
I've tried to replicate the issue, but everything works correctly on my side.
@ylandovskyy only that message - when I open the event it just displays the same thing.
@ylandovskyy only that message - when I open the event it just displays the same thing.
@_K_O Can you try to run ASM related actions? For example, try to execute "Search ASM Issues" action and see, if it will work correctly? If not, run the same action through IDE. It will return more logging, which might help us understand the root cause.
@_K_O Can you try to run ASM related actions? For example, try to execute "Search ASM Issues" action and see, if it will work correctly? If not, run the same action through IDE. It will return more logging, which might help us understand the root cause.
@ylandovskyy if I run the manual action, it succeeds:
I did see the following error in the connector logs:
Error: An error occurred: 502 Server Error: Bad Gateway for url: https://www.virustotal.com/api/v3/asm/projects b'<html>\\r\\n<head><title>502 Bad Gateway</title></head>\\r\\n<body>\\r\\n<center><h1>502 Bad Gateway</h1></center>\\r\\n<hr><center>cloudflare</center>\\r\\n</body>\\r\\n</html>\\r\\n'
@ylandovskyy if I run the manual action, it succeeds:
I did see the following error in the connector logs:
Error: An error occurred: 502 Server Error: Bad Gateway for url: https://www.virustotal.com/api/v3/asm/projects b'<html>\\r\\n<head><title>502 Bad Gateway</title></head>\\r\\n<body>\\r\\n<center><h1>502 Bad Gateway</h1></center>\\r\\n<hr><center>cloudflare</center>\\r\\n</body>\\r\\n</html>\\r\\n'
@_K_O Can you try to run the connector/action without Project Name defined? If you are running action then, it would need to also be removed from the integration configuration.
@_K_O Can you try to run the connector/action without Project Name defined? If you are running action then, it would need to also be removed from the integration configuration.
- It still succeeds without the project name when doing a manual action, but it doesn't return anything.
- In the connector, it still shows the error message: Failed to fetch data - Search completed.
I’ve just installed this integration. I don’t have ASM but everytime I run an action, it errors out with the message below. The asm project parameter is optional but this makes it seem like it is.
Output message
Failed to connect to the Google Threat Intelligence server!
Reason: 403 Client Error: Forbidden for url: https://www.virustotal.com/api/v3/asm/projects
