Wir leben in einer Zeit, in der Daten die neuen Tulpen, das neue Gold, das neue Rohöl sind. Der Run auf unsere Daten ist ungebrochen und nimmt teils beängstigende Ausmasse an. Man denke an die Goldräusche des 19. Jahrhunderts, anstelle von Gold werden heute die Daten der Benutzer aus allerlei Apps und Services geschürft. Jährlich werden durch die Beschaffung, Aufbereitung und den Weiterverkauf unserer Daten Milliarden umgesetzt. Und was hat das jetzt mit Endpoint Detection and Response (EDR) zu tun?

Wie auch bei den teilweise doch recht fragwürdigen Auswüchsen der Datensammelwut einiger Apps (aktuelles Beispiel hier: www.heise.de/ct/artikel/Wie-Avast-die-Daten-seiner-Kunden-verkaufte-4657290.html) braucht ein gescheites EDR System natürlich so viele Daten wie möglich. In dem Fall dienen sie dann jedoch einem hehren Ziel – nämlich der Erkennung von Angriffen auf das Firmennetz. Wobei, eigentlich nicht nur dazu. Wenn man die Daten schon hat, können diese natürlich auch für weitere nützliche Dinge wie Vulnerability Management oder IT-Hygiene verwendet werden. Mehr dazu etwas später.


Vom Sammeln zum Threat Hunting

Mit dem Sammeln der Daten ist es jedoch noch nicht getan. Diese müssen auch ausgewertet werden. Stichwort Threat Hunting. Als Prämisse wird dabei davon ausgegangen, dass bereits ein Angreifer auf den Systemen sein Unwesen treibt. Mit gezielten Suchkriterien will man dem Schelm nun auf die Schliche kommen. Und genau hier wird es knifflig: Wonach soll denn überhaupt gesucht werden? Die Idee einer EDR-Lösung besteht ja an und für sich darin, unbekannte verdächtige Aktivitäten zu entdecken. Also Dinge, die von (NextGen)AV-Lösungen nicht erstinstanzlich erkannt und geblockt wurden. Doch wie findet man das Unbekannte? Antwort: In dem man nicht nur direkt nach etwas Bestimmten sucht, was ja eigentlich eine AV-Lösung schon macht, sondern nach Indikatoren für einen Angriff.


Die reaktive Methode: Indicators of Compromise

Diese Indicators of Compromise (IOC) bestehen aus:

    • Hash Values
    • IP-Adressen
    • Domains
    • Host Artifacts (z.B. verdächtige Services, Files oder RegKeys)
    • verdächtiger Netzwerkverkehr
    • speziellen Tools

Ein interessanter Artikel zum Thema Indicators findet man hier: detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html. Darin geht es um die „Pyramid of Pain“, was meiner Meinung nach gut aufzeigt, wie schwierig es ist, die verschiedenen Arten von IOCs beim Jagen zu verwenden.

 

Pyramid of Pain by DavidJBianco
Quelle: detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html, abgerufen am 09.04.2020

 

Doch wo kriegt man diese IOCs überhaupt her? Eine Möglichkeit ist, dass man direkt Threat Intelligece Feeds anzapft, was auch automatische Aktualisierung bedeutet. Eine mögliche Quelle für solche Feeds ist MISP (www.misp.software/index.html). Eine andere Möglichkeit ist, sich selber IOCs zu erstellen. Dazu gibt es auch Web Tools wie z.B. IOC Bucket (www.iocbucket.com/openioceditor).

Auf welche Art auch immer man mit IOCs arbeitet, die Krux dabei ist, dass es sich dabei um eine reaktive Methode handelt. An und für sich die gleiche Methode wie die Pattern Updates bei herkömmlichen AV-Lösungen. IOCs können dabei mit der Beweissicherung in einem Kriminalfall verglichen werden. Die Sicherung der Beweise kommt immer erst nach dem Verbrechen. Wir sind ja nicht bei Minority Report 😉


Die proaktive Methode – Indicators of Attack

Um auf diese Herausforderung zu reagieren, kommen hier Indicators of Attack IOAs in’s Spiel. IOAs bieten eine proaktive Möglichkeit der Spurensuche. Dadurch soll der Schaden bestenfalls verhindert oder zumindest minimiert werden. Typische IOAs‘ sind beispielsweise:

    • Ungewöhnlich hohe Anzahl Logins an einem Server
    • Aktivitäten auf Rechner oder im Netzwerk zu aussergewöhnlichen Zeiten
    • Änderungen im Kommunikationsverhalten eines Rechners, z.B. vermehrte Kommunikation zu spezifischen IPs oder Domains
    • Portscans
    • Neue laufende Services auf einzelnen Rechnern
    • Neu erstellte lokale Accounts auf Rechnern
    • Ungewöhnliche Prozess-Aktivitäten, z.B. löschen von Volume Shadow Copies
    • Tactics, Techniques and Procedures TTPs

Zum Thema TTPs hat ein Kollege hier bereits einen lesenswerten Blog-Artikel verfasst: www.tec-bite.ch/mitre-attack-angriff-ist-die-beste-verteidigung/


Wie man Threat Hunting ohne eigene Hunters betreibt

Mit IOCs und IOAs hat man somit die Mittel zur Hand, die einem bei der Suche helfen. Doch wie sucht man jetzt? Gerade bei KMUs sind eigene SOC Teams häufig nicht vorhanden, es fehlen also schlichtweg die Spezialisten. Umso wichtiger ist dann, dass es auch für weniger versierte Jäger möglich ist, diese Tools zu verwenden. Im Endeffekt ist es aber nicht nur eine Frage des Knowhows, auch die Zeit spielt eine grosse Rolle. Wenn ich heute in meinem IT Team schon genügend mit Daily Business zu tun habe, nützt mir ein EDR System herzlich wenig. Wenn ich die Daten zwar habe, aber diese nicht verwenden kann, bringt das nichts. Für diesen Fall bieten Hersteller einen Service à là Managed SOC an. Somit kann man ohne zusätzlichen Aufwand von den Vorteilen eines EDR Systems profitieren.

Als ein Pionier was die Nutzung von IOAs betrifft, setzt CrowdStrike (www.avantec.ch/loesungen/avantec-newcomers/#crowdstrike) mit seiner Falcon Plattform hier neue Massstäbe. Das GUI ist übersichtlich und verständlich gestaltet und bietet vorgenerierte Reports und nützliche Hunting Queries als Hilfen an.

 

Hier eine Query, die mir als Resultat sämtliche Powershell Downloads zurückgibt:

event_simpleName=ProcessRollup2 FileName=powershell.exe (CommandLine=*Invoke-WebRequest* OR CommandLine=*Net.WebClient* OR CommandLine=*Start-BitsTransfer*) | table ComputerName UserName FileName CommandLine

Das Ergebnis im GUI:

Praktisch: jede getätigte Suche bleibt in der Search History und kann von da mühelos nochmals verwendet werden:

Die Queries basieren auf Splunk’s Search Processing Language.

Damit mein Artikel jetzt nicht zu sehr in die Tiefe geht, möchte ich an dieser Stelle auf den entsprechenden „How to Hunt for Threat Activity with Falcon Endpoint Protection“ Artikel von CrowdStrike verweisen. Diesen findet man hier: www.crowdstrike.com/blog/tech-center/hunt-threat-activity-falcon-endpoint-protection/.


Was ein EDR sonst noch kann

Wie Anfangs erwähnt eignet sich ein EDR System aber eben nicht nur für Threat Hunting, sondern bietet auch andere nützliche Funktionen wie IT Hygiene oder Vulnerability Management.

Bei der IT Hygiene geht es im Grunde darum, zu wissen, was ich für Applikationen auf welchen Rechnern habe, welche Versionen diese Applikationen aufweisen, welche Accounts auf welchen Systemen verwendet werden und was für Privilegien diese dort haben. Wenn wir beim Beispiel von CrowdStrike bleiben wollen, gibt es dafür das Falcon Discover Modul:

Wenn ich jetzt weiss, welche Applikationen ich in welchen Versionen auf meinen Systemen habe, wäre es doch auch noch praktisch zu wissen, ob ich ggf. offene Sicherheitslücken habe. Genau dafür kommt nun ein Vulnerability Management zum Zug. In der CrowdStrike Falcon Plattform steht hierfür das Spotlight Modul zur Verfügung.

Wie beim Discover Modul erhält man bei Spotlight auf eine komfortable Art und Weise einen Überblick über die offenen Sicherheitslücken:

Die Lücken werden dann mit den CVE IDs von MITRE gelistet. Wie auch die TTPs werden die CVE’s (Common Vulnerability and Exposures) mittlerweile von den meisten Herstellern von Security Lösungen als Standard verwendet.  Mit den Infos aus Spotlight kann ich als System Admin dann mit WSUS oder SCCM, oder sonstigen Patch Management Systemen, die fehlenden Patches auf meinen Systemen installieren und die Lücken somit schliessen.


Fazit

Zum Abschluss lässt sich zusammenfassend sagen, das Thema Threat Hunting ist nicht ganz ohne. Für effektives Hunting ist neben den richtigen Tools auch ein fundiertes Fachwissen notwendig. Da den meisten Firmen dieses Fachwissen fehlt, empfiehlt es sich zumindest anfangs auf einen Managed Service zu setzen. Dadurch kann man sofort vom erweiterten Schutz profitieren und so ganz nebenbei noch ohne Druck sein eigenes Knowhow erweitern.

Aufmerksame Leser haben vielleicht bemerkt, dass ich den Response Teil von Endpoint Detection and Response noch nicht angesprochen habe. Darauf werde ich meinem nächsten Artikel eingehen.