The Phishing Guide
Part 1 - Attack
Part 2 - Defence

  The Phishing Guide (Part 2)
Understanding and Preventing Phishing Attacks

Section 3: Defence Mechanisms

3.1  Countering The Threat

As already shown in Section 2, the Phisher has a large number of methods at their disposal – consequently there is no single solution capable of combating all these different attack vectors. However, it is possible to prevent current and future Phishing attacks by utilising a mix of information security technologies and techniques.

For best protection, these security technologies and techniques must be deployed at three logical layers:

  1. The Client-side – this includes the users PC.
  2. The Server-side – this includes the businesses Internet visible systems and custom applications.
  3. Enterprise Level – distributed technologies and third-party management services

This section details the different defence mechanisms available at each logical layer.

3.2. Client-side

The client-side should be seen as representing the forefront of anti-phishing security. Given the distributed nature of home computing and the widely varying state of customer skill levels and awareness, client-side security is generally much poorer than a managed corporate workstation deployment. However, many solutions exist for use within both the home and corporate environments.

At the client-side, protection against Phishing can be afforded by:

  • Desktop protection technologies
  • Utilisation of appropriate less sophisticated communication settings
  • User application-level monitoring solutions
  • Locking-down browser capabilities
  • Digital signing and validation of email
  • General security awareness

3.2.1. Desktop Protection Agents

Most users of desktop systems are familiar with locally installed protection software, typically in the form of a common anti-virus solution. Ideally, desktop systems should be configured to use multiple desktop protection agents (even if this functionality duplicates any corporate perimeter protection services), and be capable of performing the following services:

  • Local Anti-Virus protection
  • Personal Firewall
  • Personal IDS
  • Personal Anti-Spam
  • Spyware Detection

Many desktop protection software providers (e.g. Symantec, McAfee, Microsoft, etc.) now provide solutions that are capable of fulfilling one or more of these functions. Specific to phishing attack vectors, these solutions (or a combination of) should provide the following functionality:

  • The ability to detect and block “on the fly” attempts to install malicious software (such as Trojan horses, key-loggers, screen-grabbers and creating backdoors) through email attachments, file downloads, dynamic HTML and scripted content.
  • The ability to identify common Spam delivery techniques and quarantine offending messages.
  • The ability to pull down the latest anti-virus and anti-spam signatures and apply them to the intercepting protection software. Given the variety in spamming techniques, this process should be scheduled as a daily activity.
  • The ability to detect and block unauthorised out-bound connections from installed software or active processes. For example, if the customers host has been previously compromised the protection solution must be able to query the authenticity of the out-bound connection and verify it with the user.
  • The ability to detect anomalies in network traffic profiles (both inbound and outbound) and initiate appropriate counter-measures. For instance, detecting that an inbound HTTP connection has been made and substantial outbound SSL traffic begins on a non-standard port.
  • The ability to block inbound connections to unassociated or restricted network ports and their services.
  • The ability to identify common Spyware installations and the ability to prevent installation of the software and/or blocking outbound communications to known Spyware monitoring sites.
  • Automatically block outbound delivery of sensitive information to suspected malicious parties. Sensitive information includes confidential financial details and contact information. Even if the customer cannot visually identify the true web-site that will receive the sensitive information, some off the shelf software solutions can.


  • Local Defence Awareness - Local installation of desktop protection agents is becoming an easier task, and most customers already appreciate the value of anti-virus software. It is a simple conceptual process to extend this cover to other protection agents and get customers to “buy-in”.
  • Protection Overlapping - Using a variety of desktop protection agents from various software manufacturers tends to cause overlaps in overall protection. This means that a failure or security lapse in one product may be detected and defended against by another.
  • Defence-in-Depth - The independent nature of desktop protection agents means that they do not affect (or are affected by) security functionality of other externally hosted services – thereby contributing to the overall defence-in-depth posture of an organisation.


  • Purchasing Price - The purchasing price of desktop protection agents is not an insignificant investment for many customers. If multiple vendors’ solutions are required to provide coverage against all attack vectors, there can be a substantial multiplication of financial cost for very little extra security coverage.
  • Subscription Renewals - Many of the current desktop protection agents rely on monthly or annual subscription payments to keep the users installation current. Unless appropriate notices are given, these renewals may not take place and the protection agents will be out of date.
  • Complexity & Manageability - For corporate environments, desktop protection agents can be complex to deploy and manage – particularly at an enterprise level. Since these solutions require continual deployments of updates (sometimes on a daily schedule), there may be a requirement of an investment in additional man-power.

3.2.2. Email Sophistication

Many of the email applications corporate users and customers use to access Internet resources provide an ever increasing level of functionality and sophistication. While some of this functionality may be required for sophisticated corporate applications and systems – use of these technologies typically only applies to inter-company systems. Most of this functionality is not required for day-to-day use – particularly for Internet communication services.

This unnecessary embedded (and often default) functionality is exploited by Phishing attacks (along with increasing the probability of other kinds of attacks). In general, most popular applications allow users to turn off the most dangerous functionality.

HTML-based Email
Many of the attacks outlined in Section 2 are successful due to HTML-based email functionality. In particular the ability to obfuscate the true destination of links, the ability to embed scripting elements and the automatic rendering of embedded (or linked) multimedia elements.

