Kategorie: Erklärer

Öffnest du die Motorhaube eines modernen Autos, um das Bremssystem zu verstehen, siehst du tausende Kabel, Schläuche und Steuergeräte – aber wo genau sitzt die Logik, die bei einer Vollbremsung die Räder blockiert? Genau so geht es Entwicklern, die den Quellcode eines KI-Agenten studieren. Sie sehen Tausende von Dateien, aber die entscheidende Frage „Fragt der Agent den Benutzer, bevor er eine Datei löscht?“ ist nicht auf einen Blick zu beantworten.

Das Problem ist nicht fehlender Code. Es ist die fehlende Verbindung zwischen was das System tut (seinem Verhalten) und wo dieses Verhalten im Code umgesetzt wird. Ein Forscherteam um Ruhan Wang von Tencent HY LLM Frontier entwickelte dafür das Harness Handbook. Es ist kein weiterer Code-Index, sondern eine navigierbare Verhaltenslandkarte. Sie ordnet den verstreuten Implementierungscode in logische Verhaltenseinheiten und verknüpft jeden Schritt mit überprüfbaren Codebelegen. So können Entwickler, Auditoren und andere KI-Agenten das System verstehen, überprüfen und anpassen – ohne sich durch 2000 Dateien quälen zu müssen.

Warum ein Agenten-Harness ein Handbuch auf Verhaltensebene braucht

Bei KI-Agenten denken wir oft zuerst an die Fähigkeiten des Modells. Sobald der Agent echte Arbeit erledigt, verschiebt sich die Frage: Nicht „Was kann das Modell?“, sondern „Was erlaubt das System dem Modell zu tun?“. Ob ein Befehl ausgeführt wird, ob der Benutzer um Erlaubnis gefragt wird oder ob ein Fehler abgefangen wird – das entscheidet nicht das Modell allein, sondern der sogenannte Harness, die ausführende Hülle um das Modell herum.

Ein solcher Harness ist nicht trivial. In einem Produktionssystem wie Codex – hier als Beispiel – koordiniert der Harness das Modell, die Werkzeuge, den Zustand, die Berechtigungen und die Ausführungsumgebung. Das Ergebnis: 2.267 Dateien, über 34.000 Funktionen und fast 160.000 Code-Verbindungen. Eine klassische Dateistruktur zeigt nur, wo Code liegt, nicht wie die Teile zusammenwirken, um ein bestimmtes Verhalten zu erzeugen. Suchst du nach „delete“ oder „confirm“, erhältst du Fragmente, die du mühsam zusammensetzen musst.

Besser: Starte beim Verhalten und folge den Spuren zurück zum Quellcode. Genau das bietet das Handbook. Es erfüllt drei Zwecke: Verstehen – wie der Harness einen Benutzerauftrag durchläuft. Auditieren – ob die Sicherheitsversprechen der Dokumentation tatsächlich im Code eingehalten werden. Anpassen – um einen eigenen Agenten auf Basis des bestehenden Harness zu bauen. Alle drei Zwecke beginnen mit einer konkreten Verhaltensfrage und enden im Code als Beleg.

Warum ist ein Verhalten an so vielen Stellen verstreut?

Die Regel „Frage den Benutzer, bevor du eine Datei löschst“ klingt einfach. Um sie im Code zu überprüfen, musst du eine Kette von Entscheidungen nachvollziehen: Fordert das Modell eine Bestätigung an? Kann der Werkzeugaufruf abgefangen werden? Wo wird die Benutzerantwort gespeichert? Unter welchen Bedingungen wird die Löschung endgültig ausgeführt? Jedes Glied dieser Kette kann das Ergebnis verändern.

Ein Verhalten wird nicht von einer einzigen Funktion entschieden. Es wird gemeinsam von Prompts, Tool-Wrappern, Berechtigungskonfiguration, Zustandsverwaltung, Sandbox-Ausführung und Fallback-Pfaden bestimmt. Es gibt keine Funktion confirmBeforeDelete(). Du musst Prompts, Wrapper, Berechtigungen und Zustand bis zur Sandbox-Ausführung und zu den Ausweichpfaden verfolgen, bevor du sagen kannst, ob die Anfrage ausgeführt, abgelehnt oder in einen anderen Fluss umgeleitet wird.

Die Forscher nennen diese Suche Behavior Localization. Die Vollständigkeit der Rekonstruktion bestimmt die Qualität der Erklärung, der Risikoanalyse und der Änderungsgrenzen. Das Harness Handbook verwandelt diese versteckten Verhaltensketten in eine Karte, die du Schicht für Schicht durchblättern und gegen den Quellcode prüfen kannst.

