G53SEC Coursework

April 6, 2011

Part I
Spam Detection and Categorisation
1 Approach
For analyzing each email I used a standard text editor, a small perl script I wrote for decoding
the base64 encoded images, and the wealth of information provided by SpamAssassin. I followed
a process of first analyzing the email headers to look for signs of how legitimate the sending host
may be, and then using the body of the message and SpamAssassin scores to deduce what the
email should be classified as.

2 Categorisation & Classification

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Solicited • • • • •
Phishing • • • • •
Scam • • •
Spam • • • •

3 Emails
Emails 1-3
Date: Thu, 28 Apr 2005 09:40:30 +0200
From: Abbey <support num 2@abbey.com>
To: mvr@Cs.Nott.AC.UK
Subject: Important Information From Abbey National plc BiIIing Department

Emails one to three are classified as phishing emails, designed to steal the banking credentials
of the recipient by tricking the user into following a link to the attackers site, and then having
the user enter their own banking details for the attacker to capture. By just analyzing the basic
information presented above we can identify multiple suspect characteristics of these emails.

1
Firstly, the From email address appears to come from the abbey.com domain, however the user
account contains underscores and numbers. In the context of unsolicited email detection, this
is often considered a trait of spammers and certainly not a trait of legitimate banking emails.
Secondly, a keen eye will notice that the word Billing in the Subject line has been spelt using
two I’s rather than two l’s. This technique is one of many used by bulk emailers to evade spam
filtering by removing trigger words from the email.
Inspection of the email body reveals a multi-part MIME message comprising of two lines of
HTML code and a base64 encoded GIF image (see Figures 1, 2 and 3). Bulk emailers commonly
use HTML emails with images to evade detection by anti-spam filters that match on keywords.
The images themselves state that the customers bank has been experiencing technical prob-
lems, and that their data must be confirmed in order for their banking service to continue as
expected. Below this poorly written paragraph is a legit url to the banking website. However,
on its own, clicking on any part of this image will serve no purpose.
If the HTML part of the email is rendered, an area is created inside the image, that when
clicked, serves as a hyperlink. This area overlays the area of the legitimate looking url in the
image, so that when the recipient clicks on what they think is a url to their bank, they are
in-fact clicking on the area link to the attacker’s phishing website. Also, as an extra measure of
convincing the user of the link’s legitimacy, the area is filled with text that links to the legitimate
site. So that on mouseover, the legitimate link is shown.
Finally, numerous SpamAssassin tests have concluded that the sending IP addresses are on
multiple blacklists.

Figure 1: Abbey National

Figure 2: Halifax Figure 3: Natwest

2
Email four
Date: Tue, 05 Jul 2005 14:21:33 -0500
From: Account Manager <Amanda Mims@fastmail.co.uk>
To: bruce.campbell@nottingham.ac.uk
Subject: Mailing Address Invalid

The From email addresses domain fastmail.co.uk is indicative of a free email hosting ac-
count. Whilst the body of the email claims to be coming from an account manager of a property
financing company, it is unlikely that this is being sent from a legitimate business. On top of
that we can see that the email body claims to come from Thomas Wright(Account Manager),
yet the From address states the email is from an Amanda Mims(Account Manager).
The University of Nottingham’s mail scanner has picked up that the sending mail server’s
IP address is listed on Trend Micro’s MAPS-RBL+ blacklisting database. Clearly, this email
is both unsolicited and ill-natured, and by deducing that no legitimate business exists, I have
classified this email as a scam rather than spam.

Email five
Date: Mon, 1 May 2006 20:00:22 +0200
From: PayPal <service@paypal.com>
To: None
Subject: Renew your account, Official notification from Paypal.com !

To an unaware recipient, this PayPal phishing email looks no different to any other email
from PayPal. The spoofed From address, carbon copy of a legitimate PayPal email and the full
domain in the link provide a good case for email five being a legitimate email.
Two anomalies that a keen eye will not miss are the lack of a To address and the suspect link:

http://0xd35abf59/kfq/%20/www.paypal.com/personal/accounts/pp/us/index.htm

Although the link text displays a PayPal URL, the HTML anchor tag actually points to
0xd35abf59, which is a hex representation of the IP address 211.90.191.89 (the attacker’s
phishing host).
Despite this obviously being a phishing email, SpamAssassin has mostly filtered the email on
the basis of the sending host forging itself as an Outlook client.

