Our mission is to empower every person and every organization on the planet to achieve more. A trusted and secure computing environment is a critical component of our approach. When we introduced Win...
Updated Apr 23, 2018
Version 4.0
Blog Post
Dan Michelson
Microsoft
MicrosoftThanks for your feedback,
Nothing wrong with your deployment. ATP does not present every piece of information that is collected. We try to keep the investigation experience useful.
ATP do monitor the volumes of inbound and outbound traffic in an aggregative way including UDP traffic. It means that we can tell the volume of the traffic in a time window for a specific process/destination address but we cannot really tell if it was a two files upload case or one single upload. As UDP is a connectionless protocol, it feels like it is too noisy to present every single packet in the timeline. There will be some more work to do in order to present it in a way that will make sense.
We'd love to hear your feedback regarding the investigation use cases you had and regarding the way you would suggest to see this information.
For example:
1) What was the trigger for typical investigation cases?
2) Was it HTTP over UDP traffic or something else?
3) Inbound or outbound traffic.
4) What data in the machine time line or in the investigation experience of ATP could help you?
5) Anything else you might think will be useful.
Thanks,
Dan
Dan,
Thanks for the response, very helpful information to know. I'll share my ideas and answers to your questions below:
I certainly agree that presenting every UDP transaction would be overly noisy for most deployment situations. Perhaps a toggle feature, similar to the ability to filter on Event Type within the timeline view? I'm imagining selecting only network communications, with further options for selecting TCP and/or UDP communications. Even when selecting UDP from the dropdown menu, I think it would be beneficial to provide 5-tuple summaries similar to how the timeline currently summarizes encrypted network communications with the source process tree and destination IPs (ex: chrome.exe communicated over the network using an encrypted channel), adding in the destination port would help with lead information.
1) What was the trigger for typical investigation cases?
Various NIDS alerts for newly seen outbound UDP traffic (VOIP Traffic to a cloud service as an example)
2) Was it HTTP over UDP traffic or something else?
VOIP and its supporting protocols (sip, stun/turn), NTP, DNS
3) Inbound or outbound traffic.
Outbound
4) What data in the machine time line or in the investigation experience of ATP could help you?
A summary of source process, destination IPs, ports, would help. (ntpd.exe communicated over UDP 123 with 6 IPs)
5) Anything else you might think will be useful.
Even if the information doesn't make sense to view in the timeline feature, perhaps adding a table within the Advanced Hunting feature dedicated to UDP communications would help during an investigation?
Thanks again,
Ricky
- Dan Michelson
Ricky,
That was very helpful.
For short term solution I suggest the following:
A stream in Advanced hunting for the aggregated data (1h interval)
- Not sure if UDP/TCP info will be there as well as the specific process info. I believe solving the process identity here is important. Not sure if protocol (TCP/UDP) is so important here.
For longer term we'll consider adding it to the UX and even build a full AutoIR flow.
I would appreciate your feedback about both.
Also, please share the name of the NIDS solution you use.
Thanks,
Dan