[Intelmq-dev] Destination host in malware feeds

Sebastian Wagner wagner at cert.at
Wed Jun 14 16:26:28 CEST 2017


I opened https://github.com/certtools/intelmq/issues/1007 for this


On 04/12/2017 11:17 AM, Thomas Hungenberg wrote:
> Hi all,
>
> next to the destination IP and port, malware sinkhole feeds commonly also
> include information on the destination 'host'. This value is usually taken
> from the 'Host:' header of the HTTP request sent to the sinkhole by the
> infected client. The corresponding columns in the feeds are usually called
> 'dsthost', 'http_host' (e.g. Shadowserver HTTP-Sinkhole-Drone) or 'cc_dns'
> (Shadowserver Botnet-Drone). The name 'cc_dns' is probably misleading.
>
> In most cases, the value of the destination host field in the feeds is a FQDN -
> but depending on how the malware sets up the "Host:" header in the HTTP requests,
> it may also be FQDN:Port, an IP address or IP:Port (or just some crap).
> Some malware families perform a DNS lookup for the (DGA based) C2 domain first
> and then only use the IP address in the HTTP requests instead of the domain name.
>
> I noticed that the IntelMQ parsers for the Shadowserver feeds simply try to
> map the value of 'http_host' to 'destination.fqdn', e.g.
>
> https://github.com/certtools/intelmq/blob/master/intelmq/bots/parsers/shadowserver/config.py
>
> Line 295: ('destination.fqdn', 'http_host'),
>
>
> The scripts we currently use for generating notifications to network owners
> use the following logic (pseudo code here) to extract the destination host information:
>
>     if (feed.dstip is a valid ip) {
>       destination.ip = dstip
>     }
>     else {
>       discard event   # destination IP is required
>     }
>
>     dsthost = feed.http_host
>     dsthost =~ s/:[0-9]+$//    # remove potential port information (we already have this information in dstport)
>     if (dsthost is a fqdn) {
>       destination.fqdn = dsthost
>     }
>     else {
>       do nothing   # dsthost is either an IP (which we already have in destination.ip) or useless data
>     }
>
>
> I'd like to suggest using a similar logic in the InteMQ parsers for the Shadowserver
> (an other malware sinkhole) feeds to not miss destination.fqdn information which comes
> in the form FQDN:Port - instead of writing the information to an extras field which is
> most probably not used by the output generators or even dropping the complete event.
>
>
>      - Thomas
>
> CERT-Bund Incident Response & Malware Analysis Team
> _______________________________________________
> Intelmq-dev mailing list
> Intelmq-dev at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev

-- 
// Sebastian Wagner <wagner at cert.at> - T: +43 1 5056416 7201
// CERT Austria - https://www.cert.at/
// Eine Initiative der nic.at GmbH - https://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20170614/548c8b3e/attachment.sig>


More information about the Intelmq-dev mailing list