HTML functionality must be disabled in all email client applications capable of accepting or sending Internet emails. Instead plain-text email representation should be used, and ideally the chosen font should be fixed-with such as Courier.

Emails will then be rendered in plain-text, preventing the most common attack vectors. However, users should be prepared to receive some emails that appear to be “gobbldy-gook” due to textual formatting issues and probable HTML code inclusions. Some popular email clients will automatically remove the HTML code. While the visual appeal of the received emails may be lessoned, security is improved substantially.

Users should not use other email rendering options (such as Rich-text or Microsoft Word editors) as there are known security flaws with these formats which could also be exploited by Phishers.

Attachment Blocking
Email applications capable of blocking “dangerous” attachments and preventing users from quickly executing or viewing attached content should be used whenever possible.

Some popular email applications (such as Microsoft Outlook) maintain a list of “dangerous” attachment formats, and prevent users from opening them. While other applications force the user to save the file somewhere else before they can access it.

Ideally, users should not be able to directly access email attachments from within the email application. This applies to all attachment types (including Microsoft Word documents, multimedia files and binary files) as many of these file formats can contain malicious code capable of compromising the associated rendering application (e.g. the earlier example of a vulnerability in the RealPlayer .RM player). In addition, by saving the file locally, local anti-virus solutions are better able to inspect the file for viruses or other malicious content.


  • Overcomes HTML Obfuscation - Forcing all inbound emails into text-only format is sufficient to overcome standard HTML-based obfuscation techniques.
  • Overcoming Attached Viruses - By blocking attachments, and/or forcing content to be saved elsewhere, it makes more difficult for automated attacks to be conducted and provides extra potential for standard anti-virus products to detect malicious content.


  • Readability - The rendering of HTML-based emails often means that HTML code elements make the message difficult to read and understand.
  • Message Limitations - Users often find it difficult to include attachments (such as graphics) in TEXT-only emails having been used to drag-and-drop embedding of images into to HTML or Microsoft Word email editors.
  • Onerous Blocking - The default blocking of “dangerous” attachments often results in technical users attempting to bypass these limitations in commercial environments that are used to attaching or receiving executable content.

3.2.3. Browser Capabilities

The common web browser may be used as a defence against phishing attacks – if it is configured securely. Similar to the problems with email applications, web browsers also offer extended functionality that may be abused (often to a higher degree than email clients). For most users, their web browser is probably the most technically sophisticated application they use.

The most popular web browsers offer such a fantastic array of functionality – catering to all users in all environments – that they unintentionally provide gaping security flaws that expose the integrity of the host system to attack (it is almost a weekly occurrence that a new vulnerability is discovered that may be exploited remotely through a popular web browser). Much of the sophistication is devoted to being a “jack of all trades”, and no single user can be expected to require the use of all this functionality.

Customers and businesses must make a move to use a web browser that is appropriate for the task at hand. In particular, if the purpose of the web browser is to only browse Internet web services, a sophisticated web browser is not required.

To help prevent many Phishing attack vectors, web browser users should:

  • Disable all window pop-up functionality
  • Disable Java runtime support
  • Disable ActiveX support
  • Disable all multimedia and auto-play/auto-execute extensions
  • Prevent the storage of non-secure cookies
  • Ensure that any downloads cannot be automatically run from the browser, and must instead be downloaded into a directory for anti-virus inspection

Moving Away from Microsoft Internet Explorer
Microsoft’s web browser, Internet Explorer, is the most sophisticated web browser available. Consequently it has a very long track record of vulnerability discovery and remote exploitation. For typical web browsing, less than 5% of its built-in functionality is used. In fact many of the “features” available in the browser were added to protect against previous flaws and attack vectors. Unfortunately each new feature brings with it a host of security problems and additional complexity.

While some of the most dangerous functionality can be disabled or muted using various configuration options, customers and corporate users are urged to use a web browser that is most applicable to the task at hand (e.g. is the browser supposed to be a multimedia centre, a mail client, a chat platform or a compiled application delivery platform).