Harness Handbook: Eine navigierbare Verhaltenskarte

Da ein einzelnes Verhalten viele Implementierungsorte haben kann, kann das Handbook nicht einfach den Dateibaum neu verpacken. Stattdessen stellt es den Harness aus Verhaltensperspektive dar, mit drei Ebenen – L1, L2, L3 – die die Frage Schritt für Schritt eingrenzen. Jede Ebene bewahrt überprüfbare Codebelege, sodass du jede Erklärung nachvollziehen und spätere Änderungen im Quellcode verankern kannst.

L1 – Systemüberblick: Statt Dateien und Funktionen aufzulisten, folgt L1 einem Benutzerauftrag durch das gesamte System: Wie tritt der Auftrag ein, welche Stufen durchläuft er, wie bewegt sich der Zustand zwischen ihnen, und wie wird die Modellausgabe zu einer echten Aktion? Sie beantwortet zuerst: Wie läuft dieser Harness im Ganzen ab?

L2 – Verhaltenseinheiten-Überblick: Diese Ebene zerlegt den Systemablauf in Verhaltenseinheiten. Jede Einheit erfasst eine zusammenhängende Klasse von Verhalten und dokumentiert ihre Verantwortlichkeiten, Ein- und Ausgaben, Abhängigkeiten und Schlüsselzustände. Auf dieser Ebene siehst du, wie komplexes Verhalten zerlegt wird und wie die Teile im Gesamtablauf wieder zusammenhängen.

L3 – Verhaltenseinheit im Detail: Hier zoomst du in eine einzelne Einheit hinein: Wann ein Verhalten ausgelöst wird, wie es ausgeführt wird, wie sich der Zustand ändert, welcher Pfad nach einer Ausnahme oder einem Fehler genommen wird und welche Dateien und Funktionen den Beleg liefern. „Vor dem Löschen einer Datei bestätigen“ ist keine allgemeine Regel mehr, sondern eine überprüfbare Kette einzelner Entscheidungen.

Ein konkretes Beispiel aus der Arbeit der Forscher: Die L3-Einheit für „Bestätigung vor Dateilöschung“ listet auf, welcher Trigger (das Modell sendet delete_file(path)), welche Berechtigungsregel (Dateilöschung ist als risikoreich markiert), welche Zustandsänderung (Bestätigungsanfrage und Antwort werden aufgezeichnet), welcher Ausführungspfad (Benutzer genehmigt → Sandbox-Runner, Ablehnung → Abbruch) und welche Randfälle (Headless-Modus, Auto-Approval) relevant sind. Für jeden Schritt gibt es Code-Belege wie tools/file_ops.py:32-78.

Wie wird die Verhaltenskarte aus dem Code erzeugt?

Damit das Handbook vertrauenswürdig ist, darf

Quelle: ruhan-wang.github.io

Du installierst eine neue Software, liest dich durch eine ellenlange Dokumentation und fühlst dich wie ein Tourist ohne Karte. Die meisten Produkte setzen darauf, dass du dir das Wissen selbst aneignest. Bei MCPs – Model Context Protocols – war das bisher nicht anders. Doch das ändert sich gerade.

Der Autor des ursprünglichen Beitrags, Moe, CTO bei Webhound, hat in den letzten Wochen gearbeitet, das Onboarding seines Produkts für KI-Agenten nahtlos zu gestalten. Er entdeckte mehr als nur eine Verbesserung. Der Nutzer interagiert nicht mehr direkt mit dem Produkt, sondern ein Agent übernimmt: Er erfasst die Absicht des Nutzers und setzt sie auf einer vom Produkt bereitgestellten Oberfläche um. Das wirft bisherige UX-Prinzipien über den Haufen – Touchpoints, Edge Cases, Frustrationsquellen. Es entsteht ein völlig neues Problemfeld.

Der Fehler der traditionellen MCP-Dokumentation

MCPs haben ihre Nutzer beim Einstieg oft vernachlässigt. Die meisten setzen auf API-Dokumentation, die man mühsam durcharbeiten muss. Niemand liest freiwillig Endpunkt-Beschreibungen, nur um ein Tool zum ersten Mal zu benutzen. Moe hält das für falsch. Onboarding soll den Umgang mit dem Produkt vermitteln. Die besten Beispiele haben immer das Produkt selbst in den Onboarding-Prozess integriert. Warum bei MCPs anders?

