Know your Enemy: Phishing

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.

Introduction

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:

Sector 4G9E of our data base has lost all I/O functions. When your account
logged onto our system, we were temporarily able to verify it as a
registered user. Approximately 94 seconds ago, your verification was made
void by loss of data in the Sector 4G9E. Now, due to AOL verification
protocol, it is mandatory for us to re-verify you. Please click 'Respond' and
re-state your password. Failure to comply will result in immediate account
deletion.

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.

Tools and Tactics

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:

Using IP addresses instead of domain names in hyperlinks that address the fake web site. Many innocent users will not check (or know how to check) that an IP address is registered and assigned to the target organisation that the branded fake web site claims to represent.

Registering similar sounding DNS domains and setting up fake web sites that closely mimic the domain name of the target web site (i.e. b1gbank.com or bigbnk.com instead of bigbank.com), in the hope that users will mistake the fake domain name for the real domain name.

Embedding hyperlinks from the real target web site into the HTML contents of an email about the fake phishing web site, so that the user's web browser makes most of the HTTP connections to the real web server and only a small number of connections to the fake web server. If the user's email client software supports auto-rendering of the content, their client may attempt to connect automatically to the fake web server as soon as the email is read, and manual browsers may not notice the small number of connections to a malicious server amongst the normal network activity to the real web site.

Encoding or obfuscating the fake web site URL. Depending on the method employed, many users will not notice or understand what has been done to a hyperlink and may assume it is benign. One variant of this technique (IDN spoofing) is to use Unicode URLs that render in browsers in a way that looks like the original web site address but actually link to a fake web site with a different address.

Attempting to exploit weaknesses in the user's web browser to mask the true nature of the message content. Microsoft's Internet Explorer and Outlook applications have been particularly vulnerable to such techniques (such as the address bar spoofing or IFrame element bugs).

Configuring the fake phishing web site to record any input data that the user submits (such as usernames and passwords), silently log them and then forward the user to the real web site. This might cause a "password incorrect, please retry" error or even be totally transparent, but in either situation many users will not be overly worried and put this event down to their own poor typing, rather than intervention by a malicious third party.

Set up a fake web site to act as a proxy for the real web site of the target brand, covertly logging credentials that are not encrypted using SSL (or even registering valid SSL certificates for spoof domains).

Redirect victims to a phishing web site by first using malware to install a malicious Browser Helper Object on their local PC. BHOs are DLLs designed to customize and control the Internet Explorer web browser, and if successful, victims can be tricked into believing they are accessing legitimate content when in fact they are accessing a fake web site.

Use malware to manipulate the hosts file on a victim's PC that is used to maintain local mappings between DNS names and IP addresses. By inserting a fake DNS entry into a user's hosts file, it will appear that their web browser is connecting to a legitimate web site when in fact it is connecting to a completely different web server hosting the fake phishing web site.

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.

Real World Phishing Techniques

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.

Phishing Technique One - Phishing Through Compromised Web Servers

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:

Attackers scan for vulnerable servers

Server is compromised and a rootkit or password protected backdoor installed

Phishers gain access to the server through this encrypted back door

If the compromised server is a web server, pre-built phishing web sites are downloaded

Some limited content configuration and web site testing is performed (potentially revealing the phisher's true IP address when they first access the web server)

Mass emailing tools are downloaded and used to advertise the fake web site via spam email

Web traffic begins to arrive at the phishing web site and potential victims access the malicious content

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:

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):

[image:images/HTTP%20access.JPG size=full]

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.

Phishing Technique Two - Phishing Through Port Redirection

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.

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).

Phishing Technique Three - Phishing Using Botnets

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.

Incident Timeline

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.

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:

harvest.emails - "makes the bot get a list of emails"

harvest.emailshttp - "makes the bot get a list of emails via HTTP"

spam.setlist - "downloads an email list"

spam.settemplate - "downloads an email template"

spam.start - "starts spamming"

spam.stop - "stops spamming"

aolspam.setlist - "AOL - downloads an email list"

aolspam.settemplate - "AOL - downloads an email template"

aolspam.setuser - "AOL - sets a username"

aolspam.setpass - "AOL - sets a password"

aolspam.start - "AOL - starts spamming"

