infoguard-blog-azure-teil2

Wie schütze ich meinen Azure-Account

Im letzten Blogbeitrag haben wir uns vertieft mit Business E-Mail Compromise (BEC) auseinandergesetzt. Als kleine Wiederholung: Ein Angreifer verschafft sich Zugang zu einem fremden E-Mail-Konto, um sich in legitime Mail-Konversationen einzuschleusen. Dadurch können zum Beispiel Kontoangaben in Rechnungen manipuliert oder Spam-E-Mails über den kompromittierten Account versendet werden. Das FBI bezifferte alleine den durch Business E-Mail Compromise gemeldete Schaden auf knapp 2,4 Milliarden US-Dollar (Internet Crime Report 2021). Diese Schadenssumme übersteigt jene von Ransomware um ein Vielfaches. Da BEC also durchaus ein ernst zu nehmender Vorfall ist und nicht «nur» ein kompromittierter E-Mail-Account, werden wir uns im zweiten Teil meines Azure-Blogbeitrages noch vertiefter mit der Sicherheit von E-Mail-Konten und dem Schutz von Azure-Accounts befassen.

Password Spraying

Einer der wirksamsten Mechanismen gegen kompromittierte Azure-Accounts ist das Einschalten der Multi-Factor-Authentication (MFA), die wir schon im ersten Teil kennengelernt haben. Auch wenn Benutzer ihre Passwörter nicht auf einer Phishing-Seite eingeben, haben Angreifer die Möglichkeit, mit öffentlich verfügbaren Tools wie MSOLSpray schwache Passwörter zu knacken.

Das Script des MSOLSpray führt eine sogenannte Brute-Force-Attacke aus. Das heisst, es werden eine Liste von Passwörtern pro Benutzer-Account durchprobiert. Dieses Vorgehen ist gerade bei einer schwachen Passwort-Policy sehr vielversprechend und wird auch öfters für die initiale Kompromittierung von Azure-Accounts verwendet.

 

Abbildung 1: MSOLSpray – Password Spraying Software

Eine gute Möglichkeit, um den Azure Tenant weiter abzusichern, ist der Einsatz der «Azure AD Password Protection». Dabei können selbst definierte Wörter konfiguriert werden, die von den Benutzern nicht als Teil vom Passwort verwendet werden dürfen. Zudem hat Microsoft eine Liste bereitgestellt, die in Kombination mit der eigenen konfigurierbaren Liste die Passwortsicherheit erhöht.

 

Abbildung 2: Liste der Wörter, die nicht in Passwörter vorkommen dürfen

Illicit Consent Grant – ein Klick ist genug

Eine weniger bekannte Technik, um Zugang zu einem Azure-Account zu erhalten, ist der «Illicit Consent Grant». Dabei versendet der Angreifer ein E-Mail an sein Opfer mit einem Link, der zu einer präparierten Applikation führt (Abbildung 3). Die vom Angreifer präparierte Applikation verlangt vom Benutzer gewisse Rechte wie der Zugriff auf die Mailbox oder das Profil. Der Klick auf den Accept-Button führt dazu, dass die Applikation danach im Kontext vom Benutzer-Account innerhalb von Azure installiert wird. Damit hat der Angreifer vollen Zugriff auf das Konto vom Opfer resp. auf alle Daten, die mit den bewilligten Rechten einsehbar sind.

 

Abbildung 3: Eine bösartige App verlangt Zugriff auf die E-Mails vom Opfer

Das Perfide daran: Der Benutzer musste zu keinem Zeitpunkt sein Passwort eingeben! Ein unbedachter Klick genügt, um wiederum Opfer von Angreifern geworden zu sein. Administrator*innen können ihre Benutzer aber auch hier relativ einfach gegen diese Angriffsform schützen, indem den Benutzern die Installation von Applikationen in den Tenant nicht erlaubt wird (Abbildung 4).


Abbildung 4: TODO

Dabei können spezifischen Applikationen immer noch auf einer per Benutzerbasis von Administrator*innen installiert werden. Unser InfoGuard Computer Security Incident Response Team (CSIRT) geht davon aus, dass solche Angriffsformen immer häufiger durchgeführt werden, da Mutli-Factor-Authentication die einfachen Phishing-Angriffe zunehmend erschwert.

MS Azure Konfiguration überprüfen

 

Bypassing Multi-Factor-Authentication

Multi-Factor-Authentication ist zwar ein sehr wirksamer Schutz gegen Account-Kompromittierungen; einen 100-prozentigen Schutz in der IT-Sicherheit ist jedoch eine Illusion. Angreifer verwenden teils Angriffsformen wie «Push Notification Spamming», bei denen sie zuerst über Phishing oder Brute-Forcing an das legitime Passwort vom Benutzer gelangen, um sich dann so lange versuchen einzuloggen, bis der Benutzer in der Authenticator-App seine Zustimmung zum Login gibt (Abbildung 5 rechts).


Abbildung 5: Bestätigungs-Prompt für die Multi-Factor-Authentication (Quelle: jeffreyappel.nl)

Auch hier reicht ein falscher Klick – eben die Zustimmung für das Login –, damit die Angreifer Zugriff auf den Azure-Account vom Benutzer erhalten und in der Folge auch einen weiteren eigenen Authentisierungsmechanismus für das Login einrichten können (Abbildung 6), was MFA somit aushebelt.


Abbildung 6: TODO