Seine Lösung ist einfach: Er baute ein Onboarding-Tool direkt ins MCP ein. Es führt den Agenten Schritt für Schritt durch die erste Nutzung. Danach kennt der Nutzer das Produkt und hat bereits einen echten Mehrwert daraus gezogen. Der Agent navigiert den Nutzer sicher durch den Einstieg – ohne dass vorher die Landkarte studiert werden muss. Das ist bequemer und effektiver.

Den Arbeitsbereich des Nutzers verstehen

Jeder Nutzer hat eine andere Arbeitsumgebung, andere Ziele und Motivationen. Jede Sitzung eines Agenten startet mit anderen Gedanken. Der Arbeitsbereich sollte so eingerichtet sein, dass der Nutzer den größten Nutzen aus dem Produkt zieht. Agenten sind darauf programmiert, Code zu schreiben und einen Rechner zu bedienen – sie brauchen nur die richtigen Anweisungen. Diese Anleitung muss das Onboarding liefern.

Moes Ansatz: Der Onboarding-Prozess fordert den Agenten auf, den Nutzer um Erlaubnis zu bitten, eine Meta-Analyse des Arbeitsbereichs durchzuführen – komplett lokal, ohne dass Daten an den Server gesendet werden. Danach gibt der Agent Vorschläge, wie der Nutzer seine Umgebung anpassen kann, um das volle Potenzial des Produkts zu nutzen. Stimmt der Nutzer zu, führt der Agent die Änderungen aus. Das respektiert die Privatsphäre und schafft Vertrauen. Vertrauen ist die Grundlage jeder Beziehung.

Das erste Vertrauen als Kipppunkt

Moe ist überzeugt, dass der Moment des ersten Vertrauens entscheidet, ob ein Nutzer bleibt. Die Bitte um Erlaubnis ist ein Teil davon. Ein noch größerer Teil – vor allem wenn man die lokale Arbeitsumgebung verändert – ist die einfache Rückgängigmachbarkeit. Ein funktionierendes Produkt unterscheidet sich von einem Virus dadurch, wie leicht man es wieder loswird. Deshalb sollte jedes MCP so gestaltet sein, dass es sich mühelos deinstallieren lässt.

Für sein Team hat Moe einen Endpunkt geschaffen, der dem Agenten die gleiche Schritt-für-Schritt-Anleitung bietet – nur diesmal rückwärts. Der Agent entfernt alle Regeln, Dateien und Einstellungen, die das MCP mitgebracht hat, und löscht sich selbst. Der Nutzer kann jederzeit zum Ausgangszustand zurückgehen, ohne Angst haben zu müssen, dass sein System verseucht bleibt. Das zeigt Respekt für die Kontrolle des Nutzers über sein Gerät.

Ein lebendiges Dokument für die Hilfe

Moe betont die Bedeutung eines sogenannten „Company Brains“. Viele Unternehmen haben umfangreiches Wissen in Code-Kommentaren und internen Dokumenten gespeichert. Ein Agent, der darauf zugreifen kann, kennt das Produkt so gut wie die Entwickler selbst. Falls so etwas noch nicht existiert, reicht es, den Agenten zu öffnen, ihm per Sprache das gesamte Wissen über das Produkt zu diktieren und ihn den Code analysieren zu lassen. Das schafft einen Kontext.

Diesen Wissensschatz sollte man über das MCP zugänglich machen: einen Help-Endpoint, der FAQ, Produktinfo und alles andere enthält, was Nutzer fragen könnten. Und das Ganze sollte ein lebendiges Dokument sein – regelmäßig aktualisiert, mit neuen Erkenntnissen und Feedback der Nutzer. Wenn ein Agent sofort die richtige Antwort parat hat, schätzt man das Produkt. Es wirkt wie ein persönlicher Assistent.

Ein realistischer Blick in die Zukunft

Agenten-Erst-Interfaces sind noch neu. Moe selbst räumt ein, dass seine Erkenntnisse in Zukunft widerlegt werden könnten. Sollte das passieren, würde er den Fehler eingestehen und das Produkt anpassen. Das zeigt Demut und Offenheit für Diskussion. Er lädt alle ein, ihre Gedanken zu teilen.

Für den Nutzer bedeutet das: Die Tür steht offen. Produkte, die MCPs auf diese Weise gestalten, respektieren Zeit, Privatsphäre und Arbeitsumgebung. Man muss nicht mehr stundenlang Dokumentationen wälzen, sondern wird direkt in die Nutzung geführt. Der Agent wird zum Verbündeten, nicht zum Hindernis. Und wenn es nicht passt, verschwindet er spurlos.

