PHONEY: Mimicking User Response to Detect Phishing Attacks

Size: px

Start display at page:

Download "PHONEY: Mimicking User Response to Detect Phishing Attacks"

Vernon Anderson
5 years ago
Views:

1 PHONEY: Mimicking User to Detect Phishing Attacks Madhusudhanan Chandrasekaran Ramkumar Chinchani Shambhu Upadhyaya Department of Computer Science and Engineering University at Buffalo 201, Bell Hall, Buffalo, NY {mc79, rc27, Abstract Phishing scams pose a serious threat to end-users and commercial institutions alike. continues to be the favorite vehicle to perpetrate such scams mainly due to its widespread use combined with the ability to easily spoof them. Several approaches, both generic and specialized, have been proposed to address this problem. However, phishing techniques, growing in ingenuity as well as sophistication, render these solutions weak. In this paper we propose a novel approach to detect phishing attacks using fake responses which mimic real users, essentially, reversing the role of the victim and the adversary. Our prototype implementation called PHONEY, sits between a user s mail transfer agent (MTA) and mail user agent (MUA) and processes each arriving for phishing attacks. Using live data collected over a period of eight months we demonstrate data that our approach is able to detect a wider range of phishing attacks than existing schemes. Also, the performance analysis study shows that the implementation overhead introduced by our tool is very negligible. 1. Introduction The Internet is playing an increasingly significant role in today s commerce and business activities. Unfortunately, poor security on the Internet and large financial gains provide a strong motivation for attackers to perpetrate such seemingly low risk, yet high-return online scams. In the year 2004 alone, an estimated 20 million phishing s were sent out, resulting in nearly 10 billion dollars in damage [1]. Most of the phishing attacks are carried out by sending large volume of clearly crafted s posing to originate from a legitimate business domain. These messages are intended for redirecting the recipients to a masqueraded website, which manifests the same behavior of a legitimate domain, for tricking the users to reveal their financial information. Although spam filtering techniques can be employed to combat phishing s, these countermeasures are not entirely effective as there are a vast number of readily available tools that can bypass both the statistical and rule based spam filters. Also, phishers can choose the recipients via social engineering mechanisms. In this paper we propose a novel framework called PHONEY for automatic detection and analysis of phishing attacks. The key idea behind our framework is to protect identities of the end-users by providing fake information to the websites requesting critical information until the site s authenticity has been verified. Here, we leverage on the premise that just as an end user cannot tell legitimate and spoofed s apart, similarly phishers cannot tell the responses of legitimate and phantom user responses apart. Victim Internet Adversary Legitimate Figure 1: Defense-centric view: Who is the real sender - legitimate or adversary? Our framework views phishing as a two-stage game between the user and the adversary. In the first round, the attacker sends messages pretending to represent a legitimate business domain for tricking the users into divulging their personal information. The success of the attack lies in the phisher s ability to craft the attack in a manner that a naive user is unable to differentiate between the legitimate and the masqueraded messages, as shown in Figure 1. For the second stage, PHONEY analyzes the incoming message content for the presence of embedded links and attached HTML forms. If the contains no such signa-

2 ture traits, further investigation is safely discarded. Otherwise, a set of phantom users or fake identities are assigned to actively communicate with these websites with appropriate random values as shown in Figure 2. The random/fake information supplied to the websites acts as active honeytokens [2], and the websites responses are forwarded to the decision engine for further analysis. The key idea here is to shield the user from giving out critical personal information until the authenticity of the website is verified. Since the attacker can not distinguish between the fake and legitimate responses, his response is the same to both real and contrived responses. As our further contribution, we evaluated and tested PHONEY on 20 different phishing s assimilated over a period of eight months. Since spoofed websites are ephemeral, live testing against such websites is difficult. Therefore, for the purpose of testing our framework, we duplicated some of these attacks by hosting the spoof websites on our internal web server. Also for the evaluation, we give out the performance overhead incurred by PHONEY. Real/Phony Users Internet Adversary Figure 2: Offense-centric view: Who is the real respondent - the real victim or a PHONEY? The rest of the paper is organized as follows. We present the related work in Section 2, where our approach is compared with other existing techniques. An overview of the PHONEY architecture and the design details are presented in Section 3. In Section 4, we show the performance results of our framework along with the detection and false alarm rates. The shortcomings of our approach are listed out in Section 5. Finally, closing remarks are made in Section 6. 2 Related Work There are only a few research efforts that focus entirely on tackling the problem of prevention of phishing attacks. Phishing s are often related to spam and most of these techniques target spam control as a mechanism to prevent such identity theft scams. In this section we briefly review and compare these approaches to put our work in perspective. 2.1 Browser Plug-ins and Anti-Phishing Toolbars Several commercial and open source toolbars have been proposed to protect the users from phishing attacks. Most of these techniques perform static checking of the visited webpages and URLs for detecting the phishing attacks. Spoofstick [3] is a widely used tool that performs reverse DNS lookup on the visited website, for the purpose of displaying the IP address of the visited site on the browser s toolbar. Although this information can be used to separate legitimate and masqueraded websites, it still necessitates human-inthe-loop to make the actual decision. NetCraft anti-phishing toolbar [4] employs distributed decision mechanisms, that relies on its client s majority vote to infer a website s validity. The websites tagged malicious by its subscribed clients are scrutinized, and the result is disseminated among other subscribed members in the form of blacklists. As this technique relies on users feedback for its decision making, it may be subject to increased false positives and denial-ofservice (DoS) attacks, especially in cases where a group of hackers maliciously frame a legitimate website malicious. Also, since the masqueraded websites are short-lived, it is highly unlikely that such responses are propagated to the clients before their lifetime. SpoofGaurd [5] is another technique which examines the downloaded website using various stateful and stateless evaluations like checking for invalid links, URL obfuscation attempts etc. The major disadvantages with these approaches is that they are susceptible to attacks launched from the compromised legitimate website. Also, in many web hosting domains the attacker could create a user account with the name login and launch a successful phishing attack by hosting the masqueraded page in his domain space, which typically would appears as com/login, thereby circumventing aforementioned approaches. It is worth mentioning that a similar attack on Geocities was accidentally discovered by one of the authors, who reported the incident to the authorities. Other security protocol based techniques [6, 7] have been proposed, which require substantial modifications to be made on the existing server-side infrastructure, for their normal functioning. 2.2 Cryptography Based Techniques Key distribution and identity based digital signatures have been proposed to make messages trustworthy [8]. S/MIME, PGP [9] and GPG [10] are popularly adopted standards for digitally signing messages which are supported by most of the GUI mail clients. As these methods encrypt the outgoing s along with the sender s identity, it makes them resilient to spoofing. However at this point, not all web-based mail clients like Yahoo!Mail, Hotmail, Gmail support S/MIME. In the case of PGP/GPG schemes, as there is no central authority server which could verify the s, a phisher may infiltrate the web of trust and digitally sign his s. Also, another drawback of this approach is that it necessitates that both the sender and the receiver have the compatible infrastruc-

3 MTA Preliminary Processing Does contain URLs, forms, etc? Content Scanner Semantic analysis of suspicious content hashdb Dynamically generate phoneys? Phishing attack or not? MUA Figure 3: Block diagram of PHONEY architecture ture to support digital signing and verification. Smartcards and one-time passwords can be used to prevent phishing scams, but these approaches incur high set-up and management costs, and are not robust and scalable. 3 Overview of PHONEY In this section we give an overview of PHONEY s architecture and its various components. 3.1 Architecture Figure 3 illustrates the architecture block diagram of PHONEY. As mentioned in Introduction, the core idea behind our framework is that as an user cannot distinguish between the legitimate and the malicious s, similarly the phisher cannot separate the responses of a legitimate user and the phantom user apart. PHONEY is deployed as a client side tool between the mail server and the mail client to detect and mitigate based phishing attacks. The working of PHONEY is as follows: First, the preprocessor probes the mail server for incoming messages. Once the mail arrives, it parses the messages body for embedded links and HTML forms. s with HTML forms requesting critical information are tagged malicious. In the presence of embedded URLs, the control is passed to the content scanner which then retrieves the source of the referred web page for its analysis. The webpage with input forms are broken down further to extract its input element and its associated text. These extracted tokens are then compared against the entries in hashdb (see Figure 3) for the presence of fields with names as username, password, credit card numbers, social security number, password etc. Each tuple in the hashdb has two fields representing the token name along with its fake value. Depending on the information required to be sent out, the values corresponding to the tokens in the hashdb are supplied to the phantom users during the time of their instantiation. The phantom users are virtual entities, primarily created for the purpose of interacting with the malicious website. They interact with the website by sending the requested information in the form of active honeytokens. The behavior of the website to the honeytokens is recorded and analyzed for any activities not conforming to reasonable response. The decision engine is formalized as a rule based system, which relies on set of pre-determined propositions and inference rules to deduce whether the process has terminated in any of the known attack instances. 4 Case Studies To illustrate the efficacy of our proposed mechanism, we have evaluated our tool against 20 different phishing s. Twelve of them contained links to masqueraded websites which were live at the time of testing. Of the remaining eight s, three had links to websites that had been taken down before our tool could actually test them. For the sake of exhaustiveness, we replicated five interesting attacks recorded at the site. In order to measure the false positive rates, our tool was tested against s containing embedded URLs of legitimate domains. Based on the tests, we show that PHONEY was able to successfully detect all based phishing attacks with zero false alarms. Also, to our best knowledge we can boldly claim that PHONEY can detect all based attacks listed on the archive. For illustrative purposes, we also show three different scenarios which exemplify the working of our tool. Here, the interaction between the phantom user and the phisher s website is captured by hooking the detection engine, as an ActiveX control in Internet Explorer. 4.1 Example 1 In the first example, we look at a simple based phishing attack against the Regions bank. First, the phisher sends an in HTML format, requesting the users to verify their account data by following the embedded link. Here, the visible link in the " EBanking/logon/user?a=defaultAffiliate" masks the reference to the phisher s website: http: // Such attacks can be easily determined by the preprocessing

escaping detection, such cases can be disastrous from the phisher s standpoint as it may invoke suspicion in the users if they are consistently denied access.

Also, to further validate our claim, the phisher s website is supplied with fake information.

4 escaping detection, such cases can be disastrous from the phisher s standpoint as it may invoke suspicion in the users if they are consistently denied access. Figure 4: Phantom users supplying fake login information to the spoofed website engine as shown in Figure 4, which relies its decisions based on such noticeable differences. Also, to further validate our claim, the phisher s website is supplied with fake information. Upon automatic submission of fake authentication values as shown in Figure 5, the site predictably refers to a page asking credit card related information, thereby triggering our tool to raise an alarm. As most of the observed based phishing scams adopt similar attack model, PHONEY can trivially detect such kind of attacks. 4.2 Example 2 In the second example we show the working of PHONEY on an mimicking ebay website. The had a URL which redirected the users to the phishing website There were two noticeable differences in this phishing site: (a) This site attempted to spoof its URL as a legitimate site using a IE vulnerability. On our test machine, this spoofed URL was clearly detected since the machine was patched. (Note that this was NOT the basis for PHONEY detecting this site to be dangerous. Since our testing relies on the evaluating response of the spoofed website, it is reasonable to assume that our framework is effective even if IE was unpatched). (b) Also, the behavior of this site was different from the other cases. Upon submission of any value, the user was asked to enter his/her information again. Only when the submission was made a second time in the same browser session the user was directed to another page asking for more information. This is an excellent social engineering tactic where the phisher assumes that the naive user on receiving an about account suspension would hastily type in wrong credentials. PHONEY can be tuned to repeated test to ensure correctness. Though an attacker can replay the same strategy by not allowing the user to login for a repeated number of attempts, therefore successfully Figure 5: The detection engine flags the website malicious 4.3 Example 3 The third example is to show the working of our system against s that are received from the legitimate domains. Here, we test our tool with an containing a URL referring to the hotmail login page. Though our tool correctly identified this to be a legitimate , there are two caveats in hotmail. Usually, when users type in their user name in hotmail and move to the password field, a script automatically fills in However with PHONEY, no such action happens. Hence the result of submitting contrived values pops up a Java script box asking for the information to be entered again. Our tool nevertheless detects that fake inputs lead to the same behavior and infers that this is a legitimate site. We again would like to note in passing, that it is trivial to maintain a list of such domains to appropriately fill in random values. While being able to detect legitimate domains correctly, it is possible that an attacker launches denial-of-service attacks by sending s with URLs of real domain. Though this poses a serious threat, during real time deployment we can force the traffic through our own servers, which maintain the list of all the tested websites, thereby eliminating the need to test for previously tested domains. 5 Evaluation An evaluation of our tool was conducted to quantify the performance overhead incurred during detection. The overhead introduced by our detection system highly depends upon two parts: (a) phantom user instantiation overhead; (b) response analysis overhead. We performed our experiments on an Intel Pentium M, 1.3 GHz processor with 512Mb RAM. The five attacks illustrated in the www.

5 antiphishing.org s archive were replicated on an Intel Pentium GHz processor running Apache HTTP Server version The operating system is Redhat linux running kernel version We also benchmarked the execution time of each of the PHONEY s subcomponents, using auditing scripts. 5.1 Phantom user instantiation overhead The overhead involved in instantiation of phantom user is the aggregation of time taken by the preprocessing component plus the time needed to extract fake values from the hashdb. The overhead caused here is mainly due to file I/O, while flooding the phantom user with appropriate type fake values. But since the number of distinct fields stored are small in number, the entire hashdb file can be loaded into memory during start of execution, thereby reducing the overhead. Instantiation of phantom users, on an average took 1.2 secs with a standard deviation of 510 msec for its operations. 5.2 analysis overhead The total time taken by the response analysis subsystem is the time taken to post the response of phantom users plus the time taken for analysis. The average delay time because of response analysis was 2.35 secs with an exception that, the links whose website didn t exist took far longer because of the time out policy. From our observations, we can safely conclude that our detection framework does not introduce any significant computation overhead in the system. Also, the modular nature of the individual subcomponents provides hooks to replace existing modules with efficient variants, without affecting the overall performance. 6 Limitations The approach described in this paper has a few limitations. First, if this tool is widely adopted, the phishers can circumvent the given defense mechanism by replaying the response of the legitimate site for spurious inputs. However, such behavior is disastrous from the phisher s standpoint, as it may invoke suspicion in users, if they consistently observe invalid data error despite providing authentic information. Second, phishers can include robot detecting schemes like CAPTCHA (completely automated public Turing tests to tell computers and humans apart) in their websites to subvert the tool s effort to enact the responses of the legitimate users. Currently, this is not a problem, as CAPTCHA is widely used for preventing automated registration rather than user validation. Finally, there might also be legal ramifications of our tool consuming the sites bandwidth and computation power for its detection purposes. Though the traffic can be contained by the use of distributed lists, like web crawlers they also should operate with caution, to not violate any website s terms of usage. 7 Conclusions and Future Work In this paper, a novel anti-phishing framework for detecting based phishing attacks has been presented. The described approach adopts an offense centric technique to detect phishing attacks by using fake responses which mimic the real users, essentially, reversing the role of the victim and the adversary. The evaluation of the tool showed that our approach is able to detect a vast majority of the attacks, including cases where the masqueraded page is launched within the legitimate domain with no false positives. There are two main avenues which we are actively pursuing as a part of our ongoing and future work. First, we are investigating ways to differentiate the responses of the phisher and the legitimate websites via server side assistance. Though, at the current stage our tool does not require any change to the server side domain, the server side assistance can possibly increase the accuracy of our detection engine by eliminating the need of human in the loop. Finally, after satisfactory maturity, we are planning to release our tool as a browser extension to mitigate web based phishing attacks. References [1] D. Illett. Phishing attacks skyrocket in html, [2] L. Spitzner. Honeytokens: The other honeypot. July [3] Spoofstick toolbar. [4] Netcraft Anti-Phishing Toolbar. [5] N. Chou, R. Ledesma, Y. Teraguchi, and J. C. Mitchell. Client-side defense against web-based identity theft. In NDSS, [6] R. Dhamija and J. D. Tygar. The battle against phishing: Dynamic security skins. In SOUPS 05: Proceedings of the 2005 symposium on Usable privacy and security, pages 77 88, New York, NY, USA, ACM Press. [7] M. Jakobsson. Modeling and preventing phishing attacks. In Phishing Panel of Financial Crytography, [8] S. H. Ben Adida and R. Rivest. Fighting phishing attacks: A lightweight trust architecture for detecting spoofed s. Feb [9] S/MIME and Openpgp. [10] The GNU Privacy Gaurd.

Review of Phishing Detection Techniques

Review of Phishing Detection Techniques Swati Gaikwad Computer Engineering, DACOE, Pune, India. swatigaikwad0385@gmail.com Abstract Nowadays phishing attacks are increasing with burgeoning rate which is