Einführung

In diesem Artikel werde ich mich mit der Erkennung von HTML-Schmuggel befassen und dabei den technischen Prozess zur Erkennung befolgen, den ich in meinen letzten beiden Beiträgen beschrieben habe. Dieser Prozess umfasst die Erforschung, Erprobung und Entwicklung neuer Detektionskonzepte. Im Gegensatz zu meinen vorherigen Beiträgen werden wir dieses Mal jedoch echte QakBot-Malware im Labor beobachten, profilieren und erkennen. Mit diesem Beitrag möchte ich zeigen, wie aktuelle und aufstrebende Erkennungsingenieure über simulierte Herausforderungen im CTF-Stil hinausgehen können, um reale Angreifertechniken zu untersuchen und zu erkennen, sie für unser SOC zu kennzeichnen und es unseren Kollegen für die Reaktion auf Vorfälle zu ermöglichen, die Bedrohung zu neutralisieren.

Unsere Reiseroute

Nach einigen Hintergrundinformationen und der Definition des Ziels werde ich demonstrieren, wie wir QakBot HTML Smuggling-Malware im Labor ausführen und ihr Verhalten in Splunk verfolgen können. Dann folge ich beobachtbare Ereignisse dieses Angriffs und identifiziere nützliche Erkennungspunkte (die ich als „Bausteine“ oder Glieder der Angriffskette betrachte). Ich werde auch Korrelation (insbesondere Kettenregeln) vorstellen, ein entscheidendes Werkzeug in Ihrer Toolbox zur Erkennung von Bedrohungen. Um zu veranschaulichen, wie das aussieht, werde ich eine noch unveröffentlichte Funktion von Sigma namens Sigma Correlations diskutieren und demonstrieren. Zum Abschluss teste ich eine neue Kettenregel gegen 10 weitere Beispiele von QakBot HTML Smuggling-Malware, um zu sehen, wie sie sich verhält.

Lass uns anfangen!

Hintergrund

Zu Beginn meiner Reise zur Cybersicherheit sagte John Strand von Black Hills Information Security etwas, das mir im Gedächtnis geblieben ist: „Es gibt kein ‚SIE WURDEN GEHACKT‘-Protokoll.“ Ereignisprotokolle können verwirrend und selbst an guten Tagen schwer zu lesen sein. Das Ableiten nützlicher, umsetzbarer Erkenntnisse aus Protokollen ist schwierig! Die Herausforderung erfordert manchmal eine gründliche Analyse und spezialisierte Techniken, um erfolgreich zu sein.

Ich hatte diese Lektion während meiner gesamten Karriere im Sicherheitsbereich im Hinterkopf, und vor diesem Hintergrund begann ich vor ein paar Monaten, Tonnen von Posts wie diesen von @pr0xylife zu sehen :

Ich mag die Art und Weise, wie pr0xylife und ihre Kollegen diese Angriffe so prägnant zusammenfassen, und ich fand mich dabei, wie ich die Abfolge der Dateitypen laut wiederholte – fast wie eine seltsame Form der Poesie!

Ich wollte mehr lernen, wusste aber nicht, wie ich anfangen sollte. Ich hatte einige hervorragende Forschungen des Teams von Trellix zu QakBot überprüft, daher kannte ich ihre Techniken ein wenig. (Wenn Sie noch nie von QakBot gehört haben, lesen Sie bitte den Trellix-Bericht!) Als ich anfing, die Aktivitäten von QakBot zu verfolgen und tiefer zu graben, wurde mir klar, dass pr0xylife und andere die subtilen Kombinationen und Variationen beschrieben, wie QakBot seine Opfer austricksen und unseren ausweichen kann Verteidigung. Einige Beispiele:

• Es verwendet HTML-Schmuggel , bei dem eine bösartige HTML-Datei mit verschlüsseltem JavaScript vom Browser des Opfers ausgeführt wird und die nächste Stufe der Nutzlast herunterlädt.
• Es verwendet passwortgeschützte ZIP-Dateien , um die Sandboxing-Analyse zu blockieren.
• Es verwendet ein Disk-Image-Format namens .iso-Datei, um den Mark-of-the-Web-Schutz zu umgehen, wie Red Canary sehr gut erklärt .
• LNK-Dateien, die getarnt sind, um Benutzer dazu zu verleiten, versteckte .CMD- und .DLL-Dateien auszuführen.
• Und weiter und weiter mit immer mehr Täuschungsmanövern!

Das Ziel

