Wir reiten ja immer wieder auf dem Thema Sicherheit herum und empfehlen ATP als O365 AddOn. Bis dato fehlte uns allerdings ein echter Schadensfall in der eigenen Kundschaft. Das ist natürlich eine gute Nachricht und spricht dafür, dass unsere initialen Vorsichtsmaßnahmen bei neuen Mandanten sowie regelmäßige Aufklärung wirken.

Honeypod O365

Trotzdem muss man sich immer wieder deutlich machen, dass Office 365 ein inzwischen extrem verbreiteter Dienst ist, auch weltweit. Das erhöht den Anreiz für IT-affine Menschen mit bösen Absichten, O365 für Angriffe jeglicher Art zu nutzen. Die Firma Vade Secure bringt es mit folgendem Statement auf den Punkt: "Microsoft is the number one phished brand for the fourth straight quarter—thanks to Office 365. A multisystem platform, Office 365 combines email, file storage, collaboration, and productivity applications, including OneDrive and SharePoint. Together, they represent a honeypot of sensitive data and files that phishers are looking to exploit."

Der Angriff

Leider kam es kürzlich bei einem Kunden zu einem "gehackten" Account mit einer O365 Business Premium Lizenz (ohne ATP, ohne MFA). Microsoft selbst hat den "Hack" (vermutlich) anhand von einer stark gehäuften Anzahl von Anmeldungen von unterschiedlichen IP-Adressen automatisiert erkannt und zunächst den Versand von Emails gesperrt, was die klassische Gegenmaßnahme ist, wenn z.B. auffällig viele Emails oder Spam Emails versendet werden. Daraufhin wies auch die Fehlermail, die beim Versuch, Mails zu senden, unmittelbar zurückkam: "Your message couldn't be delivered because you weren't recognized as a valid sender. The most common reason for this is that your email address is suspected of sending spam and it's no longer allowed to send messages outside of your organization. Contact your email admin for assistance."

Die technische Meldung lautete: "550 5.1.8 Access denied, bad outbound sender AS(42003)"

Die gute Nachricht ist, dass das automatisierte Monitoring in der Microsoft Cloud funktioniert, ein großer Vorteil bei den ganzen Klein- udn Kleinstunternehmen, die Office 365 heute nutzen und die Ihre Infrastruktur nicht professionell überwachen können.

 

Analyse

