Analyse des CastleBot Malware-as-a-Service-Betriebs

IBM X-Force untersucht ein neu aufgetauchtes Malware-Framework namens CastleBot. Es wird angenommen, dass die Malware Teil eines Malware-as-a-Service (MaaS)-Betriebs ist und speziell für eine flexible Malware-Bereitstellung konzipiert wurde. CastleBot wird derzeit von Cyberkriminellen genutzt, um alles Mögliche zu verbreiten, von Infostealern bis hin zu Hintertüren wie NetSupport und WarmCookie, die mit Ransomware-Angriffen in Verbindung gebracht werden.

Besonders besorgniserregend an CastleBot ist die Art seiner Verbreitung: meist über mit Trojanern infizierte Software-Installationsprogramme, die von gefälschten Webseiten heruntergeladen werden und ahnungslose Benutzer dazu verleiten, die Infektion selbst auszulösen. Diese Technik ist Teil eines wachsenden Trends, den X-Force beobachtet. Dies wird häufig durch SEO-Poisoning ermöglicht, was dazu führt, dass bösartige Seiten in Suchmaschinen einen höheren Rang einnehmen als legitime Softwarevertreiber. Sobald CastleBot im System ist, durchläuft er einen dreistufigen Prozess: einen Stager/Downloader, einen Loader und eine zentrale Backdoor, die eine Reihe von Aufgaben von ihrem Command-and-Control-Server (C2) anfordert. Die von der infizierten Maschine gesammelten Informationen ermöglichen es den Betreibern, Opfer leicht zu filtern, laufende Infektionen zu verwalten und Malware präzise auf hochwertige Ziele bereitzustellen.

CastleBot entwickelt sich immer noch weiter, und unsere Forschung zeigt, dass es wahrscheinlich gerade erst anfängt. In diesem Bericht erläutern wir, wie es funktioniert, wie es sich verbreitet und warum es wichtig ist.

• CastleBot ist eine neue Malware, die wahrscheinlich als Malware-as-a-Service betrieben wird und zur Bereitstellung einer Vielzahl bösartiger Nutzlasten eingesetzt werden kann.
• Die folgenden Payloads reichen von Infostealern bis hin zu Backdoors im Zusammenhang mit Ransomware-Angriffen wie NetSupport und WarmCookie
• X-Force stellte fest, dass mit Trojanern infizierte Software-Installationsprogramme der häufigste Infektionsvektor für die Verbreitung von CastleBot sind.
• Das CastleBot-Framework umfasst drei Komponenten: einen Stager, einen Loader und einen Kern und befindet sich offenbar in aktiver Entwicklung.
• Die Malware scheint es den Betreibern zu ermöglichen, Opfer einfach zu filtern, Nutzdaten zu aktualisieren und mehrere Kampagnen während ihres gesamten Lebenszyklus zu verwalten.

CastleBot erschien erstmals Anfang 2025. X-Force stellte ab Mai eine Zunahme des Volumens von Stichproben und verschiedenen Nutzlasten fest und hat seitdem die Bereitstellung verschiedener Backdoor- und Infostealer-Nutzlasten beobachtet. Der häufigste Infektionsvektor von CastleBot ist trojanisierte Software, was Teil eines Trends ist, den X-Force seit 2024 fortsetzt. Trojanische Softwarepakete und Installationsprogramme werden oft über gefälschte Websites verbreitet, die SEO-Vergiftung nutzen, um Opfer anzulocken. CastleBot wurde außerdem über GitHub-Repositories verteilt, indem es legitime Software imitierte, sowie über die beliebte ClickFix-Technik.

X-Force identifizierte drei Komponenten als Teil des CastleBot-Malware-Frameworks: einen Stager, einen Loader und den CastleBot-Kern/die Backdoor.

Beachten Sie, dass frühere öffentliche Berichte von Prodraft sich auf dasselbe Malware-Framework als „CastleLoader“ beziehen.

