Source and Destination: Who is the Attacker?

Every Suricata alert provides a source and destination address. Before doing much with an alert, an analyst needs to determine which host is the attacker and which is the victim. This is a common part of alert triage, and across a busy console it can consume a considerable amount of attention. The question is how much of that work can be handled automatically so analysts can spend more time on the parts of triage that actually require human judgement?

Traffic Direction does not tell you Intent

Two attributes, src_ip and dest_ip, tell analysts the direction of the traffic being observed. They tell you who sent the traffic and who received it. These are important facts, but they don’t tell us about the intent behind the connection. From these two attributes alone, we cannot determine which side is the attacker and which is the victim. Suricata rules can provide some help here. A rule author can use the optional target keyword to mark the source or destination as the target of the attack. This gives the alert more security context than src_ip and dest_ip provide on their own. However, target is optional, and many rules do not define it. Even when it is, it tells you which host the rule considers the target, but does not necessarily provide the complete interpretation of who is acting as the attacker and who is acting as the victim in the given event.

When the Victim is the Source

This distinction matters because the source and the attacker are not always the same host. Consider a scenario where an internal host is infected with malware that is beaconing out to a command-and-control server. While the alert would show the internal host appearing to be the source and the external server as the destination, we know from a security perspective that the internal host is the compromised victim and the external server is adversary-controlled, meaning it is being controlled by the attacker and belongs to their infrastructure. Thus if we assume the source is the attacker and the destination is the victim, we end up interpreting the alert backwards.

Where Verdix Comes In

Verdix makes this assessment up front on every alert. It looks at information already available from Suricata, such as the rule category, the attack_target hint when one is present, and whether each host falls inside the HOME_NET defined in your suricata.yaml file. Using these signals, Verdix determines which host is likely the attacker and which is likely the victim, and shows the reasoning behind the assessment. In the beaconing scenario above, the internal address would be identified as the likely victim and the external server as the likely attacker. Verdix displays this assessment alongside the original source and destination information in the investigation review. This lets the analyst see both the direction of the connection and Verdix’s interpretations of what that connection most likely represents.

Uncertainty is Part of the Assessment

When the available evidence is not enough to support an attacker/victim assessment, Verdix says so. For example, if two hosts are both inside HOME_NET and there is nothing in the alert to clearly distinguish their roles, Verdix marks the result as ambiguous rather than forcing a confident answer. This behavior is deliberate. A useful triage tool should be able to show when the evidence supports a conclusion and when it does not. Verdix shows the signals behind its assessment and makes uncertainty visible instead of hiding it behind a confident guess. The goal is not to replace the analyst’s judgement, but to make the information behind that judgement easier to see.

Only the First Step

If you already run Suricata, your alerts contain more context than src_ip and dest_ip alone can show. Understanding what those connections actually mean is one of the first steps in triage. Verdix takes a first pass at that interpretation, helping analysts spend less time resolving basic context and more time on alerts that still require human judgement. Attacker and victim assignment is only one part of that process. There is more that goes into a Verdix verdict, and I’ll break down those pieces in future posts.

The role assignment logic is open source under AGPL, at github.com/verdixsec/verdix.