Es gibt einige Erkennungen für HTML-Schmuggel und andere mit QakBot verbundene Techniken. Diese basieren hauptsächlich auf übereinstimmenden verdächtigen Protokollereignissen, wie z. B. diesem von Elastic Security:

Ich wollte sehen, ob ich meine eigenen Erkennungen erstellen könnte, indem ich Korrelation (im Gegensatz zu einfachem Abgleich) verwende, um sie widerstandsfähig gegen subtile Änderungen im Angriffsverhalten zu machen.

TBH, ich hatte auch die dummen Schikanen von QakBot satt und wollte einen zuverlässigen Weg, um es direkt in unser Sichtfeld zu bringen.

Erste Beobachtung und Analyse von QakBot-Malware

Um mein Ziel zu erreichen, musste ich über Threat Intelligence-Berichte von Sicherheitsanbietern und Atomic Red Team-Tests hinausgehen; Ich brauchte meine eigenen Daten, die aus echten Malware-Beispielen erstellt wurden. Ich wandte mich einem alten Favoriten zu: malware-traffic-analysis.net von Brad Duncan (@malware_traffic). Diese Website gehört zu den nützlichsten Bildungsressourcen, die mir im Bereich Sicherheit begegnet sind. Zusätzlich zu Wireshark-Tutorials und praktischen Übungen zum Netzwerkverkehr bietet die Website Qualitätsanalysen realer Malware-Beispiele, einschließlich QakBot-HTML-Schmuggeldateien.

Nachdem ich Snapshots meiner Labor-VMs erstellt hatte, startete ich mein virtuelles Erkennungslabor und besuchte einen kürzlich erschienenen Eintrag. Seien Sie vorsichtig, die auf dieser Seite gehosteten Dateien sind unsicher!

Ich habe die ZIP-Datei mit den Artefakten heruntergeladen und mit dem in mein Erkennungslabor integrierten WinRAR-Dienstprogramm in meinen Download-Ordner extrahiert:

Die IOC-Notizen waren äußerst hilfreich, um den enthaltenen Dateien einen Kontext zu geben. Unter den Notizen befanden sich die folgenden, die mich wissen ließen, dass die Infektionskette mit der HTML-Datei mit dem Namen SCAN_DT6281.html begann.

2022-12-09 (FRIDAY) - HTML SMUGGLING FOR QAKBOT (QBOT) DISTRIBUTION TAG: AZD

DISTRIBUTION:

- Unknown source, possibly email --> HTML file --> password-protected zip archive --> extracted ISO image with .img file extension

… klar, öffnen wir die ZIP-Datei, warum nicht?

Die ZIP-Datei war passwortgeschützt, konnte aber mit dem auf der HTML-Seite angezeigten Passwort geöffnet werden. Die ZIP-Datei enthielt eine einzelne .img-Datei, von der ich weiß, dass es sich um ein anderes montierbares Disk-Image-Dateiformat handelt. Durch Doppelklicken darauf wurde die Datei als Laufwerk D auf meinem System bereitgestellt:

Ich habe auch ein verstecktes Verzeichnis namens IncomingPay bemerkt, das eine .lnk-Datei, zwei Textdateien, die (kein Witz) Auszüge aus der Wikipedia-Seite über Psychologie, eine .cmd-Datei und eine .lc-Datei enthielten.

Als Sicherheitsexperte und pflichtbewusster Beobachter von Schulungen zum Sicherheitsbewusstsein in Unternehmen waren alle meine auf den Beinen und winkten im Wind. Aber das ist für die Wissenschaft, also nehme ich den Köder und doppelklicke auf die LNK-Datei, genau wie der Angreifer es vom Opfer will. Ein Befehlszeilenfenster erscheint für einige Sekunden und verschwindet dann:

Interessant ist die Ziel-Eigenschaft der LNK-Datei:

C:\Windows\System32\cmd.exe /c IncomingPay\Issues.cmd A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9

Woher weiß ich, welche Suchen ausgeführt werden sollen? Ich nicht wirklich, aber durch meine Erfahrung als Analyst und Forscher weiß ich, dass es bestimmte Arten von Beweisen gibt, die in meinen Protokollen erscheinen können – Prozessausführungen, Dateierstellung, Netzwerkverbindungen und dergleichen. Hier sind praktische Erfahrungen als Sicherheitsanalyst oder eine gute Dosis CTF-ähnlicher Schulungen (wie sie bei CyberDefenders oder LetsDefend erhältlich sind ) von Vorteil .

