APWG odnotowało 971 181 ataków phishingowych tylko w pierwszym kwartale 2026 roku — to wzrost o 13,8% względem poprzedniego kwartału. A w styczniu 2026 Google zakłóciło działanie tego, co nazwało jedną z największych na świecie sieci proxy opartych na łączach domowych, po ustaleniu, że w ciągu jednego tygodnia korzystało z niej ponad 550 grup zagrożeń do routowania ruchu. Jak się okazuje, proxy stoją po obu stronach walki z phishingiem.
To właśnie ten konflikt większość artykułów o „proxy i phishingu” pomija. Albo przedstawiają proxy jako tarczę („kup nasz produkt proxy i bądź bezpieczny”), albo ostrzegają, że to narzędzie atakującego („bój się”). Rzeczywistość jest bardziej złożona — i znacznie ciekawsza.
Atakujący używają infrastruktury proxy, aby ukryć źródło ruchu, rotować między zaufanymi adresami IP i kraść uwierzytelnione sesje — nawet po MFA. Zespoły obronne wykorzystują proxy do bezpiecznej analizy podejrzanych linków, sprawdzania, co pokazują strony phishingowe w różnych krajach, oraz filtrowania złośliwego ruchu, zanim dotrze on do ich serwisów. Ten poradnik omawia obie strony, a potem prowadzi przez konkretny workflow, który naprawdę da się wdrożyć. Bez ogólników, bez „cudownych” rozwiązań.
- Poziom trudności: średni
- Szacowany czas: około 25 minut na przeczytanie i zaplanowanie; wdrożenie zależy od etapu
- Czego potrzebujesz: podstawowej wiedzy o infrastrukturze webowej swojej organizacji, dostępu do ustawień DNS domeny, przeglądarki Chrome (do kroków z Thunderbit) oraz opcjonalnie konta u dostawcy proxy
Czym jest phishing i dlaczego Twoja firma powinna się nim przejmować?
Phishing to atak oparty na oszustwie. Przestępcy wykorzystują e-mail, SMS-y, fałszywe strony logowania, kody QR lub podrobione witryny, aby skłonić ofiary do ujawnienia danych dostępowych, zatwierdzenia logowania, zainstalowania złośliwego oprogramowania albo wykonania przelewu.
To już nie jest tylko problem „złego e-maila”. Współczesny phishing obejmuje strony hostowane w chmurze, fałszywe procesy logowania do Microsoft 365, kody QR i kradzież tokenów sesyjnych.
Dla firm stawka jest bardzo konkretna. W raporcie IBM 2025 Cost of a Data Breach średni globalny koszt naruszenia danych wynosi 4,4 mln USD. Z kolei raport FBI Internet Crime Report 2025 podaje, że IC3 otrzymało około 453 000 skarg na cyberoszustwa, a zgłoszone straty przekroczyły 17,7 mld USD, z czego business email compromise (BEC) odpowiadało za ponad 3 mld USD.
Kradzież danych logowania, oszustwa przelewowe, przejęcie łańcucha dostaw, kary regulacyjne — phishing dotyka wszystkiego.
Poniżej: jak proxy wpisują się zarówno w atak, jak i obronę oraz jak wygląda wielowarstwowa, realistyczna ochrona.
Podwójna natura proxy: Twoja tarcza i broń atakującego
Proxy to pośrednik między Twoim urządzeniem a internetem. Zamiast prawdziwego adresu IP witryna widzi adres proxy. To trochę jak usługa przekierowania poczty: odbiorca dostaje list z adresu pośrednika, a nie z Twojego domu.
Ta sama cecha tworzy problem podwójnego zastosowania. Zespoły bezpieczeństwa używają proxy do badania zagrożeń bez ujawniania firmowego IP czy stacji analityka. Atakujący wykorzystują dokładnie tę samą technologię, aby złośliwy ruch wyglądał jak ruch zwykłych użytkowników, z innych krajów albo zaufanych sieci domowych. Analiza Barracuda z kwietnia 2026 wyjaśnia to wprost: adresy IP z sieci domowych wyglądają autentycznie, bo są powiązane z rzeczywistymi łączami domowymi lub małej firmy, więc systemy antyfraudowe rzadziej je oznaczają.
Większość konkurencyjnych artykułów opisuje tylko jedną stronę. To zostawia czytelników z niepełnym obrazem — i niepełną ochroną.
Jak atakujący używają proxy przeciwko Tobie
Najważniejsze z perspektywy obrony firmy są trzy wektory: anonimowość i rotacja IP, nadużywanie proxy residential oraz omijanie zabezpieczeń na zaufanych platformach.
Czym jest phishing AiTM (Adversary-in-the-Middle)
AiTM to atak, który obala założenie „MFA nas chroni” (spoiler: klasyczne MFA go nie zatrzyma).
W ataku AiTM napastnik umieszcza reverse proxy między ofiarą a legalną stroną logowania — na przykład Microsoft 365. Użytkownik widzi coś, co wygląda jak prawdziwy proces logowania. Wpisuje dane, przechodzi MFA, a prawdziwy dostawca tożsamości wystawia ciasteczko sesyjne. Ale ponieważ cały ruch przechodzi przez proxy atakującego, to właśnie on przechwytuje ten cookie. Potem może go odtworzyć i dostać się do konta — bez hasła i bez kolejnego promptu MFA.
Analiza Microsoft dotycząca Tycoon2FA, jednego z najważniejszych zestawów phishingowych AiTM, pokazuje, że operatorzy potrafią podszywać się pod strony logowania Microsoft 365, Outlook, SharePoint, OneDrive i Google. Zestaw generuje PDF-y i kody QR, zarządza łańcuchami przekierowań oraz śledzi użycie MFA i przechwytywanie cookies sesji. Jego infrastruktura korzysta z krótkotrwałych subdomen i hostingu Cloudflare, by utrudnić blokowanie.
To nie jest teoria. Zestawy AiTM są aktywnie wykorzystywane na masową skalę i są głównym powodem, dla którego „mamy MFA” nie jest pełną odpowiedzią na phishing.
Nadużywanie proxy residential i rotacja IP
Sieci proxy residential routują ruch atakującego przez prawdziwe domowe adresy IP, przez co żądania phishingowe wyglądają wiarygodnie i przechodzą obok zabezpieczeń opartych na IP. Wielu dostawców nie weryfikuje rygorystycznie, w jaki sposób ich IP są używane, co tworzy szarą strefę.
Najbardziej konkretny przykład: w styczniu 2026 Google Threat Intelligence Group zakłóciło działanie sieci proxy residential IPIDEA, zmniejszając pulę dostępnych urządzeń o miliony. GTIG zaobserwowało ponad 550 pojedynczych grup zagrożeń korzystających z węzłów wyjściowych IPIDEA w ciągu zaledwie siedmiu dni. Dochodzenie wykazało powiązania z botnetami, nadużyciami dostępu do SaaS, atakami password spraying i aktorami globalnego cyberszpiegostwa. Wiele wdrożeń SDK proxy nie miało jasnej zgody użytkownika.
Poradnik FBI z 2026 roku o proxy residential wymienia phishing, logowanie na skradzione dane, ataki brute force, przejmowanie kont, spam oraz maskowanie kanałów C2 jako przestępcze zastosowania.
Hostowanie na zaufanych platformach i omijanie wykrywania przez zestawy phishingowe
Inna technika omijania wykrywania to hostowanie stron phishingowych na zaufanych platformach — SharePoint, Google Docs, Azure Blob Storage — żeby „pożyczyć” sobie reputację domeny. Analiza Microsoft dotycząca zagrożeń w Azure Blob Storage pokazuje, że atakujący używają tej usługi do hostowania podrobionych stron logowania Microsoft, co utrudnia ofiarom rozpoznanie zagrożenia tylko na podstawie certyfikatu.
Zestawy phishingowe stosują też własną logikę ukrywania się. Analiza Cofense dotycząca phishing kitów opisuje filtrowanie geolokalizacji, filtrowanie po user-agent i języku, CAPTCHA, wykrywanie narzędzi deweloperskich oraz przekierowania do legalnych stron. Jeśli odwiedzający nie pasuje do profilu ofiary — jest z niewłaściwego kraju, używa niewłaściwej przeglądarki albo wygląda na skaner bezpieczeństwa — strona pokazuje coś nieszkodliwego albo błąd 404.
Skanowanie z jednego firmowego IP albo z jednego centrum danych w chmurze takich stron po prostu nie wykryje. Zestaw jest dosłownie zaprojektowany tak, żeby się przed Tobą ukryć.
Jak obrońcy używają proxy do kontrataku
Po stronie obrony proxy pełnią cztery praktyczne funkcje:
-
Anonimowe skanowanie URL-i i domen. Podejrzane linki przechodzą przez kontrolowane proxy, dzięki czemu cel widzi adres proxy, a nie laptop pracownika czy sieć firmową. To zmniejsza bezpośrednią ekspozycję i tworzy powtarzalny proces analizy.
-
Zbieranie threat intelligence. Rotujące proxy pozwalają crawlować infrastrukturę phishingową, listy domen, publiczne feedy zagrożeń czy źródła świeżo zarejestrowanych domen bez szybkiego blokowania po kilku żądaniach. (Zawsze w granicach prawa i warunków korzystania.)
-
Wykrywanie phishingu w wielu regionach. Proxy w różnych lokalizacjach pozwalają sprawdzić, czy podejrzany URL zachowuje się inaczej z USA, UE, APAC lub innego rynku docelowego. To pomaga wykrywać zestawy używające geofencingu lub filtrowania user-agentów — tych samych technik omijania, o których mowa wyżej.
-
Reverse proxy / wdrożenie WAF. Reverse proxy stoją przed Twoimi własnymi domenami. Nie powstrzymają pracowników przed klikaniem w zewnętrzne linki phishingowe, ale chronią należące do Ciebie serwisy przed ruchem botów, credential stuffingiem, złośliwym payloadem i nadużyciami.
Dlaczego samo MFA nie wystarcza wobec phishingu opartego na proxy
Widziałem tę dyskusję dziesiątki razy na forach IT: „Mamy MFA, więc jesteśmy bezpieczni”. Administratorzy, którzy faktycznie mierzyli się z incydentem AiTM, patrzą na to zupełnie inaczej.
Mechanizm jest prosty. Ofiara przechodzi MFA w procesie, który wygląda jak prawdziwe logowanie. Prawdziwy dostawca tożsamości wydaje token sesyjny. Atakujący przechwytuje go przez swoje reverse proxy.
Uwierzytelnienie zakończyło się sukcesem — ale atakujący właśnie przejął sesję. Sam reset hasła może nie wystarczyć, jeśli aktywne sesje i zmiany MFA wprowadzone przez atakującego nadal obowiązują. Microsoft wyraźnie podaje , że organizacje muszą unieważnić cookies sesyjne i cofnąć modyfikacje MFA wykonane przez atakującego, ponad standardowe działania naprawcze.
Kody SMS, aplikacje OTP, zatwierdzenia push — wszystko to można wyłudzić, jeśli użytkownik wpisuje je w przepływie kontrolowanym przez atakującego. MFA wykonało swoją pracę. Problem polega na tym, że napastnik obserwował cały proces.
Co naprawdę zatrzymuje phishing AiTM
FIDO2 / passkeys. FIDO Alliance wyjaśnia, że passkeys są z definicji odporne na phishing: nie ma haseł do kradzieży, nie ma danych logowania do ponownego użycia. Para kluczy kryptograficznych jest przypisana do źródła legalnej domeny, więc proxy atakującego nie jest w stanie odtworzyć wyzwania. CISA potwierdza, że FIDO i PKI to jedyne powszechnie dostępne, niezastrzeżone metody MFA, które skutecznie blokują phishing danych uwierzytelniających.
Uwierzytelnianie oparte na certyfikatach. Rozwiązanie klasy enterprise, bardziej złożone we wdrożeniu, ale równie odporne na phishing, bo opiera się na certyfikatach urządzeń, a nie kodach wpisywanych przez użytkownika.
Polityki Conditional Access. W środowiskach Microsoft Conditional Access może wymagać zgodnych urządzeń, zaufanych lokalizacji, kontroli ryzyka lub uwierzytelniania odpornego na phishing — zmniejszając wartość skradzionego tokenu sesyjnego, nawet jeśli atakujący go zdobędzie.
Wszystko to uzupełnia proxy, a nie je zastępuje. Celem jest wielowarstwowość.
Praktyczne opcje dla małych i średnich firm z ograniczonym budżetem
Oczywisty zarzut brzmi: „Intune, MDM, klucze sprzętowe — to budżet dla enterprise”. Słusznie. Oto budżetowa ścieżka:
- Passkeys w przeglądarce. Większość nowoczesnych przeglądarek obsługuje passkeys natywnie. Bez zakupu sprzętu. Zacznij od kont administratorów, finansów i HR.
- Bezpłatne wdrożenie DMARC. Rekordy SPF, DKIM i DMARC można opublikować bez opłat. Google Workspace i Microsoft 365 mają gotowe instrukcje konfiguracji.
- Defensywna rejestracja domen. Zarejestruj typowe literówki i podobne domeny dla swojej marki. Większość rejestratorów pobiera 10–15 USD rocznie za domenę. Ustaw na każdej politykę DMARC typu reject.
- Ukierunkowane szkolenia. Skup świadomość pracowników na konkretnych pułapkach AiTM: fałszywe strony logowania Microsoft 365, fałszywe udostępnianie dokumentów, kody QR, oszustwa z device code i procesy „pilna wypłata / pilny kontrahent”.
Myśl o tym jak o podejściu: „zacznij tutaj, rozbuduj później”. Nawet częściowe wdrożenie znacząco zmniejsza ryzyko.
Jaki typ proxy najlepiej sprawdza się w ochronie przed phishingiem?
Różne rodzaje proxy służą różnym celom antyphishingowym, a wybór niewłaściwego oznacza marnowanie pieniędzy albo powstawanie martwych punktów.
| Typ proxy | Najlepszy przypadek użycia w ochronie przed phishingiem | Zalety | Wady | Poziom kosztów |
|---|---|---|---|---|
| Datacenter | Masowe skanowanie URL-i, monitorowanie domen | Szybkie, tanie, duża przepustowość | Łatwo wykrywane przez bardziej zaawansowane zestawy phishingowe | Niski |
| Residential | Wykrywanie phishingu ukierunkowanego geograficznie, testy z perspektywy użytkownika | Wygląda jak prawdziwy ruch użytkownika, omija blokady geograficzne | Wolniejsze, droższe, poważne wątpliwości etyczne co do źródła ruchu | Wysoki |
| Rotating | Zbieranie threat intelligence, długotrwałe monitorowanie | Unika blokad IP podczas długich sesji crawlowania | Bardziej złożona konfiguracja, zmienna latencja | Średni |
| Reverse Proxy / WAF | Ochrona własnych serwisów | Filtrowanie ruchu przychodzącego, wykrywanie botów, ochrona przed DDoS | Nie pomaga w wykrywaniu phishingu wychodzącego | Średni |
Uwaga o etycznym źródle ruchu. Przypadek Google/IPIDEA i poradnik FBI jasno pokazują, że sieci proxy residential mogą być budowane z urządzeń przejętych, podstępnych SDK, ukrytych zapisów w warunkach VPN albo złośliwego oprogramowania. Zanim kupisz ruch z proxy residential, wymagaj od dostawcy przejrzystej zgody użytkownika, mechanizmów opt-out, audytowalności i obsługi nadużyć. Dostawców wcześniej wskazywanych w badaniach bezpieczeństwa (PacketStream, dziś już nieistniejące 911 Proxy) należy traktować z najwyższą ostrożnością.
Dla większości małych i średnich firm najlepiej zacząć od proxy datacenter do masowego skanowania oraz reverse proxy/WAF dla własnych domen. Proxy residential dodawaj tylko wtedy, gdy potrzebujesz testów geograficznych i możesz dokładnie zweryfikować dostawcę.
Krok po kroku: jak unikać phishingu z użyciem proxy (praktyczny workflow)
Większość artykułów kończy się na teorii. Każdy krok poniżej zawiera rekomendację narzędzia i wystarczająco dużo szczegółów, by przekazać to zespołowi IT albo wdrożyć samodzielnie.
Krok 1: Monitoruj świeżo zarejestrowane domeny podobne do Twojej marki
Atakujący rejestrują domeny podobne do Twoich, zanim uruchomią kampanię: thunderb1t.com, thunderbit-login.com, thunderbit-support.net.
Wykrycie ich wcześnie to jedno z najcenniejszych działań obronnych.
Jak to zrobić:
- Zbuduj listę obserwowanych haseł: nazwa marki, nazwy produktów, nazwiska kadry zarządzającej i słowa związane z logowaniem (np. „login”, „portal”, „invoice”, „payment”).
- Codziennie przeszukuj logi Certificate Transparency (CT) za pomocą crt.sh, które pozwalają szukać rekordów certyfikatów po domenie lub nazwie organizacji. Logi CT obejmują publicznie zaufane certyfikaty, więc nowo wydane certyfikaty dla podobnych domen pojawią się właśnie tam.
- Oznaczaj domeny o małej odległości edycyjnej od Twojej marki, podejrzanych TLD (.xyz, .top, .click) albo z słowami kluczowymi związanymi z logowaniem/płatnością.
- Renderuj oznaczone strony przez proxy lub w sandboxie — nigdy z przeglądarki pracownika.
Powiązanie z Thunderbit: Thunderbit ma batch extract API, które może przetwarzać do 100 podejrzanych URL-i na jedno zadanie, używając renderMode: "full", aby renderować phishingowe klony intensywnie korzystające z JavaScriptu. Definiujesz schemat JSON dla danych, które chcesz otrzymać — tytuł strony, obecność formularza logowania, domenę działania formularza, wystawcę SSL, łańcuch przekierowań, końcowy URL. Odpowiednik CLI dobrze wpisuje się w monitoring oparty na cron:
thunderbit batch extract --file suspicious-urls.txt --schema phishing-signals.json --render-mode full
Dla użytkowników nietechnicznych rozszerzenie Thunderbit Chrome extension można też wykorzystać do szybkiego pobrania i przejrzenia podejrzanych stron w kilku kliknięciach — przydatne, gdy trzeba po prostu obejrzeć kilka URL-i, a nie uruchamiać pełny pipeline.
Oczekiwany rezultat: codzienny lub tygodniowy raport nowych domen podobnych do marki, z uporządkowanymi metadanymi gotowymi do triage.
Wypróbuj Thunderbit do przeglądu podejrzanych URL-i
Krok 2: Przekierowuj podejrzane linki przez proxy datacenter
Zanim ktokolwiek w Twojej organizacji kliknie podejrzany link, przeanalizuj go przez kontrolowaną ścieżkę. Widoczny jest adres IP proxy, a nie urządzenie pracownika ani sieć firmowa.
Jak to zrobić:
- Do szybkich kontroli użyj urlscan.io (sandbox webowy, w którym można wybrać kraj skanowania) albo VirusTotal (skanuje URL-e wieloma silnikami AV i listami blokad).
- Do skryptów wewnętrznych lub analizy większej skali kieruj żądania przez proxy datacenter:
curl -x http://proxy.example.com:8080 -I "https://suspicious.example"
- W przypadku aktywnych stron phishingowych użyj jednorazowej maszyny wirtualnej lub sandboxa przeglądarki. Wyłącz możliwość wpisywania danych uwierzytelniających. Zbieraj łańcuch przekierowań, tytuł strony, końcowy adres, wysłane formularze, skrypty i zrzuty ekranu.
- Nigdy nie podawaj prawdziwych firmowych danych logowania. I ostrożnie traktuj publiczne skany — niektóre usługi ujawniają zgłoszone URL-e, jeśli nie są ustawione jako prywatne lub niewidoczne publicznie.
Oczekiwany rezultat: bezpieczna ocena celu linku, jego zachowania i wskaźników zagrożenia — bez ujawniania infrastruktury firmy.
Krok 3: Użyj proxy z różnych regionów, aby wykryć kampanie phishingowe ukierunkowane geograficznie
Niektóre zestawy phishingowe pokazują złośliwą treść tylko odwiedzającym z konkretnego kraju albo z określonym ustawieniem języka. Cofense dokumentuje, że filtrowanie geolokalizacji jest powszechnie stosowane: użytkownicy z „niewłaściwego” regionu widzą nieszkodliwą stronę lub błąd 404, a właściwa grupa docelowa dostaje formularz do wyłudzania danych.
Jak to zrobić:
- Testuj podejrzane linki z tych regionów, w których faktycznie działają Twoi pracownicy, klienci i zespoły finansowe. Jeśli firma ma siedzibę w USA i biuro w Wielkiej Brytanii, sprawdzaj z obu.
- Porównuj końcowe URL-e, zrzuty ekranu, tytuły stron, formularze i kody odpowiedzi HTTP według regionu.
- Rotuj ustawienia user-agent i języka podczas analizy pułapek opartych na kodach QR lub urządzeniach mobilnych — niektóre zestawy filtrują także po tych parametrach.
- Eskaluj URL-e, które w jednej lokalizacji pokazują nieszkodliwą treść, a w innej formularz logowania. To mocny sygnał phishingu.
Oczekiwany rezultat: wykrycie kampanii geotargetowanych, których nie da się zobaczyć przy skanowaniu z jednej lokalizacji.
Krok 4: Wdróż reverse proxy lub WAF dla własnych domen
Czas przejść od wykrywania ruchu wychodzącego do obrony ruchu przychodzącego. Reverse proxy i WAF stoją przed Twoimi serwisami, analizując ruch zanim dotrze do serwerów.
Jak to zrobić:
- Skieruj DNS domeny do dostawcy reverse proxy. Cloudflare to najłatwiejsza opcja dla SMB — DNS, CDN, WAF i reguły są w jednym interfejsie. Dla aplikacji hostowanych na AWS AWS WAF sprawdza się dobrze, jeśli już korzystasz z CloudFront, ALB lub API Gateway.
- Włącz zarządzane reguły WAF. Blokują znane złośliwe IP, filtrują ruch botów i wykrywają wzorce credential stuffing.
- Ustaw limity dla logowania, resetu hasła i formularzy kontaktowych.
- Dodaj reguły bot/challenge dla newralgicznych endpointów.
- Monitoruj zdarzenia WAF co tydzień — nie ustawiaj i nie zapominaj.
Oczekiwany rezultat: złośliwy ruch przychodzący jest filtrowany, zanim dotrze do serwerów. Próby credential stuffing na stronach logowania są blokowane albo sprawdzane.
Krok 5: Zautomatyzuj i zaplanuj stały monitoring
Phishing to nie jednorazowy audyt. Nowe domeny, zestawy i infrastruktura pojawiają się codziennie — dlatego monitoring musi mieć rytm:
- Codziennie: skan lookalike w CT i kolejka podejrzanych domen.
- Codziennie lub co godzinę (dla marek wysokiego ryzyka): sprawdzanie nowych domen w sandboxie URL.
- Co tydzień: przegląd zbiorczych raportów DMARC i wzorców spoofingu.
- Co tydzień: przegląd zdarzeń WAF pod kątem credential stuffing i skoków aktywności botów.
- Co miesiąc: ocena postępów wdrażania MFA odpornego na phishing.
- Co kwartał: test procesów finansowych i HR w realistycznych scenariuszach AiTM i BEC.
Powiązanie z Thunderbit: planowane pobieranie danych i workflow CLI/API w Thunderbit mogą wspierać cykliczny monitoring dla zespołów operacyjnych bez zaplecza technicznego. Najlepszy use case nie brzmi „Thunderbit sam zapobiega phishingowi”, tylko „Thunderbit pomaga zespołom operacyjnym zbierać uporządkowane sygnały z podejrzanych stron i źródeł monitorowania domen bez pisania własnego scrapera od zera”. Wyniki można kierować do Google Sheets lub Airtable, by były widoczne dla zespołu, albo do Slacka przez prostą integrację.
Oczekiwany rezultat: ciągła pętla monitoringu, która wykrywa nowe zagrożenia w ciągu godzin, a nie tygodni.
Czego proxy nie wychwytują: zabezpieczenie poczty dzięki DMARC, SPF i DKIM
Dostawcy proxy nie powiedzą Ci tego otwarcie: proxy to tylko jedna warstwa obrony, a phishing e-mailowy, który nigdy nie przechodzi przez tę warstwę, wymaga osobnej ochrony.
Wiele ataków phishingowych przychodzi przez podrobione adresy e-mail. Proxy tego nie zatrzyma.
Konfiguracja SPF z twardym odrzuceniem
SPF (Sender Policy Framework) to rekord DNS wskazujący, które adresy IP mają prawo wysyłać pocztę w imieniu Twojej domeny. Ustaw -all (hard fail), a nie ~all (soft fail), aby od razu odrzucać nieautoryzowanych nadawców.
Częsty błąd: pominięcie wszystkich legalnych usług wysyłających mail — CRM, platformy marketingowej, dostawcy wiadomości transakcyjnych, helpdesku. Zanim opublikujesz rekord, zinwentaryzuj wszystkie źródła wysyłki.
Wdrożenie podpisu DKIM
DKIM (DomainKeys Identified Mail) dodaje kryptograficzny podpis do wychodzących wiadomości. Odbiorca sprawdza, czy treść nie została zmodyfikowana w tranzycie. Zarówno Google Workspace, jak i Microsoft 365 mają gotowe instrukcje konfiguracji DKIM. To zajmuje około 15 minut.
Wymuszenie polityki DMARC na reject
DMARC (Domain-based Message Authentication, Reporting & Conformance) mówi serwerom odbierającym, co zrobić, gdy SPF lub DKIM nie przejdzie. Najważniejszy krok, którego większość organizacji nie robi: przejście z p=none (tylko monitorowanie) do p=reject (blokowanie wiadomości niespełniających wymagań) po zweryfikowaniu legalnych przepływów poczty.
Wiele organizacji zostawia DMARC na p=none bezterminowo — widoczność bez ochrony. To jak zamontowanie kamery bezpieczeństwa, ale nigdy niezamknięcie drzwi.
Defensywna rejestracja domen podobnych do marki
Zarejestruj z wyprzedzeniem typowe literówki i podobne domeny swojej marki. Ustaw na nich polityki DMARC reject, żeby nie dało się ich użyć do spoofingu. Przy koszcie 10–15 USD rocznie za domenę to jedno z najtańszych i najbardziej skutecznych działań — a wiele małych firm całkowicie je pomija.
Jak to wszystko połączyć: wielowarstwowa obrona przed phishingiem
Żadne pojedyncze narzędzie nie zatrzyma phishingu. Skuteczna obrona wynika z kombinacji warstw. Praktyczna lista kontrolna:
Ruch wychodzący (analiza zagrożeń):
- skanowanie URL-i przez proxy dla podejrzanych linków
- monitorowanie domen przez logi CT i batch extraction
- testy geograficzne dla kampanii ukierunkowanych regionalnie
Ruch przychodzący (ochrona własnych zasobów):
- reverse proxy / WAF dla domen webowych
- DMARC/SPF/DKIM do uwierzytelniania poczty
- defensywna rejestracja domen podobnych do marki
Uwierzytelnianie (ochrona kont):
- FIDO2 / passkeys jako MFA odporne na phishing
- polityki Conditional Access (zgodne urządzenia, kontrole ryzyka)
- monitorowanie i procedury unieważniania tokenów sesyjnych
Ludzie (ostatnia siatka bezpieczeństwa):
- szkolenia skupione konkretnie na pułapkach AiTM, kodach QR i scenariuszach BEC
- jasna kultura zgłaszania — ma być łatwo i bez kar za raportowanie podejrzanych wiadomości
- regularne testowanie procesów finansowych i HR na realistycznych scenariuszach phishingowych
To podejście odpowiada zasadzie defense-in-depth z NIST Cybersecurity Framework: wiele niezależnych warstw, tak aby awaria jednej nie oznaczała pełnego przejęcia.
Dla zespołów, które muszą analizować podejrzane URL-e, zbierać dane o zagrożeniach lub monitorować domeny na dużą skalę, AI web scraper Thunderbit może przyspieszyć pracę — rozszerzenie Chrome dla osób nietechnicznych, API/CLI dla zespołów technicznych. To nie jest samo w sobie produkt bezpieczeństwa, ale zasługuje na miejsce w arsenale analityka. Więcej o web scrapingu bez kodowania albo o podejściach do AI web scrapingu znajdziesz na naszym blogu.
Wykorzystaj AI web scraping do monitorowania zagrożeń Get Started Free
FAQ
Jak atakujący wykorzystują proxy w atakach phishingowych?
Atakujący używają proxy residential i rotating, aby ukryć swój prawdziwy IP, rotować między zaufanymi adresami, omijać wykrywanie oparte na IP i wdrażać reverse proxy AiTM do przechwytywania uwierzytelnionych sesji — nawet po tym, jak ofiara przejdzie MFA. Zakłócenie IPIDEA w styczniu 2026 pokazało, że z jednej sieci proxy residential korzystało ponad 550 grup zagrożeń.
Jak reverse proxy pomaga zapobiegać phishingowi i przejęciu witryny?
Reverse proxy stoi przed Twoimi serwerami webowymi i analizuje ruch przychodzący, zanim dotrze do infrastruktury. Blokuje znane złośliwe IP, filtruje ruch botów, ogranicza liczbę prób logowania i wykrywa credential stuffing lub aktywność związaną z phishingiem. Nie chroni jednak pracowników przed klikaniem w zewnętrzne linki phishingowe.
Czy proxy mogą całkowicie wyeliminować phishing?
Nie. Proxy to tylko jedna z kluczowych warstw. Phishing e-mailowy wymaga DMARC/SPF/DKIM, a przejęcie sesji przez AiTM wymaga MFA odpornego na phishing, takiego jak FIDO2/passkeys. Niezbędna jest wielowarstwowa obrona łącząca proxy, uwierzytelnianie poczty, odporne na phishing dane logowania i szkolenia pracowników.
Czym jest phishing AiTM i dlaczego MFA go nie zatrzymuje?
Phishing AiTM (Adversary-in-the-Middle) wykorzystuje reverse proxy między ofiarą a prawdziwą stroną logowania, przechwytując token sesji po zakończeniu MFA. Tradycyjne MFA go nie zatrzymuje, ponieważ atakujący kradnie już uwierzytelnioną sesję, a nie hasło. FIDO2/passkeys są odporne na ten atak, ponieważ wyzwanie kryptograficzne jest powiązane z legalną domeną i nie da się go odtworzyć przez proxy atakującego.
Jaki typ proxy najlepiej nadaje się do wykrywania phishingu?
Proxy datacenter najlepiej sprawdzają się do masowego skanowania URL-i (szybkie i tanie). Proxy residential są najlepsze do testów geotargetowanych (bardziej realistyczne, ale droższe — trzeba zweryfikować etyczne źródło ruchu). Reverse proxy/WAF są najlepsze do ochrony własnych serwisów. Najmocniejsze podejście to kombinacja dopasowana do tego, co chcesz wykryć albo chronić.
Wypróbuj Thunderbit do monitorowania zagrożeń i AI scrapingu Get Started Free
Dowiedz się więcej