In den meisten Fällen wird die CastleBot-Kernkomponente über einen Shellcode-Stager bereitgestellt, der zur selben CastleBot-Malware-Familie gehört. Der Stager ist eine leichte Shellcode-Nutzlast, die von jedem anderen First-Stage-Loader injiziert werden kann. X-Force beobachtete verschiedene Crypter, die mit CastleBot verwendet wurden, darunter Dave, ein AutoIt-basierter Crypter, sowie einfache Crypter, die in C kompiliert wurden.

Die Malware verwendet den DJB2-Hashing-Algorithmus, um notwendige APIs zur Laufzeit aufzulösen. Bevor jedem API-Aufruf lädt es die entsprechende DLL und durchsucht die Export-Adresse-Tabelle (EAT) nach der API-Funktion via vorab generierten DJB2-Hashes. Sollte der Export an eine andere DLL weitergeleitet werden, analysiert der Stager den DLL-Namen, lädt ihn und löst die Funktion über GetProcAddress auf.

Nach der Ausführung lädt der Stager zwei Nutzdaten via HTTP mit dem User-Agent „Googlebot“ herunter. Die URL-Pfade zwischen den Beispielen sind ähnlich und adressieren denselben C2-Server wie die CastleBot-Kern-Komponente.

Beispiel für Download-URLs:

Beide Payloads werden über eine hartcodierte XOR-Zeichenfolge entschlüsselt, in diesem Fall „GySDoSGySDoS“ (UTF-16-codiert), und zeigt einen PE (CastileBot-Core) und einen Shellcode-Stub (CastileBot Loader).

Der Stager verwendet dann VirtualProtect , um die Ausführung auf dem Heap für den Speicherbereich zu aktivieren, in dem die zweite entschlüsselte Shellcode-Nutzlast gespeichert wird. Letzteres, das als Loader fungiert, wird direkt im Speicher ausgeführt und erhält als Argument einen Zeiger auf die entschlüsselte PE.

Der CastleBot Loader ist ein voll funktionsfähiger PE-Loader, der zunächst jeden Abschnitt des bereitgestellten PE in eine neue Speicherregion abbildet, die mit NtAllacateVirtualMemory zugewiesen wurde. Anschließend werden notwendige Relokationen behoben, Importe gelöst, die entsprechenden Speicherschutzoptionen festgelegt und bestehende TLS-Rückruffunktionen ausgeführt.

Insbesondere richtet der Lader auch eine neue LDR_DATA_TABLE_ENTRY-Struktur und den entsprechenden LDR_DDAG_NODE (erweitert in Windows 8 und später) ein, die dann in die PEB_LDR_DATA doppelt verknüpften Listen mit den geladenen Modulen für jeden Prozess eingefügt werden. Für EDR-Agenten, die den PEB überwachen, würde dies den Eindruck erwecken, als sei die eingeschleuste Nutzlast rechtmäßig vom Betriebssystem geladen worden.

Sofern die eingespritzte Datei keine DLL ist, wird das ImageBaseAddress-Feld des PEB ebenfalls auf die Basisadresse der eingespritzten Nutzlast gesetzt.

Um die Payload auszuführen, führt CastleBot Loader den Einstiegspunkt aus oder weist eine neue Konsole für Anwendungen zu.

In dem oben analysierten Beispiel ist die injizierte Nutzlast die x86 CastleBot-Backdoor (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04).

Der CastleBot-Kern verwendet denselben API-Auflösungsmechanismus wie die Hashing-Algorithmus und Loader-Komponenten, mit Ausnahme des Hashing-Algorithmus, der der AP-Hash ist, der von Arash Partow entwickelt wurde.

Zuerst beginnt die Backdoor mit der Entschlüsselung ihrer Konfiguration. Fast alle Strings im gesamten Binärcode, einschließlich derjenigen, die Teil der Konfiguration sind, werden als UTF-16 gespeichert und inline über einen eindeutigen 4-Byte-XOR-Schlüssel für jede Zeichenkette entschlüsselt. Während der Entschlüsselung wird folgende Konfigurationsstruktur erstellt:

