Moin,
da hier was die Themenauswahl betrifft ziemlich tote Hose herrscht und man irgendwie vergessen hat mit dem Laufe der Zeit zu gehen (kein Mensch kann die hier "geleakten" uralten RATs mehr einsetzen, das Zeug wird instant von Windows Defender weggef*ckt; SmartScreen und so .. ).
Für Makros ist das folgende ganz hilfreich, ich habe den original Eintrag zusammengefasst und unten verlinkt.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PowerShell Obfuscation
Es gibt mehrere Varianten einen PS Payload zu obfuskieren. In Vergangenheit wurde das (via Empire) u.A. mit GZIP, XOR, simplen Base64 Encoding oder diversen Stringoperationen (Escapen, Formatieren, Konkatinieren) gemacht. Ziel: Download und Ausführung einer Binary direkt in den Speicher rein (in-memory exec.)
Die erwähnten Techniken kann man sich hier geben:
und auf jeder Windows Maschine in der PS Umgebung (ja Windows hat ein eigenes IDE dafür) austesten. Kann Spaß machen und hat mir auch schon geholfen einen MSW Makro zu FUD'den.
Eine Dieser Techniken ist die SecureString obfuscation. Laut dem Niederländer wohl noch ein Ding ..
So sieht dass dann aus. Eine Invoke-Expression "cmdlet" kombiniert mit einem SecureString enkodierten Befehl. Wichtig ist das SecureString hier das Encoding Schema darstellt.
Zu Freuden der eher minderbemittelten Benutzer (nicht Suchmaschinen nutzen zu können), hier das Ganze aufgedrößelt:
"iex" oder IEX ist die Abkürzung für eine Invoke-Expression, welche ein einen String als Befehl evaluiert und das Resultat zurückliefert. System.Net.NetworkCredential wird hier als neues Objekt initialisert, der Befehl für sich versucht sich an einer definierten (Web) Ressource zu authentifizieren über ein User-Passwort Paar (user ist in dem Fall leer; ""). ConvertTo-SecureString macht was der Name sagt (
).
Weiter im Kontext.
Warum gibt es SecureString Objekte? Um mit Passwörtern zu arbeiten. SSO's sind Objekte welche AES verschlüsselte Daten enthalten, standartgemäß werden diese Daten über den Username und Computername verschlüsselt, man kann allerdings auch einen statischen Schlüssel verwenden und entsprechend den Klartext ohne zuviel Aufwand wiedererhalten. Ursprüngliche Idee von MS war, dass man damit z.B. mit Webseiten und deren Authentifizierung interagieren kann (HTTP Auth z.B.).
SecureString kommt out-of-box, ist also in der Standartbibliothek, praktisch. Hier ein kleines Beispiel, wie das ganze funktioniert:
PS> $encoded = ConvertFrom-SecureString -k (0..15) (ConvertTo-SecureString "Malicious Command" -AsPlainText -Force) PS> $encoded 76492d1116743f0423413b16050a5345MgB8AFIAWQB3AHoAbABjADMALwA5AGIAdgA3ADAAYgBzAGQAZABqAFAANQBWAFEAPQA9AHwAYwBiAGIAYwBlADYAYQA0ADQA
Der Schlüssel ist statisch, 128bit (0x0-0xF; 0-15). Das Output besteht aus multiplen AES-verschlüsselt und Base64-enkodierten Elementen. Deserilization kann wie folgt erlangt werden (also von Krypto -> Plain zurück):
PS> (New-Object System.Net.NetworkCredential("", (ConvertTo-SecureString -k (0..15) $encoded))).Password Malicious Command
Gibt auch andere Methoden:
(New-Object System.Management.Automation.PSCredential(" ", (ConvertTo-SecureString -k (0..15) $encoded))).GetNetworkCredential().Password
Hier wird einfach ein anderer API-Call verwendet. Oder:
[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR((ConvertTo-SecureString -k (0..15) $encoded)))
Im Endeffekt ist der Befehl ziemlich praktisch. Ein Angreifer kann wie mit Base64 seine Daten traditionell enkodieren, mit einem Einzeiler aus der Standartbibliothek. Einzige Limitierung: 65,536 Zeichen (ist aber kein Problem sofern man mit dem Befehl dann weitere Scripts nachlädt und ausführt).
Was damit machen kann und wie sei jedem selbst überlassen. Mit der Methode lässt sich allerdings nach wie vor der AV umgehen.
Quelle:
Greetz, Abrax
Bearbeitet von abrax, 20 January 2020 - 10:21 Uhr.