Thwarting phishing attacks by using pre-established policy files

[0001] This invention pertains to the field of preventing phishing attacks on recipients of electronic messages, wherein criminals imitate legitimate companys' electronic messages and Websites to entice recipient account holders to share highly sensitive personal data.

[0002] “Phishing” refers to the activities of criminals who imitate legitimate companys' electronic messages and Websites to entice recipient account holders to share highly sensitive personal data, such as Social Security numbers, users' names, passwords, and/or account numbers. Once acquired, the criminals use the stolen information to commit subsequent crimes.

[0003] One of the most common phishing attacks is to modify an existing Website of a trusted brand so that it appears to be part of the trusted company's Website. A spoofed company e-mail is then sent to a recipient with a link to this modified Web page, with a form that solicits the user's credit card data or passwords. When the form is submitted, it sends the data to the criminals while leaving the user on the replica company site. Nothing appears out of the ordinary to the user, who has now become a victim of fraud and has been exposed to potential substantial personal loss and identity theft.

[0004] Phishing is extremely dynamic and is growing in both sophistication and volume. The Anti-Phishing Working Group estimates that incidents of phishing attacks are increasing by 50% per month at the time this patent application is being written, and that phishers are able to convince up to 5% of recipients to respond to them.

[0005] What is needed is a reliable set of techniques to determine whether a subject electronic message is attempting to send the recipient to a Website that is not part of the Website of a legitimate company.

[0006] Methods, apparati, and computer-readable media for thwarting a phishing attack on a recipient of an electronic message (5). A method embodiment of the present invention comprises the steps of intercepting (31) the electronic message (5); extracting (32) a sender domain name from the electronic message (5); identifying (33) remote links associated with the electronic message (5); comparing (34) the identified remote links against a pre-established set (14) of acceptable domains, using the extracted sender domain name as an index; and when at least one extracted remote link is not found in the pre-established set (14) of acceptable domains, preventing (37) the message (5) from being delivered to the recipient.

[0011] FIG. 1 illustrates apparatus suitable for carrying out the present invention.

[0012] Electronic message 5 can be any type of electronic message, such as an e-mail message following the SMTP protocol, a text message following the SMS protocol, or an instant message following the IMPP protocol.

[0013] Interception module 10 intercepts electronic messages 5 before they reach the intended recipient. Interception module 10, and its fellow modules 11-15, can be located anywhere in the chain from the messages 5 to the recipient. Thus, these modules can be located at a server, a proxy, a gateway, and/or a client.

[0014] Coupled to interception module 10 is extraction module 11, which extracts the domain name of the sender of the electronic message 5.

[0015] Coupled to extraction module 11 is identification module 12, which identifies all the remote links contained in electronic message 5 and, optionally, identifies conditions that are flagged within policy files 14.

[0016] Coupled to identification module 12 is comparison module 13, which compares the identified remote links and, optionally, the identified flagged conditions, against a pre-established set of acceptable domains contained within policy files 14 that are posted at a fixed location, using the extracted sender domain name as an index to get to the policy file 14 associated with the extracted sender domain name.

[0017] Coupled to comparison module 13 is deletion module 15 for preventing the electronic message 5 from being delivered to the recipient when at least one identified remote link is not found in the pre-established set of acceptable domains contained within the relevant policy file 14.

[0018] The above describes in a nutshell the whitelist embodiment of the present invention. In an alternative blacklist embodiment, the invention is the same as in the whitelist embodiment, except that comparison module 13 compares the identified remote links, and optionally the identified flagged conditions, against a pre-established set of unacceptable domains (and, optionally, flagged conditions) contained within the relevant policy file 14, again using the extracted sender domain name as an index; and in the blacklist embodiment, deletion module 15 prevents the electronic message 5 from being delivered to the recipient when at least one identified remote link is found in the pre-established set of unacceptable domains contained within the relevant policy file 14 (or when at least one flagged condition corresponds to a pre-established unacceptable flagged condition as specified in the relevant policy file 14).

[0019] Modules 10 through 15 can be implemented in any combination of hardware, firmware, and software. When implemented in whole or in part in software, modules 10 through 15 can be embodied on at least one computer readable medium, such as one or more hard disks, floppy disks, CDs, DVDs, etc.

[0020] For purposes of illustration only, FIG. 1 illustrates modules 10 through 13 and 15 as being separate and distinct from each other. However, one or more of the functions implemented by modules 10 through 13 and 15 can be combined to form fewer than the illustrated five modules.

[0021] FIG. 3 illustrates a method embodiment of the present invention. At step 31, interception module 10 intercepts an electronic message 5 for processing.

