![]() ![]() Once we notice that the rogue DNS server is being contacted by a LAN host, we can change our visualisation to see which domain name is being queried by which server. When isolating DNS traffic in our graph, we clearly see communication with a non-corporate DNS server. In the example below, we have isolated DNS traffic we quickly see that the PCAP contains communication between hosts in our LAN (remember, the LAN dot now represents traffic from multiple hosts!) and 2 different DNS servers. The benefit of doing this is that we can easily focus on the type of traffic we want to investigate without being burdened with things we don’t care about at that point in time of the analysis. We don’t know much about the external systems that are being contacted.Įxperiment 3 – Isolating specific types of trafficīy applying simple visual filters to our simulation (just like we do in tools like Wireshark), we can make a selection of the packets we want to investigate.We still don’t really have a clue on the actual content of the network communication (is this DNS? HTTP? Something else?).However, we still face a few shortcomings: All the internal LAN traffic is now represented as 1 node in our graph this can be interesting in case our analyst wants to quickly check which network segments are involved in the communication.We can very quickly see which traffic is leaving our LAN, and which external (internet facing) systems are involved in the communication.This lets us quickly see which external systems our LAN hosts are communicating with: Tagging the LAN segment clearly shows which packets leaves the network.īy doing this, we have improved our understanding of the data in a few ways: IP addresses are made to be processed by a computer, not by a human adding additional context to make them easier to classify by a human analyst would definitely help.Įxperiment 2 – Adding context to IP address informationīy using basic information to enrich the nodes in our graph, we can aggregate all LAN traffic into a single node.We have no clue on the actual content of the network communication (is this DNS? HTTP? Something else?).We see how interactions between systems change as time moves on.Ī few shortcomings of this first experiment include:.It’s quickly visible which hosts account for the “bulk” of the traffic.We quickly see which IP addresses are most actively communicating with each other (172.29.0.111 and 172.29.0.255).This visualisation already allows us to quickly see and understand a few things: IP traffic illustrated as interactive nodes. For our experiments, the time dimension is normalised: each packet traveling from A to B is visualised in the order they took place, but we don’t distinguish the duration between packets for now. This simple principle is highlighted below. A packet being sent from source A to destination B is visualised as the dot visually traveling from A to B. Each dot in the visualisation represents the source of a packet. Let’s go!Įxperiment 1 – Visualising network traffic using graph nodesĪs a first step, we simply represent all IP packets in our PCAP as unconnected graph nodes. ![]() In the screenshot a 15Kb sample containing 112 packets.įor this blog post we will use this simple 112 packet PCAP to experiment with novel ways of visualising and understanding our network data. A screen we are all familiar with – our beloved Wireshark! Unmatched capabilities to analyse even the most exotic protocols, but scrolling & filtering through events can be daunting if we want to quickly understand what is actually happening inside the PCAP. In this blog post we want to perform a series of experiments to try and improve our understanding of captured network traffic as intuitively as possible, by exclusively using interactive visualisations. Going through these network events in traditional tools such as Wireshark is extremely valuable however they are not always the best to quickly understand from a higher level what is actually going on. Analysing these often takes a lot of time: a 1MB network traffic capture (PCAP) can easily contain several hundred different packets (and most are much larger!). ![]() In this context, our work often involves investigating raw network traffic logs. This ranges from our SOC analysts looking at millions of collected data points per day all the way to the malware analyst tearing apart a malware sample and trying to make sense of its behaviour. At NVISO Labs, we are constantly trying to find better ways of understanding the data our analysts are looking at. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |