Vorsicht: Rechnungs-Spam-E-Mail von Ionos mit Verschlüsselungstrojaner

Sicherheit (Pexels, allgemeine Nutzung)Kleine Warnung vor einer neuen Ransomware-Kampagne, die vermeintlich von noreply@ionos.de versandt wird. Die Mail avisiert eine Rechnung, die vom Anbieter Ionos für einen Vertrag erstellt wird. Die Rechnung ist aber ein Phishing-Angriff und enthält einen Verschlüsselungstrojaner. Das Skurrile an dieser Geschichte: Offenbar gelingt es Ionos nicht, diese Mails bei der Zustellung über die eigenen E-Mail-Server wirksam auszufiltern. Ergänzung: Solche Mails kommen auch mit angeblichem Absender von Strato, HostEurope oder anderen Providern, wobei der vorgebliche Absender gefakt ist.


Anzeige

Ich bin über Twitter mittels nachfolgend gezeigtem Tweet mit der betreffenden E-Mail auf den Sachverhalt aufmerksam gemacht worden. Der Tweet enthält einen Screenshot der betreffenden E-Mail, die einen Betrag für eine Ionos-Leitung in Rechnung stellt.

Der Empfänger der Mail schreibt im Tweet, dass diese mit einem Verschlüsselungstrojaner daherkommt und wundert sich, dass der Anbieter Ionos diese Mails nicht in seinen Filtern erkennt und ausfiltert. Es ist kein Einzelfall, da gleich zwei Personen in Antworten bestätigen, dass sie eine solche Mail ebenfalls bekommen haben. Die Antwort des Ionos-Supports:

Danke fürs Feedback. Wichtig ist, dass Sie die E-Mails über den Spam-Button filtern, damit der persönliche Spamfilter lernt, diese E-Mails zukünftig nicht mehr in den Posteingang zuzustellen. Prinzipiell können wir von unserer Seite keine E-Mails unterdrücken. Gruß

Das Thema Phishing-Mails in Verbindung mit Ionos hatte ich 2020 bereits hier angesprochen. Und es ist nicht die erste Phishing-Kampagne, die diesbezüglich läuft (siehe beispielsweise den Beitrag Phishing-Kampagne zielt auf 1&1/IONOS-Kunden).

Ergänzungen: Den Einträgen in den nachfolgenden Kommentaren entnehme ich, dass die Ionos DMARC mehr oder weniger unbrauchbar für eine Prüfung sind.

Blog-Leser haben inzwischen ja den Eingang solcher Mails bestätigt und weitere Informationen in den nachfolgenden Kommentaren geliefert. Ein HTML-Anhang kann auf eine Phishing-Seite führen, auf der Anmeldedaten abgezogen werden sollen. Oder es wird dort der Schadcode zur Installation des Verschlüsselungstrojaners bereitgestellt.

Den nachfolgend geposteten Mail-Headern ist zu entnehmen, dass diese Nachrichten nicht über die Ionos-Mail-Server verschickt, sondern nur zugestellt werden. Der Absender ist ein Drittanbieter Mailserver wie mail.hotwy.store (der Provider ist crowncloud.net aus Australien).

Ergänzung: Solche Mails kommen auch mit angeblichem Strato-Absender. Auf Facebook hat mir ein Blog-Leser folgenden Screenshot zukommen lassen.


Anzeige

Strato Phishing-Mail

Auch weitere angebliche Absender wie HostEurope oder andere Provider wurden mir berichtet. In alles Fällen stimmt der Absender in der Mail nicht mit dem vorgeblichen Absender überein.

Ziel des Beitrags hier ist auch, die Leserschaft für die neue Spam-/Phishing-Kampagne zu sensibilisieren. Vielleicht nützt es was.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

