Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Gefährliche Malware "Cthulhu Stealer" in Umlauf

Laut Cado Security ist eine neue Malware in Umlauf, die es auf Apples Betriebssystem abgesehen hat. „Cthulhu Stealer“ soll bereits seit Ende 2023 aktiv sein. Besonders alarmierend ist, dass die Malware auf einschlägigen Cybercrime-Marktplätzen für lediglich 500 Dollar pro Monat angeboten wird. Der niedrige Preis macht eine Investition in die Software und das Ausspionieren von Macs für Kriminelle besonders lukrativ.


Verbreitung über gefälschte Software
Die Verbreitung von „Cthulhu Stealer“ erfolgt über manipulierte Apple-Disk-Images, die sich als beliebte Software tarnen, darunter „Grand Theft Auto IV“ oder „CleanMyMac“. Auch eine gefälschte Version des weitverbreiteten Tools „Adobe GenP“, das normalerweise verwendet wird, um Adobe-Programme ohne gültigen Lizenzschlüssel zu betreiben, gehört zu den Methoden, mit denen die Malware potenzielle Opfer anlockt. Das Programm ist in der Lage, sowohl Intel- als auch Apple-Silicon-basierte Macs anzugreifen, was seine potenzielle Reichweite erheblich erhöht.

Ziel: Zugangsdaten und Kryptowährungen
Sobald die Malware auf dem System installiert ist, beginnt sie mit dem Sammeln sensibler Daten. Zu den bevorzugten Zielen gehören Systeminformationen, iCloud-Schlüsselbund-Passwörter, Browser-Cookies und sogar Zugangsdaten zu Telegram-Konten. Besonders bedenklich ist, dass die Schadsoftware auch Passwörter für Crypto-Wallets wie MetaMask abfragt. Die gesammelten Daten gehen anschließend an einen zentralen Steuerungsserver, wo sie für kriminelle Zwecke missbraucht werden können.

Verwandtschaft zu Atomic Stealer
Eine genaue Analyse des "Cthulhu Stealer" hat gezeigt, dass es sich bei der Malware wahrscheinlich um eine Weiterentwicklung des „Atomic Stealer“ handelt, einer früheren Malware-Variante, welche ähnliche Funktionen aufweist. Die Übereinstimmungen in der Programmierung, wie etwa identische Rechtschreibfehler in den Scripts, deuten stark darauf hin, dass die Entwickler den Code von Atomic Stealer als Grundlage verwendet haben. Berichten zufolge wurde der Hauptentwickler auf einem bekannten Cybercrime-Marktplatz gesperrt, nachdem es dort zu Zahlungsstreitigkeiten und Betrugsvorwürfen gekommen war. Der Umstand könnte die Verbreitung und Wirksamkeit der Malware zumindest kurzfristig einschränken.

Kommentare

donw
donw27.08.24 09:03
wir das von Gatekeeper erkannt?
+1
FlyingSloth
FlyingSloth27.08.24 09:35
Ein Zeichen wie sehr Crypto mittlerweile für viele Menschen eine wichtiges Asset darstellt. Denn wenn es da nichts zu ergaunern gaebe, würden Kriminelle nicht den Aufwand betreiben, Crypto Wallets zu hacken. Deshalb sollte jeder, der Crypto hat, Cold Storage Wallets verwenden.
Fly it like you stole it...
+2
Deichkind27.08.24 09:46
donw
wir das von Gatekeeper erkannt?
Die Programme sind sicherlich nicht notarisiert. Also muss man Hürden überwinden, um sie trotzdem zu installieren. Danach helfen allenfalls noch Werkzeuge zum Entfernen von Malware (Malware Removal Tools). Auch macOS bringt solche mit.
+2
don.redhorse27.08.24 09:57
Die wichtigere Frage ist doch, kann man sich das Ding auch anderweitig einfangen? Wenn es nur über gecrackte Software aus dubiosen Quellen geht, sollte es die meisten Nutzer nicht stören. Es ist aber noch nicht z.B. über Homebrew, oder sonstiger freier Software verbreitet worden? Das blöde ist ja, wie kann man immer sicher sein, dass die Webseite die man vom Entwickler XY aufruft die echte ist? „Lemkesoft.de“ ist ja eine Seite die viele kennen und wo man ab und an mal eine neue Version etc. runterläd. Aber wie kann man sicher sein, dass die Seite nicht umgebogen wurde, z.b. weiterer Klassiker. Statt Lemkesoft.de Lemkesoft.com, weiß jetzt nicht ob es die gibt. Wer aber Seiten via Google öffnet bekommt es ja nicht zwingend mit.
Bleibt also nur der Notarisierungsdialog übrig? Ich wollte mal ein freies Programm öffnen, da gab es halt die Meldung das es von einem unbekannten Entwickler kommt und eben nicht notarisiert ist. Beim Blick auf der Webseite hat er dann geschrieben das er es nicht machen wolle, da Apples Absicherung etc. zuviel Aufwand ist und er dazu keine Lust hat. Denke die Gebühren spielen da auch noch eine Rolle. Hab’s dann sein gelassen und etwas anderes gesucht.
Also wie kann man sich infizieren, wenn man genau auf diese Punkte achtet?
+5
Mendel Kucharzeck
Mendel Kucharzeck27.08.24 11:24
don.redhorse
Das Dumme: Du kannst dir nicht sicher sein. Installierst du etwas über Homebrew, kann es sein, dass du dutzende oder gar hunderte Bestandteile runterlädst – und ob irgendwo irgendwer was eingeschleust hat, kannst du unmöglich feststellen.

