How to pick up the trail when it stops at the domain controller?

[JacobYonkman]

Hello Community! 

Situation: We are seeing XDR incidents where NGFW detects something trying to reach out to malicious websites. This is automatically mitigated by dropping the connection on both ends, as it should. However, it seems this results in no causality chain. The source shows the domain controller involved, but that's not the actual origin of the request.

Any ideas on how to query for more information that will lead us to what attempted to reach said malicious site?

I'm fairly new to building XDR queries but have tried exploring datasets and trying to correlate the alert times stamps to other events/host network connections on the domain controller. 

Example alert desc: "'generic:sussybadsite.bad along with 3 other alerts generated by PAN NGFW detected on host zdomainctrl1"

We get a couple duplicate incidents per day and I'm burning with curiosity as what keeps attempting to reach out. Any and all thoughts/suggestions are most welcome!

[Antony_Chan]

Hello @JacobYonkman,

Before we dive into XQL query/investigation. It's better to understand how's the infrastructure being setup.

Questions:

1. Is your Domain Controller work as a DNS server
2. Did the NGFW enable DNS sinkhole?
3. Do all of your endpoints install with Cortex XDR agent?

Apart from Question 3, the investigation needs to be carry out from NGFW.

Here's an article of DNSSinkhole that might help you identify the source that attempted to access a malicious website.

How DNS Sinkholing Works (paloaltonetworks.com)

[JacobYonkman]

Hello Antony!
The article is definitely helpful.
1. No
2. Yes
3. Yes. MOST endpoints have the XDR agent. (There is also a chance people are plugging personal devices into endpoints for charging, which naturally will not have any agents installed)