aolspam.stop - "AOL - stops spamming"

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.

Example 1

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:

A URL for a file that contains several email addresses.

The web page to target within the spam email - this could be a normal spam web-page or a phishing web site.

The name of the sender.

The subject of the email.

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.

Example 2

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.

Example 3

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.

Common Themes

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.

Mass Scanning

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.

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.

Combination Attacks

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:

[image:images/phishing-setup.png size=full]

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:

If the compromise of one of the remote redir hosts is detected, the victim will probably take the system offline and re-install it. This does not represent a major loss for the phisher because the main phishing web site is still online and several other redir hosts continue to deliver HTTP traffic to the central web server.

If the compromise of the central phishing server is detected, this system will also be taken offline. Now the phisher can simply set up a new phishing site on a freshly compromised system and then re-adjust the existing network of redir hosts to redirect traffic to the replacement central host. Using this technique, the whole network can be made available very quickly and the phishing attacks can soon recommence.

A redir host is very flexible, since it can be easily reconfigured to point to another phishing web site. This decreases the time between initial system compromise and phishing web site availability, and increases the length of the attack window in which the phishing attacks can be performed.

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.

Further Observations - Fund Transfer

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:

Hello!
We finding Europe persons, who can Send/Receive bank wires
from our sellings, from our European clients. To not pay
TAXES from international transfers in Russia. We offer 10%
percent from amount u receive and pay all fees, for sending
funds back.Amount from 1000 euro per day. All this activity
are legal in Europe.
Fill this form: http://XXX.info/index.php (before filling
install yahoo! messenger please or msn), you will recieve
full details very quickly.
_________________________________________________________

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.

Honeysnap - An Incident Analysis Assistant

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.

Further Research

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.

Conclusions

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:

Appendix

Additional Informations

Background on Phishing Attacks

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:

[image:../images/targets.PNG size=full]

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 MessageLabsreported 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:

[image:../images/phishing-mails.PNG size=full]

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.

Detailed analysis of two phishing incidents

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 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.

Attacker returns to set up phishing web sites and sends out spam mails (blocked by Honeywall)

08/12/04

11:30 AM

Honeypot disconnected for forensic analysis

A more detailed incident timeline, including an analysis of the tools and techniques the attackers used, is available here.

Setup and Timeline for UK Honeynet Project Phishing Incident

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.

[image:uk-honeynet_files/image001.jpg size=full]

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.

Phishers arrive through back door set up by initial attackers and set up phishing website

23/08/04
09:23 PM

First web traffic arrives at web server for phishing site

27/08/04
09:30 AM

Honeypot disconnected for forensic analysis

A more detailed incident timeline of the UK phishing incident can be found here and more detailed analysis, including an analysis of the tools and techniques the attackers used, can be found here.

Details of German compromise

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.

At1: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:

/usr/bin/dir

/usr/bin/top

/bin/ps

/sbin/ifconfig

/usr/bin/slocate

/usr/bin/pstree

/bin/netstat

/usr/bin/vdir

/usr/bin/socklist

/usr/bin/strings

/usr/bin/chattr

/usr/sbin/lsof

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

For both input fields (username and password), the input must be longer than one character. Note the use of the strings $mesaj and $muie, which suggests a Romanian connection and have been observed in other incidents analysed by members of the UK Honeynet Project. If the input is okay, it will be written to the file /tmp/User.doc and 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:

After downloading the test.txt file which contained 3719 e-mail addresses, the attacker started sending phishing mails to the recipients listed in this file. The source code of this file shows the real target of the comprised link:

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?

We found archives which contained pre-packaged pages for other major banks. These pages are used for gathering credit card numbers from the victims. For example, in one case the form input will be checked with the help of JavaScript and the only condition is that the input fields are not blank. The next script sends the data to the attacker:

After this validation, the file processing.html shows just the text: "Thank you, Our update team will verify provided information and you will be contacted". In another bank page, we found the input will not be checked for reasonable values. Instead, it will be just send to the attacker by mail after using the "Save" button. Furthermore, we found a mailer-script for a US bank which works like the mailer-script. It is a simple PHP script that reads e-mail addresses from a separate file and sends the contents of another file. The recipient file includes 83,073 mail addresses.

