advanced threat protection ATP logging timestamps

Hi onward 

Could you please share more details on your requirement to understand it better because ATP and tcpdump are different modules and work differently so we may not able to match their output.

Example ATP timestamp from the gui showing only 1 second interval accuracy: "2020-04-16 13:11:40"

Example cish cli tcpdump timestamp showing a timestamp numbering scheme that extends below 1 second intervals: "07:19:25.095221"

If the goal is to determine which dns lookup resolved to an ip associated with an atp detection alert, if the client generated 50 dns lookups within the 1 second interval of the atp detection it's not practical to use timestamps alone to verify. it becomes necessary to check the source port numbers logged as well which does work for types of traffic where the source port is likely to be unique but more precise timestamps would be helpful.

Maybe another approach would be to use a Endpoint solution, which graps those Alerts on the Endpoint in the first place? 

To find out, which Endpoint causes this issue in bigger setups on bigger DNS Servers are messy, especially to dig into 500+ User networks - i know. 

For such customers the CLI is the better approach, to be honest. 

Or did you take a look at Central Reporting ? Maybe the information is saved there in your wanted way? Not sure right now. 

To clarify where it became necessary to check tcpdump: There was ongoing atp email alerts from one xg multiple times per day.  Monitoring lookups from the Windows client was not a good option.  The endpoint responsible for the alerts was already known because the ip and username for the vpn client were in the atp log for DNS origin but only the ip of the destination that triggered the detection and not the actual fqdn of the dns lookup was shown for "Threat URL/IP".   "Dst IP" was the internal ip of the xg the vpn client used as its dns server.  Whois for the threat ip resolved to Cloudflare which itself is a legit provider and we wanted to figure out if the detection was a false positive.  Monitoring the traffic from cish tcpdump and matching src port#'s between that and the atp log determined the fqdn for the forward dns lookups was a seemingly legit news website.   The detection could be a false positive from other sites hosted behind the Cloudflare ip.  A Sophos support case was opened to check into that.

To clarify where it became necessary to check tcpdump: There was ongoing atp email alerts from one xg multiple times per day.  Monitoring lookups from the Windows client was not a good option.  The endpoint responsible for the alerts was already known because the ip and username for the vpn client were in the atp log for DNS origin but only the ip of the destination that triggered the detection and not the actual fqdn of the dns lookup was shown for "Threat URL/IP".   "Dst IP" was the internal ip of the xg the vpn client used as its dns server.  Whois for the threat ip resolved to Cloudflare which itself is a legit provider and we wanted to figure out if the detection was a false positive.  Monitoring the traffic from cish tcpdump and matching src port#'s between that and the atp log determined the fqdn for the forward dns lookups was a seemingly legit news website.   The detection could be a false positive from other sites hosted behind the Cloudflare ip.  A Sophos support case was opened to check into that.