About chrking

"We tried to push splunk alerts to XSOAR" - I'm assuming this means you're using the Demisto Add-on for Splunk. This is not the recommended way to get incidents into XSOAR for precisely the reason you've discovered - it is difficult to troubleshoot issues, and issues will cause incidents to be silently lost rather than raising errors.   The standard, recommended method uses queries from the XSOAR side, which will have logs to allow you to debug the issue in case of errors.   If you *need* to use the Demisto add-on for some reason, I'd suggest checking your network from splunk to XSOAR, as well as making sure you have the appropriate instance.execute.external key set on the XSOAR side. Given the lack of proper logs you may need to use tcpdump to debug the issue. ... View more

The problem is that the direct output of msgraph-download-file is *not* a file, it's a war room entry which contains a reference to a file. Until that war room entry has been written and the file reference is usable, it's not possible to get the data contained in the file. The only way to do that is to have two separate tasks, which requires a playbook.   If you absolutely can't use a playbook for some reason, the only option I see is to modify the integration to add a variant of msgraph-download-file which does the required pandas processing before returning anything. ... View more

So I think the first thing I should address here is that you shouldn't do this.   Either the results of the results of the subplaybook are required for the main playbook to continue, or they aren't. If they are, then doing this is just going to cause the rest of the main playbook to fail. If they aren't, then there's no clear point in waiting for the subplaybook to complete at all, just run it simultaneously with the rest of the playbook.   Whatever you're trying to do here, it's likely that the downsides of actually implementing this will outweigh the upsides. Something like SLA timers to warn users of excessively long running playbooks so they can manually review seems like a better approach.   That said, this was an interesting technical challenge so I have a solution.   You'll want to create two separate branches: A timeout branch (left) and a subplaybook branch (right). The end of the subplaybook branch should set a key in the context to let us know it's finished. The left branch will then use the built-in "Context Polling - Generic" playbook to finish *either* when the subplaybook finished context key is set OR the context polling timeout is reached (default 10 minutes). Note that the polling mechanism will introduce a delay of up to 1 minute (or more if you set a longer poll time) in the event the subplaybook does actually finish before the timeout. ... View more

Preprocess rules which drop incidents create an audit log entry when they do so, so it's worth taking a look in your audit log for the missing incidents to see if they're being dropped unexpectedly.   You should also take a look at your filtering options on the QRadar integration - it's also possible that the missing incidents were never fetched in the first place. ... View more

Javascript doesn't run in containers like the other runtimes, and I don't see any settings for http proxy specific to javascript executions so this is a bit tricky.   One thing I think would be worth trying would be to set a config level (ie /etc/containers/containers.conf or similar) config in podman for proxy A and then set the XSOAR http_proxy to proxy B and see if you can get it to work that way.    Also, having two proxies like this seems confusing and not ideal, but if it's absolutely unavoidable I'd suggest saving yourself some pain and using tinyproxy (or similar) with conditional upstreams (eg, upstream http proxyA:8000 ".docker.io") then pointing everything at the local tinyproxy. This gives you even more control if you need to add additional domains to proxyA, or some other, third proxy in the future.     ... View more

As SanDev says, this should be all that's required for it to work. Does the test command for your MSGraph setup complete successfully?   If you're stuck, you could try running with both the using argument (to make sure you're calling the correct email integration) and debug-mode=true argument to get some debug output which should help you understand what the problem is. ... View more

Have you enabled mirroring on your QRadar integration? You'll need the "Mirroring Options" selector set to one of the mirror options for the "Close Mirrored XSOAR Incident" option to work. ... View more

It sounds like you could implement your playbook with logic something like this to meet your requirements:   Fetch file from Graph (file entry ID is written to context) -> Conditional task which calls a custom automation, where the custom integration uses the python zipfile (or similar) library to determine if the zip is encrypted, then returns the result -> (If unencrypted) sends to sandbox / (else) do other custom processing for encrypted zips. ... View more

I'm confused by this statement: "The way in which XSOAR works with these files does not allow the use of python libraries." If you use a custom automation with a custom docker image you can import and use basically any library you want, I don't understand what the the restriction would be here. ... View more

Yes, you can create incidents in XSOAR based on emails arriving to a dedicated inbox. You'll need a mail integration like Mail Listener or Gmail Single User to receive the emails. These are most commonly used for phishing reports, but there's nothing to stop you from using them for other purposes. You can have multiple instances of the same integration, so if you need multiple mailboxes for different purposes that's fine too.   You can use the classifier and mapper with regular expressions (or similar) to select the appropriate incident type and extract stored data from the email into fields. For this, bear in mind that this kind of extraction works best with highly structured mails (eg, mails created to a template).   Once the incident has been classified and mapped, it will automatically execute the associated playbook for the incident type (depending on incident type settings). ... View more

Hmmm, I think we'll need to look more into the image where this is trying to run. I'm assuming this is a version of the panorama integration downloaded from the marketplace and not a customized version?   I think it would be worth trying to remove the existing docker images for this integration and re-fetching them. First, stop XSOAR. Then run: docker images | grep pan-os That should give you a list of one (or more) images that this integration uses. You can remove them with: docker rmi <image id> where the image id is in the output of the docker images command. Once done re-start XSOAR, and the required image should be re-fetched. If you're still seeing issues, you might need to check out your repository config (to see where you're fetching images from) or your outbound proxy (used to fetch images).   ... View more

Assuming this is XSOAR 6.x and you haven't already, I'd suggest giving /reset_containers a try.  ... View more

XSOAR does not support iframes. You could have an integration which creates a Browserling session and returns a link. You could then put that link in the layout so that users could click on it.   You should also check out the rasterize integration if you haven't already, rasterize has the ability to provide an image file containing the local rendering of an arbitrary URL so you may not actually need Browserling. ... View more

Yeah, if they need the multi-mailbox delete functionality then "O365 Outlook Mail (Using Graph API)" is definitely one way to do this. I had assumed that wasn't possible for DennisO since the original post mentioned "O365" as being something they couldn't do, but if that was a misunderstanding on my part then they should definitely check it out. ... View more

When you say "Graph Mail", are you referring to "Microsoft Graph Mail Single User" ?    Microsoft Graph Mail Single User authenticates as a single, non-admin user for the purposes of sending/receiving email. In contrast with the other integrations, it is specifically intended to be used in situations where XSOAR cannot or should not be granted admin-level privileges over the mail system.   The "Search and Delete" functionality in the phishing playbook requires admin-level privileges to search / delete from other user's mailboxes, and so it is inherently incompatible with the design goals of this integration. ... View more