Detecting Malicious SSL Certificates Using Bro

Editor's Notes

• #2: Hello folks,  My name is Ajit Thyagarajan and this is my colleague, Andrew Beard.  We are both from Atomic Mole, a small startup developing a security solution for the mid-market.  Before we dive into the guts of this presentation, I thought it would be worthwhile to tell you how we got interested in this work. 
• #3:  The statistics are out there.  SSL traffic is on the increase (courtesy Dell).   Expected growth is 20% each year and not surprisingly only a very small percentage of this traffic is analyzed.  According to Dell, there was a sharp increase in SSL/TLS encryption through 2015. In the fourth quarter of 2015 nearly 65 percent of all web connections that Dell observed were encrypted, leading to a lot more under-the-radar attacks, according to the company. Gartner has predicted that 50 percent of all network attacks will take advantage of SSL/TLS by 2017.
• #4: Another interesting statistic is that it is becoming harder and harder to inspect SSL traffic content.  First you need a man-in-the-middle device and then you have to figure out how to manage certificates.  In addition, Certificate pinning and use of complex ciphers make decryption of content even more challenging. A lot of organizations also just do not decrypt SSL traffic due to legal concerns and infringement of privacy for users .  [Ref: https://securityevaluators.com/knowledge/case_studies/mutual/]  So, all of this points to a need for new innovative ways to analyze SSL traffic for maliciousness without decrypting the content by looking for other clues. 
• #5: So, Andrew and I both attended BSides Baltimore and there was a talk there about detecting anomalies in x.509 certs using bro.  Since our security solution uses Bro for network traffic analysis, we figured that it would be a great feature to explore.  So, we listen and it turns out that the main hypothesis of that talk was around the certificate creation time.  The author had hypothesized that if the certificate creation time was some random value like 10am, then there was a high probability of it being malicious mainly because most of the good certs apparently had the creation time as midnight.  Well, that didn't make any sense to us and we decided to really look into this further.  Turns out that the default value for creation time (its an optional field during cert creation) is 0, so thats why a lot of the values were showing up as 12:00am.  That validated our theory that the creation time probably didn't have much to do with the maliciousness of a cert. But we left with a burning question - so what attributes could potentially indicate maliciousness (if any) and we thought that there were definitely some attributes that were more likely than not which might be indicative of maliciousness.  We also had to sort of think like a hacker and try and see how and what they might do to get certs as compared to a legitimate organization.  In the BSides talk, the author had used 2K good certs and a "handful" of bad certs.  Not sure if this was a good training set in the first place.  So, we decided to go all out with much higher fidelity .  We needed a setup that would pull a very large number of good and bad certs and analyze the heck out of them.  One thing I did want to point out is that when our abstract was accepted, we got some great feedback from the reviewers (kudos to them - wish more conferences gave that kind of feedback).  They mentioned that since this was a Bro conference, it would be beneficial to focus more on the Bro aspect of things, so thats  what we did.   
• #6: Talk a little bit about certificate feeds, as these become very important to information gathering process as you’ll see in a moment Mostly commodity C2 servers, Dridex, Dyre, TorrentLocker, etc 10/week excludes Dyre High efficacy -> Ground truth
• #7: Pain on adversary by denying them access to X Not just for self-signed certs anymore. Mention the rise of Let’s Encrypt and other no-cost ways of getting legit certificates. As a network defender, I want to cause pain. How do we cause pain? Identify adversary's process and tools Make them identify and change things that take time and effort
• #8: We can do better, enriching feed data and processing results Not just cert feeds, but they’re my confirmed bads What do I mean by resulting from? Refer to next side
• #9: Could have scripted something with curl, openssl, and a lot of parsing Combine Bro for research and monitoring after the fact Talk about feedback loop, bro -> pattern generating process -> back into bro
• #10: Tours of my datacenter usually begin with someone asking “What’s making that noise?”
• #11: All x509 certificates end up in files table with sha1s By isn’t totally trustworthy, I mean we don’t for use it’s malicious. Things move, takedown pages, etc
• #13: Response rate on the order of most telemarketers This is a funnel, start wide, end up with few final results. Match rate is biased because our feeds include other Abuse.ch feeds, so there’s a better chance than looking at other sources
• #14: Mention Bsides Charm talk concentrated on not_valid_after and not_valid_before Not scalar, categorical
• #15: Ran into problems with initial analysis, not a lot of commonality. There is structure here. Separate attributes with key and value pairs
• #16: Yes, we’ll make it a package
• #17: ALL optional
• #19: Last point, feeds change. I’ve already processed the data, tell me given what I know know about the things that happened then
• #20: Look at data -> common elements. Values that recur. Every single attribute you have, sort by count Start with a bad record, spider out of other similar records Next steps -> automation. Still working on getting good results there. Known good, baseline set of traffic you trust. With a lot number of results it’s always the possibility that your “known good” traffic isn’t that good, so review to be sure.
• #22: The email address part didn’t make a lot of sense until we tried generating a certificate with the openssl command
• #23: Alex Kirk blog post talking about Snort signature, Talos Netresec, post on https reverse tunnel Note about the email address going off the end of the command. Probably not an automated system. Also saw results for Default Company Ltd, some versions of openssl use this by default instead
• #24: These aren’t malicious, but there’s a higher proibability of something bad going on
• #27: Not all patterns are in the values themselves, some are in the form Difficult to do via automated analysis Entropy calculation on text would probably show very high value
• #28: What’s the best way to do these? Not really part of intel framework as I understand it.
• #29: Longer shelf life. Issuing new certs part of brining up new domains, but if the patterns don’t change puts you a step ahead.
• #30: Try to piece together why. Easy to create patterns that are coincidental.
• #32: Special thanks to Ravi Pandey, one of our summer interns from UMD, who spent a fair bit of time with the certificates applying trying various ML algorithms on multiple versions of our dataset.