Mail delivery failed: returning message to sender

Seit gestern bekomme ich mehrmals stündlich folgende E-Mails in mein Postfach:

This message was created automatically by mail delivery software.
Error
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  xyz@mail.ru
    SMTP error from remote mail server after end of data:
    host mxs.mail.ru [94.100.180.104]: 550 spam message rejected. Please visit http://help.mail.ru/notspam-support/id?c=WMigd_PLYuHmakzNLb3CXKQa0-GwN0i5g6somqCPuTsEAAAAuccBAC4KwyA~ or  report details to abuse@corp.mail.ru. Error code:
    77A0C858E162CBF3CD4C6AE65CC2BD2DE1D31AA4B94837B09A28AB833BB98FA0. ID:
    000000040001C7B920C30A2E.

------ This is a copy of the message's headers. ------

Return-path: <meine-email@it-freelancer-magazin.de>
Received: from vwp16331.webpack.hosteurope.de ([111.111.111.111] helo=www.it-freelancer-magazin.de); authenticated
	by vwp16331.webpack.hosteurope.de running ExIM with esmtpa
	id 1ewLyd-0001NJ-PT; Thu, 15 Mar 2018 07:02:59 +0100
Date: Thu, 15 Mar 2018 06:02:59 +0000
To: xyz@mail.ru
From: IT Freelancer Magazin <newsletter@it-freelancer-magazin.de>
Reply-To: meine-email@it-freelancer-magazin.de
Subject: =?UTF-8?Q?Bitte_best=C3=A4tigen_Sie_die_Registrierung_-_IT_Freelancer_Mag?=
 =?UTF-8?Q?azin_newsletter?=
