Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
  • H04L63/1441—Countermeasures against malicious traffic
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/10—Office automation; Time management
  • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
  • H04L63/1441—Countermeasures against malicious traffic
  • H04L63/1483—Countermeasures against malicious traffic service impersonation, e.g. phishing, pharming or web spoofing

Definitions

• This invention relates generally to information delivery and management in a computer network. More particularly, the invention relates to techniques for automatically classifying electronic communications and web pages as phishing or non-phishing.
• Phishing often involves an unwary user being redirected, via links in an electronic message, to a web site ("pharm") run by the phisher.
• the phishing message often pretends to be from a bank. Since with email, forging the sender line is trivial. Plus, the text of the message reinforces this false impression; typically suggesting or even requiring that the user click on a link that goes to the bank, and then to login to her account.
• the visible text of the link pretends to be the bank. But in practice, the link really goes to the pharm, where the phisher has made up dummy web pages that look like the bank's pages.
• the Antiphishing Working Group (antiphishing.org) has documented a heavy rise in phishing globally, up to September 2004. Its website also furnishes examples of phishing messages and describes, or links to descriptions, of existing antiphishing methods. A reference is cited herein:
• Antiphishing Working Group antiphishing.org. "Worldwide phishing attacks originate from less than five zombie network operators", securitypark.co.uk, 19 Oct 2004.
• An Aggregator can have a hierarchy of subAggregators, that validate companies, and act to distribute the workload from plug-ins.
• a company publishes a Restricted List of its pages containing sensitive operations, like user login. This information can be used by an ISP or plug-in against links or text in a message or web page. The list can be used as a negative template. So that on another website, if pages are found similar to those on the list, it would be a strong indication of phishing.
• a phishing message that just points to a phisher's website might be detected, by spidering the website and searching for the names of various banks. If a name is found, then a comparison can be done with the bank's website.
• the bank's pages are used as a positive template, to search for a phisher mimicking them. We also search for labels of user input widgets, and compare these to a table of key words for sensitive personal data.
• FIG. 1 shows the general configuration on a computer network of various elements in our Invention.
• Fig. 1 shows the general configuration on a computer network of various elements in our Invention.
• BMEs Bulk Message Envelopes
• Amy be a phisher. Unlike writing regular non-phishing spam, Amy cannot easily insert a link to an innocent site. Firstly, this link must be valid, and not within a comment. Secondly, a phishing message tries as much as possible to be about a target, like a bank. Hence it often has several links to the bank's actual website. With often only one crucial link to Amy's website or network address. Any link to a third party increases the risk that the reader will see her message as fake.
• a cluster can arise out of one or more of the above reasons, and possibly other reasons. Further analysis can be done. We can search the DNS name registries for the owners of record of the domains, and other related data held by the registries. Clearly, if several domains are owned by the same person, then we have corroborative evidence linking those domains, separate from and independent of our clustering methods. But suppose we have different owners. Note that owner data in a name registry is not absolutely definitive. Different name registries can have different policies as to how they authenticate the name of someone who wants to buy a domain name. In fact, some name registries may have no such policy, or only a most minimal one.
• the registry might use the existence of a valid credit card as the authenticator for the name on the card. But if you pay with a postal money order, a registry might just accept that and accept whatever name and address you give to them. Keep in mind that the registries compete with each other, and with a registration fee around $US 10-20, no registry can afford to spend much effort authenticating its customers.
• Amy Plus instead of Amy submitting false owner data to a registry, she can pay others to submit real data about themselves, and have these people be the owners of record of her domains.
• Another method is to see if any of the domain owners are close to each other spatially, based on the owners' data at the registries. Some of this data might be false. But even if an owner address is false, it might give some rough geographic indication of the real owner. A style can be used here.
• any domain names in the cluster map to the same IP address. This can be extended to see if IP addresses that correspond to the domains are close to each other, in the IP address space.
• a related idea is to group the domains by the ISPs that host them. For example, suppose Amy buys two domains, giving false owner data. She still needs to find ISPs that can host them. Sometimes, there may only be one or two ISPs in her vicinity to choose from. Styles can be defined here.
• each cluster is disjoint from other clusters, ("1745") by explicit construction.
• Different clusters may be construed as belonging to different phishers.
• the number of original messages or recipients in each cluster may be used to rank the clusters. So that, for example, clusters with the most messages or number of recipients are investigated first, because these may cause the most damage.
• Another idea is to search different data for information that might link phishing clusters. This is the basic method in "1014".
• One method is to look at the non-phishing messages using the Antispam Provisionals, and form domain clusters. If a non-phishing cluster has two domains that are in two different phishing clusters, then we can associate the phishing clusters with each other. As a higher level of structure. This can be depicted as a graph, with each phishing cluster being a node, and a vertex connects two nodes if found from the non-phishing data. Plus, the weight on the vertex can be some measure of the "strength" of this association.
• it might be derived from the number of domains in one or both of the phishing clusters that are in one or more common non-phishing clusters. Or it might be derived from the number of messages received by those domains. Or from the number of users (recipients) associated with those domains.
• Amy decides not to do this, then she will not cause her phishing cluster to be linked to another phishing cluster. But for her phishing cluster not to be actually linked, all the other true owners of domains in the cluster must also refrain from spamming. If they do that, perhaps in reaction to our method, then it reduces an income source, and hence it increases the pressure on them.
• domains in this cluster might be put into some special list, that suggests possible phisher affiliation. Future messages received, that link to those domains, or purport to be from them, might be subject to other antiphishing analysis.
• Another reason for looking at the other domains in this non-phishing cluster is to find if they are being used to exploit identity information.
• One of the ways that she can establish this is to pretend to be a merchant who sells on the Internet. Hence, she might set up a domain, different from where she will point her phishing. This merchant domain will have a web site. Plus, she might send spam pointing to it, so that she can bill for actual sales and establish a track record, before phishing.
• the merchant domain might be in the cluster with her phishing domain. Or, given a phishing domain, we can take its IP address and then find any non-phishing clusters with members close to it, in IP space.
• CipherTrust released an analysis of phishing, from mail messages from many countries, in the first two weeks of that month.
• Worldwide phishing attacks originate from less than five zombie network operators", SecurityPark.co.uk, 19 Oct 2004.
• Another method is to use results from antivirus efforts. For example, if some viruses were found to be able to send data to other network addresses, then it might be useful to search for any correlations between those addresses and those of the phishers.
• phishers' domains and corresponding IP addresses
• antivirus efforts might including scanning a message or found virus, looking for the presence of the phishers 1 domains or (more likely) addresses.
• domain clusters There is also another usage of domain clusters from non-phishing messages. Suppose that from some phishing messages, the recipients get fooled and give their personal data to Amy. Suppose these involve credit cards, and Amy has a merchant domain that falsely bills the credit cards. When the credit card organization determines that these are fake, it can tell us what domain was involved. Then we can search our domain clusters and find the cluster that the merchant domain is in. The other domains in the cluster can be subject to extra scrutiny by the credit card organization, and possibly other financial or governmental organizations. (It can be seen that this is not necessarily restricted to domains involved in phishing.) This is after the fact of the initial false billing. But it does allow for pre-emptive methods against related cluster domains, that may not have yet been "activated" by her in actual fraudulent billing.
• Our organization might act in the fashion of this Invention, and as an intermediary between the ISPs and financial companies and any other companies targeted by phishers.
• a related approach is for the algorithmic methods in this Invention and earlier Provisionals to be encoded in an enterprise level software package. This might be run by an ISP. Or the package might be instantiated within a computer, as an appliance that could be installed at an ISP. Or, indeed, at any organization that receives electronic messages. If such appliances were to be deployed, they would send results to their host companies, and also to our central analysis organization, if it existed.
• Kappa gathers this data - (sender address,base domains, "few” value, hash), and stores it in a database or sends it to some other program, Gamma, which is associated with the bank's implementation of the methods in "2458". Kappa also sends Costas' message, with its addition of the tag, to the mailer program that handles outgoing mail.
• the value of "few” is not necessarily a unique identifier of the message. It could be unique for a given combination of sender address and set of base domains. So if Costas were to send a different message, that had the same base domains, then the previous value of "few” could be reused here. This is in contrast to any method that makes an id using a message body as part or all of the input.
• the listening service gets the tag, finds the "few” variable and hence sends the tag, plus any associated information from Lucy, like the domains, to a process or program, that might be called Gamma. That program then compares any uploaded domains to the above approved list that Costas made. If there are any not on the list, then it returns "no" to Lucy's plug-in, which will not validate the message. If the plug-in did not upload any domains, then Costas' list is downloaded to the plug-in, which then makes the comparison. If a hash identifies the message, then this might be sent to the plug-in for comparison with the hash found by the plug-in from the received message.
• Gamma need not be distinct from the listening service. Such implementation details are irrelevant to the gist of this method.
• the plug-in could send this query to an Aggregator.
• the plug-in should communicate directly with the bank. It reduces the amount of information that an Aggregator needs to handle. Plus, given the possibly sensitive nature of the original message (as opposed to a mass mailing), it is safer that only two parties be involved in this conversation. Less chance for a phisher or other hostile entity to intervene.
• the plug-in might have a policy that it will not validate a message with this tag, if it contains a form.
• the reason is that phishers often have 2 ways to get users to submit their information.
• the message might look like it is from BankO, and contains a form for the user to fill in and then press submit, which sends the information to the phisher, and not the bank.
• the other way is with a hyperlink to the phisher's web site, which looks like BankO.
• some banks have taken to warning customers not to fill out any forms in messages purporting to be from them. Instead, the customers should only fill these out on the web site of a bank.
• the plug-in could relay this page to Sarah's ISP or to our central aggregation service, or to the authorities. (The plug-in might ask Sarah for permission to send out her message, first, if the page contains a message sent to her.)
• the plug-in could run an extensive analysis of the page. This can involve the methods of the Antispam Provisionals. Plus, it could use other methods, like Bayesians and artificial intelligence. Typically, such analysis is too computationally intensive to run on every page or message that Sarah looks at. But for a suspected fraud, she might want to see the results of such an analysis. (Some of this analysis may be language specific.)
• the plug-in would change state. Plus, it could upload the page, as before.
• the plug-in could also allow her to add a comment, as to why she thinks it is bad.
• Provisional "2458" described a single Aggregator. But there could a hierarchy of these. If the methods of our inventions become widely adopted, then there is incentive for many midlevel or small businesses to want to register with an Aggregator, so that their outgoing messages can be validated. But this registration should entail non-trivial checks on the applicant. Because there is a risk that a phisher might form an ostensibly respectable business, and then have it apply at an Aggregator. If the phisher then gets on the Aggregator's list of reputable companies, she can send out tagged messages that will validate at the plug-ins.
• a subAggregator could charge a merchant for its audit, and pass a portion of this to its parent.
• a subAggregator may assume some liability for the merchants it approves. Which is part of the justification for the fee it levies.
• SubAggregators can also have another role. When a plug-in contacts an Aggregator or subAggregator, then that might redirect it to a subAggregator for its region. This helps make the query methods scalable on a global basis. Then, subsequently, the plug-in can default to that subAggregator. This follows the general idea of the Internet's Domain Name Service, and the global hierarchy of DNS servers.
• the global Aggregator may decide to have a validation criterion that companies that are widely known and already validated by some external agency or body, would be validated by it. For example, the top 400 or 500 industrial companies in the US, and similar groups in other major countries. But because subAggregators might deal with much smaller companies, the validation process should be rigorous. Specifically, it needs to be far stricter than the process of registering a domain name.
• a subAggregator might also interact with ISPs in the fashion of the Aggregator.
• Phishing is a global problem. But those methods might not be deployable globally, for the reasons outlined above.
• PL Partner List
• Provisional "2458" then expanded this to the desktop by having a plug-in, which looks for a certain tag (which we call ⁇ notphish>). So that our analysis could be applied to web pages as well as messages. If the tag was present, the analysis would then describe the page as valid or invalid. But if the tag was not present, then no analysis would be done, and the plug-in would then indicate this as a default "tag missing" state.
• BankO with its base domain of bankO.com. It can construct a "Restricted List". This is a list of domains, or URLs or URIs, or some other network addresses, where for all of these, it owns those addresses. The intent is at these addresses are web pages or assets (like image files), for sensitive operations, like a user logging into her account. If the address is a domain, it does not have to be a base domain. For example, it might be login.bankO.com.
• BankO can then send these in any fashion, electronic or otherwise, to an Aggregator or ISP. It can also make this information queryable programmatically from its web site. So an Aggregator or ISP or plug-in might make a query and then obtain the Restricted List.
• L be the set of links
• B be the set of base domains.
• X be the set of base domains of important companies, which presumably includes bankO.com. X is independent of the web page under scrutiny.
• the plug-in has X held locally. Then it sees if any member of B is in X. If none, then it ends the analysis of the page. Else, it asks an Aggregator for the Restricted Lists belonging to (B intersect X). Call this Y. Of course, it might already have some or all of these lists, based on earlier activity. In this case, it might only ask the Aggregator for Restricted Lists that it does not already have. If the plug-in does not have X, then it might send B to an Aggregator. Who would then reply with the Restricted Lists belonging to (B intersect X).
• the plug-in has Y. If all the domains, or possibly entire links, in L are in Y then the plug-in can classify the page as having a warning level MildWarning, which is different from, and less severe than the Invalid classification for a page with a ⁇ notphish> tag.
• MildWarning MildWarning
• the plug-in can change its visual representation. For example, if Invalid is shown as red, then MildWarning might be some lighter shade of red, and WorseWarning be some shade intermediate between the two.
• WorseWarning and red to be invalid, and all lights off to be the default.
• the plug-in button when it is yellow, it might show a pop up window with information as to whether the page has a MildWarning or WorseWarning.
• An advantage of using traffic light colors relates to the observation that phishing tends to target the inexperienced or less educated users. More easily fooled. The choice of the traffic lights can be so intuitive that such users could especially benefit from it.
• a plug-in has some aural representation, then it might choose different sounds, but related in some way that users might find intuitive.
• the ISP finds that a message has a MildWarning or WorseWarning, it can do special steps. For example, it might write a header line giving the warning level. Of course, if it finds the message to be Invalid, then it can also do this. Then, any client message viewing program that downloads messages from the ISP can use this header line to apply special treatment to the message. For example, the viewer might have an Inbox and a Bulk folder, where the latter is meant for spam. Our header now lets the viewer have more folders, for example. Perhaps one for each negative state.
• the ISP might also apply further analysis. Possibly as a result, it might forward some such messages to the authorities or banks in question.
• Restricted Lists give more protection to banks and other companies.
• a bank can segregate the sensitive places in its website into specific addresses, that few outsiders should be linking to, in messages or web pages. This is distinct from its home page, or pages with purely informational content. News articles or indeed anyone commenting on the bank might well link to these pages.
• our method prevent anyone from linking to the the Restricted List. But it provides a classification that can help reduce the chances of a casual user been defrauded.
• the Aggregator can search any Partner Lists submitted to it by companies that are already registered. It has a core list of major financial institutions and other large companies. Call this list T. If a list submitted by a company not in T includes any companies in T, then the Aggregator can submit the list to those companies for approval. This can be done in a programmatic fashion. Alternatively, T might be the entire set of companies registered with the Aggregator.
• WS Web Services Description Language
• a document might be some combination of data and instructions.
• WSDL there is provision for a document to be authenticated by various methods. Typically, the authentication might be of the entire document, or precisely defined subsets. In any event, the methods are invariably computationally intensive because of the complexities of the authentication methods.
• the crucial elements might be links, incoming or outgoing. Where an incoming link might mean get some data from that address. While an outgoing link might mean send some data to that address.
• the program tells the program to go to an Aggregator and find the WS Partner List for bankO.com. In general, this might be different from the Partner List for messages or web pages.
• the query from the program to the Aggregator might include a flag that indicates a WS context.
• the program gets a WS Partner List from an Aggregator, it may cache this, to speed up processing the next time it gets a document purporting to be from BankO. It might also register itself with the Aggregator, so that the latter can send any changes to this list. Or it could periodically poll the Aggregator for any changes.
• a WS program might require that its input documents contain a ⁇ notphish> tag. It will not process documents lacking the tag. Otherwise, with such a tag, if any links in the document are not in the WS Partner List, the document is considered invalid, and will not be processed.
• the Partner List may contain a specific set of allowed addresses, from which queries can come from.
• a Restricted List can be used in WS along similar lines.
• our methods also have an advantage over methods that may lead to banks (and other companies) using them running a risk of liability.
• a bank may use a method that forces the customer to perform extra validation steps, when the customer contacts the bank via the Internet and wants to transfer money to a merchant. But in some jurisdictions, this may expose the bank to some liability for losses.
• our methods do not intervene during any actual financial transaction steps.
• our methods are strictly advisory. Even if the plug-in were to turn off suspect links in a suspect web page or message, say, this is a policy setting of the plug-in that the user can change.
• Partner Lists to verify the other links in the message. This is a limited case, because the phisher cannot link to a bank, or have a sender address at a bank. Hence, in and of itself, this case should be less likely to fool users. So even if the methods we describe below are not applied, forcing phishers to congregate here should significantly reduce losses by banks.
• the message has a form for the user to input personal data, and the submit button of the form sends it to the phisher's website.
• the analysis below of the phisher's website can also be applied to this message.
• Amy be the phisher. Let us assume that the message only has one image. Though in general it could have several. The targeted company is taken to be a bank, though it could be other types of companies. Let BankO be one of these banks, with a domain or bank0.com. We take the recipient's viewing program to be a browser, though it could be any other program capable of showing a hypertext message, and following links in it.
• the image contains some text, purporting to be from a bank, and urging the recipient to click on the link in order to enter some of her information.
• the logic might include scrutiny of any text in the message, that is not in the images. This could involve language-specific methods.
• the text search might use the anti-obfuscation techniques of "1745" and "1622". For example, if the phisher were to put random tags, in order to break up a word, we would remove these. So "B ⁇ other>an ⁇ random>kO" would become “BankO". Or if some characters were written as hexadecimal, we would undo these, before searching for any bank names. Or if Amy were to write invisible text, then we would remove it.
• amydomain.com amydomain.com
• the spider can search for various heuristics. As discussed above, it can look for the names of banks. We assume that Amy is impersonating BankO at her web site. So her web pages should contain several references to BankO. Plus, the pages might mimic the visual appearance of BankO's actual website. Therefore, before all this analysis, we can cache the websites of the banks who are using our methods. Then, when we detect "BankO" in Amy's web page, we can compare that page with BankO's actual pages.
• Amy Another technique that Amy might employ is changing the format of a copied image.
• a BankO image that is in the GIF format.
• One countermeasure we could adopt is that we might store copies of banks' images, but converted to some common format, like GIF.
• GIF some common format, like GIF.
• From Amy's website we convert images to GIF if they are not already in this format, before making a comparison with our stored images.
• the interconnection topology of Amy's website can be compared with BankO's website. Plus, the topology of Amy's website and any outside websites that it links to, can also be compared to BankO's website. This can account for the possibility that Amy may be controlling several websites.
• this style might be held as a boolean, and set true if at least one such token is found near an input widget. Quicker to compute, but lacks a potentially useful measure of how many such items there are in a page.
• Amy might replace the labels with images of text. If we see any such images, near or next to input widgets, then we might increment an integer style, NumlmageLabels, for that page. We might treat this as very suspicious, given that it is far simpler to write text into a label than to make an image of text and then use it in the label. If desired, we might also apply the methods of Optical Character Recognition to the images, to try to find the text presented by them, and with any such found text, to check these against a list of key words. In such a case, we might apply any weightings for those tokens, as was suggested for NumKeyWords.
• our method of this Invention can also be used without necessarily starting from a set of messages.
• the input might be a set of addresses (base domains, URLs, URIs%) to which we apply our method. So if we imagine an implementation of our method as an appliance (hardware or software), then as such, it can have use by other applications which need some addresses to be investigated for phishing.
• Another application might be a general purpose search engine. It could be programmed to periodically search for BankO. (That is, it has a list of large banks, and it does this for all entries in that list.) In the search results for BankO, it might take the top 50, say. From these, it removes any that point directly to BankO's base domain, or other base domains that BankO might own. (The search engine can have already obtained this information from BankO.) But for any remaining results, it might then send these addresses or base domains to our method. The search engine is looking for any websites that might be manipulating its ranking algorithms to present themselves as BankO. When the search engine is Google Corp., this is sometimes known as "Google bombing".
• search engine may have extensive coverage of the web, and enough technical expertise, so that it is more economical for a bank to outsource this task.
• an Aggregator as we have described in the Antiphishing Provisionals, might perform this as a regular service for the banks.
• Another application might be a website specializing in financial matters that lets its readers write comments, perhaps in the style of a blog. If the website shows these comments, in such a way that any links in a comment can be selected, then it may want to guard against Amy directing readers to her website, while posing as BankO. So the financial website might run our application automatically as a filter on user submissions, and reject any that fail our method.
• Another application might be an ISP or any other organization using our Antispam Provisionals, and finds groups (possibly clusters) of spammer domains. These domains might be input into our method to find any phishing websites.
• Another application might be an antivirus company that finds network addresses in viruses. If the virus appears to be capable of sending information to an address encoded in it, then this address might be searched with our method. This is especially useful because of the discovery that many phishers send out viruses to take over computers, and use those in phishing, in part as destinations referred to in messages.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Business, Economics & Management (AREA)
• Computer Hardware Design (AREA)
• Human Resources & Organizations (AREA)
• Entrepreneurship & Innovation (AREA)
• Strategic Management (AREA)
• Computer Networks & Wireless Communication (AREA)
• General Engineering & Computer Science (AREA)
• Signal Processing (AREA)
• Computing Systems (AREA)
• Operations Research (AREA)
• Economics (AREA)
• Marketing (AREA)
• Data Mining & Analysis (AREA)
• Quality & Reliability (AREA)
• Tourism & Hospitality (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Information Transfer Between Computers (AREA)

Applications Claiming Priority (6)

Publications (2)

Family

ID=36203315

Family Applications (1)

Country Status (1)

Cited By (4)

• 2005
  • 2005-10-24 WO PCT/CN2005/001751 patent/WO2006042480A2/fr active Application Filing

Also Published As

Similar Documents

Legal Events