"Aber es ist nicht langweilig!" - so lautet das informelle Motto der Mitarbeiter unseres Solar JSOC Cyber Threat Monitoring Centers (und ich muss sagen, dass 2019 voll und ganz dem entsprach). Zu Beginn des neuen Jahres ziehen viele Leute gerne Bilanz und setzen sich neue Ziele. Stattdessen haben wir beschlossen, ein paar „Schrecken unserer Stadt“ zu erzählen - die Fälle von 2019, die selbst erfahrene Analysten beeindruckten. Die Schlussfolgerung aus diesen Geschichten ist nur eine: Technologie entwickelt sich und entwickelt sich weiter, und menschliche Faulheit, Nachlässigkeit und Nachlässigkeit sind ewig.
Gast Wifi
Bei der Verbindung von Kunden mit der Überwachung werden zunächst die wichtigsten Informationen abgefragt: kritische Konten, Domänengruppen, nicht vertrauenswürdige Segmente, weiße Adressen, DMZ, kritische Subnetze usw. Nicht vertrauenswürdige Subnetze sind nur Gast-Wi-Fi-Netzwerke sowie Subunternehmer-Netzwerke, Test-Segmente mit Berechtigungen zum Zulassen beliebiger, usw. ... Normalerweise sehen wir, dass die Möglichkeit der Interaktion mit solchen Segmenten nicht vorhanden oder stark eingeschränkt ist, da sie gesteuert werden sehr schwierig, wenn nicht unmöglich. Im Kundennetzwerk gab es keine Möglichkeit für solche Interaktionen, mit Ausnahme der Autorisierungsseite im Gastnetzwerk. Wir haben uns beruhigt, indem wir die Interaktion von Wi-Fi mit TOR, C & C-Servern und anderen bösen Geistern verboten haben, damit wir nicht mit Vorgängen bombardiert werden, an denen der potenzielle Kunde nicht interessiert war (obwohl wir immer noch Statistiken zu diesen Vorfällen für zusammenfassende Berichte gesammelt haben). Und am dritten Morgen des Pilotprojekts stellten wir eine Anomalie fest: Der Ereignisfluss von der Firewall hat sich vervierfacht!
Sie begannen, nach der Ursache der „Blockade“ zu suchen und fanden sie überraschenderweise im Segment des WLANs für Gäste. Ein bestimmter Host erzeugte 4 Millionen (!) Events pro Stunde. Und die Ereignisse sind ziemlich interessant - Verbindungen über Port 445 zu zufälligen weißen Adressen des Internetraums. Vier Millionen, Karl!
Nachdem sie den Kunden darüber informiert hatten, warteten sie auf Informationen über den Host und den Vorfall, da DHCP (dies ist der Autorisierungsserver) nicht mit SIEM verbunden war. Nach ca. 3-4 Stunden meldete der Kunde, dass der Host ein Mobiltelefon ist. Zu sagen, dass wir überrascht waren, heißt nichts zu sagen. Ein gewöhnliches Mobiltelefon kann einen solchen Ereignisstrom nicht erzeugen. Sie begannen, die Details herauszufinden, und es stellte sich heraus, dass das Mobiltelefon nichts damit zu tun hatte - jemand benutzte nur eines der registrierten Geräte als Abdeckung. Es war nicht möglich, die wahre Quelle der Aktivität zu finden, und unser Kunde sagte, dass er an diesem Fall nicht interessiert sei, sodass die Aktivität minimiert werden musste. Trotzdem haben wir die Spezialisten des Kunden vor möglichen Risiken gewarnt: Da die (offensichtlich böswillige) Aktivität von ihren Adressen ausgeht, können sie beispielsweise in die Listen der C & C-Server von Antiviren-Anbietern aufgenommen werden und Beschwerden von Strafverfolgungsbehörden erhalten (wer weiß, welche Infrastruktur dieser Host scannt) - Schließlich kann es KII geben, und das Scannen nach Schwachstellen bezieht sich auf Vorfälle, die an GosSOPKA gemeldet werden müssen. Nach solchen Argumenten entschied sich der Kunde immer noch, unsere Empfehlungen genauer zu verstehen und zu erfüllen. Und sie waren wie folgt:
- schließe alle Ports außer 80 und 443 (dies stellte sich als die richtige Entscheidung heraus, da nach 445 ein Scan auf Port 22 folgte),
- Wir begrenzen die Geschwindigkeit des ausgehändigten Internets.
- Aktivieren Sie UTM-Chips, einschließlich der Anwendungssteuerung, und schneiden Sie seltsame Kategorien wie Torrents, TOR-Browser, erkannte Scanner und mehr aus.
- Aktivieren Sie das Limit für die Anzahl der Verbindungen pro Zeitintervall.
Der Kunde konnte nie herausfinden, wer dieser aktive Wi-Fi-Benutzer war, aber er wurde zumindest mit Sauerstoff blockiert (und der Angreifer suchte höchstwahrscheinlich nach dem nächsten verfügbaren Wi-Fi.
Einige Monate später wurde dieses Pilotprojekt erfolgreich abgeschlossen und in den Vertrag übernommen. Es gibt jedoch immer noch ähnliche Fälle in völlig unterschiedlichen Unternehmen, sodass die obigen Empfehlungen als universell eingestuft werden können.
Standardmäßig oder Hersteller Sabotage
Parallel zur Pilotverbindung zur Solar-JSOC-Überwachung hat der Kunde eine neue UTM in Betrieb genommen. Die Migration wurde schrittweise durchgeführt: Zuerst wurde die ACL über die Subnetze übertragen, dann die Anwendungsrichtlinien. Das Dessert ist das interessanteste.
Alles geschah nach dem Vorbild der Klassiker - am Freitagabend. In der ersten Zeile wurden Pannen bei der Kontaktaufnahme mit der Kundeninfrastruktur für TOR-Knoten verzeichnet, die in einer der FinCERT-Mailinglisten als C & C angezeigt wurden. Da es sich bei dem Projekt um ein Pilotprojekt handelte und der Kunde alle Vorfälle auf Low-Criticality umstellte, war neben der Benachrichtigung per Post keine Vorfallkarte vorgesehen. Daher wurde der erste Vorgang von verschiedenen Hosts an eine Adresse nicht weiter eskaliert, obwohl er bei den Überwachungsingenieuren Verdacht erweckte. Als die Anzahl der Fahrten drei erreichte, ahnten die Jungs, dass etwas nicht stimmte, und informierten den Analysten, der den Vorfall zur Arbeit mitnahm.
Zunächst kontaktierte der Analyst die verantwortlichen Mitarbeiter des Kunden und schlug vor, Hosts auf lokaler Protokollebene zu verbinden, um die Quelle der Aktivität zu identifizieren. Zum Zeitpunkt der Diskussion mit den Spezialisten des Kunden war die Anzahl der Hosts auf 7 angewachsen. Die Situation war der Epidemie sehr ähnlich, aber das Virenschutzprogramm auf den Hosts funktionierte und war stumm, es gab keine aktiven Aktionen und Hostinteraktionen im Netzwerk.
Durch das Verbinden von drei Hosts auf lokaler Protokollebene konnte auch nicht verstanden werden, welcher Prozess die Aktivität erzeugte. Die Angst wuchs, die einzige funktionierende Option war die Isolierung von Hosts mit der parallelen Entfernung eines RAM-Dumps und des Images der Festplatte. Der Analyst begann, Anweisungen vorzubereiten, und entschied sich gleichzeitig, die IP-Adresse zu googeln, auf die die Hosts zugegriffen hatten, um die Verfügbarkeit in anderen Mailings und Vorfällen zu überprüfen (da sich die Art der beobachteten Aktivitäten von der im FinCERT-Newsletter beschriebenen unterscheidet). Zum größten Teil ist die Idee ziemlich miserabel, aber diesmal nicht.
Es wurde auf den Artikel hingewiesen, in dessen Titel die IP-Adresse und der Name des UTM-Anbieters aufgeführt sind. Um das Wesentliche der Veröffentlichung zusammenzufassen, kaufte der Anbieter eine IP-Adresse, die zuvor zum TOR-Knoten gehörte und die im FinCERT-Newsletter vorgestellt wurde. Und das ist nicht nur alles! Darüber hinaus hat der Anbieter beschlossen, diese Adresse als Standard festzulegen, um alle verdächtigen Anrufe von der Infrastruktur seiner Kunden an potenziell böswillige Adressen umzuleiten. Das heißt, jede Verbindung mit einer fremden IP-Adresse wurde von UTM als unzulässig interpretiert und an diese wundersame Adresse umgeleitet.
Nachdem festgelegt wurde, ob das Anti-Malware-Schutzmodul bereits aktiviert ist, und eine Bestätigung erhalten wurde, atmeten der Analyst und die Spezialisten des Kunden aus.
PS Die Analyse der von UTM erkannten Fehler bestätigt, dass alle 7 Aktivitäten falsch positiv waren.
Wir haben für jeden Fall Empfehlungen versprochen, aber hier geben wir vielleicht nur eine an: Nicht am Freitag einsetzen. Und warne alle Interessierten und Sympathisanten.
Historisch gesehen
Dieses Leitmotiv bringt eine Vielzahl von Fällen zusammen. Nehmen Sie zum Beispiel die Außerbetriebnahme. Oftmals werden Prozesse, die in Unternehmen an Relevanz verloren haben, einfach vergessen: Niemand "analysiert" die alte Infrastruktur und hinterlässt die alten virtuellen Maschinen, Server und Netzwerkzugriffe. Gleichzeitig überwacht niemand Updates, Virenschutzprogramme und Ereignisse auf diesen Hosts, und selbst Administratoren kennen die Eigentümer der Systeme häufig nicht. Daher bieten solche Infrastrukturelemente nach einer Weile nicht die angenehmsten Überraschungen. Was kostet es nur, signifikante Telemetrie von einer Umweltorganisation in einem 2005 abgeschlossenen Projekt an FTP-Server eines nicht-freundlichen Landes zu senden?
Oft befasst sich niemand mit der Wartung von 10 Jahre alten Systemen, obwohl sie weiterhin verwendet werden. Ein Portal zum Zurücksetzen von Passwörtern, das die alte Engine verwendet und den Benutzern die Arbeit erleichtert, betrachtet beispielsweise das Internet oder RDP, das der Auftragnehmer zum Konfigurieren von Geschäftsanwendungen benötigt und das sich für 5-6 Jahre auszeichnet.
Das Vorhandensein solcher Probleme wird normalerweise bekannt, wenn:
- Der Host wurde gehackt und die Verschlüsselung erfolgte mit weiterer Erpressung (in letzter Zeit gab es viele solcher Vorfälle).
- Es findet eine Migration von einer Lösung auf dem Perimeter zu einer anderen statt.
- wir kommen zum pilot und sammeln das profil der offenen ports am umfang.
Aber es gibt auch völlig mythische Situationen: 2013 baute das Unternehmen einen Tunnel mit einem Auftragnehmer, der sein Finanzsystem bedient. Der Vertrag endete, aber der Tunnel blieb bestehen, da er von dem Unternehmen hergestellt wurde, von dem der Auftragnehmer die Räumlichkeiten zusammen mit der IT-Infrastruktur gemietet hatte. Eine neue Firma nahm den gleichen Platz ein und war überrascht, verfügbare Adressen der Infrastruktur anderer Leute zu finden. Neugierde übernahm und dann Versuchung und Durst nach Profit. Sie stellten eine Datenbank mit Gegenparteien und Verträgen zum Lärm ab - der Vorteil des Wettbewerbs war interessant, aber niemand machte Lärm in der Opferfirma. Die Geschichte dauerte mehr als ein Jahr (es war nicht möglich, die Protokolle weiter zu verfolgen), aber am Ende sind die Ermittlungen, die Entlassungen und die Kirsche auf dem Kuchen eine kriminelle Angelegenheit.
AWOL oder Weil es bequemer ist
Der gesamte Fall ist eher trivial, was sich nicht auf die "Implementierungsmethodik" beziehen lässt.
Gegeben:
- Pilotprojekt zur Kundenüberwachung;
- verbundene Quellen auf dem Perimeter sowie zwischen dem Unternehmens- und dem Technologiesegment;
- diensthabender Administrator am Arbeitsplatz und für das geschlossene Netzwerksegment;
- Der Administrator möchte unbedingt weniger arbeiten, mehr schlafen und alles bequem erledigen.
Wie ich bereits sagte, bitten wir den Kunden beim Herstellen einer Verbindung um verschiedene Informationen, einschließlich weißer Adressen, um Statistiken über Verbindungen aus dem Internet zu sammeln und so ein Profil für den Außenumfang zu erstellen. Nachdem wir eine Regel erstellt haben, die die Liste in SIEM ausfüllt, erfassen wir in ein oder zwei Wochen Statistiken über alle offenen Ports am Perimeter, entladen sie an den Kunden, beobachten und reparieren sie gemeinsam (während wir das Unzulässige schließen). Wir sammelten Informationen für das Profil und gingen die Liste in regelmäßigen Abständen durch. Dabei stellten wir sicher, dass die Ports für alle oder nur einige Adressen auf weißen Listen geöffnet sind. Es wurde auf den Port 43388 hingewiesen, der unauffällig zu sein schien, aber 3389 ausgestrahlt wurde und dessen graue Adresse uns damals unbekannt war.
Beim Check stellte sich heraus, dass es für unsere Adressen geschlossen ist. Wir dachten, dass er auf weißen Listen steht, aber tagsüber konnten wir keine erfolgreichen Verbindungen zu ihm feststellen. Als sie am nächsten Morgen ankamen, bemerkten sie erneut, dass über Nacht ein Paket von Ereignissen eingetroffen war. Dieses Mal haben wir uns die Quellenadressen genauer angesehen und mehrere Sitzungen aus Moskau mit einer Gesamtdauer von mehr als 5 Stunden und eine große Anzahl von kurzen Sitzungen aus der ganzen Welt gesehen. Dann wurde klar, dass der Hafen nicht nur für Adressen von der weißen Liste zugänglich war, sondern dass er nur nachts geöffnet war - von ungefähr 00.00 bis 06.00 Uhr morgens. Nach dem Ausgraben der Protokolle von der Domäne und dem Antivirus (sie waren zu diesem Zeitpunkt gerade verbunden) stellte sich überraschend heraus, dass die Adresse dem diensthabenden Administrator gehört, der in diesem Zeitraum am Arbeitsplatz sein sollte! Nachdem wir die Verbindungen von seinem Auto aus analysiert hatten, fanden wir eine weitere interessante Situation: Jeden Abend öffnete sich der Hafen im geschlossenen Segment (ich denke, es ist nicht schwer zu erraten, welchen). Es ist fast unmöglich, eine solche Aktivität am vierten Tag des Piloten zu bemerken, da zu diesem Zeitpunkt die Anzahl der zulässigen Verbindungen zwischen Segmenten immer noch mehr als die Anzahl der offenen Ports am Perimeter beträgt. Nachdem sie die Sicherheitspersonal über die Situation informiert hatten, verbanden sie den Host auf lokaler Protokollebene und stellten sicher, dass der Administrator leise von der Arbeit nach Hause floh. Wie sich herausstellte, lebte er fast in einem Nachbarhaus, und die Fernverbindung wurde natürlich zu einer Versuchung.
Wenn der Administrator die Situation umreißt, kann er möglicherweise über die SKDPU aus der Ferne arbeiten, vorausgesetzt, dass er zum Zeitpunkt des Unfalls innerhalb von 15 Minuten zur Arbeit kommen kann und es überhaupt keine Probleme gibt.
Total
In Wirklichkeit besteht eine der Hauptbedrohungen für die Informationssicherheit darin, sich vor Ort zu verbauen. Minimieren Sie daher die Risiken:
- Verfolgen Sie die Perimeter- und Firewall-Konfigurationen.
- Versuchen Sie, die Fernbedienung in einem Unternehmen zu verwalten (VPN über einen Terminalserver). Und wenn es bereits vorhanden ist, können Sie steuern, wer es verwendet (indem Sie verschiedene RATs auf Hosts entfernen, die jetzt fast alle Antiviren-Engines problemlos erkennen).
- Verfolgen Sie die Aktionen privilegierter Benutzer: Sehr oft verlieren sie die Wachsamkeit, weil sie glauben, alles unter Kontrolle zu haben, und erleichtern Angreifern den Zugriff auf wichtige Daten.