Die gezielte Überwachung der Sign-In Logs (wie im ersten Blogbeitrag beschrieben) kann hier ein guter Indikator für ein verdächtiges Login sein, selbst wenn der Benutzer den zweiten Faktor bestätigt hat. Aber auch bei dieser Angriffsform können wir die Latte für Angreifer höherschrauben, indem zum Beispiel die Verwendung von einem simplen Promt in der Authenticator App nicht mehr zugelassen werden, sondern der Benutzer muss eine zusätzliche Nummer für die Bestätigung eingeben. Dieser zusätzliche Schritt könnte schon genügen, um den Angriff zu stoppen.


Abbildung 7: Keine simple Bestätigung mehr (Quelle: jeffreyappel.nl)

Diverse weitere Implementierungen und Techniken sind unter Link einsehbar.

Shady Service Providers

Innerhalb der Sign-In Logs von Azure kann gezielt nach verschiedenen Kriterien gefiltert werden. Einer dieser Filter ist für die autonomen Systeme (kurz AS). Ein AS wird primär für das Routing im Internet verwendet und kann mehrere grössere Netze beinhalten. Klassischerweise haben Internet Server Provider und grosse Firmen eigene AS oder ASN (Autonomous System Numbers).

Unser CSIRT hat in diversen Azure-Untersuchungen regelmässig die folgenden ASN-Nummern gesehen, die in Zusammenhang mit kompromittierten Account stehen:


  • 33438 – HIGHWINDS32
  • 25369 – Hydra
  • 62240 - Clouvider
  • 9009 – M247
  • 60068 – Datacamp
  • 40676 – Psychz

 

Alle Logins von diesen ASN sollten genauer untersucht werden. Natürlich könnten sich Mitarbeitende immer noch per VPN in den Azure Tenant einloggen – viele VPN Provider verwenden auch Services von den oben stehenden ISPs –, aber zumindest ist das Hunting nach Logins von diesen ASN ein guter Startpunkt für eine vertiefte Analyse der aufgezeichneten Logins.

Defense-In-Depth

Multi-Factor-Authentication

Obschon bereits erläutert, kann die Wichtigkeit der Multi-Factor-Authentication nicht genug betont werden. Wenn möglich, sollte der einfache Bestätigungsdialog mit der Eingabe einer Zahl ersetzt oder es sollten andere Faktoren wie ein Token für das Login verwendet werden, um die Gefahr von «MFA Prompt Spamming» zu verringern.

Unterbindung der Installation von Apps

Ein weiterer Sicherheitsgewinn für den Azure Tenant kommt mit der Unterbindung von App-Installationen durch normale Benutzer. Administrator*innen können es Benutzern erlauben, eine Notification auszulösen, wenn sie eine Applikation installiert haben möchten. Diese Notification wird anschliessend von den Administrator*innen geprüft und die Applikation bei Bedarf installiert. Durch diese Restriktionen können geschickte Angriffe wie die «Illicitat Grant» zumindest erschwert werden.

Sichere Passwörter

Auch der Einsatz der global «verbannten» Passwort-Liste von Microsoft in Zusammenhang mit einer eigenen Passwort-Liste mit Wörtern, die nicht in Passwörtern vorkommen dürfen, kann die Sicherheit von Azure-Accounts erhöhen. Durch die gesteigerte Komplexität der Passwörter ist es für Angreifer schwieriger, durch simples Erraten der Passwörter ein Konto zu knacken.

 

Wünschen Sie eine Überprüfung Ihrer Azure-Konfiguration?

Damit Sie nicht auch zu den zahlreichen prominenten Opfern zählen, bieten wir speziell für Sie eine dezidierte, einmalige Hunting Session in Ihrer kompletten Azure-Umgebung an. Das attraktive Package beinhaltet die folgenden Leistungen:

  • Analyse der Logins: Aufklärung verdächtiger Logins basierend auf den verwendeten Ländern und ISP's.
  • Analyse der konfigurierten Mail-Regeln all Ihrer Benutzer.
  • Analyse der installierten (Azure-)Apps der Nutzer zur Erkennung des sogenannten "Illicit consent grant attack".
  • Individuelle Beurteilung mittels kleinem, abschliessendem Report.
  • Einmalige Investition von CHF 2'400.- (pauschal).

Interessiert? Unsere Incident Response Experten im CSIRT freuen sich über Ihre Kontaktaufnahme und überprüfen mittels eines One-Time Huntings gerne Ihren Azure-Tenant auf gehackte Accounts.

MS Azure Konfiguration überprüfen

<< >>

Breach Detection , Cyberrisiken , CSIRT

Stephan Berger
Über den Autor / Stephan Berger

InfoGuard AG - Stephan Berger, Head of Investigations

Weitere Artikel von Stephan Berger


Ähnliche Artikel
Dunkle Wolken am Security-Himmel – Kompromittierung von Azure-Accounts
Dunkle Wolken am Security-Himmel – Kompromittierung von Azure-Accounts

Das CSIRT der InfoGuard hat in den letzten Monaten verschiedene Cybervorfälle im Azure Umfeld bearbeitet, [...]
Schnell, schneller, XDR – wie Sie Ihre Detection & Response beschleunigen können
Schnell, schneller, XDR – wie Sie Ihre Detection & Response beschleunigen können

Viele Sicherheitsteams können aktive Angriffe nicht schnell genug erkennen und deshalb auch nicht rechtzeitig [...]
[Video] Ein Cyber-Krimi in 48 Stunden
[Video] Ein Cyber-Krimi in 48 Stunden

«Willkommen. Wir sind es, nochmals... Ihre Dateien sind verschlüsselt und derzeit nicht verfügbar. Sie können [...]

Spannende Artikel, aktuelle News sowie Tipps & Tricks von unseren Experten rund um Cyber Security & Defence.

Blog Updates abonnieren
Social Media
infoguard-cyber-security-ratgeber-2