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!
Diagnostic information for administrators:
Generating server: democorp.CORP
group@democorp.com
#550 5.7.1 RESOLVER.RST.AuthRequired; authentication required ##
Original message headers:
Received: from mx4.dfw1.democorp.com (10.7.9.76) by smtpout.democorp.com
(10.12.120.25) with Microsoft SMTP Server id 14.2.298.4; Mon, 9 Jul 2012
09:14:34 -0500
Received-SPF: Pass (mx4.dfw1.democorp.com: domain of
xyz@c22.cc designates 209.85.214.180 as permitted
sender) identity=mailfrom; client-ip=209.85.214.180;
receiver=mx4.dfw1.democorp.com;
envelope-from="xyz@c22.cc";
x-sender="xyz@c22.cc"; x-conformance=spf_only;
x-record-type="v=spf1"
Received-SPF: None (mx4.dfw1.democorp.com: no sender
authenticity information available from domain of
postmaster@mail-ob0-f180.google.com) identity=helo;
client-ip=209.85.214.180; receiver=mx4.dfw1.democorp.com;
envelope-from="xyz@c22.cc";
x-sender="postmaster@mail-ob0-f180.google.com";
x-conformance=spf_only
X-SBRS: 4.4
X-SenderGroup: None
X-MailFlowPolicy: $ACCEPTED
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtkBAHvm+k/RVda0kGdsb2JhbABCA4JKpEeHVgGIfAgiAQEBAQkJDQcUBCOCIAEBAQEDEgIsAQE4DxYGAwECLyISAQUBEgIIBw4ECBqFb4F8C45NjioJA4pmhC4BBY5kBotAgmuDIYspihCBEoUwhESDIj6EAIFd
Received: from mail-ob0-f180.google.com ([209.85.214.180]) by
mx4.dfw1.democorp.com with ESMTP/TLS/RC4-SHA; 09 Jul 2012 09:14:33 -0500
Received: by mail-ob0-f180.google.com with SMTP id uo19so20894072obb.11
for <group@democorp.com>; Mon, 09 Jul 2012 07:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=c22.cc; s=c22;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-type;
bh=UTOmJBpa86TfxGjU5tQXis28YV6Sw/gTVT6wUE6UMws=;
b=eSSc9Wsxr4Tn1WRIl6iQX8C67WGREgXDr1/U8r4vSfUTMRxXbyH4pYYdGR08yt8RQi
iC1AkTr1hNqvBUJ4mt5ELhfW8NPwfRD9W2DShyFS2engogMPg6EKt6DuWuCy0hLRJOzN
hmPSk/1VTuegKJa8nIAwTW5I/hCL8EkJKtn1M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-type:x-gm-message-state;
bh=UTOmJBpa86TfxGjU5tQXis28YV6Sw/gTVT6wUE6UMws=;
b=X+t+5o5x/V/kpc1b2fMKr31W1wj5jLnkEfhwjLVEqLrLMczv2WjyI0VCDXDmBLJQ7R
DvDRMRnB+Hwk/xhDwOcogOvHucrXk3wCrgAGZqnFbKgqjcoR99OnRIaSgFmYeHE1lNmN
twOHoamsRoBmeh8xtuCzt24WdcBiSrw9VzugUu2xJ+3/9kWrJijqk0I4VaFDrNIeu6TH
DmGIEtZojB0MLLZC/a4x2Bg7AhnKElP0AQTnOihXw+CuoJcbI1GzIdCkB3mBHtnvPW9Z
GmtqoKjvwvxaYOlOPkM3zKilOJ4oc8QywG89sFDT7+zs3zaL53JPlmJGpzV3rBjmOY4J
eQ9g==
Received: by 10.182.216.99 with SMTP id op3mr15297272obc.30.1341843273175;
Mon, 09 Jul 2012 07:14:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.209.3 with HTTP; Mon, 9 Jul 2012 07:14:12 -0700 (PDT)
In-Reply-To:
References: <CAOXycj0yy-qAmWUz6PpqjAVX=XOV3=eEJN3VU=iQsZfj_zDH0g@mail.gmail.com>
From: Chris John Riley <xyz@c22.cc>
Date: Mon, 9 Jul 2012 16:14:12 +0200
Message-ID: <CAOXycj2BvTr19Raa-qt4KbBo0QigNATR20VH9fwpKL3oJwQxdA@mail.gmail.com>
Subject: subject
To: <group@democorp.com>
Content-Type: multipart/alternative; boundary="f46d044786e7a4540a04c4663b39"
X-Gm-Message-State: ALoCoQkSGcaZiYEGGYIMbwVNAM5LTm/F/gFzBwRRIeWWGriOQ48yR0cwLsmbBD6aFt5YFVyrA+
Return-Path: xyz@c22.cc
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!
Cатсн²² (in)sесuяitу / ChrisJohnRiley 