Nachdem ich meine Suche ein paar Mal aktualisiert und mich gefragt hatte, ob ich etwas falsch gemacht hatte, bemerkte ich ein eindeutiges, unbestreitbares Zeichen eines Eindringens: einen Ausbruch von Aufklärungsaktivitäten auf meinem Opfer-Host:

Als ich mir diese Befehle ansah, bemerkte ich den Zeitraum, in dem sie auftraten – alles innerhalb weniger Sekunden! Außerdem wurden die Prozesse alle von einem ungewöhnlichen Elternteil erzeugt – wermgr.exe (dem Windows Error Reporting Manager). Vielleicht eine gute Erkennungsmöglichkeit? Selbst der verwirrteste Administrator oder die überbaute [legitime] Software wird nicht alle diese verdächtigen Aufklärungsbefehle innerhalb eines so kurzen Zeitrahmens ausführen, und niemals als Kinder einer wermgr.exe. Als ich zu meinen Netzwerkverbindungen überging, bemerkte ich, dass wermgr.exe plötzlich extrem geschwätzig mit externen IP-Adressen geworden war:

Nach dieser ersten Bewertung meiner Daten habe ich Folgendes festgestellt:

• Das Malware-Sample enthielt einen böswilligen Erstzugriffsvektor (duh, die Rogue-Galerie der .html-, .zip-, .img-, .lnk-, .cmd- und .lc-Dateien).
• Die Malware lud die Zip-Datei herunter, nachdem sie die HTML-Seite in einem Browser geöffnet hatte, und die Zip-Datei enthielt eine mountbare .img-Datei.
• Das gemountete Laufwerk enthielt eine böswillige Verknüpfung, die zur Ausführung zusätzlicher Befehle führen würde.
• Ein injizierter wermgr.exe-Prozess löste einen automatisierten Ausbruch von Aufklärungsaktivitäten aus und stellte dann eine Verbindung zu verdächtigen externen IP-Adressen her, vermutlich um dem Angreifer Informationen über unser System und Netzwerk zu senden.

Zerlegung des Angriffs in Erkennungsbausteine

Nachdem ich im Labor eine erste Ausführung der QakBot-HTML-Schmuggeltechnik durchgeführt und zu meinen VM-Snapshots zurückgekehrt war, war es an der Zeit, weiter in den Protokollen zu graben, um zu sehen, was passierte.

Als ich die verschiedenen Arten von Ereignissen, die durch den Angriff verursacht wurden, überprüfte, begann ich, ein klares narratives Verständnis von dem zu entwickeln, was geschah:

„Ein Angreifer sendet einem Opfer eine HTML-Datei, die vorgibt, einen Bericht, eine Rechnung oder ein anderes für ihn interessantes Dokument zu enthalten. Im Grunde ein Phishing-Köder. Wenn das Opfer die Datei in seinem Browser öffnet , wird eingebetteter JavaScript-Code ausgeführt, der eine passwortgeschützte ZIP-Datei auf dem System des Opfers herunterlädt oder erstellt. Wenn das Opfer das Archiv entpackt , erstellt die Extraktion eine mountbare Disk-Image-Datei. Nach dem Mounten des Laufwerks sieht der Benutzer eine Verknüpfung, von der er glaubt, dass sie ihn zu der Ressource führt, die er zu finden versucht. Aber die Verknüpfung ruft tatsächlich einen Befehl oder Skriptinterpreter auf, der andere bösartige Dateien ausführtdie auf dem Laufwerk versteckt sind, was zu einer anfänglichen Kompromittierung des Zugriffs führt.“

Das ist ein wortreicher Brocken Prosa, aber in meinem Kopf macht es Sinn. Wenn ich etwas entdecken will, muss ich es zuerst verstehen! Beachten Sie den fettgedruckten Text: Ich habe meine Erzählung verwendet, um Ereignisse hervorzuheben, die ich verwenden könnte, um die Angriffskette zu erkennen. Basierend auf dieser Überprüfung habe ich die Protokolle des Angriffs analysiert und versucht, die folgenden Ereignisse zu isolieren:

