Entwickler dürfen nun erstmals die neue Siri AI auf der Apple Watch testen. Die in der Nacht zum Dienstag erschienene dritte Beta von watchOS 27 enthält erstmals die dafür notwendige neue Siri-AI-App samt entsprechender Integration in das Betriebssystem. Es bleibt zunächst unklar, ob es wie bei macOS 27, iOS 27 und iPadOS 27 eine Warteliste gibt oder die Funktion sofort zur Verfügung steht. Da die Apple Watch im Gegensatz zu iPhone und iPad nicht von der EU-Kommission reguliert wird, steht Siri AI auch in Europa zur Verfügung. Allerdings ist die einzige zugelassene Hauptsprache derzeit US-Englisch, auch wenn man versuchen kann, mit dem neuen Chatbot in deutscher Sprache zu kommunizieren und dabei des Öfteren zielführende Antworten erhält.

Siri AI auf der Apple Watch nur auf bestimmten Modellen

Apple hatte sich mit watchOS 27 entschieden, beliebte Apple-Watch-Modelle nicht mehr mit dem neuen Betriebssystem zu versorgen, darunter Series 8 und die erste Generation der Ultra. Apples Verteidigung der vielfach kritisierten Entscheidung nannte unter anderem die fehlende ausreichende Rechenleistung für Siri AI.

Allerdings lief die Sprachassistentin bislang auf der Apple Watch gar nicht lokal, sondern gab Anfragen an das verbundene iPhone weiter. Ob sich das mit watchOS 27 tatsächlich ändert, ist unklar. Es wird spekuliert, dass Siri AI die in neueren Apple-Watch-Modellen (ab Series 9, Ultra 2 und SE 3) integrierte KI-Einheit (Neural Engine) benötigt. Am Hauptspeicher hat sich zwischen den Varianten offenbar nichts geändert.

Neues KI-System prominent platziert

Am leichtesten zu finden ist die neue Siri-AI-App über eine neue Steuerfunktion, die Apple in watchOS 27 eingebaut hat: Drückt man auf die digitale Krone, tauchen nun fünf ausgewählte Anwendungen auf. In der Mitte ist das Siri-AI-Icon platziert. Zu allen Apps im Raster (Grid) oder der Listenansicht kommt man mit einem weiteren Knopfdruck.

Apple will also, dass die User die Sprachassistentin schnell finden und nutzen. Natürlich ist auch ein Aufruf mit der Stimme möglich, wenn man dies nicht abgeschaltet hat. Die Darstellung von Siri AI ist aufgrund der kleinen Bildschirmgröße nicht perfekt, Nutzer sollten sich darauf einstellen zu scrollen. Anfragen finden sich später auch in der Siri-AI-App für iPhone, iPad und Mac.

(bsc)

Das bislang optionale Windows-Update KB5095093 behebt einen teils schwerwiegenden Fehler unter Windows 11, der einiges an Speicherplatz fressen kann. Es geht um die Datei CapabilityAccessManager.db-wal, die sich bei manchen Nutzern auf Dutzende bis Hunderte Gigabyte aufbläht.

Berichte über diesen Fehler gab es schon vor einem Jahr. Ein Extremfall beklagte sich über mehr als 500 GByte verschwendeten Speicherplatz auf der eigenen SSD. In den vergangenen Wochen häuften sich die Fälle unter anderem im Microsoft-Forum und auf Reddit.

Das Windows-Update KB5095093 ist seit dem 23. Juni als optionale Preview verfügbar. Wer unter Einstellungen > Windows Update nach Updates sucht, sollte KB5095093 angeboten bekommen. Erst am 29. Juni ergänzte Microsoft im Änderungsprotokoll die Fehlerbehebung. Dort heißt es umschrieben: „Dieses Update verbessert die Speicherplatznutzung für die Datei CapabilityAccessManager.db-wal.“ Ab dem 14. Juli beginnt die automatische Verteilung des Updates im Rahmen von Microsofts Patchday.

CapabilityAccessManager.db-wal ist eine Protokolldatei (Write-Ahead Log, WAL) für den Capability Access Manager Service. Letzterer verwaltet die Zugriffsrechte von Apps unter anderem auf Webcams und Mikrofone. Bisherige Lösungsvorschläge waren risikobehaftet, da der übergeordnete Ordner C:\ProgramData\Microsoft\Windows\CapabilityAccessManager Systemrechte hat. Im Zweifelsfall können manuelle Eingriffe die Windows-Installation beschädigen.

Überprüfen, ob man betroffen ist

Verweigert Windows den Zugriff auf den Ordner, lässt sich die Dateigröße über die Eingabeaufforderung überprüfen. Dazu in der Taskleiste „cmd“ eingeben und die Eingabeaufforderung per Rechtsklick als Administrator öffnen. Dort folgenden Befehl eingeben: robocopy "C:\ProgramData\Microsoft\Windows\CapabilityAccessManager" "%TEMP%\CAMCheck" /L /B /R:0 /W:0 /BYTES /NP.