Das klingt nach einer menschenzentrierten Technologie. Der Einstieg ist nicht mehr Hürde, sondern Beginn einer produktiven Zusammenarbeit. Das macht MCP Onboarding zu einer interessanten Entwicklung – wegen des menschenzentrierten Ansatzes.

Wer ein Produkt mit diesen Prinzipien nutzt, wird sich fragen, warum es nicht schon immer so war. Bisher stand das Produkt im Mittelpunkt, nicht der Mensch. Das ändert sich jetzt. Das ist ein Fortschritt.

Quelle: moekhalil.substack.com

Du kaufst eine teure Küchenmaschine, aber hast kein Rezept und keine Ahnung, wie sie funktioniert. Was bringt dir das Gerät? Nichts. Mit KI-Modellen ist es ähnlich. Unternehmen hören ständig von neuen Sprachmodellen. Entscheidend ist nicht, welches das beste ist, sondern wie sie es gewinnbringend einsetzen. Hier liegt ein Milliardengeschäft, das jetzt Gestalt annimmt.

Anthropic, das Labor hinter Claude, hat mit Blackstone, Hellman & Friedman und Goldman Sachs ein Joint Venture gegründet: Ode. Die Firma soll KI in Unternehmen implementieren. 1,5 Milliarden Dollar schwer, versteht sich Ode als Übersetzer zwischen Technologie und betrieblicher Realität. Die Beteiligung der Private-Equity-Häuser ist kein Zufall. Sie wollen ihre Portfoliounternehmen produktiver machen und sehen in Ode den Schlüssel dazu.

Die Idee entstand bei Blackstone. Der Finanzinvestor sah, dass große Beratungshäuser und kleine KI-Boutiquen oft an der Umsetzung scheiterten. Eine Boutique, Fractional AI, stach hervor. Ode übernahm Fractional und machte sie zum Kern. Fractional hatte zuvor mit OpenAI zusammengearbeitet. Chris Taylor, CEO von Ode und Mitgründer von Fractional, sagt: „Wenn wir richtig umsetzen, könnte dies irgendwann ein Billionen-Dollar-Unternehmen werden.“ Nicht das Modell ist der Hebel, sondern die Dienstleistung drumherum. Taylor betont: Nicht-KI-Unternehmen können große Gewinner sein, wenn sie die Technologie richtig adaptieren.

Ode beschäftigt rund 100 Ingenieure. Das Team arbeitet eng mit Anthropics angewandter KI-Abteilung zusammen, um maßgeschneiderte Systeme zu entwickeln. Anders als reine Beratung geht es um technische Umsetzung: Code, Integration, Testing. Ein idealer Kunde ist ein Unternehmen, dessen CEO persönlich von der KI-Transformation überzeugt ist. „Vieles, was wir tun, ist die oberste Priorität des CEOs“, sagt Taylor. Es geht um die wichtigsten Produktfeatures der nächsten zwei Jahre oder die Neugestaltung zentraler Geschäftsprozesse. Das ist kein Experiment am Rande. Die Private-Equity-Partner führen ihre Portfoliounternehmen als Kunden zu, doch der Markt steht allen offen.

Eine Besonderheit: Ode arbeitet „Claude-first“ mit Anthropics Technologie. Aber die Firma ist nicht dogmatisch. Wenn ein anderes Modell besser passt, wird es genutzt. Eddie Siegel, Chief Technologist bei Ode, erklärt: Die Modellauswahl sei nur eine Zutat in einem komplexen System – vergleichbar mit der Wahl zwischen Python und Java. Nicht unwichtig, aber nicht entscheidend. Die wahre Kunst liegt in der Qualität der Implementierung. Siegel spricht von „erwachsenen Ingenieuren“ – Spezialkräften, die ein Problem von Anfang bis Ende verstehen und lösen können. Über die Hälfte des Teams sind ehemalige Gründer, die unternehmerisch denken gelernt haben. Diese Denkweise erinnert an die alte Schule der Softwareentwicklung, wo man das volle Problem löste.

Quelle: techcrunch.com

