IBo nefig: Die besten Angaben zur Cybersicherheit im Jahr 2020 laut JSOC

Das erste Halbjahr geht zu Ende und wir haben beschlossen, uns an die interessantesten Fälle aus dem Leben von JSOC zu erinnern, die wir in diesem Jahr erlebt haben. Ein Treffen mit einem Cyberkriminellen eines "alten Freundes" bei einem neuen Kunden, ein bösartiges Skript im Taskplaner und das Rätsel der Balancer-Konfigurationskurve - wir lesen und durchdringen den Schnitt.





Aufnahme aus der Serie South Park

Wir haben ihn an seiner Handschrift erkannt

Während der Existenz von JSOC waren wir mit unterschiedlichen IT-Infrastrukturen und unterschiedlichen Kundenwünschen konfrontiert, um ihre IT-Landschaft mit Überwachung abzudecken. Es kommt beispielsweise häufig vor, dass ein Kunde nur die Server überwachen möchte, um sich die Möglichkeit zu nehmen, zu sehen, was um das überwachte Segment herum geschieht. Dieser Ansatz kann zu einer späten Angriffserkennung führen, wenn der größte Teil der Infrastruktur bereits gefährdet ist. Und wenn unsere bestehenden Kunden solche Situationen nicht haben, ist dies bei Pilotprojekten eine häufige Geschichte.



Während eines der Pilotprojekte war der Kunde dabei, seine eigene IT-Landschaft neu aufzubauen, und wollte wissen, wie sich der SOC in seine neue Infrastruktur und Prozesse einfügt. Aufgrund verschiedener Umstände, auf die wir keinen Einfluss hatten, war keine einzige Netzwerkquelle angeschlossenkapets, wie sehr es uns bei der Aufdeckung verschiedener Vorfälle einschränkte. Es wurden nur ein Domänencontroller, einige Windows-Server, ein Mailserver und ein Antivirenprogramm verbunden. Der Pilot verlief recht ruhig und war für uns Standard: In der Infrastruktur wurden mehrere Malware entdeckt, TOR verwendet und RATs verboten. Aber eines schönen Tages begann eine große Anzahl unserer Regeln zu funktionieren, darunter Regeln aus der Kategorie Bedrohungsjagd, die den Prozess der Identifizierung der Spuren eines Eindringlings automatisieren. Der verantwortliche Analytiker erkannte schnell, dass der Fall nach Kerosin roch, und erkannte sogar, mit wem er es zu tun hatte.



Was ist passiert? Das erste, was wir sahen, war das Hinzufügen neuer Konten zur Gruppe der Domänenadministratoren. Aber eine weitere Regel hat funktioniert, nämlich der verdächtige Name der Konten, auf die wir bereits gestoßen sind. Ein alter Bekannter von uns, ein Angreifer, erstellt bei Angriffen zwei Konten, die in seinem Skript geschrieben sind: Diese beiden Namen "wandern" von einem Opfer zum anderen - eine kleine Änderung kann nur durch die Regeln für die Benennung von Konten der angegriffenen Organisation verursacht werden. Wir haben ihn viele Male getroffen, als wir Vorfälle untersucht haben. Es greift Unternehmen aller Größen und Branchen mit derselben Methode an und verschlüsselt in der Regel die Schlüsselserver des Unternehmens.



Leider befand sich der erste kompromittierte Computer außerhalb des Bereichs verbundener Quellen, sodass der Zeitpunkt des Starts des Skripts selbst nicht aufgezeichnet werden konnte. Nach der Erstellung der Konten haben wir eine Regeländerung in der lokalen Firewall erfasst, die die Verwendung eines bestimmten Remoteverwaltungstools ermöglichte, und anschließend wurde der Agentendienst dieses Tools erstellt. Das vom Kunden verwendete Antivirenprogramm erkennt dieses Tool übrigens nicht. Daher steuern wir es, indem wir den entsprechenden Dienst erstellen und den Prozess starten.







Das Wichtigste war die Verteilung eines legalen Verschlüsselungsprogramms an kompromittierte Hosts. Er hatte keine Zeit, es auf alle Hosts hochzuladen. Der Angreifer wurde 23 Minuten nach der ersten Auslösung dieses Vorfalls aus der Infrastruktur „geworfen“.



Natürlich wollten der Kunde und ich uns ein vollständiges Bild von dem Vorfall machen und den Einstiegspunkt für den Angreifer finden. Aufgrund unserer Erfahrung haben wir Protokolle von Netzwerkgeräten angefordert, aber leider konnten wir aufgrund der Anmeldestufe keine Schlussfolgerungen ziehen. Nachdem wir jedoch die Konfiguration der Edge-Netzwerkgeräte von den Administratoren erhalten hatten, sahen wir Folgendes:



