Get best of the week

Untersuchung von Informationssicherheitsvorfällen in freier Wildbahn: unerwartete Informationsquellen

Bild

Es wurde viel über die Untersuchung von Computervorfällen oder Digital Forensics geschrieben. Es gibt viele vorgefertigte Hardware- und Softwaretools. Die Hauptartefakte von Betriebssystemen sind bekannt und in Handbüchern, Büchern und Artikeln beschrieben. Es scheint schwierig zu sein - lesen Sie das Handbuch und finden Sie die erforderlichen. Es gibt jedoch technisch schwierige Fälle, in denen die Analyse dieser sehr bekannten Artefakte nicht genügend Informationen liefert, um die Chronologie der Ereignisse wiederherzustellen. Wie kann man in dieser Situation sein? Wir analysieren es anhand realer Beispiele unserer Untersuchungen.

Warum fehlen generell grundlegende Artefakte? Es kann mehrere Gründe geben:

  1. Die Infrastruktur ist nicht ausreichend auf eine vollständige Überwachung und Reaktion auf Ereignisse vorbereitet (wir haben hier darüber geschrieben ).
  2. , ( Digital Forensic)
  3. , ( – , MFT-).

Wenn die Infrastruktur groß und vielfältig ist, der Vorfall sich über einen langen Zeitraum entwickelt hat und der Angreifer ein „geriebener Kalach“ ist, werden zusätzliche Informationsquellen benötigt, um alle seine Aktionen aufzudecken und die Chronologie der Ereignisse wiederherzustellen.

Je nach Situation können SIEM-Systeme, die Analyse der Netflow-Netzwerkflüsse oder des Rohdatenverkehrs (obwohl dies in 90% der Fälle in der Realität nicht möglich ist) sowie ungewöhnliche Artefakte, die sich auf Software von Drittanbietern beziehen, zufällig Abhilfe schaffen. in der Infrastruktur des Kunden.

Es ist die letzte Art von Artefakten, die wir stoppen werden.

Ivanti Endpoint Manager (ehemals LANDESK Management Suite). IT Asset Management System

www.ivanti.ru/company/history/landesk Im

Zusammenhang mit der Überwachung eines unserer neuen Kunden haben wir in seiner Infrastruktur die Bereinigung von Ereignisprotokollen auf einem der Server festgestellt, während im SIEM-System keine anderen Manifestationen böswilliger Aktivitäten aufgetreten sind. Während der Analyse wurde festgestellt, dass der Server kompromittiert war und der Angreifer spezielle Ausrüstung verwendete, um unbemerkt zu bleiben. Es bestand aus folgenden:

  1. Sicherheitsprotokollereignisse wurden in eine separate temporäre Datei umgeleitet.
  2. ein Angreifer führte die notwendigen Aktionen aus,
  3. Ereignisse werden zurück in das Sicherheitsprotokoll umgeleitet.
  4. temporäre Datei wurde gelöscht.
  5. Profitieren!

Trotz der Tatsache, dass das Sicherheitsjournal ordnungsgemäß eingerichtet wurde, enthielt es keine Ereignisse im Zusammenhang mit böswilligen Aktivitäten, während es selbst unberührt aussah.

Nach einer kurzen Analyse stellten wir fest, dass der Angreifer seit etwa 2-3 Jahren in der Infrastruktur "lebt", wodurch alle wichtigen Server kompromittiert werden konnten. In solchen Fällen steigt der Wert zusätzlicher Informationsquellen, da einige grundlegende Artefakte entweder ausgefranst oder nicht informativ sind und kein vollständiges Bild des Vorfalls ermöglichen.

Auf der Suche nach zusätzlichen Informationsquellen führten wir eine mündliche Bestandsaufnahme der in der Infrastruktur verwendeten Dienste und Systeme durch und stellten fest, dass der Kunde zusammen mit der Implementierung unserer Überwachung mit der Bereitstellung eines IT-Asset-Management-Systems begann
Ivanti Endpoint Manager.

Da das System immer noch instabil war (Ereignisse von Agenten wurden nicht teilweise
an den Server gesendet), konnten wir Ereignisse von den Hosts auf dem Server nicht zentral anzeigen. Nachdem wir uns entschlossen hatten, nach Artefakten zu suchen, die von Ivanti Endpoint direkt auf dem Host gespeichert wurden, stellten wir fest, dass diese Software Informationen zu Prozessstarts lokal im folgenden Registrierungszweig speichert:

