Forescout przeniósł exploit WAGO PLC za pomocą Claude Code za 535,74 USD — i uszkodził nieodwracalnie kontroler, próbując uzyskać więcej

W dniu 1 września 2026 r., należące do Forescout Research,Vedere Labs opublikowało eksperyment, w którym dało Claude Code terminal, narzędzie do inżynierii wstecznej Ghidra, plik binarny firmware'u i fizyczny kontroler WAGO 750-831, a następnie poprosiło je o przeniesienie exploita zdalnego wykonania kodu przed uwierzytelnieniem, który działał już na blisko spokrewnionym WAGO 750-852. Modelowi się udało: ustalił, dlaczego jego shellcode był ciągle usuwany, zmienił sekwencję wyzwalania i wykonał dostarczony przez atakującego shellcode ARM na działającym sprzęcie bez żadnych poświadczeń. Koszt to 8 godzin 32 minuty czasu sesji rozłożonego na kilka dni, 535,74 USD wykorzystania API i ciągłego nadzoru człowieka. Późniejsza próba rozszerzenia exploita do implantu C2 zapisała dane do regionu pamięci mapowanego jako flash i trwale uszkodziła kontroler — własną jednostkę testową badaczy, a nie sprzęt w terenie. Eksperyment jest jednym rekordem w archiwum incydentów AI, które zawiera pełny zestaw rekordów, ich źródła i sąsiednie wpisy w tej serii.

Co Forescout faktycznie przekazał modelowi

Konfiguracja ma większe znaczenie niż liczba z nagłówka, ponieważ przesądza o tym, co eksperyment pokazuje, a czego nie. Własny opis Vedere Labs przedstawia interaktywny układ: Claude Code miał terminal, pliki referencyjne, narzędzia analityczne, w tym Ghidra, oraz dostęp sieciowy do działającego celu pod adresem 192.168.2.14 — WAGO 750-831 z oprogramowaniem układowym V01.04.16. Naukowcy mogli interweniować w dowolnym momencie sesji. Nie było debuggera ani kodu źródłowego docelowego oprogramowania układowego, zgodnie z notatką badawczą Cloud Security Alliance dotyczącą tego przypadku.

Luka była już znana i została już udokumentowana. CVE-2021-31886 to przepełnienie bufora na stosie w serwerze Nucleus FTP, osiągalne przed uwierzytelnieniem na porcie TCP 21 przez wysłanie zbyt dużego polecenia typu USER, a wcześniejsze prace Forescouta pozwoliły już opracować działający exploit dla 750-852. The Hacker News podaje wynik CVSS jako 9.8, przyznany przez firmę Siemens, która utrzymuje Nucleus. Oryginalnym biuletynem CERT@VDE jest VDE-2021-050.

To nie było więc autonomiczne odkrywanie podatności. To był nadzorowany port: jedna znana luka, jeden działający exploit referencyjny, jedno bliźniacze urządzenie, ekspert pod ręką. Język Forescout jest co do tego precyzyjny, a jego własny wniosek jest taki, że bariera pozostaje wysoka. Eksperyment mierzy koszt krańcowy przeniesienia exploita z urządzenia, które ktoś już złamał, na kolejne urządzenie z tej samej rodziny — co, jak ujmuje to nota Cloud Security Alliance, jest krokiem decydującym o tym, czy luka w łatkach w jednym modelu jest luką w łatkach we wszystkich.

Osiem godzin i bufor 256 bajtów

Pierwszą rzeczą wartą odnotowania jest to, jak duża część sesji upłynęła na myleniu się. Forescout twierdzi, że już pierwsze zapytanie do modelu ujawniło inny potencjalny błąd FTP, a nie CVE-2021-31886; badacze odłożyli go na bok, a firma twierdzi, że ręczna analiza sugeruje, iż może to być odrębna, wcześniej niezidentyfikowana luka, której nie przypisano CVE. Jedna z późniejszych sesji nie zdołała poprawnie prześledzić podatnej funkcji i wygenerowała nieprawidłowy exploit. Model podążał za fałszywymi hipotezami, dekompilował niepowiązany kod i zabrakło mu kontekstu.