Analysis of German attacker's sessions

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.

German PHP script analysis

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.

Redirected Phishing Victims

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

28

203.186.X

16

80.58.X

13

212.138.X

12

195.175.X

9

61.56.X

9

213.42.X

8

62.220.X

8

200.141.X

8

195.229.X

7

200.207.X

5

200.226.X

5

200.171.X

5

142.32.X

5

133.11.X

4

61.19.X

4

219.249.X

4

203.162.X

4

203.113.X

4

202.129.X

4

201.6.X

4

200.204.X

3

82.129.X

3

66.173.X

3

65.214.X

3

216.189.X

3

212.0.X

3

211.248.X

3

202.175.X

3

200.168.X

3

200.153.X

3

193.95.X

3

193.188.X

3

163.28.X

2

81.192.X

2

81.168.X

2

81.116.X

2

80.55.X

2

80.53.X

2

69.56.X

2

68.167.X

2

67.163.X

2

66.6.X

2

66.250.X

2

66.207.X

2

66.135.X

2

64.139.X

2

63.70.X

2

61.220.X

2

61.179.X

2

61.131.X

2

24.106.X

2

219.148.X

2

218.30.X

2

217.166.X

2

217.14.X

2

216.37.X

2

216.244.X

2

216.108.X

2

213.212.X

2

212.165.X

2

211.75.X

2

210.95.X

2

210.212.X

2

210.193.X

2

210.177.X

2

208.59.X

2

207.250.X

2

203.87.X

2

203.75.X

2

203.233.X

2

203.177.X

2

203.154.X

2

203.147.X

2

202.157.X

2

202.138.X

2

200.68.X

2

200.45.X

2

200.247.X

2

200.216.X

2

200.206.X

2

200.161.X

2

200.14.X

2

196.40.X

2

195.92.X

2

193.251.X

2

168.143.X

2

163.27.X

2

148.244.X

2

148.240.X

2

12.154.X

1

84.9.X

1

84.114.X

1

82.67.X

1

82.194.X

1

82.156.X

1

82.144.X

1

82.112.X

1

82.108.X

1

81.86.X

1

81.193.X

1

81.115.X

1

80.65.X

1

80.51.X

1

80.48.X

1

80.235.X

1

80.191.X

1

80.183.X

1

80.178.X

1

80.15.X

1

80.13.X

1

80.132.X

1

80.108.X

1

69.95.X

1

69.8.X

1

69.88.X

1

69.76.X

1

69.50.X

1

69.26.X

1

69.201.X

1

68.9.X

1

68.95.X

1

68.81.X

1

68.60.X

1

68.255.X

1

68.228.X

1

68.169.X

1

68.164.X

1

68.163.X

1

68.161.X

1

68.153.X

1

68.122.X

1

68.120.X

1

67.50.X

1

67.162.X

1

67.132.X

1

67.10.X

1

67.109.X

1

67.101.X

1

67.100.X

1

66.95.X

1

66.93.X

1

66.8.X

1

66.69.X

1

66.56.X

1

66.30.X

1

66.255.X

1

66.23.X

1

66.228.X

1

66.214.X

1

66.201.X

1

66.178.X

1

66.159.X

1

66.150.X

1

66.147.X

1

66.0.X

1

65.75.X

1

65.69.X

1

65.33.X

1

65.202.X

1

65.198.X

1

65.197.X

1

65.166.X

1

65.115.X

1

65.113.X

1

64.84.X

1

64.7.X

1

64.76.X

1

64.5.X

1

64.39.X

1

64.31.X

1

64.2.X

1

64.26.X

1

64.219.X

1

64.217.X

1

64.205.X

1

64.198.X

1

64.173.X

1

64.167.X

1

64.166.X

1

64.145.X

1

64.132.X

1

64.12.X

1

64.114.X

1

64.105.X

1

63.86.X

1

63.245.X

1

63.209.X

1

63.171.X

1

63.169.X

1

63.167.X

1

63.162.X

1

63.145.X

1

63.134.X

1

62.69.X

1

62.39.X

1

62.252.X

1

62.190.X

1

62.103.X

1

61.62.X

1

61.241.X

1

61.236.X

