Nowoczesne zagrożenia w phishingu: ClickFix, BitB i OAuth

Utworzone przez Dawid Bakaj • niedziela, 30.08.2026, 17:49 • Cyberzagrożenia i ataki – analiza przypadków

99% udanych cyberataków wymaga interakcji z użytkownikiem, a tradycyjne filtry zabezpieczające pocztę e-mail nie radzą sobie z nowoczesnymi technikami omijania zabezpieczeń. Atakujący coraz rzadziej polegają na fałszywych stronach logowania czy typowych załącznikach z malware. Współczesne, zaawansowane kampanie phishingowe opierają się na celowych działaniach użytkowników oraz zaufanych mechanizmach chmurowych. Przestępcy wykorzystują przepływy autoryzacyjne OAuth, aby zdobyć długoterminowy dostęp do systemów.

Techniki takie jak ClickFix, browser-in-the-browser (BitB) oraz OAuth consent phishing stanowią obecnie największe zagrożenie dla tożsamości cyfrowej. Metody te są często łączone z atakami wykorzystującymi zmęczenie mechanizmem MFA (MFA fatigue) oraz nadużywaniem usług SaaS. Pozwala to na łatwe ominięcie nowoczesnych mechanizmów kontrolnych. Ataki te, podobnie jak ataki phishingowe na KSeF, pokazują jasno, jak łatwo przejąć kontrolę nad infrastrukturą za pomocą sprytnej socjotechniki. Poniżej znajduje się szczegółowa analiza tych taktyk, ich mechaniki działania oraz sposobów obrony na poziomie dojrzałych środowisk IT.

ClickFix i techniki Copy-Paste Phishing

ClickFix, często nazywany atakiem typu copy-paste lub phishingiem opartym na terminalu, to wysoce skuteczna technika socjotechniczna. Złośliwy kod nigdy nie trafia do użytkownika w postaci pliku czy załącznika. Strona internetowa lub wiadomość e-mail przekonuje ofiarę do ręcznego skopiowania i wklejenia poleceń dostarczonych przez atakującego. Użytkownik wprowadza je w oknie Uruchom (Win+R), w konsoli PowerShell, wierszu poleceń, a w przypadku systemów Apple – w macOS Terminal. Ofiara samodzielnie wykonuje malware. Daje to napastnikowi początkowy dostęp do maszyny lub pełną zdalną kontrolę nad systemem. Główną innowacją jest przeniesienie egzekucji kodu do natywnych narzędzi systemu operacyjnego (OS).

Większość kampanii ClickFix dzieli się na określone etapy. Początkowa przynęta przybiera formę wiadomości e-mail z prośbą o weryfikację. Użytkownik widzi komunikaty typu „Musisz potwierdzić, że jesteś człowiekiem”, „Napraw błąd wyświetlania” lub „Zaktualizuj ustawienia bezpieczeństwa”. Czasami użytkownik jest przekierowywany ze skompromitowanej strony, trafia na złośliwe reklamy (malvertising) lub oszustwa z użyciem kodów QR. Następnie ofiara trafia na stronę z fałszywą weryfikacją CAPTCHA lub fałszywym ekranem błędu (Blue Screen of Death – BSoD). Strona wyświetla dokładne instrukcje krok po kroku. Użytkownik czyta: „Naciśnij Windows + R”, „Wpisz powershell”, „Naciśnij Ctrl+V, aby wkleić kod”, a na koniec „Naciśnij Enter”.

Skopiowany skrypt to najczęściej zaciemniony kod PowerShell lub skrypt powłoki. Pobiera on i uruchamia zawartość ze zdalnego adresu URL. Skrypt wyłącza funkcje oprogramowania antywirusowego, dodaje nowego użytkownika lub tworzy trwałe zadanie w harmonogramie. Często instaluje narzędzia typu RAT (Remote Access Tool) lub payload, taki jak Cobalt Strike czy dedykowany backdoor. Wiele wariantów używa kodowania Base64 dla PowerShell, aby ukryć rzeczywiste zachowanie przed prostą inspekcją.

Po uruchomieniu skryptu następuje faza post-eksploitacji. Narzędzia nawiązują połączenie z serwerem C2 (command-and-control). Zbierają poświadczenia, takie jak dane z przeglądarki, procesów LSASS i tokeny sesyjne. Atakujący mogą wdrożyć ransomware lub oprogramowanie do eksfiltracji danych. Następnie poruszają się w sieci (lateral movement), używając standardowych narzędzi administracyjnych, takich jak RDP, WMI czy PsExec. Malware uruchamia się wyłącznie dlatego, że użytkownik wykonuje polecenia. Brakuje tu klasycznego exploita.

