[Oisf-users] Analysis of SSL-decrpyted traffic

[Cooper F. Nelson]

Hey Kevin,

Good to see there is the beginning of a consensus on this issue. I've 
been saying the following to my customers for years....

1.  Everybody should be blocking malicious domains and IPs at their 
perimeter, automatically.  Just that one control will eliminate the bulk 
of potential malicious behavior over secure channels.  This is 
"Defense-in-Depth" at its finest.

2.  A full "Next-Gen" EDR deployment with centralized logging/reporting 
should be a higher priority (with a higher ROI) then tls inspection for 
client networks.

3.  If you are *really* serious about inspecting clients TLS traffic, 
then you are a 'security positive' organization and should be doing the 
following at the very least.

     a.  A full 'zero trust' deployment for all client vlans. This is 
'deny ip any any' inbound and outbound.

     b.  A DMZ with an explicit proxy for accessing external domains (no 
NAT!).

     c.  Full domain whitelisting on the proxy.  I.e., both http and tls 
connections should only be allowed to trusted domains. Using an explicit 
proxy gets around the the TLS 1.3 encrypted SNI as it still requires an 
explicit domain name via the HTTP CONNECT method.  Access to new domains 
should be treated like firewall requests, with a business justification 
and sign-off by management.

Once you have that infrastructure in place, TLS inspection becomes 
trivial and can be done on a per-domain basis.  It's also easy to put in 
controls for data exfiltration, i.e. you can alert on any outbound data 
transfers that exceed expected client profiles.  You can do this all for 
free via open source projects like OPNids, as well.

-Coop

On 2/28/2020 2:51 AM, Kevin Ross wrote:
> Just to add some (hopefully useful) info around this. Decrypting 
> traffic (privacy issues and mitigation aside) such as signatures like 
> CobaltStrike beacons which may detect in clear; simply shoving them 
> down a HTTPS tunnel hides them. I have seen plenty examples red team 
> tools (empire and Cobalt) used maliciously with HTTPS sometimes just 
> as normal such as not using CobaltStrike stuff like malleable 
> profiles. There are issues though around certificate pinning, TLS 1.3 
> and other privacy features that may impact your decryption and also 
> non-decryption hunts (TLS 1.3 encrypts certificates and you get 
> encrypted SNI hiding the host it is connecting to)
>
> As mentioned before Suricata has signatures around TLS certs and IOCs 
> in encrypted traffic. I think though as time goes forward no 
> decryption detection need to be used. There are various commercial 
> solutions claiming this now. Basically it boils down to combination of 
> threat intel, behaviour and generally fishiness of the connection 
> often using machine learning to automate.
>
-- 
Cooper Nelson
Network Security Analyst
UCSD ITS Security Team
cnelson at ucsd.edu x41042