Die Malware versucht, eine Mutex mit dem Namen aus der Konfiguration zu erstellen, um sicherzustellen, dass nur eine einzige Instanz ausgeführt wird. Im nächsten Schritt sendet es eine HTTP-GET-Anfrage an die festkodierte URL, um die Einstellungen abzurufen, wobei die Kampagnen-ID im URL-Pfad verwendet wird:

Als Reaktion darauf erhält CastleBot einen Block verschlüsselter Daten.

Alle C2-Kommunikation wird über den symmetrischen ChaCha-Algorithmus verschlüsselt, abgesehen von der anfänglichen GET-Anfrage der Malware. Nach der Entschlüsselung verwendet das C2-Protokoll eine serialisierte benutzerdefinierte Datenstruktur, die intern als Container bezeichnet wird und Werte verschiedener Typen speichern kann.

Am Anfang der serialisierten Datenstruktur steht immer ein Feld vom Typ ContainerFieldArray. Die untenstehenden Strukturen definieren weiter, wie Array- und Bool-Typen aufgebaut werden:

Beim Parsen des entschlüsselten Containers, der die von der Hintertür angeforderten Einstellungen definiert, beginnen die Daten mit dem Byte 0x0D, das den Typ ContainerFieldArray angibt.Auf dieses Byte folgt der Feldname, der wiederum aus der 2-Byte-Länge und dem UTF-16-kodierten Namen besteht. Nach dem Namen definiert ein Array-Feld eine 4-Byte-Länge der Daten, gefolgt von den Daten selbst, die wiederum mit dem ersten Byte beginnen, das den Typ definiert.

Die von der oben analysierten Stichprobe empfangenen Einstellungen werden wie folgt ausgewertet.

Serialisierte Daten:

Deserialisiertes Objekt:

Für jede aktivierte Einstellung werden von CastleBot die folgenden Aktionen ausgeführt:

run_as_admin: Malware führt seinen übergeordneten Prozess über "cmd.exe /c <parent_process>" mittels ShellExecuteW mit dem Verb "runas" aus, um ihn als Administrator zu starten.

anti_vm: CastleBot verwendet die Anweisung cpuid mit dem Blatt 0x40000000, um zu versuchen, Hypervisor-Umgebungen zu erkennen. Wenn entweder VMware oder Parallels entdeckt werden, wird die Malware beendet.

prevent_restart: CastleBot erstellt eine neue versteckte Datei in %PROGRAMDATA% mit dem Namen, der mit dem in der Konfiguration eingebetteten Mutex-Namen übereinstimmt. Wenn die Datei bereits existiert, wird die Malware beendet.

Show_fake_Error: Die Malware zeigt ein Meldungsfenster „Systemfehler“ mit der Meldung „Das Programm kann nicht gestartet werden, da die VCRUNTIME140.LL auf Ihrem Computer fehlt. Versuchen Sie, das Programm neu zu installieren, um dieses Problem zu beheben.

In den nächsten Schritten sammelt CastleBot Informationen über den infizierten Host, um ihn beim C2-Server zu registrieren und Aufgaben anzufordern.

• Benutzername über GetUserNameW
• NetBIOS-Name über GetComputerNameW
• Systemarchitektur über IsWow64Process
• Lokaler DNS-Domainname, indem Sie LsaQueryInformationPolicy verwenden, um die Struktur PolicyDnsDomainInformation abzurufen. Der Standardwert ist „WORKGROUP“.
• Volume-Seriennummer über GetVolumeInformationW abgerufen.CastleBot verwendet es, um eine eindeutige Opfer-ID mithilfe eines linearen Kongruenzgenerators (LCG) mit einem Multiplikator von 0x41C64E6D und einem Addend von 0x3039 zu berechnen.
• Windows-Version über RtlGetVersion und GetSystemMetrics(89)