1. An das Opfer gesendete Phishing-E-Mail mit einem HTML-Anhang.
2. Erstellung einer HTML-Datei an verdächtigen Orten.
3. Öffnen einer eigenständigen HTML-Datei in einer Browseranwendung.
4. Herunterladen/Erstellen einer ZIP-Datei durch die Browseranwendung.
5. Öffnen/Extrahieren einer passwortgeschützten Zip-Datei.
6. Erstellen eines montierbaren Dateiformats für Laufwerke (.iso, .img usw.).
7. Mounten eines Laufwerks.
8. Prozessausführung auf einem externen Laufwerk (entweder von einer ausführbaren Datei auf diesem Laufwerk oder von einer ausführbaren Systemdatei, die Dateien auf diesem Laufwerk berührt).

Die guten Nachrichten

Die gute Nachricht war, dass es Möglichkeiten gibt, fast alle oben aufgeführten Ereignisse zu erkennen! Das bedeutet, dass ich zahlreiche Ideen hatte, wie verfügbare Protokolle abgefragt und gefiltert werden können, um die aussagekräftigen Ereignisse (Bausteine) für zukünftige Erkennungen zu extrahieren.

Die schlechten Nachrichten

Die schlechte Nachricht war, dass keines dieser vielen Ereignisse für sich genommen bösartig ist. Auch hier gibt es kein IHRE HACKED-Protokoll: Jedes dieser Ereignisse kann im normalen Geschäftsverlauf auftreten und völlig sicher und harmlos sein. Die Lösung wäre, diese Ereignisse in einer geordneten oder ungeordneten Reihenfolge zu korrelieren, sie nach einem gemeinsamen Attribut wie dem Hostnamen zu gruppieren und eine Warnung auszulösen, wenn all diese Ereignisse innerhalb eines Zeitfensters, z. B. einer Stunde, auftreten. Das Problem ist nach meiner Analyse und meinen Tests (mehr dazu gleich), dass das Verketten oder Korrelieren so vieler Ereignisse zu einer spröden Erkennung führen würde.

Spröde vs. belastbar

„Sprödigkeit“ beschreibt den Grad, in dem eine Erkennungsidee angesichts subtiler Änderungen der Angreifertechniken, Variationen der vom Opfer ausgeführten Aktionen, Problemen mit der Protokollierung oder anderer Faktoren, die außerhalb unserer Kontrolle liegen, auseinanderfällt. Spröde Erkennungen stehen im Gegensatz zu „widerstandsfähigen“ Erkennungen, die flexibel sind und diesen subtilen Verschiebungen standhalten können.

Es ist nicht so einfach zu sagen „Spröde = schlecht und belastbar = gut“. Eine spröde Erkennung könnte mit einer engen „Öffnung“ sehr gezielt erfolgen. Der Vorteil könnte darin bestehen, dass beim Auslösen einer Sprödigkeitserkennungsregel eine sehr hohe Wahrscheinlichkeit besteht, dass es sich um ein echtes Positiv handelt. Widerstandsfähige Erkennungen können eine breitere Apertur haben und mit mehr potenziellen böswilligen Aktivitäten übereinstimmen. Dies könnte jedoch zu falsch positiven Ergebnissen und einem frustrierten SOC führen, wenn sie nicht sorgfältig entwickelt werden.

In diesem Sinne bin ich zu meiner Ereignisliste von oben zurückgekehrt.

Bestimmung der zu testenden Bausteine

Im Kontext wurde mir klar, dass die Punkte eins bis drei in der obigen Liste möglicherweise keine guten Komponenten für meine Erkennung von HTML-Schmuggel sind. Mangelnde Sichtbarkeit und ein hohes Maß an unschuldigem Verhalten würden Punkt 1 behindern. Ich habe Punkt zwei gestrichen, weil ich nur begrenzte Möglichkeiten hatte, dieses Ereignis zu testen, und Punkt drei erwies sich je nach verwendetem Browser als unzuverlässig. Obwohl es technisch gesehen kein HTML-Schmuggel ist, verwenden viele QakBot-Aktivitäten URLs anstelle von eigenständigen HTML-Dateien, um die anfängliche Nutzlast zu liefern.

Punkt fünf (Extraktion einer passwortgeschützten ZIP-Datei) hat viel Potenzial und kann mit dieser von Florian Roth geschriebenen und von der Recherche von @SBousseaden inspirierten Regel erkannt werden . Ich habe es jedoch aus meinem Bereich gelassen, weil 1) dieses Ereignis nicht in meinem Labor protokolliert wurde und 2) einige Dokumentationen darauf hinweisen, dass es nur für bestimmte Betriebssysteme gilt.

Nachdem ich meine Daten untersucht, mögliche Erkennungsbausteine ​​für meine Korrelation aufgezählt und diese Liste basierend auf weiteren Analysen durchforstet hatte, hatte ich die folgenden Bausteine:

