[Oisf-users] Analysis of SSL-decrpyted traffic

Fri Feb 28 10:51:01 UTC 2020

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.

On doing this using tools available now I found these talks very useful in
understanding options and techniques in locating malicious encrypted
traffic in CnC communications. Making sure you have fingerprinting (JA3 and
GQUIC
https://engineering.salesforce.com/gquic-protocol-analysis-and-fingerprinting-in-zeek-a4178855d75f?gi=bf8da3484cd7
).

JA3 asking for a friend (2019):
https://www.youtube.com/watch?v=HrP6Ep3xgQM&t=684s
Network forensics in an encrypted world (2017 but covers a lot of
indicators you can hunt on)
https://www.youtube.com/watch?v=APHlvFaUEKE&t=1930s
Encrypted things: Network detection and response in an encrypted world
https://www.youtube.com/watch?v=HPvIGP2mgbI&t=2667s
Security Onion Conference 2019: Finding traffic anomalies using SSL
certificates https://www.youtube.com/watch?v=-WD9BWlENwc&t=762s

Using combinations of cert, fingerprinting and threat intel can be useful
and hunting for beaconing too using tools like RITA (free for zeek data)
https://www.activecountermeasures.com/blog-beacon-analysis-the-key-to-cyber-threat-hunting/.
Fingerprinting has limitations though and while useful for known bad
hunting for rarity, newness etc. of Ja3/JA3s and destination combos is a
useful hunt.

I find the big issue though with fingerprinting is limited fingerprint
databases that are FP prone. Understanding for instance outbound Powershell
(downloads, beaconing implants like CobaltStrike) would be good to
understand and label. But every version of powershell on every OS can
generate different fingerprint. Without some processes to generate these
mappings using them gets difficult and flagging every connection with an
alert would be pointless, a much better just to log that mapping into
metadata and then into tools like elasticstack, splunk etc. or enrich it
into those tools but there is a lot of difficultly in getting all
variations of fingerprints (software versions + OS). Known bad is usable
though too although some hashes without JA3s are very false positive prone.

Hope those videos and info are helpful to people.

Kind Regards,
Kevin Ross

On Wed, 26 Feb 2020 at 10:30, Federico Foschini <undicizeri at gmail.com>
wrote:

> Hello Nelson thank you for your insights.
>
> The inbound case obviously is the more interesting one since you can
> inspect all inbound attacks hitting your servers.
> Unfortunately it seems the way to go for all firewall vendors is to sell
> the client SSL inspection as the holy grail to solve all security problems.
> I agree with you that is not so useful but some of our clients have it
> enabled so analyzing the traffic on suricata would be useful to me.
>
> Also I read that ET is planning to release some signature specifically for
> TLS-inspected traffic.
>
> However I did some testing and it looks like that if I’m only sniffing
> from the firewall interface everything is working fine. The issue starts
> when I’m sniffing both from the mirror port on the switch and on the
> firewall with this configuration:
>
> af-packet:
>   - interface: enp4s0
>     threads: 2
>     cluster-id: 1
>     cluster-type: cluster_flow
>     defrag: yes # To use the ring feature of AF_PACKET, set 'use-mmap' to yes
>     use-mmap: yes
>     tpacket-v3: yes
>   - interface: enp3s0
>     threads: 2
>     cluster-id: 2
>     cluster-type: cluster_flow
>     defrag: yes # To use the ring feature of AF_PACKET, set 'use-mmap' to yes
>     use-mmap: yes
>     tpacket-v3: yes
>
> enp4s0 is the firewall mirror port and enp3s0 is the switch.
>
> All traffic mirrored from the switch is processed while the one from the
> firewall is not. When doing an SSL connection in Zeek I can see the SSL
> encrypted flow mirrored from the switch and also the HTTP decrypted traffic
> from the firewall. In suricata I see only the SSL encrypted traffic.
>
> Il giorno mar 25 feb 2020 alle ore 20:04 Cooper F. Nelson <
> cnelson at ucsd.edu> ha scritto:
>
>> Have you tried logging http to file, to ensure that suricata is decoding
>> it?
>>
>> Have you tried enabling the http-events rules?
>>
>> https://github.com/OISF/suricata/blob/master/rules/http-events.rules
>>
>> In my personal experience, I haven't seen any evidence of malicious
>> behavior over tls from common sources (trusted domains/IPs) to our
>> clients.  This is based on cross-referencing EDR alerts with suricata.  We
>> sinkhole bad IPs and domains automatically, which will stop the bulk of
>> these attacks entirely from 'known bad' sources.  I have observed malicious
>> activity inbound over tls to servers, however.
>>
>> For malware that uses tls, like Dridex, the EmergingThreats team will
>> release signatures for the certificates, so you may actually be losing
>> visibility by decoding the traffic.  I'm not sure if they have sigs to
>> detect the decoded CnC traffic for malware families that utilize tls.
>>
>> -Coop
>> On 2/25/2020 8:53 AM, Federico Foschini wrote:
>>
>> Hello,
>> I’ve configured my firewall to mirror SSL-decrypted traffic to a server
>> in which I’m running suricata 5.0
>>
>> I cannot trigger any alert on this type of traffic, even if using zeek or
>> wireshark I can clearly see that the traffic is HTTP (but on port 443).
>>
>> In suricata.yaml I’ve added port 443 in HTTP_PORTS variable:
>>
>> port-groups:
>>     HTTP_PORTS: "[80,81,311,383, 443, ...]"
>>
>> --
>> Cooper Nelson
>> Network Security Analyst
>> UCSD ITS Security Teamcnelson at ucsd.edu x41042
>>
>>
>
> --
> Federico Foschini.
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>
> Conference: https://suricon.net
> Trainings: https://suricata-ids.org/training/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20200228/aad33d80/attachment.html>