Du vertraust einem Sicherheitsdienst, der dein Haus bewachen soll. Du gibst ihm die Schlüssel. Er soll nach Einbrechern Ausschau halten. Doch der Dienst entpuppt sich als Schläfer und öffnet den Einbrechern selbst die Tür. So funktioniert die Technik, die wir besprechen: Die Antimalware Scan Interface (AMSI) von Microsoft ist ein neutraler Vermittler zwischen Skript-ausführenden Anwendungen wie PowerShell und den installierten Antiviren- oder EDR-Lösungen. Sie soll bösartige Inhalte abfangen, bevor sie ausgeführt werden. Die Architektur hat eine unbeabsichtigte Schwachstelle: Drittanbieter können eigene AMSI-Provider registrieren. Hat ein Angreifer erst Administratorrechte auf einem System, manipuliert er diese Funktion und installiert einen fingierten Provider. Bei jedem Aufruf von PowerShell – oder jeder anderen AMSI-fähigen Anwendung – löst er eine eigene Aktion aus. Das ist keine theoretische Gefahr. Ein öffentlich verfügbarer Proof-of-Code zeigt, wie es funktioniert. Der Angreifer registriert eine DLL mit einer speziellen Scan()-Methode. Bei bestimmten Schlüsselwörtern (einem Trigger) führt sie beliebigen Code aus – etwa eine Verbindung zu einem Command-and-Control-Server. Das geschieht im Hintergrund, der Benutzer bekommt nichts mit. Warum ist das gefährlich? AMSI-Provider gelten als legitimer Mechanismus. Sicherheitsteams achten auf verdächtige Prozesse, Netzwerkverbindungen oder Dateien – weniger darauf, wer als AMSI-Provider registriert ist. Genau diese Lücke nutzen Angreifer. Sie verstecken sich im Vertrauensraum des Betriebssystems. Ihr Code wird bei jeder PowerShell-Sitzung erneut ausgeführt. Das ist Persistence auf einem kompromittierten System: Der Angreifer muss Administratorrechte nicht jedes Mal neu erlangen – sein Provider sorgt dafür, dass er bei jeder Interaktion mit PowerShell eine Hintertür offen hat.

Wie funktioniert die Antimalware Scan Interface? Microsoft hat AMSI mit Windows 10 eingeführt. Es schließt die Lücke zwischen Skript-Engines wie PowerShell, VBScript oder JScript und den Sicherheitsprodukten. Vorher musste jedes Sicherheitstool selbst in die Prozesse hineinreichen, um Skriptinhalte zu lesen – aufwändig und oft umgangen. AMSI bietet eine standardisierte Schnittstelle: Eine Anwendung wie PowerShell sendet den auszuführenden Code an AMSI, und AMSI leitet ihn an den registrierten Antimalware-Provider weiter. Der Provider untersucht den Inhalt und gibt eine Bewertung zurück: sauber, verdächtig oder bösartig. Erst dann entscheidet die Anwendung, ob sie den Code ausführt. Das Design ist herstellerneutral – jeder Sicherheitsanbieter kann einen eigenen Provider registrieren. Microsoft selbst veröffentlichte ein Codebeispiel, um Entwicklern die Implementierung zu erleichtern. Diese Offenheit ist der Hebel für Angreifer. Sie schreiben einen Provider, der nicht auf Malware scannt, sondern auf einen Trigger lauscht. Der Provider wird wie jede andere COM-Komponente registriert, über die Registry unter HKLM\SOFTWARE\Microsoft\AMSI\Providers. Ist er erst eingetragen, wird er bei jeder AMSI-Instanziierung geladen – typischerweise, wenn eine PowerShell-Konsole geöffnet wird. Der Code des fingierten Providers ist simpel: Die Scan()-Methode prüft, ob der übergebene Inhalt einen festgelegten String enthält. Trifft das zu, startet sie einen neuen Thread, der die eigentliche Schadaktion ausführt – etwa einen Reverse Shell startet. Die Ausführung erfolgt mit den Privilegien des PowerShell-Prozesses, also im Kontext des aktuellen Benutzers. Wenn der Benutzer Administrator ist, hat auch der Schadcode volle Kontrolle.

