{Quick Post} Mail headers

I know this topic has been discussed in various venues under the flag of OSINT, but I came across a nice example that I thought was worth sharing… even if just to re-iterate the point!

Following an email to a unnamed company, threw up a couple of interesting facts that companies should really be aware of. Information disclosure is always present, but email headers and failure notices are a goldmine of information if you take the time to dig into them.

Note: nothing I’m posting here is private or restricted. Anybody sending an email to the public relations email address will receive the same information. Don’t shoot the messenger!

Taking some of the more interesting points from the above message, you can extract the obvious information such as internal IP range and the version of Exchange Server in use (14.2.298.4) from the first few lines of the error (lines 10-11).

Digging a little deeper however you can also extract some interesting information about the security in and around the email system (lines 32-35). This includes details on the use of TLS for email transfer (ESMTP/TLS/RC4-SHA), and a hint to the cipher (dependant on the support ciphers on the sender-side). What’s also interesting is the “Received-SPF” and “DKIM-Signature” (lines 13 and 36). In the case of SPF the remote mailserver is actively checking the SPF record and is performing a reverse lookup to check that the sending host is permitted to send email on behalf of the sending domain (c22.cc). In this case everything is fine, but it’s important to know if you’re performing an authorised pentest… especially if you’re phishing 😉

The last little bit of information you can squeeze out is the exposed “X-IronPort-Anti-Spam” and “X-SBRS” headers (lines 27-31). From this you can gather that the remote server is running IronPort and the email you sent scored a 4.4 on the IronPort’s anti-spam rating. Again, this is good for those tests where you’re phishing and need to see what score your emails are getting. Simply sending your prepared email to a non-existent (or in this case, failing) email address should net you some feedback on how good your phishing email is perceived by the IronPort.

The “X-SenderGroup” and “X-MailFlowPolicy” headers (lines 28 and 29) are also added in by the Cisco IronPort, so might be a source of interest!

My suggestion to companies is to check the data that your mailservers are exposing through failure notifications… even if you can’t stop this data from leaving your network via configuration tweaks, it’s at least good to know what information you’re providing to attackers!

Links

Disclaimer

The contents of this personal blog are solely my own opinions and comments, as such they do not reflect the opinions of my employer(s) past, present or future. No legal liability is accepted for anything you do, think, or consider fact as the basis of articles and links posted on this blog.

"Three to one...two...one...probability factor of one to one...we have normality, I repeat we have normality. Anything you still can’t cope with is therefore your own problem."

Note: A large portion of content I post on my blog comes from "live blogging" of security conferences. These posts are in notes form and are written live during a talk. As such errors and emissions are expected. I'm only human after all!