IP-Adresse innerhalb der statischen Quell-TCP "graue Adresse" 22 "weiße Adresse" 9922

IP- Adresse innerhalb der statischen Quell-TCP "graue Adresse" 3389 "weiße Adresse" 33899



Daraus wurde geschlossen, dass höchstwahrscheinlich einer der Server, auf denen ein solches NAT konfiguriert war, zum Einstiegspunkt wurde. Wir haben die Protokolle dieser Server analysiert und eine erfolgreiche Authentifizierung unter dem Administratorkonto festgestellt. Dabei wurde Mimikatz gestartet und anschließend ein Skript gestartet, mit dem Domänenadministratoren erstellt wurden. Durch diesen Vorfall nahm der Kunde eine vollständige Überarbeitung der Firewall-Regeln, Kennwörter und Sicherheitsrichtlinien vor und identifizierte mehrere weitere Fehler in seiner Infrastruktur. Außerdem habe ich ein systematischeres Verständnis dafür erhalten, warum der SOC in seiner Organisation benötigt wird.

Remote- und Home-Router - Hacker-Paradies

Unter den Bedingungen von Unternehmen, die auf Fernsteuerung umsteigen, ist es offensichtlich viel schwieriger geworden, Ereignisse auf Endgeräten zu überwachen. Es gibt zwei Hauptgründe:

1. Eine große Anzahl von Mitarbeitern verwendet persönliche Geräte für die Arbeit.
2. VPN , .

Es ist auch eine offensichtliche Tatsache, dass sich selbst erfahrene Angreifer für Heimnetzwerke interessiert haben, da dies nun der ideale Punkt für das Eindringen in den Unternehmensbereich ist.



Einer unserer Kunden hatte 90% der Mitarbeiter in den Remote-Arbeitsmodus versetzt, und alle hatten Domain-Laptops - daher konnten wir die Endgeräte weiterhin überwachen - natürlich unter Berücksichtigung von Punkt 2 oben. Und genau dieser Punkt hat gegen uns gespielt.



Einer der Benutzer stellte während der Selbstisolation fast einen ganzen Tag lang keine Verbindung zum VPN her. Am Ende des Arbeitstages benötigte er noch Zugang zu Unternehmensressourcen. Er benutzte ein VPN, wir holten die Protokolle von seiner Arbeitsmaschine und sahen etwas Seltsames. In Task Scheduler wurde eine verdächtige Aufgabe erstellt: Jeden Mittwoch um 17:00 Uhr wurde eine bestimmte Datei gestartet. Sie begannen zu verstehen.







Die Traces führten zu zwei Dokumentdateien: Eine davon erstellte die Aufgabe, die zweite war die ausführbare Datei in der Aufgabe. Der Nutzer hat sie von Google Drive heruntergeladen.



In dieser Phase unserer Suche war der Sicherheitsdienst des Kunden bereits verbunden und leitete eine interne Untersuchung ein. Es stellte sich heraus, dass der Nutzer einen Brief an seine persönliche E-Mail erhielt, die einen Link zu Google Drive enthielt, von dem die Dokumente heruntergeladen wurden. Allmählich erreichten wir den Router des Benutzers - natürlich war das Login / Passwort dafür admin \ admin (als ob es anders wäre?). Das Interessanteste wurde jedoch in den Einstellungen des DNS-Servers des Routers gefunden: Dort wurde die IP-Adresse eines der europäischen Länder angegeben. Wir haben diese Adresse in VirusTotal übernommen - die meisten Quellen leuchten rot. Nach dem Ende der Untersuchung schickte uns der Kunde zwei Dateien zur Recherche, und wir stellten fest, dass die von der Aufgabe gestartete Datei verschiedene Verzeichnisse durchlief und Daten von dort herunterlud.



Die Chronologie des Vorfalls war wie folgt: Der Angreifer erhielt Zugriff auf den Router des Benutzers, änderte die darin enthaltenen Einstellungen und gab seinen eigenen Server als DNS-Server an. Einige Zeit beobachtete ich mein "Opfer" und schickte einen Brief an die persönliche Mail des Benutzers. In diesem Schritt haben wir es gefunden und konnten nicht tief in die Unternehmensinfrastruktur eindringen.

Sie brechen auch ihre

In der Anfangsphase der Arbeit mit einem ausgelagerten SOC empfehlen wir immer, Ereignisquellen schrittweise zu verbinden, damit der Kunde auf seiner Seite die Prozesse debuggt, die Verantwortungsbereiche klar definiert und sich im Allgemeinen an dieses Format gewöhnt. Bei einem unserer neuen Kunden haben wir zunächst grundlegende Quellen wie Domänencontroller, Firewalls, Proxys, verschiedene Tools für die Informationssicherheit, E-Mail-, DNS- und DHCP-Server sowie verschiedene andere Server miteinander verbunden. Wir haben auch angeboten, die Maschinen der Administratoren der Zentrale auf der Ebene der lokalen Protokolle anzuschließen, aber der Kunde sagte, dass dies bisher unnötig ist und er seinen Administratoren vertraut. Hier beginnt tatsächlich unsere Geschichte.



Eines Tages kamen keine Ereignisse mehr zu uns. Wir haben vom Kunden erfahren, dass sein Rechenzentrum angeblich aufgrund eines groß angelegten DDoS-Angriffs "gefallen" ist und er sich nun mit der Wiederherstellung beschäftigt. Dies warf sofort viele Fragen auf - schließlich war das DDoS-Schutzsystem mit uns verbunden.



Die Analytikerin fing sofort an, in ihren Protokollen zu stöbern, fand dort aber nichts Verdächtiges - alles war im normalen Modus. Dann schaute ich mir die Netzwerkprotokolle an und machte auf die seltsame Arbeit des Balancers aufmerksam, der die Last auf zwei Server verteilte, die eingehenden Datenverkehr verarbeiten. Der Load Balancer hat die Last nicht verteilt, sondern im Gegenteil nur an einen Server weitergeleitet, bis sie "verstopft" war, und erst dann den Datenfluss an den zweiten Knoten umgeleitet. Es ist jedoch viel interessanter, dass dieser Datenverkehr, sobald beide Server ausfielen, weiter ging und alles im Allgemeinen "platzierte". Während der Restaurierungsarbeiten fand der Kunde heraus, wer es vermasselt hatte. Dies scheint das Ende des Vorfalls zu sein: Es hat nichts mit Informationssicherheit zu tun und ist einfach mit krummen Händen verbunden.Administratorfehler. Der Kunde entschied sich jedoch, bis zum Ende nachzuforschen. Nachdem er die AWPs der Administratoren überprüft hatte, stellte er fest, dass alle Betriebssystemprotokolle von diesem sehr unglücklichen Handwerker gelöscht worden waren, und bat uns dann, seine Aktionen in der letzten Woche zu überprüfen.



Interessanterweise war dieser Administrator einige Wochen vor dem Vorfall Gegenstand unserer Untersuchungen. Er hat vom lokalen Netzwerk auf einen externen Host an Port 22 zugegriffen. Dann wurde dieser Vorfall als legitim markiert, weil Administratoren ist es nicht untersagt, externe Ressourcen zu verwenden, um ihre eigene Arbeit zu automatisieren oder neue Geräteeinstellungen zu testen. Vielleicht wäre diese Verbindung zwischen dem Ausfall des Rechenzentrums und dem Anruf an einen externen Host nie bemerkt worden, aber es gab einen anderen Vorfall: Anrufe von einem der Server des Testsegments an denselben Host im Internet, den der Administrator zuvor kontaktiert hatte - dieser Vorfall wurde auch vom Kunden notiert als legitim. Nachdem wir uns die Aktivitäten des Administrators angesehen hatten, sahen wir ständige Anfragen des Testsegments an diesen Server und baten den Kunden, diese zu testen.



Und hier ist es die Auflösung - auf diesem Server wurde ein Webserver bereitgestellt, der die Teilfunktionalität der Hauptwebsite des Kunden implementiert. Es stellte sich heraus, dass der Administrator vorhatte, einen Teil des eingehenden Datenverkehrs auf seine gefälschte Website umzuleiten, um Benutzerdaten für seine eigenen Zwecke zu sammeln.

Ergebnis

Trotz der Tatsache, dass es bereits 2020 ist, halten sich viele Organisationen immer noch nicht an die gemeinsamen Wahrheiten der Informationssicherheit, und die Verantwortungslosigkeit ihrer eigenen Mitarbeiter kann katastrophale Folgen haben.



In diesem Zusammenhang hier einige Tipps:

1. Setzen Sie RDP und SSH niemals nach außen aus, auch wenn Sie sie hinter anderen Ports verstecken - dies hilft nicht.
2. Passen Sie die höchstmögliche Protokollierungsstufe an, um die Erkennung von Eindringlingen zu beschleunigen.
3. Threat Hunting . TTPs , . .
4. , . , , .

, Solar JSOC (artkild)