-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Maltrail detection nuances
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:
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:
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.
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
- FAQ - Frequently Asked Questions
- Trail classes - Information about different classes of trails
- Specific detections - Information about Maltrail specific detections
- Maltrail trails structure - Information about Maltrail trails structure
- Maltrail trails base format - Information about Maltrail trails base format
- Maltrail trails contribution - Information about Maltrail trails contribution
- Maltrail detection nuances - Information about Maltrail detection nuances
- Maltrail verdicts on Validin Threat Hunting and DNS Enrichment Platform - Information about Maltrail verdicts on Validin Threat Hunting and DNS Enrichment Platform
- UI tips and tricks - Brief list of user interface features
- CLI management for Maltrail - Information about CLI management for Maltrail
- Miscellaneous - Miscellaneous HOWTOs