Udało się jednak uzyskać jeden wynik pośredni: payload, który spowodował awarię 750-831, co dowiodło, że przepełnienie dotarło do drugiego urządzenia, nie dając jeszcze kontrolowanego wykonania. To rozróżnienie — awaria kontra kontrola — było miejscem, w którym sesja utknęła. Każdy payload tworzony przez model był usuwany, zanim zdążył się uruchomić, a przyczyną okazała się zwykła obsługa FTP na urządzeniu docelowym: po zbyt dużym poleceniu USER normalne przetwarzanie zerowało 256-bajtowy bufor, który zawierał shellcode atakującego. Forescout twierdzi, że znalezienie winowajcy wymagało kierowanej przez człowieka analizy łańcucha wywołań i ujścia, i identyfikuje tę procedurę jako sub_100BA758.

Poprawka polegała na zmianie sekwencji. Exploit 750-852 wysyłał USER, a następnie QUIT. W przypadku 750-831 model przełączył się na USER, a następnie CWD i pominął terminator CRLF w poleceniu, więc ścieżka przetwarzania nie zakończyła się w zwykły sposób, a bufor przetrwał wystarczająco długo, aby doszło do wykonania. Exploit uruchomił się następnie w kontekście wywołania zwrotnego odbioru Ethernet. Według Forescout demonstrowana możliwość ogranicza się do wysyłania pakietów sieciowych.

Gdy wykonanie kodu stało się niezawodne, tempo zmieniło się całkowicie. Model przeszedł od shellcode'u, który nic nie robi, do dwóch działających ładunków sieciowych w 12 minut: jeden wysyłał żądania ICMP echo do hosta kontrolowanego przez atakującego, drugi był pakietem UDP zawierającym ciąg "PWNED". Ta liczba 12 minut to najistotniejsza wartość w całym zapisie i właśnie ją w opracowaniu Forescouta traktuje się jako ostrzeżenie — trudna była pierwsza część, a kolejne kroki były niemal darmowe.

Rachunek: $535.74 za port, który człowiek mógłby wykonać szybciej

W końcowym etapie zdalnego wykonania kodu Forescout podaje 535,74 USD zużycia API w sesji trwającej 8 godzin i 32 minut, przy czym prace rozłożono na kilka dni badań, a nie wykonano ich za jednym podejściem. Publikowane wartości tokenów to 2,6 tys. tokenów wejściowych i 1,3 mln tokenów wyjściowych.

Ten podział jest wystarczająco nietypowy, by go odnotować. W długiej sesji kodowania z użyciem agentów zwykle dominuje strona wejściowa, ponieważ modelowi przy każdej turze ponownie przesyłany jest rosnący kontekst; 8,5-godzinna sesja rozliczona na 2600 tokenów wejściowych nie stanowi pełnego rozliczenia kosztu kontekstu. Forescout nie publikuje żadnego podziału, a SecurityWeek, relacjonując ten sam etap tego samego dnia, podaje jedynie „ponad 500 dolarów” i w ogóle nie podaje żadnych liczb tokenów. Łączna kwota w dolarach to liczba, którą potwierdzają oba źródła; podział wejście/wyjście należy czytać tak, jak został podany, a nie jako pełny zapis rozliczeniowy.

Koszt jest najsłabszym elementem argumentacji na rzecz wsparcia AI i sama Forescout to przyznaje. Własna ocena firmy jest taka, że badacz mógłby przenieść ten exploit „bez AI w krótszym czasie i niższym kosztem, jednocześnie utrzymując PLC w działaniu”. Eksperyment nie jest argumentem, że model jest tańszy niż ekspert. Jest argumentem o tym, w którą stronę zmierza to porównanie.

Uceglony kontroler

Awaria to ta część tego zapisu, która ma fizyczny skutek. Po uzyskaniu wykonania kodu kolejna sesja próbowała rozszerzyć exploit do implantu typu command-and-control. Forescout twierdzi, że payloady stawały się coraz bardziej złożone, a jeden z nich zapisał dane do obszaru pamięci odwzorowanego na flash. Kontroler został trwale uszkodzony.

Warto tu rozdzielić trzy rzeczy. Urządzenie było własnym sprzętem testowym badaczy, więc żaden operator nie stracił linii produkcyjnej, a archiwum nie odnotowuje rzeczywistych szkód. Szkody dokonał agent mający legalny dostęp do sprzętu, wykonujący zadanie, o które poprosili jego operatorzy — a nie atakujący. Zapis był zaś nieodwracalny w sposób, w jaki zła linijka kodu na serwerze zwykle nie jest: pamięć flash na wbudowanym kontrolerze to nie plik, który można przywrócić. Ujęcie Forescout wynika bezpośrednio z tego. Wskazywane przez niego bezpośrednie ryzyko to nie agent sam z siebie decydujący się zaatakować kontroler, lecz "upoważniony agent podejmujący niewłaściwe działanie w systemie fizycznym", gdzie awaria ma konsekwencje operacyjne.

Co jest ustalone, a co nie

Archiwum ocenia ten rekord jako: pewność A, waga średnia, niekwestionowany, bez odnotowanych rzeczywistych szkód — a relacje, na których się opiera, bronią się na tych warunkach. Opracowanie Forescout jest głównym źródłem. SecurityWeek opublikował własny report 1 września 2026 r., tego samego dnia; The Hacker News oraz laboratorium badawcze Cloud Security Alliance opublikowały 2 września. Żadna z tych publikacji nie jest niezależną replikacją techniczną i żadna nie twierdzi, że nią jest, ale wszystkie zgadzają się co do mechanizmu, dwóch wersji modeli, kosztu, 12-minutowego przebiegu payloadu i zbrickowania urządzeń.

Ustalono, na podstawie tego zapisu:

• Że nadzorowane przeniesienie zakończyło się sukcesem. Exploit przeduwierzytelnieniowy dla CVE-2021-31886 zaadaptowano z WAGO 750-852 na 750-831 z firmware V01.04.16, a dostarczony przez operatora shellcode ARM wykonano na działającym urządzeniu.

• Mechanizm. To, że 256-bajtowy bufor jest zerowany podczas normalnej obsługi polecenia USER, zmiana z QUIT na CWD oraz pominięty terminator CRLF są opisywane spójnie przez Forescout i przez źródła wtórne.

• Liczby dla ostatniego etapu: 8 godzin 32 minuty, 535,74 USD, 2,6 tys. tokenów wejściowych i 1,3 mln tokenów wyjściowych, 12 minut od wykonania kodu do dwóch działających payloadów.

• Że rozszerzenie C2 nieodwracalnie uszkodziło kontroler i że był to egzemplarz testowy.

• Że sama ocena Forescout jest negatywna pod względem kosztów. Stwierdza ona wprost, że ludzki badacz prawdopodobnie wykonałby ten port szybciej i taniej, i to bez niszczenia sprzętu.

Nieustalone lub w napięciu:

• Niezależna walidacja techniczna. Każda opublikowana relacja, w tym analiza Cloud Security Alliance, wywodzi się z opisu własnej pracy sporządzonego przez Forescout. Nikt spoza Forescout nie odtworzył portu, a raport SecurityWeek nie zawiera żadnego niezależnego komentarza eksperckiego.

• Kalendarzowe daty sesji. Forescout podaje czasy trwania, a nie daty. Jedyną pewną datą w zapisie jest data publikacji, 1 września 2026.

• Ile modeli WAGO obejmuje źródłowy biuletyn. The Hacker News przytacza listę dziesięciu zagrożonych modeli z VDE-2021-050 opracowanego przez CERT@VDE; notatka Cloud Security Alliance podaje liczbę 19. Sam biuletyn jest źródłem rozstrzygającym, a rozbieżność jest powodem, by go sprawdzić, a nie cytować którejkolwiek z tych liczb.

• Dokładne rozliczanie tokenów wejściowych, zgodnie z powyższym opisem.

• Co tak naprawdę zrobił nieudany implant. Forescout twierdzi, że payload zapisał dane do regionu mapowanego w pamięci flash; nie publikuje jednak ani payloadu, ani adresu, ani sekwencji, więc unieruchomienia urządzenia nie da się odtworzyć z zewnątrz.

Strona WAGO: brak dostępnej aktualizacji

Powód, dla którego port na model bliźniaczy ma znaczenie, jest taki, że model bliźniaczy nie zostanie naprawiony. VDE-2021-050 CERT@VDE wymienia kontrolery serii 750 działające pod kontrolą systemu operacyjnego czasu rzeczywistego Nucleus V1 jako podatne i stwierdza: „W tej chwili nie są dostępne żadne aktualizacje dla tej wersji”. The Hacker News zauważa, że dwóch modeli z listy podatnych — 750-882 i 750-885/0xx-xxx — nie ma ani w sekcji środków łagodzących biuletynu, ani w jego tabeli napraw, co pozostawia ich status niejasny.

Siemens, który utrzymuje Nucleus, twierdzi, że nie planuje się żadnych działań naprawczych dla Nucleus NET we wszystkich wersjach, według The Hacker News, podczas gdy wydania Nucleus ReadyStart V3 od V2013.08.1 wzwyż już naprawiają CVE-2021-31886. To niewielkie pocieszenie dla kontrolera, którego firmware zawiera starszy stos i którego dostawca nie opublikował żadnej ścieżki aktualizacji.

Luka nie jest nowa. CVE-2021-31886 była jedną z 13 podatności ujawnionych w listopadzie 2021 r. pod nazwą NUCLEUS:13 przez Forescout i Medigate. The Hacker News sprawdził również 1 września 2026 r., czy publiczny kod exploita można łatwo znaleźć: wyszukiwanie repozytoriów na GitHubie nie zwróciło żadnych wyników, a luki nie było w Exploit-DB ani Packet Storm — z zastrzeżeniem, że wyszukiwarka GitHuba obejmuje nazwy i opisy repozytoriów, a nie zawartość plików. Port, nad którym Forescout spędził osiem i pół godziny i wydał ponad pięćset dolarów, nie powstał przez kopiuj-wklej.

Dlaczego Forescout i tak twierdzi, że linia trendu ma znaczenie

Wniosek Forescouta jest celowo mało ekscytujący i to właśnie ta część zapisu najłatwiej może zostać błędnie odczytana w jedną albo drugą stronę. „Można to zrobić, ale nie jest to tak łatwe, jak się wydaje” – pisze firma. Zauważa, że jej wcześniejsze badania NUCLEUS:13 doprowadziły do wniosku, iż te kwestie prawdopodobnie nie powinny znajdować się w czołówce listy priorytetów właściciela aktywów, i twierdzi, że postęp w dziedzinie AI powinien skłonić organizacje do ponownego przeanalizowania tej oceny — ponieważ „trudny do wykorzystania” staje się słabszym argumentem za obniżeniem priorytetu kontrolera, w miarę jak maleje nakład pracy potrzebny do jego wykorzystania.

Nota Cloud Security Alliance podaje przydatny skrót opisujący ten schemat: trudny pierwszy krok, szybkie kolejne kroki. Pierwsza adaptacja kosztowała osiem i pół godziny, nadzór eksperta i zniszczone urządzenie. Drugi i trzeci payload zajęły dwanaście minut. Jeśli pierwszy krok stanie się tańszy, proporcja nie pozostanie taka sama.