Die Informationen werden in das untenstehende Objekt kompiliert, gefolgt von Serialisierung und ChaCha-Verschlüsselung:

Die fest codierten Werte sind der Zugriffsschlüssel (identisch mit dem User-Agent aus der Konfiguration), die Kampagnen-ID und die CastleBot-Build-Version, die „1.0“ lautet, für die analysierte Probe.

Die Backdoor sendet die verschlüsselten Daten in einer HTTP-POST-Anfrage an

 Die Antwort ist ein größerer verschlüsselter Container mit den vorkonfigurierten Aufgaben des CastleBot.

Der Container, den das analysierte CastleBot-Sample vom C2-Server erhält, wird entschlüsselt und in ein Objekt mit den folgenden Feldern deserialisiert:

Das Feld „tasks“ ist ein benutzerdefinierter Array-Typ, wie oben beschrieben, der mindestens ein unbenanntes Array (Name der Länge Null) enthält, von denen jedes eine Aufgabe darstellt. CastleBot kann auch ein Array mit mehreren Aufgaben erhalten, die nacheinander ausgeführt werden sollen. Jede Aufgabe enthält eine ID und mehrere Felder, die angeben, wie die Aufgabe ausgeführt werden soll. Diese Felder werden bei der Deserialisierung in eine Aufgabenstruktur kopiert.

Das wichtigste Feld in jeder Aufgabe ist die „launch_method“, die Art der Nutzlast bestimmt, die von CastellBot verarbeitet werden soll.

Die anderen Felder können verwendet werden, um spezifische Optionen für die Ausführung der Aufgabe festzulegen:

CastleBot unterstützt Simple Process Injection für PE-Nutzlasten. Es beginnt mit der Erstellung eines neuen unterbrochenen Prozesses, basierend auf dem Installationspfad und den Argumentfeldern. Um unter Windows 11 24H2 und späteren Versionen funktionieren zu können, entschieden sich die Malware-Entwickler dafür, die NtManageHotPatch -Funktion der NTDLL im Speicher einzubinden, um die neu hinzugefügte Speicherprüfung zu umgehen. Weitere Einzelheiten finden Sie im Beitrag von Hasherezade, welche auch die genaue POC-Implementierung bereitstellt, die von CastleBot verwendet wird:

Der Rest der Prozessinjektion folgt gängigen Injektionstechniken, indem Speicher im Zielprozess zugewiesen, die Abschnitte in den Puffer geschrieben und der Thread-Kontext angepasst wird, bevor die Ausführung fortgesetzt wird.

Wenn das Feld „Startmethode“ auf „1“ gesetzt ist, stellt CastleBot die Persistenz durch die Erstellung einer geplanten Aufgabe her. Um die Aufgabe zu registrieren, verwendet die Malware die COM-Schnittstelle ITaskService, um sich mit dem Task Scheduler-Service zu verbinden. Sie erstellt eine neue Aufgabe und eine Ausführungsaktion für die Ziel-Nutzlast, die jedes Mal ausgelöst wird, wenn sich der aktuelle Benutzer anmeldet (TASK_TRIGGER_LOGON).

Jede Aufgabe im Container „tasks“ wird iterativ anhand ihrer angegebenen Felder bearbeitet. Sobald eine Aufgabe fehlerfrei abgeschlossen wurde, meldet die Malware die erfolgreiche Ausführung über eine HTTP-GET-Anfrage an:

X-Force entdeckte eine aktualisierte CastleBot-Kernvariante, die neue Startmethoden und eine Option namens "wow64_bypass" unterstützt, mit der speziell 32-Bit-Systembinärdateien im Ordner SysWOW64 gestartet werden können.

Die zusätzliche Prozessinjektionsimplementierung (Startmethode 6) schreibt sowohl die CastleBot Loader-Komponente (siehe Analyseabschnitt oben) als auch die PE-Nutzlast in den Zielprozess. Anschließend werden QueueUserAPC und ResumeThread verwendet, um die Ausführung an den Loader zu übertragen, der die PE-Nutzlast ordnungsgemäß in den Speicher lädt und ausführt.

