Identifying antivirus and content checking mechanisms

NDN messages might also contain headers generated by content filtering mechanisms (either distinct hardware appliances or software running on a mail server). Example 9-4 demonstrates the headers added by a Barracuda Networks content filter at barracuda.noa.nintendo.com.

X-Barracuda-Connect: gateway07.websitewelcome.com[70.85.67.23]
X-Barracuda-Start-Time: 1411818632
X-Barracuda-Encrypted: AES256-SHA
X-Barracuda-URL: http://barracuda.noa.nintendo.com:80/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at noa.nintendo.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVE= L=2.0 
QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.9943

Through sending messages with different contents, you can use responses to reverse engineer content filtering policy and antivirus configuration. For example, you can force identification and alerting of malicious content by sending an EICAR test file² within an email.

Table 9-2 lists antivirus engines revealed upon parsing the EICAR test file, based on NDN headers received. Jon Oberheide and Farnam Jahanian published research that expands on this tactic.³

X-Proofpoint-Virus-Version: vendor=fsecure 
engine=2.50.10432:5.11.87,1.0.14,0.0.0000 
definitions=2013-12-12_01:2013-12-11,2013-12-12,1970-01-01, 
signatures=0

X-Proofpoint-Virus-Version: vendor=nai engine=5400
definitions=5800 signatures=585085

X-IronPort-AV: E=Sophos;i="4.27,718,1204520400";
v="EICAR-AV-Test'3'rd"; d="txt'?com'?scan'208";a="929062"

X-IronPort-AV: E=McAfee;i="5400,1158,7286"; a="160098426"

X-TM-AS-Product-Ver: CSC-0-5.5.1026-15998
X-TM-AS-Result: No-10.22-4.50-31-1

The WebShield(R) e500 Appliance discovered a virus in this file. 
The file was not cleaned and has been removed.

X-Barracuda-Virus-Scanned: by Barracuda Spam &
Virus Firewall at example.org

Known antivirus engine defects

Upon identifying the deployed antivirus engine you can exploit defects by sending malicious content via SMTP. Remotely exploitable flaws have been found in ClamAV, ESET, Kaspersky, Sophos, and Symantec engines in particular, as listed in Table 9-3. Unfortunately, an increasing number of these issues do not have CVE references.

EXPN

The EXPN command expands details for a given mail address, as shown in Example 9-6. Through analyzing the server responses, we find the test user account doesn’t exist, mail for root is forwarded to chris@example.org, and an sshd account exists for privilege separation purposes.

root@kali:~# telnet 10.0.10.11 25
Trying 10.0.10.11...
Connected to 10.0.10.11.
Escape character is '^]'.
220 mail2 ESMTP Sendmail 8.13.8/8.12.8; Thu, 13 Nov 2014 03:20:37
HELO world
250 mail2 Hello onyx [192.168.10.1] (may be forged), pleased to meet you
EXPN test
550 5.1.1 test... User unknown
EXPN root
250 2.1.5 <chris@example.org>
EXPN sshd
250 2.1.5 sshd privsep <sshd@mail2>

VRFY

The VRFY command verifies that a given SMTP mail address is valid, as shown in Example 9-7. We can abuse this feature to enumerate local accounts (chris in this case).

root@kali:~# telnet 10.0.10.11 25
Trying 10.0.10.11...
Connected to 10.0.10.11.
Escape character is '^]'.
220 mail2 ESMTP Sendmail 8.13.8/8.12.8; Thu, 13 Nov 2014 04:01:18
HELO world
250 mail2 Hello onyx [192.168.10.1] (may be forged), pleased to meet you
VRFY test
550 5.1.1 test... User unknown
VRFY chris
250 2.1.5 Chris McNab <chris@mail2>

RCPT TO

Many administrators ensure that EXPN and VRFY commands don’t return user information; however, RCPT TO enumeration exploits a flaw that is not easily mitigated within Sendmail in particular. Example 9-8 demonstrates the command used to identify valid local users accounts.

