On Tue, Mar 13, 2018 at 2:21 PM, John Hardin <jhar...@impsec.org> wrote:
> On Tue, 13 Mar 2018, Olivier Coutu wrote:
>> In the last few months, we have seen an increase of generic emails (e.g.
>> regarding unpaid invoices) being sent with links to infected legitimate
>> websites hosting malware. This malware often comes in the form of docs with
>> macros e.g. https://pastebin.com/VHz41RUL
>> In a lot of cases, neither the sender nor the URL are listed in any
>> blacklists at send time, and we are looking into ways to deal with these
>> links. We have developed some heuristics based on the text but this is more
>> reactive than proactive and the spams often are very similar to legitimate
>> emails. Ideally we would be able to see what is /really/ behind these links.
>> The technologies we know exist are:
>> a) Link following
>> Whether it is only for url shorteners or for all links, simulating a click
>> could give us info on what will happen, but has implications when the
>> website interprets that like a click from the user and updates their
>> database in some way such as unsubscribing a user.
>> b) Link rewriting
>> Rewrite the link so that it is analysed by the anti-spam provider at
>> click-time. Costly to implement and breaks message integrity/DKIM. Even
>> after 24h, a lot of these infected websites are not listed on blacklists.
>> This method also has privacy implications.
>> c) DNS-based approaches
>> Similar to link rewriting, use a dns-firewall such as Cisco Umbrella to
>> block queries to malicious websites. Our tests indicate that this does not
>> work very well for the aforementioned infected websites. It might work well
>> for C&C servers but we feel like that is a bit late to avoid an infection.
>> Are there other solutions that we have not thought of? Are any of you
>> having trouble with these types of links?
> d) Don't accept emails from outside your organization that link to hosted
> documents. The document needs to be attached, so that it can be scanned.
> Unfortunately this is not feasible if you're not a (at least
> semi-)monolithic organization where you can apply such policies.

I don't think denying access to direct downloads in email is really a
policy that would work in any moderately sized organization. I tried
looking at this in the recent past, and it would block a ton of
legitimate email.

Also, in this particular case, you don't know that the link downloads
something until you actually click on it or follow it.

> e) if you are a (semi-)monolithic organization that uses a boundary proxy to
> control web access, then add such URLs to that proxy's blocklist until the
> contents can be scanned, or so that the proxy does the redirect-through-AV
> automatically (not sure if that will work, though).

I think what some providers do is wrap the URL and at some point later
(after perhaps the domain or URL itself is listed by an RBL) disable
the link for when the recipient clicks the link or views the email. I
don't know how (or whether) they always break DKIM in the process.
That would be interesting to find out.

Reply via email to