Die konkrete Umsetzung dieser Technik ist einfach. Der Proof-of-Code von Pentestlab zeigt eine DLL, die als COM-Komponente die IAmsiProvider-Schnittstelle implementiert. Der Kern liegt in der Scan()-Methode: Sie vergleicht den übergebenen Inhalt mit einem oder mehreren Trigger-Strings (im Beispiel ipurple.team). Stimmt der String überein, ruft sie CreateThread auf und startet eine Funktion, die die Windows-Rechner-App (calc.exe) oder eine andere ausführbare Datei startet. Die Registrierung erfolgt mit regsvr32.exe, dem Standardwerkzeug für COM-Komponenten. Der Befehl regsvr32 AmsiProvider.dll trägt die notwendigen Schlüssel in die Registry ein – sowohl den Provider unter dem AMSI-Pfad als auch die CLSID unter HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID. Nach der Registrierung reicht es, in PowerShell "ipurple.team" einzugeben, um die Payload auszulösen. Die Ausführung erfolgt im selben PowerShell-Prozess. Das bedeutet auch, dass die DLL in diesen Prozess geladen wird – ein Hinweis, den Sicherheitsteams erfassen können. Der Code zeigt auch eine Deinstallationsroutine (DllUnregisterServer), die die Registry-Einträge wieder entfernt. Der Angreifer kann so Spuren verwischen. Für die Registrierung ist Administratorenzugriff erforderlich, denn der Registry-Pfad liegt unter HKEY_LOCAL_MACHINE. Hat der Angreifer diese Rechte bereits, ist die Technik sehr effektiv, weil sie sich als legitime Systemkomponente tarnt.

Wie erkennt man einen gefälschten AMSI-Provider? Der naheliegendste Ansatz: Überwachung des Registry-Schlüssels HKLM\SOFTWARE\Microsoft\AMSI\Providers. Jeder neu hinzugefügte Unterschlüssel – eine GUID – sollte verdächtig sein, sofern er nicht von einem autorisierten Sicherheitsanbieter stammt. Unternehmen sollten dort per Gruppenrichtlinie ein Überwachungs-Audit einrichten, insbesondere für Set Value, Create Subkey und Query Value. Die Registrierung löst Windows-Ereignis 4663 aus (Versuch, auf ein Registry-Objekt zuzugreifen). Da auch die Installation legitimer Provider solche Ereignisse erzeugt, muss man die Ereignisse mit einer Liste vertrauenswürdiger Quellen abgleichen. Eine zweite Erkennungsmöglichkeit: Überwachung von DLL-Ladungen in PowerShell-Prozesse. Der gefälschte Provider wird als DLL (z. B. AmsiProvider.dll) in den PowerShell-Prozess geladen. Mit Sysmon können Sie Ereignis-ID 7 (Image geladen) nutzen, um unsignierte DLLs in PowerShell zu erkennen. Das produziert viele False Positives, weil auch nicht signierte .NET Native Images geladen werden. Sie können diese Quelle ausschließen, aber ein schlauer Angreifer könnte seine Schad-DLL genau in diesen Pfad legen. Deshalb prüfen Sie zusätzlich den Prozessbaum: Ein PowerShell-Prozess, der einen ungewöhnlichen Kindprozess startet (etwa cmd.exe oder einen unbekannten Executable), ist ein starkes Alarmsignal. Es gibt ein minimales Tool namens AmsiProviderMonitor.exe, das alle drei Minuten den AMSI-Provider-Registry-Zweig auf neue Einträge prüft und bei unsignierten DLLs in verdächtigen Pfaden Alarm schlägt. Das ist ein guter Ausgangspunkt für die Eigenentwicklung.

Die Hürde für den Angreifer ist nicht niedrig – er braucht lokale Administratorrechte, um den Provider zu registrieren. Hat er diese, ist die Technik äußerst effektiv. Sie missbraucht das Vertrauen in AMSI und verursacht kaum verdächtige Netzwerkaktivitäten. Microsoft hat mit Windows 10 Version 1903 eine Signaturprüfung für AMSI-Provider eingeführt: Ab diesem Update kann das Betriebssystem verlangen, dass Provider-DLLs signiert sein müssen. Standardmäßig ist diese Prüfung nicht aktiviert. Sie müssen sie über eine Gruppenrichtlinie (Turn on AMSI Provider signing check) einschalten. Das ist die effektivste Maßnahme: Aktivieren Sie die Signaturprüfung, dann werden nur noch DLLs mit einer gültigen digitalen Signatur als Provider zugelassen. Der Angreifer müsste dann entweder eine gültige Signatur besorgen (teuer und aufwändig) oder auf andere Persistence-Techniken ausweichen. In Kombination mit Registry-Überwachung und DLL-Ladungsprüfung schaffen Sie eine mehrschichtige Verteidigung.