Email six
Date: Sun, 19 Feb 2006 16:34:18 -0500
From: Adam <adamft@verizon.net>
To: mrl@nottingham.ac.uk
Subject: Online Canadian Pharmacy

Email six makes no attempts to hide what it is selling (Pharmaceuticals), or evading being
caught by a spam filter. With a straight to the point subject and body, this email is likely
being sent in huge volumes and hoping to hit recipients without spam filters or those who browse
their junk/spam folders. SpamAssasin picks up that this email’s checksum is located within the
Distributed Checksum Clearinghouse (DCC), as well as the sending IP address being listed in
multiple blacklists.

3
Email seven
Date: Sat, 29 Oct 2005 00:35:00 -0500
From: walton fitch <cacue@efilipino.org>
To: joan jasper <mrl@nottingham.ac.uk>
Subject: Our wattcch internet sshop allows anyone to obtain a rich novelty.

Unlike the previous email, email seven takes measures to evade spam-filters to inbox its
advertisement. As seen previously, the email body text is full of spelling errors to avoid using
spam keywords.
However, the bottom paragraph of the email is completely unrelated to advertising watches
and has no spelling errors. This is a technique known as Bayesian poisoning. It works by filling
the email with text that is unlikely to be seen in spam emails, and as a result it can evade
bayesian spam filtering. This relies on bayesian probabilities to detect whether an email is spam
based on the words used in the email.

Email eight
Date: Wed, 01 Mar 2006 12:43:12 +0100
From: ”DR.ROBERT SANCHEZ” <euspainshlottery@netscape.net>
To: None
Subject: CONGRATULATION!!! YOU HAVE WON

Dr. Sanchez’s lottery scam, much like email six, has a high disregard for spam filtering, and
focuses on capturing the recipients attention by deceiving them into thinking they have won the
lottery. Typically, a scam of this nature will attempt to part the recipient with their money by
tricking them into sending a comparatively small amount of money to release their final prize
(known as Advance Fee Fraud).
The email message is included on both the DCC checksum blacklist and SpamHaus’ Exploits
Block List (XBL).

Email nine
Date: Thu, 29 Dec 2005 23:12:25 +0400
From: ”FROM MR.AHMED HASSAN.” <mrahmed 101hassan@yahoo.co.in>
To: None
Subject: FROM MR.AHMED HASSAN.

Similar to the previous email, the body of this email attempts to trick the recipient with
Advance Fee Fraud into parting with their money. This particular scam is reminiscent of the
well known 419 Nigerian scam and its heavy use of capital letters and features of a confidence
trick have been picked up by SpamAssassin as well as being identified on blacklists.

Email ten
Date: Thu, 24 Nov 2005 14:49:15 +0400
From: Eric Fabian <toenini@imaginatekwiggins3.eg>
To: Moya.Mason@nottingham.ac.uk
Subject: Using our webpage builder is not easy! IT’S DEAD EASY?

4
 Email ten’s body is suggestive of typical advertising spam. From what can be seen, it appears
that the email is promoting a product for web page creation. The legitimacy, or even existence
of that product is not known with an outdated URL.
The email headers show that the sending email server used a forged HELO command:

Received: from [222.133.170.167] (helo=128.243.40.90)

Email eleven
Date: Thu, 12 Jun 2008 12:35:23 +0100 (IST)
From: ”Content-filter at EMANUELE.IRELAND.iotals.com” <virusalert@iotals.com>
To: undisclosed-recipients: ;
Subject: VIRUS (HTML.Phishing.Bank-1269) IN MAIL TO YOU

Unique to this set of emails, email eleven is neither specifically solicited or unsolicited, but
an alert of an attempted infection. The nature of the original email was to steal banking cre-
dentials as indicated by the virus alerts signature, HTML.Phishing.Bank-1269. We can consider
this to be an accurate prediction of the virus’ intent because the From address was forged as
costumer.message@natwest.com.

Email twelve
Date: Fri, 11 Jul 2008 12:00:09 -0700
From: manet-request@ietf.org
To: manet@ietf.org
Subject: manet Digest, Vol 51, Issue 6

Solicited mailing list digest

Email thirteen
Date: Sat, 16 Aug 2008 05:45:43 -0700
From: Lindsy Idalia <l.idalia kq@eunet.no>
To: maggie.cooper@nottingham.ac.uk
Subject: No Class, No Exam, BUY Yourself World Recognized University Degree/Dip1oma/Bacheloor/Maaster
for you zpmkbq 1t