Technika ClickFix nadużywa zaufania do procesów wsparcia technicznego. Fałszywe ekrany błędów i ostrzeżenia świetnie naśladują oryginalny interfejs systemu. Złośliwa logika omija skanowanie e-maili i adresów URL. Rozwiązania bezpieczeństwa analizują głównie załączniki, ignorując instrukcje tekstowe. Atakujący używają legalnych komponentów systemowych, takich jak cmd, bash, curl czy Invoke-WebRequest. Narzędzia EDR muszą oddzielać legalne skrypty administratorów od poleceń pochodzących z phishingu. Istnieją również warianty cross-platform, takie jak „FileFix” lub „TerminalFix”, uderzające w systemy Mac i Linux za pomocą aplikacji Finder i Terminal.

Obrona przed ClickFix

Podstawą obrony jest ustanowienie twardej zasady w organizacji. Żaden wewnętrzny proces wsparcia nigdy nie poprosi użytkownika o wklejanie poleceń do okna Uruchom, PowerShell czy Terminala. Każda taka prośba musi być domyślnie traktowana jako złośliwa. Należy szkolić użytkowników, aby rozpoznawali fałszywe ekrany CAPTCHA i niespodziewane komunikaty systemowe w przeglądarce.

Na poziomie technicznym konieczne jest wdrożenie wielowarstwowej strategii obronnej:

• Ograniczenie PowerShell: Należy stosować tryb Constrained Language Mode, wymuszać podpisywanie skryptów oraz konfigurować restrykcyjną politykę wykonywania (execution policy).
• Zaawansowane logowanie: Kluczowe jest włączenie logowania bloków skryptów (Script Block Logging) oraz modułów (Module Logging) w PowerShell. Pozwala to na monitorowanie pobierania i wykonywania plików, skryptów zakodowanych w Base64 oraz podejrzanych połączeń sieciowych.
• Kontrola aplikacji: Wdrożenie narzędzi takich jak AppLocker lub Windows Defender Application Control (WDAC) jest niezbędne do blokowania niezaufanych skryptów. Należy zablokować dostęp do interpreterów (PowerShell, wscript, cscript, Python) dla użytkowników, którzy nie są administratorami IT.
• Blokady systemowe: Dostęp do okna Uruchom (Win+R) powinien być zablokowany za pomocą Group Policy (GPO) lub systemów MDM dla większości użytkowników.
• Detekcja EDR: Reguły detekcji w systemach EDR muszą być skonfigurowane tak, aby wykrywać łańcuchy uruchamiania procesów, np. przeglądarka wywołująca PowerShell w krótkim oknie czasowym. Alarmy powinny dotyczyć poleceń pobierających ładunki z sieci i modyfikujących harmonogram zadań. Tego typu luki konfiguracyjne to klasyczne ukryte błędy w cyberbezpieczeństwie, które wymagają natychmiastowej poprawy.
• Filtrowanie sieciowe: Należy włączyć filtrowanie DNS i filtrowanie ruchu sieciowego (web filtering), aby blokować połączenia ze znaną infrastrukturą C2 wykorzystywaną w kampaniach ClickFix.
• Korelacja w SIEM: Systemy SIEM powinny korelować nietypową aktywność przeglądarki (np. wizyta na nowej domenie) z późniejszym wykonaniem poleceń w konsoli na tej samej stacji roboczej.

Browser-in-the-Browser (BitB) Phishing

Browser-in-the-browser (BitB) to zaawansowana technika oszustwa wizualnego. Napastnik buduje fałszywe okno logowania wewnątrz obszaru treści samej przeglądarki. Interfejs precyzyjnie naśladuje wyskakujące okna logowania Microsoft 365, okna Google, Okta oraz inne panele Single Sign-On (SSO). Ofiara jest przekonana, że korzysta z natywnego okna przeglądarki, podczas gdy w rzeczywistości wprowadza dane do elementu stworzonego za pomocą HTML, CSS i JavaScript. Metoda ta skutecznie przełamuje procedury weryfikacyjne „Zaloguj się przez X”, gdzie użytkownicy są przyzwyczajeni do wyskakujących ekranów autoryzacji.