There are a number of vendors that offer web browsers that are more secure against a wider range of attack vectors – including phishing. A popular “stripped down”, but fully configurable, web browser is Firefox ( With a default install the web browser is one of the most secure around, yet it can still be managed within a corporate environment and is extensible through selective add-on modules.

Anti-Phishing Plug-ins
There is a growing number of specialist anti-phishing software producers that provide browser plug-ins. Most often, the plug-ins are added to the browsers toolbar and provide an active monitoring facility. These toolbars typically “phone-home” for each URL and verify that the requested server host is not currently on a list of known Phishing scams.

It is important to note that many of the browser plug-ins only support Microsoft’s Internet Explorer browser.


  • Immediate Security Improvements - Moving away from a complex web browser with reduced functionality will immediately mitigate against the most common security flaws and vulnerabilities in Internet Explorer.
  • Speed - Less sophisticated web browsers typically access and render web-based material quicker.


  • Loss of Extended Functionality - For corporate environments, the loss of some extended functionality may require dedicated applications instead of web browser integrated components.
  • Rendering of Complex Web-Applications - The removal of some complex functionality (in particular some client-side scripting languages) may cause web-applications to not render page content correctly.
  • Plug-ins Responsiveness - The current anti-phishing plug-ins are only as good as the managed provider maintaining the list of known phishing scams and sites. Plug-ins are typically only good for well known, widely distributed, phishing attacks.

3.2.4. Digitally Signed Email

It is possible to use Public Key cryptography systems to digitally sign an email. This signing can be used to verify the integrity of the messages content – thereby identifying whether the message content has been altered during transit. A signed message can be attributed to a specific users (or organisational) public key.

Almost all popular email client applications support the signing and verification of signed email messages. It is recommended that users:

  • Create a personal public/private key pair
  • Upload their public key to respected key management servers so that other people who may receive emails from the user can verify the messages integrity
  • Enable, be default, the automatic signing of emails
  • Verify all signatures on received emails and be careful of unsigned or invalid signed messages – ideally verifying the true source of the email

Figure: Digitally signed email – recipient validation of authenticity

A message signature is essentially a sophisticated one-way hash value that uses aspects of the sender’s private key, message length, date and time. The email recipient uses the public key associated with the email sender’s address to verify this hash value. The contents of the email should not be altered by any intermediary mail servers.

It is important to note that, in general, there are no restrictions on creating a public/private key pair for any email address a person may choose and consequently uploading the public key to an Internet key management server. Therefore it is still possible for a Phisher to send forth an email with a spoofed address and digitally sign it with a key that they own.

There are currently two popular methods for providing digital signing. These are S/MIME and PGP (including PGP/MIME and the newer OpenPGP standard). Most major Internet mail application vendor’s ship products capable of using and understanding S/MIME, PGP/MIME, and OpenPGP signed mail.

Although they offer similar services to email users, the two methods have very different formats. Further, and more important to corporate users, they have different formats for their certificates. This means that not only can users of one protocol not communicate with the users of the other; they also cannot share authentication certificates.

Key points for S/MIME and PGP:

  • S/MIME was originally developed by RSA Data Security, Inc. It is based on the PKCS #7 data format for the messages, and the X.509v3 format for certificates. PKCS #7 is based n the ASN.1 DER format for data.
  • PGP/MIME is based on PGP, which was developed by many individuals, some of whom have now joined together as PGP, Inc. The message and certificate formats were created from scratch and use simple binary encoding. OpenPGP is also based on PGP.
  • S/MIME, PGP/MIME, and OpenPGP use MIME to structure their messages. They rely on the multipart/signed MIME type that is described in RFC 1847 for moving signed messages over the Internet.


  • Business Standard - Since S/MIME is already a business standard, it is already incorporated into most standard email clients. Therefore it can work without and additional software requirements.
  • Identity Audit Trail - Phishers who digitally sign their emails must register their public keys with a central key authority. This registration process can provide a stronger audit trail when prosecuting the Phisher.
  • Trust Relationship - Legitimate business email can be better identified by customers, therefore generating a greater trust relationship with their customers.


  • Web-based Email Support - Not all web-based mail clients support S/MIME (e.g. Hotmail, AOL, Yahoo! Mail, Outlook Web Access for Exchange 5.5).
  • Misleading Domains - Customers must still closely inspect the “From:” address for misleading domains (e.g. support@mybá instead of
  • Revocation Checking - Recipients may not check certificate revocation status

3.2.5. Customer Vigilance

Customers may take a number of steps to avoid becoming a victim of a phishing attack that involve inspecting content that is presented to them and questioning its authenticity.

General vigilance (in addition to what has been covered in sections 3.2.1 to 3.2.4) includes:

  • If you get an email that warns you, with little or no notice, that an account of yours will be shut down unless you reconfirm billing information, do not reply or click on the link in the email. Instead, contact the company cited in the email using a telephone number or Web site address you know to be genuine.
  • Never respond to HTML email with embedded submission forms. Any information submitted via the email (even if it is legitimate) will be sent in clear text and could be observed.
  • Avoid emailing personal and financial information. Before submitting financial information through a Web site, look for the "lock" icon on the browser's status bar. It signals that your information is secure during transmission.
  • For sites that indicate they are secure, review the SSL certificate that has been received and ensure that it has been issued by a trusted certificate authority. SSL certificate information can be obtained by double-clicking on the “lock” icon at the bottom of the browser, or by right-clicking on a page and selecting properties.
  • Review credit card and bank account statements as soon as you receive them to determine whether there are any unauthorised charges. If your statement is late by more than a couple of days, call your credit card company or bank to confirm your billing address and account balances.

Money Laundering Job Scams
Given the successes of phishing scams in obtaining personal financial information from their victims, Phishers have needed to develop follow-up scams in order to safely transfer stolen monies from the accounts and country. An increasingly popular method of accomplishing this is through fake job scams.

For those not aware of what we are talking about here's how these job scams work.

  • The Phishers exploit a number of bank accounts via standard phishing attack vectors.
  • They then have a problem of getting the money out of them as most Internet banking facilities do not allow direct transfers to overseas accounts.
  • A common way to avoid these restrictions is through job scams. Phishers offer these "jobs" via spam emails, fake job advertisements on real job websites or instant messaging spam.
  • Once they have recruited a "mule", they are then instructed to create a new bank account with the exploited bank (or use their existing one if they are already a customer) where the Phishers have exploited accounts in the past. The Phishers then remove money from the exploited accounts and put in to the mules account.
  • The mule is told this is a payment that needs to be transferred and is asked to withdraw the money, minus their "commission", and typically wire it via services such as Western Union to a European/Asian country.
  • The Phishers now have the majority of the money from the original exploited accounts and when the money is traced by the banks/police the mule is left being accountable.


  • Cost - By remaining aware of common phishing attack vectors and understanding how to respond to them, customers can take cost efficient actions to protect themselves.


  • Information Overload - With so many attack vectors and corresponding steps that that must be taken to identify the threat, customers are often overwhelmed with necessary detection processes. This may result in customers not trusting or using any electronic communication methods.
  • Changing Battlefield - Phishers are constantly developing new deceptive techniques to confuse customers and hide the true nature of the message. It is increasingly difficult to identify attacks.

3.3. Server-side

By implementing intelligent anti-phishing techniques into the organisations web application security, developing internal processes to combat phishing vectors and educating customers – it is possible to take an active role in protecting customers from future attack. By carrying out this work from the server-side, organisations can take large steps in helping to protect against what is invariably a complex and insidious threat.

At the client-side, protection against Phishing can be afforded by:

  • Improving customer awareness
  • Providing validation information for official communications
  • Ensuring that the Internet web application is securely developed and doesn’t include easily exploitable attack vectors
  • Using strong token-based authentication systems
  • Keeping naming systems simple and understandable

3.3.1. Customer Awareness

It is important that organisations constantly inform their customers and other application users of the dangers from Phishing attacks and what preventative actions are available. In particular, information must be visible about how the organisation communicates securely with their customers. For instance, a posting similar to the following will help customers identify phishing emails sent in the organisations name.

"MyBank will never initiate a request for sensitive information from you via email (i.e., Social Security Number, Personal ID, Password, PIN or account number). If you receive an email that requests this type of sensitive information, you should be suspicious of it. We strongly suggest that you do not share your Personal ID, Password, PIN or account number with anyone, under any circumstances.

If you suspect that you have received a fraudulent email, or wish to validate an official email from MyBank, please visit our anti-phishing page"

Key steps in helping to ensure customer awareness and continued vigilance:

  • Remind customers repeatedly. This can be achieved with small notifications on critical login pages about how the organisation communicates with their customers. Customers reaching the page should be prompted to think about the legitimacy of the email (or other communication) that drove them to the page.
  • Provide an easy method for customers to report phishing scams, or other possible fraudulent emails sent in the organisations name. This can be achieved by providing clear links on key authentication and help pages that enable customers to report a possible phishing scam – and also provide advice on recognising a scam. Importantly, the organisation must invest in sufficient resources to review these submissions and be capable of working with law enforcement agencies and ISP’s to stop an attack in progress.
  • Provide advice on how to verify the integrity of the website they are using. This includes how to:
        Check the security settings of their web browser
        Check that their connection is secure over SSL
        Review the “padlock” and certificate signature of the page
        Decipher the URL line in their browser
  • Establish corporate communication policies and enforce them. Create corporate policies for email content so that legitimate emails cannot be confused with phishing attacks. Ensure that the departments likely to communicate with customers clearly understand the policy and take steps to enforce them (e.g. perimeter content checking systems, review by QA teams, etc.).
    To be effective, organisations must ensure that they are sending a clear, concise and consistent message to their customers. For example, don’t post announcements claiming to “never prompt users to fill in forms in an email” one day and then send out an email request for online bill payment the following day, which includes a login form in the email.
  • Respond quickly and clearly about phishing scams that have been identified. It is important that customers understand that the threat is real and, importantly, how the organisation is working to protect them against attack. However, organisations must take care not to swamp customers with information.


  • Low Cost - Out of all the anti-phishing techniques, ensuring that customers are aware of the threats and can take preventative action themselves proves to be a cost worthy investment.
  • Low Tech - By providing a low tech solution to a complex threat, customers are better able to trust their relationship with the organisation


  • Consistency - Care must be taken to ensure that communications are conducted consistently. One poor decision can undermine much of the work.
  • Information Overload - Care must be taken to not overload customers with too much information and make them fearful of using the organisations online resources.

3.3.2. Validating Official Communications

Steps may be taken by an organisation to help validate official customer communications and provide a means for identifying potential phishing attacks. Tied closely with the customer awareness issues already discussed, there are a number of techniques an organisation may apply to official communications, however care must be taken to only use techniques that are appropriate to the audience’s technical ability and value of transactions.

Email Personalisation
Emails sent to customers should be personalised for the specific recipient. This personalisation may range from the use of the customers name, or reference some other piece of unique information shared between the customer at the organisation.

Examples include:

  • “Dear Mr Smith” instead of “Dear Sir,” or “Our valued customer”
  • Credit card account holder “**** **** **32 6722” (ensure that only parts of confidential information are used)
  • Referencing the initiating personal contact such as “your account manager Mrs Jane Doe…”

Organisations must ensure that they do not leak other confidential details about the customer (such as full address details, passwords, individual account details, etc.) within their communications.

Previous Message Referral
It is possible to reference a pervious email that was sent to the customer – therefore establishing a trail of trust in communications. This may be achieved through various means. The most common methods are:

  • Clearly referencing the subject and date of the previous email.
  • Providing a sequential number to the email.

While these methods of email referral are valuable, they are also complex for the customer to validate. There are no guarantees that the customer still retains access to a previous email to verify the sequence – and is especially so if the organisation sends the customer a high volume of emails, or frequent advertising-type messages.

Digital Signatures
The use of digital certificates to sign messages is recommended. However, care must be taken to educate customers on their use and understand how to validate signatures.

Web Application Validation Portals
A successful method of providing reassurance to customers on the authenticity of a communication, and subsequently providing the ability to identify a new phishing attack, is to provide a portal on the corporate website. The web portal exists to allow customer to copy/paste their received message content to an interactive form, and for the application to clearly display the authenticity of the message.

If the message fails the authenticity checks, the message should be manually verified by the organisation to evaluate whether the message contains a malicious phishing attack.

Similarly, an interface should be provided in which customer can copy/paste suspicious URL’s that they have received. The application then validates whether this is a legitimate URL relating to the organisation.

Visual or Audio personalisation of email
It is possible to embed personalised visual or audio data within an email. This material would have been supplied by the customer previously, or contain the equivalent of a shared secret. However, this method is not recommended as it may be rendered ineffectual through the enforcement of non-HTML or attachment emails at the customer side.


  • Efficient - The simple process of personalising communications makes it a lot easier for customers to identify official communications from spam. Making the process of validating message sources faster and more efficient.


  • Additional Resources - Organisations must typically expand their online validation services which will require additional resources – both in development and day-to-day management.
  • Customer Awareness - Customers may not use or be aware of the significance of these personalised protective actions.

3.3.3. Custom Web Application Security

Organisations constantly underestimate the anti-phishing potential of their custom web applications. By applying robust content checking functions and implementing a few “personalisation” security additions, many popular Phishing attack vectors can be removed.

Securing web-based applications offer the greatest “bang for buck” method of protecting customers against Phishing attacks.

A key security concern revolves around increasingly sophisticated cross-site scripting vulnerabilities. These cross-site scripting vulnerabilities often escape other client-side protection strategies due to inherent trust relationships between the customer and the web-site owner – resulting in highly successful (and undetectable) attacks.

Content Validation
One of the most common security flaws in custom web-based applications relates to poorly implanted (or non existent) input validation processes.

The key principles to successfully implementing content validation processes include:

  • Never inherently trust data submitted by a user or other application components.
  • Never present submitted data directly back to an application user without sanitising it first.
  • Always sanitise data before processing or storing it
  • Ensure that all dangerous characters (i.e. characters that may be interpreted by the clients browser or background application processes) as constituting an executable language are replaced with their appropriate HTML safe versions. For example, the less-than character “<” has a specific meaning in HTML – so is should be rendered back to users as &lt.
  • Ensure that all data is sanitised by decoding common encoding schemes (e.g. %2E, %C0%AE, %u002E, %%35%63) back to their root character. Again, if the character is “unsafe”, it should be rendered in the HTML equivalent format. Beware that this decoding process may have to be carried out many times – until all encoded sequences have been removed.

More information can be found in “URL Encoded Attacks” and “HTML Code Injection and Cross-site scripting”.

Session Handling
The stateless nature of HTTP and HTTPS communication necessitates the correct application of session handling processes. Many custom applications implement custom session handling routines that are potentially vulnerable to preset session attacks.

To overcome a Preset Session attack, developers should ensure that their application functions the following way:

  • Never accept session information within a URL.
  • Ensure that SessionID’s have expiry time limits and that they are checked before use with each client request.
  • The application should be capable of revoking active SessionID’s and not recycling the same SessionID for an extended period.
  • Any attempts to submit an invalid SessionID (i.e. one that has expired, been revoked, extended beyond it’s absolute life, or never been issued), should result in a server-side redirection to the login page and be issued with a new SessionID.
  • Never keep a SessionID that was initially provided over HTTP after the customer has logged in over a secure connection (i.e. HTTPS). After authenticating, the customer should always be issued a new SessionID.

More information can be found in “Web Based Session Management”.

URL Qualification
For web-based applications that find it necessary to use client-side redirection to other page locations or hosts, great care must be taken in qualifying the nature of the link beforehand. Application developers should be aware of the techniques discussed in Section 2 of this paper.

Best practices for URL qualification are:

  • Do not reference redirection URL’s or alternative file paths directly within the browsers URL path (e.g.
  • Always maintain a valid “approved” list of redirection URL’s. For example, manage a server-side list of URL’s associated with an index parameter. When a client follows a link, their submission will reference this index, and the returned redirection page will contain the full managed URL.
  • Never allow customers to supply their own URL’s.
  • Never allow IP addresses to be used in URL information. Always use the fully qualified domain name, or at the very least conduct a reverse name lookup on the IP address and verify that it lies with a domain the application should be trusted.

Authentication Processes
For many Phishing scams, a key goal of the attack is to capture the customers authentication credentials. To do so, the attacker must be able to monitor all the information submitted during the application login phase. Organisations can use multiple methods to make this process more difficult for the Phisher.

Application developers should review the comprehensive guide to “Custom HTML Authentication” to prevent most forms of possible attack. However, related specifically to protecting against Phishing attacks, developers should:

  • Ensure that (minimally) a two-phase login process is used. The customer is first presented with a login screen that they must present account details that are typically less secure (i.e. there is a high probability that the customer may use these details on other websites – e.g. their login name and credit card number). Once successfully passing this page, they are presented with a second page that requires two or more unique pieces of authentication information before they can proceed to the application proper.
  • Use of anti key-logging processes such as selecting specific parts of a password or pass phrase from drop-down list boxes is highly recommended.
  • Try to used personalised content (combined with customer awareness) to identify fake web-sites. For example, when a customer originally creates their online account they should be able to select or upload their own personalised graphic. This personalised graphic will always be presented to them during the second stage of the authentication process and on any authenticated page. This graphic may be used as a watermark of authenticity to combat faked content.
  • Not make the authentication process too complex. Be aware that disabled customers may have difficulty with some functionality such as drop-down boxes.

Image Regulation
As many phishing attacks rely upon hosting a copy of the target website on a system under the Phishers control, there are potential avenues for organisations to automatically identify a faked web-site.
Depending upon whether the Phisher has mirrored the entire website (including pages and their associated graphics) or is just hosting a modified HTML page (which reference graphics located on the real organisations servers), it may be possible to disrupt or uniquely identify the source of the attack.

Two methods are available to application developers:

  • Image Cycling - Each legitimate application page references their constituent graphical images by a unique name. Each hour, the names of the images are changed and the requesting page must reference these new image names. Therefore any out-of-date static copies of the page that make reference to these centrally stored images will become dated quickly. If an out-of-date image is requested (say 2+ hours old) a different image is supplied – perhaps recommending that the customer login again to the real site (e.g. “Warning Image Expired”).
  • Session-bound Images - Extending the image cycling principle further, it is possible to reference all images with a name that includes the users current SessionID. Therefore, once a fake website has been discovered (even if the Phisher is using locally stored graphics), the organisation can review their logs in an attempt to discover the originating source of the copied website. This is particularly useful for fake sites that also use content that requires authenticated access and could only be gained by a Phisher actually using a real account in the first place.
    In addition, the organisation may utilise transparent/invisible watermarking technologies and embedding session information into the graphic itself. However, this process would incur high performance overheads at the server-side.


  • Robustness - By adding appropriate security to custom developed web applications, organisations find that not only are their applications better capable of resisting phishing attacks, but that overall robustness against other more sophisticated attacks is gained.
  • Cost Effectiveness - By fixing security issues within the application, the number of attack vectors available to a Phisher diminishes substantially. Securing the base application thus proves to be a cost effective defence against current and future threats.
  • Customer Independence - Security improvements with the server-side applications do not generally involve changes to the customers experience. Therefore changes can be conducted independent of the customers client-side configuration.


  • Requires Skilled Developers - Implementing these security additions requires skilled developers with some experience in implementing security. These resources are traditionally harder to obtain.
  • Must be Tested - Organisations must ensure that all new security features (along with any standard application modifications) are thoroughly tested from a security perspective before going live (or as soon as possible after going live).
  • Performance Overheads - Extra processing resources are normally required to implement these security mechanisms. Therefore application performance may be adversely affected.

3.3.4. Strong Token-based Authentication

There are a number of authentication methods that make use of external systems for generating single-use or time-based passwords. These systems, often referred to as token-based authentication systems, may be based on physical devices (such as key-fobs or calculators) or software. Their purpose is to create strong (one-time) passwords that cannot be repeatedly used to gain entry to an application.

Customers of the legitimate web-based application may use a physical token such as a smartcard or calculator to provide a single-use or time-dependant password.

Figure: Strong token-based authentication

Due to high setup and maintenance costs, this solution is best suited to high value transactional web applications that are unlikely to require a large number of users.

As with any authentication process, organisations must strike a balance between what personal/confidential details are minimally required to uniquely authenticate a customer, and how much of this information is either publicly available or likely to be used by the customer to access another organisations web-based application. By reducing the likelihood of authentication details being shared between multiple organisations, there is less opportunities for an attacker to achieve an identity theft.


  • Time Dependence - The password is time dependant. Therefore, unless the Phisher can retrieve and use this information within preset time limits, the password will have expired and become useless.
  • Physical Token Access - A Phisher must gain physical access to the token in order to impersonate the user and carry out the theft.
  • Sense of Trust - Users are more inclined to trust token-based authentication systems for monetary transactions.
  • Anti-Fraud - Duplicating the physical token requires much more sophistication, even if the victim provides their personal PIN number associated with the token.


  • User Education - Users must be provided with guidance on how to use the physical token within a time-dependant framework.
  • Token Costs - Physical tokens are typically costly to manufacture and distribute to users. Each physical token may cost between £5 and £50, with distribution costs (e.g. postage) being additional.
  • Setup Times - Account creation and token distribution will typically require a number of days before the user potentially can access the web application.
  • High Management Costs - Managing a token-based system requires more effort and greater access to internal resources.
  • Scaling Issues - A customer may need to carry multiple tokens, one for each service to which they are subscribed.

3.3.5. Host and Linking Conventions

A growing number of phishing attacks make use of the confusion caused by organisations using complex naming of host services (e.g. fully qualified domain names) and undecipherable URL’s. Most customers are non-technical and are easily overwhelmed with the long and complex information presented in “follow this link” URLs.

Wherever possible, organisations should:

  • Always use the same root domain. For example: instead of instead of instead of
  • Automatically redirect regional or other registered domain names to the main (single) corporate domain. For example: redirects to redirects to redirects to
  • Use host names that represent the nature of the web-based application. For example: instead of instead of
  • Always use the simplest URL or host name possible. For example: instead of instead of
  • Never keep session information in a URL format. For example, don’t do the following:

    Instead, keep the URL as clean as possible and manage this extra information through appropriate server-side session management techniques (preferred), or keep the data within hidden fields of the HTML document and only use HTTP POST commands (less preferred).


  • Easy to Apply - Application of a robust and simple naming convention for host and URL naming is a simple process. It can be applied quickly.
  • Visible Identification - A simplified naming convention makes it much easier for customers to spot fraudulent links and understand their site destination.
  • Easy to Explain - Organisations can explain quite simply how their naming convention functions, and provide valuable advice on identifying and reporting malicious links.


  • Application Modification - Some complex applications with hard coded host names may require updating.

3.4. Enterprise

Businesses and ISP’s may take enterprise-level steps to secure against Phishing scams – thereby protecting both their customers and internal users. These enterprise security solutions work in combination with client-side and server-side security mechanisms, offering considerable defence-in-depth against phishing and a multitude of other current threats.

Key steps to anti-phishing enterprise-level security includes:

  • Automatic validation of sending email server addresses,
  • Digital signing of email services,
  • Monitoring of corporate domains and notification of “similar” registrations,
  • Perimeter or gateway protection agents,
  • Third-party managed services.

3.4.1. Mail Server Authentication

Multiple methods have been proposed to authenticating sending mail servers. In essence, the senders mail server is validated (e.g. reverse resolution of Domain information to a specific IP address or range) by the receiving mail server. If the senders IP address is not an authorised address for the email domain, the email is dropped by the receiving mail server.

Figure: Mail server authentication – DNS querying of MX records

Alternatively, through the use of Secure SMTP, email transport could be conducted over an encrypted SSL/TLS link. When the sender mail server connects to the recipient mail server, certificates are exchanged before an encrypted link is established. Validation of the certificate can be used to uniquely identify a trusted sender. Missing, invalid or revoked certificates will prevent a secure connection from occurring and not allow delivery of emails.

If desired, an additional check with the DNS server can be used to ensure that only authorised mail servers may send email over the secure SMTP connection.

Figure: Mail server authentication – server certificates

The purpose of validating the sending servers address is to help cut down the volume of spam, and accelerate the receipt of emails known to come from a “good” source. However, both systems can be overcome with poor server configuration – especially if the sender server can operate as an open relay agent. It is important to note that Secure SMTP is not commonly deployed. However, email server validation is useful in intra-corporate communications when combined with mail server rules that block/disallow inbound emails that use “From:” addresses which could only come from internal users.


  • Easy Configuration - Updating the DNS server with the relevant MX records for each mail server is required for reverse resolution of valid mail servers within a domain.
  • Anonymity Prevention - Sending servers are validated before emails are accepted by the Receiving server. Therefore the phishers sending server cannot be anonymous.
  • Business Email Identification - Validation of the sending server can be used to identify legitimate business emails; thereby lowering email spam false positives


  • From: Address Spoofing - Since the SMTP sender address is not normally visible to email recipients, it is still possible to spoof the From: address.
  • Email Forwarding - Both methods do not allow for email forwarding processes. Validation of sending server depends upon direct Sender-Receiver connections.
  • Third-party Email Services - Third-party email service providers (e.g. MessageLabs) act as mail forwarders.
  • Secure SMTP Distribution - SMTP over secure SSL/TLS protocols is not common, nor is the implementation of the supporting certificate architecture for Mail servers.

3.4.2. Digitally Signed Email

Extending the processes for digitally signed email discussed in section 3.2.4, enterprises can configure their receiving email servers to automatically validate digitally signed emails before they reach the recipient. This process may prove to be more efficient for an organisation, and automatic steps can be taken to alert recipients of invalid or unsigned emails.
In addition, the enterprise email server can be configured to always sign outbound email. By doing so, a single “corporate” digital certificate can be used and customers who receive these signed emails can be confident that their received message is legitimate.

Figure: Digitally signed email – receiving mail server validation of authenticity

3.4.3. Domain Monitoring

It is important that organisations carefully monitor the registration of Internet domains relating to their organisation. Companies should be continuously monitoring domain name registrars and the domain name system for domain names that infringe upon their trademarked names, and that could used for launching spoofed websites to fool customers. There are two areas of concern:

  1. The expiry and renewal of existing corporate domains
  2. The registration of similarly named domains

Domain Name Expiry and Renewal
There are numerous agencies that allow the registration of domains previously owned by an organisation that have not been renewed. Since many organisations own multiple domains, great care must be made to manage renewal payments if they wish to retain it. Failure to reregister domains in a timely fashion will result in a loss of service (i.e. domain name lookup no longer associate to an IP address) or may be purchased by a third-party.

Registration of Similarly Named Domains
It is a simple process for someone to register a domain name through any domain registrar, anywhere in the world. Consequently there are many routes and opportunities for third-parties to register domain names that may infringe upon an organisations trademark or used to trick customers into believing that they have reached a legitimate host.

For example, assuming the organisations name is “Global Widgets” and their normal website is, the organisation should keep a watchful eye out for:

  • Hyphenated names –
  • Country specific –
  • Legitimate possibilities –
  • Mixed wording –
  • Long host names –
  • Hard to spot misspellings – or
  • Mixed-case ambiguities – (

There are now commercial services available that help organisations monitor the domain name service and alert when potentially threatening new domains are registered. Similarly, alerting services exist that will observe popular hacking chat rooms and posting forums for discussions on phishing and other spoofing scams.

3.4.4. Gateway Services

The enterprise network perimeter is an ideal place for adding gateway protection services that can monitor and control both inbound and outbound communications. These services can be used to identify malicious Phishing content; whether it be located within email or other communication streams.

Typical enterprise-level gateway services include:

  • Gateway Anti-Virus Scanning – used to detect viruses, malicious scripting code and binary attachments that contain Trojan horse software.
  • Gateway Anti-Spam Filtering – rule-based inspection of email content for key phrases (such as Viagra) and bad words, typically used to identify common spam, but also capable of stopping many forms of phishing attack that are designed to look like legitimate spam.
  • Gateway Content Filtering – inspection of many types of communication methods (e.g. email, IM, AOL, HTTP, FTP) for bad content or requests. Simple protection against users visiting known bad or dangerous websites.
  • Proxy Services – management concatenation of Internet protocols and control over types of egress communications. Protection against inbound attacks through the use of network address translation. Good protection against common information leakage of internal network configurations.


  • Update Efficiency - It is far easier, and faster, for a large institution to update a relatively small number of gateway scanner than it is to ensure that all desktop scanners are up to date. Automated desktop virus scan updates help, but is still somewhat slower than gateway updates.
  • ISP Independence - Gateway content filtering is very effective at blocking access to known phishing sites or content, without waiting for an ISP to remove the offending phishing site.
  • Pre-emptive Protection - Malicious code can be blocked from entering the network.


  • Traffic Limitations - Some forms of network traffic cannot be scanned.
  • Firewall Changes - Some gateway implementations may require manual configuration of firewalls and other gateway devices to implement blocking rules.
  • Roaming User Protection - Roaming users such as mobile salesmen are not protected by the gateway services.

3.4.5. Managed Services

While perimeter defence systems provide a good safeguard against many common phishing attack vectors, Phishers (along with Spammers) are constantly developing methods designed to bypass these protection agents.

Managed services in the realm of anti-spam and anti-phishing provide valuable improvements in security. This is largely due to their ability to analyse email messages delivered at a global level, and identify common threads between malicious emails. For instance, an organisation may only receive 5 or 6 carefully disguised phishing emails with minor content changes – not enough to trigger an anti-spam response – while the managed service provider has spotted several thousand of the same style emails which triggers the anti-spam/anti-phishing blocking processes. When dealing with phishing and spam, email volume is a key component in identifying malicious activities.

Active Web Monitoring
Managed service providers may deploy agent-based ‘bots to monitor URL’s and web content from remote sites, actively searching for all instances of an organisations logo, trademark, or unique web content. The subscribing organisation institution provides a “white list” of authorised users of logo, trademark, and unique web content to the service provider. When the ‘bots detect unauthorised deployments or instances of the logos, trademarks, or other web content, remediation actions may be taken by the subscriber.


  • Ease of Use - Since the services are provided by an external party, there are very few internal requirements in setting up and configuring the service.
  • Wider Visibility - Managed service providers that look after many organisations globally have great visibility of current threats and can easily identify threats that would normally fall below standard triggering threshold.
  • Timely Intervention - Legal writs may be generated as a result of active monitoring of content, and identification of inappropriate use even if no phishing emails have been detected.


  • Costly - For large organisations, outsourcing protection to managed service providers can be expensive. For smaller organisations the cost may however be less than running the service themselves with dedicated resources.
  • False Positive Management - Steps must be taken to manage false positives and quarantine procedures – requiring internal resources to monitor and manage this process.

Section 4: Summations

4.1. Conclusions

Phishing started off being part of popular hacking culture. Now, as more organisations provide greater online access for their customers, professional criminals are successfully using phishing techniques to steal personal finances and conduct identity theft at a global level.

By understanding the tools and technologies Phishers have in their arsenal, businesses and their customers can take a proactive stance in defending against future attacks. Organisations have within their grasp numerous techniques and processes that may be used to protect the trust and integrity of their customers personal data. The points raised within this paper, and the solutions proposed, represent key steps in securing online services from fraudulent phishing attacks – and also go a long way in protecting against many other popular hacking or criminal attack vectors.

By applying a multi-tiered approach to their security model (client-side, server-side and enterprise) organisations can easily manage their protection technologies against today’s and tomorrows threats – without relying upon proposed improvements in communication security that are unlikely to be adopted globally for many years to come.

4.2. Resources

“Proposed Solutions to Address the Threat of Email Spoofing Scams”, The Anti-Phishing Working Group, December 2003
“Anti-Phishing: Best Practices for Institutions and Consumers”, McAfee, March 2004
“URL Encoded Attacks”, Gunter Ollmann, 2002
“HTML Code Injection and Cross-site scripting”, Gunter Ollmann, 2001
“Web Based Session Management”, Gunter Ollmann, 2002
“Custom HTML Authentication”, Gunter Ollmann, 2003
“Phishing Victims Likely Will Suffer Identity Theft Fraud”, Gartner Research Note, A. Litan,
14 May 2004.

Information Links
Code Fish Spam Watch -
Anti-Phishing Working Group -
Technical Info –

    Copyright 2001-2007 © Gunter Ollmann