1. Webbrowser erstellt (lädt) eine Zip-Archivdatei herunter (stellt das Öffnen der schädlichen HTML-Datei in einem Browser dar).
2. Aus Zip extrahierte ISO-, VHD-, LNK- oder IMG-Datei (Extrahieren der schädlichen Disk-Image-Datei).
3. Disk Image Mount (Mounting des Images – dieses habe ich direkt von Sigma gezogen).
4. Verdächtige benutzerinitiierte Prozessausführung auf externem Laufwerk (Klicken auf die .lnk-Datei, die Dateien auf dem externen Laufwerk ausführt oder darauf verweist).

Sigma-Korrelationen

Die Korrelation ermöglicht es uns, Protokollereignisse über die Zeit zu verfolgen. Anstatt für jedes der vier oben aufgeführten Ereignisse eine Warnung auszulösen, ermöglicht uns eine Kettenregelkorrelation, nur dann eine Warnung auszulösen, wenn alle vier Ereignisse der Reihe nach auf demselben Host von demselben Benutzer auftreten, was viel verdächtiger ist. Viele SIEM-Produkte und ihre entsprechenden Abfragesprachen unterstützen diese Art der Verkettung (obwohl einige dies nicht tun).

Um diese Funktionalität zu unterstützen, arbeitet Sigma an einem Korrelationsstandard, der es uns ermöglicht, benutzerdefinierte Korrelationsregeln in einem gemeinsamen Format zu schreiben und sie dann in ein beliebiges SIEM-Produkt zu konvertieren, das diese Logik unterstützt. Der Normentwurf kann hier eingesehen werden:

Wie könnte das aussehen? Es handelt sich um einen Standardentwurf, der sich ändern kann, aber ein einfaches Beispiel für eine Brute-Force-Kettenregel könnte wie folgt aussehen:

action: correlation
type: temporal
rule:
    - many_failed_logins
    - successful_login
group-by:
    - User
timespan: 1h
ordered: true

Mein Entwurf für eine Korrelationsregel sieht folgendermaßen aus:

title: HTML Smuggling Activity - Chain Rule
id: 0952f2fa-e29b-4eb5-831c-ce21520c56e3
status: experimental
description: Detects HTML smuggling-style compromise (such as HTML > ZIP > ISO/IMG/VHD > CMD/BAT/VBS > DLL). Includes rules to detect zipfile dropped by browser, ISO/IMG/VHD/LNK file extraction, disk image mount, followed by user-initiated process creation on an external drive.
references:
    - https://blog.talosintelligence.com/html-smugglers-turn-to-svg-images/#:~:text=HTML%20smuggling%20is%20a%20technique,directly%20on%20the%20victim's%20device.
    - https://www.malwarebytes.com/blog/news/2021/11/evasive-maneuvers-html-smuggling-explained
    - Original research and analysis performed off of QakBot intelligence gathered at https://github.com/pr0xylife/Qakbot, https://www.malware-traffic-analysis.net/, and https://github.com/executemalware/Malware-IOCs
author: Micah Babinski
date: 2022/12/27
tags:
    - attack.s0650
    - attack.s0483
    - attack.initial_access
    - attack.defense_evasion
    - attack.execution
    - attack.t1564
    - attack.t1566.001
    - attack.t1566
    - attack.t1027
    - attack.t1027.006
    - attack.t1059
    - attack.t1204
    - attack.t1204.002
action: correlation
type: temporal
rule:
    - 1_win_zipfile_drop.yml
    - 2_win_susp_file_extraction.yml
    - 3_win_security_iso_mount.yml
    - 4_win_process_creation_ext_drive.yml
group-by:
    - ComputerName
    - User
timespan: 1h
ordered: true
falsepositives:
    - Unknown
level: high

Auch hier befindet sich die Sigma Correlations-Spezifikation in der Entwicklung und kann sich ändern. Dennoch wird dies eine sehr nützliche Erweiterung der Fähigkeiten von Sigma sein, daher wollte ich es Ihnen jetzt schon vorab vorstellen!

Testen der Korrelation

Als dieses Erkennungskonzept Gestalt annahm und eine Hypothese in Form meiner Korrelationsregel entwickelt wurde, war es an der Zeit, die Erkennung mit einer größeren Stichprobengröße zu testen. Ich habe mich auf das MalwareBazaar-Repository von Abuse.ch verlassen, das eine hilfreiche Bibliothek mit markierten Malware-Beispielen bereitstellt. Ich habe 10 QakBot-HTML-Beispiele heruntergeladen, die größtenteils von pr0xylife gemeldet wurden und deren Datum vom 11. Juli bis zum 22. Dezember 2022 reicht. Ich habe die Beispiele auf meiner Labor-VM vorbereitet und jedes nach seinem ersten Erscheinungsdatum und seinem „Humanhash“ benannt. Eigenschaft (eine zufällige, eindeutige Folge von menschenlesbaren Wörtern, wie z. B. („dakota-earth-mockingbird-march“):

Um meine Ergebnisse zu verfolgen, habe ich eine einfache Tabelle in Google Sheets erstellt:

Ich erstellte vor dem Test einen sauberen Snapshot meines Opfer-VM-Hosts, auf den ich nach jedem Test zurückgreifen konnte, und begann mit dem Test. Nachdem ich sieben der zehn Proben getestet hatte, hatte meine Sequenz aus vier Bausteinen eine perfekte Abdeckung! Als ich jedoch das achte Beispiel traf, wurde die vierte Regel in der Kette nicht ausgelöst, weil die .lnk-Datei direkt RunDLL32.exe anstelle von cmd.exe oder wscript.exe aufrief. Das war in Ordnung – ich habe einfach eine Anpassung an die Bedingungen meiner Sigma-Regel vorgenommen, erneut getestet und perfekte Übereinstimmungen erhalten! Ich war von den Ergebnissen begeistert und freute mich darauf, den Anwendungsfall für die Erkennung mit der Community zu teilen.

Bonusrunde!

Viele QakBot-Phishing-Angriffe verwenden keine .html-Anhänge, sondern stattdessen bösartige .pdf-Dateien mit eingebetteten Links oder einfach gute altmodische Phishing-Links, die auf ZIP-Dateien verweisen, die auf einer kompromittierten Website gehostet werden. Um zu testen, ob meine Erkennung flexibel genug war, um auch diese Instanzen zu erfassen, habe ich sie an einigen aktuellen Beispielen aus dem von @ExecuteMalware verwalteten IOC-Repository getestet und festgestellt, dass diese URL-basierten Driveby-Angriffe ebenfalls von der Erkennung erfasst wurden. Die hier dokumentierte enthielt sogar eine .wsf (Windows Script File) – ein Dateityp, mit dem ich nicht vertraut war, der aber dennoch von meiner Erkennung erwischt wurde.

Ein Hoch auf die Resilienz!

Fazit

Glückwünsche! Sie haben das Ende eines langen Posts über einige dichte, komplizierte Themen erreicht. Alle Regeln, auf die verwiesen wird, finden Sie hier . Vielen Dank fürs Lesen, und ich hoffe, Ihnen hat mein Geschwätz über QakBot, HTML-Schmuggel, Sigma und Korrelationen gefallen. Ich freue mich wirklich sehr auf den Start von Sigma Correlations. Es wird ein großer Gewinn für die Community der Erkennungstechnik sein und es uns ermöglichen, anspruchsvollere Anwendungsfälle für die Erkennung zu teilen.

Ich war sehr zufrieden mit dem Verlauf meiner Tests, insbesondere als sich herausstellte, dass einer der Bausteine ​​in meiner Kettenregel versagt hatte und angepasst werden musste! Warum testen, wenn Sie denken, dass Ihre Arbeit bereits perfekt ist? Schließlich machte mir diese Erfahrung deutlich, was ich bereits zu glauben begonnen hatte – dass wir nicht erkennen können, was wir nicht verstehen. Es gibt keinen Ersatz für Erfahrungen aus erster Hand mit echter Live-Malware, wenn Sie versuchen zu sehen, was sie tut.

Dank des Detection Lab-Projekts, von dem ich in früheren Beiträgen begeistert war, ist diese reale Erfahrung für mehr Menschen als je zuvor erreichbar. Zu guter Letzt danke ich pr0xylife, Brad (malware_traffic) und executemalware für die Bereitstellung makelloser Repositories mit gut dokumentierten QakBot-Malware-Beispielen, auf die wir zugreifen, sie analysieren und verstehen können. Diese sind wirklich eine pädagogische Fundgrube!

Bitte zögern Sie nicht, mir Ideen, Kommentare oder Vorschläge zu senden, wie ich mich verbessern kann. Ich bin noch neu dabei und freue mich über respektvolles Feedback und Kritik in jeglicher Form.

Wie immer viel Spaß beim Analysieren!