[English]Die Sicherheitsexperten von Microsoft haben diverse Einbruchsaktivitäten beobachtet, die auf den Diebstahl von Zugangsdaten mehrerer Microsoft-Kunden abzielen. Diese Angriffe durch mutmaßlich staatliche Akteure (China-Russland) waren wohl erfolgreich und wurden durch Passwort-Spray-Angriffe oder über RDP ermöglicht.
Anzeige
Warnung vor Passwort-Spray-Angriffen
Der erste Fall betrifft mutmaßlich chinesische Hackergruppen, die Zugangsdaten für Benutzerkonten abgreifen wollen. Microsoft hat die Erkenntnisse über laufende Cyberangriffe auf Kunden durch mutmaßlich staatliche Akteure bereits Ende Oktober 2024 in diversen Tweets veröffentlicht.
Es heißt, dass Microsoft Einbruchsaktivitäten aufgefallen sind, die auf mehrere Microsoft-Kunden abzielen. Dabei sollen erfolgreich Anmeldedaten für diese Konten gestohlen worden sein. Dies wurde durch Passwort-Spray-Angriffe ermöglicht, sprich, die Kunden haben keine Zweifaktor-Authentifizierung zur Absicherung der Konten verwendet.
Die Passwort-Spray-Angriffe gehen laut Microsoft auf ein Botnet, bestehend aus einem Netzwerk kompromittierter Geräte, aus. Dieses Botnet wird von Microsoft als CovertNetwork-1658, oder xlogin und Quad7 (7777), bezeichnet.
Anzeige
Microsoft verwendet den Begriff "CovertNetwork" für eine Sammlung von IPs, die kompromittierten oder geleasten Geräten zugeordnet sind, und die von einem oder mehreren Bedrohungsakteuren verwendet werden können. Microsoft geht davon aus, dass ein in China ansässiger Bedrohungsakteur CovertNetwork-1658 eingerichtet hat und unterhält.
Microsoft hat den chinesischen Bedrohungsakteur Storm-0940 beobachtet, der Anmeldeinformationen von CovertNetwork-1658 verwendet. Storm-0940 ist seit 2021 aktiv und hat es auf Organisationen in Nordamerika und Europa abgesehen, darunter Think Tanks, Regierungsorganisationen, NGOs, Anwaltskanzleien und die Verteidigungsindustrie.
Details lassen sich im Blog-Beitrag Research Threat intelligence Microsoft Defender XDR Attacker techniques, tools, and infrastructure 8 min read Chinese threat actor Storm-0940 uses credentials from password spray attacks from a covert network nachlesen.
Spear-Phishing per RDP durch Midnight Blizzard
Eine weitere Bedrohung existiert durch die staatliche russische Hackergruppe Midnight Blizzard, die per Spear-Phing mit RDP-Files versucht in Netzwerke einzudringen. Microsoft Threat Intelligence beobachtet seit dem 22. Oktober 2024, dass der russische Bedrohungsakteur Midnight Blizzard eine Reihe gezielter Spearphishing-E-Mails an Personen in Behörden, Hochschulen, Verteidigungseinrichtungen, Nichtregierungsorganisationen und anderen Sektoren versendet.
Opfern wird eine Phishing-Mail mit einer RDP-Datei zugeschickt. Die Spear-Phishing-E-Mails in dieser Kampagne wurden an Tausende von Zielpersonen in über 100 Organisationen gesendet und enthielten eine signierte RDP-Konfigurationsdatei (Remote Desktop Protocol), die eine Verbindung zu einem von einem Akteur kontrollierten Server herstellte.
In einigen der Köder versuchten die Täter, ihren bösartigen Nachrichten mehr Glaubwürdigkeit zu verleihen, indem sie sich als Microsoft-Mitarbeiter ausgaben. Der Bedrohungsakteur verwies in den Phishing-Lockmitteln auch auf andere Cloud-Anbieter. Fällt das Opfer auf den Köder herein, versuchen die Hacker Informationen über Zugänge zu sammeln.
Microsoft hat die Details der Kampagne und die Erkenntnisse Ende Oktober 2024 im Blog-Beitrag Midnight Blizzard conducts large-scale spear-phishing campaign using RDP files veröffentlicht.
Florian Roth hat in diesem Tweet die YARA-Rules zum Aufspüren dieser Phishing-Angriffe veröffentlicht.
Microsoft forgot to include the hashes of the RDP files and I wrote a YARA rule to detect them Hashes
db326d934e386059cc56c4e61695128e 40f957b756096fa6b80f95334ba92034 f58cf55b944f5942f1d120d95140b800 b38e7e8bba44bc5619b2689024ad9fca e1d7de6979c84a2ccaa2aba993634c48 f7e04aab0707df0dc79f6aea577d76ea
Ähnliche Artikel:
China-Hacker (Storm-0558) in Microsofts Cloud, Outlook Online-Konten gehackt
Nachlese zum Storm-0558 Cloud-Hack: Microsoft tappt noch im Dunkeln
Nach CISA-Bericht zum Storm-0558-Hack stellt Microsoft Kunden erweitertes Cloud-Logging bereit
GAU: Geklauter AAD-Schlüssel ermöglichte (Storm-0558) weitreichenden Zugang zu Microsoft Cloud-Diensten
Hewlett Packard Enterprise (HPE) von Midnight Blizzard seit Mai 2023 gehackt
Whistleblower: Microsoft ignorierte Warnungen vor Azure AD-Bug; wurde 2020 bei SolarWinds-Hack ausgenutzt
Midnight Blizzard-Hack-Benachrichtigung: Microsoft schickt Kunden Mail die in SPAM-Ordnern landet
Microsoft übt sich in Schadensbegrenzung bei Kongress-Anhörung (13.6.2024): Sicherheit habe Vorrang vor KI
Microsoft Ankündigung einer Secure Future Initiative
Microsoft durch russische Midnight Blizzard gehackt; E-Mails seit Nov. 2023 ausspioniert
Wie Midnight Blizzard-Hacker in Microsofts E-Mail-System eindringen konnten
Microsoft bestätigt: Russische Spione (Midnight Blizzard) haben Quellcode beim Zugriff auf Systeme gestohlen
Microsoft: Neues vom Midnight Blizzard-Hack – auch Kunden möglicherweise betroffen
Midnight Blizzard-Hack bei Microsoft: US-Behörden und Großkunden suchen Alternativen
Anzeige
Azure wurde vor einiger Zeit gehackt und Microsoft weis bis heute nicht genau wie!
Eventuell hängt dieser Angriff ja damit zusammen, den Microsoft weiß auch nicht, welche Daten genau damals erbeutet wurden.
Ergo, Azure ist unsicher und sollte nicht mehr genutzt werden!
Es hat schon seinen Grund, warum das Pentagon wichtige Dinge nicht mehr in Microsofts-Cloud ablegt.
Tatsächlich habe ich mir ähnliches auch gedacht. Und gleich noch ein paar plausible Nebelkerzen werfen…
Microsoft hat immens Vertrauen verspielt (bei denen, die mal hatten)
Azure gehackt ist noch milde formuliert… die Master Keys herausgetragen haben die.
Microsoft hat dazu einen sehr ausführlichen Post geschrieben und den Vorfall detailliert aufgeklärt.
https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/
Ist das alles richtig? Ist alles geschlossen und sicher?
Vermutlich nicht. Denn es wird immer wieder und wieder Angriffe geben, mit neuen Techniken, neuen Angriffsvektoren etc. AI sei dank wird es noch mehr.
Aber ich vertraue lieber Microsoft, als einem kleinen Serverhoster mit wenig und nicht ausreichend qualifiziertem Personal.
Kümmere Dich selbst um Deine Daten, dann musst Du niemandem vertrauen
und sparst auch noch Geld, bist von niemanden abhängig!
Im begrenzten Maßen kann man unbekannten Diensten (Servern) im Internet ja
benutzen, aber blind vertrauen? Hey, die Anbieter wollen nur Dein Bestes,
Deine Daten und Dein Geld!
Dazu muss man das aber auch selbst wirklich können! Was ich da schon alles gesehen habe, weia…!
> mit wenig und nicht ausreichend qualifiziertem Personal.
Oh weia das dürfte eher auf Microsoft zutreffen, die für die Menge an Services und Systemen eindeutig zu wenig und ausreichend qualifiziertes Personal vorhalten. Schonmal bei MS versucht Support zu bekommen?
Ist das so?
Das ist doch nicht schlimm, sagen einige Länderverwaltungen und die haben doch alles in Griff, wenn wir unsere Verwaltungsdaten, war es mit SAP zusammen, in die Wolke laden.
Deutsches Neuland und wissende Politiker halt.
Zur Kennzeichnung – Alles Ironie.
Vier Fragen:
– wer stellt RDP-Zugänge ohne was davor ins Internet?
– wer filtert RDP Dateien nicht aus Emails raus? Bzw. die ganze Mail?
– wer lässt RDP vom Arbeitsplatz direkt auf Systeme im Internet zu?
– wer schult seine Mitarbeiter nicht in Bezug auf Phising, z.B. auch mit fingierten Trainingsmails?
Ämter und Behörden!
Und auf diverse Firmen trifft das auch zu.
Wer betreibt denn bitte noch einen eigenen E-Mail-Server?
Geschweige denn eigene Fileserver?
Alle Fragen beantwortet?
Selbst Mailserver in der Wolke können Mails filtern. Und was hat das denn mit Fileservern zu tun?
Alle Theorie ist grau – die Schmerzen bringt die Praxis. Wenn deine Welt so wäre, wie beschrieben, hätte ich diesen Blog-Beitrag mit Verweis auf einen MS-Sicherheitsbeitrag sparen können ;-).
Entsprechende Recommendations und Best Practizes gibts von MS bestimmt.
@Froschkönig: Ich finde Deine 4 Fragen berechtigt. Allerdings passt die 1. Frage nicht zum Sachverhalt:
"When the target user opened the .RDP attachment, an RDP connection was established to an actor-controlled system. The configuration of the RDP connection then allowed the actor-controlled system to discover and use information about the target system, including:
Files and directories
Connected network drives
Connected peripherals, including smart cards, printers, and microphones
Web authentication using Windows Hello, passkeys, or security keys
Clipboard data
Point of Service (also known as Point of Sale or POS) devices"
Der Ziel-Host für den RDP-Zugang wird vom "malicous actor" betrieben. Der wird den RDP-Zugang natürlich nicht "schützen", sondern gerade offen lassen.
Die restlichen 3 Fragen sind allerdings tatsächlich Versäumnisse des angegriffenen Unternehmens.
Deswegen Frage Nummer 3, würde ich mal vermuten. Macht auf jeden Fall Sinn, was der König der Frösche da fragt.
@Gänseblümchen:
Frage 3: "Wer lässt RDP vom Arbeitsplatz direkt auf Systeme im Internet zu?"
Wenn ich auf Azure-VMs zugreifen will (die bei MS in deren Azure-Rechenzentren) laufen, muss ich als Admin RDP nutzen. Die Firewall-Regel ist natürlich sehr "eng" eingestellt: Quelle "Meine Maschine" > Ziel: "genau die eine Azure VM".
Gibt es hier noch mehr Schutzmöglichkeiten?
Naja, wenn das eine eigene VM in Azure ist, dann ist das keine von Phising-Hackern kontrollierte Maschine, hoffentlich jedenfalls… Dann kann ich da gefahrlos auch eine RDP-Verbindung hin aufbauen. Ist ja nicht so, dass sich das nicht absichern lässt, ich empfehle mal unabhängig von den entsprechenden Seiten von MS zum Thema "Bastion" als Einstieg ein bisschen Lesestoff:
https://github.com/HotCakeX/Harden-Windows-Security/wiki/How-to-Securely-Connect-to-Azure-VMs-and-Use-RDP
@Froschkönig: Danke für den Hinweis.
Wie mir mein SOC-Team sagt, gibt es wohl auch die Möglichkeit per "Just-in-Time" Zugriff per RDP zu erhalten:
https://learn.microsoft.com/en-us/azure/defender-for-cloud/just-in-time-access-overview?tabs=defender-for-container-arch-aks
Und klar: Die VM wurde von uns aufgesetzt, ist also (hoffentlich) nicht komprimitiert.