Encrypted traffic has always posed more challenges to network defenders than plaintext traffic but thanks to some recent enhancements in NetWitness 11.2 and a really useful feed from Abuse.ch defenders have a new tool in their toolbox.
11.2 Added the ability to enable TLS certificate hashing by adding an optional parameter on your decoders
Decoder Configuration Guide for Version 11.2
(search for TLS certificate hashing - page 164)
- Explore > /decoder/parsers/config/parsers.options
- add this after the entropy line (space delimited) HTTPS="cert.sha1=true"
- Make sure the https native parser is enabled on the decoder
This new meta is the SHA1 hash of any DER encoded cerificates during the TLS handshake which is written to cert.checksum which is the same key that NetWitness Endpoint writes its values to.
Now is a good time to revisit your application rules that might be truncating encrypted traffic. Take advantage of new parameters that were added in 11.1 related to truncation after the handshake
Now that we have a field for the certificate hash we need a method to track known certificate checksums to match against.
sslbl.abuse.ch has a feed that tracks these blacklisted certificates as long with information to identify the potential attacker campaign.
This is the feed (SSLBL Extended) could also leverage the Dyre list as well.
https://sslbl.abuse.ch/downloads/ssl_extended.csv
Headers look like this
# Timestamp of Listing (UTC),Referencing Sample (MD5),Destination IP,Destination Port,SSL certificate SHA1 Fingerprint,Listing reason
Map the feed as follows
Configure > Custom Feeds > New Feed > Custom Feed
Add the url as above, recur every hour (get new data into the feed in reasonable time)
Apply to your decoders (and you will notice that the feed is also added to your Context Hub as well in 11.2 - which means you can create a feed that is used as feed and as well as ESA whitelist or blacklist)
Non-IP type, map Column 5 to cert.checksum and column 6 to IOC (as if we have a match this is pretty confidant that this traffic is bad)
And now you have an updated feed that will alert you to certificate usage that matches known lists of badness.
an example output looks like this (always ends <space>c&c in IOC key)
(the client value is from another science project related to JA3 signatures ... in this case double confirmation of gootkit)
the testing data that was used to play with this came from here
Malware-Traffic-Analysis.net - 2018-09-05 - Emotet infection with IcedID banking Trojan and AZORult
Great resource and challenges if you are looking for some live fire exercises.
To wrap this up an ESA rule can be created with the following criteria to identify these communications and create an Alert
/*
Module debug section. If this is empty then debugging is off.
*/
@Name("outbound_blacklisted_ssl_cert: {ioc}")
@Description('cert.checksum + ssl abuse blacklist all have ioc ends with <space>c&c')
@RSA
SELECT * FROM Event(
/* Statement: outound_ssl_crypto_cnc */
(
direction.toLowerCase() IN ( 'outbound' ) AND
service IN ( 443 ) AND
ioc IS NOT NULL AND
matchLike(ioc,'% C&C' )
/*isOneOfIgnoreCase(ioc,{ '%c&c' })*/
)
) ;The reason advanced mode was needed was that the IOC metakey needed to be wildcarded to look for any match of <name><space>C&C and I didnt want to enumerate all the potential names from the feed (the UI doesnt provide a means to do this in the basic rule builder for arrays - of which IOC is string[]).
Another thing to notice is that the @Name syntax creates a parameterized name that is only available in the alert details of the raw alert.
I was hoping to do more with that data but so far not having much luck.
You can also wrap this into a Respond alert to make sure you group all potential communications together for a system and these alerts (grouping by source IP)
If everything works correctly then you get Resond alerts like this that you should investigate
4 Comments