1

61.222.X

1

61.221.X

1

61.219.X

1

61.218.X

1

61.206.X

1

61.197.X

1

61.17.X

1

61.150.X

1

61.145.X

1

61.138.X

1

4.7.X

1

4.79.X

1

4.60.X

1

4.42.X

1

4.239.X

1

38.5.X

1

38.118.X

1

24.74.X

1

24.28.X

1

24.252.X

1

24.242.X

1

24.220.X

1

24.217.X

1

24.209.X

1

24.175.X

1

24.167.X

1

24.140.X

1

24.13.X

1

24.129.X

1

24.11.X

1

24.117.X

1

24.0.X

1

222.51.X

1

222.35.X

1

222.111.X

1

221.2.X

1

221.142.X

1

220.80.X

1

220.65.X

1

220.255.X

1

220.244.X

1

220.172.X

1

220.135.X

1

220.130.X

1

219.93.X

1

219.89.X

1

219.239.X

1

219.166.X

1

219.163.X

1

219.161.X

1

219.147.X

1

219.142.X

1

219.137.X

1

219.133.X

1

218.93.X

1

218.89.X

1

218.76.X

1

218.5.X

1

218.56.X

1

218.188.X

1

218.157.X

1

218.152.X

1

218.145.X

1

218.144.X

1

218.108.X

1

217.95.X

1

217.84.X

1

217.56.X

1

217.33.X

1

217.172.X

1

217.167.X

1

217.136.X

1

217.128.X

1

216.86.X

1

216.77.X

1

216.43.X

1

216.253.X

1

216.250.X

1

216.246.X

1

216.239.X

1

216.221.X

1

216.191.X

1

216.190.X

1

216.185.X

1

216.161.X

1

216.155.X

1

216.154.X

1

216.153.X

1

216.144.X

1

216.139.X

1

216.135.X

1

216.104.X

1

213.81.X

1

213.56.X

1

213.3.X

1

213.229.X

1

213.199.X

1

213.186.X

1

213.172.X

1

213.164.X

1

213.157.X

1

213.132.X

1

213.121.X

1

212.97.X

1

212.95.X

1

212.55.X

1

212.37.X

1

212.182.X

1

212.112.X

1

211.92.X

1

211.72.X

1

211.57.X

1

211.46.X

1

211.38.X

1

211.251.X

1

211.249.X

1

211.241.X

1

211.23.X

1

211.22.X

1

211.21.X

1

211.184.X

1

211.167.X

1

211.114.X

1

211.108.X

1

210.93.X

1

210.90.X

1

210.83.X

1

210.60.X

1

210.249.X

1

210.187.X

1

210.150.X

1

210.138.X

1

210.104.X

1

210.100.X

1

210.0.X

1

209.88.X

1

209.63.X

1

209.58.X

1

209.250.X

1

209.239.X

1

209.232.X

1

209.226.X

1

209.205.X

1

209.204.X

1

209.195.X

1

209.183.X

1

209.173.X

1

209.113.X

1

208.63.X

1

208.62.X

1

208.42.X

1

208.29.X

1

208.232.X

1

208.203.X

1

208.19.X

1

208.191.X

1

208.190.X

1

208.16.X

1

208.153.X

1

208.147.X

1

207.6.X

1

207.69.X

1

207.44.X

1

207.28.X

1

207.233.X

1

207.212.X

1

207.192.X

1

207.177.X

1

207.152.X

1

207.121.X

1

207.109.X

1

206.205.X

1

206.173.X

1

206.163.X

1

205.208.X

1

205.201.X

1

205.188.X

1

205.145.X

1

204.69.X

1

203.59.X

1

203.51.X

1

203.252.X

1

203.208.X

1

203.199.X

1

203.195.X

1

203.185.X

1

203.172.X

1

203.157.X

1

203.151.X

1

203.145.X

1

203.131.X

1

203.130.X

1

203.121.X

1

203.112.X

1

203.10.X

1

202.85.X

1

202.67.X

1

202.5.X

1

202.58.X

1

202.54.X

1

202.47.X

1

202.39.X

1

202.216.X

1

202.213.X

1

202.174.X

1

202.169.X

1

202.162.X

1

