About Iñigo

Iñigo · ‎03-01-2023

It happens (or used to happen) when setting a value would create a "duplicate" container. For example, when you have two containers with the same data and their only difference is their label this error appears when trying to set the same label for both. I said "used to happen" because I'm finding this error in some executions for containers apparently not duplicated. It would be nice to know which values are being tested in that validation.

phanTom · ‎02-21-2023

@Iñigo you can query for artifact values a few ways, as you have probably seen. The artifact table is always going to be much heavier to query than the container one, for example, due to numbers. You can access artifact values through the container rest endpoint such as below: /rest/container?_filter_artifact__label="event" Note the double _ which basically jumps to the artifact table but via the container REST endpoint. With this you should be able to have filters at both container and artifact level and pull back the data possibly in 1 go? The double _ can be used a lot in this way but requires the field before it to have a context in another table. I wish they would put more examples like this in the docs so when you get this working it might be worth adding something to the feedback section of the docs page for REST so they can add something relevant? -- If this helped solve your issue please mark as a solution! Happy SOARing! --

Iñigo · ‎02-17-2023

Is there any update about this behaviour? We have had an application generated, given adequate permissions in Azure Portal and had an admin give their consent. No matter what, the app doesn't connect. We oberved that, the Azure application was granted "Application" type permissions by the admin (as required for our needs) but, during the test connectivity process, the SOAR's Graph app asks for "Delegated" type permissions. There is no place in the asset settings to define the permission type the app is asking for and, in our context, "Delegated" isn't acceptable. Also, even while the admin has already given consent to the Azure app, the consent is asked once again throught the login portal. @lluebeck_splunk The token is written into the asset internal state file, but these files get frequently corrupted in many apps, so constant connectivity tests are needed. @enfinality57 We are getting this error on a daily basis: "Error occurred while loading the state file due to its unexpected format. Resetting the state file with the default format." and token information gets lost. From what I see in the source code this state file corruption happens in several connectors. These kind of errors should rise some kind of alert or appear somewhere in the system health given their impact on functionality, or at least be documented so external monitoring can be setup to take care of them.

Iñigo · ‎11-25-2022

Hi Did you get any solution for this issue? We are getting the same error message at the EWS Office365 app for a specific mail account that is apparently configured in the same way that others that allow access without issues. We are missing something but can't figure out what.

Iñigo · ‎10-13-2022

Hi all, We use email ingestion as an input for several processes, mainly for phishing analysis. So far we are ingesting from O365 through the EWS app but we are experiencing some issues so we want to migrate to ingestion through Graph API via the Graph app. The thing is that comparing the artifacts generated at ingestion time for the same emails between the EWS app and the Graph app there are differences in the number of artifacts (sometimes more, sometimes less) and the CEF detail in those of "Email Artifact" type. Even in the containers generated by the Graph app the different email artifacts created during ingestion (ex: from an email with other emails attached) have different structures, some of them similar or maybe equal to the CEF structure generated by the EWS and the Parser apps and some with a new structure exclusive of Graph generated artifacts. Since the source of the emails is exactly the same and the output type is the same (Email Artifact) we expected the output content to be also the same. There are differences not only in the output structure, but in the content also, mainly in the body content and its parsing. Has anyone found any documentation explaining the parsing process and the output structure? Any hints about the logic behind the different output data structures? I'll mention some members who posted about related topics: @phanTom @drew19 @EdgeSync @lluebeck_splunk

Iñigo · ‎08-11-2022

Hi Sharada What issues are you experiencing with the events?

Iñigo · ‎08-11-2022

Hi. I saw you already upgraded to 5.1 We are experiencing a lot of issues since upgrading from 4.10.7 to 5.2.1. Our platform went from relatively stable to sluggish and awfully unstable So far nor us, nor professional services, have found the origin of the problems or a workaround. We were continously pushed to upgrade from Splunk and now the situation is making the platform unoperable.

Posts	7
Solutions	0
Karma Given	13
Karma Received	1
Member Since	‎09-02-2021

Online Status	Offline
Date Last Visited	‎03-01-2023 02:25 PM

Defining object detail in REST queries?

Email ingestion from O365: Different artifacts gen...

Re: SOAR Could not update record due to Validation...

Re: Defining object detail in REST queries

Re: Phantom MS Graph API for office 365

Re: Microsoft Exchange On-Premise EWS: HTTP Code: ...

Email ingestion from O365: Different artifacts gen...

Re: Why do Phantom playbooks stop processing after...

Re: Has anyone had issues with Phantom upgrade fro...