[Bro] Question about data format of ssl.log files
jessebowling at gmail.com
Wed Feb 20 13:03:21 PST 2013
Thank you Alex; this was the conclusion I came to as well...I was hoping I
missed something in my ignorance of certs...
Now, to harass everyone I can find associated with Mandiant in the hopes of
getting those md5's... :)
On Wed, Feb 20, 2013 at 3:57 PM, Alex Waher <alexwis at gmail.com> wrote:
> The most consistent/least-false-positive/sustainable way would be to use
> the public certificate's fingerprint, which bro calculates into an md5 and
> logs within ssl.log as 'cert_hash'. Unfortunately Mandiant's report does
> give us the cert hashes-- there might be intelligence communities out there
> that will soon release an appendix supplement with these fingerprints.
> Bro is not by default logging the cert serial number (btw, serial is
> controlled by whom issues the cert), so you'll have to dig through the
> issuer and subject strings to find a match based on the info in the APT1
> On Wed, Feb 20, 2013 at 12:18 PM, Mike Sconzo <sconzo at visiblerisk.com>wrote:
>> There are a couple different things you can look for.
>> The serial number works pretty well in a lot of cases (I use this 99%
>> of the time w/o issue). The subject and issuer are useful for finding
>> odd SSL certs to begin with. A lof of their subjects and issuers are
>> pretty trash looking. If you were really paranoid you could combine
>> the 2 for a more accurate match. I'd also say having a 5 year validity
>> isn't too normal, but I don't have any hard data to back this up (just
>> from what I remember from doing analysis). Not to mention when subject
>> = issuer is also a give away for self signed, and while not
>> immediately malicious it tends to raise my eyebrow (for example, a
>> self signed mail.aol.com or mail.yahoo.com cert?). For the default bro
>> logs I'd look at servername, subject, not valid before and not valid
>> after; that should give you a reasonable starting place.
>> As an aside this might be one of my favorites:
>> C=US, ST=Washington, L=Anytown, O=ACLU, OU=A@@hole,
>> CN=NoName/emailAddress=iamnot at home.com
>> Just by looking at subjects and/or issuers that should stand out
>> because that is not normal for legit network traffic. Sorry for the
>> tangent, but personally I'd be less worried about the specifics in the
>> report and more about the chances that it's something not in this
>> report on your network <FUD alert! :) >
>> On Wed, Feb 20, 2013 at 1:11 PM, Jesse Bowling <jessebowling at gmail.com>
>> > Hi,
>> > So quite a few infosec folks are looking at Mandiant's APT1 report,
>> > included...When I saw that they included some information on SSL certs
>> > use I thought "Oh, I'll bet I can check my Bro logs for that!".
>> > Unfortunately, I don't see a way to correlate the info from these
>> > with my Bro logs (which is pretty vanilla).
>> > So I suppose my question(s) is/are:
>> > *Has anyone else seen a reliable way to correlate the report data with
>> > logs?
>> > *How might I change my Bro logs so that if I were given this info in the
>> > future I could reliably correlate it?
>> > I'm fairly ignorant about how much of an X509 cert one can see on the
>> > serial number seemed promising but is only "required" to be unique per
>> > Signature Algorithm seems promising, as does Public Key Modulus...
>> > Any suggestions/thoughts from the group?
>> > Cheers,
>> > Jesse
>> > http://intelreport.mandiant.com/
>> > http://intelreport.mandiant.com/Mandiant_APT1_Report.pdf
>> > http://intelreport.mandiant.com/Mandiant_APT1_Report_Appendix.zip
>> > --
>> > Jesse Bowling
>> > _______________________________________________
>> > Bro mailing list
>> > bro at bro-ids.org
>> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>> cat ~/.bash_history > documentation.txt
>> Bro mailing list
>> bro at bro-ids.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bro