Eine Überprüfung des Mail-Datenfluss ergab, dass keine Spam-Mails versendet worden sind. Der Benutzer war aber tatsächlich in O365 gesperrt bzw. eingeschränkt, was man etwas versteckt im neuen Security und Compliance Admin Center (https://protection.office.com/restrictedusers) sehen konnte. Dort sah die Ursache schon etwas gefährlicher aus:

2020-01_O365-kompromittiertes_Konto.jpg

 

Der Benutzer kann hier auch von einem Admin wieder entsperrt werden. Das allerdings nicht zu empfehlen. Vorher empfiehlt auch Microsoft folgende Maßnahmen:

  1. Active Directory auf verdächtige Anmeldungen überprüfen
  2. Passwort zurücksetzen (im Admin Center)
  3. Mail Weiterleitungen überprüfen (im Admin Center)
  4. Mail Regeln überprüfen (in Outlook Web angemeldet als der kompromittierte User)

Zu Punkt 1: Im AD (https://aad.portal.azure.com/) kann man den Benutzer auswählen und direkt auf der Übersichtseite die Anmeldegrafik prüfen:

Das sieht schonmal verdächtig aus. Im Detail kann man dann unter Aktivität-Anmeldungen eine komplette Liste aller Anmeldungen der letzten 7 Tage abrufen. Hier waren zahlreiche erfolgreiche Anmeldungen aus verschiedenen deutschen Städten verzeichnet, die nicht vom Anwender besucht worden waren.

Zu Punkt 4: Hier wurde die Sache dann langsam klarer. Die im Screenshot angezeigte Mail-Regel wurde in Outlook gefunden (Zahnrad/Einstellungen - Outlook Einstellungen - Regeln).

2020-01_O365-Phishing-attack_mail_rule.jpgDie Regel erkennt offenbar bestimmte Muster in eingehenden Emails und leitet diese weiter  an „cpatrishalee[at]protonmail.ch“, vermutlich ein automatisierter Check, ob die Übernahme des Accounts schon entdeckt und bereinigt worden ist. Vielleicht sollten  zunächst viele Accounts "gesammelt" werden, um dann zu einem Zeitpunkt X z.B. Spam Emails zu versenden. Theoretisch sind natürlich noch viele andere Dinge denkbar, z.B. der Missbrauch von Flow bzw. Power Automate.

 

Ursache 

Was war nun die Ursache für den "Hack"? Die o.g. Email Adresse in der Mail Regel verweist auf einen Twitter Eintrag von TheAnalyst 2020-01_O365-Phishing-attack_Twitter-snippet.jpg(https://twitter.com/ffforward/status/1176138022754095104, siehe auch der Screenshot rechts).

Er beschreibt einen Phishing Angriff z.B. per Email oder durch Abgreifen von zufälligen Fehleingaben der Microsoft-Domains im Browser. Die Phishing Seite sah dabei genauso aus wie die O365 Login Seite, war aber nur dazu da, um das O365-Login abzugreifen. Es wurden täuschend echte Domains dafür genutzt mit kleinen Schreibfehlern, z.B. portal.microsoiftonline.com oder microstroftonline.com. Dort hatte der Nutzer pflichtgemäß seine Daten eingegeben und die Aktion abgehakt.

Es zeigt sich ein Problem der Microsoft Online Welt. Durch die penetranten nicht immer einleuchtenden und wiederkehrenden Login Aufforderungen (wenn z.B. mehr als ein Account genutzt wird oder wenn einfach in der MS-Welt die Integration von OneDrive/Sharepoint und Outlook in Windows mal hakt), wird man regelrecht abgestumpft und knallt einfach immer wieder seine Login Daten rein und hofft, dass Windows dann endlich Ruhe gibt. Ein nicht erfolgreicher Login mehr oder weniger fällt jedenfalls nach unserer Erfahrung zunehmend weniger auf.

 

Gegenmaßnahmen

Zurück zur Bereinigung: Neben dem Passwort-Wechsel und dem Löschen der Mail-Regeln ist es in einem solchen Fall wichtig, den Mandaten noch einige Zeit zu beobachten z.B. auf verdächtige Anmeldungen im AD.

Es ist auch möglich, dass weitere Benutzer des Mandaten, also ArbeitskollegInnen betroffen sind, denn mit einer internen Email-Adresse fällt es leichter unverfängliche Emails an Kollegen zu senden und z.B. um Passwörter zu bitten oder weitere Phishing Seiten zu empfehlen.

Deshalb sollten auch ArbeitskollegInnen zur Sicherheit das Passwort wechseln und die Mail-Regeln in Outlook überprüfen.

 

Wie kann man sich im Vorfeld schützen?

ATP (Advance Thread Protection) als kostenpflichtiges O365-AddOn verhindert Phishing, sofern es von einer Email ausgeht, was allerdings in fast allen Fällen der Fall sein dürfte. ATP schützt auch Anhänge nochmal gesondert, wir haben darüber schon mehrfach berichtet, hier der Artikel dazu: https://itensity.de/blog/office-365-sicherheits-addon-atp-im-praxistest

Es gibt eine Reihe von Einstellungen und Vorgaben (Policies) im Admin Portal von O365. Dazu gehören Regeln zur Meldung von Vorfällen z.B. an bestimmte Email Adressen, aber auch definierbare Grenzwerte z.B. für die Gesamtzahl von Emails, die von einem Nutzer oder allen Nutzern gemeinsam versendet werden. So kann man z.B. festlegen, dass nach der Versendung von 100 Emails in einer Stunde der Mailversand für den Rest des Tages unterbunden wird.

MFA (Multi Factor Authentication) als nutzbares Office 365 Feature verhindert die Übernahme eines Accounts mit Benutzername und Passwort. Mit MFA kommt ein 3. Faktor hinzu, z.B. die Freigabe durch die Authentication App oder auch durch eine SMS TAN. MFA ist als Thema im Detail etwas komplexer, wie werden darauf nochmal gesondert eingehen. Einigermaßen sicher ist, dass MFA in naher Zukunft im Hinblick auf die Anforderungen zur Datensicherheit in der DS-GVO als Pflicht angesehen wird, wenn es um die Frage geht, ob man personenbezogene Daten in den eigenen IT-Systemen (und damit auch Office 365) nach dem Stand der Technik angemessen schützt. Andersherum formuliert: Ohne die Nutzung von MFA arbeitet man nicht mehr DS-GVO konform. Letztlich werden das natürlich verbindlich erst Gerichte entscheiden, aber zu erwarten ist es.

Außerdem hilft die Aufklärung der Benutzer:

  • Jede Email kann böse sein, auch wenn sie augenscheinlich aus vertrauenswürdiger Quelle kommt
  • Microsoft wird niemals per Email nach Login Daten fragen
  • Office 365 Accounts laufen nicht aus und müssen per Login verlängert werden
  • Passwörter laufen in gut konfigurierten Mandanten nicht aus, so dass eine Änderung niemals erzwungen wird (Ausnahme wäre der erste Login eines neues Benutzers)
  • Admins fragen auch nicht per Mail nach einem Passwort, im Zweifel und nach Rücksprache setzen sie es einfach zurück

Nachtrag (28.01.2020): Ich habe im Nachgang auch unsere eigenen Azure AD Anmeldedaten genauer überprüft. Es zeigt sich, dass es normal sein kann, wenn z.B. der Kölner Anmeldungen aus Düsseldorf hat, wenn man sich nämlich im Mobilfunknetz der Vodafone mit Zugangspunkt in Düsseldorf befindet. Bei der Telekom kann man analog in Frankfurt landen.

Weiterhin zeigt sich aber auch, dass MFA zur zusätzlichen Absicherung eine gute Entscheidung ist, denn tagtäglich kann es konventionelle Angriffe mit Nutzername und Passwort geben. Hier eine Liste der fehlerhaften Anmeldungen aus unserem Mandaten nur der letzten 7 Tage, nur um mal einen konkreten Eindruck zu geben:

197.50.41.140 Al Qahirah, Al Qahirah, EG
185.71.82.51 Sevastopol', Sevastopol' Misto, UA
122.155.37.168 Bangkok, Krung Thep, TH
103.192.76.215 Kathmandu, Province 3, NP
221.193.248.52 Fengfeng Kuangqu, Hebei, CN
221.224.40.74 Suzhou, Jiangsu, CN
220.189.235.126 Huzhou, Zhejiang, CN
220.164.193.238 Kunming, Yunnan, CN
110.137.250.101 Jakarta, Jakarta Raya, ID
125.32.1.146 Changchun, Jilin, CN
181.118.196.70 Caleta Olivia, Santa Cruz, AR
182.253.117.21 Jakarta, Jakarta Raya, ID
177.135.101.101 Sao Paulo, Sao Paulo, BR
14.161.18.209 Ha Noi, Ha Noi, VN
118.163.135.17 Taipei, Taipei, TW
122.139.5.236 Changchun, Jilin, CN
219.145.195.44 Xi'an, Shaanxi, CN
219.145.195.44 Xi'an, Shaanxi, CN
159.192.121.133 Bangkok, Krung Thep, TH
177.99.217.233 Porto Alegre, Rio Grande Do Sul, BR
171.103.141.50 Bangkok, Krung Thep, TH
173.245.239.231 Atlanta, Georgia, US
61.6.244.146 Bandar Seri Begawan, Brunei And Muara, BN
61.191.130.198 Hefei, Anhui, CN
222.189.186.67 Yangzhou, Jiangsu, CN
220.164.2.77 Kunming, Yunnan, CN
183.88.222.35 Nonthaburi, Nonthaburi, TH
221.130.130.238 Xicheng Qu, Beijing Shi, CN

 

Es zeigt sich, dass der in den Medien oft verschrieene böse Russe nicht das Problem ist, sondern China.

Diese Anmeldungen erfolgten alle schon mit dem korrekten Login Namen (Email Adresse), der ja auch kein Geheimnis ist. Ohne MFA wäre es nur noch eine Frage des richtigen Passworts. Das wäre ein zu hohes Risiko.

 


Konversation wird geladen