 Hallo, vielen Dank fürs Frühaufstehen. Hier noch mal ganz kurz zusammengefasst, was gerade vom Herald auch kam. Purple Dome, ich gehe noch später in die Details, ist ein Tool, um Angriffe zu simulieren und da mal auch die Eigenverteidigungstools, die man hat, vor allem wahrscheinlich auch dann Detection, das kann aber auch hardening sein, mal in Aktion zu sehen. Ganz kurz zu mir, ich bin ein erfahrener Entwickler von Angriffs-Analysetools, also auf der Fans-Seite her und Malware-Erkennungstechnologien, da auch bisher in zwei Firmen gewesen, die jetzt mal Close-Source-Bold-On-Malware-Detection produzieren und auch in Open-Source-Software habe ich ziemlich viel beigetragen unter einem Cuckoo Sandbox, das jetzt nicht mehr unter dem Namen entwickelt wird, aber ein Cuckoo Sandbox lebt weiter als Cape. Die Origin-Story von Purple Dome, damit man kurz den Rahmen habt, ist in der aktuellen Security-Format, der Name wird später noch mal sichtbar geworden, ist aber jetzt mal momentan nicht wichtig, gibt es ein internes Research-Projekt-Team, die sehr viel Open-Source machen und eines davon ist Purple Dome dann geworden. Das ist für uns entwickelt worden, um die eigenen Produkte, also gerade Malware-Sensoren und Logik zu Stress-Testen, bevor wir das an irgendwie Kunden rausschicken. Ungefähr ein Jahr Entwicklungszeit steckt drin, es wurde so um Jahreswechsel Open-Source, obwohl es schon länger geplant war, mussten dann noch viele Unterschriften her und Dinge geklärt worden, wie es halt so ist. So, und jetzt für euch. Also angenommen bei euch hat die Firma mal richtigen Security investiert. In eurer Firma hat man ein Security Information-Devent-Management, also irgendeine teure Software gekauft, die Locks von überall zusammen kratzt und die schön darstellt. Ihr habt sogar ein eigenes Team, Security Operation Center, die nichts anderes machen als zu gucken, was die Rechner da alles zu tun und was sie tun dürfen und vielleicht dann doch nicht tun dürfen. Und es war sogar noch Geld dafür, jemanden zu bezahlen, der im Selflesfall den Kopf hinhält. So, aber ja, habt ihr ein Problem. Eigentlich weiß keiner, ob alles funktioniert und wie Locks von so einem richtigen Angriff aussehen. Wahrscheinlich habt ihr mit einem Produkt so ein paar Beispiele mitgekriegt und ein paar Beispielregeln. Die sind schon okay, das ist aber One-Size-Fits-All-Regeln, ihr wollt die wahrscheinlich für euch tun. Dann kommt noch ein OS-Update, danach weiß man erst recht nicht mehr, ob die Locks noch so aussehen, wie sie sollten oder ob die Daten noch da sind oder einfach nur anders aussehen. Was fast schlimmer ist, dann greifen die ihre Ausdrücke nicht mehr. Ob eure selbstgeschriebenen Erkennungsregeln überhaupt was erkennen, wisst ihr nicht? Ihr wisst, dass ihr keine Fehler mehr machen könnt ihr rausfinden. So, euer Problem ist und meins eigentlich auch, kein Schwein greift mich an. Früher gab es noch den ICAR Testvirus, das ist eine Datei, die ist so kurz, die kann man in jedes Lock reinpaust und dann gucken, ob es erkannt wird. Es ist sehr praktisch um Pfeilerkennung zu machen und zu gucken, ob die Pfeilbasierten, muss ich jetzt gerade betonen, Datei basierten Erkennungstechnologie überhaupt wach sind und da sind angeschlossen sind und wohin sie locken. Ich betone es mit dem Pfeilbasiert gerade deswegen, weil die heutigen Angriffe sind mehr Pfeil-less, die etwas fortgeschritten Angriffe und das sind nicht unbedingt die Hypercracks. Die nutzen inzwischen so eine schöne Kette von Memory Exploits, die nie auf eine Festbarte schreiben, Admin-Tools, also die so bekannten LOL-Bins oder harmlose Programme, die ihr drauf habt, die veraltet sind, aber vulnerabel damit. Das alles kann man mit sowas wie eine ICAR-Destatei gar nicht mehr nachbilden, kurz noch mal zu durchgehen, was jetzt gerade die Probleme sind. Die in Memory Exploits, da ist eine Software bei euch, eine harmlose Software, die installiert ist, nur nicht abgedeutet, verwundbar. Sie akzeptiert Daten von außen, lässt sich exploiten und alles, was danach passiert, findet in Memory Start. Wenn euer Scanner nur nach Dateien guckt, dann sieht es düster aus. LOL-Bins sind Living of the Landbyneries, das sind normale Admin-Tools, ihr habt sie entweder schon drauf oder der Angriffe installiert sind noch kurz nach, es sind harmlose Tools, der Viren-Scanner schlägt nicht an, weil harmloses Tool, nur der Falsche verwendet. Nicht ihr, nicht euer Admin, sehr dreckig, vulnerable Programme, beliebtesten sind signierte, aber veraltete und verwundbare Treiber, damit kann der Angreifer dann schon auf Systemrechte kommen. Das ist ein schöner, netter Zwischenschritt. Der Treiber ist legitim, der kommt von der Firma, der gehört auf Rechner, aber es ist halt die falsche Version. Es gibt in ganz vieler Software Behaviour-Erkennung, die kann sowas abfangen. Und es gibt die ersten Skripte online, die ein bisschen Behaviour produzieren, malisches Behaviour, um diese Dinger zu testen, aber shrunkt die Qualität und die Aussagekraft ist auch nicht so sicher, weil sich das jemand halt für sein System zusammengefrichelt hat. Könnte benutzen, Zuverlässigkeit, keine Ahnung. Und bevor die Frage aufkommt, jede klassische Antivironsoftware, die ihr kauft, hat schon seit vielen, vielen, vielen Jahren Behaviour-Komponenten drin. Die scannen nicht nur nach Dateien. Das ist gut und gleichzeitig riskant, weil für das Behaviour-Erkennung müssen sie sich ins System reinhängen. Da kommt dann ein Treiber mit. Gut ist es, weil ansonsten würde einige Mal weg gar nicht erkannbar sein. So, das ist euer Problem. Zurück zu euer Situation. Ihr habt jetzt diese ganz tolle Erkennungstechnologie. Um die zu testen, habt ihr jetzt die erste Option, den Leroy Jenkins Ansatz. Ihr lasst Metasbleut auf euer Production-Environment laufen und guckt, ob irgendwas passiert. Wahrscheinlich wird etwas passieren. Was genau ist nicht ganz klar und vielleicht wolltet es auch gar nicht. Das ist jetzt einer von den Einsatzzwecken für dieses Purple Dome. Noch mal Info zum Mitschreiben. Es ist Open Source MIT-Lizenz, findet ihr auf GitHub. Und der Nutzen von Purple Dome ist jetzt, wenn ihr das startet, dieses Python-Tool, startet es mehrere virtuelle Maschinen, die alle auf einer Konfiguration basieren. Die meisten der Maschinen sind Targets, die sind angreifbar und es wird ein Attacker gestartet, der die dann basierend auf einem Skript angreift. Das wäre jetzt sehr schlau in dieser Situation, wenn ihr die Tage so konfiguriert, dass ihr eurem System möglichst älteren. Das alles läuft in der simulierten Umgebung. Es sind VMs, die VMs angreifen. Momentan bei uns VirtualBox. Eigentlich kann nichts passieren. Ich würde den Rechnungstil über von eurem Produktionsnetz trennen, damit euch die IT nicht aufs Dach steigt. Da wir das jetzt, also wir und ihr dann auch alle verwenden, um eure Sensoren zu optimieren, das ist zumindest unser Ziel gewesen, wird alles aufgezeichnet. Sowohl was die Sensoren machen, das machen die Sensoren eh. Die sind auf den Targets oder im virtuellen Netz drin. Als auch die Angriffe, die wurden auch aufgezeichnet. Es gibt ein Lock, was der Angreifer getan hat und wann. So, mit PurpleDome sind das Files Angriffe handhabbarer, weil man kann das Ding jetzt schön Rieblein in verschiedenen Konfigurationen mit verschiedenen Targets, mit verschiedenen Sensorentypen, Konfiguration der Sensoren, verschiedene Logik. Man kann es nutzen, um die Sensoren zu entwickeln, die die Daten sammeln, also ganz stumpf, oder um die Logik hinter den Sensoren mit realen Daten zu füttern und gucken, ob die Logik funktioniert. Und parallel, immer wieder die Gesamtsituation ein bisschen zu modifizieren und gucken, wann es kaputt geht oder ob es noch läuft mit dem nächsten Update. So, was das jetzt wirklich kann, das Ding ist sehr flexibel gebaut mit Plugins, sehr intensiv genutzt und auch in der Open Source Version verfügbar, sind Angriffe basierend auf Metasploit, der Kali-Gromander-Zeile und Kaldera. Zum kleinen Überblick, warum ich gerade die jetzt ausgewählt habe und das, was jetzt noch nicht drin ist. Metasploit ist ein sehr klassisches Exploit-Tool, das kann entweder mit Implants, also mit kleinen vorkompallierten Programmen, die schon manuell installiert wurden, das ist das, was getroppt wird, wenn ihr auf der E-Mail das Wortdokument öffnet, dann ist Macro startet. Das wäre so ein Implant. Oder paar Exploit aufs Target, das heißt, da müsstet ihr dann auf dem Target ein vulnerables Tool installieren und das dann exploiten. Was Metasploit dann tut, dieses Implant baut eine Verbindung zum Angreifer auf, in den klassischen Fällen, wie es oft bei Malware passiert, kommt damit von Ihnen nach außen durch eure Firewall und kann das System dann vor Windows API hauptsächlich manipulieren. Also Metasploit ist unglaublich flexibel, aber das ist jetzt mal so eine Zifferenzierung zu Kaldera. Kaldera benutzt auch Implants, die man auch auf den Target installieren muss vorher. Auch das baut eine Verbindung zum Attacker auf. Es gibt verschiedene Kommunikationskanäle bei Metasploit. Es beeinflusst aber das System hauptsächlich über Kommando-Zellenbefehle. Also PowerShell, Shell, je nach Betriebssystem und das dritte im Bunde, das wir noch haben, der Attacker, da läuft ein Kali-Lenungs drauf, die ich verwendete, die Tools, die sind eher Netzwerk zentriert, weil bei Metasploit und Kaldera sind wir ja schon auf dem Ziel. Und hier habe ich vor allem Hydra, das ist ein Passwort Brutforcer und Nmap, schon mal als Plugin, mit Plugin-Kontrolle versehen, also das Plugin nutzt einfach schon da ist. Und für unseren Experiment war es hauptsächlich, um die Netzwerke locks mal ordentlich zu füllen mit Daten. Und beide machen Learn. Was man bei Metasploit noch kostenlos dazu gibt, kriegt ist Mimikats. Also Mimikats gibt es jetzt in tausenden Varianten. Mimikats extrahiert Credentials aus einem Speicher, also username und Passwort und alles andere, was Credentials sind. Das ist bei Standard Angriffen, wie man sie so sieht draußen, auch sehr häufigen Bestandteil und deswegen auch ziemlich interessant sehen die Sensor, wenn sowas passiert. Es gibt jetzt eine Lücke, muss man darauf hinweisen. Kobalt, Kobaltstreich habe ich nicht drin, noch nicht, das ist ähnlich wie Metasploit. Wird von Malware Angriffen stark genutzt, benötigt aber eine Lizenz aus und man hat sie mal geklaut als Malware Autor und ist jetzt noch nicht drin. Aber da alles ein Plugin System ist, sind das ein paar Teilen Python Code. Damit hat der Angreifer schon mal ganz ordentlich Möglichkeiten. Gert schon, mit dem was drin ist, für Learn auf den Sensor und auf den Locks zu sorgen. Als Sensor in der Public Relisten Version relativ langweilig ist jetzt falsch, aber Lockstash Fall bietet, das sammelt so ein Business System, der Locks ein, bereitet die als Chasen auf und schickt die los. Es ist sehr open-source und jeder kann es nachvollziehen, deswegen hat es das ins Plugin geschafft aktuell. Unsere eigenen Sensoren haben nun Plugin, das ist nicht open-source. Wenn irgendjemand anders Romexperimentieren will, ich habe es schon gemacht, da ist aber noch nichts in der Qualität, dass ich es publizieren wollte mit anderen Sensoren, die komme ich nach Hause mal kurz dazu. Da kann man sehr kreativ mit werden. Die Targets und der Angreifer, die werden ja als virtuelle Maschinen gestartet. Momentan, auch als Plugin, ist Wacrant da, das nutzt ein Config-File und produziert die virtuelle Maschine, um sie dann zu starten. Das ist dann der VirtualBox oder direkt standalone VirtualBox. Auch hier haben wir noch was, das für unsere Cloud zugeschnitten ist, das ist unsere Cloud. Dementsprechend für alle anderen ziemlich nutzlos. Wenn ihr was Claudiges braucht, um massiv parallel laufen zu lassen, baut euch ein Plugin. Jetzt gibt es noch was hier netters, und zwar Vulnerabilities, die kommen bei mir nämlich auch als Plugin. Vulnerabilities sind, nachdem die virtuelle Maschine läuft und gebaut ist, kann man nachträglich noch Verwundbarkeiten in die virtuelle Maschine reinhauen, damit die Sensoren auch ein bisschen mehr sehen, damit der Angreifer weiter kommt. Also ich habe jetzt bei einem ADP aufgemacht und ich habe noch ein paar schwache User-Passworter in der virtuelle Maschine reingesprengtelt, damit Hydra auch mal irgendetwas findet. Auch hier lässt sich mit Python-Skripten ziemlich einfacher weiter und das sind. Die rufen dann auf den Tages erstmal ein paar Kommando-Zeilen Befehle auf, wie ihr sie haben wollt. Und danach sind die Tages auch gut verwundbar. Die Angreifer kommen irgendwo hin und die sind so und sehen was. Ohne, dass ihr von vorne rein die virtuelle Maschine so aufsetzen müsst, wie ihr sie braucht. Das könnt ihr dann schön an und ausschalten. In der Anwendung ist es ein gut automatisierbares Tool, weil Automatisierung war jetzt hier King und hauptsächlich über Kommando-Zeile und Config Files und genauso sieht die Kommando-Zeule aus. Wir starten das Ding, befehlen ran, setzen das Config File auf Hello World, das würde ich euch auch empfehlen. Denn das testet mal so grob so ein paar virtuelle Maschinen und guckt ob euer System grundsätzlich richtig eingerichtet ist, bevor er dann hinterher debackt und euch wundert, woran es dann liegt. Es dauert ein paar Minuten bis es durchgelaufen ist und liefert dann die Ergebnisse. Die kommen später gleich. Aber bevor ich das verheimliche, es gibt eine Konfigurteil dazu, das ist ein Ausschnitt raus. Hier werden in diesem Beispiel die Caldera Angriffe definiert. Die passieren. Caldera hat ein sehr wunderschönen kryptisches Unique Identifier System. Das ist also dieser Angriff, der gefahren wird auf alle Liedungstagez. Für das Tag jetzt habe ich hier gerade nichts definiert und parallel läuft noch ein Plug-in-Based-Attacke, die Hydra-Attacke. Wenn ihr das alles über Wack-Rent laufen lasst, nicht verheimlichend, gibt es noch die Wack-Rent-Config-Datei, die die Ziele definiert. Ansonsten müsstet virtuellen Boxen bauen. Das war es aber auch schon, was ihr an Definition braucht als eine Kommando-Zeile, Config-File und eventuell die in Wack-Rent definierten Ziele. Was haben wir davon? Was ihr davon kriegen werdet, sind sehr viele Sensor-Logs. Das Angriffs-Log das genauso wichtig ist, damit ihr abgleichen könnt, ob der Sensor zur Zeit des Angriffs aufgezeichnet hat und ein PDF-Dokument für die Manager. PDF-Dokument für die Manager sieht so aus. Inhaltend kurze Systemdefinitionen, was die Target sind, was der Attacker ist, also in dem Fall ein Target, ein Attacker und dann die verschiedenen Schritte der Angriffe, die abgefahren werden. Ein Angriff sieht dann etwas so aus, sondern mal schön beschrieben. Wir gehen mit den TTPs, das ist was Maiter definiert hat, um verschiedene Angriffstypen schön zu taxonomieren. Das ist wunderbar, da kann man endlich mit Leuten darüber reden. Die sind in den Black Ins hinterlegt oder bei Caldera. Man sieht, welche Ability genutzt wurden, das versucht wurde, einen Current-User zu holen. Bei Caldera muss man Attack-Coups, was euch nicht verwirren hier noch definieren, die geht dann nicht ganz nach IPs und der Angreifer hatte er diese Lokalein der IP 112.7.8. Und das result war, wir haben herausgefunden, dass die Vacrant-Box mit dem User Vacrant gestattet wurde. Was jetzt? Hurra, großes Ziel. Für uns Techniker interessanter ist das Angriff-Log des Parallel rauskommt, weil das kann man dann halbautomatisch oder vollautomatisch mit den Sensor-Logs abgleichen. Wir haben hier Timestamps für Angriff und Ende, wir haben hier gerade eine Attacke, einen Caldera-Attacke im Laufen gehabt. Das ist der Angreifer, der müsste hoffentlich im Lok irgendwo auftauchen. Das sind die Caldera-IDs, also Paar und Croup. Caldera macht alles ein bisschen speziell, wie es definiert wurde, wer das Ziel ist. Und das ist eine schöne Beschreibung in verschiedenen Detailgraden, was für ein Angriff das war. Das Ability-ID würde eigentlich schon reichen, könnte man nach der richtigen Datei greppen. Aber mit den typischen Tax-Copy-TTPs, man hat die Tactics-System-Owner-User-Discovery, das ist schon ein bisschen abstrakter, in der Beschreibung und den genauen Namen des Angriffs. Das findet man meinter. Und wir haben wieder das Resultat. Ziel-User Vacrant. Jetzt nicht verwurz sein, dieses Sensor-Log habe ich jetzt auf ein Hydra-Angriff gemacht, das ist ein ganz anderer Angriff, das matcht jetzt gerade nicht, weil der einfach sehr schön noisy ist. Das ist ein File-Beat-Sensor-Log, auch mal ein bisschen gekürzt, weil eigentlich wäre das jetzt noch viel, viel länger. Wir haben ein Time-Stamp, das ist aus einem Attacker-Log abgleicht. Wir haben die klassische Match-Sets-Fail-Passwort für invalid User, non-existent User 1 von diesem Angreifer. Und da das jetzt ein Stumpferbrut-Force-Angriff war, haben wir das jetzt noch ein paar hundert Mal. Da müsste die Logik drauf dringern. Also die Daten sind da, da müsste die Logik dringern. Noch mal ein ganz kurzer Überblick, was im Hintergrund passiert, dass wir haben die Kommandoseile gestartet, wir haben die Logs rausgekriegt und es ist irgendwas passiert dazwischen. Also was da passiert ist? Ziele werden aufgesetzt. Wenn ihr Vacrant nutzt, werden die VMs generiert nach eurer Definition. Am einfachsten ist es mit Linux-Targets. Windows-Targets und Vacrant ist so ein bisschen zickig, da setzt ihr wahrscheinlich im besten Manuell eure Windows-Box auf und nutzt dann Virtual-Box einfach von einem Snapshot aus. Also wahrscheinlich für euch der einfache Weg. Für mich war es es auf jeden Fall. Dann werden Targets und Attacker gestartet. Die Vulnerabilities werden nachinstelliert auf den Targets, damit ihr auch schön angreifbar sind. Also in diesem Fall jetzt gut ratbare User-Passworter. Die Sensoren wurden aufgesetzt und aktiviert. Also Sensoren können alles sein, was ihr da an Tools habt. Die wurden im selben Fall sogar installiert und einfach gestartet. Die Angriffe wurden auch im Script durchgeführt. Momentan ist es nicht allzu schlau, es geht einfach von oben nach unten durch. Da würde ich mal irgendwann mal was erweitern. Ideen sind schon da, aber dann richtig und dann wird es ein bisschen größer. Klar, die Sensoren sammeln das die Daten für sich. Die Angriffe sind abgeschlossen. Jetzt kann man die Sensoren stoppen und die Daten von allen Targets auf euren Controller-Maschinen übertragen. Da landen sie in der Zip-Datei zusammen mit der PDF, die desgeneriert werden wird und zusammen mit dem Angriffslock. Alles schön hinein. Unser Ansatz war jetzt sehr eigennützig. Wir entwickeln Sensoren für richtig viele Leute, für komplexe Angriffe wollen die testen. Aber es war von vornherein auch angedacht, dass Universitäten dranteilnehmen mit verschiedenen Security-Schwerpunkten auch so was sie forensigt. Das heißt, die Sensoren laufen nicht mit, der Angriff gelingt und was bleibt noch über auf dem System. Das ist für uns nicht so richtig relevant. Dann ist es für uns zu spät. Aber auch aufrufen euch kommt, wenn ihr weitere Ideen habt, bisherige Top-Ideen waren Schulungen. Man kann das Ding für Schulungen einsetzen, besonders auch bei Referenzix. Man kann da praktisch auf Knopfdruck Daten generieren. Wenn man einen Sensor so baut, dass er gar nicht startet, während das System losläuft, sondern am Schluss einfach ein Snapshot vom System macht, hat man die Daten. Trainings, Red-Blu-Team, sich gegenseitig Dinge wegschießen, Loks finden usw. Oder Capture the Flag. Das waren gerade so Hochschul-Ideen. Da muss ich noch etwas zu sagen. Das Security-Retret-Model, das ich da jetzt habe für dieses Dingens, sieht voraus, dass derjenige das installiert laufen lässt, die Versuche durchführt und die Loks einsammelt, die gleiche Person ist. Bei einem Capture the Flag habt jemand das aufsetzt und Leute, die alle Flaggen raustragen wollen. Dafür ist momentan noch nicht gesichert. Also wenn einer da schlau ist und den Vortrag ist geradeführt, ja. So, mehr Ideen. Jetzt habe ich heute die ganze Zeit schon versprochen, wenn ihr ein bisschen Python programmieren könnt, könnt ihr es erweitern mit Plugins. Und das ist so. Im Prinzip ist es ein grobes Grundgerüst und dann viele Plugins zu stellen. Es gibt Spezialplugin-Typen für Angriffe, Vulnerabilities, Sensorintegration in die Targets. Also wir nehmen fertige Sensoren, integrieren sie einfach nur und verschiedene Arten vor allem zu unterstützen. Beispiele sind da und ich kann gerade mal eins zeigen, dass das Linux-File bietet. Dieses Python-File, das ich jetzt euch jetzt zeige, ist ein bisschen gekürzt hier in meiner Präsentation, aber nicht viel. Jedes Plugin, jeder Typ, das ihr habt, gerade von Sensor Plugin, hat so eine Boilerplate, wo der Name drin steht, eine Beschreibung oder hier ist required Files, das sind einfach die Konfliktfiles, die dann in die Targets installiert werden müssen. Aus dieser Boilerplate wird zum Beispiel auch später das PDF gefüllt. Das zieht dann den Namen daraus und packt es an das Manager PDF rein. Die meisten Plugins-Typen haben noch zwei, drei Funktionen, die aufgerufen wurden, Prime oder Install, also es gibt praktisch zwei Installationsroutinen, Prime macht ein Hardcore Install mit Rebooten des Systems und allem und Install macht einfach nur ein Install und nicht Reboot. Können ganz simpel sein, dass hier im Ledmit Curl von Elastic Cloud dieses Ding runter, das Filebeat-Dab und ich stelle das mit Zulu, die PKG, also das klassische. Das war es, das war ein Install. Das ist jetzt ein gekürztes Detail, um Filebeat zu starten, muss man einiges an Kommando-Zeilen abschießen. In diesem Fall definiere ich welche Module enabled sein sollen, also das Filebeat kann mehr als nur System und IP-Tables, aber das war jetzt mal gerade für die Netzwerk-Tests für mich interessant und danach wurden den Pipeline aufgebaut, damit die Daten dann beim JSON-Locker landen und die wurden dann in JSON verpackt und ein schöner Detail reingeschrieben. Also ein paar Zellen fehlen, die findet ihr online, aber auch das kein Hexenwork. Die Kollektfunktion ist fast noch einfacher. Wir wissen, wo auf dem Target das Filebeat JSON landen wird, wie es im Fall hier, Temp-Filebeat JSON und das wird dann einfach rauskoppiert. Dem einfach die Liste, die jetzt rauskoppiert, der Teil von Kollekt einfach an Purple Dome selbst übermittelt wird. That's it. Im Fall fahre ich es noch nicht mal runter, weil die Maschine wird dann eh wieder terminiert. Ich habe dann schon gesagt, ich habe mit Zensoren rumexperimentiert, nichts auf einem Niveau, wo ich jetzt sagen würde, das würde ich jetzt ganz schon im Open Source sehen. Das ist alles nur so a bit nice to have. Interessant könnte es sein, für Leute, die spielen wollen, eBPF, das ist eigentlich ein Linux Kernel Monitor, der in Linux inzwischen alles tut, aber seinen Weg ins Microsoft-Reich finden wird, wie es gerade scheint. Inwiefern das in Microsoft tut, keine Ahnung, aber das ist etwas, was mich reizt. Frieda ist auch so ein Monitor für APIs, das ist ein bisschen wie Kokumonitor, falls euch Kokura sagt. Aber praktisch userkontrollierbar und es monitor jetzt nicht das System APIs, sondern Prozess APIs. Also schaut ihr auf die Prozesse. Noch mal ein anderer Ansatz, OS Query, auch spannend, weil das Zielsystem Start hier raus, also man kann das praktisch vor dem Lauf, nach dem Lauf des Angriffs durchführen und gucken, wie das System vorher nachher aussieht und was kaputt gegangen wurde. Wieder ein komischer Ding von Microsoft, Sysmon, die schieben gerade Sysmon das Standard Microsoft Monitoring Tool rüber auf Linux. Auch was, was sicherspass machen würde, da mal ein bisschen zu testen. Und wenn man im Bereich Forensics unterwegs ist, also wirklich nach dem das Kind im Grund liegt nachzukucken, wie es da aussieht. Volatility kann Memories Snapshots machen und man kann dann das Windows Memories z.B. nach Artifakten durchsuchen. Sind da Prozesse, die zwar laufen, aber nicht in der Prozessliste drin hängen. Was kann man am Routkits finden? So, das war es im Prinzip schon mit meinem Vortrag. Ihr findet mich auf viele Wege, ich habe jetzt mal meinen Master Don angegeben, weil der Trend geht ganz klar zu Master Don. Das Projekt findet ihr auf GitHub.com, aber es ist Purple Don. Und bitte folgt es, bitte beschwert euch, wenn was nicht funktioniert. Davon lebt es. Und falls ihr irgendwie mit Unis Kontakt habt und die Spaß in irgendwas haben, sagt es denen. Gibt es Fragen? Dann erst mal vielen Dank dir für den wunderschönen Vortrag. Und jetzt kommen wir tatsächlich zur Fragerunde. Wir fragen hat, hieb bitte die Hand. Ich komme rum, gebe euch ein Mikro und ihr dürft gerne Fragen stellen. Habt ihr auch, also kann man das auch gegen bestehende Infrastruktur laufen lassen? Weil also ich habe meine Infrastruktur und meine Testinfrastruktur mit Terraform definiert und wir sind nicht eigentlich nochmal neuschreiben in Vagrant und Python. Also Terraform habe ich noch nicht drin, aber das ist ja im Prinzip so ein größer gewordenes Vagrant. Von daher dürfte es nicht allzu schwer sein, das umzubauen. Und ja, also wir haben von vornherein angedacht, dass wir komplexer Systeme, also Minibüro oder so simulieren können, um lateral movement zu machen. Da ist Terraform auch schon besser als Vagrant. Das heißt, ja, wird sich lohnen. Probier mal, gebt mir Feedback. Ja, eine andere Frage, die ich noch hatte war, kann man das dann vielleicht auch irgendwie in CI-Pipeline mit integrieren, dass man quasi, wenn man Code aktualisiert von einem Projekt, dass man laufen hat, dass man quasi automatisiert solche Tests dann dagegen laufen lässt. Gibt es denn das ED hin dazu? Ja, also Kleinigkeit, die ich dazu sagen muss, es wird sich exploitsziehen, also je nachdem, wie genau euer wird der Maschine, in der das CI-Test laufen, abgesichert ist und was die Abmachung mit euren Security-Leuten ist, vielleicht lieber nicht machen, und es dauert Zeit. Also ich habe sehr oft einfach fortgekehrt virtuelle Maschinen gestartet, die gar nicht ausgebaut, weil sie immer die gleichen waren, dann dauert es, je nachdem wie viele Angriffe laufen, 4-5 Minuten. Wenn es richtig viele Angriffe sind, länger. Also wir haben versucht, das Playbook von Fin7 nachzubauen, das haben wir, die interessanten 50 Prozent haben wir gebaut, ist auch im Purple-Dorm open sourced, aber das läuft dann länger. Hängt ein bisschen von einem Timing ab und von euren Security-Menschen, was die zu euch sagen würden, wenn das da exploitscht drauf landen. Aber ja, macht Sinn. Bei deinem ersten Attackers-Log ist mir aufgefallen, dass die Time Stamps nur Stunden, Minuten, Sekunden hatten. Da habe ich mich schon gefragt, wie lange läuft denn so ein Attack? Kann der nicht auch mal mit Blood Force über den Tag laufen? Später kam dann aber auf Timestamps die ISO-Formate, das ist alles Free-Format und darf auch mal mehr wie ein Tag laufen? Also, ja, ich habe es noch nie länger laufen lassen als ein paar Minuten. Man kann es definitiv länger laufen lassen, das war jetzt aber nicht mein Use-Case. Und die Formate bei den Locks, die habe ich jetzt nicht normalisiert. Ich habe das genommen, was die Sensorin so ausgespuckt haben. Wäre sinnreich gewesen, aber Filebeat war für mich auch nur so ein, für mich eher so ein Show, heißt Dingens, um Open Source zeigen zu können, was das Ding kann und wie es läuft. Weil unsere eigenen Locks und unsere eigenen Sensorin sind da nicht drin. Eine weitere Frage, da haben wir noch eine. Hast du schon irgendwelche Erfahrungen mal mit Z-DoS gemacht? Nee. Komm nach Hause mal zu mir. Das wird noch ein längeres Gespräch bei einem Tunk, wie ich sehe. Dann, wenn keine Fragen mehr sind, vielen Dank dir. Gerne. Ich sehe keine Fragen mehr, finde ich farbehaft. Und nochmal einen Runder-Applaus an Thorsten Säck. Dann war's das.