[0022] At step 32, extraction module 11 extracts the domain name of the sender from the intercepted electronic message 5.

[0023] At step 33, identification module 12 identifies all the remote links that are contained within electronic message 5. These links are any means by which the sender of the electronic message 5 entices the recipient to go to a remote site. Thus, the links can include anchor tags (links that are blue and underlined in HTML); link tags (links to style sheets, etc.); URLs in text form; and URLs embedded in Web bugs. The Web bugs can include CSS (cascading style sheets, i.e., that part of HTML that describes formats that are used in other sections of HTML; they are “cascaded” because one can inherit from a previous one) and IMG (image tags in HTML). Optionally at step 33, preselected flagged conditions are also identified. Examples of flagged conditions are whether a form is present in electronic message 5 and whether script (part of HTML that is executable) is present in electronic message 5. The reason for wanting to identify forms is that forms are often used by phishers to get a head start in obtaining information, such as Social Security numbers, from recipients on initial screens. The reason for wanting to identify script is that script is widely used by phishers to change URLs at runtime.

[0024] At step 34, comparison module 13 compares the remote links, and optionally the flagged conditions, that were identified in step 33, against a pre-established set of acceptable domains, and, optionally, against a pre-established set of flagged conditions, stored in policy files 14, using the sender's domain name that was extracted in step 32 as an index to access the relevant policy file 14 corresponding to the extracted sender domain name. Policy files 14 containing the pre-established set of acceptable domains, and optionally the pre-established acceptable flagged conditions, have been previously compiled by a group of domain owners desirous of thwarting phishing attacks and thereby willing to set up such policy files 14.

[0025] For example, let us assume that electronic message 5 is an e-mail sent from [email protected]. In order for this invention to work, the real Citibank must have made a policy file 14 available. File 14 may be, for example, an XML file located at http://www.citibank.com/anti-phishing/policy.xml. This file 14 should be made secure, by means that are known to one of ordinary skill in the security art. This policy.xml file 14 contains a list of legitimate domain names that a real Citibank e-mail 5 could legitimately point the recipient to. In addition, this policy.xml file 14 can also contain a set of flagged conditions such as “script allowed” or “script not allowed”; or “forms allowed” or “forms not allowed”. These flagged conditions are another way to narrow what e-mails 5 are passed through to the recipient as being legitimate.

[0026] In one embodiment of the present invention, illustrated in FIG. 2, at least one domain owner (in this case Citibank) controls a plurality of sub-domains. In the illustrated embodiment, the sub-domains are Citimortgage.com having its own policy file 14(2), Citibank.co.uk having its own policy file 14(3), Citibank.co.jp having its own policy file 14(4), and Citibank.cn having its own policy file 14(5). Each sub-domain has an entry in the pre-established set 14 of acceptable domains. In this embodiment, each sub-domain entry in the pre-established set 14 of acceptable domains points to a master domain policy file 14(1) maintained by the master domain owner. In this case, this master policy file 14(1) is in the name of Citibank.com. This embodiment enables a large enterprise such as Citibank to post just a single policy file 14(1) rather than, in this case, four separate policy files 14(2) through 14(5). This makes it much easier to update the policies for all of the Citibank sub-domains. In practice, when comparison module 13 accesses the policy file 14(2) for Citimortgage.com, the policy information from master policy file 14(1) is presented to comparison module 13.

[0027] By default, the sender's domain is allowed as a legitimate domain in this whitelist embodiment. For example, Citibank.com is allowed in an e-mail from [email protected]. The list of allowed URLs in policy file 14 allows related entity Web visits, such as an e-mail 5 from [email protected] that asks the recipient to visit http://www.Citimortgage.com.

[0028] Returning to FIG. 3, at step 35 comparison module 13 inquires, in the whitelist embodiment, as to whether all of the remote links that were identified in step 33 are found within the pre-established set of acceptable domains contained within the relevant policy file 14, and, optionally, whether all of the flagged conditions satisfy the policies for flagged conditions specified in the relevant policy file 14. If everything matches, comparison module 13 passes message 5 to the recipient at step 36. If, on the other hand, at least one identified remote link is not found in the pre-established set of acceptable domains contained within the relevant policy file 14 (or, in the embodiment in which flagged conditions are employed, if one or more of the flagged conditions is not satisfied), deletion module 15, at step 37, prevents message 5 from being sent to the recipient, i.e., message 5 is blocked or deleted.

[0029] The above description is included to illustrate the operation of the preferred embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the art that would yet be encompassed by the spirit and scope of the present invention.