root@kali:~# telnet 10.0.10.11 25
Trying 10.0.10.11...
Connected to 10.0.10.11.
Escape character is '^]'.
220 mail2 ESMTP Sendmail 8.13.8/8.12.8; Thu, 13 Nov 2014 04:03:52
HELO world
250 mail2 Hello onyx [192.168.10.1] (may be forged), pleased to meet you
MAIL FROM:test@test.org
250 2.1.0 test@test.org... Sender ok
RCPT TO:test
550 5.1.1 test... User unknown
RCPT TO:admin
550 5.1.1 admin... User unknown
RCPT TO:chris
250 2.1.5 chris... Recipient ok

SPF

Sender Policy Framework (SPF)⁸ provides a mechanism by which MTAs can check if the host sending email for a given domain is authorized. Organizations define the list of authorized mail servers for a domain within a specially formatted TXT DNS record.

We can evaluate the SPF configuration of Google via dig, as shown in Example 9-12. Large organizations often use include and redirect directives, and you must iteratively step through each record to understand the configuration. In this example, the IPv6 and IPv4 ranges returned are authorized sources.

root@kali:~# dig google.com txt | grep spf
google.com.        1599 IN   TXT  "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 
ip4:216.73.93.72/31 ~all"
root@kali:~# dig _spf.google.com txt | grep spf
_spf.google.com.   246  IN   TXT  "v=spf1 include:_netblocks.google.com include:
_netblocks2.google.com include:_netblocks3.google.com ~all"
root@kali:~# dig _netblocks.google.com txt | grep spf
_netblocks.google.com.  2616 IN   TXT   "v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 
ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 
ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ~all"
root@kali:~# dig _netblocks2.google.com txt | grep spf
_netblocks2.google.com. 3565 IN   TXT   "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 
ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 
~all"
root@kali:~# dig _netblocks3.google.com txt | grep spf
_netblocks3.google.com. 3196 IN   TXT   "v=spf1 ~all"

DKIM

DomainKeys Identified Mail (DKIM)⁹ is a mechanism by which outbound email is signed and validated by foreign MTAs upon retrieving a domain’s public key via DNS. The DKIM public key is held within a TXT record for a domain; however, you must know both the selector and domain name to retrieve it.

Upon reviewing the headers of email via gmail.com, the DKIM signature is retrieved:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;d=gmail.com;s=20120113; h=mime-version:x-
received:date:message-id:subject:from:to:content-type; bh=fd9JXP6Ngw+hgcG1EbBo7GpsrIIZzdJb9Q/14o
9e5C8=; b=sYlJC2oYWzBUOPIo0jtR4iFsIVqUlwo2QRcG1186hg5ai0oO1nisiOJUD+QXjt

The d and s values are combined and fed into dig, as shown in Example 9-13.

root@kali:~# dig 20120113._domainkey.gmail.com TXT | grep p=
20120113._domainkey.gmail.com. 280 IN   TXT    "k=rsa\; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg
KCAQEA1Kd87/UeJjenpabgbFwh+eBCsSTrqmwIYYvywlbhbqoo2DymndFkbjOVIPIldNs/m40KF+yzMn1skyoxcTUGCQs8g3
FgD2Ap3ZB5DekAo5wMmk4wimDO+U8QzI3SD0" "7y2+07wlNWwIt8svnxgdxGkVbbhzY8i+RQ9DpSVpPbF7ykQxtKXkv/ahW
3KjViiAH+ghvvIhkx4xYSIc9oSwVmAl5OctMEeWUwg8Istjqz8BZeTWbf41fbNhte7Y+YqZOwq1Sd0DbvYAD9NOZK9vlfuac
0598HY+vtSBczUiKERHv1yRbcaQtZFh5wtiRrN04BLUTD21MycBX5jYchHjPY/wIDAQAB"

DMARC

Domain-based Message Authentication, Reporting & Conformance (DMARC)¹⁰ is a method of mail authentication that expands upon SPF and DKIM. Policies instruct mail servers how to process email for a given domain and report upon actions performed. The way in which DMARC is used along with SPF and DKIM is shown in Figure 9-3.

Figure 9-3. DMARC, SPF, and DKIM

DMARC policies are distributed via DNS. Table 9-11 lists fields and example values, and Example 9-14 demonstrates the policies used by Google, Yahoo, and PayPal.