Ganz unten links spuckt eine Tabelle einen Wert in Byte aus. Bis zu neun Stellen, also unter einem Gigabyte, sind normal. Üblich sind einige Megabyte (siebenstelliger Byte-Wert).

Alternativ bringt die Speicherübersicht einen ersten Überblick: Einstellungen > System > Speicher > Weitere Kategorien anzeigen > Klick auf System und reserviert. Systemdateien und reservierter Speicher machen üblicherweise bis zu 65 GByte aus. Werte deutlich darüber sind auffällig.

(mma)

Forscher der Cloud-Security-Firma Sysdig dokumentieren den ersten, wie sie behaupten „komplett LLM-getriebenen“ Ransomware-Vorfall. Und was sie beschreiben, ist tatsächlich ein Einbruch in ein Produktionssystem, bei dem offenbar ein LLM weitgehend autonom agiert, dabei wichtige Daten verschlüsselt beziehungsweise löscht und für deren Wiederbeschaffung Lösegeld fordert. Doch bei genauerer Betrachtung ist das Ganze eher skurril als ernsthaft gefährlich.

Dass bei dem Vorfall ein Large Language Model am Werk war, geht recht eindeutig aus den am Tatort vorgefundenen Skripten hervor. Menschliche Akteure dokumentieren ihre maliziösen Skripte eher nicht mit Kommentaren wie "High-ROI databases to drop". Für die These, dass das LLM weitgehend autonom handelte, führen die Forscher an, wie schnell es auf fehlgeschlagene Aktionen reagierte. So verbesserte es ein Skript nach einem fehlgeschlagenen Login innerhalb von 31 Sekunden.

Typische LLM-Fails

Man könnte an der Stelle auch anführen, dass ein menschlicher Täter für die Lösegeldforderung kaum die Adresse einer Bitcoin-Wallet verwendet hätte, die häufig als Beispiel in öffentlich verfügbarer Dokumentation auftaucht (3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy). Oder mehr Wert darauf gelegt hätte, zumindest den Anschein zu erwecken, den zum Verschlüsseln der Daten verwendeten AES-Key auch tatsächlich für eine mögliche spätere Herausgabe zu speichern. Die Liste der für LLMs so typischen Fails ließe sich weiter fortsetzen.

Das LLM absolvierte alle typischen Schritte eines Ransomware-Angriffs: vom Initial Access über Persistenz, Informationsbeschaffung, weiteres Ausbreiten bis zum finalen Impact. Die konkreten Umstände des Einbruchs sind allerdings nicht unbedingt geeignet, bei seriösen Admins Schrecken zu verbreiten. Der initiale Zugriff erfolgte über eine offenbar seit langem ungepatchte Sicherheitslücke eines über Internet erreichbaren Langflow-Servers (CVE-2025-3248), einer Code-Injection-Lücke in einem Open-Source-Framework zum Bau von LLM-Systemen. Auf dem Server lief auch ein selbst-gehostetes MinIO, ein S3-kompatibler Objektspeicher mit Defaultzugang minioadmin:minioadmin. Der daraufhin angegriffene Naming-Server enthielt eine seit fünf Jahren bekannte Schwachstelle (CVE-2021-29441). Die Systeme und ihre Daten lagen also sozusagen auf einem Präsentierteller. Woher die Zugangsdaten für den finalen Zugriff auf eine MySQL-Datenbank stammen, ist allerdings ungeklärt.

Müssen wir alle sterben?

Der von Sysdig als Jadepuffer bezeichnete Vorfall zeigt, dass Angreifer tatsächlich damit experimentieren, Angriffe von einer KI weitgehend selbstständig durchführen zu lassen. Und dass das prinzipiell Schaden verursachen kann. Doch selbst aus Sicht der eigentlichen Täter im Hintergrund dürfte dieser Vorfall bestenfalls als Proof of Concept denn als echter Durchbruch verbucht werden. Der Weg zum eigentlichen Ziel „make money fast“ ist doch noch sehr weit. Insgesamt wirkt das Vorgehen der KI mehr wie das eines Toddlers, der mit Cybercrime-Bauklötzchen spielt, als das eines Furcht einflößenden Cyber-Terminators. Doch beim aktuellen Tempo der KI-Entwicklung wird dieser Toddler sehr schnell dazu lernen. Die wichtigste Jadepuffer-Botschaft für Verteidiger ist jedenfalls keine neue: Es wird allerhöchste Zeit, seine Security-Hausaufgaben zu machen und seine IT-Infrastruktur vernünftig abzusichern.

(ju)