 Hier ein bisschen über Microsoft Domain Quirks und wie sie explodieren können. Über das wird Jakuto jetzt sagen. Hallo auch aus dem Translation Team hier für euch. Herzlich willkommen zu meinem Vortrag über Domain Controller. Domain Controller haben benutze Accounts, haben auch benutze Accounts Wir werden halt ein paar alte Hacks ausnutzen, ein paar neue Hats und ich hoffe, wir haben ganz viel Spaß zusammen. Ich möchte anfangen und mich bei ein paar Leuten bedanken, die die harte Arbeit gemacht haben, Wege herauszufinden, wie man diese Benutzerkonten ausnutzen kann. Diese Leute sind wir, Schroeder, Madnessen, Alan Shamir und Dirk John. Aber es gibt natürlich noch viele viele andere, die im Laufe der Jahre viel viel Zeit da rein gesteckt haben. In diesen Active Directory Service sich einzutauchen und ja, ihr habt einen riesigen Teil der Arbeit übernommen. Und ich möchte auch meinem Chef danken oder meinem Unternehmen, weil es echt toll ist, seine eigene Arbeit zu machen, ohne sich Sorgen, um die Bezahlung machen zu müssen. Wir möchten mit alter Technik anfangen, die Teil von Microsoft Active Directory ist und das ist NTLM. NTLM steht für New Technology Lahn Manager und es wurde in Windows NT4 eingeführt, 1996. Also diese Protokolle sind älter als ich, also es ist wirklich antiker Zeug. Das ist ein Protokoll Suite für Sicherheit. Es gibt ja viel, viel verwirrende Thermologien, wenn es über diese Technologie gesprochen wird. Und wir haben hier ein Haufen ganzes Paket von verschiedenen Protokollen, die uns ermöglichen, über das Netzwerkssicher zu kommunizieren. Also, ja, signiert Protokolle und das ist dafür bekannt für den NTLM-Hash. Das ist halt der Hash für das Passwort und jeder, der bisher Mini-Cards verwendet hat, hat wahrscheinlich sein eigenes Hash von seinem eigenen Passwort ausgegeben. Und es gibt ziemlich viel Aufruhe über solche Hash-Attacken, aber da werden wir jetzt nicht konzentrieren. Das einzige Wichte von NTLM ist, dass es dieses Challenge-Respond-Protokoll gibt. Ja, die Art, wie solche Protokolle im Allgemeinen funktionieren, ist, es gibt ein geteiltes Geheimnis zwischen dem Klein- und dem Server, also etwas, was beide kennen. Und deshalb können beide eine Berechnung machen, basierend auf irgendeiner Zufallszahl und beide von denen bekommen die gleichen Ergebnisse. Also, die Art, die das funktioniert, wie man auch auf diesem Diagramm sehen kann, ist, wenn der Klein sich gegenüber dem Server authentisieren möchte, dann sendet der Server eine Zahl zurück, eine Server-Challenge und beide von denen berechnen, also machen dieselben Berechnungen zusammen, basierend auch auf dem geteilten Geheimnis, also in dem Fall das Benutzerpasswort. Und hoffentlich kriegen Sie das selbe Ergebnis und der Klein sendet die Antwort von dieser Herausforderung an den Server zurück und der Server kann das verifizieren. Und in Version 2 gibt es auch noch einen zweiten Klein-Challenge-Step, also nicht nur der Server weiß, dass der Klein das Geheimnis kennt, sondern auch der Klein kann verifizieren, dass der Server das den Secret auch kennt. Also für diese Präsentation werde ich ein paar Fußnoten haben hier unten. Das sind Dinge, die zwar interessant sind, aber nicht zum Rahmen für diesen Vortrag gehören. Also mehr etwas, was man sich anschauen kann, wenn man sich die Slides nachher anguckt oder wenn ich etwas rede, was euch nicht interessiert. Naja, also das Ding damit ist halt, dass Sie häufig verwundbar sind zu Relay-Attacken, also Relay-Angriffen und netntlm ist da keine Ausnahme. Also wie kann dieses Relay-Angriff funktionieren? Was wichtig dafür ist oder was wichtig in diesem Diagramm ist, dass das erste Ding, was hier passiert ist, dass der Klein versucht, sich gegenüber dem Angreifer zu authentisieren. Das ist dieses Ding in der Mitte. Also der Klein sagt, ich möchte mich gegenüber von dir authentisieren und anstatt dass der Angreifer jetzt seine eigene Herausforderung generiert, schickt ja das weiter an den Server und sagt dem Server, hey ich möchte mich gegenüber dem Server authentisieren, ohne diesen Shared Secret zu können. Also er bekommt seinen eigenen Server-Challenge vom Server und leitet das weiter an den Client und kann jetzt quasi den Client dazu verwenden, die Antwort darauf zu generieren. Also der Klein versucht sich mit dem Angreifer zu verbinden und der Angreifer wird das halt, wird sich standardgemäß erhalten und dann bekommt er vom Client die Antwort, die er den Server weiterleiten kann. Und ja selbst wenn da ein zufälliger Client-Challenge ist, wir können das völlig ignorieren, ob der Klein den Server authentisieren kann oder nicht. Wir möchten einfach nur gegenüber dem Server authentisiert sein und können danach die Verbindung mit dem Klein trennen und sagen, irgendwas ist schief gegangen. Also ja, die zwei wichtigen Dinge, die man aus diesem Diagramm herausziehen kann über das Relaying ist, das in diesem Szenario, der hat der Angreifer überhaupt keine Ahnung von diesem Geheimnis und dem Nutzerpasswort. Selbst wenn diese Challenge-Response-Berechnung durch irgendwas anderes verwundbar ist, z.B. durch Bootforcing, kann er auch versuchen, das Passwort zu knacken, aber das gibt dem Angreifwärts nicht notwendigerweise ein Erkenntnis über das Passwort. Und wie ich schon gesagt habe, der Klein muss die Verbindung initialisieren. Wir müssen einen Weg finden, um den Klein dazu zu zwingen. Das ist natürlich eine große Sache und das ist schon lange Zeit bekannt. Es gibt auch ein Gegenmaßnahme dafür für NTAMM, nämlich daneben, dass du beweisen musst, dass du ein Teil des Geheimnisses weißt, wird auch daraus der Sitzungsschlüssel generiert. Das heißt, der Angreifer kann den Sitzungsschlüssel nicht generieren und man kann ihn nicht erraten. Und dann, wenn Signierung erforderlich ist, dann muss jede Nachricht mit diesem Session-Schlüssel signiert sein. Das heißt, man kann die Authentifizierung relayen, aber man kann danach nicht kommunizieren. Das heißt, man kann auch keine Nachrichten modifizieren, weil man den Sitzungsschlüssel nicht kennt. Man kann nichts signieren. Aber die interessante Sache ist, dass nicht jedes der Protokoll signiert ist, man kann nicht für jedes Protokoll Signierung entfossen, zum Beispiel SMB und LDAP können das, für Active Directory und so weiter, aber HTTP zum Beispiel kann das überhaupt nicht. Also, wenn man den Client dazu überreden kann, über HTTP an Fragen zu machen, dann weiß man, dass es nie zu Signierversuchen führt, weil es über HTTP einfach nicht funktioniert. Eine andere interessante Sache hier ist, dass die Sitznachricht, die gesendet wird, die Aushandlungsnachricht hat eine Bit-Area von Sicherheitsfeatures, die benutzt werden sollen. Zum Beispiel kann man da sagen, ich möchte überhaupt keine Signierung machen, nur signieren, falls es möglich ist oder immer signieren. Und zum Beispiel auch die Frage, ob man die erste Version benutzen möchte. Diese Nachricht enthält wieder eine Signatur, also ein MIC Message Integrity Code, das heißt, man kann die nicht einfach so modifizieren, abgesehen von Implementierungsbugs natürlich. Zum Beispiel die Drop the Mic Verwundbarkeit, wo man einfach die MIC wegwerfen konnte. Das war aber ein Fehler und wurde schnell gefixt. Das heißt, man kann nicht einfach mit Hilfe dieser Nachricht das Protokoll herunterstufen auf die letzte Version. Das ist anders als SMB. In SMB, das heißt, wenn man jetzt über SMB eine Verbindung macht und da im Kleinen drin steht, macht Signing, wenn das möglich ist. Selbst dann kann man als jemand in der Mitte nichts dagegen tun, weil die Nachrichten sind alle signiert und dann handelt der Server einfach Signierung auf. Das heißt, man kann das nicht einfach wegwerfen, diese Signierung. So, jetzt kommen wir doch mal zum Titel des Talks. Denn jeder Domaincomputer hat auch Benutzerkonten. Ich werde in diesem Vortrag jetzt über Accounts reden, wenn Sie in einem Active Directory drin stehen und Maschinen konnten einfach für die, die lokal sind. Man kann das jetzt hier erkennen, indem das ein... Das kann man daran erkennen, dass die User-Accounts mit Dollarzeichen enden. Es gibt nicht so viele Unterschiede zu normalen Accounts. Es ist hauptsächlich, dass die Maschinen-Accounts zufällige Passwords haben, sogar mit ungültigen UTF-16-Zeichen. Ich weiß nicht genau, wie das ist, aber man kann es nicht blutforsten. Ansonsten können Sie genau die gleichen Dinge tun, wie normaler Accounts. Es kann NTRML authentifiziert werden, es kann Kerberos-Tickets bekommen und es kann ein Ziel dieser Attacke sein, die ich gerade diskutiert habe. Die große Frage ist, können wir einen Computer übernehmen, indem wir die Maschinen authentifiziert werden können. Was können wir damit noch haben? Wohin können wir das irgendwo umleiten, um damit etwas zu machen? Das war jetzt eine offene Frage für eine sehr lange Zeit. Erst in den letzten und diesem Jahr haben wir ein bisschen was in diesem Thema gesehen. Um das zu beantworten, müssen wir noch etwas an schauen und das ist Kerberos. Kerberos ist ein Protokoll, um somitische Schlüsse zu verteilen. Es ist sehr kompliziert, es wurde von MIT entworfen und Microsoft hat viel dazu beigetragen. Es ist ziemlich komplex, ein komplexes Beast. Es ist ein Thema, das sich sehr vereinfachen werde und uns keine Gedanken machen über die Schlüsselverteilung. Wir werden uns nur Gedanken darüber machen, wie die Authentisierung in diesem Protokoll funktioniert. Also, ja, seit Pferd zu mir, wenn ich versuche, hier die Basics zu erklären. Ja, genau, da war kurz das Audio weg. Das Erste, was man darüber wissen sollte, ist, was ist ein TGT? Es ist ein Ticket granting Ticket, also ein Ticket, das ist ein Beweis, das man benutzen kann, um später Tickets für verschiedene Dienste zu erhalten. Also, das ist hier ein Vergleich zu einem Freizeitpark und wenn man zu einem Freizeitpark geht und fragt, wenn man sich ein Tagesticket kauft für alle Attraktionen, dann kann man das kaufen und kriegt dieses Ticket und wenn man dann später Münzen für so ein Autorescooter oder sowas braucht, dann geht man einfach zusammen zu so einer Bude und zeigt das Ticket vor und bekommt dann im Gegenzug die Münzen, die dann das Ticket für diesen spezifischen Dienst sind. Und warum man TGT verwenden sollte, man muss nur einmal sein Passwort verwenden und dann hat man dieses Ticket, was keinen Bezug zum Benutzerpasswort hat und man kann dieses Ticket dann einfach weitergeben und verwenden und die Identität wird nur einmal überprüft. Also, man muss nur einmal authentisieren und alle anderen Schritte können dann autorisieren. Also, ja, zu diesem spezifischen Nutzer. Und wie man so ein Ticket bekommt, das ist ziemlich einfach. Man fragt einfach danach und der Kerber-Server sagt, hey, du musst identisieren. Also, dann schickt man einen Request diesmal mit dem Passwort oder mit dem Passwort hälschst oder mit dem Key oder irgendwas, was beweisen kann, wer du bist und dann kriegt man sein Ticket zurück. Und der andere Teil von Kerber-Server, nach dem man so ein Ticket hat, sind eben Dienste. Und man sagt jetzt nicht, das Vergleich mit Windows-Diensten, weil da auch die Thermologie einfach doof ist, sondern halt verschiedenen Protokolle, z.B. LDAP ist ein Service, HTTPS ist ein Service, SMB oder CFS ist ein Service, also Dateyservice, Dateitransfer. Jeder dieser Dienste hat so einen SPN, so einen Namen halt, so eine ID, also quasi eine Identifizierungsnummer in der Domain für diesen Service, für diesen spezifischen Service, den man sich gegenüber authentisieren möchte. Also z.B. Beispiele, also LDAP schreckst du durch dc.domain.com, das ist der LDAP-Server auf der Domain-Kontrolle oder CFS-Files.domain.com, das ist dann halt ein Dateitransfer-Dienst auf einem Dateitransfer-Server. Das könnten so NPN sein. Und wenn man seinen Ticket hat, ist das aus der Identifizierung zu einem dieser Dienste sehr einfach, man geht zum Kerber aus und sagt, hey, ich hätte gerne einen Ticket für diesen spezifischen Dienst und zeigt ihm sein Allgemeingültiges Ticket. Deshalb überprüft er das Allgemeingültige Ticket und gibt einem ein spezifisches Ticket zurück, was man dann verwenden kann, um sich gegenüber dem Files-Server z.B. verwenden kann, um sich zu authentisieren. Wie ich bereits gesagt habe, Kerber ist mehr ein Protokoll zum Verteilen von semenischen Schlüsseln. Beim Authentifizierungsteil kriegt man auch noch seinen Schlüssel übergeben, um die Verbindung zu verschlüsseln. Aber das ist jetzt nicht wichtig für diesen Vortrag. Also eine Sache, die alle Sachen, alle komplizierten und ja, also fortgeschrittenen, wie auch immer man das nennen will, Protokolle, die sich mit Authentifizierung beschaffen gemeinsam haben, ist, dass sie einen Weg anbieten, um halt irgendwie, wie man vortauschen kann, dass man jemand anders ist, der man nicht ist. Das haben die alle gemein. Und das ist natürlich nützlich wie Single Sign-On. Also nur eine Anmeldung möglich für verschiedene Dienste. Man verbindet sie zu einem Server und der Server möchte sich mit einem Backup-Server verbinden. Dann kann der Server seine Nutzerdaten verwenden. Das sieht so aus, als wäre man direkt mit dem Backup-Server verbunden und all die Autorisierungen mit den Gruppenlichten hin und so was, die man aufreingesetzt hat, funktionieren einfach von alleine. Also das ist halt was, was Protokolle alle gemein haben. Das ist da keine Ausnahme. Die mächtigste davon ist diese Unconstruent Delegation. Das ist halt auch der Grund, warum sie diesen Namen hat, weil sie halt unangeschränkt ist. Man setzt ein Dienst auf oder ein Computer und alle Dienste auf der Maschine, auf dem Server, auf der Gerät. Also uneingeschränkte Delegation heißt, dass alle Tickets, die das TGT für diese Maschine generiert enthalten, das TGT vom ursprünglichen Nutzer, also dass der Dienst das entschlüsseln kann. Also wenn man ein so ein spezifisches Ticket zu diesem spezifischen Server gibt, kann der das entschlüsseln und kann den allgemeinen Schlüssel da rausrechnen, den man ursprünglich hatte und dann kann man auch, also man hat quasi den Master Ticket, was man dann benutzen kann, um Tickets für andere Dienste zu bekommen. Also der Server kann das aus dem spezifischen Ticket zurückrechnen. Aber standardmäßig werden, weil wenn man halt einen Host kompromittiert, der uneingeschränkte Delegation hat, jedes Mal wenn jemand sich gegenüber diesem Server authentisiert, dann kann man halt sich die ganzen ursprünglichen Sachen holen und man kann natürlich dann einfach sagen, hey, ich bin der Domain-Administrate und alle werden einem glauben. Also hier ist wieder ein kleines Diagramm, wie es funktioniert, genau das gleich, wie man halt ein reguläres Ticket bekommt, er wird, da ist das Ticket in der Antwort also verschlüsselt und der Klein kann das jetzt nicht unterscheiden, ob da jetzt sein originales Ticket drinsteckt oder nicht. Der gibt es einfach nur weiter an den Server und der Server sieht, aha, er hat mir nicht nur ein spezifisches Ticket gegeben, sondern sogar ein allgemeines Ticket und das findet er dann toll. Und das ist ziemlich mächtig, aber halt auch ziemlich gefährlich, weil wenn man jemandem vertraut bei dieser Unconstant Delegation, dann kann der in deiner ganzen Domain rumlaufen und wer jemand anderes. Und deshalb hat Microsoft etwas Engen für etwas Constraint Delegation heißt. Das heißt S4U2 Proxy hier ist das Vertrauen nicht über den ganzen die ganzen Domain, sondern es ist bloß zwischen zwei Diensten, zum Beispiel sagen wir PCA vertraut PCB, dann vertraut jeder Service auf PCA jedem Service auf PCB. Das heißt wenn man TGD hätte, dann könnte man alles machen, aber hier kriegt der vertraute Service nur ein Ticket was es weiter schicken kann weiter schicken kann an den zweiten Server, nachdem man den Key Distribution Server nach einem weiteren Ticket gefragt hat. Das heißt der Server kann dieses Ticket nehmen zum KDC gehen und dort ein Ticket kriegen für denjenigen Service der dem vertraut worden ist. Hier sieht ihr es nochmal in einem Diagramm hier der ursprüngliche Ticket Exchange ist immer noch genauso dann authentifiziert man sich mit dem Service und hier kann die Backup Domain der File Domain vertrauen und dann kann die File Domain den Key Server fragen. Hier der User ist gerade bei mir ein Ticket für den Backup Server kriegen und dann sagt der KDC kein Problem, hier ist das Ticket und dann kann der File Server einfach so tun, als sei der User gegenüber dem Backup Server. Also hier haben wir das gleiche Problem wie vorher und hier ist es immer noch ich weiß nicht wann hier konnte man das nur über vertrauten Maschinen machen und nur von Domain Admins aber jetzt hat Microsoft Ressourcen basierte Constraint Delegation eingeführt das heißt derjenige dem vertraut wird kann jetzt entscheiden wem vertraut wird also wem er vertrauen möchte das heißt jeder Service kann selber entscheiden wem er vertraut möchte das heißt das können wir jetzt für unseren Angriff benutzen dann können wir nämlich dann können wir ihm nämlich sagen dass er allen anderen Computern trusten sollen jetzt fehlt noch ein kleines Stückchen was ein kleiner witzige Sache ist es gibt nämlich noch es gibt noch eine andere Art von Delegation nämlich man kann zwischen um Protokollen zu wechseln jeder Service kann normalerweise Tickets jeder Service kann normalerweise Tickets jeder Server kann Tickets für jeden Service generieren einfach egal was der User ist es kann einfach für jeden User für sich selber Tickets generieren das heißt diese Tickets diese Tickets können dann sogar als Beweis für U2 Proxy verwendet werden das heißt man kann das benutzen um den auf die Maschinen zu greifen die einem selber vertrauen so was ist der Plan für unsere Attacke das heißt wir müssen irgendeine Maschine übernehmen dann suchen wir eine Auffahrmaschine die sich gegenüber uns identifizieren möchte mit NTRM dann relayen wir die Zugangsdaten dann benutzen wir das um das Opfer dazu zu bringen uns zu vertrauen dann kriegen wir ein ticket granting ticket und dann nehmen wir dann kriegen wir erstmal ein atmospheric ticket und dann gehen wir über die S4 U2 Proxy das nutzen um ein atmospheric ticket zu bekommen so wie können wir überhaupt eine Domainmaschine übernehmen interessanterweise standmäßig jeder Account kann im Domain bis zu fünf Maschinen zur Domain hinzufügen jeder vernünftige administrator hat das natürlich deaktiviert aber wenn man eine Domain hat die das aktiviert hat dann kann man einfach zum Domaincontroller gehen und eine neue Maschine hinzufügen und dann ist das alles was man braucht sogar Maschinenaccounts können was machen das heißt wenn man das macht dann kann man den ersten Schritt überspringen man kann einfach direkt zum dritten Schritt gehen das Opfer dazu bringen LDAP zu benutzen und dann hat man einfach eine Maschine gebaut und sie als vertraut markiert ansonsten nimmt man einfach irgendeinen Exploit zum Beispiel Eternal Blue man bootet und wie ein Kali auf einer existierenden Workstation und so weiter solange das nicht mit BitLocker verschlüsselt ist funktioniert das eigentlich ganz gut das war alles relativ einfach aber der harte Teil der jetzt noch fehlt ist die ganzen anderen Details von den Maschinen also wenn irgendwelche Ideen haben wie man das machen könnte könnt ihr das uns gerne sagen weil dann sind wir, da würden wir uns sehr freuen beim Moment ist der beste Weg den wir haben ist halt eine Manual-Mittel-Attack das beste was bisher immer von uns nett hat ist halt ein physikalisches Manual-Mittel wo man halt wirklich den Computer nimmt wenn man wirklich physisch ein Zugriff hat man nimmt diese Maschine, schließt sie an seinen eigenen PC wo man ein DHCP-Server aufläuft und der so konfiguriert dass alle Adressen, alle Anfragen auf den eigenen Computer weitergelattet werden und ja irgendwann irgendwann wird Windows irgendwelche Updates das runterladen, unverschlüsselt und sich mit seinen Benutzerpasswort bei den Updates attentifizieren man kann auch eine andere Attacke verwenden MIT M6 was es halt ein ziemlich interessantes Projekt ist wenn das Netzwerk wo man ist kein IPv6 benutzt kann man die meisten Windows Computer versuchen trotzdem einen IPv6 DHCP-Server zu finden kann man seinen eigenen DHCP-V6-Server starten und einen DNS-Server konfigurieren und weil Windows IPv6 gegenüber IPv4 bevorzugt wird Windows wahrscheinlich den eigenen IPv6-Server verwenden anstatt den IPv4-Server der Netromain verwendet werden soll aber es gab auch einige lustige und merkwürdige Sachen die da aber ins Enchantement sind zum Beispiel kann man sein Hintergrundbild oder sein Profilbild verändern wenn man sein Profilbild ändert dann wird es mit dem Maschinenkonto heruntergeladet mit einem Protokoll DHCP-Server was ein Dateizugiff über HTTPS also es ist ziemlich zuverlässig man kann halt sein Log-Scream zu irgendeinem Dateifahrt Web-Def-Relay at 80 slash folder slash Dummy.NET BG ändern und dann versucht der Server sich da eben zu authentisieren und dann kann man dabei das benutzele Passwort mitschneiden das ist der Printerbug also bug ist in diesem Fall in Anfangszeichen, weil Microsoft behauptet es wäre absolut so und es wäre eine Funktion da ist dieser Remote Prozedur Aufruf RPC Remote Fine First Printer Change Notification X und was das macht ist, es fragt den Computer sich, oder es bittet nicht darum sich gegenüber einem anderen Server zu registrieren als eine Benachrichtigung also wenn irgendwas passiert mit irgendeinem Printart z.B. wenn der Drucker kein Papier mehr hat dann wird das weitergelegt und weil diese Nachricht über SMB vermittelt wird, heißt das, dass wenn man sich selbst da registriert auf dieser Remote Maschine als so ein Benachrichtigungshändler dann wird das versuchen sich mit der über SMB zu verbinden mit dem Maschinen-Konto also wenn ich mich selber in den Notifikations-Listen da registriere dann werde ich eine SMB-Verbindung erhalten die meisten fragen natürlich nach Signatur, also nach Signierung also es ist nicht so zuverlässig wie also wenn die Maschine darum bittet das zu signieren, dann hat man eben signierte Nachrichten und man hat keine Möglichkeiten da die eigenen Nachrichten reinzubauen aber es gibt noch einen weiteren Exploit also der macht zwei Aufrufe erst mal Open Printer und dann den zweiten den wir gerade schon gehört haben und Open Printer ist halt erforderlich um erst ein Händel zu bekommen um die anderen Protokolle zu verwenden und dann also es authentiziert sich als der Drucker und nicht als der Listener und wie das funktioniert ist wenn man eine Authentisierung möchte, verbindet man sich mit dem Wittmar mit dem Opfer verwendet diese Open Printer Aufrufe und dann verwendet man diesen First-Find-First-Printer-Channel-Statification-X mit dem eigenen Computer und ich habe da ein paar Dokumentationen drüber gefunden und was ich interessant habe ist der das Printer-Name-Pattern ist so definiert nicht only hat man nicht nur den Servernamen und Local-Printer-Name sondern da ist auch noch etwas wie ein HTTP funktioniert Naja, HTTP ist besser wenn man wenn man jetzt den Printer von Self zu einem HTTP-Aufruf verwendet das ist jetzt hier ein Log wo man das sehen kann ich habe natürlich ein paar Sachen sensiert aber das ist das erste mal wo mir das passiert ist was ich hier gesehen habe ist hey HTTP Connection also da wurde eine Authentizierung über HTTP als der Maschinen-Munzeig-Account verwendet also über HTTP also unverschlüsselt das Relay hat nicht geklappt aber hey, das ist großartig und in dem Moment habe ich den Vortrag für den CCC eingereicht und ich habe es immer wieder versucht zu reproduzieren aber es hat einfach nicht funktioniert also diese zwei Zeilen die ich hier ausgewärzt habe sind die die so wichtig sind also die Zugangsdaten sind über SMB über Metropode und nicht über HTTP also was ist genau passiert ich habe eine ganze Menge Zeit so verwendet das zu debaggen und ich habe diesen Call zu Feind for Splinter Detention Innovation Unmodified also der remote-Computer hat sich über HTTP verbunden aber hat keine SMB mit einem neuen Passwort verbunden, was sich nicht wirklich was gebracht hat und man kann halt den regulären SMB aufrufen weil es halt Multifolding ist konnte ich das jetzt nicht genau debaggen aber am Ende hat es dann funktioniert also das wirkte wie ein totes Ende und hier konnte man keine Modangriff daraus bekommen der dazu führt, dass Computer sich über HTTP authentisieren also ich habe hier eine Demonstration also hoffentlich wird die Demonstration beweisen, dass es wirklich klappt also wir werden erst einem neuen Computer zu der Dominion zufügen dann werden wir diese physikalische Medial Attack verwenden um das Opfer zu uns authentisieren mit NLM und dann werden wir sagen dass wir allen anderen Quedentions von allen anderen Maschinen vertrauen sollen und dann werden wir uns ein Ticket dafür holen um auf dieser Maschine uns einzuloggen und können uns dann als Administrator mit der Maschine verbinden hier ist die Opfermaschine Desktop, ganz langer Lame und hier habe ich eine Kali Maschine die zwei Accounts hat einer ist zu der Domain verbunden und das andere ist ein DHCP Server der ganz viele der dafür sorgt, dass zu mir verbunden wird so hier nehmen wir mal an ich hätte ein Account ein unprivilegten Accounts zu der Maschine hier haben wir dann ein Maschinen-Account mit diesem Passwort bekommen was wir jetzt machen möchten ist den DNS Server benutzen das ist jetzt bloß ein DNS Server dann starte ich noch den NTML Relay wo ich zu den Domain Commutor Relay auf LDAP und dann möchte ich noch den Zugriff delegaten zu diesem Computer jetzt mache ich einfach das was ich gesagt habe was ich tue nämlich den das Netzwerk wechseln zu dem DHCP Server und dann starte ich den Computer neu hier gab es schon ein paar Windows Update Sachen ich frage mich zwar warum Windows Update über DHCP macht das ist mir überhaupt nicht klar aber jetzt rebooten wir erstmal warten wir mal ein bisschen Windows startet wenn wir jetzt uns das anschauen dann haben wir schon erfolgreich die Credentials Relay die die Zugriff starten Relay und hier irgendwann im Lock gibt es dann noch die Nachricht dass wir als dieser Person gegenüber dem anderen Service den Nutzer impersonieren können also jetzt probieren mal ob das Ticket was wir weitergeben tatsächlich korrekt ist jetzt habe ich hier noch so ein Script was uns Tickets gibt also hier wollen wir ein Ticket für ZIFS auf dem Desktop haben Administrator impersonieren und dann möchte ich als die Maschine mich identifizieren die wir da oben hinzugefügt haben das ist das Passwort der Maschine und jetzt habe ich ein Administrator auf der anderen Maschine dann mache ich jetzt hier so ein Secret Dump ich hole mir die Geheimnisse von der Maschine und wenn ich das jetzt laufen lasse dann passiert nichts jetzt habe ich das falsche Netzwerk verbunden das mache ich mal kurz wieder ganz Neuer Versuch und hier sind die Zugangsdaten wir haben uns erfolgreich gegenüber der Zielmaschine als Administrator ausgegeben das ist jetzt nicht gut was können wir dagegen tun das Problem ist das meiste ist so gedacht in Kerberos Kerberos wird nicht geändert das ist so sinnvoll die Idee die man vielleicht verfolgen könnte ist dass man die eigenen Tickets nicht benutzen kann um für andere Maschinen sich zu identifizieren die einzig mögliche Gegenmaßnahme ist eigentlich Relang zu verhindern letzte Woche hat gerade Microsoft ein Adversary rausgegeben dass man LDAP Signierung verwenden sollte was man jetzt noch zusätzlich tun kann ist dass man die kritischen Benutzer zu den geschützten Nutzern hinzufügen kann oder die Eigenschaft setzen das ist jetzt das Ende der Präsentation ein großer großer Fail ist passiert aber was passiert halt so ich würde mich sehr freuen mit euch zu reden später auf dem PC Camp oder auf Twitter und wir suchen immer noch nach neuen Wegen die Maschinen einen Weg zu finden die Maschinen zu uns zu identifizieren also falls ihr irgendwelche Fragen habt ja eine runde Applaus für hier gibt es irgendwelche Fragen gibt es eine Frage aus dem Internet keine Fragen aus der Audienz niemand aus dem Publikum 2 1 3 2 1 noch mal eine warme Runde Applaus thank you