root@kali:~# dig _dmarc.yahoo.com txt | grep DMARC
_dmarc.yahoo.com.  1785 IN TXT "v=DMARC1\; p=reject\; sp=none\; pct=100\; 
rua=mailto:dmarc-yahoo-rua@yahoo-inc.com, mailto:dmarc_y_rua@yahoo.com\;"
root@kali:~# dig _dmarc.google.com txt | grep DMARC
_dmarc.google.com. 600 IN TXT "v=DMARC1\; p=quarantine\; rua=mailto:mailauth-reports@google.com"
root@kali:~# dig _dmarc.paypal.com txt | grep DMARC
_dmarc.paypal.com. 300 IN TXT "v=DMARC1\; p=reject\; rua=mailto:d@rua.agari.com\; 
ruf=mailto:dk@bounce.paypal.com,mailto:d@ruf.agari.com"

PayPal and Yahoo instruct mail servers to reject messages that contain invalid DKIM signatures or do not originate from their networks. Notifications are then sent to the respective email addresses within each organization. Google is configured in a similar way, although it instructs mail servers to quarantine messages and not outright reject them.

Reconnaissance

Effective campaigns fool safety-conscious users by using knowledge of the target environment. Important details to focus on are as follows:

• Address format and naming convention (e.g., Smith, Stan <stan.smith@intel.com>)

• Client software used within the organization (e.g., Microsoft Outlook)

• Message details or quirks, including signature formats adopted by certain users

• Identifying a candidate web interface to clone

You can cover the first three bullets in the preceding list by obtaining material originating from the organization (e.g., email containing headers and HTML content). Mailing list archives and Google are good candidates, along with user coercion by requesting information from marketing or sales departments.

If an organization uses multifactor authentication for remote access purposes, you can subvert this by cloning the SSL VPN web endpoint to capture credentials and immediately replaying them to legitimate services.

Landing page preparation

You can use SET to clone a login page and harvest credentials. To get the best results, I would recommend going an extra step by registering a domain for use during the campaign, obtaining a valid TLS certificate, and using stunnel to broker the HTTPS traffic between the victim and SET.

For example, if the cloned web endpoint is vpn.victim.com, consider acquiring victim-corp.com, setting up the DNS so that sslvpn.victim-corp.com points to your SET instance, and purchasing the associated certificate so that the user sees a legitimate-looking encrypted connection.

SET is a powerful utility with rich functionality. You can use it to both harvest credentials (via traditional phishing attack) and exploit vulnerable browser plug-ins and components to gain code execution.¹²

Sending email

The Spearphishing module within SET uses the Sendmail MTA in Kali Linux to send email. For the best result, however, consider manually crafting an email message from the previously obtained materials (using the same font and message format as a legitimate email), piping this material via Swaks to your local Sendmail service, and onto the target SMTP server.

It is important to evaluate the security posture of the target before proceeding. Review SPF, DKIM, and DMARC policies (if any), and assess the behavior of exposed SMTP interfaces to see whether they will accept material from an internal domain. If the environment is hardened, you will need to set up a domain from which to send email (victim-corp.com, for example).

Figure 9-4 demonstrates an effective HTML email spoofed from the IT department of a company. The look and feel of the email is critical, and the language is important because you want to dictate a sense of urgency for users to click the malicious link.

Figure 9-4. HTML phishing email content

Factors that can affect the success of a phishing campaign include:

• SMTP interfaces not accepting email from the public Internet that is sent from a domain that is internal to the organization

• Use of content filtering to add material to the subject line of email originating from outside of the organization (e.g., an external or untrusted designator)

• Presence of web proxy appliances evaluating the reputation of destination URLs

• Use of particular browsers or desktop software clients

Eric Smith’s 2013 DerbyCon presentation¹³ chronicles a number of successful professional social engineering campaigns, detailing tactics used to do the following:

• Ensure that URLs used within a campaign are marked as reputable online

• Ensure that the mail server used to launch a campaign also seems reputable

• Measure the efficacy of a campaign by tracking session identifiers

• Take advantage of privileged access (via OWA or VPN) to gain intelligence

• Preoccupy and distract incident response teams

Through reconnaissance, proper staging (provisioning of domains, certificates, and reputable web and mail server addresses), and focused execution, you will likely succeed through phishing. By preparing a number of redundant attack platforms and distracting the security team of the target, you should also be able to achieve persistence.