dhosting poinformował klientów o incydencie bezpieczeństwa, który rozpoczął się 10 listopada 2026 roku. Według firmy atak był wymierzony w jednego z jej klientów, ale objął również infrastrukturę operatora. Najciekawszym elementem komunikatu jest informacja, że zebrane ślady wskazują na wykorzystanie narzędzi sztucznej inteligencji. dhosting zdecydował się na szerokie działania prewencyjne: zresetował hasła wszystkich kont FTP i SSH oraz wprowadził obowiązkową zmianę hasła do dPanelu.

O incydencie klienci dhostingu dowiedzieli się najpierw poprzez problemy z dostępem do części usług, a później z kolejnych komunikatów operatora. Firma podaje, że 10 listopada o godz. 12:43 otrzymała informację o ataku, a już o godz. 14:35 miała zablokować możliwość dalszego wykorzystania zidentyfikowanej podatności. Z dotychczasowych ustaleń wynika, że pierwotnym celem był jeden z klientów dhostingu, jednak działania napastnika objęły również infrastrukturę samej firmy hostingowej.

dhosting: w ataku wykorzystano narzędzia AI

Szczególnie interesująco brzmi fragment komunikatu dotyczący sposobu przeprowadzenia ataku. dhosting twierdzi, że zebrane informacje wskazują na wykorzystanie narzędzi AI, choć jednocześnie zaznacza, że udział człowieka w całej operacji jest nadal analizowany. Na tym etapie nie wiadomo więc, czy sztuczna inteligencja została wykorzystana jedynie do automatyzacji części działań, przygotowania kodu, analizy infrastruktury czy też prowadzenia bardziej autonomicznego ataku.

Warto tutaj zachować ostrożność. Samo stwierdzenie, że w incydencie występują ślady wykorzystania AI, nie oznacza jeszcze pojawienia się całkowicie autonomicznego „hakera AI”, który bez udziału człowieka samodzielnie włamał się do infrastruktury hostingowej. Jest jednak znamienne, że operator hostingu zdecydował się taką informację zawrzeć w oficjalnej wiadomości skierowanej do klientów. Jeżeli późniejsza analiza techniczna potwierdzi istotną rolę modeli AI w przeprowadzeniu ataku, będzie to jeden z ciekawszych elementów całego zdarzenia.

Ślady ataku przy 0,2431% aktywnych skrzynek

Według dhostingu ślady związane z atakiem zidentyfikowano w odniesieniu do 0,2431% wszystkich aktywnych skrzynek obsługiwanych przez firmę. Operator nie napisał przy tym, że doszło do przejęcia takiego odsetka kont. Mowa właśnie o zidentyfikowanych śladach, dlatego tych dwóch rzeczy nie należy ze sobą utożsamiać.

Jest to istotne również dlatego, że komunikacja firmy w trakcie analiz ulegała zmianie. Pierwotnie dhosting informował o wycieku danych dostępowych do FTP, jednak późniejsza analiza miała tego nie potwierdzić. Firma wprost zaznacza w najnowszej wiadomości, że wcześniejsze informacje dotyczące wycieku danych FTP okazały się niepotwierdzone.

To dobry przykład tego, jak dynamicznie może zmieniać się obraz incydentu bezpieczeństwa. Pierwsze godziny po wykryciu ataku często opierają się na niepełnych danych, a administrator musi jednocześnie zabezpieczać infrastrukturę, analizować logi, ustalać zakres zdarzenia i komunikować się z tysiącami klientów. Informację o braku potwierdzenia pierwotnie podejrzewanego wycieku należy więc traktować jako istotną aktualizację, a nie dowód, że wcześniejsze działania zabezpieczające były zbędne.

Wszystkie hasła FTP i SSH zostały zresetowane

dhosting zdecydował się na bardzo szerokie działanie prewencyjne. Zresetowane zostały hasła do wszystkich kont FTP i SSH powiązanych z usługami klientów, niezależnie od tego, czy na konkretnym koncie wykryto ślady związane z atakiem. Firma wprowadziła również obowiązek zmiany hasła do dPanelu przy następnym logowaniu.

Tak szeroki reset jest uciążliwy, szczególnie dla administratorów posiadających wiele stron, serwerów i zautomatyzowanych połączeń FTP lub SSH. Z punktu widzenia bezpieczeństwa jest jednak rozwiązaniem racjonalnym. Jeżeli na początkowym etapie nie można ze stuprocentową pewnością ustalić, które dane uwierzytelniające mogły zostać naruszone, wymuszenie zmiany haseł pozwala przeciąć możliwość wykorzystania ewentualnie pozyskanych wcześniej danych.

Dla właścicieli stron internetowych oznacza to konieczność sprawdzenia również wszystkich miejsc, w których dane FTP lub SSH zostały zapisane: klientów FTP, aplikacji do wdrażania stron, skryptów wykonujących automatyczne kopie zapasowe, systemów CI/CD oraz innych usług łączących się z hostingiem.

Problemem okazały się również stare i powtarzające się hasła

Przy okazji analizy incydentu dhosting zwrócił uwagę na jeszcze jeden problem. Firma twierdzi, że wielu klientów od dawna nie zmieniało swoich haseł, a hashe części wykorzystywanych haseł występują na liście Have I Been Pwned, czyli w bazach związanych z danymi ujawnionymi podczas wcześniejszych wycieków.

Nie musi to oznaczać, że hasło zostało wykradzione właśnie z dhostingu. Znacznie częstszym problemem jest ponowne używanie tych samych albo bardzo podobnych haseł w wielu usługach. Jeżeli hasło użytkownika wycieknie z jednego serwisu, przestępcy mogą później automatycznie sprawdzać je w dziesiątkach innych miejsc. Tak działają między innymi ataki typu credential stuffing.

Dlatego samo wymuszenie bardziej skomplikowanego hasła nie rozwiązuje całego problemu. Hasło powinno być przede wszystkim unikalne. Bardzo silne hasło wykorzystywane jednocześnie w poczcie, panelu hostingowym, WordPressie i kilku innych usługach nadal pozostaje poważnym zagrożeniem. Wystarczy jeden wyciek, aby napastnik otrzymał potencjalny klucz do wielu kont.

dhosting zaostrza politykę haseł

Operator poinformował również o wdrożeniu nowej polityki haseł. Podczas ustawiania nowego hasła system ma sprawdzać jego siłę i ograniczać możliwość korzystania z danych, które mogły wcześniej pojawić się w publicznie dostępnych bazach pochodzących z wycieków.

dhosting zaznacza, że zmiany związane z bezpieczeństwem i certyfikacją ISO były przygotowywane już wcześniej, natomiast obecny incydent przyspieszył ich wdrożenie. Trudno mieć zastrzeżenia do samego kierunku zmian. Unikalne hasła, kontrola danych występujących w znanych wyciekach oraz ograniczenie możliwości wykorzystywania słabych poświadczeń powinny być standardem w usługach zapewniających dostęp do infrastruktury internetowej.

W przypadku panelu hostingowego stawka jest szczególnie wysoka. Przejęcie konta nie musi oznaczać jedynie możliwości zmiany ustawień strony. W zależności od zakresu uprawnień napastnik może uzyskać dostęp do plików serwisu, baz danych, skrzynek pocztowych, konfiguracji domen, kopii zapasowych czy danych klientów znajdujących się w aplikacji.

Uwaga na phishing wykorzystujący incydent dhostingu

Sam incydent tworzy również idealną okazję dla oszustów. Klienci wiedzą już, że powinni zmienić hasła, dlatego wiadomość zatytułowana przykładowo „Pilna zmiana hasła dhosting” może wyglądać wyjątkowo wiarygodnie. Atakujący mogą wykorzystać prawdziwe informacje o incydencie, dodać logo firmy, odpowiednią datę i przycisk prowadzący do fałszywego panelu logowania.

dhosting wyraźnie ostrzega, że nie prosi klientów o podawanie hasła przez e-mail, SMS ani telefon oraz nie wysyła w wiadomościach linków do logowania czy płatności. Operator zaleca ręczne wpisywanie adresu dPanelu w przeglądarce. W obecnej sytuacji jest to szczególnie ważna rada.

Paradoksalnie właśnie prawdziwe incydenty bezpieczeństwa należą do najlepszych pretekstów wykorzystywanych w phishingu. Ofiara spodziewa się komunikatu dotyczącego zmiany hasła, wie o problemie i może działać pod presją czasu. Oszust nie musi więc wymyślać żadnej historii. Wystarczy, że podszyje się pod prawdziwą firmę i wykorzysta sytuację, która faktycznie miała miejsce.

Co powinien teraz zrobić klient dhostingu?

Przede wszystkim należy zalogować się do dPanelu bez korzystania z linków przesłanych pocztą i ustawić nowe, unikalne hasło. Następnie trzeba utworzyć nowe hasła dla kont FTP i SSH. Każde z nich powinno być inne i nie powinno być wykorzystywane wcześniej w żadnej innej usłudze.

Warto także sprawdzić własne strony. Szczególnej uwagi wymagają nowe lub zmodyfikowane konta administratorów, nieznane pliki, zmiany w konfiguracji, podejrzane zadania cron, przekierowania, nietypowe wtyczki oraz modyfikacje wykonane w czasie odpowiadającym incydentowi. W przypadku sklepów internetowych i bardziej rozbudowanych aplikacji sensowne może być również przejrzenie logów aplikacji i historii zmian.

Jeżeli to samo hasło, które było wykorzystywane w dhostingu, zostało użyte gdziekolwiek indziej, należy zmienić je również w tych usługach. Szczególnie pilnie dotyczy to poczty elektronicznej, paneli innych hostingów, rejestratorów domen i kont administratorów stron.

Atak ograniczony, ale reakcja bardzo szeroka

Na podstawie komunikatu dhostingu nie ma obecnie podstaw, aby mówić o masowym przejęciu kont klientów czy potwierdzonym wycieku wszystkich danych dostępowych. Firma podaje stosunkowo niewielki odsetek skrzynek, przy których wykryto ślady zdarzenia, a pierwotne podejrzenie dotyczące wycieku danych FTP nie zostało potwierdzone.

Jednocześnie reakcja operatora była znacznie szersza niż ustalony na obecnym etapie zakres incydentu. Zablokowano dostęp do FTP, SSH i panelu klienta, przeprowadzono reset wszystkich danych dostępowych do FTP i SSH oraz wymuszono zmianę haseł do dPanelu. W przypadku incydentu, którego dokładny zakres dopiero jest ustalany, takie podejście jest znacznie bezpieczniejsze niż oczekiwanie na stuprocentowe potwierdzenie każdego potencjalnego scenariusza.

Najciekawsze pytanie nadal pozostaje jednak otwarte: jaką dokładnie rolę odegrała sztuczna inteligencja w przeprowadzeniu ataku? dhosting sam zwrócił uwagę na ten element, dlatego można oczekiwać, że po zakończeniu analizy technicznej pojawią się bardziej szczegółowe informacje. Jeśli AI rzeczywiście została wykorzystana nie tylko jako pomoc przy tworzeniu narzędzi, lecz również do aktywnej automatyzacji kolejnych etapów ataku, incydent może być interesującym przykładem tego, jak szybko zmieniają się możliwości cyberprzestępców.