Inhalte
- Einführung
- Kampagnenübersicht
- Erster Zugriff
- Infektionskette
- Technische Analyse
- Phase 1: Erste Auslieferung (Archiv→JavaScript)
- Phase 2: Analyse des PowerShell Loaders 1
- Phase 3: Analyse des PowerShell Loaders 2
- Phase 4 – Phantom Stealer v3.5.0: Datenerfassung und -exfiltration
- Kampagnenzuordnung
- Fazit
- IOCs
- Seqrite Erfassungsbereich-
- MITRE-Angriffstaktiken, -techniken und -verfahren (TTPs)
Einführung
Phishing-Kampagnen entwickeln sich ständig weiter, indem sie sich als routinemäßige Geschäftskorrespondenz tarnen, der die Empfänger vertrauen. Im Zuge unserer Untersuchung deckten wir eine Kampagne auf, die mehrere Phishing-Köder einsetzt, um schädliche JavaScript-Dateien in komprimierten Archivanhängen zu verbreiten. Obwohl die E-Mails den Anschein erwecken, von verschiedenen vertrauenswürdigen Stellen wie einem globalen Logistikdienstleister und einer Finanzbehörde zu stammen, führen sie letztendlich zu einer identischen, mehrstufigen Infektionskette.
Nach der Ausführung startet der JavaScript-Downloader ein verschleiertes PowerShell-Skript, das den gesamten schädlichen Ablauf im Arbeitsspeicher ausführt. Dadurch wird der Speicherplatzbedarf deutlich reduziert und die Erkennung erschwert. Die Infektionskette installiert schließlich Phantom Stealer v3.5.0, der sensible Informationen vom kompromittierten System sammelt und die gesammelten Daten verschlüsselt per SMTP exfiltriert.
Diese Kampagne verdeutlicht, wie Bedrohungsakteure zunehmend überzeugende Social-Engineering-Methoden mit Geschäftsbezug mit mehrschichtiger Verschleierung und dateilosen Ausführungstechniken kombinieren, um herkömmliche Sicherheitsvorkehrungen zu umgehen und Unternehmensumgebungen zu kompromittieren.
Kampagnenübersicht
Die Kampagne setzt auf professionell gestaltete Phishing-E-Mails, die wie reguläre Geschäftskorrespondenz aussehen, um Empfänger zur Ausführung einer schädlichen JavaScript-Datei zu verleiten, die in komprimierten Archivanhängen versteckt ist. Im Rahmen unserer Analyse identifizierten wir zwei verschiedene Phishing-E-Mails, die dieselbe Schadsoftware mithilfe unterschiedlicher Social-Engineering-Methoden verbreiten.
Die erste E-Mail gibt sich als UPS Forwarding Hub aus und präsentiert Buchungsdetails und Angebotsinformationen, um Nutzer aus dem Beschaffungs- oder Logistikbereich anzulocken. Die zweite E-Mail tarnt sich als offizielle Mitteilung des malaysischen Finanzamts (LHDN) und fordert Unterlagen für eine Unternehmenssteuerprüfung an, um Druck auf die Empfänger auszuüben, die für Finanzen oder die Einhaltung gesetzlicher Bestimmungen zuständig sind.
Obwohl sich die Köder unterscheiden, nutzen beide bekannte Geschäftsprozesse aus, die zeitnahe Aufmerksamkeit erfordern. Indem sie vertrauenswürdige Marken, realistische Geschäftsszenarien und ein Gefühl der Dringlichkeit einsetzen, erhöhen die Angreifer die Wahrscheinlichkeit, dass die Empfänger das angehängte Archiv öffnen und den eingebetteten JavaScript-Code ausführen.
Erster Zugriff
Die Kampagne beginnt mit Phishing-E-Mails, die wie legitime Geschäftskorrespondenz aussehen. Im Rahmen unserer Untersuchung stellten wir zwei Phishing-E-Mails fest, die auf unterschiedlichen Geschäftsszenarien basierten, aber beide der gleichen Angriffskette folgten.
• E-Mail 1 – UPS-Versandbenachrichtigung
Die erste Phishing-E-Mail gibt sich als jemand anderes aus UPS-Weiterleitungszentrum Die E-Mail gibt sich als routinemäßige Versandbuchungsanfrage aus. Sie ist an ein Postfach im Einkauf adressiert und enthält eine Sendungsnummer, eine Angebots-ID, Lieferdetails und Empfängergebühren. Dadurch wirkt sie wie eine reguläre Logistik-E-Mail, die im Geschäftsalltag üblicherweise ausgetauscht wird. Um ihre Authentizität zu unterstreichen, enthält die E-Mail Branding, Versandinformationen und einen komprimierten Archivanhang, der angeblich die zugehörigen Versanddokumente enthält.
Interessant, Die Versanddetails verweisen auf ein Angebot vom 25. Juni 2025, obwohl die E-Mail im Juni 2026 versendet wurde. Dies deutet darauf hin, dass die Phishing-Vorlage wahrscheinlich aus einer früheren Kampagne wiederverwendet oder zusammengestellt wurde, ohne dass alle Felder gründlich aktualisiert wurden.
• E-Mail 2 – Mitteilung über eine Steuerprüfung in Malaysia
Die zweite Phishing-E-Mail gibt sich als die Malaysisches Finanzamt (LHDN) Das Schreiben ist vollständig in Malaiisch verfasst und erweckt so den Anschein einer offiziellen Steuerprüfungsmitteilung. Es fordert Belege für die Körperschaftsteuerveranlagung 2026 an und setzt eine Einreichungsfrist von 14 Tagen, um Dringlichkeit vorzutäuschen. Durch Verweise auf offizielle Steuerformulare, Regierungsbehörden und Kontaktdaten versuchen die Angreifer, Glaubwürdigkeit zu erlangen und die Empfänger zum Öffnen des beigefügten Archivs zu bewegen.
Durch die lokalisierte Sprache und den regulatorischen Kontext wirkt die E-Mail wie routinemäßige Geschäftskorrespondenz im Zusammenhang mit der Einhaltung steuerlicher Vorschriften.
Ein gemeinsamer Liefermechanismus
Obwohl die Social-Engineering-Methoden unterschiedlich sind, verbreiten beide E-Mails dieselbe schädliche JavaScript-Datei, verpackt in komprimierten Archiven. Dies deutet darauf hin, dass die Angreifer eine konsistente Malware-Verbreitungskette wiederverwenden und den Köder lediglich an verschiedene Geschäftsszenarien anpassen.
Infektionskette
Abbildung 3 veranschaulicht die vollständige Infektionskette, die wir im Rahmen unserer Analyse beobachtet haben. Die Kampagne nutzt einen mehrstufigen Ausführungsablauf, in dem jede Stufe schrittweise die nächste Komponente rekonstruiert und startet, bis schließlich Phantom Stealer v3.5.0 installiert wird.
Technische Analyse
Phase 1: Erste Auslieferung (Archiv->JavaScript)
Beide Phishing-E-Mails enthalten einen komprimierten Archivanhang. Der darin enthaltene JavaScript-Code ist durch Dateinamen getarnt, die thematisch eng mit der Phishing-E-Mail verknüpft sind. In den untersuchten Beispielen verwenden die Angreifer branchenrelevante Namen wie beispielsweise:
- UPS-Dokumente_Sendungsnummer 3264010420-Angebots-ID 203263067.js
- Bankeinzahlungsbeleg für Rechnung vom Mai 26 MBB531540 dd 20042026.js
- CKHT800A_RUJ ATC13529CWYE25M.js
Durch die Anpassung des Dateinamens an die Social-Engineering-Masche erscheint der Anhang wie ein legitimes Versanddokument, ein Bankauszug oder eine steuerbezogene Datei, wodurch die Wahrscheinlichkeit steigt, dass die Empfänger ihn ohne Verdacht ausführen.
Analyse der JavaScript-Datei
Anstatt sofort bösartige Aktivitäten auszuführen, verschleiert das Skript zunächst seine Funktionalität durch mehrere Schichten von Zeichenkettenverschleierung und indirekten Funktionsaufrufen.
Funktionsnamen, Methodenaufrufe, Befehlszeichenfolgen usw. werden durch numerische Indizes ersetzt, die auf versteckte Zeichenketten-Arrays verweisen, wodurch das Skript wesentlich komplexer erscheint, als es tatsächlich ist.
Das Skript enthält zahlreiche Hilfsfunktionen, die lediglich einfache arithmetische oder Vergleichsoperationen durchführen. Diese Wrapper bieten keinen funktionalen Nutzen, sondern beeinträchtigen die Lesbarkeit erheblich, da Analysten gezwungen sind, mehrere Abstraktionsebenen zu verfolgen, bevor sie zur eigentlichen Ausführungslogik gelangen. Die kodierten String-Arrays werden nur einmal initialisiert und anschließend wiederverwendet, was den Ausführungsablauf zusätzlich verschleiert.
Fähigkeiten des JavaScript Loaders
Die Verschleierung verbirgt zwar zunächst das Verhalten des Skripts, doch die Wiederherstellung der eingebetteten Zeichenketten liefert ein klares Bild seiner beabsichtigten Funktionalität. Die dekodierten Zeichenketten enthalten Verweise auf PowerShell, native Windows-COM-Objekte, Dateivorgänge und WMI, was allesamt auf einen sorgfältig entwickelten Loader und nicht auf eine eigenständige Malware-Payload hindeutet.
Diese Artefakte deuten darauf hin, dass JavaScript für die Vorbereitung der Ausführungsumgebung, die Rekonstruktion der nächsten Phase und die Übergabe der Kontrolle an PowerShell verantwortlich ist. Dieser mehrschichtige Ansatz hält die eigentliche Nutzlast bis zur Laufzeit verborgen, was die statische Analyse erheblich erschwert.
Eingebettete Base64-Nutzdaten
Eine der auffälligsten Eigenschaften des Loaders ist das Vorhandensein eines großen, Base64-kodierten Datenblocks, der direkt in den JavaScript-Quellcode eingebettet ist. Anstatt die nächste Stufe von einer externen Quelle herunterzuladen, bettet der JavaScript-Loader ein vollständiges, Base64-kodiertes PowerShell-Skript in seinen Quellcode ein.
Die kodierte Nutzlast wird als JavaScript-Objekteigenschaft gespeichert und erst während der Ausführung wiederhergestellt. Dadurch bleibt der Loader in sich abgeschlossen und die eigentliche PowerShell-Logik wird vor statischer Überprüfung verborgen.
Nach Abschluss der Initialisierung ruft das JavaScript die eingebettete, Base64-kodierte PowerShell-Nutzlast aus dem Objekt „encodedData“ ab. Mithilfe nativer Windows-COM-Komponenten dekodiert der Loader den eingebetteten Inhalt, rekonstruiert das PowerShell-Skript und speichert es in einer temporären .ps1-Datei. Anschließend ruft er powershell.exe mit verborgenen Ausführungsparametern auf, um die Kontrolle an die nächste Stufe der Infektionskette zu übergeben.
Eine typische Ausführungssequenz von JavaScript, das PowerShell ausführt, sieht wie folgt aus –
Phase 2: Analyse des PowerShell Loaders 1
Anstatt die nächste Stufe direkt im Klartext einzubetten, speichert der PowerShell-Loader sie als AES-verschlüsselte Nutzlast. Der verschlüsselte Inhalt, der Verschlüsselungsschlüssel und der Initialisierungsvektor (IV) sind als Base64-kodierte Zeichenketten im Skript eingebettet. Dadurch bleibt der Loader vollständig in sich abgeschlossen, und die eigentliche Schadlogik bleibt bis zur Laufzeit verborgen.
Bevor die verschlüsselte Nutzlast entschlüsselt werden kann, entfernt das Skript Leerzeichen und Zeilenumbrüche aus den eingebetteten Base64-Zeichenketten, um einen zusammenhängenden Datenstrom wiederherzustellen. Anschließend werden die bereinigten Zeichenketten mithilfe der .NET- Methode ` Convert.FromBase64String()` in Byte-Arrays konvertiert . Dieselbe Routine wird wiederverwendet, um die verschlüsselte Nutzlast, den AES-Schlüssel und den Initialisierungsvektor zu verarbeiten.
AES-Entschlüsselungsroutine
Sobald die Base64-codierten Komponenten in Byte-Arrays umgewandelt sind, rekonstruiert der Loader die versteckte Nutzlast mithilfe der .NET- Klasse AesCryptoServiceProvider.
Das Skript konfiguriert die Verschlüsselung für den CBC-Modus mit PKCS7-Padding, bevor ein Entschlüsselungsobjekt erstellt wird, das die verschlüsselten Daten vollständig im Speicher verarbeitet. Durch die Verwendung nativer .NET-Kryptografiebibliotheken anstelle benutzerdefinierter Entschlüsselungsroutinen erreicht der Loader eine zuverlässige und kompakte Implementierung und verbirgt den nächsten Schritt bis zur Ausführung.
Die entschlüsselten Bytes werden über einen CryptoStream in einen MemoryStream geschrieben, wodurch der gesamte Entschlüsselungsprozess im Speicher stattfinden kann.
Ausführung
Nach erfolgreicher Wiederherstellung des Klartext-Skripts überträgt der Loader die Ausführung umgehend mittels Invoke-Expression. Dadurch kann das Skript direkt aus dem Speicher ausgeführt werden, sodass der nächste Schritt beginnen kann, ohne dass zusätzliche Dateien auf dem kompromittierten System erstellt werden.
Phase 3: Analyse des PowerShell Loaders 2
Stufe 3 dieser Infektionskette ist ein weiterer Base64-entschlüsselter Blob, der in Stufe 2 mit PowerShell erzeugt wurde.
Im Gegensatz zur vorherigen Phase, die sich auf die Entschlüsselung des eingebetteten Skripts konzentriert, ist dieser Loader für die Wiederherstellung einer geschützten .NET-Assembly, die Überwachung der Ausführungsumgebung und das Starten der Assembly direkt aus dem Speicher zuständig, ohne sie auf die Festplatte zu schreiben.
Vorbereitung der endgültigen Nutzlast für die reflektierende Ausführung
Die Analyse des sekundären PowerShell-Skripts ergab, dass es zwei unterschiedliche Nutzdaten enthält , die jeweils einen anderen Zweck in der Infektionskette erfüllen.
• Nutzlast 1: Injektor
Die erste Nutzlast wird als Base64-kodierter Blob gespeichert und mit einer einfachen XOR-Verschlüsselung geschützt. Diese Assembly fungiert als In-Memory-Injektor und ist für die Ausführung der nachfolgenden Phase zuständig.
Vor der Ausführung dekodiert der PowerShell-Loader die Base64-Daten und wendet eine XOR-Entschlüsselungsroutine unter Verwendung des fest codierten Schlüssels an. „DEVILboy56@@“ um die ursprüngliche Baugruppe im Speicher wiederherzustellen.
Erfolgreiche XOR-Entschlüsselung des Base64-Blobs führt zu einer .NET-Assembly, die direkt in den Speicher geladen wird.
• Nutzlast 2: Phantomdieb
Eine zweite Nutzlast ist im PowerShell-Loader als rohes Byte-Array im Dezimalformat eingebettet.
Die Untersuchung des Byte-Arrays ergab den „MZ“ -DOS-Header (4D 5A), was bestätigt, dass es sich um ein gültiges Portable Executable (PE)-Image und nicht um Shellcode oder kodierte Daten handelt. Im Gegensatz zur ersten Payload wird dieses PE-Image nicht vom PowerShell-Skript entschlüsselt. Stattdessen wird es zusammen mit dem Pfad zur legitimen Binärdatei aspnet_compiler.exe direkt als Argument an die reflektierende .NET-Assembly übergeben.
Dieses Design trennt die Verantwortlichkeiten der einzelnen Komponenten klar voneinander.
- Das PowerShell-Skript fungiert in erster Linie als Orchestrator, indem es den reflektierenden Loader wiederherstellt und ihm den Zielprozess sowie die eingebettete PE-Payload bereitstellt.
- Die eigentliche Injektions- und Ausführungslogik wird an die im Arbeitsspeicher befindliche .NET-Assembly delegiert, wodurch die Komplexität der PowerShell-Phase erheblich reduziert wird, während die endgültige Malware bis zur nächsten Ausführungsphase verborgen bleibt.
Phase 4 – Phantom Stealer v3.5.0: Datenerfassung und -exfiltration
Nach erfolgreicher Ausführung des reflektierenden .NET-Loaders mündet der Angriff in der Installation von Phantom Stealer v3.5.0 . Dieser Stealer zielt darauf ab, eine Vielzahl sensibler Informationen vom kompromittierten System zu sammeln, darunter Hostinformationen, installierte Anwendungen, Browserdaten, Cookies, gespeicherte Zahlungsinformationen, Kryptowährungs-Wallets und Daten gängiger Messaging-Anwendungen. Durch das Sammeln von Informationen aus verschiedenen Quellen maximiert die Malware den Wert des kompromittierten Hosts, bevor sie mit der Datenexfiltration beginnt.
Informationsgewinnung
Phantom Stealer analysiert das infizierte System und sammelt Informationen aus zahlreichen Anwendungen und Benutzerprofilen. Zu den gesammelten Daten gehören Systeminformationen, installierte Software, Browserdaten, Cookies, gespeicherte Zahlungskarten, Browserverlauf sowie Dateien von Kryptowährungs-Wallets und Messaging-Anwendungen. Die gesammelten Informationen werden nach Anwendung oder Datentyp in separate Dateien sortiert, um die spätere Datenexfiltration zu vereinfachen.
Beispiele für geborgene Artefakte sind:
- Chromium_passwords_ .txt
- Chromium_Kreditkarten_ .txt
- Chromium_Cookies_ .json
- Gecko_passwords_ .txt
- Gecko_cookies_ .json
SMTP-Authentifizierung
Nach dem Verbindungsaufbau authentifiziert sich die Schadsoftware beim SMTP-Server mittels des AUTH-LOGIN -Mechanismus. Benutzername und Passwort werden Base64-kodiert übertragen, bevor der SMTP-Server die Berechtigung zum Versenden ausgehender E-Mails erteilt.
Im Rahmen unserer Analyse wurden folgende Merkmale festgestellt:
Benutzername (Base64): cnVoaUBha3Rla21ldGFsLmNvbS50cg==
Entschlüsselt zu: ruhi@aktekmetal[.]com[.]tr
Das Passwort wird in ähnlicher Weise in Base64-kodierter Form übertragen, bevor die Authentifizierung erfolgreich abgeschlossen wird.
Als wir die vom Bedrohungsakteur erbeuteten Base64-Daten dekodierten (siehe Abb. 18), fanden wir die eigentlichen Daten im folgenden Format vor.
SMTP-basierte Datenexfiltration
Phantom Stealer übermittelt die gesammelten Informationen direkt über die SMTP (Simple Mail Transfer Protocol)Die dynamische Analyse ergab, dass die Malware eine SMTP-Sitzung über TCP-Port 587Der Standard-Übermittlungsport für die authentifizierte E-Mail-Zustellung. Nach der Verbindung zum Mailserver initiiert die Malware einen Erweitertes SMTP (ESMTP) Sitzung mit der EHLO Befehl und anschließend wird der Kommunikationskanal durch STARTTLSDadurch wird sichergestellt, dass die übermittelten Zugangsdaten und gestohlenen Informationen während der Übertragung durch TLS-Verschlüsselung geschützt sind.
Anstatt alle gestohlenen Informationen in einem einzigen Archiv zusammenzuführen, generiert Phantom Stealer mehrere Dateien, von denen jede einer bestimmten Anwendungs- oder Anmeldeinformationskategorie entspricht.
Nach erfolgreicher Übertragung der gesammelten Informationen beendet die Schadsoftware die SMTP-Sitzung ordnungsgemäß mit dem Befehl QUIT . Dadurch wird die E-Mail-Transaktion gemäß den Standard-SMTP-Semantiken abgeschlossen, sodass die schädliche Kommunikation legitimen ausgehenden E-Mail-Verkehr täuschend ähnlich sieht.
Kampagnenzuordnung
Zum Zeitpunkt der Analyse fanden wir keine eindeutigen Beweise, die diese Kampagne mit einem bestimmten Bedrohungsakteur oder einer bestimmten Angriffsmethode in Verbindung bringen. Obwohl die finale Payload als Phantom Stealer v3.5.0 identifiziert wurde, ist die Malware im Ökosystem der Cyberkriminellen weit verbreitet und wird von mehreren Akteuren eingesetzt.
Fazit
Diese Kampagne verdeutlicht, wie sich moderne Phishing-Angriffe von der einfachen Verbreitung von Schadsoftware zu sorgfältig orchestrierten, mehrstufigen Angriffsketten entwickelt haben. Indem sie legitime Geschäftskommunikation aus den Bereichen Logistik, Bankwesen und regulatorische Compliance imitieren, erhöhen die Angreifer die Wahrscheinlichkeit einer Interaktion mit den Nutzern und verbergen gleichzeitig einen ausgeklügelten Ausführungsablauf hinter scheinbar routinemäßigen Dokumenten.
Anstatt die endgültige Nutzlast direkt offenzulegen, enthüllt jede Stufe nur die nächste Komponente in der Infektionskette, was die Komplexität der statischen Analyse erheblich erhöht und die Möglichkeiten zur Früherkennung verringert.
Für Unternehmen dient diese Kampagne als Erinnerung daran, dass überzeugende E-Mails im geschäftlichen Kontext, selbst solche, die scheinbar von vertrauenswürdigen Logistikdienstleistern, Finanzinstituten oder Regierungsbehörden stammen, mit Vorsicht zu behandeln sind. Die Stärkung der E-Mail-Sicherheit, die Schulung von Mitarbeitern zur Überprüfung unerwarteter Anhänge, die Einschränkung unnötiger Skriptausführungen und die Überwachung verdächtiger PowerShell-Aktivitäten, des Ladens von Speicherinhalten durch Reflexion, der Prozessinjektion und ungewöhnlichen ausgehenden SMTP-Verkehrs können die Wahrscheinlichkeit, ähnliche Bedrohungen zu erkennen, bevor sensible Informationen kompromittiert werden, deutlich erhöhen.
Diese Kampagne unterstreicht die Bedeutung einer mehrschichtigen Verteidigungsstrategie, bei der E-Mail-Sicherheit, endpoint protectionVerhaltensüberwachung und Netzwerktransparenz arbeiten zusammen, um ausgeklügelte, mehrstufige Angriffe zu identifizieren, die herkömmliche signaturbasierte Erkennungsmethoden umgehen können.
IOCs-
6BBFC88534D5D515DDDB0EC9BB618530
8A620E451E64F418BC21FD458E952F2E
5F238710A5EF4F6DDBBE7A118C822705
a30b628d0c087f305b35be3e3f5281b3
34bfa888695b9aaa41bd575245972043
Seqrite Erfassungsbereich-
Trojan.Injector.S39585891
Trojan.YakbeexMSIL.ZZ4
PS.Trojan.Loader.50921.GC
Js.Trojan.Loader.50922.GC
MITRE-Angriffstaktiken, -techniken und -verfahren (TTPs)
| Taktiken (ATT&CK ID) | Techniken / Subtechnik (ID) | Ablauf |
| Erstzugriff (TA0001) | Phishing: Spear-Phishing-Anhang (T1566.001) | Übermittelt schädlichen ZIP-Anhang |
| Ausführung (TA0002) | Befehls- und Skriptinterpreter: JavaScript (T1059.007) | Führt verschleiertes JavaScript aus |
| Ausführung (TA0002) | Befehls- und Skriptinterpreter: PowerShell (T1059.001) | Startet verstecktes PowerShell |
| Stealth (TA0005) | Verschleierte/komprimierte Dateien und Informationen (T1027) | Nutzt mehrschichtige Verschleierung |
| Stealth (TA0005) | Entschlüsseln/Dekodieren von Dateien oder Informationen (T1140) | Dekodiert Base64-, AES- und XOR-Nutzdaten |
| Stealth (TA0005) | Reflektierendes Code-Loading (T1620) | Lädt die .NET-Assembly aus dem Speicher |
| Stealth (TA0005) | Maskierung (T1036) | Verwendet Dateinamen mit geschäftlichem Bezug |
| Stealth (TA0005) | Prozessinjektion (T1055) | Injiziert Payload in aspnet_compiler.exe |
| Stealth (TA0005) | System Binary Proxy Execution (T1218) | Missbraucht legitime .NET-Binärdateien |
| Entdeckung (TA0007) | Systeminformationsermittlung (T1082) | Sammelt Hostinformationen |
| Entdeckung (TA0007) | Prozesserkennung (T1057) | Prüft den Status des Zielprozesses |
| Zugangsdatenzugriff (TA0006) | Anmeldeinformationen aus Passwortspeichern (T1555) | Extrahiert gespeicherte Anmeldeinformationen |
| Zugangsdatenzugriff (TA0006) | Anmeldeinformationen von Webbrowsern (T1555.003) | Stiehlt Browser-Anmeldeinformationen und Cookies |
| Sammlung (TA0009) | Daten aus dem lokalen System (T1005) | Erfasst lokale Anwendungsdaten |
| Sammlung (TA0009) | Archivierte gesammelte Daten (T1560) | Ordnet gestohlene Daten in Dateien |
| Exfiltration (TA0010) | Exfiltration über alternatives Protokoll (T1048) | Exfiltriert Daten über SMTP |
| Befehl und Kontrolle (TA0011) | Anwendungsschichtprotokoll: E-Mail-Protokolle (T1071.003) | Verwendet das SMTP-Protokoll |
| Befehl und Kontrolle (TA0011) | Verschlüsselter Kanal (T1573) | Verschlüsselt SMTP mit STARTTLS |
Autoren
- Prashil Moon
- Manoj Kumar Neelamegam