Atak przebiega według określonego schematu. Ofiara klika przycisk logowania SSO na stronie naśladującej legalną usługę, taką jak SharePoint, Teams czy Dropbox. JavaScript generuje fałszywe okno, które zawiera pasek tytułu, obramowania i systemowe cienie. Co najważniejsze, wyświetla sfałszowany pasek adresu, na przykład `https://login.microsoftonline.com/…`. Jest to zwykła grafika lub odpowiednio sformatowany tekst. Pozycjonowanie okna imituje interfejs systemu operacyjnego z ogromną precyzją.

Użytkownik wprowadza dane uwierzytelniające. JavaScript przechwytuje je natychmiast i przesyła na serwer atakującego. Napastnik może w czasie rzeczywistym wykorzystać te poświadczenia i skradzione pliki cookie. Jeśli ofiara używa MFA, atakujący wyświetla w fałszywym oknie prośbę o kod OTP lub zatwierdzenie powiadomienia push. Równocześnie napastnik loguje się do prawdziwego dostawcy tożsamości (IdP), przekazując przechwycone dane. Działa to na zasadzie serwera proxy w czasie rzeczywistym (real-time phishing proxy). W wielu przypadkach BitB służy wyłącznie kradzieży ciasteczek sesyjnych, co pozwala na całkowite ominięcie MFA.

Niebezpieczeństwo BitB wynika z faktu, że pasek adresu URL jest całkowicie sfałszowany. Użytkownicy weryfikujący adresy URL stają się bezradni, jeśli nie zorientują się, że okno znajduje się wewnątrz innej strony. Nowoczesne przepływy SSO często używają wyskakujących okien, co usypia czujność. Dodatkowo strona w tle może znajdować się na skompromitowanej, legalnej domenie biznesowej lub domenie typu look-alike.

Detekcja BitB przez użytkownika wymaga znajomości detali interfejsu. Oto jak odróżnić prawdziwe okno od fałszywego:

• Kontrolki systemowe: Prawdziwe okno pop-up posiada natywne kontrolki systemu operacyjnego (minimalizuj, maksymalizuj, zamknij) i pojawia się w menu Alt+Tab jako osobna aplikacja.
• Interaktywność paska adresu: W prawdziwym oknie pasek adresu pozwala na zaznaczanie tekstu, edycję i klikanie prawym przyciskiem myszy. Fałszywy pasek w oknie BitB nie jest interaktywny.
• Przeciąganie okna: Próba przeciągnięcia okna BitB poza granice przeglądarki, np. na drugi monitor, demaskuje oszustwo, ponieważ jest ono „uwięzione” na stronie HTML.
• Menu kontekstowe: Kliknięcie prawym przyciskiem myszy w oknie BitB wywołuje menu typowe dla strony internetowej, a nie menu przeglądarki.

Aby w pełni zrozumieć zagrożenia dla infrastruktury opartej na systemach Windows i podatności na przechwytywanie sesji, warto przeanalizować ataki NTLM Coercion, które wykazują podobną bezwzględność w pozyskiwaniu dostępu.

OAuth Consent Phishing

OAuth consent phishing, nazywany również phishingiem zgody lub atakiem z użyciem złośliwych aplikacji OAuth, to technika nadużywająca frameworka autoryzacji OAuth 2.0. Atakuje ekosystemy chmurowe takie jak Microsoft 365, Google Workspace, Okta czy Salesforce. Napastnik nie kradnie tu hasła użytkownika. Celem jest nakłonienie ofiary do przyznania złośliwej aplikacji dostępu do konta poprzez tzw. zakresy (OAuth scopes). Obejmują one czytanie i wysyłanie wiadomości e-mail, dostęp do plików lub zarządzanie kalendarzami i wiadomościami na Teams/Slack.

Po wyrażeniu zgody atakujący otrzymuje tokeny dostępu (access tokens) oraz tokeny odświeżania (refresh tokens), które umożliwiają dostęp na poziomie API. Tokeny te oferują długotrwały dostęp, który utrzymuje się nawet po zmianie hasła przez użytkownika lub wylogowaniu z sesji. Metoda ta skutecznie omija MFA, ponieważ tokeny OAuth są wydawane dopiero po prawidłowym zalogowaniu i poprawnym przejściu weryfikacji wieloskładnikowej.

Schemat ataku wygląda następująco:

1. Rejestracja aplikacji: Atakujący rejestruje złośliwą aplikację na platformie takiej jak Azure AD / Entra ID lub Google Cloud Console. Wybiera profesjonalnie brzmiącą nazwę, np. „Microsoft Document Sync”, „DocuSign Secure Portal” lub „Salesforce Data Loader”, dodając logotypy znanych marek. Następnie definiuje szerokie zakresy uprawnień: `Mail.Read`, `Mail.Send`, `Files.Read.All` czy `offline_access`.
2. Dystrybucja linku: Użytkownik otrzymuje e-mail z linkiem typu „Wyświetl bezpieczny dokument” lub „Zaktualizuj ustawienia bezpieczeństwa”. Link kieruje go na oryginalny punkt końcowy logowania i zgody u prawdziwego dostawcy usługi. Adres URL to na przykład `https://login.microsoftonline.com/…/oauth2/v2.0/authorize?…`.
3. Uwierzytelnienie: Strona logowania jest całkowicie autentyczna. Ofiara wprowadza dane i przechodzi weryfikację MFA. Z perspektywy dostawcy tożsamości (IdP) jest to w pełni legalny proces.
4. Ekran zgody: Po zalogowaniu dostawca wyświetla ekran zgody OAuth. Aplikacja prosi o uprawnienia: „Odczyt twojej poczty”, „Wysyłanie poczty jako ty”, „Odczyt twoich plików”, „Utrzymanie dostępu do danych”. Wydawca aplikacji ma zazwyczaj status „niezweryfikowany” (unverified) lub jest to nieznana firma.
5. Pozyskanie tokenów: Użytkownicy, przyzwyczajeni do podobnych ekranów, klikają „Akceptuj”. W tym momencie dostawca wysyła kod autoryzacyjny do aplikacji atakującego, która wymienia go na token dostępu i token odświeżania. Pozwala to atakującemu wywoływać API w imieniu użytkownika.

OAuth consent phishing omija klasyczną ochronę z kilku powodów. Ofiara prawidłowo przechodzi MFA. Nie ma żadnych anomalii logowania, ponieważ adres IP i urządzenie należą do legalnego pracownika. Nie dochodzi do kradzieży haseł czy dystrybucji złośliwych załączników. Wszystko odbywa się przez oficjalne punkty końcowe OAuth. Zespoły ds. cyberbezpieczeństwa skupiają się głównie na logach logowania (sign-in logs), zapominając o monitorowaniu zgód dla aplikacji (app consent logs) i przyznawaniu grantów OAuth. W kontekście zapewnienia bezpieczeństwa takich konfiguracji rekomendujemy profesjonalny audyt bezpieczeństwa.

Czerwone flagi tego ataku to między innymi: dziwna nazwa aplikacji (mimo logo znanego dostawcy), bardzo szerokie uprawnienia oraz wydawca oznaczony jako „niezweryfikowany”. Zgoda pojawia się podczas wykonywania prozaicznych czynności, które normalnie nie wymagają nowych autoryzacji. Obrona wymaga wprowadzenia rygorystycznych polityk. W systemach Entra ID i Google Workspace należy wyłączyć możliwość samodzielnego wyrażania zgody na aplikacje od niezweryfikowanych wydawców przez zwykłych użytkowników. Każda zgoda na dostęp do krytycznych danych musi być zatwierdzona przez administratora. Należy stale inwentaryzować aplikacje OAuth, monitorować nowe rejestracje i reagować na anomalie w wywołaniach API.

Taktyka działania w nowoczesnym ekosystemie phishingowym

Wszystkie trzy wymienione techniki udowadniają brutalną prawdę: wdrożenie samego MFA przestało stanowić wystarczającą zaporę. ClickFix uderza bezpośrednio w punkty końcowe, wykorzystując zaufanie do komunikatów systemu operacyjnego. BitB wykrada sesje, naśladując ramy przeglądarki. OAuth consent phishing nadużywa autentycznych, wspieranych przez MFA procesów logowania w celu pozyskania tokenów API. Napastnicy eksploatują przyzwyczajenia użytkowników (User Experience – UX).

Grupy APT i przestępcy finansowi często łączą te metody. Atak BitB symuluje okno logowania, by zdobyć poświadczenia do głównego dostawcy tożsamości. Następnie napastnik wykorzystuje te dane, by z poziomu sieci wewnętrznej rozesłać zaufanym pracownikom złośliwy link OAuth. Z kolei ClickFix często stanowi metodę instalacji oprogramowania kradnącego informacje (infostealers). Przejęte pliki cookie pozwalają ominąć MFA i zarejestrować złośliwe aplikacje OAuth wewnątrz tenanta firmy, zapewniając ukrytą formę długotrwałej obecności (persistence).

