 Congress. Wer von euch hat den Vortrag über Politiker-Sprecher heute Morgen gesehen? Niemand. Ja, es war auf Deutsch gut, deswegen vielleicht. Ich wollte eigentlich was an die Leute richten, die ihr den Vortrag gesehen haben, aber Kauderwelsch in Menschenverständlicher Sprache nur gut, das habt ihr wohl heute Morgen nicht gehört, aber Kauderwelsch in elektronischen Sprachen. Das sagt euch vielleicht mehr. Ben, hier neben mir, ist ein Sicherheitsforscher bei Checkpoint und er redet heute mit euch über DJS, also Algorithmen, die Kauderwelsch erzeugen. Aber in der Vergangenheit sind sie ein bisschen krüger geworden und er wird euch sagen, wie man dieses Kauderwelsch aufspüren kann. Manche Leute wünschen sich das vielleicht auch für Politiker, aber er wird euch erklären, wie das für DJS funktioniert. Also einen großen Applaus für Ben und lass uns loslegen. Also fangen wir am Anfang an, wenn diese Folie für euch irgendwie Sinne gibt, dann seid ihr wahrscheinlich ein Roboter. Das sind die schlechten Nachrichten, die guten Nachrichten ist, dass ihr in dem richtigen Vortrag seid, denn nach dem Vortrag werdet ihr Kauderwelsch wie Menschen erkennen können und wie niemand wird es merken. Aber was ist überhaupt DJA und was ist das Problem, das es lösen wollte? Schauen wir uns ein reguläres Szenario an, in dem ein System mit malware infiziert wurde und mit seinem Kontrollserver kommunizieren will. In der Vergangenheit brauchte man das nicht, weil es diese Kontrollserver nicht gab, aber heutzutage wartet malware normalerweise auf Befehle. In diesem Grundszenario kamen die malware mit eingebauten DNS-Adressen und die malware fragte den DNS-Server nach den harte kodierten Adressen und kriegt eine IP-Adresse zurück und jetzt kontaktiert das infiziertes System den CNC-Server und der CNC-Server sagt, juhu, ich habe eine neue Maschine unter meiner Kontrolle und jetzt könnte sich unterhalten. Das ist alles schon gut, aber an irgendwann haben die Mächte da oben das Ganze bemerkt und den Leuten, die die DNS-Server kontrollieren gesagt, hey, hier ist ein bisschen zwielichte Aktivität passiert und die benutzt eure DNS-Server, könnt ihr bitte dafür sorgen, dass das aufhört und weil die Leute, die die DNS-Server kontrollieren, keinen Stress wollen, haben sie diese Adressen entfernt und jetzt macht das die Malbräufe wieder ein Versuch, die CNC-Server zu erreichen und der DNS-Server sagt, ne, hau ab. Jetzt steht dieser CNC-Server da immer noch völlig funktionell rum und wartet auf, wartet, dass jemand mit ihm redet und erwartet und erwartet, aber das kommt niemand. DGA ist dann ein Mechanismus, den sich die Angreifer überlegt haben und haben sich dieses alte System angeschaut und wollten etwas Besseres bauen, was nicht so leicht zerstört werden kann. Ich könnte euch jetzt lange, lange erklären, wie DGA funktioniert, aber ich will das einfach an einem praktischen Beispiel festmachen. Also schauen wir uns das mal an. Unsere Geschichte fängt an mit dem CNC-Server und es hat einen Pseudo-Zufass-Generator. Der Pseudo-Zufass-Zeigen-Generator nimmt einen öffentlich verfügbaren Sieb zum Beispiel das aktuelle Datum oder die Schlagzeiten der aktuellen Zeitung. Es ist nicht so wichtig, es muss irgendetwas sein, was öffentlich zugänglich ist und jetzt nimmt es diese öffentliche Information und spuckt eine große Anzahl an Domainnamen aus. Diese Domainnamen sagen einem nicht wirklich viel und das ist typisch. Das ist im Grunde das Thema dieses Vortrages, aber was der CNC-Server macht, ist, dass er eine dieser Domains zufällig auswählt und sie registriert, damit sie auf seine IP-Adresse zeigt. Und so kann die infizierte Maschine dann mit dem Server reden. Das infizierte System hat Zugriff auf den selben Zufass-Zeigen-Generator und hat auch Zugriff auf den öffentlich zugänglichen Seed, weil der öffentlich zugänglich ist. Und jetzt fragt er den Zufass-Zeigen-Generator, was sind die Domains des Tages? Was sind die Domains, die ich heute abfragen könnte? Und das bekommt diese Liste, diese Domains manchmal sind 15, manchmal sind es 200, das ist auf jeden Fall eine ganze Menge. Und das infizierte System weiß jetzt, dass der CNC-Server eine dieser Domains registriert hat und auf seine IP-Adresse zeigen lässt, aber es weiß nicht, welche. Was wird es also tun? Es gibt eigentlich nur eine Lösung. Lass uns alle Adressen abfragen. Es wird durch alle Adressen durchgehen und DNS-Abfragen an jede einzelne machen und nach der passenden IP-Adresse fragen. Die meisten dieser Domains werden nicht tatsächlich registriert sein. Das Ergebnis ist also eine sehr merkwürdige, sehr eigenartige Konversation, die ein bisschen den Käseladensketch von Monty Python endet. Wenn ihr ihn nicht kennt, da kommt ein Typ in einen Käselladen und will versucht, verschiedene Käselsorten zu kaufen und im Verlaufe des Sketches wird es immer deutlicher, dass der Laden überhaupt gar keinen Käsel verkauft, wie mit Parmesan, nein, Bri, nein und so weiter und so weiter. Die DNS-Konversation ändert einen sehr an diesen Sketch. Weil das infizierte System fragt, hast du die Adresse für diese Code-Adresse? Der DNS-Adresse sagt nein. Wie wäre es mit dieser Code-Adresse? Nein. Wie wäre es mit der hier? Nein. Tut mir leid. Wie wäre es damit? Nein. Leider heute nicht. Das geht immer so weiter. So sieht der Traffic aus, der bei diesem Prozess entsteht. Der DNS-Adress sagt, nee, kenne ich nicht. Was willst du eigentlich von mir? Bitte auf mich zu nerven. Aber erinnert euch dran, der CNC-Server hat tatsächlich eine dieser Domains registriert. Eine dieser Domains ist eine götige Domain, die ihr auf die IP-Adresse des CNC-Servers zeigt und irgendwann wird das infizierte System die richtige Abfrage machen und den DNS-Server hoch und runter und sagt, ich kenne diese Adresse und jetzt freut sich das infizierte System total, weil es endlich die IP-Adresse des CNC-Servers hat und jetzt ist alles wieder gut und es kann mit dem CNC-Server reden. Ihr wisst, vielleicht habt ihr gemerkt, ich habe die ganze Zeit gesagt, wie vorher auch, weil das im Grunde genau das Gleiche ist und am Ende kriegen wir die IP-Adresse des CNC-Servers, aber das stimmt nicht ganz. Ich meine, denkt drüber nach, was ihr machen müsst, wenn ihr das hier jetzt vom Netz nehmen wollt. Jetzt schauen wir uns mal die Domains an, die an einem Tag von diesem Algorithmus erzeugt werden. Das ist eine ganze Menge. Und wenn ihr euch, wenn ihr diese Infrastruktur jetzt unterbinden wollt, aber den keinen Zugriff auf den Zufallzeiten Generator habt, dann ist das wirklich schwierig, weil ihr rausfinden müsst, welche dieser Adressen registriert sind und welche diese Adressen heute abgefragt werden werden. Wenn, wenn man das überhaupt unterbinden will, dann ist das hier das wahrscheinliche Szenario. Du hast zuerst deinen Opfer und das ist irgendwie infiziert und es kontaktiert den CNC-Server und schließlich wird die, wird das Ganze weitergegeben an, an, an Incident Response. Und was können Sie, was können die jetzt tun? Die können versuchen, dieses Feuer zu löschen. Und wenn ihr Glück habt, dann werden Sie vielleicht versuchen, da ihre Schlüsse daraus zu ziehen und sicherzustellen, dass die Informationen, die sie daraus gezogen haben, relevant sind und in Zukunft neue Attacken zu verhindern. Also wenn man Glück hat, dann können diese Incident Response gemeinsam mit einem Security Hersteller und dem Mittelmanagement irgendwo bei einem Security Verkäufer zusammenarbeiten und das runterzunehmen. Oder man findet einen Reverse-Engineer, der diese Malware auseinander nimmt, über zwei, drei Wochen bis mit etwas Glück daraus schlussendlich irgendwann eine Meldung resultiert, ein Report, der irgendwo unten auf einer Liste landen wird. Und über ein Prozess, der sich über Monate erstrecken kann, wird dann wahrscheinlich der Security Hersteller irgendwann zum Schluss kommen, dass er die Resultate aus diesem DGA in der Config-File für eine Firewall aufnehmen kann und damit solche Request blocken kann. Doch nehmen wir an, wir hätten die Möglichkeit, automatisch DGAs zu entdecken. Wir könnten viele Mittelsmänner heraus schneiden aus dem Prozess und schneller reagieren. Das Mittelmanagement hat besseres zu tun mit seiner Zeit, Engineers haben besseres zu tun mit ihrer Zeit. Wenn wir die DGA Traffic automatisch erkennen können, können wir den automatisch in der Firewall abfangen. Dann können die Firewall aggressiv nach der 4 bis 5 Queries von 4 bis 5 Anfragen von einem infizierten System den Traffic blockieren und sagen, sorry, du kommst nicht durch. Deshalb wäre es nützlich und cool, wenn man sowas auf einer Firewall machen könnte. Da gibt es einige Lösungen, die schon gemacht wurden, die vorgeschlagen wurden, mit denen man solchen DGA Traffic erkennen kann. Und weiter werden wir anschauen, wie diese Features, die bereits entwickelt wurden, nicht in allen Fällen funktionieren und nicht in allen Fällen dicht sind. Nun, einige Wege, wie man das erkennen kann. Ein einfacher Weg ist, die Zeichenfrequenz zu analysieren. Gewisse Zeichen in den Wörtern kommen öfters vor als andere. Diesen Beispiel haben wir in der Englischsprache verbreitete Zeichen, die oft vorkommen wie E und R, grün gekennzeichnete, mittelmäßige, gelb und seltene, rot. Auf dem slide seht ihr 5 normale Beispiele, 5 richtige Wörter und 5 Kauderweltschwörter. Das ist ein sinnvoller Approach, um damit umzugehen. Ein zweiter Ansatz nimmt einzelner Buchstaben, die Vorkommensrate von Paaren oder Trigrammen von Buchstaben in Wörtern. Ein weiterer Weg ist es, den längsten Substring mit einer Bedeutung aus einem Wort zu verwenden, also beispielsweise Bugkäfer in Bugminot. Also Bugminot enthält zum Beispiel die Wörter Bug und Not. Das Amazon ist ein Wort aus dem Wörterbuch. Das heißt, es ist offensichtlich kein Kauderweltsch. Ebay enthält das Wort Bay, es sind immerhin drei Viertel ein Kauderweltsch. Und dieser tatsächliche Kauderweltsch ist wirklich Kauderweltsch, weil ich keinen Teil davon im Wörterbuch finden kann. Das letzte Feature, das in der Vergangenheit vorgeschlagen wurde, ist der Traffic. Also wenn man sich erinnert euch an den G-Shop, wenn man einfach zu zählen, wie viele DNS-Anfragen viel schlagen. Wir haben also mehrere Möglichkeiten, wie wir DJI aufspüren können und das Problem ist gelöst. Wir können shoppen gehen. Nein, natürlich nicht. Das erste Problem mit dem, was ich gerade ausprobiert habe, ist das Tumblr-Conundrum, das Tumblr-Problem. Ich meine, schauen wir das Reddit an. Da steckt das Wort Red und Dit drin. Das kennt ihr aus Morsecode. Wenn ihr euch Google anschaut, enthält das die Wörter Go und oh, wir haben Glück. Ogil ist auch ein Wort. Das heißt, diese Algorithmus schaut sich das an und sagt, oh, Go, Ogil, das hört sich gut an. Das passt. Aber schauen wir uns das Tumblr an. Was ist ein Tumblr? Also Tumblr in dieser Schreibweise ist kein Wort. Ombler ist kein Wort. Blö, blö, blö. Es sind immer noch keine Wörter. Das heißt, da hast du ein Problem. Wenn man sich das anschaut, dann wird man sagen, also wird ein Maschine sagen, oh, das ist kauderwählig. Aber ein Mensch wird das nicht ganz so schnell sagen. Das ist ein Problem. Das zweite Problem ist Quaijibo. Quaijibo ist eine DGA-Engine und es hat seinen Namen aus einem Moment in einer Folge von den Simpsons und der Bart Scrabble gegen Homer spielt. Und Bart hat diese Wörter hier. Und Bart kann damit nicht so richtig anfangen. Und Bart sagt, dann benutzt sie einfach diese Wörter und spielt das Wort Quaijibo und macht eine Milchade-Punkte damit. Und Homer ist aber natürlich nicht erfreut darüber und fragt, was das denn sein soll. Und Bart sagt, ja, das ist ein dummer, nordamerikanischer Schimpanzer. Und das Konto und dem Radar fliegen, weil Quaijibo sich anhört wie ein Wort. Aber es ist kein echtes Wort. Und das ist dieses Problem. Es gibt Wörter, die sich anhören wie echte Wörter, aber keine echten Wörter sind. Was macht Quaijibo? Es sorgt einfach dafür, dass jeder zweite Buchstabe ein Vokale ist. Jetzt sitzt ihr da und denkt, Ben, das ist alles. Jeder zweite Buchstabe ist ein Vokal. Und jetzt ist auf einmal alles, was wir gerade gelernt haben, nutzlos. Schauen wir uns die Buchstaben-Häufigkeiten an. Früher hatten die Domainnamen Generatoren jede Menge Xe und komische Buchstaben. Aber auf einmal sieht es viel, viel besser aus, weil man überall Vokale hat. Und dann sagt man, ja, schauen wir uns die Bigramme an, also Buchstabenpaare. Aber das ist das Gleiche, den Buchstabenpaare mit Vokalen darin sind sehr, sehr häufig. Nicht alle, aber die meisten. Bei drei Buchstaben wirst du wieder fast genau das gleiche Problem haben. Das heißt, jetzt wird der Buchstabenhoffigkeitsansatz deutlich schlechter funktionieren als vorher. Und wie ist das mit den längstmöglichen Substrings? Ja, du kannst ein Bier spielen und dir diese Domainnamen anschauen, wenn ich schlurre. Ich habe sie zufällig erzeugt. Und hier finde ich schon Give und ein paar Wörter. Das heißt, diese Features, die vorher so stark schienen, sind jetzt nicht mehr ganz so gut. Und jetzt sind sie nur noch halbnützlich. Und wenn du nur halbnützliche Features nimmst und sie in einen Maschinen-Learning-Agrhythmus reinfüllst, dann wirst du Regeln bekommen, die einfach nicht funktionieren. Aufgrund all dieser Probleme haben wir uns eine schöne Idee für eine Lösung ausgedacht. Das ist, wir schauen uns einfach den Input an und schauen, wie nahe an einer Zusammensetzung von Wörtern aus dem Wörterbuch ist. Zum Beispiel Tumblr kann mit nur einer Änderung zu Tumblr werden, mit E drin, was ein echtes Wort aus dem Wörterbuch ist. Jetzt haben wir nur einen Buchstaben eingebaut und es ist ein echtes Wort. Google mit zwei Änderungen ist auch ein Wort aus dem Wörterbuch. Reddit mit zwei Änderungen wird zu Reddit. Und jetzt macht es endlich Sinn. Quigibo generiert Codawash Strings und irgendwann haltest du mal Glück und erzeugt ein Wort, das aus dem Wörterbuch kommt. Aber es wird nicht erfolgreich Zusammensetzung von vernünftigen Wörtern erzeugen. Du musst das ganze Ding anschauen und versuchen, da Sinn rauszuholen. Um weiterzumachen, habe ich einen klaren Weg. Wir können die Differenz zwischen Wörterbuch Wörtern oder Konkatenationen von Wörterbuch Wörtern vergleichen mit abgefragten Domains. Und diese Distanz, die wir auswerten, ist die Zusammenfassung von Änderungen einfügen und Anpassungen Wörtern. Dann kommt das Wunder und dann profitieren wir. Damit können wir Quigibo aushebeln, das Tumblr-Problem überleben und den Tag retten. Und dann kommt die Realität. Wieso haben wir hier ein Problem? Schauen wir uns mal an, wie wir diese Edit Distanz berechnen. Wir verwenden einen Algorithmus, das ist ein Flood Search. Damit machen wir eine breiten Suche erst. Wir versuchen für den String jede mögliche Veränderung, also einen Brute Force Ansatz, mit der steigenden Anzahl an Edits, die wir untersuchen, wird unser Suchraum exponentiell größer. Für einen Input von Größe 8, wenn wir den komplett durchsuchen wollen, dann kann mich nicht ganz an die Nummer erinnern, aber es ist eine riesige Nummer von Vergleichen. Sagen wir einmal, wenn wir das Wörterbuch schauen, dauert eine Mikrosekunde. Wenn wir die Anzahl Lookups multiplizieren mit der Anzahl Sekunden, die wir brauchen, um diesen Suchspace zu suchen, dann erhalten wir die Antwort auf die Frage, wie nahe am Wörterbuch ist diese einzelne Anfrage, die auf unserem Nameserver angefangen ist. Wir müssen das nur in den Algorithmus reinwerfen, warten über zweieinhalb Tage. Das ist übrigens die untere Limite von Lookups, die wir auf jeden Fall machen müssen. Die tatsächliche Anzahl von Lookups ist sehr wahrscheinlich größer. Alle Berechnungen hier in diesem Talk werden sind die p-mal daumenden Umrechnungen, die ich gemacht habe. Übrigens, es gibt eine unbegrenzte Anzahl von Wörtern in Wörterbuchen, Wörterbüchern, gegen die wir vergleichen könnten. Also sehen wir nicht mal bei zweieinhalb Tagen, es gibt nämlich eine unbegrenzte Anzahl, die wir anschauen müssten. Werden diese unendlich große Datenbank noch nirgends platzieren können, weil Google ein entsprechendes Projekt erst in einem halben Jahr live beschalten wird. Also müssen wir improvisieren. Wir müssen also mit irgendeinem hässlichen Hack weiterarbeiten, um das irgendwie berechenbar zu machen. Der erste hässliche Hack, den wir erfunden haben, meine erste Lösung, ist, wir verwenden einen Geizengin-Algorithmus, der den ganzen Input gegen das ganze Set an möglichen Kartenationen vergleicht und dann untersucht, ob wir irgendwann einen Prefix das Stichwort finden. Durch die Verwendung dieses Algorithmus können wir die Zeit, die Algorithmus laufen muss deutlich verringern, weil der erste Algorithmus ein exponentielles Verhältnis zur Laufzeit hat und dieser hier im Gegensatz gegen ein endliches Wörterbuch vergleicht. Es ist nicht alles Sonnenschein und Regenbögen, aber die erwartete Zeit ist immer noch eine Stunde und irgendwas pro Traffic Capture, was nicht akzeptabel ist. Wir müssen also pro Capture eine Stunde warten, was einfach nicht geht. Also brauchen wir mehr hässliche Hacks. Der zweite hässliche Hack, verwendet asymmetrische Suche, also statt die dumme breiten Suche. Und wir, was würde passieren, wenn ich mein Wörterbuch aufblasen würde, dass alle möglichen Strings enthält, die eine Edit Distanz von zwei zu meinem ursprünglichen String enthalten. Wir werden ein größeres Wörterbuch haben, aber können nun eine viel kleinere Flutungssuche über diesen Input machen. Wenn der Input eine Distanz von vier zum Wörterbuch aufwahlst und wir in unserem Dictionary schon alle Suchen von zwei haben, dann brauchen wir nur noch zwei Edits und können danach direkt zu einem Input aus der Flut-Search schließen. Damit ist der erwartete Wert viel kleiner. Er verkleine also den Exponenten unserer Berechnung und die Laufzeit ist deutlich reduziert. Leider wird dabei aber das Wörterbuch größer. Ungefähr um Vaktor 10.000 ist nicht schön, aber wir können immer noch damit leben. Wir brauchen aber noch einen dritten hässlichen Hack, dass wir zu akzeptablen Resultaten kommen. Zwar schauen wir uns die Edit Distanz an und vergleichen einen anderen Ansatz. Was, wenn wir für die Bearbeitung nur in Surgeons und also Einfügen und Löschen von Zeichen erlauben würden, statt Änderungen. Das Resultat davon ist, es gibt eigentlich keinen Grund, um es darauf zu schließen, dass das Resultat aus diesem Algorithmus schlechter ist als das Vorregel. Wir wechseln also einen Kriterium für ein anderes Aus. Die zwei Kriterien ungefähr zum gleichen Grad legitim sind, dann haben wir viele wenige Optionen, durch die wir uns durcharbeiten müssen. Weniger Arbeit. Diese hässlichen Hacks sind zwar hübsch, aber das hübsche Ding, wenn wir die alle zusammenfassen, ist was dann entsteht. Schauen wir die symmetrische Suche an und wie wir die Suche nach dieser Distanz kombinieren können. Schauen wir uns das Wort Spux an. Wir können das P entnehmen und haben Schux, Sx und haben Schuh. Wenn wir von Schout, das T und das O wegnehmen, auch dann landen wir bei Schuh. So haben diese beiden Wörter sich in der Mitte getroffen. Was wir damit bewiesen haben, ist, dass die symmetrische Einfügen und Löschdistanz zwischen Spux und Schout 4 beträgt. Wir können also uns erst von der linken Seite runterarbeiten und dann von rechts rückwärts weiter. Euch wird aufgefallen sein, wir mussten dabei nie etwas einfügen. Wir haben nur gelöscht. Wir haben Busch da aus Spux und Schout gelöscht und am Schluss haben wir den kleinsten gemeinsamen Nenner gefunden, Schuh. Das können wir für jeden möglichen Input machen. Also können wir eigentlich einfach über symmetrische Löschung sprechen. Das ist ein Vorteil, weil wir jetzt nur noch die Operation Löschen haben und nicht mehr insertion. Also kombinieren wir das jetzt mit dem aufgeblasenen Wörterbuch, das wir vorhin schon hatten und verwenden ein Wörterbuch mit allen reduzierten Formen aus dem Wort, die wir durch das Löschen von Zeichen erhalten könnten. Also nehmen wir einen Input und Löschen zeichen und vergleichen dann dieses Wort gegen die reduzierte Formen. Irgendwann werden unsere Mitte treffen und erhalten, wie bei Spux und Schout, einen kleinsten gemeinsamen Nenner. Damit haben wir einen viel kürzeren Ablauf des Algorithmus für unsere Mitte treffen. Um diesen Algorithmus komplett durchzuarbeiten, müssten wir jede mögliche Löschung aus dem Input durchführen. In unserem Beispiel haben wir uns darauf beschränkt, drei Buchstaben zu löschen, weil die Performance gewinnt, damit schon genügend schön waren und es sehr wenig Wörter im Englischen gibt, aus denen man drei Zeichen entfernen kann und immer noch etwas Sinnvolles hat. Wir fanden das einen guten Ansatz, einen sinnvollen Trailer auf einen Kompromiss. Um uns tatsächlich in der Mitte zu treffen, würde mehr Löschungen erfordern. Wir werden das also nicht komplett machen können, aber abgesehen davon die wichtige Sache ist, dass wir die Insertions kostenlose halten und wir damit zu dem Wörterbuchwort kommen können. Sogar wenn man acht Insertions bräuchte, um zu diesem Wort zu kommen, funktioniert es trotzdem. Gut, wie gut funktioniert dieses Ding eigentlich, nachdem wir all diese Ugly Hacks angewandt haben? Wir müssen das implementieren, um es zu testen. Ich wollte es eigentlich in Perl machen und jemand hat mir gesagt, Perl sei schrecklich, man sollte nichts in Perl tun. Also habe ich das Ganze in Python geschrieben und allerlei Berechnungen gemacht, um die Anzahl dieser atomaren Lookups auszuführen und haben zum Resultat, wie viel Zeit man dafür ungefähr investieren muss, um diese Berechnung auszuführen, einschließlich des Erzeugen des Kauderwäsches. Wenn man diese Zahlen nimmt, sie miteinander multipliziert, um das selbe Resultat zu erzielen, dass wir vorhin hatten, zu prüfen, wie nahe an einem Wörterbuch ein Stringer aus acht Zeichen ist. Vorhin dauerte das 2,5 Tage und jetzt ist es noch ein Viertel einer Sekunde, also eine Verbesserung von fast einer Million. Damit sind wir sehr glücklich. In den weisen Worten von Hannah Montana können wir nun das beste zweier Welten benutzen. Die Größe des Wörterbuches ist groß, aber nicht prohibitiv. Ich habe erklärt wieso, dass es ein wertvoller Kompromiss ist und wir haben damit tatsächlich ein Wörterbuch, das in der realen Welt anwendbar ist. Was wir nun machen können, ist ein Experiment. Passen wir zusammen die drei Features, die wir erstellt haben, um Wörter aus einem Capture gegen DJI zu vergleichen. Wir haben die Anzahlnummern, die Anzahlrequests mit derselben Antwort zusammengefasst. Für die zusammengefassten Request haben wir den Prozess vereinfacht und diese Berechnung für jeden Request gemacht. Zum Schluss haben wir für Vergleiche die Berechnung so vereinfacht, um einfach an den Resultat zu kommen. Also schauen wir uns jetzt den resultierten Klassifahrer an in der Demo. Jetzt werden wir eine Traffic Capture ausführen. Ich habe das so eingestellt, dass er bei den ersten drei Malen, wenn was Spannendes passiert, pausieren wird und danach nicht mehr, damit wir nicht ewig stehen. Also jetzt machen wir die Traffic Capture und wir fangen an sie zu analysieren und wir werden die Features extrahieren. Die häufigste DNS Antwort, die wir in diesem Traffic Capture bekommen haben, ist NX Domain. Also werden wir uns anschauen, welche Domains dieses Ergebnis hervorgebracht haben und ich glaube, jetzt solltet ihr euch, solltet ihr euch ein bisschen wunderbar wenn ihr das anschaut und jetzt haben wir die Maximum Domain Collision Features, also die meisten Features für dieses Resultat erzeugen. Und jetzt sind unsere relevanten Request und die werden wir analysieren auf die Features, die wir gerade ausgemacht haben. Also jetzt fangen wir an mit der Pronunciation DVNC. Also das ist ein tolles Wort für die Anzahl der Bgramme und Trigramme und wie gestarkt das von dem, was wir für Englisch erwarten würden. Für den ersten Domain Namen geht der Algorithmus jetzt durch und sagt, okay, das fängt mit C an. Wie sehr überrascht mich das, dass der das mit C anfängt? Ihr könnt sehen, die Antwort ist 5,6 Überraschung mehr oder weniger. Fragt mich nicht nach den Einhalten hier. Das ist ein ganz anderes Thema, dafür haben wir hier nicht die Zeit. Das Gleiche passiert jetzt, weil nach dem C ein I kommt und der Algorithmus fragt, okay, ich habe ein C gesehen, wie sehr überrascht es mich, dass ich ein I nach dem C sehe. Es sind 4,3 Überraschung, das ist weniger als vorher. Das geht weiter und weiter und jetzt schauen wir das C an. Bis endlich, wir haben eine Tüte voller Überraschung. Jetzt haben wir eine Zahl, wir normalisieren das, indem wir es durch die Länge des Inputs zeilen und jetzt haben wir ein Ergebnis, wie überraschen wir diesen Domain Namen insgesamt anhand seiner Bgramme. Machen wir weiter mit dem nächsten Domainnamen. Das Gleiche passiert. Auch hier haben wir jetzt wieder eine Ahnung dafür, wie überraschen wir den finden und für den nächsten. Und jetzt macht ihr das für alle Domainnamen automatisch weiter und dann nehmen wir den Durchschnitt aller Domainnamen und das haben wir ein Maß dafür, wie überraschen wir den durchschnittlichen Domainnamen finden und die Antwort ist 0,9 Überraschung. Wir machen weiter und jetzt berechnen wir die lexikalische Abweichung, das ist nur ein hochtragender Name für das, was ich euch gerade erklärt habe. Also die Ähnlichkeit zu einer Zusammensetzung von Wörtern aus dem Buchstaben mithilfe einer paar hässliche Hacks. Um das zu berechnen, muss der gierige Algorithmus über jedes mögliche Präfix iterieren und schauen, welches am vielversprechendsten aussieht. Und dann kommt aber heraus, dass er ist der vielversprechendste Kandidat. Das könnte ein Wort aus dem Wörterbuch sein. Jetzt haben wir die Präfix nachgeschlagen und können nachts nichts löschen und bei C bleiben oder wir löschen das C und bleiben bei nichts und haben nichts übrig und das stellt sich heraus, dass beide dieser Optionen im Wörterbuch sind. Also es ist besser nichts zu löschen und zu sagen, dass C im Wörterbuch ist, es ist ein Kandidat. Wir können es einfach wegnehmen und sagen, okay, das ist ein Wort aus dem Wörterbuch, aber das Problem ist natürlich, dass C nur ein Buchstab ist. Also es ist vielleicht im Wörterbuch, aber es ist trotzdem nicht der beste Kandidat, weil es eben nur ein Buchstab ist. Also wir wollen so viele Buchstaben wie möglich entfernen. Das ist das, das charakterisiert diesen gierigen Algorithmus. Wir wollen so viele Buchstaben wie möglich rauswerfen, um den Input kleiner zu machen. Schauen wir uns das Präfix CI an und auch hier wieder der gleiche Prozess. Mit jedem Präfix, das in diesem Input ist, bis endlich der Algorithmus die Entscheidung trifft, ich glaube die ersten beiden Buchstaben, das ist die beste Auswahl. Das ist das nächstmögliche, was ich habe zu einem Wort aus dem Wörterbuch, dass ich das rauswerfen kann. Jetzt passiert das gleiche wieder und es nimmt den Präfix LI weg und den Präfix CI und so weiter und so weiter. Bis schließlich ist eine Punktzahl erreicht für die Ähnlichkeit zu einer Zusammensetzung aus Wörtern aus dem Wörterbuch für diesen Domainnamen. Und das gleiche machen wir für den nächsten Domainnamen und den nächsten und den restlichen Domainnamen und auch hier nehmen wir den Durchschnitt, um eine finale Punktzahl zu erreichen für die durchschnittliche Nähe zu einer Zusammensetzung aus Wörtern aus dem Wörterbuch aller Domainnamen, die wir extrahiert haben und die wir uns genauer anschauen wollten. Jetzt haben wir unsere final Liste der Features. Wir haben 28 Domains, die ähnlich funktionieren. Wir haben eine lektrikale Abweichung von 0,6. Die Aufsprechbarkeit, das ist das Feature, das wir gebaut haben. Nein, die Aufsprechbarkeitsabweichung ist basiert auf den, darauf wie Absprechbarkeit die Buchstaben sind. Jetzt schauen wir uns die 28 Domainnamen an, die in die gleiche Richtung zeigen. 28 Domainnamen, die auf das gleiche zeigen, alles mit mehr als fünf Domainnamen auf die gleiche IP, das sagt, das lässt schon Alarmglocken klingeln. Das ist einfach zu viel. Was die Nähe der Wörter aus dem Wörterbuch angeht, schaut sich die Werte an. Ich zeige euch nachher noch die Parameter dafür und sagt, oh, das ist aber viel zu viel. Es ist nicht nah zu einer Zusammensetzung aus Wörtern aus dem Wörterbuch überhaupt nicht. Und schließlich schaut sich die Aufsprechbarkeitsabweichung an, also wie wahrscheinlich die Paare der Wörter der Buchstaben sind. Und es findet heraus, dass es eigentlich ganz vernünftig ist, weil wir einen Wert von 0,9 haben. Alles bis 1,5 ist relativ vernünftig. Also, viele Domain sehen aus wie Kauderwäsch, aber das Bigram Features schaut sich an und sagt, okay, das sieht ganz gut aus. Wollten gegen das hier, das Qui-Gi-Bo, hat diese Namen generiert. Und jetzt schauen wir uns diese Namen an und sehen, MrPronunciability. Jetzt haben wir ein neues Feature. Du sagst, das funktioniert. Wir sagen, das funktioniert nicht. Deswegen nehmen wir jetzt andere Features. Das war die kurze Demo, wie das Ganze funktioniert. Und jetzt schauen wir uns ein paar schöne Diagramme an. Wir haben 10.000 Peacups aus dem Malwell-Up von Checkpoint genommen, nur um zu sehen, wie die Daten aussehen, wenn wir sie auch auf diese gerade extrahierten Features anwenden. Und das sind deine 10.000 Peacups über der maximalen Domainnamen-Kollusion und der maximalen Zusammensetzung von Werten aus dem Wörterbuch. Und eines davon könnte für euch vielleicht ein bisschen merkwürdig aussehen. Und da habt ihr recht, denn als wir uns 100, eine Stuhlspur von 100 angeschaut haben und sie von Hand labert haben, waren die Samples in der Lampe und alles war links. Wenn ihr das visualisieren wollt, also wenn ihr die Klassikatoren selbst visualisieren wollt, dann habe ich euch versprochen, dass ich euch sage, wie das generiert wurde. Ich habe jede Menge Maschinen-Learning-Igorithmen ausprobiert, GAUS und Mixer-Modals. Aber bisher habe ich die besten Ergebnisse bekommen, indem ich mir die Daten einfach selber angeschaut habe. Also das ist eine Unterklasse des Maschinen-Learnings namens Band-Learning. Und das ist schade, weil ich eigentlich einen echten Maschinen-Learning-Algorithmus benutzen wollte und die Daten vernünftig analysieren wollte. Das hier wurde nicht anhand der Daten generiert. Es sind einfach die 10.000 Peacups, die wir genommen haben und ich habe die Parameter zur Klassifikation anhand von anderen Traffic Captures generiert. Man testet seine Klassikatoren ja nicht anhand derselben Parameter, die man benutzt hat, um die Domain namens zu erzeugen. So sieht der Klassifikator aus. Und jetzt werden wir ein bisschen über die Zukunft dieses Projektes reden und was noch gemacht werden muss. Also erstes müssen wir weiter testen, weil testen ist immer was Gutes. Aber ich bin sicher, dass wir noch viele Überraschungen sehen werden, die wir in DJI sehen, die uns zwingen werden, dieses Projekt anzupassen und unsere Funktionen im Detail nachzutunen. Eines davon kommt in den nächsten Zwei Folien. Weiter werden wir mehr Maschinen-Learning brauchen, weil wir einen wirklichen Maschinen-Learning-Algorithmus brauchen, nicht Band-Learning. Ich glaube, ich habe den Graph gesehen, also der funktioniert gut, aber ich möchte was Besseres. Und zum Schluss müssen wir auch Debrish Detection Cordewalsch-Erkennung 103 machen, weil einige dieser DGRs haben unsere Analyse bereits erwartet und es gibt solche, wie der von der Mats Malware, der neue Domain zusammensetzt, in dem er Wörterbuch Wörter konkateniert. Also wird unsere Wörterbuch-Erkennung gar nichts anfangen können. Wie können wir uns entwickeln, um dem zu begegnen? Beispielsweise könnten wir eine symptomatische Vergleich versuchen zu machen mit den Wörtern, die wir genommen haben, beispielsweise Panther und Asphyxiation, während Wörter, die nicht unbedingt im Zusammenhang auftauchen würden. Was zu unerkennbaren Cordewalsch? Meine persönliche Meinung zu unerkennbarem Cordewalsch ist, dass es nicht möglich ist, einen solchen klumpen Cordewalsch zu haben, weil es würde bedeuten, es müsste Cordewalsch oder Text, den man in der realen Welt haben könnte, in jeder möglichen Weise ähneln. Aber ich denke, das ist nicht möglich, aber es könnte sein. Es wird aber sehr möglich sein, dass man unerkennbare, automatisch generierte Domains haben könnte. Wenn wir ein Algorithmus haben, der Domainnamen erstellt, die sehr genauer Domainnamen ähnelt, der in der realen Welt auftauchen könnte, dann wird es schwierig zu erkennen. Wenn man eine Sammlung an Limitierungen für die Liste möglicher Domainnamen einführt, dann wird diese Liste irgendwann so lange, dass es irgendwann einfach möglich wird für Cordewalsch Domains auch dort drin einen Raum zu finden und zu kommen. Aber das ist noch weit von dem Weg, das wir jetzt haben. Was heute ist, wir haben Degias wie Quijibo, die am Mock laufen und leicht erkennbar werden. Bevor wir uns mit unerkennbarem Cordewalsch auseinandersetzen, sollten wir erst die bestehenden Degias dazu zwingen, dass sie wirklich äh, dass sie um unsere Erkennung hier umarbeiten und richtig unerkennbares Cordewalsch produzieren. Nun, kommen wir zu diesem Classifier. Die Frage ist, kann ich ihn haben, diesen Classifier, der unterscheiden kann, ob Traffic tatsächlich an einem DJI kommt oder nicht? Die Antwort ist ja, hier ist die Guitar Page. Wenn ihr Vorschläge habt, wenn ihr findet, ich könnte eigentlich vorschlagen, wie man das besser machen kann. Ich könnte vorschlagen, wie man das besser erkennen kann. Dann kann man das als Push Request, als Pull Request einreichen. Gut, fassen wir zusammen. Wir haben rausgefunden, DJI sind ein Problem. Die automatische Erkennung ist möglich und wenn wir, wenn wir unsere Algumten verbessern, dann können wir mit der strategischen Platzierung von Vokalen in diesen Strings umgehen. Unerkennbarer Scouter, welcher irgendwann meine Möglichkeit werden, aber bislang ist es noch nicht möglich. Danke für eure Aufmerksamkeit und gibt es Fragen aus dem Publikum. Okay, very interesting talk. Danke Ben für deinen Talk. Wenn ihr gehen müsst, dann macht das bitte leise, damit wir eine interessante und informative Q&A Session haben können. Wir haben ein paar Minuten Zeit. Wir haben einige Minuten Zeit, nicht so wenige. Wenn ihr Fragen habt, dann stellt euch bitte an die Mikros und wir nehmen auch Fragen aus dem Internet. Gehen ist okay, sprechen bitte nicht, während ihr geht. Danke für den Talk. Ich wollte fragen, ob du viele Probleme mit der Größe des Dictionaries hattest und habe gehört, du hast mit dem Hack umgegangen und du hast das Dictionary ersetzt, indem du die Werte angepasst hat mit der Silbenlöschung. Ein Wort wie zum Beispiel Mandalorian, das in einem Star Wars Dictionary sein könnte. Das ist nicht in einem normalen Wörterbuch. Ja, es gab ein Paper, das genau diesen Ansatz benutzt hat oder ungefähr, dass es einfach Wortstämme benutzt hat und Morpheme benutzt hat usw. Es war sehr interessant und deren Ansatz hat nicht so ganz gut funktioniert. Aber ich glaube, es ist ein guter Ansatz. Ich weiß nicht, ob wir wirklich das Wörterbuch komplett abschaffen sollten und durch Silbeninformationen ersetzen sollten, weil ich mir nicht sicher bin, dass Wortstämme oder Silben oder diese Atome, die du vorschlägst, dass sie sich wieder zu Wörtern aus dem Wörterbuch zusammen lassen würden. Aber ich glaube, es ist ein Weg, den man gehen könnte, wenn es helfen würde, das Wörterbuch zu reduzieren, denn dann ist es auf jeden Fall etwas, was mich interessieren würde, weil momentan dieses Wörterbuch ungefähr 10,7 Gigabyte braucht und alles, was das Kleiner machen würde, ist höchst willkommen. Also, danke. Mich interessiert, wie du mit Domains umgehst, wie z.B. xkdc.com, die eigentlich die gültige Domain sind, aber nach Kauderweltsch aussehen. Ja, xkdc z.B. hat nicht zu tun mit irgendeinem Wort aus dem Wörterbuch. Das ist eine wirklich gute Frage. Nicht jeder Domainname wird in dieses Paradigma passen von Domainnamen, die einem Wort aus dem Wörterbuch ändern. Und das ist der Grund, warum dieses Ding immer noch weiter verbessert werden muss und mehr Ansätze brauchen für die Erkennung von validen Domainnamen. Also, natürlich werden wir uns die Top-Domainnamen antauen, das ist ganz klar. Aber lasst mich dir eine Frage stellen. Welchen Ansatz kannst du dir vorstellen, der von Anfang an gesehen hätte, dass xkdc.com ein gültiger Domainname ist? Das ist, genau das ist das Problem. Ich glaube, so Sachen wie xkdc.com müssen entweder hart kodiert werden, also in einer Whitelist sein. Ich weiß es wirklich nicht, wie man vorhersehen können, dass xkd.com ein gültiger Domainname ist. Außer dieses Apriori-Wissen zu nehmen und es anzuwenden. Wie gehst du mit Fremdsprachendomains um, also IDNs, und anderen Domains in Sprachen, die aussehen, als ob es kauderweltsch wäre, zum Beispiel die chinesischen, die wenn nicht erkennen können? Hast du andere Aspekte dieser Domains angeschaut, beispielsweise, ob sie schon bekannt sind oder vor wie kurzer Zeit sie registriert wurden? Was das Sprachproblem angeht, dieses Projekt bezieht sich nur auf Englisch, das ist Work and Progress. Ich habe mir genau darüber nachgedacht und wenn das Ganze tatsächlich benutzt wird und vernünftig funktionieren soll, dann will ich es erweitern, damit es andere Sprachen unterstützen kann. Kannst du mich nochmal an eine andere Frage ändern? Punicode, also Domains, die aus englischen Zeichen bestehen, aber nicht englische Wörter sind oder in anderen Ländern verwendet werden. Oder andere Kd. Domains, zum Beispiel ob sie früher besucht wurden oder wann sie registriert wurden? Oh ja, jetzt erinnere ich mich. Es gibt viele Projekte, die dieses Problem in der Vergangenheit so lösen wollten, also mit dieser Art, dass man, das ist immer noch etwas, was heute noch versucht wird, dass dir sagen kann, um zu sagen, ob der Domain Name verdächtig ist, sondern nicht, indem man sich anschaut, wann wurde er registriert, wann wurde er darauf zugegriffen. Das sind alles sehr nützlicher Features. Ich habe spezifisch mich, habe entschieden, dass die nicht in dieses Projekt passen, sondern ich wollte, ich will aber, will aber gerne zusammenschließen mit jedem, der es schon gemacht hat anstatt das Rad neu zu finden. Ich schaue gerade, ob es Fragen aus dem Internet gibt, aber es sieht so aus, als ob das die letzte Frage aus dem Raum gewesen wäre. Klingt, als ob diese DJI bald eine art dalaistische Poesie ausgeben würden, wahrscheinlich in 400 verschiedenen Brachen möglich sein, diese Domain zu registrieren. Und an welchem Ort im DNS System denkst du, werden diese Domains auftauchen, wie nützlich wird das sein? Das ist in einem ganz anderen Kontext entstanden, als ich auf den letzten paar Folien erklärt habe, das sollte ein Feature sein, das mir in einer Sandbox funktionieren würde, also dass man Maschinen-Learning-Aparationen usw. benutzen kann, um Features herauszuziehen. Man kann sich die Stichprobe anschauen und sagen, das ist DJI, das ist eines der Features, die ich mir anschauen kann und benutzen kann. Aber wie ich gesagt habe, auf einer der ersten Folien, glaube ich, dass der Höhepunkt des ganzen, was wir machen können, wenn dieser Code für Performance in diesem Kontext optimiert wäre, was im Alter nicht ist, dann könnte es auf einer Firewall sitzen und DJI Traffic thrashing könnte, bevor er überhaupt auf den Netzwerk rauskommt. Es gibt eine weitere Frage im Hinterteil des Raums. Ja, du hast erwähnt, dass du andere Maschinen-Learn-Modelle verwendet hast. Hast du Markov-Ketten verwendet? Ah, das habe ich noch nicht probiert. Markov-Ketten, das werde ich gleich morgen probieren. Es gibt Forschung in DJI Erkennung mit Markov-Ketten und es gab dort einige Erkenntnisse, zum Beispiel, wenn du denkst, dass Bigrammen nicht ausreichen, dann hast du Vorteile und die Lookup-Zeit ist linear, also deutlich schneller. Oh, das werde ich mir mal anschauen müssen, danke. Hallo, hast du versucht einen Bloomfilter für die Lookups zu verwenden? Das sollte die Abfragezeit beschleunigen. Bloomfilters, nee, habe ich mir noch nicht angeschaut, aber das werde ich mir auch noch anschauen. Jede Menge nützliche Vorschläge, danke. Wir haben Zeit für ein paar letzte Fragen. Zum Internet gibt es nichts mehr. Letzte von einem Mikro. Danke. Ich fand die Präsentationen sehr spannend. Ich komme von einem Data Science Background. Es sieht mir nach einem Cuts- und Maus-Spiel aus. Von einer methodischen Perspektive scheint es mir nach einem Spiel, das man fast nur verlieren kann. Mich würde mehr die Motivation für den Anfang interessieren. Du hast erwähnt diesen ganzen Prozess mit dem Middle Management on Reverse Engineering. Gibt es dort auch statistische Methoden, die verwendet werden und bleibt es dasselbe Cuts- und Maus-Spiel und wird besser gespielt? Ja, ich stimme dir völlig zu. Das ist in der Theorie wirklich ein Spiel, das man nicht gewinnen kann, weil die Autoren dieser Generatoren das ändern werden. Und ich glaube, irgendwann am Ende werden sie das Spiel gewinnen. Aber das ist immer so in der Sicherheit. Am Ende werden die Anreifer immer gewinnen, denn die Last auf den Schuttern der Verteidiger ist viel größer und ist in der Theorie ein MP-Vollständiges Problem oder im schlimmsten Fall unmöglich. Aber obwohl du Recht hast, glaube ich, dass wir uns auf das fokussieren sollten, was jetzt gerade passiert. Also ja, im Moment ist es ein Spiel, dass wir nicht gewinnen können. Aber jenseits dessen können wir schauen, was wir machen können, damit das vielleicht am Ende, dass wir das Spiel am Ende vielleicht gewinnen können. Wir müssen dafür sorgen, dass wir es zumindest vorübergehend gewinnen können, auch wenn wir in der Theorie wissen, dass wir verlieren werden. Das ist das, was ich glaube. Dann schließen wir ab. Einen großen Applaus für Ben, bitte. Vielen Dank für den Talk.