Email thirteen is an example of a targetted spam advertising campaign. This can be deduced
from the nature of the advertising, selling education, and the multiple BCC targets, all of which
are University of Nottingham email addresses. As witnessed in previous emails, the subject
contains spelling errors to avoid spam keywords.

Email fourteen
Date: Sun, 7 Sep 2008 17:28:05 +0100
From: Research <Research@psut.edu.jo>
To: IMCL List <Research@psut.edu.jo>
Subject: IMCL2009 Second Call for Papers

Solicited conference call for papers

5
Email fifteen
Date: Wed, 15 Jul 2009 21:44:41 -0700
From: Kevin Fall <kfall@cs.berkeley.edu>
To: dtn-interest@maillists.intel-research.net
Subject: [dtn-interest] IETF 75 Draft Agenda

Solicited draft agenda

Email sixteen
Date: Thu, 06 Nov 2008 08:43:42 +0000
From: Roland Backhouse <rcb@cs.nott.ac.uk>
To: Milena V Radenkovic <mvr@cs.nott.ac.uk>
Subject: Re: g53sec

Solicited internal communication

Email seventeen
Date: Thu, 16 Apr 2009 14:59:04 +0100
From: Janice Wells <jmw@cs.nott.ac.uk>
To: Milena Radenkovic <mvr@cs.nott.ac.uk>
Subject: Meeting to discuss student applications

Solicited internal communication

6
Part II
Network Protection using a Firewall
4 Firewall Rules
4.1 Public Firewall
Action Protocol Src Dest Src Port Dest Port
ALLOW TCP ANY 10.1.0.1 ANY 80, 443
ALLOW TCP ANY 10.1.0.2 ANY 25
ALLOW TCP 10.2.0.0/16 10.1.0.2 ANY 110, 143
ALLOW TCP 10.1.0.1 10.1.0.3 ANY ANY
ALLOW TCP 10.1.0.2 10.1.0.3 ANY ANY
ALLOW TCP 10.2.3.0/24 10.1.0.3 ANY ANY
DENY TCP ANY TWITTER ANY 80, 443
DENY TCP ANY GMAIL ANY 80, 443, 110, 143
ALLOW TCP 10.2.0.0/16 NOT 10.0.0.0/8 ANY ANY
ALLOW UDP 10.2.0.0/16 NOT 10.0.0.0/8 ANY ANY
DENY TCP ANY ANY ANY ANY
DENY UDP ANY ANY ANY ANY

4.2 Company Firewall(Internal)

Action Protocol Src Dest Src Port Dest Port
ALLOW TCP 10.2.0.0/16 10.2.1.1 ANY 80, 443
ALLOW TCP 10.2.0.0/16 10.2.1.2 ANY 445
ALLOW TCP 10.2.3.0/24 10.2.2.0/24 ANY 3389
DENY TCP 10.2.0.0/16 10.2.0.0/16 ANY ANY
DENY UDP 10.2.0.0/16 10.2.0.0/16 ANY ANY

5 Approach
The network components and constraints require a separation of the public facing servers from the
internal company servers and users. This distinction is enforced by the Public Firewall which
is directly connected to the Internet (see Figure 4). A Demilitarized Zone (DMZ) is a commonly
used term to describe this abstraction and the three public facing servers (Web/Mail/Oracle)
are placed on the 10.1.0.0/24 subnet. The Company Firewall enforces connections within the
internal company network (10.2.0.0/16), and provides a single point of entry between the internal
company network and the public.
Public firewall rules describing access to the DMZ’s web, mail and oracle servers are simple
and all other access is contained with the two final deny rules for TCP and UDP. The rule
encompassing internal company network access dictates that any traffic originating from within
the internal network is allowed providing it is not destined for any of the company network. The
combination of this rule with the two deny rules provides the backbone for all the higher priority
rules. Without this, connections coming from the internal network could reach all servers of the
DMZ and any rogue connections.

7
 Internal network constraints are handled in a simple manner of allowing the connections.
These rules sit on the back of two deny rules which prevent any non-specified connections across
the internal network. It is important to note the distinction between blocking all internal con-
nections and blocking all connections. If all connections were blocked, internal users would not
be able to access the internet, but by blocking all connections within the internal network, we
can leave it up to the abstraction of the Public Firewall to enforce rules outside of the internal
network.

8
9
Figure 4: Network Topology