Für den Alltag bedeutet das: AMSI ist keine Blackbox, der wir blind vertrauen. Die Schnittstelle ist ein mächtiges Werkzeug – aber auch gegen uns einsetzbar. Die Technik ist nicht weit verbreitet, aber der öffentliche Code senkt die Eintrittsschwelle. Unternehmen, die PowerShell intensiv nutzen (und das tun heute die meisten), sollten die Registry und Prozessabläufe überwachen. Wenn Sie die Signaturprüfung aktivieren, eliminieren Sie die Gefahr fast vollständig – solange der Angreifer keine signierte DLL beschaffen kann. Die Registry-Überwachung bleibt als zweite Ebene. Viele Organisationen haben die Signaturprüfung nicht aktiviert, oft aus Unwissenheit oder Sorge vor Kompatibilitätsproblemen. In einer Umgebung, in der Sie die installierten Sicherheitsprodukte kennen, sollte die Aktivierung kein Problem sein. Fangen Sie klein an: Überwachen Sie mit SIEM oder Sysmon die Registry-Änderungen unter HKLM\SOFTWARE\Microsoft\AMSI\Providers. Prüfen Sie bei jedem Vorfall, ob der registrierte Provider bekannt und signiert ist. Das ist ein praktischer Schritt, den Sie noch heute umsetzen können.

Quelle: ipurple.team

Du öffnest morgens dein Smartphone, und schon schlägt dir eine Playlist vor, die genau deinen Geschmack trifft. Dein Navi wählt die schnellste Route, obwohl du selbst keine Baustelle kennst. Und während du E-Mails schreibst, vervollständigt die Software automatisch deine Sätze. Das ist keine Magie, sondern KI – künstliche Intelligenz. Aber was steckt wirklich dahinter? Die Technik wirkt oft komplex, beruht aber auf einfachen Prinzipien.

Stell dir vor, du bringst einem Freund bei, Pfannkuchen zu backen. Du zeigst ihm Zutaten, erklärst die Reihenfolge, nach ein paar Versuchen kann er das Rezept auswendig. Genauso funktioniert maschinelles Lernen, der Kern moderner KI. Statt einem Menschen zeigst du einem Computer Millionen von Beispielen – Bilder von Katzen, Texte aus Büchern, Sensordaten. Aus diesen Beispielen zieht die Maschine Muster. Irgendwann erkennt sie eine Katze, auch wenn das Bild unscharf ist oder die Katze halb im Schatten sitzt. Der Computer hat keine expliziten Regeln bekommen wie „Wenn das Tier vier Beine hat und schnurrt, ist es eine Katze“. Er hat die Regel selbst aus den Daten gelernt. Das ist der fundamentale Unterschied zu klassischer Software, die strikt nach vorgegebenen Anweisungen läuft.

Das Lernen läuft in verschiedenen Varianten ab. Am häufigsten begegnet uns das überwachte Lernen. Der Mensch gibt die richtigen Antworten vor – auf jedem Katzenbild steht ein Etikett „Katze“. Der Computer vergleicht seine eigene Vorhersage mit diesem Etikett und korrigiert sich schrittweise. Über Millionen solcher Korrekturen entsteht ein Modell, das immer treffsicherer wird. Das klingt nach viel Arbeit – und das ist es auch. Aber einmal trainiert, kann so ein Modell in Sekundenbruchteilen Entscheidungen treffen, für die ein Mensch Stunden bräuchte. Es gibt auch das unüberwachte Lernen, bei dem die Maschine selbst Strukturen in Daten entdeckt. Ein Beispiel: Ein Onlineshop gruppiert seine Kunden automatisch in Kaufverhaltenstypen, ohne je gesagt zu bekommen, welche Gruppen es geben soll. So entstehen personalisierte Empfehlungen, die oft überraschend genau passen.

Hinter vielen dieser Lernverfahren stecken sogenannte neuronale Netze. Die Grundidee ist simpel. Ein neuronales Netz besteht aus vielen kleinen Recheneinheiten, die an Nervenzellen im Gehirn erinnern. Diese Einheiten sind in Schichten angeordnet: Eine Eingabeschicht nimmt die Rohdaten auf – zum Beispiel die Pixel eines Bildes – und gibt sie an versteckte Schichten weiter. In jeder Schicht werden die Informationen nach bestimmten Gewichtungen umgerechnet, bis am Ende eine Ausgabeschicht das Ergebnis liefert – etwa „Katze mit 95 Prozent Wahrscheinlichkeit“. Die Gewichtungen sind die eigentliche Intelligenz des Systems. Während des Trainings justiert der Algorithmus diese Gewichtungen millionenfach, bis die Fehlerrate minimal ist. Man kann es sich wie eine riesige Währungskette vorstellen, bei der unzählige kleine Schrauben gedreht werden, bis die Maschine stimmige Werte zeigt.