Message-ID: <145763c7cfe0c93637c1de363c59e053@www.it-freelancer-magazin.de>
X-Mailer: PHPMailer 5.2.22 (https://github.com/PHPMailer/PHPMailer)
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

Schaut man sich diese E-Mails genauer an, dann haben alle Adressaten russische Mail-Accounts. Außerdem weist der Subject darauf hin, dass jemand versucht, meine Newsletter-Anmeldung zu missbrauchen, um die Adressaten mit meiner Anmelde-Bestätigungs-Email vollzuspamen. Ein Blick in meinen WordPress-Newsletter Subscription-List zeigt, dass tatsächlich viele Pseudo-Anmeldungen auf russische Mail-Konten stattgefunden haben. Ein Blick in die Datenbank offenbart, dass viel mehr Anmeldungsversuche stattgefunden haben, als ich E-Mails bekommen habe. Dies deutet wiederum darauf hin, dass meine Anmeldeaufforderung tatsächlich in deren Mailboxes gelandet ist und nicht von deren Mailserver abgelehnt und an mich zurückgeschickt wurden.

Vermutlich soll durch diesen Angriff mein newsletter geblacklistet werden.

Schnellmassnahmen

Newsletter-Anmeldeseite vom Netz nehmen.

Prüfe ob Deine IPv4, IPv6 oder newsletter-email-adresse hier geblacklistet ist.

Langfristige Maßnahmen

Richte Captcha ein.

Prüfe nach einiger Zeit, ob Deine IPv4, IPv6 oder newsletter-email-adresse hier geblacklistet ist.

IP Verbindungen samt Dateipfad des Prozesses monitoren

TCPViewer

TCPViewer: Die eindeutig bessere Alternative zu netstat. Es ist übersichtlicher, enthält den Dateipfad zu den Prozessen, die zu einer Verbindung aufgebaut wurden und mit dem kleinen Bruder TCPVCon kann man die Daten als .csv abspeichern.

IP-Verbindungen leuchten von Zeit zu Zeit farbig auf, um die Aufmerksamkeit des Users zu erregen:

grün: Frisch geöffnete endpoints

blau: Gerade geschlossene endpoints

gelb: endpoints haben den Status gewechselt.

 

Process Monitor

Eigentlich hat dieses Tool den Schwerpunkt auf Prozesse, ist jedoch das perfekte Tool, um Events so weit einzuschränken, um die Datei zu finden, die verdächtige IP Connections aufbaut.

Den Filter muss man um folgende beiden Entries erweitern:

Operation contains TCP Include
Operation contains UDP Include

Nun filtert man nach und nach unverdächtige Prozesse raus (bsps.weise firefox.exe) bis die potenziellen Schadprozesse übersichtlicher sind.

Windows Firewall Logging

Beim gehijackten Server, kann man verdächtige Aktivitäten im Firewall-Log genauer analysieren. Dort wird jedoch leider nicht die Quelle der verdächtigen Aktivitäten (also der Prozess) protokolliert.

Das Firewall-Log wird per default in %systemroot%\system32\LogFiles\Firewall als pfirewall.log gespeichert und ist leer, muss also erst eingeschalten werden.

Das Menü zum Einschalten des Firewall-Loggings findet sich im Programm „Firewall mit erweiterter Sicherheit“: Aktion -> Eingenschaften. Dann für alle drei Profile (Domänenprofil, …) -> Anpassen -> dort die Protokollierung mit zweimal „Ja“ einschalten.

Das Runterfahren von Windows war zumindest bei meinem letzten Einschalten vom Firewall-Log nicht notwendig. Wenn alles korrekt funktioniert, dann wird jeder(!) Aufruf einer Webseite in einem Browser zu zahlreichen Einträgen im Log führen.

Falls dies nicht der Fall ist, dann kann das möglicherweise daran liegen, dass der Windows-Firewalldienst keine Schreibberechtigungen für den Protokollordner hat:

Navigieren Sie zu dem Ordner, den Sie für die Protokolldatei angegeben haben, klicken Sie mit der rechten Maustaste darauf, und klicken Sie dann auf Eigenschaften.
Klicken Sie auf die Registerkarte Sicherheit, und klicken Sie dann auf Bearbeiten.
Klicken Sie auf Hinzufügen, geben Sie im Feld Geben Sie die zu verwendenden Objektnamen ein den Namen NT SERVICE\mpssvc ein, und klicken Sie dann auf OK.
Überprüfen Sie im Dialogfeld Berechtigungen, ob MpsSvc über Schreibzugriff verfügt, und klicken Sie dann auf OK.

Dann mit einem als Administrator gestarteten Editor die Log-Datei öffnen.

Interpretation des Firewall Logs

Nachdem die Analysephase vorbei ist, muss das Log wieder abgeschalten werden, damit durch die schnell anwachsenden Log-Files nicht irgendwann die Festplatte zu ist.

netstat

Sobald der Server kompromitiert wurde, kann man netstat nutzen, um eine erste Analyse vorzunehmen.

Übersichtlicher und v.a. für die Anaylse besser geeignet (da beim Prozessnamen auch noch der Pfad dazugeliefert wird ist jedoch TCPView (von Mark Russinovich)

Aufruf

cmd als Admin starten.

netstat -ob

Um die PID zu identifizieren, die hinter den IP-Verbindungen stehen, muss man -o als Parameter wählen. Um die Prozessnamen aufzulisten, braucht man -b

Refenrenz für verschiedene Parameter: https://technet.microsoft.com/en-us/library/bb490947.aspx

 

Spalte: Lokale Adresse

127.0.0.1  diese Ports lauschen nur auf Verbindnungen vom Computer selbst -> hier kann keine Gefahr bestehen

0.0.0.0  —>  hört an allen network interfaces (also Computer, Modem, Netzwerkkarte)

[::]   —>   bedeutet in IPv6 nichts anderes als 0.0.0.0

10.X.X.X (also die IP welche das Intranet für meinen Computer vergeben hat)   —>    hört / verbindet sich nur mit Adressen im Intranet

:*   —>   der Port ist noch nicht etabliert.

Quelle: http://stackoverflow.com/questions/20882/how-do-i-interpret-netstat-a-output

 

Status

http://stackoverflow.com/questions/20882/how-do-i-interpret-netstat-a-output