I will not consider the situation with the crooked hands of administrators who left the Internet looking unprotected Elastic or MongoDB. Let’s talk about the targeted actions of attackers, as was the case with the acclaimed story of Equifax credit bureaus. Let me remind you that in this case, the attackers first penetrated through the unpatched vulnerability to the public Web-portal, and then to the internal database servers. Remaining unnoticed for several months, they were able to steal data on 146 million credit bureau clients. Could such an incident be identified using DLP solutions? Most likely not, since classic DLPs are not tailored to the task of monitoring traffic from databases using specific protocols, and even under the condition that this traffic is encrypted. But the solution of the NTA class can quite easily detect such leaks by exceeding a certain threshold value of the amount of information downloaded from the database. Next, I will show how this is all configured and discovered using the Cisco Stealthwatch Enterprise solution.
So, the first thing we need to do is understand where our database servers are located in the network, determine their addresses and group them. In Cisco Stealthwatch, the inventory task can be performed either manually or using a special classifier that analyzes traffic and, according to the protocols used and the behavior of the node, allows you to attribute it to one or another category.
After we have information about all database servers, we begin an investigation to find out if we are leaking large amounts of data from the desired group of nodes. We see that in our case, the databases most actively communicate with DHCP servers and domain controllers.
Attackers often establish control over any of the network nodes and use it as a bridgehead to develop their attack. At the level of network traffic, it looks like an anomaly – network scanning from this node is becoming more frequent, data is being captured from the file share or interacting with any servers. Therefore, our next task is to understand with whom exactly our databases most often communicate.
In the group of DHCP servers, it turns out that this is a node with the address 10.201.0.15, interaction with which accounts for about 50% of all traffic from database servers.
The next logical question that we ask ourselves as part of the investigation is: “And what kind of node is this 10.201.0.15? Who is he interacting with? How often? What protocols? ”
It turns out that the node we are interested in communicates with various segments and nodes of our network (which is not surprising, since it is a DHCP server), but the question causes too much interaction with the terminal server with the address 10.201.0.23. Is this normal? There is clearly some kind of anomaly. A DHCP server cannot communicate so actively with a terminal server – 5610 streams and 23.5 GB of data.
And this interaction is carried out through NFS.
We take the next step and try to understand who our terminal server interacts with? It turns out that he has quite active communication with the outside world – with nodes in the USA, Great Britain, Canada, Denmark, the United Arab Emirates, Qatar, Switzerland, etc.
Suspicion was caused by the fact of P2P interaction with Puerto Rico, which accounted for 90% of all traffic. Moreover, our terminal server transmitted more than 17 GB of data to Puerto Rico via the 53rd port, which is connected with the DNS protocol. Can you imagine that you have such a volume of data transmitted via DNS? And I remind you that according to Cisco research, 92% of malicious programs use DNS to hide their activity (downloading updates, receiving commands, dumping data).
And if the ITU DNS protocol is not just open, but not inspected, then we have a huge hole in our perimeter.
As soon as the node 10.201.0.23 caused us such suspicions, then let’s see who he is still talking to?
Half of all the traffic our “suspect” exchanges with the node 10.201.3.18, which is placed in a group of workstations of employees of the sales and marketing department. How typical are these for our organization for the terminal server to “communicate” with the computer of the seller or marketer?
So, we conducted an investigation and found out the following picture. Data from the database server was “poured” onto a DHCP server with their subsequent transfer via NFS to a terminal server inside our network, and then to external addresses in Puerto Rico using the DNS protocol. This is a clear violation of security policies. At the same time, the terminal server also interacted with one of the workstations within the network. What caused this incident? Stolen account? Infected device? We do not know. This will require a continuation of the investigation, which was based on the NTA class solution, which allows analyzing network traffic anomalies.
And now we are interested in what we will do with the identified violations of security policy? You can conduct regular analysis according to the above scheme, or you can configure the NTA policy so that it immediately signals when similar violations are detected. This is done either through the corresponding general menu, or for each connection detected during the investigation.
Here is what the interaction detection rule will look like, the source of which is the database server, and the destination is any external nodes, as well as any internal, excluding Web-servers.
If such an event is detected, the network traffic analysis system immediately generates a correspondence alarm and, depending on the settings, sends it to SIEM, using the means of communication with the administrator, or can even automatically block the detected violation (Cisco Stealthwatch does this by interacting with Cisco ISE )
Recall that when I mentioned a case with Equifax, I mentioned that attackers used an encrypted channel to dump data. For DLP, this traffic becomes an insoluble task, but for NTA-class solutions, they do not – they track any excess traffic or unauthorized interaction between nodes, regardless of the use of encryption.
Only one case was shown above (in the following materials we will consider other examples of using NTA for information security purposes), but in fact, modern solutions of the Network Traffic Analysis class allow you to create very flexible rules and take into account not only the basic parameters of the IP packet header:
but also to conduct a deeper analysis, up to associating the incident with the user name from Active Directory, searching for malicious files by hash (for example, obtained as a compromise indicator from the State Social Security Administration, FinCERT, Cisco Threat Grid, etc.), etc.
It is easy to implement. For example, this is how the usual rule looks for detecting all types of interaction between database servers and external nodes using any protocol over the past 30 days. We see that our databases “communicated” with nodes external to the DBMS segment using the DNS, SMB, and port 8088 protocols.
In addition to the tabular presentation of the results of the investigation or search, we can visualize them. For our scenario, a fragment of a network flow diagram might look like this:
And right from the same map we can manage policies – block connections or automate the process of creating monitoring rules for the flows of interest to us.
Here is a rather interesting and lively example of using Netflow monitoring tools (and other flow protocols) for cybersecurity. In the following notes, I plan to show how you can use NTA to detect malicious code (using the Shamoon example), malicious servers (using the DNSpionage campaign as an example), remote access programs (RAT), bypassing corporate proxies, etc.