Wir wurden heute aufmerksam gemacht, daß einer unserer #Server offensichtlich eine #Welle von #Spam-Mails mit #Scam – Inhalt verschickt.

Tatsächlich wurden wir schnell fündig, denn in der aktuellen #Mail-Queue des jeweiligen Servers, befanden sich immerhin Mails im 5stelligen Bereich. Die Analyse ist immer sehr aufwendig, da Täter genügend kriminelle Energie entwickeln, Rückschlüsse möglichst aufwendig zu machen! So vermischen sich gleiche Mail-IDs über viele Mails und viele unterschiedliche Zeiten, scheinbar werden bei sehr schnellen Servern, wie den 1awww-Servern, via Script unlogische Pausen eingelegt, die den normal verständlichen Protokoll-Ablauf erheblich stören. Bei langsamen Servern wird gerne die Überlastung ausgenutzt, um Protokoll-Auswertungen extrem schwer zu machen!

Mit entsprechendem Aufwand und einigen Tools, die wir zum Teil selbst programmiert haben, konnten wir dann feststellen, daß die Mails via SMTP jeweils vom lokalen Server (127.0.0.1) versendet wurden. Ein ganz normaler Vorgang, daß Kunden über den Lokalhost (127.0.0.1) nach Authenthifizierung, Mails versenden. Andere, die in Ihrem PC Ihre Mails verfassen und versenden, verwenden dann einen externen SMTP-Versand!

Der Versand via Lokalhost kann also nur vom Server-Mail-Client (ein separater Web-Mail-Server, ähnliche Funktionsweise, wie bei Hotmail. Hier können Kunden über ein Webinterface Mails versenden) oder via SMTP-Versand von einem PHP-Programm erfolgt sein! Das weitere Suchen, wird also komplizierter, aber dann wurde klar, die Mails wurden alle samt authentifiziert (also mit regulären Kunden-Zugangsdaten), versendet!

Die Mails wurden dabei unter der mißbräuchlichen Verwendung von Zugangsdaten eines Kunden versendet.

Wir konnte es dazu kommen?

Eine Kundin auf diesem Server hat sich selbst Joomla installiert. Ferner wurden diverse Plugins installiert unter anderem ein Plugin, daß nicht sauber war und es ermöglichte, eine PHP-Datei zu installieren. Mittels dieser PHP-Datei konnten andere Dateien innerhalb des gleichen Webspaces ausgelesen werden, auch die Configurations-Datei von Joomla. Somit gelangten der oder die Täter auch in die Hände der Mail-User und Passwörter für den STMP-Versand. Es wurde dann ein PHP-Programm eingespielt, daß zum Versandt von Mails verwendet werden konnte unter Verwendung der Kunden-Zugangs-Daten für den SMTP-Versandt, die ja in der Joomla-Konfigurationsdatei im Klartext abrufbar waren.

Nachdem die Programme also nun schon ein paar Tage eingespielt waren, hat der Täter dann, sein eingespieltes PHP-Programm via Seitenaufruf aufgerufen, welches im Internet-Explorer ein Formular anzeigt, daß dann nur noch ausgefüllt werden mußte, um jeweils verschiedene Absender-Daten, Empfänger-Daten und verschiedene Überschriften und Mail-Texte einzugeben (Methode Post). Dieses Formular wurde dann jeweils ausgefüllt mit Scam-Inhalten, um andere herein zu legen, ähnlich wie: „Senden Sie uns alle für uns notwendigen Daten, damit wir Sie schützen können“ – Das Gegenteil sollte erreicht werden!

Jeder hätte dieses Formular verwenden können, um Mails in alle Himmelsrichtungen mit falschen Absendern, zu verschicken, da es aber in einem bestimmten Verzeichnis eingespielt wurde, konnte es natürlich nur der jenige verwenden, der genau wußte, wo es sich befindet!

Was wollten der oder die Täter denn damit überhaupt erreichen?

Die Täter wollen, daß der Mail-Empfänger seine Daten entweder via Rückmail an eine Responder-Mail-Adresse (daß kann also eine ganz unabhängige Mail-Adresse sein, oftmals von einem anderen gehackten Webspace/Server) erfahren. Viel öfter jedoch wird der Mail-Empfänger dahin gelenkt, seine Daten in ein Formular auf einer Webseite einzugeben, die dem Unternehmen, dem er vertraut, so ähnlich aus sieht, daß er den Unterschied nicht erkennen kann. Meist wird eine solche Webseite gehostet auf einem wieder zig tausend Kilometer entfernen und ebenfalls eingebrochenen Webspace/Server und möglichst wieder in einem fernen Land, so daß die Kommunikation möglichst schwierig ist. Selbst wenn man den jeweiligen Server über das dortige Rechenzentrum, z.B. in China, ausfindig gemacht hat, kann der Hoster dort nur sperren, denn in der Regel, zeigen die Logs nur an, daß der Zugriff über einen Proxy erfolgte. Die ermittelnde Stelle, muß also den Proxy-Betreiber anschreiben, der teilt dann mit, daß der Zugriff wieder über einen anderen Proxy erfolgte usw.

Nach ausreichender Erkenntnis, Datensicherung, Beweissicherung, Sperrung des betroffenen Webspaces, haben wir den Vorgang den anderen beteiligten Providern (Internet-Zugangsprovidern/anderen Server-Providern) mitgeteilt, den Kunden Informiert und der Kunde hat bereits Strafanzeige gestellt!

Wir freuen und nun über Ihren Kommentar – nehmen Sie bitte zu diesem Thema Stellung!