202.159.X

1

202.155.X

1

202.14.X

1

202.130.X

1

202.106.X

1

201.3.X

1

201.2.X

1

201.225.X

1

201.129.X

1

200.87.X

1

200.85.X

1

200.59.X

1

200.40.X

1

200.30.X

1

200.253.X

1

200.251.X

1

200.250.X

1

200.228.X

1

200.212.X

1

200.203.X

1

200.201.X

1

200.182.X

1

200.165.X

1

200.163.X

1

200.158.X

1

200.144.X

1

200.12.X

1

200.119.X

1

200.118.X

1

200.114.X

1

199.80.X

1

199.246.X

1

199.243.X

1

199.203.X

1

199.174.X

1

198.81.X

1

198.248.X

1

198.173.X

1

198.165.X

1

196.33.X

1

195.69.X

1

195.68.X

1

195.61.X

1

195.56.X

1

195.39.X

1

195.222.X

1

195.205.X

1

195.117.X

1

194.78.X

1

194.243.X

1

193.253.X

1

193.170.X

1

192.136.X

1

192.115.X

1

170.154.X

1

168.234.X

1

168.209.X

1

166.114.X

1

165.98.X

1

165.21.X

1

163.23.X

1

163.20.X

1

162.6.X

1

162.39.X

1

159.54.X

1

158.130.X

1

156.110.X

1

155.212.X

1

151.99.X

1

151.195.X

1

149.106.X

1

148.223.X

1

143.248.X

1

142.179.X

1

141.158.X

1

140.131.X

1

138.88.X

1

137.204.X

1

129.44.X

1

128.200.X

1

12.42.X

1

12.176.X

1

12.160.X

1

12.147.X

1

12.101.X

Details of UK compromise

Details about the UK compromise

Analysis

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.

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.

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 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.

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!

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.

Timeline

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.

Detailed timeline:

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 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:

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:

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.

Phishing Incident Victims

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.

IP

ISP

Country

OS

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.202.NNN.NNN

AT&T;

US

FreeBSD 4.7

12.217.NNN.NNN

AT&T;

US

Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)

12.218.NNN.NNN

AT&T;

US

UNKNOWN

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.160.NNN.NNN

Road Runner

US

UNKNOWN

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.220.NNN.NNN

Midcontinent Comms

US

UNKNOWN

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.166.NNN.NNN

Sprint

US

Windows 98

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)

65.229.NNN.NNN

UUNET

US

Windows XP/2000

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!)

67.167.NNN.NNN

Comcast Cable

US

UNKNOWN

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.205.NNN.NNN

Road Runner

US

UNKNOWN

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.134.NNN.NNN

Road Runner

US

UNKNOWN

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

Learning about phishing from bot source code

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.

bool CanSpamAOL(){int iRnd=brandom(1, 4);char*szDNS;int iIsMsg_Matched=0;// How much the AOL blocking message has been matched in %// 25% are for occurence of string "postmaster.info.aol.com"// 20% are for an immediate 554// 10% are for a line count of 5// 10% are for occurence of string "(RTR:DU)"// 10% are for occurence of string "not accept"// 5% are for occurence of string "dynamic" (occurs 2 times)// 5% are for occurence of string "residential" (occurs 2 times)// 5% are for occurence of string "are using to"switch(iRnd){case1:
szDNS="mailin-01.mx.aol.com";break;case2:
szDNS="mailin-02.mx.aol.com";break;case3:
szDNS="mailin-03.mx.aol.com";break;case4:
szDNS="mailin-04.mx.aol.com";break;default:#ifdef DBGCONSOLE
g_cMainCtrl.m_cConsDbg.Log(9, "CanSpamAOL(): Unknown value %d in switch statement.\n", iRnd);#endifbreak;}

This is private software, you may redistribute it under the terms of
the APL(Ago's Private License) which follows:

Redistribution and use in binary forms, with or without modification,
are permitted provided that the following conditions are met:
1. The name of the author may not be used to endorse or promote products
derived from this software without specific prior written permission.
2. The binary may not be sold and/or given away for free.
3. The licensee may only create binaries for his own usage, not for any
third parties.

Redistribution and use in source forms, with or without modification,
are not permitted.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */