Ein Blog-Leser hat mich vor einigen Stunden über einen komplexen Spear-Phishingangriff informiert, der einen seiner Kunden betroffen hat. Da es einen Kunden aus dem Energieversorgungsbereich betrifft, ist das LKA Rheinland-Pfalz inzwischen involviert. Ich stelle die Informationen mal hier im Blog ein, da es eine komplexe technische Umsetzung und der mir erste bekannte Fall ist, wo das Opfer binnen weniger Minuten durch die Angreifer attackiert wird.
Anzeige
Ein Leserhinweis
Blog-Leser Carsten ist Inhaber eines IT-Systemhauses (Hauptbereiche IT-Systemadministration, Cybersicherheit / Managed Services) und wurde bei einem Kunden am 16. September 2024 auf den nachfolgend beschriebenen Spear-Phishing-Angriff aufmerksam bzw. zur Abwehr hinzugezogen.
Casten schrieb in einer Mail. "Ich verfolge Ihren Blog bereits seit einigen Jahren und wollte Sie auf einen am gestrigen Tag bei einem unserer Kunden stattgefundenen Spear-Phishingangriff aufmerksam machen, der nun auch zu einem Ermittlungsverfahren beim LKA RLP geführt hat, da es sich um einen Kunden aus dem Energiesektor handelt. Bemerkenswert ist die technische Umsetzung, die mir so noch nicht auf den Tisch kam."
Der Ablauf des Angriffs
Der Leser konnte den Ablauf des gezielten Hackerangriffs bei diesem Kunden nachvollziehen. Der Angriff erfolgte per Mail, wobei sich in dieser Mail auf eine vorangegangene Korrespondenz mit einem Geschäftspartner des Kunden bezogen wurde. Es handelt sich beim Kunden und Geschäftspartner ebenfalls um ein Unternehmen aus dem Energiesektor.
In diesem Kontext gab es für den Empfänger der Mail keinen offensichtlichen Grund zum Misstrauen (wie dies bei den üblichen Phishing-Mails eigentlich der Fall gewesen wäre). Dies gilt um so mehr, da der Kunde auf eine E-Mail bzw. einen Anhang dieses Kontakts wartete.
Anzeige
Die Analyse des Vorfalls ergab, dass der Geschäftspartner Opfer eines (wohl erfolgreichen) Cyberangriff geworden war. Die Angreifer hatten wohl einerseits Zugriff auf die Mails des gehackten Unternehmens und waren auch in der Lage, deren Inhalt zu interpretieren und für weitere Angriffe zu verwenden.
Der Kunde des Blog-Lesers erhielt in der Phishing-Mail einen Link zur einer Dropbox -Freigabe (Cloud-Freigabe). Der Dropbox-Link war ausschließlich für das Opfer freigegeben (siehe obiger Screenshot). Der Leser teilte mir noch mit, dass der Link auf die Dropbox-Freigabe eine E-Mail-Domain des Opfers verlangte, um an die Datei zu kommen.
Es wurde also schon Aufwand betrieben. Das herunterzuladende PDF-Dokument forderte den Empfänger der Spear-Phishing-Mail dazu auf, sich an einem Microsoft 365-Konto anzumelden (Bezug zur E-Mail-Domain des Opfers) und nach der Anmeldung einen Anhang herunterzuladen. Es war auch eine Verlinkung zu einer fingierten Microsoft 365-Anmeldeseite (siehe Screenshot) in der Mail angegeben. Die Phishing-Anmeldeseite war vom Original kaum zu unterscheiden.
Fingierte Microsoft-Anmeldeseite
Lediglich die in Englisch gehaltenen Anmeldeinformationen hätten ein deutsches Opfer stutzig werden lassen können. Der Leser schrieb, dass selbst die URL der Phishing-Anmeldeseite im ersten Schritt verschleiert wurde und erst später sichtbar war.
Die URL, die ich hier nicht nennen kann, soll weiterhin aktiv sein. Der Leser schreibt, dass hinter dem Angriff einiges an technischem Aufwand steckt. So wurde der Phishing-Seite mit der Fake-Anmeldung noch eine Cloudflare DDOS-Protection vorgeschaltet.
Echtzeitprüfung der Eingabedaten
Der Leser hat den Fall, nachdem der Angriffsversuch aufgefallen war, dann näher untersucht und mit dem Dezernat für Cybercrime beim LKA Rheinland-Pfalz Rücksprache gehalten. Bemerkenswert sei, schreibt er, sei die Tatsache, dass die Angreifer Eingaben des Opfers in Echtzeit gegen bestehende Microsoftkonten prüfen. Es wurde verifiziert, so der Leser, dass eine korrekte Ausgabe bzw. Rückmeldung des Kontos bei der Anmeldung erfolgte. Und die Angreifer prüften, ob ein Konto existiert, das Passwort korrekt ist und verifizierten zudem ob die Multifaktorauthentifizierung ausgelöst wurde.
Normalerweise nehmen Phishing-Seiten alles entgegen das Opfer eintippt an und speichern dies in eine Datenbank. Meist werde nicht mal auf korrekte Syntax geachtet, merkt der Leser an, was ich so bestätigen kann. Die üblichen Phishing-Seiten mit einer Fake-Anmeldung geben nach Eingabe der Zugangsdaten des Benutzer lediglich einen Fehler zurück, fischen aber diese Daten ab und speichern diese in einer Datenbank zur späteren Auswertung.
Im aktuellen Fall war das nicht so, alle Eingaben wurden in Echtzeit geprüft. Theoretisch, schreibt der Blog-Leser, wäre (bei ausbleibenden Gegenmaßnahmen) ein Zugriff auf die Unternehmenskommunikation (E-Mail, Kontakte, Kalender) sowie firmeninterne Dokumente und Dateien möglich gewesen.
Diese Art eines Spear-Phishing-Angriffs kennt man von staatlichen Akteuren, wenn es um das Eindringen in Unternehmensnetzwerke von KRITS-Betrieben geht. Das untersuchende Team konnte, so der Blog-Leser in seinem Hinweis, innerhalb weniger Minuten verschleierte Zugriffsversuche unter anderem aus Russland, Iran und China dokumentieren.
Zugriffsversuche auf gehacktes Microsoft-Konto
Der Leser schrieb mir noch, dass der Angriff erfolgreich eingedämmt und abgewehrt werden konnte. Das lag zum Einen an der automatischen Gefährdungserkennung durch beim Kunden umgesetzter (aber nicht näher erläuterte) Sicherheitsarchitekturen. Und es lag zum Anderen an der schnellen Reaktionszeit durch den Dienstleister. Dadurch konnten zeitnah alle notwendigen manuellen Maßnahmen ergriffen werden, um einen wirtschaftlichen und reputationsmindernden Schaden beim Opfer zu verhindern.
Zusammenhang mit Azure-Hack steht im Raum
In einer Nachtrags-Mail schrieb mir der Blog-Leser noch, dass je mehr sich die Sicherheitsspezialisten mit dem Fall beschäftigen, umso wahnsinniger werde das Ganze. Es sei hier quasi die gesamte Sicherheitsintegration seitens Microsoft, inkl. der neu eingeführte Microsoft Authenticator App (mit Eingabe eines Zahlencodes statt einfacher Bestätigung), aus den Angeln gehoben worden.
Es kam die Frage auf, ob es sich wirklich um eine Echtzeitabfrage von Daten handelt (oder um eine zuvor angelegte Datenbank mit Microsoftkonten). Das führte zur Frage, ob es wohlmöglich einen Zusammenhang mit dem Zugriff staatlicher Hacker (Midnight Blizzard) auf Microsoft Azure gibt (siehe auch Microsoft: Neues vom Midnight Blizzard-Hack – auch Kunden möglicherweise betroffen).
Angesichts des Umstands, dass es sich um KRITIS-Unternehmen handelt, ist der Verdacht sicherlich nicht von der Hand zu weisen. Daher wurde zum Test ein neues Microsoftkonto angelegt, korrekt lizensiert und dazu Accounts angelegt. Das potentielle Opfer wurde "Carsten Honigtopf" genannt.
Dann wurde die Prozedur, wie vom Kunden im Rahmen des Phishing-Angriffs beschrieben, erneut über die Phishing-Seite durchgeführt. Der Login auf der Fake-Anmeldeseite wurde für das neue Testkonto komplett bis zum Ende (inkl. der Bestätigung im Microsoft Authenticator auf einem iPhone) durchgeführt. Bereits wenige Sekunden danach gingen dann wieder die via VPN-Kaskade verschleierten Zugriffe auf dieses Konto los, schrieb mir der Leser.
An dieser Stelle mein Dank an Carsten für den Hinweis – vielleicht hilft es der Leserschaft bei ähnlichen Angriffen bzw. sensibilisiert weiter.
Ergänzende Informationen
Der Beitrag ist nach Veröffentlichung von den Abrufzahlen durch die Decke gegangen. An dieser Stelle mein Dank an die Leserschaft für die umfassende Kommentierung. Allerdings findet sich auch viel Spekulation in den Kommentaren. Manches Detail wird im Beitrag bewusst nicht offen gelegt, andere Informationen wurden von Kommentatoren wohl überlesen. Carsten hat mir im Nachgang einige Informationen in gesammelter Form zukommen lassen. Ich bereite einige Gedanken und Aussagen mal in geraffter Form auf.
Kurze Zusatzinformationen mit Einordnung
Es wurde in Kommentaren negiert, dass es ein Spear-Phishing-Angriff war – kann man diskutieren, bringt aber keinen weiter (ist der berühmte Nebenkriegsschauplatz, wo sich hervorragend verkämpfen lässt). Carsten merkt dazu an: "Die Klassifizierung als Spear-Phishing-Versuch leitet sich aus der auf den Kunden zugeschnittenen Dropxbox-Freigabe und weiteren Indizien sowie dem getriebenen technischen Aufwand ab. "
Es wurde in den Kommentaren auch häufiger eingeworfen, dass "Conditional Access" und Geoblocking geholfen hätten. Mag nicht den Obermacker-Lehrer geben, aber gelegentlich ist tieferes Nachdenken hilfreich. Ich kippe einfach mal einige Hinweise hier im Text ab.
Was wohl einige nicht verstanden oder überlesen haben (obwohl es deutlich im Artikel beschrieben ist), dass zu den umgesetzten Sicherheitsarchitekturen die mit "automatischen Gefährdungserkennung" gemeint waren, (unter anderem) ein Conditional Access zählt.
Der Punkt ist also abgeräumt. Wobei sich in der Praxis hier auch immer individuell die Frage stellt, wie geschärft die Einstellungen gesetzt sind (auch ob noch ein manueller Eingriff gewollt ist). Hier ist zum Teil auch immer mit dem Kunden abzustimmen, wie weit er möglicherweise eingeschränkt werden will oder auch nicht, teilte mir Carsten mit.
Er merkt zudem an, dass reines Geoblocking nicht hilft. In den VPN-Kaskaden waren, ausweislich der log-Einträge, auch IP-Adressen aus Deutschland bzw. Europa enthalten.
Der Angriff konnte im beschriebenen Fall (ohne Zugriff auf Unternehmensdaten) erfolgreich abgewehrt werden. Aus dem Honeypot lassen sich inzwischen mehrere interessante Rückschlüsse ziehen. Unter anderem fanden, teilweise auch mit mehreren Minuten Verzögerung, fehlerhafte, aber auch erfolgreiche Logins auf das Konto statt (alle möglichen IP-Adressen dabei), schrieb mir der Leser. Die Beteiligten in diesem Fall gehen davon aus, dass die Zugriffe automatisiert geschehen.
Ansonsten konnten beim Honeypot, trotz aufgebohrtem Audit usw., keinerlei Aktivitäten – außer Anmeldeversuche – feststellen. Wie es beim Kunden gewesen wäre, lässt sich nun natürlich nicht sagen. Carsten schreibt, dass es für ihn aber so aussieht, als hätte das Tool gezielt zum Einsatz kommen sollen. Zudem merkt er an: "Aber sind wir mal ehrlich, der Prozentsatz an Unternehmen, die all dies [an Sicherheitsmaßnahmen] umgesetzt haben, halte ich für gering. Zumindest haben wir bisher noch keinen einzigen Kunden übernommen, bei dem entsprechende Policies umgesetzt waren."
Zudem ist von Seiten des Lesers anzumerken, dass die beschriebenen Sicherheitsmerkmale, nach aktuellem Wissen, Entra ID Premium P1 oder P2 als lizensiert voraussetzen oder inkludiert in einen der größeren Microsoft 365 Pläne z.B. Microsoft 365 Business Premium. Das dürfte aber auch nicht immer gegeben sein.
Weitere Erkenntnisse aus dem Honeypot
Inzwischen ergibt sich das Bild, dass der Leser heute ein neues Login mit geänderten Anmeldedaten über die Fake-Seite am Honeypot-Konto durchgeführt hat. Die neuen Anmeldedaten wurden also an die Phisher übertragen – das Ganze simuliert für Außenstehende einen Nutzer, der am Morgen seine Arbeit aufnimmt und sich am Microsoft Konto (mit geänderten Anmeldedaten) anmeldet. Bei diesem zweiten Versuch gab es keine Login-Kaskade mehr – der Angreifer hat das Konto möglicherweise schon als "uninteressant" abgehakt.
Sensibilisierung: Es bleibt schwierig
Es bleibt unter dem Strich, dass es bei den Geschäftspartnern ein Opfer gab, was erfolgreich angegriffen wurde. In diesem Kontext empfand ich den Kommentar hier als "unglücklich" – muss aber jeder für sich selbst einordnen.
Als nicht wirklich hilfreich empfinde ich auch die für mich aus einigen Kommentaren herauslesbare unterschwellige Botschaft "ist doch alter Kaffee, haben wir täglich Tausend Mal und alles im Griff, alles nicht neu und ein alter Hut" – und dann kommen noch die Vorhaltungen, dass Mitarbeiter so etwas erkennen müssen. Mag im Einzelfall stimmen und es gibt sicher Leute, die das hervorragend im Griff haben. Aber Pauschalierungen gehen schlicht an der Praxis vorbei. Es bringt auch niemanden weiter, mit "wissen wir doch längst" und "hättest Du erkennen können" einzutüten, wenn der Angriff erfolgt ist.
Meine 2 Cent
Schon Martin Luther wusste vor vielen Hundert Jahren "Schau dem Volk auf's Maul", dann weißt Du, wie der Hase läuft. Oder in modern getreu nach Mc Murphy ausgedrückt: "Was passieren kann, passiert – auch unmögliches – und es gibt nichts, was es nicht gibt". Die Tatsache, dass mir der Stoff mit täglichen Meldungen zu Sicherheitsvorfällen nicht ausgeht und ich höchstens an der Zeit zur Aufbereitung scheitere, zeigt doch, dass da draußen in der IT viel im Argen liegt.
Möglicherweise bin ich auch aus meiner Zeit als Ingenieur in der Großchemie geprägt. Wenn es dort einen Vorfall gab (z.B. Seveso, Bhopal) lagen keine Details vor – Internet gab es nicht. Es war gepflegte Übung, dass jeder Verantwortliche sofort überlegte, besteht bei uns das gleiche Risiko? Was passiert, wenn dies und jenes passiert? Habe ich genügend getan oder kann ich noch was berücksichtigen? War vor über 30 Jahren aber wohl eine andere Zeit …
Wie schrieb Carsten in einer Nachtragsmail: "Ziel meiner Mail war es, zur Sensibilisierung beizutragen, dass denke ich haben wir geschafft." Dem kann ich mich nur anschließen: Ziel des Blog-Beitrags ist es, auf ein Thema hinzuweisen, in der Hoffnung, dass die Leserschaft da "Honig draus saugen" und eigene Schlüssel ziehen kann.
Anzeige
Spannende Geschichte. Was ich aber nicht ganz verstehe, warum man sich mit seinem MS Konto bei Dropbox anmeldet. Sollten da nicht schon die Alarmglocken angehen? Oder benutzen die da SSO Dropbox M365 Konto (ist nur eine Vermutung, ich kenn Dropbox nicht im Einsatz)? Wenn ja, sollte man drüber nachdenken, das besser zu lassen.
Ich hoffe es gibt noch ein Update zu der Story.
Hoffentlich wird den Verantwortlichen hiermit klar, dass man eine "digitale Unterschrift" niemals gleich einer "analogen, händischen Unterschrift setzen darf, egal wie viel Hightech man dazwischen klemmt.
eine analoge, händische Unterschrift lässt sich leichter fälschen als eine gute digitale Signatur und die Echtheit einer guten digitalen Signatur lässt sich leichter überprüfen als die Echtheit einer analogen händischen Unterschrift.
Danke für das Aufbereiten. Eine Sache verstehe ich aber nicht, oder überlese zum 3ten mal oder ist ungenau erwähnt bzgl. Authenticator App
Es sei hier quasi die gesamte Sicherheitsintegration seitens Microsoft, inkl. der neu eingeführte Microsoft Authenticator App (mit Eingabe eines Zahlencodes statt einfacher Bestätigung), aus den Angeln gehoben worden.
Im ersten Teil ist nur von ZugriffsVERSUCHEN die Rede ( als über die phishing Seite auf gültigen Account geprüft wurde). Nach meinem Verständnis gescheitert da Kunde MFA konfiguriert hat und nutzt. Also hatte es doch entsprechend (positive) Wirkung.
Mit dem MFA Honeypot User hies es dann nur noch Zugriffe gingen wieder los, nachdem über phishingseite User geprüft wurde und Passwort gephisht wurde. Diespätereb Logins waren denn erfolgreich? Wie wurde dann hier aktivierte MFA Policy aus den Angeln gehoben?
Mail Filter hätten nichts genutzt, denn der Absender war ja gehackt!
Insofern wäre es von großem Interesse, wie/womit dieser Phishing Versuch aufgeflogen ist, zumal ja sogar die IP gewaschen werden sollte mittels/dank Cloudflare.
.
Denn es gilt:
There is no security by obscurity
Zumindest den Geheimdiensten dürfte durch die Meldung klar sei, wodurch sie entdeckt werden könnten..
sorry ich noch mal
ich verstehe etwas nicht..ist wohl zu spät.
"Theoretisch, schreibt der Blog-Leser, wäre (bei ausbleibenden Gegenmaßnahmen) ein Zugriff auf die Unternehmenskommunikation (E-Mail, Kontakte, Kalender) sowie firmeninterne Dokumente und Dateien möglich gewesen."
Wie soll das denn gehen?
dazu muss ich nicht nur die login Daten haben, sondern auch Zugang zum LAN.
Wo ist der hergekommen?
Hab ich da etwas überlesen?
ich schreibe jetzt hier die unschwer zu ermittelnde Infos:
Domain: meinedomain.de
Login: Pau1.Nachname (heute leider üblich.
Die Mitarbeiter werden für zu dumm gehalten, sich einen login Name zu merken…ist außerdem einfacher zu administrieren…)
Password: Geh-Heim! (Via fake Seite)
MFA: yes
und nun?
Wie meldet sich ein Externer mit meinen Daten an?
Selbst wenn ich so bescheuert wäre, das VPN ohne html knocking mit obigem Login zu fahren, fehlt immer noch derjenige, der den MFA bestätigt, oder? Wie soll ich diese Anfrage sehen ? Wenn bei mir eine MFA Abfrage aufpoppt, werden ich doch hell hörig? Oder ist das der Grund, das alles in Echtzeit passiert? Auch mich dich wiundett (mal abgesehen davon: Woher weiß der Angreifer denn, wo er meinen VPN Zugang findet?
(Weil ich mit der IP das Fake Formular ausgefüllt habe?)
Exchange Online, Sharepoint/Teams/OneDrive, O365 Dienste… Es geht hier um das Entra-ID Konto, nicht um ein AD-Konto.
In unserer schönen neuen Welt brauchst Du kein VPN mehr, um auf on premises Dienste zugreifen zu können.
Daher muss man das ganze wieder vernageln, conditional access Regeln, definierte Standorte, "hunderte" Defender-Produkte, damit diese Logins hoffentlich auffallen und dann auch noch reagiert wird.
dafür gibt es nur ein Wort
K R A N K
oder begging for trouble
Die spinnen, die Römer.
Danke für die Aufklärung.
ich könnte mir nicht vorstellen wie dumm manche Menschen sein können und trotzdem Milliarden Gewinne machen dürfen.
Hat mal wer nen neue Planeten? Ich würde gerne weg aus diesem Narrenpool.
Die Daten liegen ja immer häufiger auch in der Cloud sprich SharePoint Online oder OneDrive.
Auch Outlook ist eine herrliche Datenquelle für Informationen und Geschäftsbeziehungen. Eine gute KI kann da sicherlich hervorragende Infos und korrelationen bilden.
Was ich aber auch nicht verstanden habe ist die MFA Sache.
Der Login wird von der Fake Site an MS weitergeleitet, dort wird der MFA Push an mein Handy geschickt, ich tippe die Zahlen ein, die Info geht zurück an MS.
Im besten Fall haben die Angreifer es damit geschafft, können sich aber nur 1x einloggen damit. Reicht im Zweifel aber auch.
Genau, der MFA ist ja nur ein paar Sekunden gültig. Wenn man die Benutzeranmeldung auf einer Fake-Seite mit verfolgt und life ins echte Anmeldeportal eintippt, ist man ja "drin". Dann gibt die vorderste Front der Hackertruppe (diejenigen die rund um die Uhr auf Anmeldeversuche lauert) die VM mit der offenen Session an die Spezialisten weiter, die dann OneDrive, Outlook, OneNote usw. exportieren. Evtl. besteht sogar Zugriff mit dem Zugang auf einen M365 Cloud-PC, der wiederum auf lokale/firmeninterne Ressourcen (also die die nicht in der Cloud liegen) zugreifen darf…?
Das ist alles nicht schön und ich habe meine Zweifel, ob dagegen komplexere MFA-Verfahren (biometrisch, hardware-Token, …) besser helfen, als wie ein paar Zahlen aus dem Authenticator.
Ein bisschen schützen kann man sich vielleicht, in dem man den Zugang auf die MS-Cloud weiter einschränkt, so dass man sich nur mit Entra-ID-Joined Geräten anmelden kann.
Es wird direkt das Cookie für die angemeldete Sitzung abgegriffen (Lesestoff: nach evilginx und modlishka suchen, gibt auch Demovideos dazu). FIDO2 (und sonst eigentlich nichts) hilft gegen dieses Phishing tatsächlich zu 100 %.
Das Access Token in Entra ID ist erstmal eine Stunde gültig, dazu ein Refresh Token mit 90 Tagen Gültigkeit.
Wenn sich wer über die seltsamen Zeichen rechts wundert. Das liegt daran, das dieser Bereich für mich beim editieren unerreichbar unter der rechten Kante steckt und der Text nicht horizontal scrollbar ist.
Mit den Pfeiltasten den Cursor im Text so weit nach rechts bringen, bis unten rechts die "Griff-Ecke" zur Größenänderung des Eingabefensters wieder erscheint. Damit dann das Fenster wieder nach links verkleinern und nach unten vergrößern, bis alles wieder sichtbar ist. Das Eingabefenster darf nie breiter gezogen werden, als bis maximal zum rechten Rand der Trennlinien zwischen den Posts!
Falls der Cursor wegen ungünstiger Zeilenumbrüche durch längere Worte nicht soweit nach rechts zu bringen ist, einfach temporär 2 Zeilen mit breiten Zeichen (z. B. großes W) füllen. Dann kommt man da schon hin.
danke
den Rahmen verschieben habe ich tatsächlich nie probiert. Geht auch gar nicht (smart phone Opera mini)
Ich bekomme eine Downloadlink via "Dropbox" wie im Screenshot angegeben, muss mich dann mit einem Microsoft Konto anmelden. Jetzt sollten schon alle Alarmglocken angehen und keine weiteren Aktionen zur Dateneingabe stattfinden. Trotzdem ein personalisierter Angriff, der Aufwand dahinter lässt schon einen sehr gezielten Angriff vermuten.
Danke für die Hinweise hier im Blog.
Gruß Markus
Ja, die Alarmglocken "sollten" angehen. Ich habe gestern einer 62jährigen Mitarbeiterin im Vertrieb erklärt wie sie Icons vom rechten auf den linken Bildschirm per Drag n` Drop zieht. Bei so viel Wissen denkt doch keiner darüber nach, ob die Zugangsdaten von MS auch bei Db funktionieren oder nicht.
Das kann man nicht pauschal so sagen. Heute wird vermehrt auf SSO gesetzt. Da ist es ganz normal dass auf unterschiedlichen Login Portalen eine MS Website mit Passwort Abfrage kommt. Woher soll der geneigte Anwender denn wissen können dass bei z. B. Adobe SSO Anmeldung ok aber Dropbox nicht ok ist…
ich dachte bisher dass der große Vorteil von Sso wäre, dass man nicht andauernd das Passwort eingeben muss,und automatisch stützt, wenn man doch aufgefordert wird.
Was ist nun richtig?
Ich kenne meine Paßwörter selber nicht, da kann ich nix Falsches eingeben. Und mein Paßwortmanager gibt keine Paßwörter auf Seiten ein, die er nicht kennt ;-).
Da hast du recht, hier ist der Wissenstand und Zurückhaltung, solche Daten einzugeben sehr unterschiedlich. Da helfen Phishing Schulungen schon, aber vermutlich erhöht sich die Sensibilität nicht bei allen. vor allem ist es gut, im Blog hier immer solche aktuellen Angriffe zu lesen, hilft Wissen zu erweitern und ggf. sogar Hinweise an die User weiterzugeben. Wir sammeln solche Beispiele, machen quasi eine Art Quiz draus. Die Mitarbeiter sollen dann die Echtheit oder Gefährlichkeit einschätzen. Wir erklären dann gerne, warum eine einfache e-Mail Anfrage entwickeln, bis hin zum Empfang der gefährlichen Downloadlinks. Das kommt sehr gut an.
Es ist manchmal schon ein Elend, wie wenig MAs von Ihrem PC/Betriebssystem wissen.
"Elend" trifft es sehr gut. Was manche bei ihrer Bewerbung unter "Windows und Office Kenntnisse" verstehen, ist echt ein Witz. Leider muss man zu häufig nehmen was man bekommt. Einstellungstests würde kaum einer "überleben"
Es ist manchmal schon ein Elend, wie schnell User ohne wirkliche Infos zu den konkreten Umständen Urteile fällen.
Die Meldung ist noch zu unklar, um die "das waren wieder dumme User" Keule raus zu holen.
Bei Cyberattacken hat bisher immer noch ein bisschen Demut geholfen. Dünkel noch nie.
Hatten wir bei einem Kunden vor ca. 6 Wochen, genau so, nach Rücksprache mit Kollegen ist angeblich hier die Lösung, einen höheren Plan von M365 zu kaufen, weil in diesem Fall angeblich der MFA Token nicht entwendet werden kann, da habe ich aber nur Halbwissen, ob das wirklich die Lösung wäre. Ich will hiermit nur sagen, das Angriffsmuster existiert schon seit einiger Zeit.
Müsste der Angriffsvektor sein, um an den OAUTH Token zu kommen.
https://www.msxfaq.de/cloud/authentifizierung/m365_credential_phishing.htm
Mit einem Sender der einen gehacktem OnPremise Server verwendet, hätte das auch funktioniert.
Ich stelle hier mal im Raum das in jeder M365 Umgebung unzählige Loginversuche aus dem Ausland im Anmeldeprotokoll zu finden sind. Viele werden von MS schon geblockt da sie von verdächtigen IPs kommen, trotzdem sollte man zusätzlich den bedingten Zugriff konfigurieren und den Login nur auf wirklich notwendige Länder beschränken, notfalls sogar nur auf das eigene.
Ja dann gibt es wieder eine Diskussionen wenn Mitarbeiter A Urlaub im Land B macht und nicht an seine Mails kommt, aber das Protokoll mit den Anmeldeversuchen lügt nicht und sollte jede Diskussion im Keim ersticken.
Ja, gibt es….gegen Bezahlung. (Damit es auch vernünftig auswertbar und automatisiert geblockt wird).
Microsoft sollte diese Schutzlevel ausnahmslos für alle M365-Kunden zur Verfügung stellen – ohne Aufpreis.
Die Log Datei gibt es ohne Bezahlung:
Entra -> Benutzer -> Anmeldeprotokoll
Kann sich jeder ziehen und dann selber auswerten. Wenn jetzt einer sagt er ist nicht in der Lage auf Grundlage einer CSV Datei eine eigene Auswertung zu erstellen, dann sitzt das Problem vor dem Bildschirm. Die Auswertungen die MS Kostenpflichtig auf PowerBI Basis anbietet kann sich auch jeder Kostenlos alleine bauen.
Und das setzen des "bedingten Zugriffs" ist auch keine Sonderfunktion.
Problem ist viel mehr das es in der Cloud unzählige Funktionen und Logs gibt die man Anfangs gar nicht alle verorten kann. Schulungen helfen, aber noch mehr hilft sich wirklich mit dem Thema intensiv zu beschäftigen.
Ich sagte ja, vernünftig auswertbar….keine Frickel-Bastel-Lösung, sondern verd***t noch mal vom Hersteller, verpflichtend und frei Haus.
Log Dateien auswerten ist keine Frickel-Bastel-Lösung. Wer seine Log Dateien selber auswertet kann noch viel mehr in die Tiefe gehen als es bei irgendwelchen vorgefertigten Auswertungen der Fall ist. Darüber hinaus erhält man selber auch ein Gefühl für die Daten und das ganze Setup.
Wer sich nur mit vorgefertigten Lösungen zufrieden gibt macht es sich da sehr einfach. Sorry Chef die Auswertung wird uns vom Anbieter nicht zur Verfügung gestellt also können wir sie nicht liefern…. klingt nach 9to5
Wir haben Geoblocking für einige Verbrecherstaaten auf unserer Firewall an, was dann momentan noch übrig bleibt, zeigt folgende Statistik für die letzten 7 Tage für unser externes Mitarbeiterserviceportal:
Bulgaria 78%
Romania 13%
UAE 3%
Slovenia 3%
Kazakhstan 2%
India 2%
Brazil 2%
Belarus 1%
Lithuania 1%
Pakistan 1%
Philippines 1%
Seychelles 1%
Israel 1%
Others 1%
Ich könnte die IPs aufschlüsseln, aber die sind wie Schall und Rauch… Wahrscheinlich könnten wir die meisten dieser Länder – außer Bulgarien, Solvenien und Sychellen (Urlaubsziel, obwohl, die Mitarbeiter sollen Urlaub machen…) auch geoblocken, aber das würde weitere Recherchen über die Mitarbeiter erfordern, nicht dass die bei Besuch bei Freunden/Verwandten tatsächlich von dort legitim zugreifen, das kann man aber nicht bringen. Belarus ist eigentlich auch geblockt, aber da sind wohl die Listen fürs Geoblocken auf der Firewall wohl nicht immer aktuell.
Zwei Ansätze dazu:
Lösung A: VPN
Meldet sich der Mitarbeiter per VPN in der Firma an, läuft die Abfrage über eine Deutsche IP. Wer kein VPN Zugang zur Firma hat braucht auch im Urlaub keine Mails prüfen.
Lösung B:
Man definiert die Firmengeräte in der Blockregel als Ausnahme, womit dann die Geräte auch im Ausland funktionieren.
da fehlt aber z.B. die USA…
Bei uns kommen >60% der "ominösen" Anfragen aus den USA , dass sind bei weitem mehr wie aus allen anderen Ländern (wahrscheinlich auch, weil es dort viele VPN und Proxy-Dienstleister gibt).
Da sieht man auch immer wieder im Conditional Access, wenn ein MA seine Logindaten irgendwo eingegeben hat, kommen die ersten Loginversuchte in 95% der Fälle aus den USA (kann man immer gut sehen in den Logs & Dashboards vom CA) und nicht aus einem der "Schurkenstaaten".
Der Sicherheitsgewinn solcher Geo-lokalisierter Blockregeln erscheint mir eher zweifelhaft. Ja, man schließt einen Teil der bösen Anfragen aus. Aber es ist doch bekannt, dass deutsche Provider bei Kriminellen und staatlichen Akteuren beliebt sind. Und VPN-Tunnel gibt es auch noch.
Ich denke es ist sinnvoller, sich in Bezug auf die Angriffsvektoren laufend besser aufzustellen, anstatt die Zeit in die Blockierung "böser" Länder zu investieren.
Geoblocking ist in vielen System in kurzer Zeit eingerichtet.
Der entscheidende Vorteil in meinen Augen ist das die Anfragen deutlich nach unten gehen (bestimmte Länder haben verdammt viele Scriptkiddies?) und dadurch auch sinnvoller betrachtet werden können um herauszufinden wie man sich besser aufstellen kann.
sag das den BWL'ern aka Wirtschaftsprüfer oder ISO Auditoren :-) die hängen sich sehr gerne an so etwas auf.
Mir ist durchaus bewusst, dass eine solche Lösung nicht zielführend ist.
Was aber hilft, zumindest wenn man CA usw. von M365 nutzt, das Anmeldeverhalten der Benutzer einzuschränken, so dass die Dame aus der Zentrale sich nur von der öffentlichen IP Adresse des Unternehmens anmelden kann. Ein Servicetechniker nur mit einer deutschen IP Adresse usw., damit fängt man schon das meiste ab – eine Garantie gibt es aber nach wie vor nicht.
Quatsch!
90% der "Angriffe" kommen über angemietete Server aus EU/USA
Solche Geo-IP Blockingregeln halten nur Script-Kiddies und das "Grundrauschen" des Netzes ab, wie ich zu sagen pflege.
Die einzige Lösung lautet: Kein MS Entra/Cloud Gedönse nutzen. Das AD offline setzen und das eigene Personal sensibilisieren, dass es nirgendwo Zugangsdaten einzugeben hat außer in den selbst verteilten Programmen oder Bookmarks:
https://blog.jakobs.systems/blog/20240506-service-tips-windows/
Meine Statistik der letzten 7 Tage sagt was anderes:
25% China
15,7 % Korea
10,7 & USA
6,3% Indien
4,4 % Russland
4.1% Brasilien
3,4% Kong Kong
2,6% Taiwan
….
…
..
.
Deine Top-3 (sofern es NK ist) ist bei uns im Geoblock, plus Platz 5 und 7. Die Sachen im Geoblock werte ich garnicht mehr aus…
Dein "Lösungsvorschlag" hilft nicht weiter. Heute muss alles vernetzt sein, sonst kannst du nicht mehr mithalten.
Die Zeiten von USB-Sticks und Disketten sind vorbei.
sorry, geoblocking ist naiv.
Wenn ich jemanden angreifen wollte, würde ich das über eine VPN Kaskade machen und als letztes einen Zombie im Heimatstaat des Anzugreifen den legen.
ich bin doch nicht so bescheuert und gehe direkt von meiner eigenen IP zum Angriff.
ich vermute mal, dass diese "Angriffe" aus den bekannten Staaten nur das logfile zu müllen sollen.
Insofern ist eine positiv Liste hilfreicher.
Und für die Vertriebsleute in Übersee halt html Knocking um die aktuelle IP freizugeben und Fido2….
Ach ja, sorry.
Das könnte nur MS einrichten…
Was ist das System kaputt und alle bewundern des Kaisers neue Kleider….
Gegen ein gezielten Angriff ist es so oder so schwer, das ist aber kein Grund auf die Basics zu verzichten. Und wie wir in diesem Artikel gesehen haben hätten dieses Basic schon im ersten Schritt geholfen, da die Logins nach dem Abfangen der MFA aus dem Ausland getätigt wurden.
Die Positivliste kann man natürlich auch auswerten, blendet da seine bekannten Standort IPs aus und guckt sich nur die externen IPs an.
> Die Zeiten von USB-Sticks und Disketten sind vorbei.
Am besten nochmals den verlinkten Artikel lesen.
Niemand benutzt hier USB-Sticks oder Disks.
Es ist vornehmlichste Aufgabe eines jeden Admins die Schnittstellen (Mail Gateway, WebProxy, Guacamole, Jumphosts, etc.) zu kontrollieren. Dafür gibt es drölfzig freie und kostenlose Lösungen im Monitoring und beim IDS/IPS.
Was ist denn das für eine komische Kommunikation über Dropbox. Wenn ein Geschäftspartner sowas verwendet, ist er per se nicht vertrauenswürdig. Und ich verstehe nicht, warum immer noch fast niemand seine Emails mit X.509 Zertifikaten sprich S/MIME signiert bzw. im Falle von KRITIS verschlüsselt. Richtig implementiert verlässt der private Schlüssel niemals das Endgerät, besser noch, er ist in einem HSM wie nitrokey gespeichert. Dann sind solche Angriffe nicht mehr möglich. Die Industrie macht es den Angreifern einfach allzu leicht. Dabei stehen alle Mittel für schmales Geld zur Verfügung, wenn man sich nur von den Marketing-Lügen der großen IT Konzerne verabschiedet. Was es dazu braucht ist eigene Kompetenz, die leider in ganz vielen IT Abteilungen fehlt.
Hallo,
ich war vor kurzem mal bei einer Veranstaltung für IT-Security, das LKA war dort auch vertreten und die Veranstalter haben uns ein genau solches Scenario gezeigt. Hier wird der Token der z.B. für SSO verwendet wird geklaut. Sprich selbst die MFA schützt hier nicht mehr. Passt bitte auf wenn ihr zum Download aufgefordert werdet bzw wenn ihr aufgefordert werdet euch anzumelden obwohl ihr schon angemeldet seit. Vorallem wenn ihr ein Dokument per Dropbox erhaltet wieso solltet ihr euch dann bei MS anmelden müssen?
das kenne ich schon …
hatten wir so ähnlich vor 2 Jahren,
da war das Login für "DropBox" im mitgesendeten pdf enthalten.
Die eMail dazu war auch eine "Antwort" auf eine zuvor versendete eMail.
Ob damals die Logindaten auch sofort online geprüft worden wären kann ich nicht sagen. Die Mitarbeiter hatten rechtzeitig das ganze durchschaut …
Aus Erfahrung: es werden in den nächsten ca 1,5 Jahren noch "angebliche" eMails vom Geschäftspartner eintrudeln: Mitarbeiter schulen ! , Muster eMails sammeln und in der Schulung verwenden !
PS: Der Mitarbeiter vom Geschäftspartner der damals kompromitiert wurde, hat bis heute NICHT begriffen was er damals falsch gemacht hat.
Korrektur:
das war damals Login für OneDrive, und damit plausibel …
da helfen auch leider keine Schulungen. Ein MA langt, der es nicht begriffen hat.
Technologie wäre hier im Notfall hilfreicher.
"Ein MA langt, der es nicht begriffen hat."
Es kommt nur auf ein gutes social Engeneering an. Wie im Artikel berichtet, hat der MA eine Mail von genau diesem Partner mit einem Anhang erwartet. Wenn dann auch noch der Bezug auf die bisherige Kommunikation da ist, möchte ich nichts darauf wetten, dass du nicht auch auf den Versuch rein fällst.
Ich habe schon mehrmals Vorfälle mit sehr vorsichtigen Usern gesehen und halte daher den Ball bei der Beurteilung inzwischen sehr flach. Ich gehe auch nicht mehr davon aus, dass es nicht auch mal mich erwischen kann.
und nicht die Kollegen übersehen die ob des schlechten Betriebsklimas innerlich gekündigt haben und voll wissentlich in die Falle tappen.
oder Risiko Kompensation betreiben. Ich bin ja sicher, und wenn nicht ist die doofe IT schuld..
Ganz ganz schwierig…
Und was ist da jetzt so neu oder komplex?
Der typische Angriffsvektor mit einer typisch nachgeladenen Payload.. mit einer typisch angezeigten nachgemachten MS Konto Phishing Site auf Cloudflare. Die typische Supply-Chain Atacke, nichts Neues noch sonderlich komplex oder bemerkenswert. Das beinhaltet auch das "Einklinken" in eine bestehende Kommunikation oder die "Echtzeit" Authentifikation. Meint Ihr denn die bösen Hacker können nicht programmieren oder was?!?
Ich hätte da eher einige Gegenfragen an den IT Dienstleister selbst, der dem betroffenen Kunden diese typische bestimmt nach Microsoft Lehrbuch aber leider auch strukturell kaputte Lösung dahingestellt hat, offensichtlich ohne mitigierende Maßnahmen. Dafür braucht man keinen Dienstleister oder erfahrene Admins, das erledigen einem auch billige Operatoren, die auf Knöpfchen in einer WebUI klicken.
Aber solche Fragen sind unerwünscht, denn diese treffen genau ins Schwarze. Es wird lieber das Narrativ von sehr guten Reaktionsfähigkeiten, einsamen Helden, die Schlimmes abwehren konnten, allein gegen maximal übelsten Bösen aus dem Osten.
Guten Morgen! Das ist Alltag von ADs, allein in Deutschland mehrfach täglich…
Seit evilginx muss man sowas nicht mehr selbst programmieren. Ist ein fertiger Baukasten für Man-in-the-Middle-Attacken für viele große Anbieter (MS, FB, X, …).
Das ist nicht neu, solche Mails kommen zu schon seit >1 Jahr regelmäßig rein, Das einzige was da sinnvoll hilft, wie auch bereits andere geschrieben haben: Conditional Access und zwar strikt! Lieber ein gesperrter Geschäftsführer wie ein kompromitierter Account. Wir haben auch kein automatische entsperren, dass muss immer manuell erfolgen (wenn es am WE passiert, muss er halt bis Montag warten).
Oft enthalten die Mails auch nicht direkt den Downloadlink, weil der ggf. im Spamfilter gefunden und blockiert wird, sondern verweisen auf irgendeine "my-Seite" vom o365 Sharepoint, wo dann eine präparierte PDF oder Word Datei liegt, die den gefährlichen Link enthälten. Solche Seite kann man brav an M$ melden, die machen eh nichts. Ich habe >10 Seiten im letzten Quartal gemeldet, die sind größten Teil immer noch online.
Genau so hatte ich das bei einem Kunden vor ca. zwei Monaten beobachtet.
Evtl. ToDo: Anmeldeprotokolle im Entra regelmäßig kontrollieren auf erfolgreiche Anmeldungen aus nicht-DE (ja – ok – schützt auch nicht vollständig). Ebenso Entra Geo-Policy. Unternehmensbranding wäre auch noch eine Idee.
Und immer wieder: Usersensibilisierung
Neu oder besonders ist an diese Fall nichts, derartige Methoden gibt es schon lange.
Die Anmeldeseite ist nicht nachgebaut, sondern lediglich durch einen ReverseProxy umgeleitet; da prüft auch niemand in „Echtzeit", die Anmeldung bei Microsoft findet tatsächlich statt. Es wird lediglich das Anmelde-Token abgefangen, so dass der Angreifer dieses dann nutzen kann.
Genau dieses Vorgehen ist der Grund, warum Microsoft darauf drängt, phishing-resistant MFA einzuführen, warum es im Bereich Conditional Access die continous evaluation gibt. Darüber hinaus hätte ein konfigurierter Risk-Based Contional Access den Zugriff erkannt, bzw unterbunden; die englische Sprache der Anmeldeseite deutet klar darauf hin, dass der Reverse Proxy in einer anderen Geo-Location steht. (Insofern sehe ich da auch kein SpearPhishing.) Die MS Token Protection lassen wir mal außen vor, da diese noch im Preview ist.
Was mir wirklich Sorgen macht, ist dass ein IT-Berater eines Kritis-Unternehmens dies für „neu" hält. Selbst auf dieser Seite wurde vor über einem Jahr auf die entsprechende Methode hingewiesen:
„Microsoft veröffentlicht TokenTheft-Playbook", 03.08.2023
"Genau dieses Vorgehen ist der Grund, warum Microsoft darauf drängt, phishing-resistant MFA einzuführen, warum es im Bereich Conditional Access die continous evaluation gibt. Darüber hinaus hätte ein konfigurierter Risk-Based Contional Access den Zugriff erkannt, bzw unterbunden"
Hast du dir mal selbst zugehört.
Das ist "Microsoft macht alles richtig" dummgeschwätz.
Microsoft ist teil des Problems, nicht teil der Lösung.
Wenn ich darauf getrimmt werde, dass zScaler für mich auf allen Möglichen Seiten Login Vorgänge auf über meinen MS Accoutn durchführt, alle angeklickten Links in Teams über Microsoft Prüfseiten geschliffen werden und ich daher ständig meine MS Zugangsdaten eingeben muss, stumpft das ab.
Die Lösung ist, dass Single Sign In auch ist. was es heißt: Dass ich die Daten nicht täglich mehrmals auf diversen Webseiten eingeben muss.
Das rafft Otto Normaluser nämlich nicht.
Da hilft auch kein Conditional Access und continous evaluation. was auch immer das ist.
Microsoft klärt über solche Angriffe ganz gut auf , wenn man denn die Seiten dazu findet.
Die Phishing Geschichte mit gestohlenen Session Cookies wird hier gut beschrieben.
https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/
Das in Echtzeit versucht wird zu schauen ob die Credentials passen ist schon länger üblich aber halt noch nicht bei allen. Etwas wirklich aussergewöhnliches oder aufwändiges vermag ich hier nicht zu erkennen.
Ja, gleiches hatten wir Anfang des Monats.
In einem großen Businessnetzwerk haben alle Direktoren eine Mail von einer Person bekommen, die Veranstaltungen organisiert (es stellte sich nach Meldung heraus, das der Account Kompromittiert wurde). In der Mail wurde ein SharePoint link mit weiteren Unterlagen angepriesen. Der SharePoint gehört zu einem Weinhandel in Spanien. Die betreffende Person haben wir informiert und der Link wurde 2 Stunden Später gelöscht. in dem SharePoint war eine Verlinkung auf eine externe Seite, auf der dann die Microsoft Zugangsdaten abgefragt wurden.
unser Kunde hat sich dort angemeldet und wurde dann auch über die MFA von Microsoft geleitet. Dann gab es eine Fehlermeldung.
Wir haben umgehend reagiert (10 Minuten) , da waren die Angreifer aus den USA bereits im System und haben die MFA neu gesetzt und sich weitreichend im System umgesehen.
Link zu dem Anmeldeportal, über das die Angreifer die Zugangsdaten erbeutet haben:
*** GB: Link gelöscht, da ich dann mit dem Blog ggf. digital wegen solcher Verweise abgestraft werde. Ich habe die URL aber mal auf virustotal.com prüfen lassen. Im hier verlinkten Screenshot ist zu erkennen, dass der Link als clean angesehen wird. Ruft man die URL auf, erscheint eine Microsoft Anmeldung, wobei aber dort die turbospace-URL schon einen Hinweis liefert, dass das Ding "obskure" ist. ***
Achtung! Hier keine Zugangsdaten eingeben!
Hoffentlich wurde eine Abuse-Meldung an den Provider geschickt? Abuse-Kontaktadressen bekommt man über beliebige Who-Is-Dienste (ua. bei Heise) raus. Und selbst wenn man nur den Registrar (z.B. Godaddy) erwischt, und nicht den Hoster des Servers, reicht das oft schon, sofern der in einem vertrauenswürdigen Land ist. Ein Onlinetraceroute hilft auch manchmal, um den Hostingprovider zu identifizieren.
Jedes Email System sollte eine Adresse "abuse@domain" haben.
Dieser Account MUSS von einem Menschen gelesen werden und sollte auf keinen Fall über irgendwelche Filter gehen, die ja defekt sein können.
Keine Sorge. Die meisten Spammer sind nicht doof und schicken i.d.R. keinen Spam an abuse.
unwitzigerweise haben Microsoft diese E-Mail Adresse nicht eingerichtet und so etwas wie "abuse@[IP Adresse]", also direktes reinkippen in den SMTP Server ist heute völlig unbekannt.
Ehrlich gesagt überhaupt nichts neues. Wir haben selber schon von Kunden, bei denen ein Postfach gehackt wurde E-Mails erhalten, welche dem selben Muster folgten. Das war vor ca 1,5 – 2 Jahren. Damals waren es Sharepoint Links, hier sind es jetzt Dropbox Links. Der Ablauf ist aber identisch. Darum habe ich auch jeden Fileshare Anbieter grundsätzlich auf Quarantäne gesetzt. Zusätzlich kann man das noch mit einem Webfilter verschärfen, dann hängt es aber davon ab, wie oft man mit solchen Diensten arbeitet und man ob sich dann das Leben nicht zu schwer macht. Hier hilft nur Erfahrung und Abwägen.
Man kann den Mitarbeitern aber auch verbieten, solche Dateihoster zu benutzen und die dann z.B. per Proxy sperren. Und wenn jemand externes auf dem Weg was schicken will, den freundlichen Hinweis geben, dass das so nicht möglich ist und eine freigegebene Alternative nennen/schaffen, z.B. ein selbst gehostetes Owncloud.
Proxy?
welcher Proxy?
Man setzt heute den Leuten keinen Proxy mehr vor die Nase.
Es macht der IT Arbeit und bei vielen Usern ist es ein unnötiger Engpass oder Kostenfaktor zumal eh alles HTTPS verschlüsselt ist und nichts gecacht werden kann.
Welcher Proxy also?
Natürlich gibt es trotz HTTPS weiterhin Proxies:
a) Um z.B. den Rest des Systems offline zu halten, während nur der Browser Internetzugriff hat.
b) Um regelbasiertes Internet mit oder ohne Userauth zu gewähren oder einzuschränken.
c) Um Lizenz- und Zugriffsregelung umzusetzen. Ohne den Proxy einer Uni könnten keine Jurastudenten in Urteilsdatenbanken und Kommentierungen recherchieren oder Naturwissenschaftler in Papers.
Und HTTPS allein ist kein Hinderungsgrund für Proxies. DPI sagt Dir was? Leider in großen Konzernen öfters anzutreffen.
Ich habe gestern bei einem Kunden (Anwaltskanzlei) einen ähnlich gegliederten Fall bearbeitet.
Hier der Ablauf:
https://app.any.run/tasks/1a1dd639-4b49-4d4d-a2c8-2680e68998f4
Der erhaltene Link war sehr ähnlich. Auch das OneNote mit dem PDF-Symbol unterscheidet sich nicht sonderlich.
Die Domain habe ich im Anschluss vom betreiber "namesilo" sperren lassen.
https://www.whois.com/whois/husr.top
> Lediglich die in Englisch gehaltenen Anmeldeinformationen
> hätten ein deutsches Opfer stutzig werden lassen können.
Gerade bei irgendwelchen Cloud-Diensten bekomme ich ständig englische Dialoge, bevor ich mich angemeldet habe und der Dienst dann erst weiß, dass ich es bin und "deutsch" als Sprache gewählt hatte.
Interessanter Einblick.
Allerdings bin da irgendwie komplett raus, wenn eine 50kb pdf Datei per Mail auf Dropbox verlinkt ist und die Anmeldung (wofür?) dann über ein MS-Konto läuft. Noch mehr potentielle Angriffsvektoren kann man auch irgendwie kaum einbauen.
ich musste sehen wie eine arrogante, aber unfähige IT eine OwnCloud basteln wollte.
mit SSO.
Dad SSO funktionierte natürlich nur mit dem Internet Explorer aka Edge, Firefox Nutzer sollten ihre Login wiederholen…
Ich weiß nicht, wie diese Leute in diese Position gekommen sind. Vermutlich durch Korruption und Vettern Wirtschaft.
ein ehemaliger Kommilitone hatte ein Gaststätte eröffnet. Der Laden lief sehr gut. Seltsamerweise nahmen bei jeder Veranstaltung die Anzahl der Schlägereien zu. Hausverbote halfen nicht,es kamen dann andere. Schlägereien vergällen aber die seriösen Gäste und irgendwann war klar, was da hintersteckte: Er bekam das höchstseriöse Angebot, das man seinen Laden schützen könne… gegen eine freiwillige Umsatzbeteiligung…
Irgendwie wie erinnert mich das Verhalten von Microsoft an diese Schutzgeld Erpresser.
Microsoft schickt immer neue Schläger, die Steit anfangen und bietet dann, gegen erhebliche Beträge Schutz an.
Ist der Gedanke abwegig, wenn man so hört, welchen ungeprüften Murks MS seinen Kunden per Update aufzwingt?
Leider wurde es gegen uns im Betrieb (15 Mann, KMU) auch schon verwendet und ein Anwender jenseits der 60 (ja, ist noch beschäftigt) ist auch drauf reingefallen. Gott sei Dank hat er die 2FA aktiv… war also weniger schlimm, als zuerst vermutet…
Dennoch: alle Passwörter, sowohl privat als auch beruflich, geändert, Rechner neu aufgesetzt, etc. pp
Habe jetzt den ganzen Thread durchflogen, aber das Stichwort „AITM" ist noch nicht gefallen, oder?
Das ist ein sog. Adversary in the Middle Angriff. Anmeldeseite wird vom Original gespiegelt und somit auch die Zugangsdaten real geprüft. Diese werden dann samt MFA Token sowohl an die Originalseite, als auch dem Angreifer übermittelt.
Durch Eingabe einer anderen Emailadresse lassen sich dann auch Anmeldeseiten anderer Firmen samt Original Hintergrundbild aufrufen, solange sie einen M365 Tenant haben.
Die Thematik ist nicht neu. Es spitzt täglich weiter zu und gewinnt
auch an Qualität – auf beiden Seiten.
Office 365 sollte m. E. grundsätzlich gemieden werden – wie die Pest, insbesondere in Unternehmen. Es gibt vernünftige Alternativen, welche aus verschiedensten Gründen von IT-Dienstleistern leider zu selten zum Einsatz gebracht werden. Einer der Gründe ist vermutlich das monatliche "Grundrauschen" bei der Vermarktung in die Cloud. Der andere Grund ist die Beratungsarbeit beim Kunden.
Wenn wir die Karten auf den Tisch legen kommt noch erschwerend hinzu, dass IT-Dienstleister gerne Verantwortung auslagern möchten – aus gutem Grund. Auch der Mehraufwand einen Mailserver selbst zu betreiben, schreckt Unternehmen und Dienstleister häufig ab.
Kronjuwelen, zu denen ich auch eMails zähle, sollten grundsätzlich im Unternehmensnetzwerk lokal verwaltet werden.
Es spricht nichts dagegen Anwender lediglich per VPN Zugriff auf eMails zu gewähren. Die Bequemlichkeit ist allgegenwärtig und wer kein Outlook nutzt
denkt er wäre out, was jedoch nicht der Fall ist, ganz im Gegenteil.
Eine lokaler Mailserver schützt in so einem Fall natürlich nicht, jedoch können gut geschulte Mitarbeiter mit entsprechenden Filtern durchaus solche Angriffe erkennen und sicher damit umgehen. Der eigene Mailserver schützt jedoch vor einer Kompromittierung im eigenen Haus, wenn die eMail Zugriffe auf LAN/VPN beschränkt sind.
Kürzlich wurde ich auf einer Cybersicherheit Veranstaltung über eine Entwicklung Aufmerksam in der sich "junge IT-Unternehmen" damit rühmen, ihre Kunden 100% Serverless aufzubauen. Die Infrastruktur beschränkt sich auf Tablet, Laptop und Smartphone. Schöne neue Welt – ich glaub ich werde alt… :-)
Hallo,
wir hatten eine ähnlichen Angriff auf unseren Tenant.
Wir setzen zwar den MS Authenticator ein, aber wenn dieser dann auch den dem eigenen Mitarbeiter eingegeben wird, dann wir der Session Token geklaut.
Conditional Access Einstellungen:
Ich empfehle diese Session Tokens auf eine geringe Gültigkeitsdauer zu stellen(für Geräte die sich außerhalb der Firmen Standorte befinden).
Ebenso die Ländersperre zu aktivieren, bzw. dafür noch kürzere Gültigkeit der Tokens zu wählen.
Der beste Schutz wäre, nur die eigenen Geräte auf den Tenant zu lassen. Ist leider nicht immer umsetzbar.
Insgesamt sollte man auch immer die Risky Anmeldungen im Tenant kontrollieren.
Wir hatten uns auch auf MFA verlassen. Leider ist dieser Schutz ohne eine Awareness auch nichts wert.
Michael
Also wir haben über CA Regeln 2fa schonmal non mobile User keinen Zugriff auf O365 außerhalb der Firma WAN IPS gegeben. ohne Wertung sind die größten DAU User nicht mobil unterwegs und brauchen keine E-Mails nicht. das risky users Log im entrada hat bei uns wenig false positiv.
Meine Risikobewertung und Erfahrung sieht eher so aus, dass die Power-User eher auf sowas reinfallen als die Unsicheren. Die rufen lieber einmal durch und fragen, bevor was weggeklickt oder ausgefüllt wird.
Je erfahrener und mit Privilegien, desto gefährlicher.
Wir wurden auch durch genau dieses Vorgehen angegriffen, wir konnten die Zugriff in kurzer Zeit nachdem leider schon erneut Mail versenden wurden deaktivieren. Was aufgefallen ist, die Angreifen haben in dem betroffenen Benutzerkonto eine Anwendung registriert für den Zugriff ohne MFA, in unserem Fall war dass der "eM Client", diese haben wir dann auch komplett entfernt. Aber so waren dann auch weitere Zugriffe ohne erneute MFA möglich.
Ich schreibe den Kommentar, weil das ein wichtiger Punkt der Gegenmaßnahmen ist, wenn man betroffen war.
Ggf. werden auch andere Anwendungen genutzt, hier sollte man bei dem Anwender auf neue Anwendungen achten die zu dem fraglichen Zeitpunkt des eigenen Angriffs erstellt wurden.