How Attackers and Victims Detection works in ntopng

Posted · Add Comment

In  recent ntopng versions, alerts have been significantly enriched with metadata useful to understand network and security issues. In this post, we focus on the “Attacker” and “Victim” metadata, used to enrich flow alerts and label hosts. Specifically, the client or the server of a flow is labelled as “Attacker” when it is, with high probability, the originator of one or more security issue. Similarly, when the client or the server is deemed to be under attack, it is labelled ad “Victim”. For non security-oriented use cases (e.g. severe packet drops), hosts affected/originating the issue are still highlighted with a high score value but they are not labelled as attacker/victim as these words are used only in security.

For example:

  • In a DNS request for a suspicious DGA domain name, the client is considered to be an “Attacker” as it is the originator or such potentially malicious request.
  • When Remote Code Execution (RCE), Cross Site Scripting (XSS) and SQL injection attempts are detected, the client is the “Attacker” and the server is the “Victim” as it is being probed/attacked by the client who is trying to exploit its vulnerabilities.
  • When a binary/.exe application is downloaded over HTTP pretending it is an harmless file such as a PNG image (see Introducing nDPI Risk Analysis), the client is considered to be compromised and the server is considered to be malicious as it is sourcing suspicious files so both are labelled as “Attacker”.
  • A DNS data exfiltration alert has both its client and server labelled with “Attacker” as carrying out a data exfiltration requires both the client and the server to be running exfiltration software such as iodine.

In the reminder of this post, we analyse Hancitor Infection (pcap courtesy of Malware-Traffic-Analysis) in order to demonstrate the effectiveness of ntopng with its new “Attacker” and “Victim” metadata in detecting this kind of security issues.

An Hancitor infection is basically a multi-stage chain of events that causes the targeted host to download malware files actually turning it in a malicious host in the hands of a threat actor. This post discusses the details of this kind of infections.

Let’s see what happens when we use ntopng to analyse the pcap with the Hancitor infection. You can start ntopng as

ntopng -i 2021-06-01-Hancitor-with-Cobalt-Stike-and-netping-tool.pcap -m ""

First of all, it emerges pretty clearly from the header bar that there’s something suspicious going on, as there are thousands of flows with errors and warnings. Note that the number of alerted flows can vary according to your configuration (see in the left sidebar menu “Settings” -> “User Scripts”)

Clicking on the red “Errors” badge brings us to the flows page, filtered by flows having errors. By opening the “Status” dropdown, it becomes quite clear there is some suspicious activity as highlighted by the several suspicious DGA domain requests as well as by 2000+ of suspicious file transfers.

However, this page is not enough to understand if there is an attack going on and who is the source of the trouble. This becomes more evident when visiting the flow alerts page. Before browsing the alerts, we can set a filter to only see security-related alerts having an “Attacker”

With this filter, ntopng shows only alerts for which it has detected an attacker. Indeed, Suspicious DGA Domain alerts start popping out. The skull symbol 💀 helps in identifying the “Attacker” that, in this case, is the Hancitor-infected Windows client host.

If we keep browsing the alerts with an attacker, we will also see thousands of Suspicious File Transfer alerts. For this kind of alerts, two skulls 💀 are shown. Indeed, it is reasonable to mark as “Attacker” not only the compromised Windows host, but also the server that is distributing malicious files.

But why does file transfers for seemingly innocuous files ga.js are deemed to be suspicious? Well, because in practice, these are not Javascript files! Sometimes, they are just empty files, some other times they are binary files with unknown contents. This can be verified simply by extracting these ga.js files with Wireshark and demonstrates the effectiveness of ntopng in detecting these suspicious transfers taking place in the network. Additional suspicious files can be discovered simply by browsing these alerts. Those are requests to download Ficker Stealer and Cobal Strike.

You can identify attacker/victim in int Host Map (left sidebar menu “Maps” -> “Hosts”)

as they are the two outliers in the X/Y axis. Clicking on the bubble you can immediately jump to the host page and see what happens, as already discussed in this article.

Finally, it is worth mentioning that “Attacker” and “Victim” metadata are available also for host alerts, in order to spot hosts doing suspicious activities such as SYN scans, or high volumes of DNS or ICMP traffic. In addition to use the score in realtime as shown above, you can also monitor the score overtime in order to detect when it deviates from its expected behaviour. This is compulsory to detect “soft” behavioral changes that wouldn’t be detected with the score technique shown above, that instead is used to spot attackers with a more aggressive behaviour.

In summary, we have implemented in ntopng both “signature based” (i.e. by means of alerts) and “behavioural based” (i.e. metric analysis overtime to detect deviations from expected behaviour) anomaly detection. In a future port, we’ll elaborate more in detail how behavioural changes are detected and reported.


Enjoy !