Re: [Add] [EXTERNAL] Re: Malware adopting DoH

[Brian Dickson <[e-mail]>]

Sorry for being late to this thread. It seems to have gone into the weeds,
but it started in a pretty decent place, so I'll do a "Billy Martin" and go
back there to join in.

All of the following snippets have been selected to reinforce one point,
hiding in plain sight (a deliberate choice of words):

The real problem with malware is detecting it in the first place. Once you
know the domains/URL(s)/IPs it is using, there are numerous ways to take
action, be it on the browser, on the network, via DNS, or via routing
(black-holing).

Public DoH resolvers do several things to make things worse than they were:

   - They make it possible for malware to do resolution over DoH
   - They provide lots of traffic to those DoH resolvers in which the
   malware's traffic can effectively hide
   - They prevent correlation between DNS lookups and subsequent HTTPS
   traffic, where an absence of visible DNS lookups prior to HTTPS traffic
   would be a "signal" that detection systems could use

Malware using public DoH resolvers is the lowest hanging fruit for malware
authors.
The incremental effort needed to deploy a DoH endpoint (e.g. proxy) on some
random HTTPS server is extremely small, and has all of the same benefits to
a malware author that using Google or Cloudflare or Quad9 does, while
bypassing any malware filtering those resolvers may do.

In other words, it isn't the centralization and availability that is of
greatest value to malware authors.
Blocking on centralized resolvers would trigger the next step in the arms
race between malware authors and everyone else -- a step that creates the
biggest problem for detection.

If only malware used DoH, and everything else used DoT, a variety of
policies would be possible that preserve privacy, enable malware detection,
and enable enforcement of network-enforced policies (as an optional
benefit, not a requirement).
Networks who are happy for well-known DoT public resolvers to be used,
would be able to white-list those, and black list all other DoT endpoints.
This prevents the malware use of "random" DoT servers (unlike the DoH
scenario, where this isn't possible to do.)
If those DoT public resolvers filter malware-related DNS entries, the
network would not need to see the DNS queries. This presumes the
malware-filtering DNS has other sources for detecting which DNS entries
correspond to malware.
If the network wanted to inspect DNS traffic to correlate DNS to HTTPS
traffic, it could block DoT traffic to any resolver other than its own
specific inspection system. This is an independent model, rather than the
public DoT malware blocking via DNS, which is very dependent on the DoT
service.

Use of DoT for DNS, with local DoT resolvers and DNS-before-HTTPS would
also be useful for detecting use of DoH. It would not necessarily be 100%
foolproof, but it doesn't need to be, to be of value.

The DoH ecosystem is very much like the illegal narcotics trade. The
suppliers (DoH public resolvers) only spring up due to demand from the
buyers (the browsers). If it is possible to convince the browsers to enter
into a diversion program (switch from plans to use DoH to planning to use
DoT), it won't be necessary to consider a "War On Drugs" (war on DoH), and
the longer term effect would be the reduction or elimination of DoH
services being offered.

So, TL;DR: the problem isn't that malware can use DoH offered by public
resolvers; it is that DoH being used widely provides cover for malware
using DoH to any destination (public or otherwise), impacting malware
detection mechanisms.

Brian


On Fri, Sep 13, 2019 at 7:06 AM Ted Lemon <[e-mail]> wrote:

> A question you might ask is, “how do we know that this malware is using
> DoH?”  Also, now that it is doing DoH, what new opportunities exist for
> stopping it?  Is it easier or harder to trick it?
>
> It’s all very well and good to point out that it’s using DoH and that this
> blocks certain mitigation strategies, but eg if Google can mitigate it
> centrally we might be better off, not worse off, as a whole.
>
> On Sep 12, 2019, at 11:46, Dixon, Hugh <Hugh.Dixon=[e-mail]>
> wrote:
>
> 
>
> While tis true that there have always been other methods than Do53 for
> Malware C&C and exfil, the thing is that the existence of DoH services from
> Google (and other very large-scale internet entities) is (IMHO) quite a
> distinct change in the availability of
>
>
> A wide spread of steady-flow “genuine” traffic (e.g. 24h peak-to-mean of ~
> 2 for example for DNS) in which to hide
>
>
>
> However, it does beg the question of (all) operators of DoH infrastructure
> as to whether they are delivering “a better internet” if they ignore the
> assistance to criminals that they offer if they don’t actively take a role
> against them.
>
>
>
> To address the question, perhaps the “what can we do about mitigating the
> opportunities for harm generated through innovation?” is the better end
> point?
>
> H
>
>
>
> On 10/09/2019, 16:14, "Add on behalf of Alec Muffett" <
> [e-mail] on behalf of [e-mail]> wrote:
>
>
>
> On Mon, 9 Sep 2019, 22:16 Bret Jordan, <[e-mail]> wrote:
>
> Just making sure people here have seen this..
>
>
>
>
> https://www.proofpoint.com/us/threat-insight/post/psixbot-now-using-google-dns-over-https-and-possible-new-sexploitation-module
> <https://eur01..safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.proofpoint.com%2Fus%2Fthreat-insight%2Fpost%2Fpsixbot-now-using-google-dns-over-https-and-possible-new-sexploitation-module&data=02%7C01%7Chugh.dixon%40sky.uk%7Cbe842998fe8f4078b46908d73601822c%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C637037252427909693&sdata=7V5bD7OSaLMqCAAqiL8oBg8F4HNgU8Qb2FnND9lWw9g%3D&reserved=0>
>
>