Know Your Enemy:
Phishing

This 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 Project’s 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:

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 Project’s 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:

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.

Click here to return to the main paper.