Auch eine Notarisierung bietet nur begrenzten Schutz: Sagen wir, ein Entwickler der Software A bindet Programmierbibliothek B ein – welche wiederum C, D, E usw. benötigt. Dort hat sich eine neuartige Malware eingeschlichen, welche Apple nicht kennt. Die App wird von Apple notarisiert und der Entwickler liefert sie – in Unkenntnis der Malware in Bibliothek E – aus. Apple hat durch die Notarisierung die Möglichkeit, das Starten der App-Version zu verhindern – aber halt nur, wenn die Malware bekanntgeworden ist.
+8
don.redhorse27.08.24 12:10
Das ist der Fluch der Libs. Damit ist es aber nicht ganz so gut nur zu sagen das eine Malware nur über gecrackte Software aus dubiosen Quellen verbreitet wird.

An sich kann man also nur hoffen das (in diesem Falle Apple) die Malware schnell erkennt und die Verbreitung entsprechend eindämmt. Es bleibt ein Katz und Maus Spiel.
0
Mendel Kucharzeck
Mendel Kucharzeck27.08.24 12:28
don.redhorse
Einen gewissen Schutz hast du, wenn du nur auf Apps auf dem Mac setzt, die gesandboxed sind. Hier hat eine kompromittierte App mit sehr hoher Wahrscheinlichkeit nur Zugriff auf Dateien, die direkt mit der App assoziiert sind.

So verhasst das Sandboxing auf dem Mac von Entwicklern auch ist – meiner Meinung nach ist es die einzige praktikable Möglichkeit, die Sicherheit maßgeblich zu steigern. Viele Hersteller weigern sich aber vehement, das umzusetzen – einerseits wegen Aufwand, andererseits weil manche Features nicht nur oder nur schwer umzusetzen sind.
+2
Pineapps
Pineapps27.08.24 13:23
Mendel Kucharzeck
don.redhorse
…Sagen wir, ein Entwickler der Software A bindet Programmierbibliothek B ein – welche wiederum C, D, E usw. benötigt. Dort hat sich eine neuartige Malware eingeschlichen, welche Apple nicht kennt. Die App wird von Apple notarisiert und der Entwickler liefert sie – in Unkenntnis der Malware in Bibliothek E – aus. …

Ich kenne mich kaum mit der Entwicklung von nativen Mac Apps aus. Aber üblicherweise sind doch die meisten Libraries die häufig eingesetzt werden entweder Open Source oder in den Händen professioneller Anbieter.

Bei Open Source und einer entsprechenden Beliebtheit ist doch anzunehmen, dass eine solche Kompromittierung relativ bald auffallen würde, da diese ja in der Regel mit einer Vielzahl geänderter Code Zeilen kommt und damit nicht so einfach unter das Radar fällt.

Damit die Kompromittierte Library es dann in die Software schafft muss ja in der Regel erst die Version der Library in der App angepasst und ein Update für die eigentliche App ausgespielt werden. Bis das durch ist vergehen ja meist paar Tage und damit die Chance, dass dies einem findigen Nutzer der Library auffällt.
Click. Boom. Amazing! - Steve Jobs
0
Mendel Kucharzeck
Mendel Kucharzeck27.08.24 14:17
Pineapps
So genannte Supply-Chain-Attacken werden leider immer häufiger – und das Problem ist die schiere Menge an Bibliotheken, die meist mit der Einbindung von Open-Source-Bibliotheken einhergeht. Beispiel: Du willst das bekannte Projekt "OpenCV" nutzen – und das hat UNGLAUBLICH viele Abhängigkeiten, welche wieder Abhängigkeiten usw. haben.

Wenn nun IRGENDWO jemand fahrlässig mit seinem GitHub-Konto umgegangen ist und es sich nicht um eine viel genutzte/beachtete Library handelt, welche von OpenCV verwendet wird, kann so etwas wirklich sehr schnell passieren, dass ein findiger Angreifer Code unterjubelt, der Mist anstellt.

Die meisten Entwickler wissen noch nicht mal, was sie da eigentlich alles einbinden. Das war schön zu beobachten, als in der Java-Logging-Bibliothek Log4j eine GIGANTISCHE Sicherheitslücke aufgeflogen ist. Viele Hersteller von Software- und Hardware-Produkten mussten überhaupt erstmal feststellen, ob das (z.B. auf Routern, Firewalls etc) eingebunden ist.

Ich versuche bei unseren Projekten hier bei Synium immer WIE DER TEUFEL jede Abhängigkeit zu irgendwas zu vermeiden, was ich auch selbst erreichen kann – es wird mir früher oder später auf die Füße fallen. First-Party-Libraries von Apple verwenden wir natürlich, aber sonst sind die meisten Projekte "clean" von Dritthersteller-Abhängigkeiten.
+5

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.