Wyobraź sobie, że wpisujesz nazwę własnej firmy w Google. W wynikach wyszukiwania wszystko wygląda poprawnie dopóki nie zauważasz domeny, której nigdy wcześniej nie widziałeś. Wchodzisz na nią, widzisz własną stronę, aktualne artykuły, zdjęcia, komentarze. Pierwsza myśl? Ktoś włamał się na serwer. Dokładnie od tego rozpoczęła się historia opisana w tym artykule.
Nie każdy incydent związany z bezpieczeństwem stron internetowych zaczyna się od komunikatu o włamaniu, zainfekowanego WordPressa czy podejrzanych wpisów w logach serwera. Czasami pierwszy sygnał jest znacznie bardziej niepozorny.
W naszym przypadku był nim adres URL, który pojawił się w wynikach wyszukiwania Google. Domena wyglądała znajomo. Po wejściu na stronę okazało się, że prezentuje identyczną zawartość jak prowadzony przez nas serwis BikeSalon.pl.
Początkowo wszystko wskazywało na klasyczną kompromitację środowiska. Nowe artykuły pojawiały się pod obcą domeną natychmiast po publikacji. Synchronizowały się komentarze. Widoczne były nawet zmiany wprowadzone w konfiguracji SEO.
Przez kilka dni analizowaliśmy WordPressa, serwer oraz infrastrukturę sieciową, próbując znaleźć ślady włamania. Nie znaleźliśmy żadnych. Ostatecznie okazało się, że źródło problemu znajdowało się w zupełnie innym miejscu.
Mechanizm wykorzystywał usługę Cloudflare Workers do prezentowania zawartości naszej strony pod inną domeną. Co więcej, w trakcie dalszej analizy odkryliśmy, że podobny schemat dotyczy również innych polskich serwisów internetowych.
W tym artykule przedstawiamy pełny przebieg analizy – od pierwszego wykrycia incydentu, przez kolejne hipotezy i działania techniczne, aż po skuteczne zatrzymanie mechanizmu oraz procedury prowadzone z Google, Cloudflare i innymi podmiotami.
Mamy nadzieję, że opis naszego doświadczenia pomoże administratorom, właścicielom stron oraz specjalistom SEO szybciej zidentyfikować podobne przypadki i uniknąć wielu godzin niepotrzebnej diagnostyki.
Rozdział 1. Czy można skopiować całą stronę internetową bez włamania?
Większość administratorów, specjalistów SEO czy właścicieli stron internetowych odpowiedziałaby na to pytanie dość jednoznacznie. Jeżeli pod obcą domeną pojawia się identyczna zawartość naszej strony, prawdopodobnie doszło do włamania, wycieku danych lub skopiowania plików serwera. Jeszcze kilka tygodni temu odpowiedzielibyśmy dokładnie tak samo.
W lipcu 2026 roku prowadziliśmy prace nad rozwojem projektu BikeSalon.pl. Był to jeden z nowych serwisów znajdujących się w naszym portfolio, dlatego (jak w przypadku każdego nowego projektu) regularnie monitorowaliśmy indeksację, widoczność w Google oraz pierwsze sygnały związane z SEO.
Podczas jednej z rutynowych analiz zauważyliśmy coś, co początkowo wyglądało jak zwykła anomalia. W wynikach wyszukiwania Google zaczęła pojawiać się domena BikeSalon.mom.
Sama obecność podobnej domeny nie byłaby jeszcze niczym wyjątkowym. Internet pełen jest stron kopiujących fragmenty artykułów, agregatorów treści czy serwisów wykorzystujących RSS.
Problem polegał na tym, że po wejściu na stronę zobaczyliśmy praktycznie cały nasz serwis. Nie pojedynczy artykuł, nie kilka zdjęć, nie archiwalną kopię. Aktualną wersję BikeSalon.pl.
Jeszcze bardziej niepokojące było jednak to, że domena .mom zaczęła pojawiać się w wynikach wyszukiwania na zapytania, na które wcześniej widoczny był oryginalny serwis BikeSalon.pl. W części przypadków kopia zaczęła wręcz wypierać stronę źródłową z SERP-ów.
Było to szczególnie zaskakujące, ponieważ analiza profilu linkowego domeny BikeSalon.mom nie wskazywała na żadne istotne zaplecze SEO. Domena była świeża, miała znikomy profil odsyłających domen i nie posiadała historii, która mogłaby uzasadniać tak szybką widoczność w Google.
Mimo to Google zaczęło traktować ją jak pełnoprawny serwis i wyświetlać dla fraz związanych z publikowanymi przez nas artykułami. To oznaczało, że problem nie ograniczał się już do samego kopiowania treści. Mirror zaczął realnie konkurować z oryginałem o ruch organiczny.
Co więcej, kolejne obserwacje pokazały coś jeszcze bardziej niepokojącego. Nowo opublikowane artykuły pojawiały się pod domeną .mom w czasie rzeczywistym. Zmiany w treści były widoczne po kilku sekundach – synchronizowały się nawet komentarze oraz testowe zmiany wprowadzone w konfiguracji SEO. To nie wyglądało jak klasyczna kopia strony internetowej, ale jakby ktoś korzystał z naszego serwera w czasie rzeczywistym.
Naturalnym podejrzeniem było włamanie. Rozpoczęliśmy więc analizę, która (jak się później okazało) prowadziła do zupełnie innych wniosków.
Rozdział 2. Projekt BikeSalon.pl i pierwszy sygnał ostrzegawczy
Historia zaczęła się zaledwie kilka tygodni wcześniej, kiedy zdecydowaliśmy się na kupno wygasłej domeny BikeSalon.pl z myślą o budowie nowoczesnego serwisu poświęconego rowerom.
Jak w przypadku większości projektów opartych o domeny z historią, pierwsze tygodnie po uruchomieniu poświęciliśmy na odbudowę zawartości oraz monitorowanie zachowania wyszukiwarki Google.
Na tym etapie szczególnie ważne były dla nas:
- tempo indeksacji nowych artykułów,
- widoczność w wynikach wyszukiwania,
- reakcja Google na nowe treści,
- zachowanie dawnych sygnałów SEO odziedziczonych po domenie.
Kilka tygodni po uruchomieniu projektu rozpoczęliśmy standardowy monitoring wyników wyszukiwania. To właśnie wtedy zauważyliśmy pierwszą nieprawidłowość. Dla części zapytań Google prezentował nie tylko BikeSalon.pl, ale również domenę BikeSalon.mom.
Na pierwszy rzut oka mogło to wyglądać na zwykłą stronę wykorzystującą podobną nazwę. Po kliknięciu w link okazało się jednak, że prezentowana jest zawartość identyczna jak na naszej stronie. Pierwszą reakcją było sprawdzenie, czy nie mamy do czynienia z prostym scraperem kopiującym treści.
Szybko okazało się jednak, że problem jest znacznie poważniejszy. Publikacja nowego artykułu na BikeSalon.pl powodowała jego natychmiastowe pojawienie się również pod domeną .mom
Podobnie wyglądały zmiany komentarzy oraz aktualizacje istniejących wpisów. W pewnym momencie wykonaliśmy nawet prosty test. Na stronie głównej dodaliśmy znacznik noindex przy pomocy wtyczki Yoast SEO. Kilka chwil później identyczna zmiana była widoczna również pod domeną .mom. To był moment, w którym przestaliśmy wierzyć, że mamy do czynienia z klasycznym kopiowaniem treści.
Wszystko wskazywało na to, że druga domena w jakiś sposób pobiera zawartość naszego serwisu w czasie rzeczywistym. Pozostawało pytanie: Jak to możliwe, skoro nikt nie uzyskał dostępu do serwera?
Rozdział 3. Pierwsza hipoteza – kompromitacja środowiska
W większości podobnych przypadków administratorzy zaczynają od jednego założenia. Jeżeli obca domena wyświetla aktualną zawartość naszej strony, oznacza to, że ktoś uzyskał dostęp do serwera lub aplikacji.
Dokładnie taki był również nasz pierwszy trop:
- rozpoczęliśmy szczegółową analizę środowiska,
- sprawdziliśmy integralność plików WordPressa,
- zweryfikowaliśmy użytkowników posiadających dostęp administracyjny,
- przeanalizowaliśmy strukturę motywu oraz wykorzystywanych wtyczek,
- przyjrzeliśmy się logom serwera, REST API oraz sposobowi generowania odpowiedzi HTTP.
Na tym etapie spodziewaliśmy się znaleźć przynajmniej jeden z klasycznych objawów kompromitacji. Nie znaleźliśmy żadnego:
- nie pojawiły się nowe konta administratorów,
- nie odnaleźliśmy podejrzanych plików,
- kod strony nie zawierał nietypowych modyfikacji,
- serwer działał prawidłowo.
To właśnie ten moment okazał się najbardziej frustrujący. Z jednej strony widzieliśmy, że druga domena prezentuje aktualną zawartość naszego serwisu. Z drugiej strony wszystkie klasyczne ślady prowadzące do kompromitacji środowiska kończyły się ślepym zaułkiem.
Im dłużej analizowaliśmy sytuację, tym bardziej oczywiste stawało się jedno. Jeżeli nie doszło do włamania, to mechanizm działania musi wyglądać zupełnie inaczej, niż początkowo zakładaliśmy. I właśnie wtedy rozpoczęła się właściwa część śledztwa.
Rozdział 4. Gdy wszystkie tropy prowadzą donikąd
W analizie incydentów bezpieczeństwa istnieje moment, który administratorzy znają bardzo dobrze. To chwila, w której wszystkie najbardziej prawdopodobne hipotezy przestają mieć sens. Dokładnie w takim miejscu znaleźliśmy się po kilku dniach analiz:
- nie znaleźliśmy śladów włamania,
- nie znaleźliśmy złośliwego kodu,
- nie znaleźliśmy podejrzanych użytkowników,
- nie znaleźliśmy żadnych zmian w plikach WordPressa.
Jednocześnie druga domena nadal wyświetlała aktualną zawartość BikeSalon.pl. Co więcej, zmiany publikowane na stronie były widoczne praktycznie natychmiast. To oznaczało, że odpowiedź musiała znajdować się poza samym WordPressem. Coraz częściej zaczęliśmy zadawać sobie pytanie, czy problem nie dotyczy infrastruktury sieciowej.
Na tym etapie analizowaliśmy między innymi sposób obsługi zapytań HTTP, zachowanie odpowiedzi serwera oraz różnice pomiędzy tym, co widział użytkownik odwiedzający BikeSalon.pl, a tym, co otrzymywała domena .mom
Dopiero wtedy zaczęła pojawiać się hipoteza, że serwis nie został skopiowany w klasyczny sposób. Wyglądało raczej na to, że ktoś zbudował warstwę pośredniczącą pomiędzy użytkownikiem, a naszym serwerem. Było to jednak jedynie przypuszczenie – brakowało dowodu.
Rozdział 5. Przełom nastąpił tam, gdzie najmniej się go spodziewaliśmy
W takich sytuacjach ogromne znaczenie ma współpraca z dostawcą hostingu. Administratorzy mają dostęp do informacji, których właściciel strony najczęściej nie widzi.
Po przekazaniu wszystkich zebranych informacji rozpoczęła się analiza ruchu docierającego do naszego serwera. To właśnie wtedy udało się zidentyfikować element, którego wcześniej nie braliśmy pod uwagę. Żądania kierowane do BikeSalon.pl zawierały charakterystyczny nagłówek wskazujący na wykorzystanie Cloudflare Workers. To całkowicie zmieniało obraz sytuacji.
Cloudflare Workers to usługa pozwalająca uruchamiać własny kod na infrastrukturze Cloudflare. Najczęściej wykorzystywana jest do optymalizacji działania aplikacji, filtrowania ruchu czy budowy własnych funkcji sieciowych. Może jednak zostać wykorzystana również jako warstwa pośrednicząca pomiędzy użytkownikiem a serwerem źródłowym.
W praktyce oznacza to, że użytkownik odwiedza domenę A, natomiast Worker pobiera zawartość z domeny B i prezentuje ją tak, jakby była częścią pierwszej strony. To tłumaczyło praktycznie wszystkie wcześniejsze obserwacje:
- nie istniała kopia WordPressa,
- nie istniała synchronizacja plików,
- nie istniała baza danych zawierająca nasze artykuły.
Za każdym razem, gdy użytkownik odwiedzał domenę .mom, Cloudflare Worker pobierał aktualną odpowiedź z BikeSalon.pl, dlatego nowe artykuły, komentarze oraz zmiany SEO były widoczne niemal natychmiast. Hipoteza stała się bardzo prawdopodobna – pozostawało ją potwierdzić.
Rozdział 6. Jedna reguła, która zmieniła wszystko
Na tym etapie warto podkreślić rolę zespołu technicznego Cyber_Folks. Początkowo wszystko wskazywało na potencjalne włamanie lub kompromitację serwera. Dopiero szczegółowa analiza logów oraz nagłówków HTTP pozwoliła ustalić, że źródłem problemu nie był serwer BikeSalon.pl, lecz zewnętrzny mechanizm wykorzystujący Cloudflare Workers. Następnie wdrożona została reguła blokująca ruch zawierający nagłówek CF-Worker, co skutecznie uniemożliwiło dalsze mirrorowanie serwisu:
RewriteCond %{HTTP:CF-Worker} !^$ [NC]
RewriteRule ^ – [F,L]
Efekt był natychmiastowy – domena .mom przestała wyświetlać zawartość BikeSalon.pl. Zamiast strony użytkownicy otrzymywali odpowiedź HTTP 403 Forbidden.
Był to pierwszy jednoznaczny dowód potwierdzający wcześniejsze ustalenia:
- nie zablokowaliśmy kopiowania plików,
- nie zatrzymaliśmy synchronizacji danych,
- odcięliśmy jedynie możliwość pobierania odpowiedzi naszego serwera przez warstwę pośredniczącą.
To właśnie ten moment zakończył techniczną część incydentu. Po raz pierwszy od kilku dni mieliśmy pewność, że mechanizm mirrorowania został skutecznie zatrzymany. Jednocześnie rozpoczęła się druga część działań.
Pozostawały kwestie związane z indeksacją przez Google, procedurą DMCA oraz ustaleniem, czy podobny mechanizm wykorzystywany jest również wobec innych polskich serwisów.
Mechanizm działania (w uproszczeniu)
W praktyce oznaczało to, że użytkownik odwiedzający domenę .mom nie oglądał zapisanej kopii strony. Każde żądanie powodowało pobranie aktualnej odpowiedzi z naszego serwera, która następnie była prezentowana pod inną domeną. To tłumaczyło między innymi:
- natychmiastowe pojawianie się nowych artykułów,
- synchronizację komentarzy,
- widoczność zmian SEO,
- brak klasycznych śladów kompromitacji środowiska,
Dlaczego podejrzewaliśmy włamanie?
Większość administratorów w podobnej sytuacji prawdopodobnie postawiłaby identyczną diagnozę. Powód jest prosty: Z perspektywy użytkownika zachowanie wyglądało dokładnie tak, jakby ktoś posiadał pełny dostęp do naszego serwera.
- nowe treści były widoczne niemal natychmiast,
- komentarze synchronizowały się w czasie rzeczywistym,
- zmiany konfiguracji SEO pojawiały się równolegle na obu domenach.
Dopiero szczegółowa analiza wykazała, że źródło problemu znajdowało się poza środowiskiem WordPressa.
Wnioski z etapu analizy
Najważniejszą lekcją płynącą z tego etapu było uświadomienie sobie, że identyczny efekt końcowy może mieć zupełnie inne przyczyny.
Z punktu widzenia użytkownika wyglądało to jak klasyczne włamanie. Z punktu widzenia infrastruktury problem okazał się zupełnie inny.
Dlatego przed rozpoczęciem działań naprawczych warto poświęcić czas na możliwie dokładne ustalenie rzeczywistego mechanizmu działania. W naszym przypadku pozwoliło to uniknąć wielu godzin niepotrzebnych prac związanych z analizą WordPressa oraz samego serwera.
Rozdział 7. Procedury zgłoszeniowe – co zadziałało, a co nie?
Po zidentyfikowaniu mechanizmu działania rozpoczęliśmy równoległe działania mające na celu ograniczenie skutków incydentu.
Ich celem było nie tylko zatrzymanie mechanizmu mirrorowania, ale również usunięcie skutków jego działania w wyszukiwarce Google oraz poinformowanie podmiotów odpowiedzialnych za infrastrukturę wykorzystywaną przez domenę .mom
Pierwszym krokiem było zgłoszenie naruszenia praw autorskich w ramach procedury DMCA.
Nie obyło się jednak bez komplikacji. Początkowo Google poprosił o dodatkowe wyjaśnienia dotyczące praw do publikowanych treści. Po przedstawieniu informacji o właścicielu serwisu oraz sposobie oznaczania autorów zgłoszenie zostało uznane.
Google poinformował następnie o globalnym usunięciu wskazanych adresów URL z wyników wyszukiwania.
Na tym etapie pojawił się jednak istotny wniosek praktyczny: Google rozpatruje konkretne adresy URL, a nie automatycznie całą domenę. Oznacza to, że w podobnych przypadkach warto od początku wskazać możliwie pełną listę naruszających adresów.
W naszym zgłoszeniu podaliśmy dwa przykładowe URL-e. Po ich usunięciu rozważaliśmy utworzenie kolejnej sprawy obejmującej wszystkie pozostałe adresy domeny .mom.
Ostatecznie uznaliśmy jednak, że z perspektywy długoterminowej nie będzie to miało większego znaczenia. W tym czasie dostęp do BikeSalon.mom został już zablokowany, serwis przestał zwracać skopiowaną zawartość, a jego adresy prowadziły do komunikatu o niedostępności. Przy takim stanie rzeczy można oczekiwać, że pozostałe URL-e będą stopniowo wypadały z indeksu Google.
Wniosek praktyczny
W zgłoszeniach DMCA do Google należy wskazywać możliwie kompletną listę naruszających adresów URL. Każdy z nich jest rozpatrywany indywidualnie.
Cloudflare
Równolegle zgłoszenie trafiło do działu Trust & Safety Cloudflare.
Po analizie sprawy otrzymaliśmy informację, że domena wykorzystuje usługę Cloudflare kwalifikującą się do obsługi zgłoszeń dotyczących naruszeń praw autorskich.
Cloudflare poinformował również o wyłączeniu dostępu do zgłoszonej domeny do czasu ewentualnego wniesienia kontrzgłoszenia przez właściciela konta.
Po upływie wskazanego terminu nie otrzymaliśmy informacji o złożeniu takiego kontrzgłoszenia, a domena nadal pozostawała niedostępna.
Z perspektywy całego incydentu była to jedna z najskuteczniejszych podjętych interwencji.
Dynadot
Zgłoszenie zostało przesłane również do rejestratora domeny.
W odpowiedzi otrzymaliśmy informację o przyjęciu zgłoszenia oraz sugestię kontaktu z dostawcą hostingu, który (jako podmiot mający bezpośredni dostęp do infrastruktury) może szybciej podjąć działania techniczne.
Do dnia publikacji niniejszego artykułu nie otrzymaliśmy jednak informacji o dalszych działaniach ani o wyniku przeprowadzonej analizy.
Nie oznacza to, że sprawa nie była procedowana. Po prostu nie otrzymaliśmy kolejnych wiadomości dotyczących zgłoszenia.
Rozdział 8. Najważniejsze wnioski
Po zakończeniu technicznej części analizy warto podsumować najważniejsze obserwacje.
8.1. Nie każda kopia strony oznacza włamanie
To chyba najważniejsza lekcja płynąca z całego incydentu.
Naturalną reakcją administratora jest rozpoczęcie analizy własnego środowiska.
W naszym przypadku okazało się jednak, że problem znajdował się całkowicie poza serwerem oraz WordPressem.
8.2. Monitorowanie wyników wyszukiwania ma znaczenie
Cały incydent został wykryty wyłącznie dzięki regularnemu monitorowaniu widoczności projektu w Google.
Gdyby nie analiza wyników wyszukiwania, mirror mógłby funkcjonować znacznie dłużej.
8.3. Warto dokumentować każdy etap
Zrzuty ekranu, zapis korespondencji oraz szczegółowa chronologia zdarzeń okazały się niezwykle pomocne podczas kontaktu z Google oraz Cloudflare.
8.4. Procedury DMCA działają
Choć wymagają cierpliwości i odpowiedniego udokumentowania sprawy, zarówno Google, jak i Cloudflare pozytywnie rozpatrzyły zgłoszenia dotyczące naruszenia praw autorskich.
8.5. Nie warto wyciągać pochopnych wniosków
Na początku analizowaliśmy wiele możliwych scenariuszy – od włamania na serwer po błędy konfiguracji.
Dopiero systematyczne wykluczanie kolejnych hipotez pozwoliło ustalić rzeczywisty mechanizm działania.
Dlaczego zdecydowaliśmy się opisać ten przypadek?
Nie publikujemy tego materiału dlatego, że problem dotknął BikeSalon.pl.
Publikujemy go, ponieważ podczas analizy natrafiliśmy na kolejne domeny .mom powiązane z istniejącymi polskimi markami – od uczelni wyższych, przez znane restauracje, po duże marki z sektora e-commerce. Wszystkie domeny, podobnie jak ta, która podszywała się pod nasz serwis została zarejestrowana na przestrzeni ostatnich dni:
Na obecnym etapie nie wiemy:
- kto odpowiada za ich utworzenie,
- czy wykorzystują identyczny mechanizm,
- ani jaki był ich rzeczywisty cel.
Uznaliśmy jednak, że samo istnienie kilku podobnych przypadków jest wystarczającym powodem, aby podzielić się naszymi obserwacjami.
Jeżeli dzięki temu choć jedna firma szybciej rozpozna podobny incydent, publikacja spełni swoje zadanie.
Podsumowanie
Gdy rozpoczynaliśmy analizę, byliśmy przekonani, że doszło do włamania na serwer. Kilka dni później wiedzieliśmy już, że źródło problemu znajdowało się zupełnie gdzie indziej.
Ta historia pokazała przede wszystkim jedno: W przypadku incydentów dotyczących stron internetowych najbardziej oczywiste wyjaśnienie nie zawsze okazuje się prawidłowe.
Dlatego warto najpierw możliwie dokładnie ustalić rzeczywisty mechanizm działania problemu. W naszym przypadku pozwoliło to odróżnić kompromitację serwera od zewnętrznego mechanizmu reverse proxy, zatrzymać mirrorowanie treści i uniknąć wielu niepotrzebnych działań po stronie WordPressa.
Mamy nadzieję, że opisany przypadek pomoże innym administratorom, właścicielom stron i specjalistom SEO szybciej rozpoznać podobny problem oraz sprawniej dobrać właściwe działania techniczne i formalne.