Maltrail trails contribution

The article describes ways how to contribute to Maltrail trails.

There are two way to contribute to Maltrail trails: Maltrail collaborative trails and Manual contribution.

Maltrail collaborative trails

"Maltrail collaborative trails" is placed on Google Sheets, where everybody is welcomed to share their trails to consider them incorporate into Maltrail's bases upstream.

Info: https://twitter.com/maltrail/status/1324440490889093125

Manual contribution

Before reading, please, be aware about Maltrail trails structure and Maltrail trails base format descriptions.

Usually public malware reports contain section, where indicators of compromisation (IOC) are defined -- list of files, their hashes/checksums and also network IOCs. And, basicly, network IOCs are presented in arbitrary form and often without any pre-filtering. One can meet mix of IP-addresses list, domains list, domain:port list, URL lists, etc.

Maltrail proposes the best-practices list how to contribute to trails.

Maltrail's best-practices list for trails contribution

1. Detection for legit, but compromised domains

Before adding domain for detection, do pre-check: if domain is legit itself, but is/was compromised by attacker. In case of compromised legit domain, full-path detection is the only way.

Example: Legit domain somegooddomain.com was comromised by evil-malware and began to manage its control-centre address: somegooddomain.com/some-path/evil-malware.c2.

• Incorrect detection: somegooddomain.com
• Correct detection (full-path detection): somegooddomain.com/some-path/evil-malware.c2.

In some cases the generic detection: /some-path/evil-malware.c2 can be added only or as an add-on sign:

This will cover all suchlike cases without false capturing of legit domains themselves -- (somegooddomain.com)/some-path/evil-malware.c2. See Example 2 section of Maltrail detection nuances article for details.

2. Detection for domain:port case

In case, when IOC is published as domain:port scheme, the best way is to add two trails -- IP:port + domain.

Example: evil.domain:1234 is given. Via information of passive DNS replication service, the IP-address 1.2.3.4 is resolved for evil.domain.

Correct way to add the trail to Maltrail:

Also would be useful to switch CHECK_HOST_DOMAINS option to true value in /maltrail.conf file. When true this option checks values in Host header (along with standard non-HTTP checks) for malicious DNS trails. Downside: this can increase the number of events in Maltrail's logs. See Example 3 section of Maltrail detection nuances article for details and customer's request for extending of URL-match.

3. Detection for IP and/or IP:port case

Usually IOC-publishers put IP-addresses lists just as is with no details about specific port(s) connections. And often such information about connection port is useful for putting granular detection or being as an auxiliary detection for various njrat-based malware C&C connections. Sometimes information of connection port(s) can be found in base text of article. In case, if there's no information about connection port(s), use http:// prefix for detection.

• Incorrect detection: 1.2.3.4
• Correct detection (IP:port): 1.2.3.4:1234 or http://1.2.3.4.

4. Nuances of ports http://|:80 and or https://|:443 detection

Let's consider real-life case:

One can see one sign, which can be added in two ways: as http://192.3.245.147 (URL-matching) and as 192.3.245.147:80 (IP:port matching). Both of ways are correct to use, but preferable is the URL-matching: http://192.3.245.147.

In case of https://192.3.245.147, the correct way for Maltrail detection is 192.3.245.147:443 (IP:port matching).

5. Nuances of http://, https:// and www. prefixes for domain detection

When http(s)://evil.domainor http(s)://www.evil.domain is given, one must ommit these prefixes, adding just domain name only: evil.domain.

The reason is if www.evil.domain detection is put, Maltrail will be unable to cover evil.domain detection. But, if evil.domain detection is put, both of variants -- evil.domain and (www).evil.domain would be covered by detection. See Example 1 section of Maltrail detection nuances article for details.

6. Nuances of naming, when new trail is getting added

Sometimes one can face with situation, when new trail should get added. When this trail is gonna to be proposed to Maltrail's upstream, it should be compliant to Maltrail trails structure and Maltrail trails base format. In particular constant naming scheme must be in use.

• Usually trail's name displays threat name. For example: /matanbuchus.txt contains trails, which identify Matanbuchus malware network activity.

• Also trail name can have two or more idnetificational signs. Such signs must be separated with _sign. This is applicable for OS-specific malwares (ostype_name-of-malware.txt), APT (apt_name-of-apt.txt):

7. Nuances, when Github is unable to display content of trail

When Github is unable to display content of trail and, hence, to provide possibility to update trail via web, the simpliest way is to start new trail with the same name, but with numeric sign, separated with - sign. Example: /cobaltstrike-1.txt, which is the continuation of initial /cobaltstrike.txt trail:

Also adding respective note is the best practice to keep: