Archiwa: APT - Security Bez Tabu

TA488 i atak „half-click” na Zimbra: jak działa kampania wykorzystująca CVE-2025-66376

Wprowadzenie do problemu / definicja

Kampanie typu „half-click” to rozwinięcie klasycznych ataków phishingowych wymierzonych w użytkowników poczty elektronicznej. W takim scenariuszu ofiara nie musi świadomie klikać odnośnika ani otwierać załącznika — do uruchomienia złośliwego ładunku może wystarczyć samo wyświetlenie wiadomości w podatnym interfejsie webmail.

W analizowanej kampanii grupa TA488 wykorzystała podatność stored XSS oznaczoną jako CVE-2025-66376 w Zimbra Collaboration Suite. Luka pozwalała na wykonanie kodu JavaScript w kontekście zalogowanej sesji użytkownika, co otwierało drogę do przejęcia dostępu do skrzynki, kradzieży danych i utrzymania trwałej obecności w koncie.

W skrócie

Atakujący wykorzystywali błąd w klasycznym interfejsie Zimbra, związany z nieprawidłową sanitacją treści HTML oraz dyrektyw CSS @import w wiadomościach e-mail. Po wyświetleniu spreparowanej wiadomości w podatnym kliencie webmail uruchamiał się osadzony kod, który działał z uprawnieniami aktywnej sesji użytkownika.

Wektor ataku: stored XSS w wiadomości e-mail.
Warunek powodzenia: otwarcie lub nawet sam podgląd wiadomości w Classic UI.
Skutki: kradzież sesji, eksfiltracja poczty, pozyskanie danych 2FA i trwałość przez hasło aplikacyjne.
Podatne wersje: Zimbra 10.0 wcześniejsze niż 10.0.18 oraz 10.1 wcześniejsze niż 10.1.13.

Kontekst / historia

Ataki na platformy webmail od lat pozostają atrakcyjne dla grup APT, ponieważ umożliwiają dostęp do komunikacji organizacji bez konieczności wdrażania typowego malware na stacji końcowej. W ostatnich latach obserwowany jest wyraźny trend przechodzenia od prostego phishingu do bardziej dyskretnych kampanii wykorzystujących błędy po stronie klienta i interfejsu użytkownika.

W przypadku TA488 celem były przede wszystkim organizacje rządowe, sektor obronny oraz podmioty o znaczeniu strategicznym, w tym cele związane z Ukrainą i Stanami Zjednoczonymi. Ustalono, że podatność była aktywnie wykorzystywana przez wiele miesięcy, zanim otrzymała identyfikator CVE-2025-66376 i została załatana w wydaniach Zimbra 10.0.18 oraz 10.1.13.

Fakt, że luka trafiła do katalogu Known Exploited Vulnerabilities, podkreśla jej praktyczne znaczenie. Nie był to błąd o wyłącznie teoretycznym charakterze, lecz element realnych operacji szpiegowskich prowadzonych przeciwko wybranym organizacjom.

Analiza techniczna

Rdzeniem kampanii był stored XSS w klasycznym interfejsie Zimbra. Atakujący osadzali złośliwy kod w treści wiadomości HTML, a następnie maskowali go przy użyciu dyrektyw @import, komentarzy HTML i fragmentacji znaczników. Taka konstrukcja pozwalała ominąć mechanizmy sanitacji i doprowadzić do odtworzenia aktywnego kodu przez przeglądarkę.

Po wyrenderowaniu wiadomości uruchamiał się JavaScript działający w kontekście zalogowanej sesji użytkownika. Oznaczało to dostęp do tokenów sesyjnych, danych konta, wiadomości, katalogów adresowych i innych zasobów dostępnych z poziomu interfejsu webmail. To właśnie wykonywanie kodu „wewnątrz” legalnej sesji czyniło ten atak szczególnie niebezpiecznym i trudnym do zauważenia.

Zaobserwowany ładunek, określany jako ZimReaper, miał charakter wieloetapowy i realizował kilka celów jednocześnie:

potwierdzał skuteczną kompromitację,
pozyskiwał adres e-mail ofiary i informacje o środowisku,
zbierał kody 2FA,
odczytywał dane z mechanizmów autouzupełniania,
tworzył hasło aplikacyjne w celu utrzymania dostępu,
enumerował Global Address List,
eksportował wiadomości z ostatnich około 90 dni,
eksfiltrował dane do infrastruktury przeciwnika.

Szczególnie groźnym elementem była trwałość dostępu. Dzięki utworzeniu hasła aplikacyjnego operator mógł dalej logować się do skrzynki z użyciem standardowych protokołów pocztowych, bez potrzeby ponownego przejmowania sesji przez exploit. Dodatkowo część danych była wyprowadzana kanałem DNS, co mogło utrudniać wykrycie incydentu w środowiskach skupionych głównie na monitorowaniu ruchu HTTP i HTTPS.

Atak był też relatywnie „cichy” na poziomie endpointu. Kod wykonywał się w silniku JavaScript przeglądarki, przez co klasyczne rozwiązania EDR mogły nie zarejestrować oczywistych artefaktów typowych dla uruchamiania zewnętrznego malware.

Konsekwencje / ryzyko

Największe ryzyko wynikało z minimalnej interakcji wymaganej od użytkownika. W praktyce samo wyświetlenie wiadomości mogło uruchomić cały łańcuch ataku, co znacząco zwiększało szansę powodzenia operacji. Użytkownik nie musiał popełnić klasycznego błędu, takiego jak kliknięcie w link czy pobranie załącznika.

Potencjalne skutki kompromitacji obejmowały zarówno przejęcie pojedynczej skrzynki, jak i dalsze działania wewnątrz organizacji:

przejęcie aktywnej sesji webmail,
kradzież wiadomości i załączników,
pozyskanie danych uwierzytelniających oraz materiału 2FA,
dostęp do książki adresowej i relacji komunikacyjnych,
ustanowienie trwałego dostępu do konta,
wykorzystanie przejętej skrzynki do dalszego spear phishingu.

Dla organizacji rządowych, obronnych i badawczych skutki mogą być szczególnie poważne. Utrata korespondencji, danych osobowych, materiałów strategicznych czy informacji kontraktowych może stać się punktem wyjścia do dalszej eskalacji, ruchu bocznego i budowy bardzo wiarygodnych kampanii podszywających się pod zaufanych nadawców.

Rekomendacje

Najważniejszym krokiem jest szybka weryfikacja używanej wersji Zimbra i aktualizacja do wydań wolnych od podatności, czyli co najmniej 10.0.18 lub 10.1.13. Jeżeli organizacja nie może wdrożyć poprawek natychmiast, warto tymczasowo ograniczyć korzystanie z podatnego klasycznego interfejsu webmail i skierować użytkowników do alternatywnych klientów.

przeprowadzić przegląd wszystkich instancji Zimbra, zwłaszcza tych dostępnych z internetu,
ograniczyć lub wyłączyć Classic UI tam, gdzie jest to możliwe,
monitorować tworzenie i użycie haseł aplikacyjnych oraz nietypową aktywność IMAP, POP3 i SMTP,
analizować logi pod kątem masowego eksportu wiadomości i nietypowych zapytań do katalogu adresowego,
monitorować ruch DNS pod kątem anomalii i możliwej eksfiltracji,
badać wiadomości HTML pod kątem podejrzanych konstrukcji z @import i ukrytych elementów,
zwiększyć retencję logów aplikacyjnych, sieciowych i proxy,
przeprowadzić hunting w kierunku podejrzanych sesji webmail oraz zmian ustawień kont,
w razie podejrzenia kompromitacji wymusić reset poświadczeń i unieważnić aktywne sesje,
przetestować scenariusze reagowania na incydenty specyficzne dla środowisk webmail.

W organizacjach o podwyższonym profilu ryzyka warto traktować webmail jako krytyczną powierzchnię ataku, wymagającą równie ścisłego monitoringu jak systemy końcowe i usługi zdalnego dostępu.

Podsumowanie

Kampania TA488 pokazuje, jak skuteczne mogą być ataki wykorzystujące błędy po stronie klienta w popularnych platformach pocztowych. CVE-2025-66376 w Zimbra umożliwiała uruchomienie kodu po samym wyświetleniu wiadomości, a następnie przejęcie danych sesyjnych, eksport poczty i utrwalenie dostępu do konta.

Dla zespołów bezpieczeństwa najważniejsze wnioski są jednoznaczne: szybko łatać systemy pocztowe, monitorować anomalie w sesjach i protokołach pocztowych oraz uwzględniać webmail w modelu zagrożeń jako pełnoprawny, krytyczny element infrastruktury.

Źródła

Infosecurity Magazine – TA488 Outlook Half-Click OWAReaper https://www.infosecurity-magazine.com/news/ta488-outlook-half-click-owareaper/
Proofpoint – TA488 Targets Zimbra Mailservers with Half-Click Exploits https://www.proofpoint.com/us/blog/threat-insight/ta488-targets-zimbra-mailservers-half-click-exploits
NIST NVD – CVE-2025-66376 https://nvd.nist.gov/vuln/detail/CVE-2025-66376
Joint Cybersecurity Advisory – Russian State-Supported Cyber Actors Conduct Phishing Campaign Targeting Users of Zimbra Collaboration Suite https://media.defense.gov/2026/Jul/22/2003965244/-1/-1/1/CSA_RUSSIA_PHISHING_TARGET_ZIMBRA.PDF
Zimbra Security Center https://wiki.zimbra.com/wiki/Security_Center

Google wprowadza nowy system nazewnictwa grup zagrożeń

Wprowadzenie do problemu / definicja

Nazewnictwo grup zagrożeń od lat pozostaje jednym z bardziej problematycznych obszarów cyber threat intelligence. Ten sam aktor bywa opisywany pod różnymi nazwami przez różnych dostawców, co utrudnia korelację incydentów, analizę kampanii oraz sprawną wymianę informacji między zespołami bezpieczeństwa. Google poinformował o wdrożeniu nowego systemu nazewnictwa, którego celem jest uproszczenie identyfikacji i klasyfikacji klastrów aktywności.

W skrócie

Google Threat Intelligence Group odchodzi od mniej intuicyjnych, numerowanych identyfikatorów na rzecz dwuczłonowego modelu nazw. Nowa konwencja ma łączyć łatwy do zapamiętania element identyfikujący klaster z drugim członem wskazującym kategorię aktora według motywacji, atrybucji geopolitycznej lub typu działalności. Zmiana ma ułatwić analitykom poruszanie się po złożonym ekosystemie nazw używanych w branży.

Kontekst / historia

Problem wielości nazw nie jest nowy. W świecie threat intelligence te same grupy APT, klastry sponsorowane przez państwa i podmioty cyberprzestępcze są często śledzone równolegle przez producentów bezpieczeństwa, instytucje publiczne i niezależne zespoły badawcze. Każda z tych organizacji buduje jednak własny model atrybucji, oparty na innych źródłach telemetrycznych, wskaźnikach kompromitacji i poziomie pewności analitycznej.

W praktyce oznacza to, że jeden aktor może funkcjonować pod wieloma aliasami. Taki stan rzeczy komplikuje ocenę, czy różne raporty opisują ten sam podmiot, czy tylko częściowo pokrywające się operacje. Branża od lat próbuje uporządkować ten obszar poprzez mapowanie aliasów między dostawcami, wykorzystanie MITRE ATT&CK oraz rozwój wspólnych słowników pojęć. Decyzja Google wpisuje się w ten trend standaryzacyjny.

Analiza techniczna

Nowy model Google opiera się na dwóch słowach. Pierwszy element nazwy to unikalny i łatwy do zapamiętania termin reprezentujący konkretny klaster aktywności. Jeśli dla danej grupy istnieje już rozpoznawalna nazwa publiczna, może ona zostać zachowana. W przeciwnym razie stosowany będzie losowo generowany identyfikator.

Drugi człon pełni funkcję klasyfikacyjną i ma wskazywać kategorię aktora na podstawie motywacji, przypisania geopolitycznego lub typu operacji. Google stosuje określone słowa końcowe dla klastrów powiązanych między innymi z Chinami, Iranem, Koreą Północną, Rosją oraz cyberprzestępczością. Dzięki temu sama nazwa przekazuje nie tylko tożsamość klastra, ale też podstawowy kontekst analityczny.

Jednym z przykładów jest rosyjska grupa znana szerzej jako Sandworm, wcześniej śledzona przez Google jako APT44. W nowym modelu ma ona funkcjonować jako Sandworm Relic. To podejście ogranicza zależność od numeracji sekwencyjnej, która dla wielu odbiorców bywa mało intuicyjna.

Istotnym elementem zmiany jest zachowanie ciągłości danych. Historyczne nazwy mają pozostać indeksowane i możliwe do wyszukania w platformie Google Threat Intelligence, a mapowania do MITRE ATT&CK oraz aliasy innych dostawców mają zostać utrzymane. Google zapowiada również pozostawienie oznaczenia UNC dla klastrów nieprzypisanych lub jeszcze niesklasyfikowanych.

Konsekwencje / ryzyko

Z perspektywy operacyjnej sama zmiana nazewnictwa nie podnosi bezpośrednio poziomu ryzyka, ale może istotnie wpłynąć na procesy analityczne. Największą korzyścią jest uproszczenie pracy zespołów SOC, CTI, DFIR i vulnerability management, które regularnie korelują informacje z wielu źródeł. Bardziej intuicyjne nazwy mogą skrócić czas potrzebny na zrozumienie kontekstu raportu i ograniczyć liczbę błędów interpretacyjnych.

Okres przejściowy niesie jednak także wyzwania. Organizacje korzystające z własnych baz wiedzy, dashboardów, runbooków, parserów raportów oraz integracji z TIP i SIEM mogą napotkać niespójności, jeśli nowe nazwy nie zostaną prawidłowo zmapowane do wcześniejszych aliasów. Problem może dotyczyć także automatycznego tagowania incydentów, playbooków SOAR i raportowania zarządczego.

W dojrzałych środowiskach CTI nazewnictwo pełni funkcję warstwy logicznej spajającej IOC, TTP i ocenę atrybucji. Każda zmiana tej warstwy wymaga więc kontroli jakości danych referencyjnych. Bez tego istnieje ryzyko powstawania duplikatów encji, błędnych relacji między kampaniami oraz niepełnego obrazu aktywności przeciwnika.

Rekomendacje

Organizacje wykorzystujące komercyjne i własne źródła threat intelligence powinny potraktować zmianę jako impuls do przeglądu modeli danych dotyczących aktorów zagrożeń.

zaktualizować słowniki nazw aktorów w platformach TIP, SIEM, SOAR i systemach case management;
utrzymywać tabelę aliasów obejmującą stare i nowe nazwy oraz mapowania między dostawcami;
sprawdzić, czy reguły korelacyjne, parsery raportów i integracje API nie opierają się sztywno na przestarzałych identyfikatorach;
uwzględnić aliasy w procedurach huntingu, raportach CTI i materiałach dla SOC;
przeszkolić analityków, aby rozumieli nową konwencję i potrafili szybko przełożyć ją na wcześniejsze oznaczenia;
zachować ostrożność przy automatycznej atrybucji i nie opierać wniosków wyłącznie na samej nazwie grupy.

Dobrą praktyką pozostaje także wiązanie nazw aktorów z trwalszymi atrybutami technicznymi, takimi jak techniki ATT&CK, rodziny malware, infrastruktura C2, wzorce targetingu czy oś czasu kampanii. Takie podejście zmniejsza wpływ przyszłych zmian nazewniczych na procesy operacyjne.

Podsumowanie

Nowy system nazewnictwa wprowadzany przez Google ma uporządkować jeden z najbardziej problematycznych obszarów cyber threat intelligence, czyli niespójne identyfikatory grup zagrożeń. Dwuczłonowy model łączy prostotę, lepszą zapamiętywalność i podstawową klasyfikację analityczną. Dla zespołów bezpieczeństwa oznacza to potencjalnie łatwiejszą korelację danych i czytelniejsze raportowanie, ale jednocześnie wymaga starannego mapowania aliasów w narzędziach i procesach.

Źródła

https://www.securityweek.com/google-adopts-new-threat-actor-naming-system/
https://cloud.google.com/blog/topics/threat-intelligence/threat-actor-naming-at-google-threat-intelligence
https://attack.mitre.org/

Certighost: nowe PoC ujawnia drogę do przejęcia domeny Windows przez AD CS

Wprowadzenie do problemu / definicja

Publicznie udostępniony exploit proof-of-concept dla podatności Certighost ponownie kieruje uwagę administratorów na bezpieczeństwo Active Directory Certificate Services. Luka oznaczona jako CVE-2026-54121 dotyczy procesu obsługi żądań certyfikatów w środowiskach Windows opartych na Active Directory i może prowadzić do eskalacji uprawnień z poziomu zwykłego użytkownika domenowego do pełnej kompromitacji domeny.

W praktyce problem polega na tym, że atakujący może uzyskać certyfikat pozwalający podszyć się pod konto maszyny, a w niektórych scenariuszach nawet pod kontroler domeny. To z kolei otwiera drogę do przejęcia krytycznych uprawnień i naruszenia zaufania w całym środowisku tożsamości.

W skrócie

Certighost jest podatnością związaną z AD CS i mechanizmem wykorzystywanym podczas wystawiania certyfikatów. Słabość wynikała z niewystarczającej walidacji serwera wskazywanego w parametrach żądania, co umożliwiało przekierowanie procesu do usług kontrolowanych przez napastnika.

atak wymaga uwierzytelnionego konta domenowego, a nie uprawnień administracyjnych na starcie,
celem może być uzyskanie certyfikatu dla konta maszyny lub kontrolera domeny,
publiczne PoC obniża próg wejścia dla cyberprzestępców,
skutkiem może być pełne przejęcie domeny i dalsza eskalacja przez Kerberos oraz DCSync.

Kontekst / historia

Microsoft załatał podatność w ramach pakietu Patch Tuesday z lipca 2026 roku. Po publikacji poprawek badacze odpowiedzialni za zgłoszenie błędu opublikowali również techniczne szczegóły oraz kod demonstracyjny, co istotnie zwiększyło ryzyko praktycznego wykorzystania luki w niezałatanych środowiskach.

Znaczenie tego przypadku wynika z centralnej roli, jaką AD CS odgrywa w infrastrukturze przedsiębiorstw korzystających z Active Directory. Usługa jest fundamentem firmowego PKI i wspiera uwierzytelnianie, szyfrowanie oraz integrację z Kerberosem. W ostatnich latach AD CS pozostaje jednym z najważniejszych obszarów analiz bezpieczeństwa, ponieważ błędy w mapowaniu tożsamości certyfikatów często prowadzą do przejęcia kont uprzywilejowanych bez potrzeby łamania haseł.

Analiza techniczna

Istota ataku dotyczy mechanizmu awaryjnego wyszukiwania używanego podczas obsługi żądań wystawienia certyfikatu. W tym procesie urząd certyfikacji korzysta z wartości przekazanych w żądaniu, w tym informacji o serwerze, z którym ma się połączyć, oraz koncie, którego dane mają zostać pobrane. Historyczny problem polegał na tym, że wskazany host nie był weryfikowany wystarczająco rygorystycznie jako prawidłowy kontroler domeny.

W efekcie napastnik mógł przygotować własne usługi SMB, LSA i LDAP oraz skłonić AD CS do komunikacji z podstawioną infrastrukturą. Gdy urząd certyfikacji pobierał informacje o koncie maszyny, otrzymywał odpowiedzi kontrolowane przez atakującego. Jeżeli celem było konto kontrolera domeny, wystawiony certyfikat mógł następnie posłużyć do uwierzytelnienia przez PKINIT jako ten kontroler.

Ważnym elementem scenariusza jest domyślna możliwość tworzenia kont komputerów przez zwykłych użytkowników domenowych. W wielu środowiskach parametr ms-DS-MachineAccountQuota nadal pozwala na utworzenie własnego obiektu maszyny w domenie. Takie konto jest pełnoprawnym principalem domenowym, co ułatwia spełnienie części wymagań uwierzytelniających potrzebnych do nadużycia mechanizmu wystawiania certyfikatów.

Po uzyskaniu certyfikatu atakujący może zalogować się jako wybrany kontroler domeny, zapisać bilety Kerberos i przejść do dalszych działań. Kolejnym krokiem może być pozyskanie skrótu NT konta maszyny lub wykonanie operacji DCSync. Ponieważ konto kontrolera domeny posiada prawa do replikacji katalogu, przeciwnik może uzyskać dostęp do sekretów Active Directory, w tym danych konta krbtgt. Na tym etapie organizacja powinna traktować incydent jako pełną kompromitację domeny.

Microsoft usunął problem przez wprowadzenie dodatkowej walidacji. Mechanizm ma teraz potwierdzać, że serwer wskazany w żądaniu rzeczywiście odpowiada prawidłowemu kontrolerowi domeny w Active Directory oraz że zwrócona tożsamość pasuje do oczekiwanego obiektu.

Konsekwencje / ryzyko

Ryzyko związane z Certighost jest bardzo wysokie, ponieważ atak może rozpocząć się od konta o niskich uprawnieniach, a zakończyć pełnym przejęciem domeny. Obecność publicznego PoC dodatkowo zwiększa prawdopodobieństwo wykorzystania luki przez operatorów ransomware, grupy APT oraz przestępców prowadzących kampanie oportunistyczne.

pełne przejęcie domeny Windows,
kradzież poświadczeń uprzywilejowanych,
trwałe utrzymanie dostępu dzięki kompromitacji zaufania Kerberos,
podszywanie się pod usługi krytyczne i konta infrastrukturalne,
przygotowanie środowiska pod szyfrowanie systemów lub sabotaż operacyjny.

Szczególnie zagrożone są organizacje korzystające z AD CS, które nie wdrożyły jeszcze poprawek z lipca 2026 roku, pozostawiły domyślne ustawienia tworzenia kont maszyn oraz nie monitorują w wystarczającym stopniu procesów wystawiania certyfikatów i nietypowego użycia PKINIT.

Rekomendacje

Najważniejszym krokiem jest pilne wdrożenie aktualizacji bezpieczeństwa opublikowanych przez Microsoft. W organizacjach, gdzie AD CS stanowi część krytycznej infrastruktury tożsamości, patching powinien zostać potraktowany priorytetowo i przeprowadzony we współpracy z zespołami odpowiedzialnymi za PKI, IAM oraz administrację domenową.

przeprowadzić inwentaryzację wszystkich serwerów AD CS i używanych szablonów certyfikatów,
sprawdzić wartość ms-DS-MachineAccountQuota i rozważyć jej ograniczenie lub ustawienie na zero,
monitorować żądania certyfikatów dotyczące kont maszyn i kontrolerów domeny,
analizować logi Kerberos pod kątem nietypowego użycia PKINIT,
wykrywać operacje DCSync i traktować je jako zdarzenia najwyższego priorytetu,
ograniczyć dostęp administracyjny i sieciowy do serwerów CA zgodnie z zasadą najmniejszych uprawnień,
przeprowadzić przegląd architektury zaufania wokół LDAP, SMB oraz mapowania tożsamości certyfikatów.

Jeżeli natychmiastowe wdrożenie poprawek nie jest możliwe, można rozważyć zastosowanie tymczasowych obejść konfiguracyjnych związanych z mechanizmem fallback w AD CS. Nie powinny one jednak zastępować właściwej aktualizacji, ponieważ ich skuteczność zależy od konkretnej konfiguracji środowiska.

Z perspektywy incident response i threat huntingu warto również przeanalizować historię tworzenia nowych kont komputerów, sprawdzić wystawione certyfikaty dla kont maszyn i kontrolerów domeny, a także zweryfikować, czy nie doszło do prób uzyskania dostępu do sekretów krbtgt. Taki sygnał może oznaczać konieczność szerokiej odbudowy zaufania w domenie.

Podsumowanie

Certighost pokazuje, jak niebezpieczne mogą być błędy w integracji usług certyfikatów z Active Directory. Publiczne PoC potwierdza, że podatność nie ma wyłącznie charakteru teoretycznego i może zostać wykorzystana do przejścia od zwykłego konta domenowego do uprawnień krytycznych dla całego środowiska.

Dla organizacji korzystających z AD CS oznacza to konieczność natychmiastowego działania: wdrożenia poprawek, przeglądu konfiguracji kont maszyn, wzmocnienia monitoringu PKI i Kerberos oraz potraktowania infrastruktury certyfikatów jako jednego z najważniejszych elementów ochrony tożsamości.

Źródła

BleepingComputer — New Certighost PoC exploit lets attackers hijack Windows domains — https://www.bleepingcomputer.com/news/security/new-certighost-poc-exploit-lets-attackers-hijack-windows-domains/
Microsoft Security Response Center — CVE-2026-54121 — https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-54121
Microsoft Security Response Center — July 2026 Security Updates — https://msrc.microsoft.com/update-guide/releaseNote/2026-Jul
H0j3n and Aniq Fakhrul — Certighost technical write-up — https://gist.github.com/
GitHub — certighost.py proof-of-concept — https://github.com/

Certighost: nowe PoC ujawnia drogę do przejęcia domeny Windows przez AD CS

Wprowadzenie do problemu / definicja

W skrócie

atak wymaga uwierzytelnionego konta domenowego, a nie uprawnień administracyjnych na starcie,
celem może być uzyskanie certyfikatu dla konta maszyny lub kontrolera domeny,
publiczne PoC obniża próg wejścia dla cyberprzestępców,
skutkiem może być pełne przejęcie domeny i dalsza eskalacja przez Kerberos oraz DCSync.

Kontekst / historia

Analiza techniczna

Konsekwencje / ryzyko

pełne przejęcie domeny Windows,
kradzież poświadczeń uprzywilejowanych,
trwałe utrzymanie dostępu dzięki kompromitacji zaufania Kerberos,
podszywanie się pod usługi krytyczne i konta infrastrukturalne,
przygotowanie środowiska pod szyfrowanie systemów lub sabotaż operacyjny.

Rekomendacje

przeprowadzić inwentaryzację wszystkich serwerów AD CS i używanych szablonów certyfikatów,
sprawdzić wartość ms-DS-MachineAccountQuota i rozważyć jej ograniczenie lub ustawienie na zero,
monitorować żądania certyfikatów dotyczące kont maszyn i kontrolerów domeny,
analizować logi Kerberos pod kątem nietypowego użycia PKINIT,
wykrywać operacje DCSync i traktować je jako zdarzenia najwyższego priorytetu,
ograniczyć dostęp administracyjny i sieciowy do serwerów CA zgodnie z zasadą najmniejszych uprawnień,
przeprowadzić przegląd architektury zaufania wokół LDAP, SMB oraz mapowania tożsamości certyfikatów.

Podsumowanie

Źródła

BleepingComputer — New Certighost PoC exploit lets attackers hijack Windows domains — https://www.bleepingcomputer.com/news/security/new-certighost-poc-exploit-lets-attackers-hijack-windows-domains/
Microsoft Security Response Center — CVE-2026-54121 — https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-54121
Microsoft Security Response Center — July 2026 Security Updates — https://msrc.microsoft.com/update-guide/releaseNote/2026-Jul
H0j3n and Aniq Fakhrul — Certighost technical write-up — https://gist.github.com/
GitHub — certighost.py proof-of-concept — https://github.com/

Certighost: nowe PoC ujawnia drogę do przejęcia domeny Windows przez AD CS

Wprowadzenie do problemu / definicja

W skrócie

atak wymaga uwierzytelnionego konta domenowego, a nie uprawnień administracyjnych na starcie,
celem może być uzyskanie certyfikatu dla konta maszyny lub kontrolera domeny,
publiczne PoC obniża próg wejścia dla cyberprzestępców,
skutkiem może być pełne przejęcie domeny i dalsza eskalacja przez Kerberos oraz DCSync.

Kontekst / historia

Analiza techniczna

Konsekwencje / ryzyko

pełne przejęcie domeny Windows,
kradzież poświadczeń uprzywilejowanych,
trwałe utrzymanie dostępu dzięki kompromitacji zaufania Kerberos,
podszywanie się pod usługi krytyczne i konta infrastrukturalne,
przygotowanie środowiska pod szyfrowanie systemów lub sabotaż operacyjny.

Rekomendacje

przeprowadzić inwentaryzację wszystkich serwerów AD CS i używanych szablonów certyfikatów,
sprawdzić wartość ms-DS-MachineAccountQuota i rozważyć jej ograniczenie lub ustawienie na zero,
monitorować żądania certyfikatów dotyczące kont maszyn i kontrolerów domeny,
analizować logi Kerberos pod kątem nietypowego użycia PKINIT,
wykrywać operacje DCSync i traktować je jako zdarzenia najwyższego priorytetu,
ograniczyć dostęp administracyjny i sieciowy do serwerów CA zgodnie z zasadą najmniejszych uprawnień,
przeprowadzić przegląd architektury zaufania wokół LDAP, SMB oraz mapowania tożsamości certyfikatów.

Podsumowanie

Źródła

BleepingComputer — New Certighost PoC exploit lets attackers hijack Windows domains — https://www.bleepingcomputer.com/news/security/new-certighost-poc-exploit-lets-attackers-hijack-windows-domains/
Microsoft Security Response Center — CVE-2026-54121 — https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-54121
Microsoft Security Response Center — July 2026 Security Updates — https://msrc.microsoft.com/update-guide/releaseNote/2026-Jul
H0j3n and Aniq Fakhrul — Certighost technical write-up — https://gist.github.com/
GitHub — certighost.py proof-of-concept — https://github.com/

Irańscy aktorzy APT atakują systemy sterowania w sektorze wodnym i energetycznym USA

Wprowadzenie do problemu / definicja

Amerykańskie agencje federalne ostrzegają przed aktywną kampanią wymierzoną w środowiska OT oraz programowalne sterowniki logiczne wykorzystywane w sektorach infrastruktury krytycznej. Chodzi o systemy odpowiedzialne za sterowanie procesami przemysłowymi, w których kompromitacja PLC, HMI i SCADA może prowadzić nie tylko do zakłóceń operacyjnych, ale również do powstania niebezpiecznych stanów procesu.

Najważniejszy element zagrożenia polega na tym, że atakujący nie ograniczają się do klasycznego dostępu do sieci, lecz dążą do ingerencji w logikę sterowania. To oznacza przejście od rozpoznania i penetracji do realnego wpływu na fizyczne działanie instalacji.

W skrócie

Kampania koncentruje się na przejmowaniu dostępu do urządzeń OT wystawionych bezpośrednio do internetu lub osiągalnych przez słabo zabezpieczone kanały zdalnego dostępu. Po uzyskaniu łączności atakujący korzystają z legalnego oprogramowania inżynierskiego dostawców, pobierają projekty sterowników, modyfikują logikę procesu i ponownie wgrywają zmienione pliki do urządzeń.

przejmowanie dostępu do publicznie dostępnych zasobów OT,
modyfikacja projektów sterowników PLC,
manipulacja danymi prezentowanymi w HMI i SCADA,
wyłączanie alarmów i mechanizmów bezpiecznego zatrzymania,
zwiększanie ryzyka zakłóceń operacyjnych i incydentów safety.

Kontekst / historia

Obecne ostrzeżenia wpisują się w szerszy wzorzec aktywności irańskich grup cybernetycznych wymierzonych w infrastrukturę krytyczną. Wcześniejsze doniesienia koncentrowały się na wybranych rodzinach sterowników przemysłowych, jednak nowsze informacje sugerują rozszerzenie działań także na rozwiązania innych dużych producentów automatyki.

To istotna zmiana, ponieważ świadczy o dojrzewaniu zdolności operacyjnych przeciwnika. Ataki nie są już postrzegane wyłącznie jako incydenty IT, lecz jako działania ukierunkowane na sam proces przemysłowy, szczególnie w sektorach wodno-kanalizacyjnym, energetycznym oraz w jednostkach powiązanych z administracją publiczną.

Analiza techniczna

Technicznie kampania nie musi opierać się na exploitach zero-day. Kluczowym wektorem jest ekspozycja urządzeń PLC i innych elementów OT do internetu albo udostępnienie ich przez niewłaściwie zabezpieczony zdalny dostęp. W obserwowanych przypadkach wskazywano aktywność na portach kojarzonych z usługami przemysłowymi oraz przez kanały administracyjne, takie jak SSH.

Po uzyskaniu dostępu atakujący pobierają projekt sterownika za pomocą natywnych narzędzi inżynierskich. Następnie analizują logikę drabinkową, bloki funkcyjne, konfigurację komunikacji i zależności z systemami wizualizacji. Zmieniony projekt zostaje ponownie wgrany do PLC, co pozwala wpływać na zachowanie procesu bez konieczności stosowania niestandardowego malware.

Zakres modyfikacji może obejmować:

usunięcie lub nadpisanie logiki odpowiedzialnej za bezpieczne parametry pracy,
zmiany w Add-On Instructions i modułach wielokrotnego użycia,
modyfikację warunków aktywacji alarmów,
wyłączenie automatycznych sekwencji shutdown,
fałszowanie danych widocznych dla operatorów w HMI i SCADA.

Najgroźniejszy scenariusz polega na rozdzieleniu rzeczywistego stanu procesu od obrazu prezentowanego personelowi operatorskiemu. Jeżeli logika PLC zostanie zmieniona, a jednocześnie dane na ekranach zostaną zmanipulowane, operator może nie zauważyć pracy instalacji poza bezpiecznym zakresem. To klasyczny atak na integralność procesu, w którym kluczowa jest zdolność ukrycia zmian do momentu wystąpienia skutków operacyjnych.

Konsekwencje / ryzyko

Ryzyko należy rozpatrywać w trzech warstwach: dostępności, integralności i bezpieczeństwa fizycznego. Modyfikacja logiki PLC może doprowadzić do zatrzymania procesu, awarii linii technologicznej, przerw w dostawach mediów lub kosztownych przestojów. Jednocześnie zmiana alarmów, blokad i parametrów pracy podważa zaufanie do danych procesowych i samego systemu sterowania.

Najpoważniejsze konsekwencje dotyczą jednak warstwy safety. W środowiskach wodnych i energetycznych błędne sterowanie może wpływać na ciśnienie, przepływ, dozowanie, temperaturę, obciążenie urządzeń oraz reakcje awaryjne. W praktyce jedna kampania może więc jednocześnie wywołać incydent cyberbezpieczeństwa, zakłócenie operacyjne i zagrożenie dla bezpieczeństwa fizycznego infrastruktury.

Dodatkowym problemem jest wykorzystanie legalnego oprogramowania producentów, co utrudnia wykrywanie nieautoryzowanych działań. Ruch generowany przez narzędzia inżynierskie może wyglądać wiarygodnie, jeśli organizacja nie monitoruje połączeń do sterowników i nie kontroluje integralności projektów.

Rekomendacje

Najważniejszym krokiem obronnym pozostaje całkowite wyeliminowanie bezpośredniej ekspozycji PLC i innych zasobów OT do internetu. Sterowniki nie powinny być publicznie dostępne ani przez natywne porty przemysłowe, ani przez improwizowane kanały zdalnego dostępu. Serwis powinien odbywać się wyłącznie przez kontrolowane bramy, silne uwierzytelnianie, segmentację sieci oraz dedykowane rozwiązania bezpiecznego dostępu.

zinwentaryzować wszystkie PLC, HMI, stacje inżynierskie i połączenia zdalne,
zablokować komunikację z internetu do portów przemysłowych,
ograniczyć uruchamianie oprogramowania inżynierskiego do autoryzowanych hostów,
monitorować transfery projektów i zmiany logiki sterowników,
regularnie porównywać aktywny projekt PLC z wersją referencyjną,
włączyć alertowanie dla zmian w alarmach, shutdown i instrukcjach dodatkowych,
prowadzić centralne logowanie z zapór, serwerów zdalnego dostępu i stacji inżynierskich,
testować odtworzenie projektów sterowników z zaufanych kopii zapasowych,
stosować zalecenia bezpieczeństwa producentów automatyki,
koordynować reakcję incydentową między zespołami IT, OT i inżynierią procesu.

W środowiskach o podwyższonym ryzyku szczególnie ważna jest walidacja integralności projektu przed i po każdym oknie serwisowym. Każda nieautoryzowana zmiana logiki PLC powinna być traktowana jako incydent wysokiego priorytetu, nawet jeśli proces pozornie działa poprawnie.

Podsumowanie

Aktualna kampania pokazuje, że zagrożenia dla infrastruktury krytycznej coraz częściej koncentrują się na bezpośredniej manipulacji procesem przemysłowym, a nie wyłącznie na kompromitacji klasycznych systemów IT. W sektorach wodnym i energetycznym skutki takich działań mogą obejmować przestoje, straty finansowe, utratę integralności danych operatorskich oraz poważne konsekwencje dla bezpieczeństwa procesu.

Dla organizacji korzystających z systemów OT oznacza to konieczność wzmocnienia kontroli dostępu, monitorowania zmian w logice sterowników oraz bezwzględnego usunięcia internetowej ekspozycji urządzeń sterowania. To dziś jeden z kluczowych warunków ograniczenia ryzyka sabotażu cyfrowego wymierzonego w procesy przemysłowe.

Źródła

Security Affairs — https://securityaffairs.com/195991/apt/iran-linked-actors-breach-are-targeting-us-water-and-energy-control-systems.html
IC3 / Joint Cybersecurity Advisory AA26-097A — https://www.ic3.gov/CSA/2026/260407.pdf
US EPA — Iranian APT Actors Targeting PLCs: Impacts and Mitigations for Water and Wastewater Systems — https://www.epa.gov/cyberwater/iranian-apt-actors-targeting-plcs-impacts-and-mitigations-water-and-wastewater-systems
Infosecurity Magazine — Iranian Hackers Target Siemens and Schneider Industrial Systems — https://www.infosecurity-magazine.com/news/iran-hackers-siemen-schneider-ics/

Irańscy operatorzy APT celują w systemy sterowania wodociągami i energetyką w USA

Wprowadzenie do problemu / definicja

Amerykańskie agencje federalne ostrzegają przed aktywną kampanią przypisywaną podmiotom powiązanym z Iranem, wymierzoną w systemy sterowania przemysłowego wykorzystywane w sektorze wodnym i energetycznym. Celem są środowiska OT i ICS, w tym sterowniki PLC, interfejsy HMI oraz platformy SCADA, które w wielu organizacjach pozostają dostępne z internetu lub są osiągalne przez niewystarczająco zabezpieczone mechanizmy zdalnego dostępu.

To zagrożenie ma szczególną wagę, ponieważ dotyczy infrastruktury krytycznej, gdzie skutki incydentu cybernetycznego mogą wykraczać poza sferę IT i prowadzić do realnych zakłóceń fizycznych. W praktyce oznacza to ryzyko ingerencji w procesy technologiczne odpowiedzialne za dostawy wody, pracę pomp, zaworów, napędów oraz elementów nadzorujących bezpieczeństwo operacyjne.

W skrócie

Kampania koncentruje się na internetowo eksponowanych urządzeniach przemysłowych obsługujących procesy krytyczne. Atakujący uzyskują dostęp przez typowe porty OT oraz usługi administracji zdalnej, a następnie pobierają pliki projektowe, analizują logikę działania sterowników i wprowadzają zmiany wpływające na sterowanie procesem.

celem są systemy wodociągowe i energetyczne w USA,
atak obejmuje urządzenia PLC, HMI i środowiska SCADA,
przeciwnik wykorzystuje legalne narzędzia inżynierskie producentów,
możliwe są zakłócenia pracy, straty finansowe i wzrost ryzyka awarii fizycznej,
szczególnie groźna jest manipulacja alarmami i wizualizacją procesu.

Kontekst / historia

Obecna kampania wpisuje się w szerszy trend eskalacji działań cybernetycznych wymierzonych w infrastrukturę krytyczną Stanów Zjednoczonych. W poprzednich latach ostrzeżenia koncentrowały się często na pojedynczych rodzinach urządzeń lub konkretnych lukach, jednak obecnie zakres ryzyka obejmuje więcej platform, producentów i scenariuszy dostępu zdalnego.

Z perspektywy strategicznej jest to kolejny przykład przesuwania aktywności grup państwowych i quasi-państwowych z klasycznego cyberszpiegostwa w kierunku operacji zakłócających. Różnica ma fundamentalne znaczenie: w warstwie OT nawet niewielka i trudna do zauważenia modyfikacja logiki sterowania może doprowadzić do destabilizacji procesu przemysłowego, utraty kontroli nad instalacją lub sytuacji niebezpiecznej dla personelu.

Analiza techniczna

Z dostępnych informacji wynika, że atakujący koncentrują się na urządzeniach wystawionych bezpośrednio do internetu oraz systemach osiągalnych przez modemy i sesje administracyjne. Wśród wskazywanych wektorów dostępu pojawiają się porty charakterystyczne dla środowisk przemysłowych, takie jak 44818, 2222, 102 i 502, a także standardowy port 22 wykorzystywany przez SSH.

Po uzyskaniu dostępu przeciwnik korzysta z natywnych narzędzi inżynierskich producentów, aby pobrać konfiguracje i pliki projektowe sterowników. To etap krytyczny, ponieważ umożliwia dokładną analizę logiki procesu, zależności między komponentami oraz sposobu działania alarmów, blokad i procedur awaryjnych. Następnie może zostać przygotowany zmodyfikowany projekt, który z perspektywy operatora wygląda wiarygodnie, ale zawiera nieautoryzowane zmiany.

Kolejna faza obejmuje manipulację logiką sterującą, a w niektórych przypadkach także jej częściowe usuwanie lub nadpisywanie. Z technicznego punktu widzenia może to oznaczać zmianę sekwencji działania urządzeń wykonawczych oraz dezaktywację elementów odpowiedzialnych za bezpieczne parametry pracy.

zmiana sekwencji sterowania pompami, zaworami lub napędami,
wyłączenie warunków zatrzymania awaryjnego,
dezaktywacja progów alarmowych,
nadpisanie instrukcji funkcyjnych i bloków rozszerzających,
manipulacja danymi prezentowanymi na ekranach HMI i w systemach SCADA.

Szczególnie niebezpieczny jest scenariusz, w którym proces technologiczny nadal działa pozornie poprawnie, ale operator otrzymuje niepełny lub zafałszowany obraz sytuacji. Tego typu ingerencja utrudnia wykrycie anomalii, wydłuża czas reakcji i zwiększa ryzyko wystąpienia awarii wtórnej. Dodatkowym problemem jest wykorzystanie legalnych narzędzi administracyjnych, co powoduje, że aktywność napastnika może przypominać rutynowe działania inżynierskie.

Konsekwencje / ryzyko

Ryzyko dla organizacji ma charakter wielowarstwowy. Na poziomie operacyjnym skutkiem może być zakłócenie uzdatniania i dystrybucji wody, przerwanie pracy zakładu, błędne sterowanie procesami energetycznymi lub utrata widoczności nad kluczowymi parametrami produkcyjnymi. W sektorach krytycznych nawet krótkotrwały incydent może wywołać konsekwencje społeczne, regulacyjne i finansowe.

Jeszcze groźniejsze są skutki związane z bezpieczeństwem procesowym. Jeśli modyfikacje obejmują wyłączenie alarmów, blokad lub logiki ochronnej, instalacja może wejść w stan niebezpieczny bez odpowiedniej sygnalizacji dla operatora. W takiej sytuacji organizacja traci podstawowe mechanizmy obronne przed uszkodzeniem urządzeń, przestojem technologicznym, skażeniem medium lub zagrożeniem dla personelu.

Na poziomie cyberbezpieczeństwa poważnym problemem pozostaje trudność jednoznacznego wykrycia kompromitacji. W wielu środowiskach OT nadal brakuje pełnej rejestracji zmian logiki sterowników, kontroli integralności projektów, centralnego monitoringu połączeń zdalnych oraz procedur szybkiej walidacji stanu procesu po incydencie. To daje przeciwnikowi możliwość utrzymywania obecności przez dłuższy czas i ponownego wejścia do środowiska.

Rekomendacje

Operatorzy środowisk ICS i SCADA powinni potraktować ten typ zagrożenia jako priorytetowy. Obrona nie może ograniczać się wyłącznie do klasycznych mechanizmów bezpieczeństwa IT, ponieważ kluczowe znaczenie ma również integralność logiki sterowania oraz faktyczny stan fizyczny procesu.

usunąć bezpośrednią ekspozycję sterowników PLC, HMI i serwerów SCADA do internetu,
wdrożyć segmentację sieci IT i OT zgodnie z zasadą minimalnego dostępu,
ograniczyć zdalną administrację do kontrolowanych bram z silnym uwierzytelnianiem wieloskładnikowym,
przeprowadzić audyt aktywnych portów i usług typowych dla środowisk przemysłowych,
monitorować zmiany w plikach projektowych sterowników i porównywać je z wersjami referencyjnymi,
weryfikować integralność logiki PLC po każdym nieplanowanym restarcie, serwisie lub połączeniu zdalnym,
analizować logi stacji inżynierskich i operatorskich pod kątem nietypowych sesji oraz eksportu projektów,
egzekwować listę zatwierdzonych stacji mogących programować sterowniki,
utrzymywać aktualne kopie zapasowe projektów PLC, HMI i SCADA wraz z procedurami odtworzeniowymi,
regularnie przeglądać konfigurację alarmów, blokad procesowych i funkcji bezpieczeństwa.

Równie ważne jest przygotowanie procedury reagowania specyficznej dla środowisk OT. W praktyce oznacza to ścisłą współpracę zespołów SOC, inżynierów automatyki, utrzymania ruchu oraz specjalistów odpowiedzialnych za bezpieczeństwo procesowe. W przypadku podejrzenia kompromitacji nie wystarczy odizolować pojedynczego hosta — konieczna jest także weryfikacja logiki sterowników oraz rzeczywistego stanu instalacji.

Podsumowanie

Najnowsze ostrzeżenia potwierdzają, że internetowo dostępne systemy sterowania w sektorze wodnym i energetycznym pozostają atrakcyjnym celem dla zaawansowanych grup powiązanych z państwami. W tym scenariuszu stawką nie jest wyłącznie dostęp do sieci czy kradzież informacji, ale możliwość cichej zmiany działania procesu przemysłowego oraz osłabienia mechanizmów bezpieczeństwa.

Dla operatorów infrastruktury krytycznej oznacza to konieczność traktowania integralności PLC, HMI i SCADA jako jednego z najważniejszych obszarów obrony. Największe ryzyko nie wynika dziś tylko z obecności przeciwnika w środowisku, lecz z jego zdolności do niezauważalnej ingerencji w proces technologiczny i sposób prezentacji danych operatorowi.

Źródła

https://securityaffairs.com/195991/apt/iran-linked-actors-breach-are-targeting-us-water-and-energy-control-systems.html
https://www.cisa.gov/
https://www.fbi.gov/
https://www.nsa.gov/
https://www.energy.gov/