Re: Clarification on Fetching Assets via listasset...

rohan1804 · 04-29-2025 12:05 AM

Hi everyone,

I'm trying to fetch assets using the following Chronicle API endpoint:
https://backstory.googleapis.com/v1/artifact/listassets

While using this API, the input parameters require one of the following:

"artifact.domain_name"
"artifact.destination_ip"
"artifact.hash"

I'm a bit confused about the distinction between artifacts and assets in this context. Also, where can I find valid values for these artifact fields (like "domain_name", "destination_ip", or hash) to use in the request?

Could someone please help clarify:

What exactly is the difference between an artifact and an asset in Chronicle?
Where can I obtain artifact values to query the "listassets" API?

Any help or examples would be greatly appreciated.

Thanks!

James_E

@rohan1804 the difference in artifact and asset are described in the Search API docs A artifact could be an IOC that has been seen in your environment.

rohan1804

Hi @James_E ,

We have ingested logs into Google SecOps using the AWS S3 feeder. The logs are being parsed correctly, and alerts are also being generated as expected.

These logs contain known malicious IPs, each with a threat score above 80, verified via the Mandiant portal. However, despite the alerts being triggered, the corresponding IOCs are not being generated.

We’d like to clarify:

Is it mandatory to enable Applied Threat Intelligence in order for IOCs to be generated?
If so, does this feature require the Enterprise Plus edition?

Looking forward to your guidance on this.

Thanks in advance!

James_E

@rohan1804 Applied Threat Intelligence does require Enterprise Plus. You do have the ability to ingest your own supported intel feeds or send in IOC's through the ingestion API. For the logs that you're currently ingesting, the key here is that the IOC's need to be ingested as an entity and not an event.

What log type are you currently ingesting for IOC's?

rohan1804

Hi @James_E ,

We are ingesting AWS Cloudtrail json logs, through a SIEM AWS Cloudtrail feeder below is the sample for your reference:

sample log:

{"eventVersion":"1.09","userIdentity":{"type":"IAMUser","principalId":"AIDAEXAMPLE456","arn":"arn:aws:iam::123456789012:user/ioc_user1","accountId":"123456789012","accessKeyId":"ASIAEXAMPLEKEY456","userName":"ioc_user1"},"eventTime":"2025-04-28T07:01:01Z","eventSource":"signin.amazonaws.com","eventName":"ConsoleLogin","awsRegion":"us-east-1","sourceIPAddress":"0.00.000","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64)","requestParameters":null,"responseElements":{"ConsoleLogin":"Success"},"additionalEventData":{"MFAUsed":"No","LoginTo":"https://console.aws.amazon.com/console/home","MobileVersion":"No"},"requestID":"req-login-001","eventID":"event-login-001","eventType":"AwsConsoleSignIn","managementEvent":true,"recipientAccountId":"123456789012","eventCategory":"Management"}

And How to ingest IOC's as entities not events ?

dbt_metron

Hi @James_E ,

Just following up on our earlier message - we’re currently exploring how to generate Assets in the Google SecOps platform, and your guidance would be really helpful at this stage.

Here’s a quick summary of what we’ve tried so far:

Ingested IoCs and assets as events
Ingested IoCs and assets as entities
Ensured the time range of the IoC is within scope

Challenges we’re facing:

Unable to generate IoCs and assets visibly within the platform
Receiving empty responses from the legacySearchArtifact endpoint

Our current focus is on successfully generating Assets. If there are any specific formats, ingestion methods, or query parameters we should follow, we’re open to all suggestions.

Looking forward to your inputs. Thank you!

cc: @rohan1804 @vishnusoni

James_E

@dbt_metron I think there's a lot missing in here. If you want to create asset or IOC entities within the platform, you need to make sure you're ingesting that log type. You also need to make sure the parser is creating an asset/ioc entity during the normalization process. If you're not sure, you can look at the parser for that specific log type. A good example is the TANIUM_ASSET log type. It should be creating an asset entity when that log type is being ingested. On the other hand, we have a log type for TEQTIVITY_ASSETS but no parser. In that instance, you would have to create a custom parser for that log type that would create an asset entity.

Once you have the log type and parser to create the asset entity, it should show up in the platform. This same logic applies for IOC's. We have a log type and parser for ANOMALI_IOC, so IOCs should be created if you were to ingest that log. Whereas we have a log type of CYBERES_IOC but no parser, so you would have to create a custom parser that would take those logs and create an IOC.

The last option would be to convert the log into UDM yourself and then ingest the IOC or ASSET. Sometimes this is the easier route when the log is small and it's not worth creating a full parser. You can convert the log to UDM following the UDM Schema (using python or something else), and ingest the log as UDM log type through a feed or the Ingestion API.

The following docs will come in handy if you need to write your own parser, or if you decide to convert it to UDM yourself.

The Google Cloud Security Community will be in read-only mode July 16 - July 22 as we migrate platforms.

Read more and check out our FAQ.

Clarification on Fetching Assets via listassets API – Artifact vs Asset