Wozu das alles? KI ist längst kein Laborphänomen mehr, sondern arbeitet im Hintergrund fast aller modernen Dienste. In der Medizin hilft sie Radiologen, Tumore auf Röntgenbildern zu erkennen – oft mit einer Genauigkeit, die an erfahrene Ärzte heranreicht. Im Straßenverkehr analysieren selbstfahrende Autos in Echtzeit ihre Umgebung: Fußgänger, Ampeln, andere Fahrzeuge. Das gelingt, weil die Fahrzeuge mit einem Ensemble aus verschiedenen KI-Modellen ausgestattet sind, jedes spezialisiert auf eine Aufgabe wie Objekterkennung oder Abstandsmessung. In der Industrie überwachen KI-Systeme Maschinen und sagen Ausfälle voraus, bevor sie passieren. In der Kommunikation erzeugen Sprachmodelle fließende Texte und Übersetzungen. All das geschieht oft unbemerkt, eingebettet in Apps und Dienste, die wir täglich nutzen.

KI ist kein Allheilmittel. Die Modelle sind nur so gut wie die Daten, mit denen sie gefüttert werden. Sind die Daten einseitig oder enthalten sie Vorurteile, lernt die Maschine diese mit. Ein Bewerbungstool, das anhand historischer Einstellungen trainiert wurde, kann unbewusst Diskriminierung fortsetzen. Und dann ist da die Frage der Erklärbarkeit: Viele moderne KI-Modelle sind Black Boxes – sie liefern ein Ergebnis, aber selbst die Entwickler können nicht immer im Detail nachvollziehen, wie es zustande kam. Das ist in sicherheitskritischen Bereichen wie der Medizin oder der Justiz ein ernstes Problem. Hinzu kommt der enorm hohe Energieverbrauch großer Modelle. Ein einziges Training eines leistungsfähigen Sprachmodells kann so viel CO₂ ausstoßen wie fünf Autos in ihrem gesamten Leben. Die Branche arbeitet daher an effizienteren Algorithmen und spezieller Hardware.

Und dann ist da noch das Thema Automatisierung von Arbeitsplätzen. Ja, KI wird bestimmte Aufgaben übernehmen, die bisher Menschen machten. Vor allem repetitive Tätigkeiten in der Dateneingabe, der Buchhaltung oder der Fertigung sind betroffen. Gleichzeitig entstehen neue Berufe: Datenwissenschaftler, Ethikbeauftragte für KI, Trainer für Modelle. Die Herausforderung liegt darin, Menschen durch Umschulung und Weiterbildung auf diese Veränderung vorzubereiten. Wer glaubt, KI werde in absehbarer Zeit alle Arbeitsplätze ersetzen, unterschreibt eine Utopie oder Dystopie, die fern der Realität liegt. KI ersetzt keine kompletten Berufe, sondern verschiebt Tätigkeitsschwerpunkte. Ein Buchhalter wird künftig weniger Rechnungen prüfen, dafür aber mehr die Ergebnisse der KI-Prüfung interpretieren und Ausnahmen bearbeiten.

Was bedeutet das konkret für dich? Du wirst nicht zum Programmierer werden müssen, um von KI zu profitieren. Aber ein grundlegendes Verständnis dafür, was KI kann und was nicht, hilft dir, bessere Entscheidungen zu treffen. Wenn eine App dir ein Produkt empfiehlt oder eine Versicherung deinen Tarif berechnet, kannst du hinterfragen: Auf welchen Daten basiert diese Entscheidung? Bin ich in einer Gruppe, die vielleicht benachteiligt wird? Solche Fragen werden in den nächsten Jahren immer wichtiger. Die Technologie selbst ist neutral – sie ist ein Werkzeug. Wie jedes Werkzeug hängt ihr Nutzen davon ab, wer sie anwendet und mit welchen Absichten.

In den kommenden Jahren werden wir KI noch alltäglicher erleben: in Haushaltsgeräten, im Gesundheitswesen, in der Bildung. Die großen Fortschritte geschehen jetzt. Entwickler arbeiten an Modellen, die mit weniger Daten auskommen und ihre Entscheidungen transparenter machen. Politik und Gesellschaft ringen um Regeln, die Missbrauch verhindern, ohne Innovation zu ersticken. Das alles ist kein abgeschlossener Prozess. Wir können die Entwicklung mitgestalten – indem wir informiert bleiben, kritisch fragen und offen für Neues sind. KI ist nicht der Bösewicht und nicht der Retter. Sie ist eine der faszinierendsten Erfindungen des Menschen. Und sie wird das bleiben, was wir aus ihr machen.

Quelle: inkling.com