HKLM \ SOFTWARE \ Wow6432Node] \ LANDesk \ ManagementSuite \ WinClient \ SoftwareMonitoring \ MonitorLog \ < Der Pfad zur ausführbaren Datei>

Die folgenden Informationen werden in den entsprechenden Schlüsseln gespeichert:

  • erste Startzeit (im FILETIME-Format)
  • letzte Laufzeit (im FILETIME-Format)
  • Anzahl der Starts
  • Benutzer mit Rechten, für die die ausführbare Datei gestartet wurde


Ivanti Endpoint-Prozessstartartefakte

Dank dieser Informationen konnten wir den Zeitpunkt des Auftretens des Angreifers auf einigen bisher nicht bekannten Systemen bestimmen. Darüber hinaus wurde ein Teil seines Toolkits ausschließlich anhand des Namens ausführbarer Dateien veröffentlicht.

Citrix NetScaler System für den Zugriff auf Unternehmensressourcen und -anwendungen

www.citrix.com/en-us/products/citrix-adc


Citrix NetScaler Workflow

Eine weitere interessante Untersuchung. Ein Angreifer ist über ein VPN in die Infrastruktur des Unternehmens eingetreten. Er arbeitete in der Zeitzone UTC +8. Nach der Authentifizierung verhielt es sich ziemlich aggressiv (aktiv gescannte interne Subnetze mit der Maske / 24 und / 16), wodurch es tatsächlich bemerkt wurde.

Das VPN wurde auf dem Citrix NetScaler Enterprise Resource and Application System konfiguriert. Nachdem wir die Protokolle untersucht hatten, konnten wir den Zeitpunkt des ersten „Besuchs“ (Datum des Kompromisses), die vom Angreifer verwendeten Mitarbeiterkonten (übrigens wurden mehr als 5 Konten kompromittiert) und die IP-Adressen der Proxyserver ermitteln, von denen aus er arbeitete.

Die Untersuchung selbst endete erfolgreich: Wir konnten die Quelle des Kompromisses ermitteln - es stellte sich heraus, dass das interne System zum Zurücksetzen von Anmeldeinformationen, auf die über das Internet zugegriffen werden kann, einer SQL-Injection unterlag.

Aber jetzt möchte ich noch etwas anderes beachten: Nach dem Bestehen der VPN-Authentifizierung unter Citrix NetScaler wurden alle HTTP-Benutzeranforderungen erfolgreich protokolliert. Der Angreifer wusste dies wahrscheinlich entweder nicht oder verwirrte seine Netzwerkschnittstellen und schickte seine eigenen Anfragen über das Unternehmensnetzwerk des Kunden an Suchmaschinen. Auf diese Weise konnten wir Informationen über die für den Angreifer interessanten Systeme, seine Kompetenzen und die verwendeten Tools erhalten.


Citrix NetScaler-Protokolldatei


Informationen, nach denen ein Angreifer über Citrix NetScaler gesucht hat


Informationen, nach denen ein Angreifer über Citrix NetScaler gesucht hat

Geheimes Netzstudio. System zum Schutz von Informationen vor unbefugtem Zugriff

www.securitycode.ru/products/secret_net

Eines schönen Tages fiel ein Ticket mit einem verdächtigen Authentifizierungsvorfall in unserer ersten Zeile unter dem Konto eines IT-Mitarbeiters des Unternehmens auf dem Verwaltungsserver in der Nacht (der Mitarbeiter war zu diesem Zeitpunkt im Urlaub, er hatte ein VPN hatte nicht). Architektonisch befand sich der Administrationsserver zusammen mit mehreren anderen Schlüsselservern des Unternehmens (einschließlich des Secret Net-Servers) in einem separaten Netzwerksegment, während SIEM nur Ereignisse vom Administrationsserver selbst erhielt (Kunden stimmen leider nicht immer zu, alle potenziellen Quellen zu verbinden )

Die erste Zeile, in der das Ticket verarbeitet und Informationen darüber gesammelt werden, was nach der Authentifizierung passiert ist, stößt auf verschiedene verdächtige Prozessstarts (nicht standardmäßige Pfade, binäre Dateinamen in einem Buchstaben) und den Start von mstsc.exe, was auf eine mögliche RDP-Sitzung hinweist.

