Maltrail detection nuances - stamparm/maltrail GitHub Wiki

Maltrail uses records (trails) from its feed-based and static bases, when it parses network traffic flows. Depending on how detection trail (pattern) built is, Maltrail respectively displays results, when he "recognize" malicious network traffic flows.

  • Example 1:

Here one can see detection of domain abbyycommunity.com for ramnit malware. Prefix in bracket signs -- (www). does mean, that Maltrail's base contains explicit record for abbyycommunity.com domain, but doesn't contain www.abbyycommunity.com record.

Despite on that, detection for ramnit malware won't get lost and, if some other (preliminary unknown) domain (somedomain.abbyycommunity.com or yet.another.domain.abbyycommunity.com, etc) is met, Maltrail will anyway detect them as ramnit malware: (somedomain).abbyycommunity.com | ramnit (malware), (yet.another.domain).abbyycommunity.com | ramnit (malware) etc.

In case, when some domain is shared by various of malware families or a new malware starts to use domain of another previous malware, it globally doesn't really matter -- this is a signal, that known malware domain is in use again. But no problem to add new explicit detection (e.g. some-new-malware-family.abbyycommunity.com) for new malware family.

  • Example 2:

image

When explicit detection for malicious domain is absent, the respective malicious network connection can be caught with generic trail. That is demonstrated by real-life Android.Hydra malware case. See URL (type) column. After explicit detection for malicious domain was added, the type DNS (type) is displayed in statistics instead.

  • Example 3:

Here one can see detection of generic records, that Maltrail contains in its static bases. Detection by deneric records means, that some malware-related specific pattern was matched. And Maltrail administrator should pay attention to it.

Let's consider (www.powersept.ie)/js/mage/cookies.js | magentocore (malicious) detection example.

Here we have explicit detection by generic pattern -- /js/mage/cookies.js and non-explicitly detected domain, bordered by bracket signs -- (www.powersept.ie). And there are two ways of interpretation:

high 1) (www.powersept.ie) domain is related to magentocore (malicious) family, but its explicit detection is currently absent in Maltrail static base. And explicit detection for (www.powersept.ie) domain should be added.

medium 2) (www.powersept.ie) domain is legal site, but currently compromised with magentocore-related script /js/mage/cookies.js. In this case it's better to inform www.powersept.ie admins, that their website compromised is. When admins clean script /js/mage/cookies.js off, Maltrail detection will also disappear.

  • Example 4:

Detection with CHECK_HOST_DOMAINS true option in [Sensor] of /maltrail.conf file.

When true status, this option checks values in Host header for malicious DNS trails along with standard non-HTTP checks. Can be useful, when tracking DNS-requests with non-standard ports (see picture) as the auxiliary for IP:port (IPORT) detection. Downside: this can increase the number of events in Maltrail's logs.

Real case: Customer's question on extending URL-match detection