Diese Technik verwendet deutlich weniger WriteProcessMemory-API-Aufrufe und bietet eine umfassendere Ladefunktion vom CastleBot Loader-Stub.

Das Hauptziel von CastleBot ist es, die Bereitstellung sekundärer Nutzlasten auf Opfermaschinen zu ermöglichen. X-Force hat mehrere verschiedene Payloads aufgedeckt, die von CastleBot verteilt wurden, oft mit mehreren Payloads in einer einzigen Kampagne. Die Payloads sind unterschiedlich komplex, von Standard-Infostealern bis hin zu leistungsfähigeren Backdoors wie NetSupport oder WarmCookie, die mit Ransomware-Angriffen in Verbindung gebracht wurden.

Das CastleBot-MaaS-Framework scheint es Betreibern zu ermöglichen, infizierte Rechner zu filtern und Payloads einfach zu aktualisieren, um mehrere aktive Kampagnen mit großer Flexibilität zu verwalten, wie aus der Analyse und den Screenshots von Prodaft des C2-Panels hervorgeht. Aufgrund der Fluktuation der Payloads und der Möglichkeit des Betreibers, mehrere Aufgaben und Payloads zu einer einzigen Kampagne hinzuzufügen, sind die Infektionsketten von LockBot im Vergleich zu traditionell statischen Malware-Phasen komplexer.

X-Force hat keine Hinweise auf eine weit verbreitete Werbung für MaaS im Dark Web, was darauf hindeuten könnte, dass der Service derzeit nur an eine private Gruppe von verbundenen Unternehmen verkauft wird.

Ohne die Malware als eigenes Framework zu identifizieren, wurden verschiedene Fragmente der Kampagnen, die zu NetSupport führten, im Juni und Juli 2025 von anderen Forschern öffentlich gemeldet.

DomainTools beobachtete gefälschte DocuSign-Seiten, die die ClickFix-Technik verwenden, um ein bösartiges PowerShell-Skript auszuführen, das wiederum CastleBot herunterlädt, um NetSupport bereitzustellen. Kampagnen-IOCs:

PaloAlto's Unit42 meldete ähnliche Aktivitäten mit Websites, die DocuSign und Okta imitierten und ClickFix verwendeten, um CastleBot über die ersten Stager- und Loader-Komponenten zu implementieren. Es enthält eine Teilanalyse von einem „NetSupport RAT Loader“, den X-Force als das CastleBot-Framework identifiziert. Kampagnen-IOCs:

Eine der interessanteren Payloads von CastleBot ist die WarmCookie-Backdoor (auch bekannt als Quickbind, BadSpace). Es ist wahrscheinlich Teil eines größeren Ökosystems der Cyberkriminalität, das Ransomware-Angriffe ermöglicht, und gehörte zu den Malware-Familien, die während der Operation Endgame im Jahr 2024 erfolgreich von internationalen Strafverfolgungsbehörden ins Visier genommen wurden. Zuvor verteilte der Bedrohungsakteur Hive0137 WarmCookie über bösartige E-Mail-Kampagnen, obwohl laut der Sichtbarkeit von X-Force im Jahr 2025 keine nennenswerte Aktivität festgestellt wurde. WarmCookie ist öffentlich mit TA866/Asylum Ambuscade in Verbindung gebracht.