Te ataki idealnie napędzają kampanie typu Business Email Compromise (BEC). Przejęte za pomocą OAuth tokeny pozwalają na manipulację fakturami i przechwytywanie płatności na dużą skalę. Szerokie uprawnienia w systemach plików gwarantują skuteczną eksfiltrację danych biznesowych. W ostatecznym rozrachunku ataki te mogą prowadzić bezpośrednio do wdrożenia destrukcyjnego oprogramowania ransomware. Zaczynając od prostego polecenia ClickFix, intruzi zdobywają dominację nad domeną, poruszają się wewnątrz sieci i dokonują szyfrowania kluczowych zasobów. Aby ocenić podatność infrastruktury na tak złożone scenariusze, zalecamy przeprowadzenie kompleksowych testów penetracyjnych infrastruktury sieciowej oraz ludzkiej.

Strategiczne zalecenia dotyczące obrony infrastruktury IT

Zabezpieczenie przed atakami ClickFix, BitB oraz OAuth consent phishing wymaga ścisłej integracji ludzi, procesów oraz platform technologicznych. Oto kluczowe filary skutecznej obrony:

• Edukacja personelu: Szkolenia muszą wykraczać poza proste „nie klikaj w linki”. Symulacje phishingowe i ćwiczenia typu tabletop powinny obejmować scenariusze z wklejaniem komend, rozpoznawanie fałszywych paneli BitB oraz krytyczną analizę ekranów zgód OAuth. Pracownicy muszą wiedzieć, kiedy eskalować nietypowe prośby o dostęp do aplikacji i danych.
• Rygorystyczne procesy: Należy wdrożyć żelazną politykę, w ramach której dział wsparcia nigdy nie prosi o wklejanie komend skryptowych. Onboarding nowych dostawców oprogramowania musi obejmować audyt bezpieczeństwa i wymagać uprawnień zgodnych z zasadą najmniejszych przywilejów (least-privilege scopes). Każda zgoda na dostęp do danych wrażliwych musi przechodzić przez proces autoryzacji administratora.
• Architektura Zero-Trust: Platforma sprzętowa i chmurowa musi bazować na architekturze „zero zaufania” oraz bezpieczeństwie skoncentrowanym na tożsamości. Obejmuje to polityki dostępu warunkowego oparte na kontekście, ocenę stanu zabezpieczeń urządzenia (device posture) i wdrożenie rozwiązań EDR, AppLocker oraz kontroli PowerShell. Środowiska SaaS wymagają wykorzystania narzędzi klasy SSPM (SaaS Security Posture Management), które nieustannie skanują system pod kątem ryzykownych aplikacji i nadmiernych uprawnień OAuth. Jeżeli chcesz symulować tego rodzaju zaawansowane włamania, nasze usługi typu red team dostarczą Ci realnej wiedzy o zachowaniu Twoich systemów alarmowych.

Wsparcie w zabezpieczaniu infrastruktury

Techniki phishingowe stają się niezwykle precyzyjne. Atakujący całkowicie zmienili wektory ataku, uderzając bezpośrednio w uprawnienia tożsamości, logikę procesów chmurowych oraz naiwność użytkowników polegających na natywnych funkcjach systemu. Obrona przed złośliwymi aplikacjami OAuth, fałszywymi interfejsami i poleceniami uruchamianymi w konsoli wymaga wdrożenia zaawansowanych procedur kontrolnych na każdym poziomie infrastruktury.

Brak monitorowania zewnętrznych aplikacji czy pozostawienie odblokowanego dostępu do powłok systemowych grozi krytycznym naruszeniem danych. Nie czekaj, aż Twój zespół stanie się ofiarą nowej fali ataków cybernetycznych. Możemy pomóc w audycie platform chmurowych, utwardzeniu systemów endpointowych oraz weryfikacji procedur dostępowych dla aplikacji trzecich. Wejdź na stronę Kontakt i skonsultuj z naszymi specjalistami strategię zabezpieczenia Twojego przedsiębiorstwa.

Checklista: Zabezpieczenie przed nowoczesnymi technikami phishingu

FAQ