This side note provides further detailed background on phishing attacks, beginning with a historic overview of phishing and social engineering, and concluding with quantitative data on phishing attempts and information on high level trends.
During the 1990’s, as the popularity and take up of the Internet grew, social engineering was gradually transformed and attackers began to focus on the mass consumer market. Phishers moved from AOL to the unregulated and more anonymous Internet, with email becoming the preferred medium for engaging (often naïve) end users. One reason for this change of focus might be that online discussion forums, IRC and instant messaging were increasingly portrayed by the press as dangerous places, where evildoers and system crackers waited to ambush unsuspecting users. Also, users had become aware that legitimate companies nearly exclusively use telephone, email and traditional postal mail as means of communication with their customers, rarely participating in less formal chat sessions. Users had also become more familiar with and confident in trusting web based authentication systems, e-shopping with credit cards, online banking services and the protection offered by technologies such as Secure Sockets Layer (SSL) - all fronted by a myriad of different looking user interfaces.
Internet based email solutions continued to evolve at a rapid rate, with increasingly complex methods being offered to customise the look and feel of email messages and therefore potentially fooling unsuspecting users into trusting spoofed communications that might appear to be legitimate. When compared to established and relatively well policed closed loop systems, it still remains difficult for consumers to trace the exact origin of an SMTP mail message, and the available global user base of Internet email is many times larger. Even activities with a very low success rate can still be attractive to an attacker if the number of end users receiving the message is large enough to generate a number of responses, as can be witnessed by the continued growth in organisations willing to pay for the sending of spam and many users' own experiences of inboxes regularly full of unsolicited email.
In a more sinister turn, phishers have not only changed their primary means of communication to email, they have also started operating in a more organised manner and to target their attacks against more profitable information. In recent years, requests for AOL accounts or single credit card numbers have gradually been replaced with schemes aimed at obtaining more sensitive data, such as personal information that could allow unlimited access to online banking services or that could serve as a foundation to enable identity theft. Sensitive information to fraudulently impersonate another person’s identity might include name, date of birth, address, social security number or "secret" information such as mother's maiden name, account numbers, first school, pet’s name, user names, passwords, Personal Identification Numbers (PINs) or even one-time passwords (which are quite common in European Internet banking).
The following chart that shows the top corporate phishing targets based on responses in a recent survey of spam recipients (October 2004) by email security company CipherTrust:
Phishing attacks have affected many users and have caused serious problems for some major banks. In extreme cases, some banks have been forced to shut down their ebanking operations for period of time due to phishing attacks. The exact cost to the banking industry of phishing attacks is not available in the public domain, and there are few well documented qualitative examples of public arrests and prosecution (such as in Estonia or Brazil), but it is likely to be substantial. In most cases banks will refund the money lost by their customers due to phishing attacks, although they reserve the right not to refund such losses at their discretion. Estimates by the Association for Payment Clearing Services (APACS) for the cost of phishing attacks against UK banks were £1M for the previous 18 months to April 2004, rising to £12M by March 2005. Australian estimates for March 2005 were A$25M, whilst Financial Insights estimates the cost to US business to be $400M in 2004. A study by Gartner estimated the cost in 2003 to be $1.2B and the number of reported phishing attacks have massively increased since then.
In October 2004 the Anti-Phishing Working Group reported that it had seen 6597 new phishing emails, an increase of 36% on the previous month. 1142 phishing web sites were reported, double the number for September and part of a "bumper month" during a period of huge growth in automated phishing attacks. Email filtering specialist MessageLabs reported that it intercepted more than 18 million phishing messages during 2004, and the graph below clearly shows the growth in attempted phishing attacks by email:
The loss of trust, impact on consumer confidence and the associated financial costs of phishing attacks have become important enough for banks to set up web sites such as BankSafe Online to try and educate their customers, and most target brands now provide sections of their official web site with advice on identifying and avoiding online scams (such as Citizen Bank's "Online Fraud Prevention Centre" or Citibank's "Learn About Spoofs" pages ). Other organisations such as the Anti Phishing Working Group are also hoping to educate consumers as to the potential risks and teach Internet users how to avoid online scams such as phishing attacks. However, the main challenge in preventing phishing attacks is that phishing is not a pure technology problem - the major contributing factor is human nature, and as long as attackers can continue to create schemes to trick unwary users, phishing will continue to be successful and potentially lucrative. As Bruce Schneier writes in a recent weblog, even issuing all end users with two-factor authentication doesn't really help to solve the problem if the phisher is successful in tricking the users into authenticating themselves against a fake, malicious system. Given the combination of human nature, the rapid rate of technological change and the potential for illegitimate profits to be made, it seems safe to assume that the problem of phishing will get worse before it gets better.
his side note provides a more detailed overview of the two incidents discussed in the "Phishing Technique One - Phishing Through Compromised Web Servers" section of this whitepaper. One incident was catpured using a honeypot deployed by the German Honeynet Project, and the other incident was captured by a honeypot deployed by the UK Honeynet Project.
The honeynet deployed and analysed by the German Honeynet Project in the first incident formed part of a diploma thesis ("Planung und Realisierung eines Honeynet zur Analyse realer Angriffe aus dem Internet") by a graduate student at MAGELLAN Netzwerke GmbH in Cologne, Germany. The honeynet was a high interaction research honeynet deployed by the German Honeynet Project during November 2004. The honeynet topology is depicted below:
The honeynet deployed was a typical GenII honeynet based on the three basic principles defined by the Honeynet Project: data capture, data control and data analysis.
Data capture was performed by recording all inbound and outgoing network traffic for later analysis, using packet sniffing tools such as tethereal. All network traffic to and from a RedHat Linux honeypot was mirrored via the monitor port of a network switch and logged using the popular open source Intrusion Detection System snort running in binary capture mode (as daily pcap files). To allow keystroke logging after a successful system compromise, version 2.1.7 of the Honeynet Projects Sebek kernel module was installed on the honeypot. The Redhat syslog daemon was also modified to output syslog information to the serial port for capture by the honeynet gateway.
For data control, all network traffic from the Internet was routed through a transparent bridging honeynet gateway running the FreeBSD release 4.10 operating system that limited outgoing network connections from the honeypot. Outgoing connections were identified by SYN packets, differentiated and logged by TCP connection types (such as IRC-connections), and the number of connections limited to 15 IRC-connections and 10 other TCP-connections with a 24 hour period. Connection limiting is designed to allow attackers to successfully compromise the honeypot and download a limited amount of rootkits or other malware from external servers, but to then limit their potential to attack further hosts from the compromised honeypot. It also helps to hide the presence of the honeynet gateway by not totally blocking all outbound traffic, along with preventing denial of service attacks.
For data analysis, all network traffic to or from the honeypot was mirrored to a snort IDS for pattern matching against the current signature rulebase. Manual and automated analysis of logged data was performed regularly, along with real time monitoring and alerting.
The honeynet gateway was connected to a central network switch which was used to separate network traffic from the honeypot system network and the administrative network using VLANs, a common method to logically segmented network on the same physical hardware. The honeypot itself was a standard installation of RedHat Linux version 7.1 on Intel hardware running the latest version 2.4.20 kernel with several network services such as FTP (wu-2.6.1-16), HTTP (Apache 1.3.19, OpenSSL/0.9.6) and a database (MySQL 3.23.36) server enabled. All services were left in their default configuration, except for the MySQL database which had a random secure password set for the root user. To make the system more realistic and more closely simulate a production system, a mocked up web site for an imaginary sales company was installed and reverse DNS added for the web server.
The following table depicts the timeline of the incident:
|Date / Time||Event|
|12/11/04||First data from honeypot|
|Honeypot WU-FTPd compromised by autorooter|
|Attacker manually installs rootkit, IRC bot and Ebay phishing attack content|
|Attacker returns to install and run mass scanning tool|
|Attacker returns to install proxy server|
|Attacker returns to install additional rootkit|
|Attacker returns to set up phishing web sites and sends out spam mails (blocked by Honeywall)|
|Honeypot disconnected for forensic analysis|
A more detailed incident timeline, including an analysis of the tools and techniques the attackers used, is available here.
The honeynet deployed and analysed by the UK Honeynet Project in the second phishing incident was a high interaction research honeynet deployed in a UK ISP data centre during August 2004.
The UK Honeynet deployment was similar in broad outline to the German honeynet configuration detailed above, being composed of a number of physical honeypots running default installations of common UNIX operating systems on Intel and Sparc hardware. The Honeynet Projects Honeywall bootable CDROM was used for data control, providing a transparent bridging iptables firewall and using network connection rate limiting plus the snort-inline IPS to restrict outbound attack traffic. Another snort IDS provided data capture in binary pcap format, along with snort and snort-inline alerting and automated daily script based data analysis.
Individual honeypots were hosted behind the Honeywall gateway, connected to an Ethernet hub, and the Honeynet project's Sebek loadable kernel module was covertly installed and enabled on each honeypot to allow full keystroke logging. All network traffic to and from the honeypots was logged in pcap format, as were any keystrokes recorded using Sebek. Any compromised hosts were eventually taken off line and imaged for later forensic examination.
The RedHat Linux 7.3 server on Intel hardware honeypot that was compromised and used to host a phishing attack was a default CDROM based installation with a number of common network services such as Apache and samba enabled and left un-patched.
Again, a timeline of the incident is given:
|Date / Time||Event|
|17/08/04||First data from honeypot|
|Honeypot samba server compromised. Various IRC tools, backdoors and mass scanners installed by multiple groups|
|19/08/04||Attackers check result of network scans|
|20/08/04||New attackers compromise honeypot|
|22/08/04||More scanning activity|
|Phishers arrive through back door set up by initial attackers and set up phishing website|
|First web traffic arrives at web server for phishing site|
|Honeypot disconnected for forensic analysis|
On November 12, 2004, the Honeynet was connected to the Internet. During the time between the start up and November 22, nothing special happened. We just observed an enormous number of
packets with destination port 445 which is not critical for the installed Honeypot.
At 1:16 am the Honeypot got compromised by exploiting the WU-FTP daemon. There was no port scan or FTP connection before, the first connect was used to hack the computer which is an indication of an autorooter-tool. Such tools are used to scan whole network ranges for vulnerable machines and attack everything they come across. They just deliver their "evil" payload to every system in the given address range. In our case, it was probably a tool called
superwu since later on, the attacker used this tool to attack further targets from the Honeypot.
Until 8:21 am there was no activity from the attacker. Probably he started the tool the night before and checked in the morning for successful gained access. As a first step he downloaded a rootkit and installed it on the Honeypot. This script-based rootkit replaces some system binaries with trojaned files:
In addition, it install an SSH-daemon on port 255 which was used by the attacker to log on the Honeypot in the following. The rootkit uses source code to compile new versions of binary files. These trojaned executables are adjusted to the size of the original files of the target system to "hide" the presence. The rootkit also installs a sniffer to collect login information to other systems. Furthermore, it modifies the init-scripts to ensure that the installed services will start on next reboot and then sends out an information mail about the system status to the attacker. After finishing the installation, the attacker reentered the Honeypot via the additionally installed SSH service using the tool "putty", an SSH-Client for Windows-systems. Afterwards the attacker downloaded a file called spam.tgz. This archive contains some PHP and HTML files. Further examination showed that these files contain web-pages to update the billing profile update for seller accounts of a large Internet auctions website. The attacker copied this files into the document root of the webserver. The "index.html" start page is a forwarding page to the auctions website. The reason for that is that these PHP pages were incomplete. The attacker edited them, but never finished his work on this files. By tracing the IP of the attacker, the source could be located in Romania. A scan of this computer showed no open ports, so this could be the computer of the cracker.
At8:49 am the attacker downloaded another file: psybnc.tgz. After extracting the archive, he installed the included IRC-Bouncer and started an IRC-Session to an "undernet.org" server. The channel he entered was probably used to control hacked systems. A scan of all 8 connected clients showed the same untypical open port 255 with a listening SSH-daemon like the Honeypot had. The attacker also entered another channel and received Operator-rights there. The topic on this channel was a pointer to his personal homepage and the language used in that channel was Romanian.
At6:25 pm the attacker came back and downloaded the file windmilk.tgz. This archive contains the "superwu" autorooter. After extracting the executable binary file, he started the exploiter in a screen-session with a target network as parameter. Then the attacker detached the session and logged off. Later when he came back, he attached the session again to see the results. Since the Honeywall blocked all attacks, no systems could be compromised. The attacker did not realize the intervention, downloaded and installed at 10:40 pm a "socksify" proxy which was configured without any restrictions. With this service anybody could use the Honeypot as a proxy for spreading spam or anonymous connections to any other systems. During the honeynet's online time, it was never used.
On November 23, 2004, the attacker came back at 2:25 pm. He added the user "ro" and installed another rootkit. In a side note we present the recording of this session captured by the snort binary logging.
At 4:40 pm, the attacker downloaded the archive willson.tgz. This file includes already finished webpages similar to the spam.tgz archive. The attacker installed them in the document root directory of the webserver. Now this Honeypot could be used for phishing attacks. By calling the startup page, you get a login page that looks like the original login page. While unrelated to the incident we report, a recent example illustrating the similarity of a phishing data entry form to compare to the acutal site can be found here.
The input of this form will be rudimentary checked with the help of a small PHP-script
/tmp/User.docand the next page will be shown. On this page, the victim is tricked into entering personal information. All input will be checked and if one is not according to the condition, an error page will be shown. This error page does not attempt to mimic the real error page and most victims would likely become suspicious of the fake web site at this point.
With the help of the following validation script, the data entered into the form is checked. The resulting page of the validation process is not interpreted by the webserver because Apache does not accept
.dll files as PHP files by default. The attacker forgot to set the "AddType" variable of the Apache server to interpret
.dll files with the PHP-engine. The next activity of the attacker was downloading an archive called banksend.tgz. This file includes a PHP script for sending mails:
Please follow the link below and renew your account information. <br><br> <a href="http://XXX.XXX.XXX.XXX/Checking/login.php" onClick="popup('http://www.totalmates.com/php/click.cgi?id=xakir')" onMouseOver="window.status='https://internetbanking.bank.com';return true;" onMouseOut="window.status=' ';return true;">https://internetbanking.bank.com</a> <br> <br>
At this point of time we decided to block outgoing TCP ports 25 and 443 so that no victim would suffer from the phishing attacks. The attacker probably noticed that we blocked outgoing connections and concluded that something weird was happening. He never came back and on Decembers 8, 2004, the honeynet went offline for further analysis.
What else did we find?
This side note shows the commands issued by the phisher from the perspective of the attacker. Their actions were reconstructed with the help of the log files generated by Snort and other logged data. The first part of this side note shows a screenshot of the installation process of the rootkit, with a very "user-friendly" interface allowing easy setup. The second part shows the commands issued by the attacker once the rookit was installed, which were again reconstructed with the help of Snort log-files.
Screenshot of the rootkit installation:
Commands issued by the attacker:
In this side note we analyse an example script that used to validate the information entered by users into a HTML form on a phishing web site. Initially the input data is checked to ensure that the submitted strings are valid. For example, the PIN should be four characters long and the username should not contain certain words. If the entered data passes this check, the script constructs an e-mail message containing the user's information and sends it to an address at a free e-mail provider. Finally, the location bar of the browser is updated to point to the file
xxxxISAPI.dll (the file name has been obfuscated). This page will display a confirmation for the victim. In addition, a script was also included that could be used to transfer the phished information to an FTP server.
cc-ftp.php (commented out in the data processing script above) will transfer the input to an FTP server:
In this side note we provide an overview of the source IP addresses of potential victims in the redirection phishing attack described in phishing technique two. The data below was collected with the help of the compromised German honeypot and modified redir software. Over a period of about 36 hours we observed 721 redirections of inbound HTTP requests to the honeypot, presumably recipients of a spam phishing email who were tricked into accessing the redirected content by clicking on the link provided. All are potential victims of the phishing attack, but as no personal data was captured we we cannot make an educated guess how many people actually entered sensitive information into the HTML form on the Chinese phishing web site.
|Count||Source IP address range|
Details about the UK compromise
This honeynet was a high interaction research honeynet deployed by the UK Honeynet Project in a UK ISP data centre. After a few hours of general background network activity, the Redhat Linux 7.3 honeypot was scanned, compromised and an IRC server installed. A number of further compromises occurred, as multiple attackers located the vulnerable system and exploited it for their own purposes, before the honeypot server was used to host a phishing attack targeting a well known US bank. For brevity, this detailed analysis of the uploaded content only covers the activity relevant to the phishing attack.
The first zip file downloaded was bank.zip, via wget from the Romanian FTP server host2.go.ro.
The file was a valid zip archive, and contained the following data:
This was a pre-prepared web site that mimics the official login page for a major US bank. It included a server side PHP script called check.php, intended to harvest any credentials entered by an unsuspecting end user and email them to the phisher. The presence of a Thumbs.db file suggests that the contents was prepared on a MS Windows system. Scrisoare is the Romanian word for letter, suggesting an email or message or Romanian origin.
Analysis of the check.php script (shown below) reveals that this script is a more advanced version of the script used the German phishing incident. Basic checks on the card number received have been added, along with a refinement that uses the credit card number to classify cards into different types and insert the type into the subject line of the email. This suggests basic scripting abilities and not just a simple script kiddie.
The check.php script:
A hard coded IP address of 66.XXX.XXX.XXX was included in the original script, suggesting that the script had already been used on an alternate server (either another compromised host or a test machine local to the attacker). This IP address appears to be a home DSL IP block belonging to a US carrier and no web site is hosted there now. This script also links directly to the real target bank web site, presumably for added realism and to attempt to confuse recipients.
The second file downloaded using FTP was bank1.tgz:
The file was a valid tgz archive, and contained the following data:
The attacker moved the new files into location in the web root and used the pico editor to change popup.html to point to a test server (http://69.24.XX.XX/testing.php). Again, this was possibly a previously compromised host or a system local to the attacker.
Interestingly, because this FTP session was plain text and the attacker helpfully used the directory listing command, we can observe the attacker�s activities and also see what other tools they have stored in their FTP area. Directory listings are often very useful in providing further background detail during incident analysis:
The contents of this FTP server home directory suggests that the phisher is heavily involved in spam and phishing activities, with pre-built content and message delivery tools targeting many well known online brands stored on this server. Based on this captured session, this phishing activity is not likely to be an isolated incident.
The third file downloaded was sendbankNEW.tgz from the Romain FTP server host2.go.ro.
The file was a valid archive and contained the following files:
The purpose of each file is listed in the table below:
|File||Contents and purpose|
|ini.inc||Spam sending configuration|
|list.txt||This file contained a list of 5 email addresses to send spam email to. Because of the limited size and Romanian email addresses linked to the attacker, this was presumably the email addresses of fellow gang members and not a real phishing attack|
|bank.php||A simple PHP script to read the contents of a text file (bla.txt) and email it to each recipient in an input file (list.txt)|
The email lure blah.txt was notable for having good grammar and spelling, legalise at the bottom about "Equal Opportunity Lending" and heavy use of files linked directly from the official web site of the targeted bank, all of which help it to appear more realistic. One ironic point to note is that the email even included an exhortation to not provide passwords to fraudulent web sites, or to ever email your password to a third party!
The bank.php mass emailing script to send spam advertising this particular phishing scam is shown below:
Although simple, it is functional and could easily have been used to send many more messages than the 5 test messages sent from the honeynet. The honeynet architecture would have restricted outbound emails, but the honeypot was taken offline for forensic analysis before any bulk spam email could be sent by the attacker.
This honeynet was a high interaction research honeynet deployed by the UK Honeynet Project in a UK ISP data centre. After a few hours of general background network activity, the Redhat Linux 7.3 honeypot was scanned, compromised and an IRC server installed. A number of further compromises occurred, as multiple attackers located the vulnerable system and exploited it for their own purposes, before the honeypot server was used to host a phishing attack targeting a well known US bank. For brevity, this detailed timeline only covers the activity relevant to the phishing attack.
18/07/04 - 12:30. First the attacker exploits a buffer overflow in the samba server on the Redhat Linux 7.3 honeypot, as can be seen from the snort alerts shown below:
18/07/04 - 12:30. After a few retries with different offsets, the samba exploit (CAN-2003-0201) succeeds and returns a root prompt to the attacker, as show by the snort alert below:
18/07/04 - 12:30. After gaining root access, the attacker check who they are and who else is logged into the system before attempting to hide their activities by turning off shell history logging. The Sebek keystrokes for this session are shown below:
18/07/04 - 12:31. The attacker then proceeds to downloading what appears to be an image file from a remote web server using the wget command line HTTP client:
18/07/04 - 12:32. The attacker unpacks the image file, which is actually a gziped tar archive, before extracting and running a setup program:
From the SHV4 root kit source code, we can determine what the setup command does:
The attacker has installed and configured an encrypted backdoor on the honeypot, bound to TCP port 2277. A large amount of other activity occurs on the system over the next few 12-72 hours, including installation of PsyBNC IRC servers by a Romanian group, installation and usage of the mole and mazz mass scanners (probably the autorooter used to compromise this honeypot), installation and re-installation of other rootkits, password sniffing and various other activities not relevant to the main phishing attack.
23/07/04 - 21:11. The attacker returns from 192.226.XXX.XXX (a Windows 2000 or Windows XP PC in Ontario) via the SSH backdoor listening on TCP port 2277 and checks if the server is still active and who is logged in:
23/07/04 - 21:13. The attacker reconnects, prepares a directory in the Apache web server's document root and then downloads some pre-built web content from a Romanian web server using, again using wget, before checking the honeypot's IP address and PHP configuration:
23/07/04 - 21:15. The attacker attempts to extract the contents of the zip file but finds it is corrupt and deletes it.
23/07/04 - 21:16. The attacker changes tools and gets another file using FTP, again from the same web server in Romania, which does extract successfully this time:
23/07/04 - 21:17. The attacker edits the extracted web content and updates the HTML to point to a testing PHP script on a remote web server:
23/07/04 - 21:22. The attacker checks the network configuration of the honeypot and version of PHP installed:
25/07/04 - 21:42. The attacker opens a second session, checks again if PHP is configured correctly on the honeypot and downloads a tool for sending spam email from the same Romanian web server:
25/07/04 - 22:08. The attacker checks an input list email addresses and runs a PHP script to send spam email:
25/07/04 - 22:10. The attacker edits the content of the spam message, points it a co-located Linux web server running an American student web site, and runs the PHP script to send spam email again:
The attackers initial test at 22:08:52 works as planned, with 5 test messages being successfully sent (although due to the outbound traffic restrictions on the Honeywall, further mass mailing attempts would fail). However, after 10 minutes wait the attacker cleans up and leaves without sending any further messages from this honeypot.
In this side note we provide an overview of the source IP addresses of potential victims in the UK phishing attack against a major US bank described in phishing technique one. The data below was collected with the help of the compromised UK honeypot and network packet captures. Over a period of about 4 days we observed 265 inbound HTTP requests to the honeypot, presumably recipients of a spam phishing email who were tricked into accessing the redirected content by clicking on the link provided. All were potential victims of the phishing attack, but none actually submitted personal data and therefore the phishing attack was unsucessful.
|4.138.NNN.NNN||Level 3||US||Windows XP, 2000 SP2+ (NAT!)|
|4.224.NNN.NNN||Level 3||US||Windows 98|
|4.235.NNN.NNN||Level 3||US||Windows XP, 2000 SP2+ (NAT!)|
|4.239.NNN.NNN||Level 3||US||Windows XP, 2000 SP2+|
|12.217.NNN.NNN||AT&T;||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.16.NNN.NNN||Comcast Cable||US||Windows XP Pro SP1, 2000 SP3|
|24.58.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3|
|24.59.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.62.NNN.NNN||Comcast Cable||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.90.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.93.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3|
|24.107.NNN.NNN||Charter Comms||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.129.NNN.NNN||Comcast Cable||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|24.140.NNN.NNN||Massillon Cable||US||Windows XP, 2000 SP2+|
|24.154.NNN.NNN||Armstrong Cable||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.161.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.162.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.163.NNN.NNN||Road Runner||US||Windows 2000 SP4, XP SP1|
|24.165.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3|
|24.166.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.208.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|24.209.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3 (firewall!)|
|24.231.NNN.NNN||Charter Comms||US||Windows XP SP1, 2000 SP3|
|24.239.NNN.NNN||Armstrong Cable||US||Windows XP/2000|
|24.243.NNN.NNN||Service Co LLC||US||Windows XP Pro SP1, 2000 SP3|
|63.165.NNN.NNN||DIGITEL||Prob US||OpenBSD 3.0|
|63.192.NNN.NNN||Pacific Bell||US||Windows 2000 SP4, XP SP1|
|64.12.NNN.NNN||AOL||US||Linux 2.4 w/o timestamps|
|64.33.NNN.NNN||West Winconsin Telecomn||US||Windows XP, 2000 SP2+|
|64.58.NNN.NNN||Marlowe & Associates||US||Windows 98 (2) (NAT!)|
|64.136.NNN.NNN||Juno Online||US||OpenBSD 3.0|
|64.136.NNN.NNN||Juno Online||US||OpenBSD 3.0|
|64.136.NNN.NNN||Juno Online||US||OpenBSD 3.0|
|64.161.NNN.NNN||Pacific Bell Internet||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|64.216.NNN.NNN||SBC Internet||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|64.222.NNN.NNN||Verizon Internet||US||Windows 2000 SP4, XP SP 1|
|65.78.NNN.NNN||RCN Corporation||US||FreeBSD 4.7|
|65.204.NNN.NNN||Eagle Mountain Telecom||US||FreeBSD 4.8|
|65.221.NNN.NNN||Buckeye Cablevision||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|66.38.NNN.NNN||Brandenburg Telephone Company||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|66.41.NNN.NNN||Comcast Cable||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|66.45.NNN.NNN||WholeSecurity, Inc||US||Windows 2000 SP4, XP SP1|
|66.61.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3|
|66.67.NNN.NNN||Road Runnner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|66.68.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3|
|66.82.NNN.NNN||Hughes Network Systems||US||UNKNOWN|
|66.170.NNN.NNN||T-NET, Inc||US||Windows XP, 2000 SP2+|
|66.188.NNN.NNN||Charter Comms||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222) (firewall!)|
|67.5.NNN.NNN||Qwest||US||Windows XP, 2000 SP2+|
|67.23.NNN.NNN||Adelphia Cable Comms||US||Windows XP Pro SP1, 2000 SP3|
|67.38.NNN.NNN||Ameritech Electronic Commerce||US||Windows XP, 2000 SP2+|
|67.66.NNN.NNN||SBC Internet Services||US||Windows XP SP1, 2000 SP3|
|67.122.NNN.NNN||Pac Bell Internet||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|67.160.NNN.NNN||Comcast Cable||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|67.164.NNN.NNN||Comcast Cable||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|68.10.NNN.NNN||Cox Communications Inc||US||Windows XP Pro SP1, 2000 SP3|
|68.14.NNN.NNN||Cox Communications Inc||US||FreeBSD 4.7|
|68.32.NNN.NNN||Comcast Cable||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|68.53.NNN.NNN||Comcast Cable||US||Windows XP Pro SP1, 2000 SP3|
|68.88.NNN.NNN||SBC Internet Services||US||Windows 2000 SP4, XP SP 1|
|68.89.NNN.NNN||SBC Internet Services||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|68.94.NNN.NNN||SBC Internet Services||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|68.103.NNN.NNN||Cox Communications Inc||US||Windows XP Pro SP1, 2000 SP3|
|68.109.NNN.NNN||Cox Communications Inc||US||Windows 2000 SP4, XP SP1|
|68.254.NNN.NNN||SBC Internet Services||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|69.23.NNN.NNN||-||-||Windows XP Pro SP1, 2000 SP3|
|69.48.NNN.NNN||Choice One Comms||US||Windows XP, 2000 SP2+|
|69.59.NNN.NNN||Peak Inc||US||Windows XP/2000 via Cisco|
|69.132.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|69.133.NNN.NNN||Road Runner||US||Windows XP Pro SP1, 2000 SP3|
|69.135.NNN.NNN||Road Runner||US||Windows 2000 SP4, XP SP1|
|69.135.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|69.151.NNN.NNN||SBC Internet Services||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|69.162.NNN.NNN||Adelphia Cable Comms||US||FreeBSD 4.7|
|137.229.NNN.NNN||University of Alaska||US||Windows XP Pro SP1, 2000 SP3|
|141.154.NNN.NNN||Verizon Internet||US||Windows XP SP1, 2000 SP3|
|148.78.NNN.NNN||Starband Comms||US||CacheFlow CacheOS 4.1 (up|
|149.174.NNN.NNN||CompuServe||US||Linux 2.4 w/o timestamps|
|152.163.NNN.NNN||AOL||US||Linux 2.4 w/o timestamps|
|156.36.NNN.NNN||US Bancorp||US||OpenBSD 3.0|
|162.83.NNN.NNN||Verizon Internet||US||Windows 2000 SP4, XP SP1|
|166.102.NNN.NNN||WRK Internet||-||Windows XP, 2000 SP2+|
|166.102.NNN.NNN||WRK Internet||-||Windows XP, 2000 SP2+|
|169.207.NNN.NNN||Executive PC, Inc||US||Windows 98|
|170.94.NNN.NNN||State of Arkansas||US||Windows 2000 SP4, XP SP1|
|172.131.NNN.NNN||AOL||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|172.131.NNN.NNN||AOL||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|204.95.NNN.NNN||Sprint||US||Windows XP, 2000 SP2+|
|204.210.NNN.NNN||Road Runner||US||Windows 2000 SP4, XP SP1|
|204.210.NNN.NNN||Road Runner||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|205.162.NNN.NNN||Buckeye Cablevision||US||Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222)|
|206.148.NNN.NNN||AGIS||US||Windows XP, 2000 SP2+|
|206.196.NNN.NNN||US West Internet Services||US||Windows XP Pro SP1, 2000 SP3|
|207.89.NNN.NNN||NetLink Systems LLC||US||Windows XP, 2000 SP2+|
|207.89.NNN.NNN||NetLink Systems LLC||US||Linux 2.4/2.6 (up|
|207.231.NNN.NNN||Surewest Internet||US||BSD/OS 3.1|
|208.60.NNN.NNN||Local Link||US||Windows XP, 2000 SP2+|
|208.187.NNN.NNN||Lanset Comms||US||Windows XP, 2000 SP2+|
|208.191.NNN.NNN||SBC Internet||US||Windows XP Pro SP1, 2000 SP3 (NAT!)|
|209.43.NNN.NNN||IQuest Internet||US||Windows XP, 2000 SP2+|
|209.131.NNN.NNN||CenturyTel Internet Holdings Inc||US||Windows 98|
|209.206.NNN.NNN||IQuest Internet||US||Windows XP, 2000 SP2+|
|209.247.NNN.NNN||Bend Cable||US||Linux 2.4/2.6 (up|
|216.93.NNN.NNN||Voyager Information Networks||US||Windows XP, 2000 SP2+|
|216.228.NNN.NNN||Bend Cable||US||Cisco Content Engine|
In this side note will will review the source code of some bots captured during our research and show several examples of how bots are being used to send out spam and phishing emails.