Die von X-Force beobachtete Kampagne begann im Juni mit einem ZIP-Archiv, das als Installationsprogramm für eine legitime Software getarnt war: SSMS-20.2-enu.zip (4766f5cc6501fc40c7151a0ce1c9d2cc49fca9b0b9cab2a206dd2426947e9afe). Unter den legitimen Komponenten befindet sich eine bösartige ausführbare Datei SSMS_Windows.x64.exe (05ecf871c7382b0c74e5bac267bb5d12446f52368bb1bfe5d2a4200d0f43c1d8), die als Variante des Dave Loaders identifiziert wurde und eine in seinen Ressourcen gespeicherte Nutzlast entschlüsselt. Nach der Entschlüsselung injiziert Dave Loader die CastleBot-Backdoor (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04), die den Auftrag erhält, eine WarmCookie-Payload (5bca7f1942e07e8c12ecd9c802ecdb96570dfaaa1f44a6753ebb9ffda0604cb4) herunterzuladen und auszuführen.

Der WarmCookie C2-Server befindet sich hier:

Eine zweite Sample, die später im Juni gefunden wurde, verwendete eine ähnliche ausführbare Datei, die einen Installer für Zscaler-Software Zscaler-windows-4.4.0.379-installer-x64.exe imitierte (bf21161c808ae74bf08e8d7f83334ba926ffa0bab96ccac42dde418270387890). Die mit AutoIt kompilierte Binärdatei ist ein einfacher Shellcode-Loader, der den eingebetteten CastleBot-Stager ausführt, welcher wiederum die gleiche CastleBot-Backdoor-Binärdatei (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04) herunterlädt.

Sandbox-Ausführungen des übergeordneten CastleBot-Samples deuten darauf hin, dass derselbe Partner während der Kampagne möglicherweise eine StealC-Payload mit einem C2-Server unter „http://107.158.128[.]105/c91252f9ab114f26.php“ abgelegt hat; X-Force konnte jedoch kein Sample abrufen. 

Beide Kampagnen verwenden die CastleBot-Kampagnen-ID „81a16c72f9c9c4ea94d68b609c78f72d4a8725e7b8f6949b12d8871b6c6843e3“.

Darüber hinaus verfolgt X-Force mehrere CastleBot-Kampagnen, die verschiedene Infostealer bereitstellen. Die Malware unterstützt mehrere Download-Aufgaben für jede Kampagne, was zur Bereitstellung mehrerer Payloads auf demselben Client führt. Die ausführbare Datei AMD_Chipset_DriverOnly_DCH_AMD_Z_V1.2.0.105_20238.exe (e6aab1b6a150ee3cbc721ac2575c57309f307f69cd1b478d494c25cde0baaf85) lädt die eingebettete CastleBot-Kernnutzlast (b45cce4ede6ffb7b6f28f75a0cbb60e65592840d98dcb63155b9fa0324a88be2 ) aus ihren Ressourcen und führt sie aus. Der Endpunkt für die Einstellungen des C2-Servers befindet sich unter

und es wurde festgestellt, dass insgesamt drei separate Aufgaben in einer einzigen C2-Nachricht übertragen wurden, wobei jede Aufgabe eine unterschiedliche Nutzlast enthielt:

• Aufgaben-ID: 0x16
• • URL herunterladen: https[:]//google.herionhelpline[.]com/app/AcerUSBUpdate.exe
  • Nutzlast: 03122e46a3e48141553e7567c659642b1938b2d3641432f916375c163df819c1 (Rhadamanthys)
  • Installationspfad: Keine
  • Startmethode: 6

• Aufgaben-ID: 0x17 
• • URL herunterladen: https[:]//google.herionhelpline[.]com/app/light1_v5_signed.html
  • Nutzlast: 12de997634859d1f93273e552dec855bfae440dcf11159ada19ca0ae13d53dff (Remcos)
  • Installationspfad: %ProgramData%\AmazonApp\AmazonWebServiceUpdate.exe
  • Startmethode: 1

• Aufgaben-ID: 0x18
• • https[:]//google.herionhelpline[.]com/app/SlackUpdateWeb.html
  • Payload: c8f95f436c1f618a8ef5c490555c6a1380d018f44e1644837f19cb71f6584a8a (DeerStealer)
  • Installationspfad: %AppData%\SlackUpdate\SlackServiceUpdate.exe
  • Startmethode: 1

