Wir von JSOC CERT untersuchen Vorfälle. Im Allgemeinen untersuchen alle 170 Personen in JSOC, aber die technologisch schwierigsten Fälle fallen in die Hände von CERT-Experten. Wie kann man beispielsweise Spuren einer Malware erkennen, wenn ein Angreifer bereinigt wurde? Wie finde ich einen „Assistenten“, der wichtige Geschäftsdokumente von einem Dateiserver gelöscht hat, auf dem die Protokollierung nicht ordnungsgemäß konfiguriert ist? Zum Nachtisch: Wie kann ein Angreifer Passwörter von Dutzenden nicht verwandter Domain-Konten erhalten, ohne in das Netzwerk einzudringen? Details wie immer unter dem Schnitt.
Wochentags JSOC CERT
Oft müssen wir den tatsächlichen Kompromiss des Kundennetzwerks bewerten, dafür führen wir Folgendes durch:
- retrospektive Analyse von Festplatten und Speicherabbildern,
- Reverse Engineering von Malware
- Falls erforderlich, Notfallbereitstellung der Überwachung und Überprüfung von Hosts auf Kompromissindikatoren und Spuren von Hacking.
In unserer Freizeit schreiben wir detaillierte Zusammenfassungen, Techniken und Spielbücher - im Wesentlichen Anweisungen, die helfen, auch komplexe Untersuchungen zu skalieren Sie können halbautomatisch darauf reagieren.
Manchmal müssen Sie während der Reaktion auf den Vorfall - mitten im Löschen eines „Feuers“ - auch als „psychologischer Unterstützungsdienst“ fungieren. Einmal wurden wir eingeladen, bei der Bekämpfung der Infektion des Subnetzes einer großen Organisation zu helfen. Das Netzwerk wurde von zwei Auftragnehmern bedient, die sich in dieser Situation selbstlos
auf einen Ventilator stürzten und sich auf etwas anderes
einließen , aber nicht nach einem böswilligen Wurm suchten. Um den Grad der Hysterie zu verringern, musste ich alle an den Tisch setzen
, um ein Handtuch und eine Flasche Bourbon zu holen und klar zu erklären, dass es jetzt nicht an der Zeit ist, nach Schuldigen zu suchen. Sie bestimmten das Verteilungsverfahren, leiteten ein zusätzliches Audit ein und begannen, die Infektion gemeinsam und gemeinsam systematisch zu beseitigen.
Während der Untersuchung müssen wir häufig Festplatten- und Speicherabbilder auswählen, um dort aktive Malware zu finden. Um den Prozess vorhersehbar und objektiv zu machen, haben wir verschiedene Methoden für die retrospektive Festplattenanalyse formalisiert und automatisiert und die bereits klassische
SANS- Methode zugrunde gelegt - in der Originalversion ist sie recht hoch, aber bei korrekter Verwendung ermöglicht sie die Erkennung aktiver Infektionen mit sehr hoher Genauigkeit.
Es ist klar, dass die Durchführung von All-All-Checks Zeit und tiefes Expertenwissen über die Funktionen der verschiedenen Komponenten von Betriebssystemen erfordert (und spezielle Software viel erfordert).
Wie vereinfacht man das Überprüfen einer Festplatte auf aktive Infektionen? Wir teilen den Life Hack - er kann dynamisch überprüft werden (wie in der Sandbox), dafür:
- Kopieren Sie die Festplatte des verdächtigen Hosts Stück für Stück.
- Konvertieren Sie das resultierende DD-Image mit diesem Dienstprogramm in das VMDK-Format.
- Führen Sie das VMDK-Image in Virtual Box / VMware aus.
- und analysieren wie ein lebendes System, das sich auf den Verkehr konzentriert.
Es wird jedoch immer Vorfälle geben, für die keine detaillierten Anweisungen geschrieben und die Techniken nicht automatisiert werden.Fall 1. Der Buchhalter hat nichts damit zu tun oder wie wir nach Malware gesucht haben
Der Kunde hat uns gebeten, den Computer des Buchhalters auf Malware zu überprüfen: Jemand hat mehrere Zahlungsaufträge an eine unbekannte Adresse gesendet. Der Buchhalter behauptete, dass er nicht daran beteiligt war und dass sich der Computer zuvor seltsam verhalten hatte: Die Maus bewegte sich manchmal buchstäblich über den Bildschirm selbst - tatsächlich wurden wir gebeten, diese Anzeigen zu überprüfen. Der Haken war, dass der auf 1C gerichtete Trojaner seine schmutzigen Taten vollbrachte und aufräumte und fast einen Monat nach der Infektion verging - während dieser Zeit legte der fleißige Enikeyschik eine Menge Software ein, rieb den nicht zugewiesenen Speicherplatz und minimierte so die Wahrscheinlichkeit eines Erfolgs bei der Untersuchung.
In solchen Fällen kann nur ein erfahrener, sorgfältiger Analyst und eine umfangreiche, automatisch aktualisierte Threat Intelligence-Datenbank helfen. Während des Scannens des Startordners wurde die Aufmerksamkeit durch ein verdächtiges Tag erregt, das auf ein angeblich antivirales Update-Dienstprogramm hinweist:
Leider konnte der Kadaver des Trojaners von der Festplatte nicht wiederhergestellt werden, aber die Fakten zum Starten des
Remoteverwaltungsdienstprogramms aus demselben Ordner wurden im
Superfetch- Cache "zur
Schau gestellt" :
Beim Vergleich mit dem Zeitpunkt des Vorfalls haben wir bewiesen, dass nicht der Buchhalter des Gelddiebstahls schuldig war, sondern ein externer Angreifer.
Fall 2. Wer hat meine Dateien gelöscht?
Die meisten unserer Untersuchungen und Reaktionen auf Vorfälle beziehen sich auf die Erkennung von Malware, gezielte Angriffe mit Dienstprogrammen mit mehreren Modulen und ähnliche Geschichten, bei denen es einen externen Angreifer gibt. Manchmal gibt es jedoch viel profanere, aber nicht weniger interessante Untersuchungen.
Der Client hatte den gewöhnlichsten alten Dateiserver, auf dessen öffentliche Ordner mehrere Abteilungen zugreifen konnten. Auf dem Server lagen viele sehr wichtige Geschäftsdokumente, die jemand genommen und gelöscht hat. Wir haben es spät bemerkt - nachdem das Backup überlastet war. Sie begannen nach Schuldigen zu suchen.
Wenn Sie jemals versucht haben zu googeln, um festzustellen, welcher Benutzer die Datei gelöscht hat, sind Sie wahrscheinlich auf Tipps gestoßen, die alle in Windows-Protokollen enthalten sind, wenn Sie sie im Voraus richtig konfigurieren (wir haben übrigens bereits
einige Tipps dazu gegeben) Protokolle konfigurieren):
QuelleIn der Realität führen jedoch nur wenige Personen Dateisystemprüfungen durch, was kitschig ist, da viele Dateivorgänge ausgeführt werden und die Protokolle schnell ausgefranst werden und ein separater Server zum Speichern der Protokolle erforderlich ist ...
Wir haben beschlossen, die Aufgabe in zwei Teile aufzuteilen: Stellen Sie zunächst fest, WANN die Dateien gelöscht wurden. zweitens - Die WHO stellte zum Zeitpunkt der Löschung eine Verbindung zum Server her. Wenn Sie eine Vorstellung von den Funktionen von NTFS haben, wissen Sie, dass in den meisten Implementierungen dieses Dateisystems beim Löschen einer Datei der belegte Speicherplatz als frei markiert wird und sich die Zeitstempel nicht ändern. Daher kann auf den ersten Blick die Löschzeit nicht eingestellt werden.
Das Dateisystem enthält jedoch nicht nur Dateien, sondern auch Ordner. Darüber hinaus haben Ordner ein spezielles Attribut $ INDEX_ROOT, das den Inhalt des Ordners als B-Baum beschreibt. Natürlich ändert das Löschen einer Datei das Attribut $ INDEX_ROOT des Ordners und damit seine Zeitstempel, insbesondere in der Struktur von $ STD_INFO. Somit ist es möglich, die ungefähre Zeit zum Löschen einer großen Anzahl von Dateien und Ordnern durch Anomalie in der
MFT (Hauptdateitabelle) zu bestimmen:
Nachdem Sie herausgefunden haben, wann die Dateien ungefähr gelöscht wurden, können Sie versuchen herauszufinden, wer zu diesem Zeitpunkt im Norden gearbeitet hat, um den Kreis der Verdächtigen einzuschränken. Folgende Methoden kommen in den Sinn:
- Durch die Protokolle des Servers selbst - durch Ereignisse mit der Ereignis-ID 4624/4625 wird es sichtbar, wenn der Benutzer eine Verbindung herstellt und die Verbindung trennt;
- nach Domänencontrollerprotokollen - Mit EventID 4768 können Sie feststellen, dass ein bestimmter Benutzer den Zugriff auf den Server angefordert hat.
- Durch Datenverkehr - Netflow- / interne Router-Protokolle - können Sie herausfinden, wer über jdm aktiv über das Netzwerk mit diesem Server kommuniziert hat.
In unserem Fall waren diese Daten nicht mehr vorhanden: Es war zu viel Zeit vergangen, die Protokolle wurden gedreht. In diesem Fall gibt es eine andere nicht sehr zuverlässige, aber immer noch eine Methode oder vielmehr den Registrierungsschlüssel -
Shellbags . Es speichert insbesondere Informationen darüber, welche Art von Ordner der Benutzer beim letzten Besuch besucht hat: Tabelle, Liste, große Symbole, kleine Symbole, Inhalt usw. Der gleiche Schlüssel enthält Zeitstempel, die mit hoher Sicherheit als Zeitpunkt des letzten Besuchs im Ordner interpretiert werden können.
Es wurde eine Methode gefunden. Sie mussten nur noch die Register der erforderlichen Hosts sammeln und analysieren. Dazu benötigen Sie:
- Bestimmen Sie anhand der Domänengruppe, die Zugriff auf den Ordner hatte (in unserem Fall gab es ungefähr 300 Benutzer).
- Sammeln Sie Registrierungen von allen Hosts, auf denen diese Benutzer gearbeitet haben (Sie können dies einfach nicht tun, Sie benötigen ein spezielles Dienstprogramm, um direkt mit dem Laufwerk zu arbeiten, z. B. https://github.com/jschicht/RawCopy ).
- "Feed" alle Registries in Autopsy und benutze das Shellbags Plugin;
- Gewinn!
In diesem Fall fiel die Zeit zum Löschen von Dateien mit der Zeit zusammen, zu der ein Benutzer das Stammverzeichnis des gelöschten Ordners besuchte, wodurch wir den Kreis der Verdächtigen von 300 auf 1 eingrenzen konnten.
Was als nächstes mit diesem Mitarbeiter passiert ist - die Geschichte ist still. Wir wissen nur, dass das Mädchen gestanden hat, dass sie es versehentlich getan hat, und weiterhin in der Firma arbeitet.
Fall 3. Passwort-Master: "stehlen" in wenigen Sekunden (und noch schneller)
Ein Angreifer betrat das Netzwerk eines Clients, der uns über ein VPN um Hilfe bat, und wurde sofort erkannt. Kein Wunder, denn gleich nach dem Betreten begann er, das Subnetz mit einem Schwachstellenscanner zu scannen - der Chanipot blinzelte wie ein Weihnachtsbaum.
Nachdem das Konto gesperrt wurde, begann das Sicherheitspersonal des Clients, VPN-Protokolle zu analysieren, und stellte fest, dass der Angreifer mehr als 20 verschiedene Domänenkonten für die Penetration verwendet hatte (wobei die meisten erfolgreich angemeldet waren, bei einigen jedoch die Authentifizierung nicht erfolgreich war). Und die logische Frage stellte sich: Wie hat er die Passwörter aus diesen Konten herausgefunden? Unsere Mitarbeiter von JSOC CERT wurden eingeladen, nach der Antwort zu suchen.
In einem der
vorhergehenden Artikel haben wir bereits gesagt, dass in Untersuchungen Hypothesen gebildet und verifiziert werden sollten, wenn ihre Wahrscheinlichkeit abnimmt. Also haben wir diesmal angefangen, typische Kontodiebstahlvektoren zu beschreiben:
Wir haben eine Reihe von Versionen überprüft, aber nirgends gab es einen Hinweis auf einen Angriff. Nicht dass die Untersuchung in einer Sackgasse war, aber die innere Stimme und der gesunde Menschenverstand deuteten darauf hin, dass etwas nicht stimmte - Sie müssen einen Schritt zurücktreten und das Bild weiter betrachten.
Auf den ersten Blick sind alle diese Konten in keiner Weise miteinander verbunden. Ihre Eigentümer stammen aus verschiedenen, geografisch getrennten Abteilungen. Normalerweise verwenden sie einen nicht überlappenden Satz von Unternehmensdiensten. Auch der Grad der IT-Kenntnisse ist unterschiedlich. Ja, ein Schritt zurück war nicht genug - ein weiterer wurde benötigt.
Zu diesem Zeitpunkt gelang es uns, eine große Anzahl von Protokollen aus verschiedenen Unternehmenssystemen zu sammeln und die vom Angreifer hinterlassenen Spuren zu identifizieren. Sie begannen zu analysieren, wo es erschien (ich erinnere mich: Er scannte aktiv das interne Netzwerk des Unternehmens). Wir haben festgestellt, dass vor dem Hintergrund eines gleichmäßig verteilten Netzwerkrauschens durch fliegende Exploits eine ungewöhnlich große Anzahl von Anforderungen an den Kennwortwiederherstellungsdienst gestellt wird. Ein Dienst, der über das Internet zugänglich ist. Hmm ...
Wenn Sie Sicherheitsereignisse überwachen, wissen Sie wahrscheinlich, dass die Analyse von Versuchen, einen extern zugänglichen Server anzugreifen, aufgrund von Internetrauschen häufig nicht sinnvoll ist: Es ist im Allgemeinen nicht einfach, wirklich schwerwiegende Angriffe von zahlreichen Script-Kiddie-Versuchen zu unterscheiden. Aber nicht immer.
Nachdem wir einige Zeit in den Webdienstprotokollen verbracht hatten, konnten wir die folgenden Angriffe auf den Dienst herausgreifen:
- Mit Acunetix scannen
- SQLmap-Scan
- eine große Anzahl von Anfragen an eine Seite.
Der dritte Angriff ähnelt auf den ersten Blick brutalen Benutzeranmeldungen. Dies ist jedoch nicht der Fall, da der Dienst zumindest dadurch geschützt ist, dass Passwörter in einer Hash-Form mit Salt gespeichert werden - oder nicht? Es war notwendig, es schnell zu überprüfen.
Das folgende Bild zeigt ein typisches Schema des Dienstes zum Zurücksetzen des Passworts:
Es ist interessant, dass Passwörter nicht immer in einer sicheren Form gespeichert werden - es gibt einen Zeitpunkt, an dem sie gemeinfrei sind - unmittelbar nach dem Öffnen der Anwendung und vor ihrer Ausführung! Eine große Anzahl von Abfragen auf einer Seite stellte sich nicht als Brute Force und nicht als Scannen heraus, sondern als Hochfrequenzabfragen mit SQL-Injection, deren Zweck darin bestand, Kennwörter zum Zeitpunkt ihrer Änderung zu extrahieren.
Nachdem wir den Angriff auf den Dienst modelliert und die Informationen aus den Protokollen des Webservers, den Kennwortänderungsprotokollen und mehreren Netzwerkgeräten verglichen hatten, fanden wir immer noch den Durchdringungspunkt des Angreifers im Unternehmen.
Also, Kollegen, tauchen Sie in Rohdaten ein und möge die Macht bei Ihnen sein!
