<div dir="ltr">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)<div><br></div><div>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. </div><div><br></div><div>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 <a href="https://engineering.salesforce.com/gquic-protocol-analysis-and-fingerprinting-in-zeek-a4178855d75f?gi=bf8da3484cd7">https://engineering.salesforce.com/gquic-protocol-analysis-and-fingerprinting-in-zeek-a4178855d75f?gi=bf8da3484cd7</a>). </div><div><br></div><div>JA3 asking for a friend (2019): <a href="https://www.youtube.com/watch?v=HrP6Ep3xgQM&t=684s">https://www.youtube.com/watch?v=HrP6Ep3xgQM&t=684s</a></div><div>Network forensics in an encrypted world (2017 but covers a lot of indicators you can hunt on) <a href="https://www.youtube.com/watch?v=APHlvFaUEKE&t=1930s">https://www.youtube.com/watch?v=APHlvFaUEKE&t=1930s</a></div><div>Encrypted things: Network detection and response in an encrypted world <a href="https://www.youtube.com/watch?v=HPvIGP2mgbI&t=2667s">https://www.youtube.com/watch?v=HPvIGP2mgbI&t=2667s</a></div><div>Security Onion Conference 2019: Finding traffic anomalies using SSL certificates <a href="https://www.youtube.com/watch?v=-WD9BWlENwc&t=762s">https://www.youtube.com/watch?v=-WD9BWlENwc&t=762s</a></div><div><br></div><div>Using combinations of cert, fingerprinting and threat intel can be useful and hunting for beaconing too using tools like RITA (free for zeek data) <a href="https://www.activecountermeasures.com/blog-beacon-analysis-the-key-to-cyber-threat-hunting/">https://www.activecountermeasures.com/blog-beacon-analysis-the-key-to-cyber-threat-hunting/</a>. 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.</div><div><br></div><div>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.</div><div><br></div><div>Hope those videos and info are helpful to people.</div><div><br></div><div>Kind Regards,</div><div>Kevin Ross</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 26 Feb 2020 at 10:30, Federico Foschini <<a href="mailto:undicizeri@gmail.com">undicizeri@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><p style="margin:0px 0px 1.2em">Hello Nelson thank you for your insights.</p>
<p style="margin:0px 0px 1.2em">The inbound case obviously is the more interesting one since you can inspect all inbound attacks hitting your servers.<br>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.</p>
<p style="margin:0px 0px 1.2em">Also I read that ET is planning to release some signature specifically for TLS-inspected traffic.</p>
<p style="margin:0px 0px 1.2em">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:</p>
<pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;background-color:rgb(248,248,248);white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block">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
</code></pre><p style="margin:0px 0px 1.2em"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">enp4s0</code> is the firewall mirror port and <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">enp3s0</code> is the switch.</p>
<p style="margin:0px 0px 1.2em">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.</p>
<div title="MDH:SGVsbG8gTmVsc29uIHRoYW5rIHlvdSBmb3IgeW91ciBpbnNpZ2h0cy48ZGl2Pjxicj48L2Rpdj48
ZGl2PlRoZSBpbmJvdW5kIGNhc2Ugb2J2aW91c2x5IGlzIHRoZSBtb3JlIGludGVyZXN0aW5nIG9u
ZSBzaW5jZSB5b3UgY2FuIGluc3BlY3QgYWxsIGluYm91bmQgYXR0YWNrcyBoaXR0aW5nIHlvdXIg
c2VydmVycy48L2Rpdj48ZGl2PlVuZm9ydHVuYXRlbHkgaXQgc2VlbXMgdGhlIHdheSB0byBnbyBm
b3IgYWxsIGZpcmV3YWxsIHZlbmRvcnMgaXMgdG8gc2VsbCB0aGUgY2xpZW50IFNTTCBpbnNwZWN0
aW9uIGFzIHRoZSBob2x5IGdyYWlsIHRvIHNvbHZlIGFsbCBzZWN1cml0eSBwcm9ibGVtcywgSSBh
Z3JlZSB3aXRoIHlvdSB0aGF0IGlzIG5vdCBzbyA8c3BhbiB6ZXVtNGMwPSIxNTgyNzEyMzA4OTk4
IiBkYXRhLWRkbndhYj0iMTU4MjcxMjMwODk5OCIgY2xhc3M9Im5nIiBkYXRhLXdwa2d2PSJ0cnVl
Ij51c2VmdWw8L3NwYW4+Jm5ic3A7YnV0IHNvbWUgb2Ygb3VyIGNsaWVudHMgaGF2ZSBpdCBlbmFi
bGVkIHNvIGFuYWx5emluZyB0aGUgdHJhZmZpYyBvbiBzdXJpY2F0YSB3b3VsZCBiZSB1c2VmdWwg
Zm9yIG1lLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QWxzbyBJIHJlYWQgdGhhdCBFVCBpcyBw
bGFubmluZyB0byByZWxlYXNlIHNvbWUgc2lnbmF0dXJlIHNwZWNpZmljYWxseSBmb3IgVExTLWlu
c3BlY3RlZCB0cmFmZmljLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SG93ZXZlciBJIGRpZCBz
b21lIHRlc3RpbmcgYW5kIGl0IGxvb2tzIGxpa2UgdGhhdCBpZiBJJ20gb25seSBzbmlmZmluZyBm
cm9tIHRoZSBmaXJld2FsbCBpbnRlcmZhY2UgZXZlcnl0aGluZyBpcyB3b3JraW5nIGZpbmUuIFRo
ZSBpc3N1ZSBzdGFydHMgd2hlbiBJJ20gc25pZmZpbmcgYm90aCBmcm9tIHRoZSBtaXJyb3IgcG9y
dCBvbiB0aGUgc3dpdGNoIGFuZCBvbiB0aGUgZmlyZXdhbGwgd2l0aCB0aGlzIGNvbmZpZ3VyYXRp
b246PC9kaXY+PGRpdj5gYGA8L2Rpdj48ZGl2PmFmLXBhY2tldDo8YnI+Jm5ic3A7IC0gaW50ZXJm
YWNlOiBlbnA0czA8YnI+Jm5ic3A7ICZuYnNwOyB0aHJlYWRzOiAyPGJyPiZuYnNwOyAmbmJzcDsg
Y2x1c3Rlci1pZDogMTxicj4mbmJzcDsgJm5ic3A7IGNsdXN0ZXItdHlwZTogY2x1c3Rlcl9mbG93
PGJyPiZuYnNwOyAmbmJzcDsgZGVmcmFnOiB5ZXMgIyBUbyB1c2UgdGhlIHJpbmcgZmVhdHVyZSBv
ZiBBRl9QQUNLRVQsIHNldCAndXNlLW1tYXAnIHRvIHllczxicj4mbmJzcDsgJm5ic3A7IHVzZS1t
bWFwOiB5ZXMgPGJyPiZuYnNwOyAmbmJzcDsgdHBhY2tldC12MzogeWVzIDxicj4mbmJzcDsgLSBp
bnRlcmZhY2U6IGVucDNzMDxicj4mbmJzcDsgJm5ic3A7IHRocmVhZHM6IDI8YnI+Jm5ic3A7ICZu
YnNwOyBjbHVzdGVyLWlkOiAyPGJyPiZuYnNwOyAmbmJzcDsgY2x1c3Rlci10eXBlOiBjbHVzdGVy
X2Zsb3c8YnI+Jm5ic3A7ICZuYnNwOyBkZWZyYWc6IHllcyAjIFRvIHVzZSB0aGUgcmluZyBmZWF0
dXJlIG9mIEFGX1BBQ0tFVCwgc2V0ICd1c2UtbW1hcCcgdG8geWVzPGJyPiZuYnNwOyAmbmJzcDsg
dXNlLW1tYXA6IHllczxicj4mbmJzcDsgJm5ic3A7IHRwYWNrZXQtdjM6IHllczxicj48L2Rpdj48
ZGl2PmBgYDwvZGl2PjxkaXY+YGVucDRzMGAgaXMgdGhlIGZpcmV3YWxsIG1pcnJvciBwb3J0IGFu
ZCBgZW5wM3MwYCBpcyB0aGUgc3dpdGNoLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QWxsIHRy
YWZmaWMgbWlycm9yZWQgZnJvbSB0aGUgc3dpdGNoIGlzIHByb2Nlc3NlZCB3aGlsZSB0aGUgb25l
IGZyb20gdGhlIGZpcmV3YWxsIGlzIG5vdC4gV2hlbiBkb2luZyBhbiBTU0wgY29ubmVjdGlvbiBp
biBaZWVrIEkgY2FuIHNlZSB0aGUgU1NMIGVuY3J5cHRlZCBmbG93IG1pcnJvcmVkIGZyb20gdGhl
IHN3aXRjaCBhbmQgYWxzbyB0aGUgSFRUUCBkZWNyeXB0ZWQgdHJhZmZpYyBmcm9tIHRoZSBmaXJl
d2FsbC4gSW4gc3VyaWNhdGEgSSBzZWUgb25seSB0aGUgU1NMIGVuY3J5cHRlZCB0cmFmZmljLjwv
ZGl2Pg==" style="height:0px;width:0px;max-height:0px;max-width:0px;overflow:hidden;font-size:0em;padding:0px;margin:0px"></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 25 feb 2020 alle ore 20:04 Cooper F. Nelson <<a href="mailto:cnelson@ucsd.edu" target="_blank">cnelson@ucsd.edu</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <p>Have you tried logging http to file, to ensure that suricata is
      decoding it?  <br>
    </p>
    <p>Have you tried enabling the http-events rules?</p>
    <p><a href="https://github.com/OISF/suricata/blob/master/rules/http-events.rules" target="_blank">https://github.com/OISF/suricata/blob/master/rules/http-events.rules</a></p>
    <p>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.  <br>
    </p>
    <p>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.  <br>
    </p>
    <p>-Coop<br>
    </p>
    <div>On 2/25/2020 8:53 AM, Federico Foschini
      wrote:<br>
    </div>
    <blockquote type="cite">
      <p style="margin:0px 0px 1.2em">Hello,<br>
        I’ve configured my firewall to mirror SSL-decrypted traffic to a
        server in which I’m running suricata 5.0</p>
      <p style="margin:0px 0px 1.2em">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).</p>
      <p style="margin:0px 0px 1.2em">In <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">suricata.yaml</code>
        I’ve added port 443 in HTTP_PORTS variable:</p>
      <pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;background-color:rgb(248,248,248);white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block">port-groups:
    HTTP_PORTS: "[80,81,311,383, 443, ...]"
</code></pre>
    </blockquote>
    <pre cols="72">-- 
Cooper Nelson
Network Security Analyst
UCSD ITS Security Team
<a href="mailto:cnelson@ucsd.edu" target="_blank">cnelson@ucsd.edu</a> x41042</pre>
  </div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">Federico Foschini.</div>
_______________________________________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundation.org</a><br>
Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/support/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
<br>
Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/training/</a></blockquote></div>