Als wir erkannten, dass dies ein potenzieller Kompromiss war, forderten wir Images aller Server an
und begann ihre Analyse. Beim Öffnen des ersten Images (Secret Net-Server) erhielten wir eine „große Überraschung“ als Geschenk: Die System-, Sicherheits- und Anwendungsprotokolle wurden gelöscht und entfernt, sodass selbst Wiederherstellungsversuche erfolglos blieben. Es konnte nur verglichen werden, dass die Einträge in den TerminalServices-Protokollen des SecretS-Servers zeitlich mit dem Start von mstsc.exe auf dem Administrationsserver zusammenfielen, was bedeutet, dass sich der Angreifer definitiv im Secret Net befand. Die Analyse der verbleibenden Server ist ebenfalls fehlgeschlagen.

Infolgedessen befanden wir uns in einer Situation, in der mit Sicherheit bekannt ist, dass der Angreifer dort ist (er hat definitiv etwas getan und gestartet), aber wir haben keine Hostprotokolle, da die Traces gelöscht werden
und keine Netzwerkprotokolle vorhanden sind, da sich alle Server im selben Subnetz befinden.

Auch aus dieser Situation wurde eine Lösung gefunden. Das Secret Net-System ist sehr vielseitig und besteht aus vielen Komponenten, sowohl auf Kernel- als auch auf Benutzerebene. Nachdem wir jede Protokolldatei analysiert hatten, die von verschiedenen Komponenten von Secret Net aufgezeichnet und gespeichert wurde, stießen wir auf einige hervorragende Artefakte, die durch die Dateikontrolle entstanden sind. Als wir alles zusammengestellt haben, haben wir Informationen über die Aktionen des Angreifers (er war wirklich auf jedem Server dieses Subnetzes) und über seine Tools erhalten.

Übrigens haben die erhaltenen Informationen dazu beigetragen, die Anwesenheit eines Angreifers in der Infrastruktur vollständig zu beseitigen.


Schema eines Angreifers, der über die Secret Log Studio- Dateisteuerungsdatei des Secret Net Studio-Servers arbeitet




KVRT. Kostenloses Antiviren-Tool

www.kaspersky.ru/downloads/thank-you/free-virus-removal-tool

Wir wurden kontaktiert, um Hilfe bei der Untersuchung eines Vorfalls im Zusammenhang mit ausgehenden böswilligen Aktivitäten (Botnet- und Miner-Aktivitäten) von den öffentlichen Adressen des Unternehmens zu erhalten. Nachdem wir die Bilder und Protokolle des Systems erhalten hatten, begannen wir mit der Analyse und fanden einige Artefakte, die auf einen Kompromiss zwischen dem öffentlichen Webdienst des Unternehmens und den verbleibenden schädlichen Dateien hinweisen. Leider reichte dies nicht aus, um alle vom Kunden gestellten Fragen zu beantworten: Unter anderem fanden wir keine Dateispuren des Bergmanns, obwohl es zwischen der Behebung böswilliger Aktivitäten und unserer Untersuchung einige Zeit dauerte.

Wir kehrten noch einmal zu den Artefakten und Protokollen zurück und machten auf die Spuren mehrerer kostenloser Antivirenscanner aufmerksam. Es wurde deutlich, dass die fehlenden Dateien verschlüsselt und unter Quarantäne gestellt wurden und die Zeitstempel des Dateisystems sicher gelöscht wurden.

Unter den verwendeten Scannern befand sich KVRT, das einige schädliche Dateien erkannte und unter Quarantäne stellte. Der Standardspeicherort für Quarantänedateien ist C: \ KVRT_Data \ Quarantäne, und das Entschlüsseln ist sehr einfach: Ein einfaches XOR mit einem bekannten Schlüssel ist e2 45 48 ec 69 0e 5c ac.


Entschlüsselte KVRT-Quarantäne

Wie sich später herausstellte, gelang es dem IT-Administrator vor unserer Ankunft, das System mit kostenlosen Antivirenscannern zu scannen, obwohl empfohlen wurde, nichts zu berühren.
Infolgedessen haben unter Quarantäne gestellte Dateien dazu beigetragen, Lücken in der Chronologie der Ereignisse zu schließen und alle Fragen zu beantworten.


Jede Untersuchung ist immer etwas Ungewöhnliches, Einzigartiges und Vielseitiges. Ja, es sind Artefakte von Betriebssystemen bekannt, aber bevor die Untersuchung beginnt, ist es schwierig, die Vollständigkeit der Informationen vorherzusagen, die nach ihrer Analyse erhalten werden können. Daher empfehlen wir Ihnen, vor einer technischen Untersuchung des Vorfalls eine Bestandsaufnahme der Software und Systeme vorzunehmen und diese nicht als mögliche Quelle für die Untersuchung zu untersuchen.

More articles:


All Articles