This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL/TLS decryption - Downloads

I am pleased this feature now exists in Intercept-X

We see one of the main attack vectors as follows:

  • User receives phishing e-mail or a macro-enabled attachment.
  • User clicks through warnings and executes the macro-enabled attachment. Or, they're tricked into a download.
  • It downloads an executable or payload etc, etc.

While we can block Downloads in a Web Control policy (particularly exe, DLL, etc) - it would never prevent Downloads through HTTPS connections.

Now we have the capability:

  • Given my use case above, is it possible to implement a policy on the endpoint that prevents users from downloading executables or potentially malicious payloads (i.e. Beacons)
  • If so, how do we avoid legitimate downloads (i.e. Microsoft Updates, Adobe, etc) - or do we simply have to whitelist wildcard domains?

I appreciate we can do this at the firewall level with SSL-inspection.

Ideas welcomed.

Thanks



This thread was automatically locked due to age.
Parents Reply Children
  • Good point. 
    Downloads triggered through Powershell or VBS are my primary concern. We have Sophos, Umbrella and SSL inspection in (some) sites - but this would be a useful control.

  • Network threat protection would block the request for the file from say a non browser process like cscript/wscript/Powershell.exe, etc.

    It would require Sophos Labs to have classified the IP or domain as hosting malicious content. This is your c2 type detection.

    If it does bring down the payload. The AMSI component would see the script at this point for processes that pull in the AMSI dll like Powershell, cscript, wscript. If it was written to disk it would be scanned also. 

    Behavioural would also have a run at it post execution.  There are many layers.