Argument ten wpisuje się jednak w określone tło, choć jest odrębny od eksperymentu Forescout i nie należy go odczytywać jako dowodu na jego temat. The Hacker News podaje, że19 sierpnia 2026 NSA, CISA, FBI, Departament Energii i EPA wydały wspólne ostrzeżenie dotyczące generowanych przez AI skryptów eksploatacyjnych wymierzonych w wystawione na dostęp z internetu sterowniki Siemens S7 PLCs; agencje oceniły, że działalność ta prawdopodobnie miała służyć długotrwałemu rozpoznaniu i rozwijaniu zdolności, i nie przypisały jej żadnemu podmiotowi. Ten sam serwis podaje, że FBI i EPA wykryły włamania do zakładów wodociągowych w co najmniej siedmiu stanach od 27 lipca 2026 r., w niektórych z nich doszło do pogorszenia działania, a napastnicy zmieniali adresy IP i hasła na wystawionych na dostęp z internetu kontrolerach Rockwell Automation MicroLogix, nie potrzebując do tego w ogóle exploita. Wspólne ostrzeżenie przestrzegało, że wykorzystywanie AI do generowania exploitów „drastycznie zmniejsza wymaganą wiedzę techniczną i czas potrzebne” do zbudowania działających narzędzi do ataków na ICS.

Co operator powinien z tego wynieść

Praktyczna reakcja jest nieefektowna i nie zależy od tego, jak rozstrzygnie się spór o AI. Ustal, czy w sieci znajduje się jakikolwiek kontroler serii 750 lub inny kontroler oparty na Nucleus i jaki ma firmware. Tam, gdzie nie ma aktualizacji, ogranicz lub wyłącz FTP, Telnet i administrację przez WWW, zablokuj port 21 na granicy sieci, segmentuj sieć sterowania i nie wystawiaj interfejsów zarządzania do internetu. Monitoruj nietypowe użycie protokołów, powtarzające się awarie i nieoczekiwany ruch wychodzący — awaria kontrolera to sygnał, a nie tylko przerwa w działaniu.

Cloud Security Alliance dodaje krok, który wynika z samej logiki eksperymentu: niezależnie zweryfikować, czy modele pokrewne dzielą tę samą podatność, zamiast zakładać, że zakres łatki dostawcy pokrywa się z rzeczywistym narażeniem. To właśnie tę kontrolę Forescout przeprowadził na jednej parze urządzeń, a jego argument brzmi, że ta sama kontrola staje się tańsza w miarę, jak tanieje pierwszy krok.

Dla zespołów korzystających z agentów w pobliżu systemów fizycznych zbrickowanie sprzętu jest konkretną lekcją. Forescout zaleca włączanie ekspertów-ludzi do procesu decyzyjnego w przypadku decyzji krytycznych dla bezpieczeństwa oraz uczynienie zaufania do autonomicznej obrony „ograniczonym, obserwowalnym i weryfikowalnym” — bramki zatwierdzania przed zapisami do firmware’u lub pamięci flash, wycofywanie zmian tam, gdzie jest dostępne, oraz testowanie na sprzęcie nieprodukcyjnym, ponieważ w kontrolerze wbudowanym błędny zapis nie zostaje wycofany.

Zapis będzie odczytywany inaczej w zależności od tego, czego się po nim spodziewałeś. Nie jest to dowód, że model można skierować na sterownik przemysłowy i pozostawić bez nadzoru; sama firma, która go uruchomiła, twierdzi, że człowiek wykonałby tę pracę szybciej i taniej. Pokazuje natomiast wymierny koszt etapu, który kiedyś wymagał specjalisty: osiem i pół godziny, pięćset trzydzieści pięć dolarów, stały nadzór eksperta i jeden martwy sterownik.