31 Antworten zu Vorsicht: Rechnungs-Spam-E-Mail von Ionos mit Verschlüsselungstrojaner

  1. Singlethreaded sagt:

    Um die Frage nach der Filterung zu beantworten wäre der Header der Mail interessant. Wurde diese wirklich über die Mail-Server von Ionos gesendet? Ich denke ehr nicht, weil dann deren Server gehackt oder als Open-Relay im Netz stehen würde. Leider habe ich diese Mail nicht aber ich würde annehmen, dass eine dritte Partei die Mail im Namen von Ionos.de über eigene Server sendet. In diesem Fall kann Ionos nicht viel tun / filtern.
    Man müsste dann den Anbieter auf der Empfängerseite in die Pflicht nehmen. Dieser muss Reverse DNS-Einträge und SFPs prüfen, wenn so eine Mail reinkommt und nach diesen filtern.

    Gruß Singlethreaded

    • Gero sagt:

      Ja, nur leider ist der SPF und dmarc Eintrag von ionos Mist… Unglaublich das ein Hoster nicht fähig ist das anständig zu konfigurieren.

    • mvo sagt:

      Das sehe ich ganz genauso. Dieses "dritte Partei" wird aber nicht über eigene Server senden (das wäre dumm, denn die würden sofort auf den Blacklists landen), sondern sich wie üblich eines Botnetzes bedienen. Je nachdem, wie plump der Absender gefälscht wurde, wird aber auch eine Reverse DNS Prüfung nichts bewirken.
      Der Anspruch, dass Ionos alle Mails mit dem Absender noreply@ionos.de ausfiltern soll, ist zudem sehr skurril.

      • Paul sagt:

        Diese "dritte Partei" darf keine eMails mit dem Absender @Ionos.de versenden. Das würde der SPF sagen, den auch Ionos.de anwenden könnte um solche eMails zu rejekten.
        Bei Kunden domains ist es schwierig. das sieht man daran, das Ionos.de auch von sehr vielen google Hosts verschickt werden dürfte und das das SPF natürlcih kaputt macht.

    • Robin Pfeifer sagt:

      Ich habe die Mail unter meiner Geschäftsadresse und zuvor privat ebenfalls erhalten. Der Anhang ist allerdings keine ausführbare Datei, sondern eine HTML-Datei, die einen IONOS-Login nachbildet. Sieht also für mich eher nach Phishing aus.

      Hier ist der Header der Mail:

      Return-Path:
      Authentication-Results: kundenserver.de; dkim=none
      Received: from mail.hotwy.store ([185.243.114.233]) by mx.kundenserver.de
      (mxeue111 [217.72.192.67]) with ESMTPS (Nemesis) id 1M1ooI-1nl50e1PRY-002Cno
      for ; Mon, 25 Apr 2022 09:29:00 +0200
      From: "Rechnungsstelle IONOS"
      To: info@computer-service-remscheid.de
      Subject: Ihre Rechnung 784544786885 =?UTF-8?B?dm9tIDI1LjA0LjIwMjIgZsO8ciBkZW4gVmVydHJhZyA=?=01554188
      Date: 25 Apr 2022 07:28:57 +0000
      Message-ID:
      Content-Type: multipart/mixed;
      boundary="—-=_NextPart_000_0012_B4740F1F.454DBB8C"
      Envelope-To:
      X-Spam-Flag: NO
      X-UI-Filterresults: notjunk: […]

      • Andreas K. sagt:

        Danke für den Header. Waren die Betreffe in beiden Fällen gleich?

        • Robin Pfeifer sagt:

          Ich weiß nicht, ob alles exakt gleich war, da ich die erste nicht näher angeschaut habe. Aber beide bezogen sich auf eine Rechnung und hatten eine angehängte HTML-Datei.

      • mvo sagt:

        Wie man sieht kommt die Mail eben nicht von Ionos sondern von mail.hotwy.store ([185.243.114.233]. Laut Whois ist Crowncloud.net aus Australien der Provider. Ein Reverse DNS führt, wie bereits von mir vermutet, zu keinen Auffälligkeiten, denn die IP Adresse entspricht dem MX Eintrag der Domäne, die über den israelischen Registrar "Namecheap" registriert wurde.
        Wenn die E-Mail lediglich auf eine Böse URL verlinkt, wird diese von den üblichen Spamfiltern der großen Provider nicht beanstandet werden.

        • cko sagt:

          Und hier die Mail an unsere Firma, gesendet von mail.raag.store ([185.243.115.236]):
          Responsible organisation: GWY IT PTY LTD
          Abuse contact info: support@crowncloud.net

          Return-Path: noreply@ionos.de
          Authentication-Results: kundenserver.de; dkim=none
          Received: from [217.72.192.67] ([217.72.192.67]) by mx.kundenserver.de (mxeue110 [217.72.192.67]) with ESMTPS (Nemesis) id 1MrzbH-1oCX1r0pOP-00nyA2 for ; Tue, 26 Apr 2022 10:36:50 +0200
          Received: from mail.raag.store ([185.243.115.236]) by mx.kundenserver.de (mxeue110 [217.72.192.67]) with ESMTPS (Nemesis) id 1M8idL-1nnPQR0fE9-004hj0 for ; Tue, 26 Apr 2022 10:36:50 +0200
          From: Kundenservice IONOS
          To:
          Subject: =?utf-8?B?SWhyZSBWZXJ0cmFnc2Jlc3TDpHRpZ3VuZyA1MzEwMTQzNA==?=
          Date: Tue, 26 Apr 2022 08:36:49 +0000
          Message-ID:
          Content-Type: multipart/mixed;
          boundary="—-=_NextPart_000_0012_ABFABEAC.A8B7208D"
          Envelope-To:
          X-Spam-Flag: NO
          X-UI-Filterresults: notjunk:1;

        • Robin Pfeifer sagt:

          Die Mail hat eine HTML-Datei im Anhang. Diese lädt in erster Linie tatsächlich grafische Elemente von IONOS selbst herunter, um deren Login nachzuempfinden. Es gibt eine längere codierte Sequenz in einem Javascript:

          document.write(unescape('%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3C%64%69%76%20%63%6C%61 […]

          Diese Sequenz, wenn man sie dekodiert, erstellt das Login-Formular unter Bezug auf IONOS-Elemente. Das Formular wird aber dann über die Action https:// email-businessionos.su/ionos/api.php abgearbeitet.

          Es scheint sich also um Phishing zu handeln. Wenn auch ein Erpressungstrojaner ins Spiel kommt, dann vielleicht sekundär?

    • Jens sagt:

      Ich verstehe es eher so, dass der Empfänger die böse Email in seinem Ionos-Postfach zugestellt bekommen hat. Und das sollte Ionos auf jeden Fall unterbinden können.

    • Paul sagt:

      Em.. Es gibt wohl kaum noch MXe die Emails von Hosts annehmen, die keinen rev. DNS haben.
      Das waren schon immer schlecht gewartet oder gehackte Systeme die nicht für den Email Versand gedacht waren.

      SPF kennt nur IP Adressen, keine User.dir eine Domain benutzen dürfen.

  2. El Barto sagt:

    Offensichtlich hat der Oliver Contney von Spoofing noch nie etwas gehört, geschweige denn, dass er zur Veranlassung geeigneter Gegenmaßnahmen fähig wäre. Wobei mir der Screenshot spanisch vorkommt. Wo ist die Anlage mit dem Trojaner?

  3. A. Nonym sagt:

    Ionos schafft auch nicht einen C&C Server innerhalb von 5 Tages nach "abuse-complain" abzuschalte:

    https://feodotracker.abuse.ch/browse/host/217.160.107.189/

  4. Egal sagt:

    Hier geht es doch wohl eher darum, dass die Mail vor dem Empfang an einem Email-Account von Ionos ausgefiltert werden könnte und auch sollte!?

    • Günter Born sagt:

      Jein – der ursprüngliche Twitter-Post hatte dieses Ziel. Da hat der IONOS-Support aber drauf geantwortet. Mir ging es beim Blog-Beitrag vorrangig darum, bei der Leserschaft und bei mir "ein Bit zu setzen", dass da was war und man achtsam sein sollte. Ob es wirkt? We will wait and see.

    • Paul sagt:

      Ich vermute mal. das jeder Ionos eine eMail-Adresse Kunde@Ionos bekommen hat.
      (Was eine sehr dumme Idee gewesen wäre)
      Der Kunde benutzt diese eMail adresse als Absender, ganz legal,
      weil er die ANtworten auf diesen Account haben möchte.
      Der benutzt den Outgoing-Mailhost seines DSL-Providers um einen anderen Kunden bei Ionos anzuschreiben.
      Wenn Ionos nun diese eMail rejekten würde, wäre der Kunde nicht wirklich glücklich, obwohl sie Recht haben.
      Ich habe aber Zweifel das ein Jurist das ebenso sieht…
      Warum also sollte Ionos arbeit darein stecken?
      IP ist billig.

      Klar das der Kunde der andere über den Mail host seines DSL-Providers anschreibt bei denen gegen eine Wand fährt. Aber der SPF von Ionos ist nur "optional" zu bewerten…

      Das ist alles nicht so einfach, wenn man es den Kunden (und sich) einfach machen will..:-)

  5. Bernd sagt:

    Hatten wir jetzt auch von all-inkl. Der Anhang war auch eine HTML und man sollte User und PW eingeben. Der Anhang begann mit Document.write(

  6. Der Gute Spion Der Mich Liebte sagt:

    was ist eigentlich die logik dahinter dass riesen firmen und AGs hier z.B. ein mail und hostinganbieter nichtmal ihre eigene Domain derart schuetzen koennen? wollen? duerfen? (siehe der twitter reply? oder was verstehe ich hier falsch??) dass sie nichtmal ihre eigenen direkten Kunden (bin Kunde direkt bei ionos und erhalte die fake ionos mails auch) schuetzen ?

    das kapier ich nicht? ein faker macht quasi betrug, urkundenfaelschung oder eben missbrauch im namen der AG: diese AG ist der Postdienstleister des Kunden bei AG. die AG nimmt briefbombe, fake notarurkunde, fake vertrag, fake-you-name-it und stellt sie seinem eigenen Kunden der AG zu.

    wo wie um himmels willen ist da die logik dass sie das nicht koennen? oder besser schuetzen wollen wuerden etc?

    WTF? bitte echt mal um saubere und vollstaendige erklaerung dieser sachlage? ich muss echt im falsche universum leben ich sehe absolut keinerlei grund um sowas nicht zu verhindern.

    anyone? danke

    • mvo sagt:

      Nun ja. Die Absenderadresse einer E-Mail zu fälschen ist genauso einfach, wie die eines Briefes. Wenn ich nun einen Brief per Post an Dich schicke und als Absender "Deutsche Post AG" draufschreibe, dann würdest Du auch nicht erwarten, dass die Post diesen Brief als Fälschung erkennt und abfängt.

    • Paul sagt:

      Die Frage kann nur ionos.de beantworten, denn:

      Zu einer Zeit als Wünschen noch geholfen hat, gab es ein paar Menschen die wollten sich Briefe elektronisch zusenden.
      Sie kannten und vertrauten sich und sahen keinen Grund, warum jemand mit einem falschen Absender eMails verschicken sollten (Vgl. Warum sollte jemand sein eigenes Impfbuch fälschen?)
      also wurde nichts, absolut garnichts dafür vorgesehen den Absender zu verfizieren.
      Zu dem gingen damals die meisten, wenn überhaupt nur wenige Minuten mit einem Modem online. Damit sie ihre eMails los werden konnten suchten sich irgendeinen der (wenigen oft universitären) eMail Server, deren Default-Installation "relayen" erlaubte, denn dieses galt als elegante Geste. Dort kippten sie ihre ihre 2..3 eMail ab, obwohl sie nichts mit dieser Uni zutun hatten. Daher war es üblich, das beliebige Hosts eMails mit beliebigen Absendern versendteten. Wenn es den Empfänger nicht gab oder sein Postfach voll war schickte dieses offene Relay eine Bounce Mail an den Absender (der natrülich nie gefälscht war. Warum sollte man? Dann hätte man ja diese Info nicht mehr bekommen…
      Wie wissen wie es weiterging.
      Dieses Vertrauen wurden von Kriminellen ("Spammern") ausgenutzt.
      Heute gilt es als extrem Unfein, eMails Dritter zu relayen, oder eMails direkt von einem DialUp am den MX des Empfänger zu schicken.

      Ein Problem war die fehlende Überprüfung der Hosts der eMails mit dieser Domain versenden durfte. (Wie gesagt oft irgendwelche Uni-rechner)
      Man erfand "spf". Einen Text-Record im DNS -Eintrag für diese Domain.
      Da standen dann alle IPs von den Hosts drin, die eMails mit dieser Domain im Absender versenden durften.
      $nslookup -type=TXT ionos.de
      ionos.de text = "v=spf1 redirect=_spf-corporate.ionos.com"
      Emm ja…"nett" ist das nicht, also den nächtsen
      _spf-corporate.ionos.com text = "v=spf1 a:moi.1and1.com a:moint.1and1.com a:mxint.1and1.com a:mbulk.1and1.com include:_spf.google.com ~all"

      Super, also die Name nach IPs auflösen und dann auch noch den SPF von Google einbinden, falls nix dabei.
      _spf.google.com text = "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

      Emm, und wieder in den DNS.
      _netblocks2.google.com text = "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"

      Immerhin stehen da den gleich die IPs drin…

      Aber mehr als 10mal darf man keinen DNS wg. spf befragen…IIRC

      OK, so könnte aber jeder (inkl. ionos.de) feststellen, ob der Host diese eMail versenden durfte und sie als Spamverdächtig markieren…(vgl. das "~" vor dem "all"

      ionos.de weiss aber das das ihre eigene Domain und das diese nur von den eigenen Server kommen kann und könnte sie rejekten.

      Es fragt sich also:
      Warum rejctet ionos.de solche eMails nicht?
      Vermutlich zuviel arbeit oder man will dem Kunden extra Spamfilter verkaufen.

      Also demnach könnte ionos.de seine Domain zumindest auf dem eigenen Mailserver schützen…
      aber das erfordert bei jeder eMail viele ("teure") DNS Abfragen und mit DKIM-Signierung auch nach viel rechenleistung.
      Also nimmt man einfach alles für diese Domains an und leitet das 1:1 an die Kunden weiter. Anstatt 10 emails pro Tag bekommt dieser dann 20000 eMails pro Tag davon 19990 an unbekannte Empfänger in seiner Domain.
      Er macht also 19990 bounces an arglose Opfer und der Spammer hat seinen Spam da wo er ihn hinhaben will und der eigene Mail server landet auf eine "back scattering" blacklist…alles nicht so einfach…
      Das Mail volumen könnte man aber auf einen Bruchteil reduzieren in dem ionos.de wüsste, welche Empfänger seine Kunden hat und die falschen gleich rejectet. Dafür gibt es Protokolle und Datenbanken. Aber das kostet alle.
      IP ist billiger als man power.
      Außerdem wüsste der Spammer damit, welche Adresse es wirklich gibt…
      das ist aber das kleinere Übel, denn jetzt hätte man rechenzeit für spf in dkim…und spammer warten nicht besonders lang auf antwort. Wenn sie ein paar Sekunden hängen läßt ehe man den 550 schickt sind sie schon vorher weg.

      Eigentlich macht man heuta auch noch DKIM, weil die Spammer das spf auch umgehen. Wer mag kann sich ja mal das SPF von bluehost anzeigen lassen.
      Auch ein Massenbillighoster…mit noch kaputterem spf.

      HTH

      • mvo sagt:

        Alles sehr schön erklärt. Wer einen eigenen Mailserver einsetzt, sollte auch so vorgehen. Allerdings gibt es derartige Maßnahmen bei KEINEM der üblichen E-Mail Anbieter wie T-Online, GMX, Google und wie sie alle heißen. Wir haben immer wieder den Fall, dass Geschäftspartner, vornehmlich aus China,ihre Mailserver schlampig konfiguriert haben, so dass unser Mailserver die Mails nicht annimmt. Diese Mails werden aber ausnahmslos von den genannten Providern angenommen. Ionos ist somit kein Einzelfall. "you get what you pay for". Nicht nur, dass diese Provider praktisch jede Mail durchlassen, sie lesen die eingehenden Mails auch systematisch mit. Insofern ist es mir schleierhaft, wieso man überhaupt über solche Adressen kommuniziert.

  7. Blupp sagt:

    Danke. Sensibilisierung ist immer gut.
    Vorgebliche Ionos-Mails gehen hier schon länger ein, bisher aber noch keine die vorgibt eine Rechnug zu sein. Da wir bei Ionos nicht Kunde sind, werden diese Mails von vornherein passend behandelt.

  8. Sven Fischer sagt:

    Da geht zur Zeit ne Menge Crap rum. Ich habe in meinem Postfach von der Firma auch so ominöse Mails. Im Anhang: Rechnung-……html. Beim Link landest man dann bei globalpoint.es Webmail Login.

    Return-Path:
    Received: from www204.your-server.de
    by www204.your-server.de with LMTP
    id 6J5eLpJPZmKbTgAAphIeYA
    (envelope-from ); Mon, 25 Apr 2022 09:36:50 +0200
    Envelope-to: info@itsysteme-fischer.de
    Delivery-date: Mon, 25 Apr 2022 09:36:50 +0200
    Authentication-Results: www204.your-server.de;
    iprev=pass (thtwentynine.tarhely.eu) smtp.remote-ip=185.51.191.29;
    spf=pass smtp.mailfrom=bognarvendeghazzirc.hu;
    dkim=pass header.d=bognarvendeghazzirc.hu header.s=default header.a=rsa-sha256;
    dmarc=skipped
    Received: from thtwentynine.tarhely.eu ([185.51.191.29])
    by www204.your-server.de with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
    (Exim 4.92.3)
    (envelope-from )
    id 1nitH8-0005Ss-65
    for info@itsysteme-fischer.de; Mon, 25 Apr 2022 09:36:50 +0200
    DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
    d=bognarvendeghazzirc.hu; s=default; h=Content-Type:MIME-Version:Date:Subject
    :To:From:Reply-To:Message-ID:Sender:Cc:Content-Transfer-Encoding:Content-ID:
    Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
    :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
    List-Subscribe:List-Post:List-Owner:List-Archive;
    bh=amYWJgSxSDA/zgdjUZth7iA589Oasd+zeCiOAwMrk54=; b=G34+nlv0/GV2gnom89M+6vxp76
    y6N8izvB0NI8X3OBG43dMqLFXH9wvm05h2QiEPpCcksSt5Gzau1PGFXg5/4giJHFWfV5aUewuqYtQ
    rBdZOV4imrR8IbO+AwXpVi7c3VNdGoTcCCjFGF6/g4k22tK/jjdl7KC2lm/I3q76dV7tkwc1zD2St
    pWRuofGeynUQTdyrh89r3RWZ1hi4IEGRBlkhc2VVyHPM3VwaHTzH4Zb83TB3BfPSrUPvOcP/J5k85
    k7/BjrltaD8++tPkNxkj5PoMKnXb1/LQwyy15SrXM1uX7PEeXI0/GqnvPjqvSm34/bxfBASjrbG0u
    F0Bbt7iQ==;
    Received: from ec2-18-197-97-0.eu-central-1.compute.amazonaws.com ([18.197.97.0]:64557 helo=localhost)
    by thtwentynine.tarhely.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    (Exim 4.95)
    (envelope-from )
    id 1nitGv-00Cr6w-SG
    for info@itsysteme-fischer.de;
    Mon, 25 Apr 2022 09:36:41 +0200
    Message-ID:
    Reply-To: Rechnungsabteilung-Host
    From: Rechnungsabteilung-Host
    To: info@itsysteme-fischer.de
    Subject: Ihre Rechnung, Rechnungs-Nr.137784 vom 25.04.2022
    Date: Mon, 25 Apr 2022 07:36:34 +0000
    MIME-Version: 1.0

    Lustig, jeden Tag was neues.

  9. Extrawurst sagt:

    > Man müsste dann den Anbieter auf der Empfängerseite in die Pflicht nehmen. Dieser muss Reverse DNS-Einträge und SFPs prüfen, wenn so eine Mail reinkommt und nach diesen filtern.

    Du weißt aber schon, dass im konkreten Fall der E-Mail-Anbieter der Empfängerseite Ionos ist?

  10. Herr IngoW sagt:

    Habe Gestern (25.04.2022) so ein ähnliche E-Mail, angeblich Sparkasse.
    Bin ja kein Kunde da.
    War schon an der Absender-Mail-Adresse zu sehen das das Unsinn ist.
    Angebliche Änderung durch die IT, man solle sich doch über einen Link anmelden.
    Also weg damit!!!!

  11. Judith sagt:

    Ist es jetzt "nur" ein Phishing-Angriff oder doch ein Verschlüsselungstrojaner dabei?

  12. Brezensalzer sagt:

    Das kann ich alles bestätigen. Das ging schon vor mehreren Monaten los:

    In meinem Falle kamen zahlreiche Mails an, deren Absenderadresse die eMail-Adresse des Empfänger-Postfachs war (!) und Phishing-Formulare als HTML-Attachments enthielten.

    Ich dachte zuerst: Hey, da hat eine Spammer-Gang eine trickreiche Möglichkeit gefunden, Spam zu delivern indem sie irgendwelche hochspezifischen Schwachstellen bei den IONOS-MXern nutzen.

    Ich hätte mir im Traum nicht vorstellen können, dass so ein riesiger Mailhoster es nicht auf die Reihe bringt, SPF so zu implementieren wie es sich gehört!! Ich hab mal ein halbes Jahr an genau denselben Problemen des eMail-Systems eines Mittelständlers gearbeitet – und habs als Teilzeit-Mailserver-Admin mit begrenzter Zeit, ein wenig Recherche und extrem vielen Tests zur Zufriedenheit aller hinbekommen. Das ein Riesen-Konzern wie 1&1 / IONOS hingegen sowas grundlegendes nicht hinbekommt find ich echt bitter!! Da arbeiten doch sicher zig Leute in deren Mail-Abteilung.

    Und jetzt seit mehreren Wochen kommen nun wie bei den anderen Opfern oben schon geschildert angebliche Rechnungen mit IONOS-Absender im From: – Header durch und HTML-Attachments.

    Der Theorie, dass IONOS das schon seit Monaten so laufen lässt weil sie damit die separat zu bezahlenden Spamfilter-Optionen verkaufen können will ich jetzt mal nicht beipflichten, denn dafür hab ich keinen Insight was bei denen läuft. Das wäre eine Unterstellung.

    Aber es ist schon ein starkes Stück, dass die ein so grundlegendes und gravierendes Sicherheitsproblem (ja, das ist eins, denn technisch wärs möglich das abzustellen) so lange nicht beheben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.