Das Unternehmen WEKO Wohnen GmbH hat die Woche eine E-Mail an diverse Kunden geschickt, in der vor Phishing-Mails, die im Namen des Unternehmens verschickt werden, gewarnt wird. Es wurden mutmaßlich zwei Mitarbeiter-Konten gehakt. Ich habe die Phishing-Mail, die angeblich ein PDF auf OneDrive hostet, mal etwas genauer angeschaut und das Ganze dokumentiert. Scanner wie Virustotal schlagen übrigens nicht an.
Ein Leserhinweis zur Weko-Warnung
Blog-Leser Benjamin S. hat mir zum 12. November eine Warnung vor Phishing-Mails im Namen von weko.com zugeschickt. Die WEKO Wohnen GmbH ist ein Hersteller von Büromöbeln, und Unbekannte missbrauchen den Namen, um Phishing-Mails zu versenden.
Die Phishing-Mail im Namen von Weko
Nachfolgender Screenshot zeigt den Inhalt der Phishing-Mail. Es handelt sich um eine E-Mail, die im Namen einer Weko-Projektleiterin verschickt wurde und sich angeblich um Planungsunterlagen für eine Küche dreht.
Der dort angegebene Link führt auf ein OneDrive-Laufwerk, der von Virustotal nicht bemängelt wird. Ich habe das Ganze weiter analysiert.
Phishing-Dokument auf OneDrive
Auf dem OneDrive-Laufwerk findet sich dann eine PDF-Datei, die der Empfänger öffnen soll.
Der Kontextmenübefehl zum Kopieren des Links "KLICKEN SIE HIER, UM DAS DOKUMENT ANZUSEHEN" ist gesperrt. Zeigt man auf den Link, wird in der Fußzeile die URL https: //prozessing. spbrealty. info/safe eingeblendet. Das ist aber lediglich eine in den USA gehostete Webseite ohne weitere Inhalte, die der Phisher für eigene Zwecke angelegt hat.
Die Phishing-Seite
Klickt der Empfänger der Phishing-Mail auf den betreffenden Link, um das vermeintliche Dokument mit der Küchenplanung als PDF anzusehen, wird folgendes angezeigt. Die Seite erweckt den Anschein, dass ein besonders gesichertes Dokument der Anzeige harrt.
Die Schaltfläche Sign In with Microsoft to Access zeigt aber, wessen Geistes Kind das Ganze ist. Klickt der Empfänger auf die Schaltfläche und gibt die Anmeldedaten für sein Microsoft Konto ein, hat der Phisher Erfolg und die Daten sind weg.
Der Header der Mail
Nachfolgend habe ich mal den Header der betreffenden Phishing-Mail zur Information eingestellt.
Received: from FR5P281MB4764.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:151::5) by FRYP281MB0174.DEUP281.PROD.OUTLOOK.COM with HTTPS; Wed, 12 Nov 2025 10:28:10 +0000 ARC-Seal: i=3; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=fail; b=UaSlLenEYv8lMdAugB4QNgc0oeUX1ZzIetuaf6Q1tb4QKWIBYAPKJumyiVzDNcABKMOZLm41W8yIacU0VvJFcEmP0Z3lYzlnBHgskdzYwsFg4bHnSy0Se5DT2HctjXKnTzw/xlNwHuEbThaRMkNu4161CvCftIlCbJo9s8kT9qGM8KBPu+0ew4SyD4qcq85d7pxVo0bZjU7PUNJeSkm3mDRHpcml8FskTmLTb0AYr1nym0ecvyH6vT+C/Lue35iay/adB4aHZ8vc7GQ6mnf8IEIxR/H92e+Ea2tJi2nfst20ahH/bZt7BgqSRidLjaA4g18YE+MBGW3ZjNQW+y/EAw== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cgGshnm3qk7dfmxDUehsoPo7QA3q1ZjbX+fuEyX7Iks=; b=Dn1YkXftDvYlUW0gJ2VSzagWlPJD2Pu+UaK9yNf9bW2beU7VEojT2L+6dNPOnPmT9XhuYLUhHLz5MCRTJ/npY1AmTIRf2GbG/3vVewTIQ2hk5QfppkAn1ICQGHXlDcKpBXn5Sh8FSU4VBzGpRGI/EIJyHAkFBz4iMx7Jj+6IuQj9x/y8U6N6pAQgPoUmfQdq+ry7j2qayWra0J5ezjDGm0DOy6SgOgMYaensRR4XLm8vl+EecMiQI/tSzXRaCfHQVO1oWv6GjWR8lGq1iajZIweTzvZxZ3vK5aiLSqkpYalr6XpvYM+EEp8ijUokacKUhK3H09nPiOLCCXEJMwOIPw== ARC-Authentication-Results: i=3; mx.microsoft.com 1; spf=pass (sender ip is 94.100.128.29) smtp.rcpttodomain=oh-muenchen.de smtp.mailfrom=weko.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=weko.com; dkim=fail (signature did not verify) header.d=weko.com; arc=fail (48) Received: from FR4P281CA0214.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4::10) by FR5P281MB4764.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:151::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9320.15; Wed, 12 Nov 2025 10:25:53 +0000 Received: from FR2PEPF000004EF.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e4:cafe::a0) by FR4P281CA0214.outlook.office365.com (2603:10a6:d10:e4::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9320.16 via Frontend Transport; Wed, 12 Nov 2025 10:25:52 +0000 Authentication-Results: spf=pass (sender IP is 94.100.128.29) smtp.mailfrom=weko.com; dkim=fail (signature did not verify) header.d=weko.com;dmarc=pass action=none header.from=weko.com;compauth=pass reason=100 Received-SPF: Pass (protection.outlook.com: domain of weko.com designates 94.100.128.29 as permitted sender) receiver=protection.outlook.com; client-ip=94.100.128.29; helo=mx-relay19-hz1-if1.hornetsecurity.com; pr=C Received: from mx-relay19-hz1-if1.hornetsecurity.com (94.100.128.29) by FR2PEPF000004EF.mail.protection.outlook.com (10.167.240.36) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9320.13 via Frontend Transport; Wed, 12 Nov 2025 10:25:53 +0000 ARC-Authentication-Results: i=2; mx-gate19-hz1.hornetsecurity.com 1; spf=pass reason=mailfrom (ip=52.101.69.100, headerfrom=weko.com) smtp.mailfrom=weko.com smtp.helo=am0pr83cu005.outbound.protection.outlook.com; dmarc=pass header.from=weko.com orig.disposition=pass ARC-Message-Signature: a=rsa-sha256;
Die Mail stammt also von Weko und das Unternehmen bestätigt weiter unten, dass kompromittierte E-Mail-Konten zum Versand missbraucht wurden..
Die Warnung von Weko
Weko hat dann die Empfänger dieser Phishing-Mail kontaktiert und eine Warnung mitgeliefert. Ich stelle den Inhalt der Mail, in der die WEKO Wohnen GmbH vor diesen Phishing-Mails warnt, hier mal zur Informationen ein.
Von: *** <***@weko.com>
Gesendet: Mittwoch, 12. November 2025 12:47
An: it-security@weko.com <it-security@weko.com>
Betreff: Phishing-Mail von weko.com
ACHTUNG: Diese E-Mail stammt von einem externen Absender. Bitte vermeiden Sie es, Anhänge oder externe Links zu öffnen
Sehr geehrte Damen und Herren,bitte beachten Sie, dass heute eine Phishing-E-Mail aus unserem Hause an einen begrenzten Personenkreis versendet wurde. Sie sind einer der Empfänger.
Die Nachricht wurde über das Postfach von Frau ***(***@weko.com) oder Herrn **** (***@weko.com) verschickt, deren Zugang unbefugt verwendet wurde.
Wichtige Hinweise:
- Öffnen Sie keine Anhänge und klicken Sie auf keine Links in der betreffenden E-Mail.
- Geben Sie keine Benutzer, Passwörter oder andere Daten ein.
- Löschen Sie die Nachricht sofort aus Ihrem Posteingang.
- Sollten Sie bereits auf einen Link geklickt oder einen Anhang geöffnet haben, informieren Sie bitte umgehend Ihre IT-Abteilung.
- Ändern Sie ggf. Ihr Passwort
Der Vorfall wird derzeit untersucht, und es wurden bereits entsprechende Sicherheitsmaßnahmen eingeleitet, um weiteren Versand zu verhindern.
Rückfragen bitte an die Mail-Adresse it-security@weko.com.
Vielen Dank für Ihre Aufmerksamkeit und Ihr umsichtiges Handeln.
Freundliche Grüße
***
Datenschutz & Compliance-Manager
Recht & Risiko
Ich habe in obiger Mail die Namen der Beteiligten verschleiert. Es sieht so aus, dass zwei Benutzerkonten des Weko-Mailsystems gehackt und zum Mailversand missbraucht werden konnten.
MVP: 2013 – 2016
dig MX weko.com liefert aber andere IPs als die Absender IP 94.100.128.29
Keine DMARC Policy Reject = kein Mitleid
Nutzen schon einen 3rd Party Security Anbieter und schaffen es immer noch nicht?
Merksatz: Auch Phisher können Kunden bei dem Sicherheitsanbieter oder Cloudanbieter sein und von dort aus Ihre Mails versenden.
@Tomas Jakobs:
Die Absender-IP 94…. (zu hornetsecurity gehörend) muss aber nicht im MX record auftauchen, wenn man Empfang und Versand technisch trennt.
Weko schreibt:
"Die Nachricht wurde über das Postfach von Frau ***(***@weko.com) oder Herrn **** (***@weko.com) verschickt, deren Zugang unbefugt verwendet wurde."
Damit wurden die Phishing-Emails aus derselben Infrastruktur versendet wie alle legitimen Emails auch. Selbst ein korrekt gesetzter DMARC-Record p=reject hätte dann nichts genutzt, weil ja SPF und DKIM gestimmt hätten.
PS: Ich hoffe mal nicht, dass ein Phisher bei einem Email-Dienstleister wie hornet-Security mit der Domain eines Kunden senden und der Domain des Kunden DKIM-signieren kann. Das darf nicht möglich sein. Sendgrid z.B. macht die Absicherung IMHO recht gut.
> Die Absender-IP muss aber nicht im MX record auftauchen, wenn man Empfang und Versand technisch trennt.
kann man machen, scheitert bei vielen aber bei fehlerhaften SPF, PTR und DKIM und die Mails werden von jedem sauber konfigurierten Server abgewiesen.
> deren Zugang unbefugt verwendet wurde.
Dann wundert es mich allerdings, dass ein User mit Massenmails nicht längst rgendwelche Quotas gerissen hat. Oder doppelte Anmeldungen von unterschiedlichen Geräten/Stellen unbemerkt bleiben.
Kann man drehen und wenden wie man will, am Ende des Tages bleibt's an denen selbst hängen.
> Damit wurden die Phishing-Emails aus derselben Infrastruktur…
Also Microsoft + Hornet…
> Ich hoffe mal nicht, dass ein Phisher bei einem Email-Dienstleister wie hornet-Security mit der Domain eines Kunden senden und der Domain des Kunden DKIM-signieren kann.
Ich erinnere, dass bei IONOS/ 1&1 das genau bis vor einigen Jahren jeder Kunde mit seiner eigener Domain konnte: Mit einer anderen Absenderdomain, die auch bei Ionos lag, im Namen des anderen Mails zu versenden.
Mit div. Credt-Card Generatoren kann man für kurze Zeit überall Server und Abos Schiessen. Zur Not wird schnell eine Firma irgendwo in einem Inselstaat inkl. Bankkonto gegründet.
Woher kommt die Annahme, dass die bösen Mädels und Jungs nicht die gleichen Dienste nutzen, wie die braven?
Da das hier leider nicht zur Sprache kam und HS so kritisch beäugt wird, muss man hier mal eine Lanze für sie brechen: Sie haben den Mailversand eines kompromittierten Kontos nach ca. 1h von sich aus unterbunden, was Luft gab, um die Lage einzuordnen.
Im Nachgang fiel auf, dass der Angreifer auch eine Regel erstellte, die alle eingehenden Mails in den Deleted-Ordner verschob. Die Regel war zunächst legitim benannt, weshalb das Problem initial nicht auffiel.
@Seiberwohr: HS = Hornsecurity? Das Unterbrechen des Mailversands von Massen-Phishing-Emails ist zu loben. Allerdings können in einer Stunde schon viele Emails verschickt worden sein. Wieviele waren es denn in Summe?
>> Regel erstellte.
Das ist das übliche Vorgehen. So bekommt der gekaperte User nicht sofort mit, dass z.B. NDRs oder Rückfragen eintreffen, die ihn auf die verdächtigen Emails aufmerksam machen.
Es handelt sich bei den betroffenen Usern ja wohl um MS365-Accounts. Weiß man, wie diese "gekapert" wurden? Gab es kein MFA?
MFA hin oder her. Ich bin zwischenzeitlich zu der Erkenntnis gelangt, dass nur registrierten Gerät ein Login auf irgendwelchen Cloud Diensten erlaubt sein darf.
Also Absicherung mittels eines Hardware basierten Gerätes .
Angesichts der Tatsache, dass da zunehmend Password Manager/Passphrases dranhängen ist das der einzige Weg der so hinreichend sicher ist, dass ich ruhig schlafen kann.
Heißt aber halt auch: für das Szeanario Reisen/Unterwegs Handy verloren/gestohlen/zerstört braucht man eine Lösung.
@JohnRipper: Also Conditional access policies mit compliant devices (in der Regel firmen-ausgerollte Geräte – Azure or hybrid joined)?
Ein Einloggen vom Privat-PC, Urlaubshotel, Flughafen-Terminal ist dann natürlich nicht möglich.
@Tomas Jakobs:
>> kann man machen, scheitert bei vielen aber bei fehlerhaften SPF, PTR und DKIM und die Mails werden von jedem sauber konfigurierten Server abgewiesen.
Klar: Die Trennung muss korrekt eingerichtet werden, geht aber technisch.
>> Dann wundert es mich allerdings, dass ein User mit Massenmails nicht längst rgendwelche Quotas gerissen hat. Oder doppelte Anmeldungen von unterschiedlichen Geräten/Stellen unbemerkt bleiben.
Vielleicht hat man es ja erst bemerkt, als die User sagten, dass ihre Sende-Quota überschritten wurde ;-) Bin trotzdem ganz bei Dir: das PROAKTIV zu entdeckten, zeichnet ein gutes SOC aus.
>> Kann man drehen und wenden wie man will, am Ende des Tages bleibt's an denen selbst hängen.
Full ack.
>> Also Microsoft + Hornet…
Korrekt.
>> Ich erinnere, dass bei IONOS/ 1&1 das genau bis vor einigen Jahren jeder Kunde mit seiner eigener Domain konnte: Mit einer anderen Absenderdomain, die auch bei Ionos lag, im Namen des anderen Mails zu versenden.
Stimmt, da war was.
>>Woher kommt die Annahme, dass die bösen Mädels und Jungs nicht die gleichen Dienste nutzen, wie die braven?
Ist nicht meine Annahme. Ich gehe fest davon aus, dass die "Pöhsen" dieselben Dienstleister benutzen (siehe MS-Test-Tenant-Problematik)
Die "pösen" Mädels und Jungs haben offensichtich besseres Monitoring über Geräte und User als der Laden selbst dachte ich mir beim Lesen dieses Artikels:
https://www.golem.de/news/angriffe-auf-microsoft-365-neues-phishing-kit-macht-datenklau-leichter-denn-je-2511-202064.html
Wer seine Authentifizierung und Zugangsdaten aus der Hand gibt, der ist einfach nur lost.