X-Force entdeckte darüber hinaus Kampagnen, bei denen SecTopRAT (auch bekannt als ArechClient), HijackLoader (auch bekannt als Shadowladder) und MonsterV2 (auch bekannt als Aurotun Stealer) eingesetzt wurden.

SecTopRAT und HijackLoader:

• GlobalProtect-win-6.3.zip mit ausführbarer Datei zum Sideloading von msvcp140.dll (8bf93cef46fda2bdb9d2a426fbcd35ffedea9ed9bd97bf78cc51282bd1fb2095)
• CastleBot C2-Server: http[:]//107.158.128[.]45/service/settings/81a16c72f9c9f4ea94d68b609c78f72d4a8725e7b8f6949b12d8871b6c6843e3
• Payload gehostet unter http[:]//107.158.128[.]45/service/download/Exchanger32.zip (4834bc71fc5d3729ad5280e44a13e9627e3a82fd4db1bb992fa8ae52602825c6)

MonsterV2:

• libssl-1_1.dll (53dddae886017fbfbb43ef236996b9a4d9fb670833dfa0c3eac982815dc8d2a5) DLL-sideloaded, reflektiert CastleBot Stager
• CastleBot C2-Server: http[:]//107.158.128[.]45/service/settings/8306a6b35d4be6de72be58860791e3644468fd675e4045a246dd27fa5692c
• Payload gehostet unter http[:]//107.158.128[.]45/service/download/CCver_Setup.exe (ab725f5ab19eec691b66c37c715abd0e9ab44556708094a911b84987d700aa62)

CastleBot ist der jüngste Beweis für eine Verschiebung der ursprünglichen Infektionsvektoren in der Geschäftswelt der Cyberkriminalität. Backdoors und MaaS-Frameworks werden zunehmend über gefälschte Webseiten als Teil von trojanischer Software oder über die ClickFix-Technik verbreitet. Innerhalb weniger Monate nach dem Anstieg der CastleBot-Aktivitäten haben die Entwickler bereits mehrere neue Funktionen hinzugefügt und werden voraussichtlich versuchen, mit der Anpassung von EDR- und Netzwerksicherheitslösungen Schritt zu halten. Aktuelle Aktivitäten lassen vermuten, dass mehrere verbundene Unternehmen CastleBot nutzen, um sowohl Infostealer als auch Hintertüren bereitzustellen, was zu schwerwiegenden Ransomware-Vorfällen führen kann.

Den Verteidigern wird geraten, die in diesem Bericht genannten Techniken weiterhin aufmerksam zu verfolgen und geeignete Maßnahmen zu ergreifen, um das Risiko einer CastleBot-Infektion zu minimieren.

• Stellen Sie sicher, dass die EDR-Software und die zugehörigen Sicherheitskontrollen auf dem neuesten Stand sind.
• Trainieren Sie die Benutzer, bei der Installation von Software äußerste Vorsicht walten zu lassen und die Installation nicht genehmigter oder nicht verifizierter Software zu unterlassen.
• Implementieren Sie eine Multi-Faktor-Authentifizierung und überwachen Sie die Weitergabe von Zugangsdaten.
• Richten Sie Warnmeldungen ein oder erwägen Sie die Blockierung ausgehender HTTP-Verbindungen (nicht HTTPS) und insbesondere von URLs mit IP-Adressen.

IBM X-Force Premier Threat-Intelligence ist nun mit OpenCTI by Filigran integriert und liefert umsetzbar Threat-Intelligence zu dieser Bedrohungsaktivität und mehr. Erhalten Sie Erkenntnisse zu Bedrohungsakteuren, Malware und Branchenrisiken. Installieren Sie den X-Force OpenCTI-Connector, um die Erkennung und Reaktion zu verbessern und Ihre Cybersicherheit mit der Expertise von IBM X-Force zu stärken. Erhalten Sie noch heute eine 30-tägige Testversion von X-Force Premier Threat Intelligence.