Co się dzieje po kliknięciu w złośliwy załącznik: techniczna autopsja udanego phishingu

Dlaczego jedno kliknięcie w załącznik potrafi rozłożyć firmę

Scenariusz: jeden mail, jedno kliknięcie, jeden wielki problem

Pracownik działu księgowości dostaje e-mail od rzekomego dużego kontrahenta: „Pilna korekta faktury – przed dzisiejszym przelewem, prosimy o weryfikację”. Nadawca wygląda wiarygodnie, stopka profesjonalna, w treści rozmowa z poprzednich tygodni (bo atakujący przejął kiedyś cudzą skrzynkę). W załączeniu plik „Faktura_04_2026.pdf.iso”. System wyświetla ikonę jak dla obrazu dysku, ale użytkownik widzi głównie słowo „Faktura_04_2026.pdf” – rozszerzenia są domyślnie ukryte.

Kliknięcie, zamontowanie obrazu, uruchomienie „podpisanego” pliku wykonywalnego o ikonie PDF. W tle powstaje nowy proces, który szybko pobiera dodatkowy plik z Internetu, modyfikuje kilka kluczy rejestru i instaluje usługę systemową. Po godzinie serwer plików działa już ociężale, kolejne katalogi zaczynają mieć rozszerzenie „.locked”, a w każdym z nich pojawia się plik „INSTRUKCJA_ODZYSKANIA_DANYCH.txt”. Firma właśnie oficjalnie weszła w klub „mieliśmy udany phishing z ransomware”.

Z zewnątrz wygląda to jak przypadek i „głupie kliknięcie”. Z perspektywy technicznej to ściśle zaplanowany łańcuch zdarzeń: od oszukania użytkownika, przez wykorzystanie słabych konfiguracji systemu, aż po pełne przejęcie kontroli nad stacją i ruchem bocznym po sieci. I właśnie ten łańcuch warto rozłożyć na czynniki pierwsze.

Phishing 2026: od tandetnych wiadomości do chirurgicznej precyzji

Fala maili „Wygrałeś iPhone’a” już dawno nie jest głównym problemem. Dzisiejszy phishing to często precyzyjne kampanie:

• Spear phishing – wiadomości szyte na miarę konkretnej osoby lub roli (np. dział finansów, HR).
• Business Email Compromise (BEC) – przejęcie prawdziwej skrzynki (np. kontrahenta) i wysyłka z niej złośliwych załączników.
• Thread hijacking – podpinanie się pod istniejącą korespondencję, z realną historią maili.

Im lepsza socjotechnika, tym łatwiej „przepchnąć” złośliwy załącznik przez filtr ludzkiego zdrowego rozsądku. Gdy mail przychodzi z prawdziwej, oczekiwanej domeny, a temat dotyczy czegoś bieżącego (przetarg, faktura, CV kandydata), opory użytkownika znacząco spadają.

Dlaczego załącznik jest ulubionym nośnikiem atakujących

Z perspektywy atakującego złośliwy załącznik ma kilka przewag nad samym linkiem:

• Bezpośredni kontakt z endpointem – plik jest uruchamiany lokalnie, na stacji roboczej, z uprawnieniami użytkownika.
• Możliwość obejścia filtrów URL – część firm ma dobre filtry web, ale słabsze analizy załączników.
• Formaty „biurowe” jako przykrywka – dokumenty Office, PDF, ZIP kojarzą się z pracą, a nie z malware.
• Łańcuch wieloetapowy – załącznik może być jedynie dropperem lub downloaderem, dociągającym właściwe malware później.

Link w mailu może zostać zablokowany przez bramkę proxy czy filtr DNS. Załącznik trafia wprost do klienta poczty, gdzie wiele zależy od konfiguracji stacji i systemu EDR/AV. Dodatkowo złośliwy dokument może używać funkcji wewnętrznych (makra, skrypty, DDE), które wyglądają jak „funkcje aplikacji”, a nie jak obcy kod.

Niebezpieczny link vs złośliwy plik – różnica z punktu widzenia obrony

Link jest dość prosty do opisu: adres URL, domena, parametry, ewentualnie przekierowania. Można go:

• blokować na poziomie DNS,
• analizować na sandboxie,
• skanować pod kątem phishingu (certyfikat, zawartość strony, formularze).

Złośliwy plik jest znacznie bardziej elastyczny. Może zawierać:

• makro VBA,
• osadzony skrypt PowerShell,
• linki do zewnętrznych zasobów,
• fragmenty zaszyfrowanego payloadu rozbitego na części.

Dodatkowo plik jest często modyfikowany, packowany lub obfuskowany, by utrudnić klasyczne skanowanie sygnaturowe. Dwa załączniki z tej samej kampanii mogą mieć inny hash, ale ten sam efekt – co utrudnia prostą blokadę „po sumie kontrolnej”. Obrona wymaga więc skupienia się na zachowaniu po uruchomieniu, a nie tylko na treści pliku.

Anatomia złośliwego załącznika – formaty, triki, kamuflaż

Najpopularniejsze formaty, w których ukrywa się malware

Z punktu widzenia analizy złośliwego załącznika najczęściej pojawiają się:

• DOC/DOCX, XLS/XLSX, PPT/PPTX – dokumenty Office z makrami VBA, polami DDE, osadzonymi obiektami OLE.
• PDF – formularze, skrypty JavaScript, linki do zewnętrznych plików, pola akcji.
• Archiwa: ZIP, RAR, 7z – ukrywanie wielu plików, często z hasłem podanym w treści maila (utrudnia to skanowanie AV na bramce pocztowej).
• Obrazy dysków: ISO, IMG, VHD – montowane jak napęd, zawierają pliki EXE, LNK, skróty do skryptów.
• LNK – skróty systemu Windows, które mogą uruchamiać cmd, PowerShell, wscript z parametrami.
• Pliki skryptowe – .vbs, .js, .ps1, .bat, .cmd, często spakowane w archiwa.

W wielu organizacjach użytkownicy rzadko widują skróty .lnk jako załączniki, więc ich czujność jest niska. Tymczasem plik LNK może zawierać bezpośrednie wywołanie powershell.exe z parametrami ściągającymi i uruchamiającymi kolejny etap ataku.

Maskowanie rozszerzeń, ikon i nazw plików

System Windows wciąż domyślnie ukrywa znane rozszerzenia plików. To klasyczne ułatwienie życia użytkownikowi… i atakującemu. Dzięki temu nazwa:

Faktura_04_2026.pdf.exe

może w eksploratorze wyglądać po prostu jak:

Faktura_04_2026.pdf

Zdarzają się też bardziej wyrafinowane sztuczki:

• Podwójne rozszerzenia – np. Umowa2026.docx.exe.
• Znaki Unicode „right-to-left override” (RLO) – zmiana kierunku wyświetlania tekstu, np. nazwa pliku „photo[U+202E]gpj.exe” wyświetli się jako „photoexe.jpg”.
• Fałszywe ikony – plik EXE z ikoną PDF, DOCX czy arkusza.

Z kolei pliki ISO/IMG często są kojarzone z instalatorami lub backupami. Po dwukrotnym kliknięciu system montuje je jak wirtualny napęd – użytkownik widzi katalog z „dokumentem” i szybko uruchamia to, co wygląda na bezpieczny plik biurowy, a w rzeczywistości jest wykonywalnym dropperem.

Socjotechniczny kamuflaż: faktury, CV, wezwania z urzędów

Od strony treści nazwy złośliwych załączników są do bólu przyziemne:

• Faktura_2026_04_2234.zip
• Umowa_Ankes_1.docm (celowa literówka „Ankes”)
• CV_Jan_Kowalski.pdf.iso
• Wezwanie_do_zaplaty_09-2026.pdf

Na to nakładają się komunikaty w treści: „Dokument zabezpieczony, proszę uruchomić makra”, „Plik zaszyfrowany ze względu na RODO, hasło: 1234” albo „Proszę otworzyć na komputerze stacjonarnym, urządzenia mobilne nie obsługują tego formatu”. Taki komunikat zdejmuje z atakującego podejrzenie, że coś jest „inaczej niż zwykle”.

Wielopoziomowe łańcuchy załączników

Rzadkością nie są już sytuacje, w których złośliwy kod jest rozbity na kilka warstw:

• Mail zawiera ZIP z hasłem.
• W środku znajduje się ISO.
• ISO zawiera skrót LNK.
• LNK uruchamia PowerShell, który ściąga właściwy payload EXE/DLL z Internetu.

Każda kolejna warstwa utrudnia analizę statyczną i automatyczne skanowanie na bramkach. Z punktu widzenia triage’u incydentu dobrze jest rozumieć, że „złośliwy załącznik” to czasem dopiero pierwszy klocek domina, który startuje całą sekwencję.

Co dzieje się na stacji użytkownika w chwili otwarcia pliku

Procesy i moduły: kto faktycznie otwiera plik

Po dwukrotnym kliknięciu w załącznik kilka rzeczy dzieje się niemal równocześnie:

• explorer.exe (powłoka systemowa) interpretuje rozszerzenie i uruchamia skojarzony program – np. WINWORD.EXE dla .docx, AcroRd32.exe dla PDF, cmd.exe lub wscript.exe dla .vbs.
• System ładuje moduły DLL niezbędne do otwarcia danego typu pliku – np. biblioteki Office, biblioteki renderujące PDF.
• Klient pocztowy (np. Outlook) może otwierać podgląd dokumentu w swoim procesie, zanim użytkownik kliknie „Otwórz”.

Jeśli załącznik to archiwum (ZIP, RAR, 7z), najpierw uruchamiany jest program obsługujący archiwa (np. explorer.exe w przypadku wbudowanego wsparcia ZIP, lub 7zFM.exe przy 7-Zip), a dopiero potem zawartość. Z punktu widzenia obrony ważne jest zrozumienie, który proces jest „rodzicem” złośliwej aktywności, bo w logach EDR to często pierwszy trop.

Podgląd w Outlooku i miniatury – infekcja nawet przed „otwarciem”

Czasem do zainicjowania niebezpiecznych działań wystarczy zaznaczenie wiadomości z załącznikiem. Outlook czy inne klienty potrafią generować:

• podgląd treści dokumentu (Word/Excel/PDF) wewnątrz okna programu,
• miniatury plików w Zasobniku załączników.

Jeśli złośliwy dokument wykorzystuje podatność w silniku renderowania (np. stary komponent do podglądu PDF), to sam proces renderowania miniatury może zostać wykorzystany do wykonania kodu, jeszcze zanim użytkownik kliknie „Otwórz”. To rzadszy, ale wciąż istotny scenariusz przy analizie incydentów na starszych stacjach czy bez aktualizacji.

Pierwsze logi, które „mówią”, że coś jest nie tak

Otwarcie pliku generuje od razu kilka śladów w systemie:

• Event Log – Application: uruchomienie aplikacji (Word, Excel, Acrobat), ewentualne błędy ładowania modułów, awarie.
• Event Log – Security: logon typu 2 (interaktywny), czasem nowe sesje powłoki, jeśli uruchamiany jest np. cmd/powershell.
• Logi AV/EDR: rejestracja uruchomienia nowego procesu, próby tworzenia plików w katalogach tymczasowych, modyfikacja rejestru.

Dla zespołu bezpieczeństwa to sygnały, które można korelować. Przykład: plik otwarty przez Worda, a w ciągu 5 sekund pojawia się nowy proces powershell.exe z nietypowymi parametrami oraz połączenie HTTP do domeny, której organizacja nigdy wcześniej nie widziała. To klasyczny początek łańcucha infekcji.

Przykładowa różnica: stacja z EDR vs stacja „goła”

Na stacji bez EDR otwarcie zainfekowanego DOCX może wyglądać tak:

• Użytkownik klika „Włącz zawartość” (Enable Content).
• Makro wywołuje powershell.exe w trybie ukrytym, bez konsoli.
• PowerShell pobiera plik z Internetu i zapisuje go w %TEMP%.
• Uruchamiany jest nowy plik wykonywalny z tego katalogu.

Systemowy rejestr zdarzeń może pokazać jedynie ogólne informacje o uruchomieniu aplikacji. Z kolei na stacji z dobrym EDR zobaczymy:

• proces WINWORD.EXE jako rodzica powershell.exe,

Telemetryjne „nitki”, po których można iść

Dla zespołu bezpieczeństwa moment otwarcia załącznika to pierwsza okazja, by złapać atakującego za rękaw. Część ścieżek infekcji wygląda chaotycznie, ale w logach widać powtarzalne wzorce. Kilka z nich wraca jak bumerang:

• Nietypowe procesy potomne aplikacji biurowych – Word/Excel/Acrobat nagle stają się „rodzicami” dla cmd.exe, powershell.exe, wscript.exe, mshta.exe lub rundll32.exe.
• Tworzenie plików w katalogach tymczasowych z losowymi nazwami, często ukrytych (attrib +h), np. w %TEMP%, %APPDATA%, %PROGRAMDATA%.
• Nagłe pojawienie się nowych kluczy rejestru w miejscach związanych z autostartem lub konfiguracją skryptów.
• Świeże wpisy w harmonogramie zadań (Task Scheduler) z dziwnymi nazwami typu „UpdateSvc” uruchamiane co kilka minut.

Jeśli w środowisku zbierane są logi z Sysmon lub podobnego agenta, korelacja „WINWORD.EXE → POWERSHELL.EXE → połączenie HTTP” często wystarcza, żeby wstępnie wytypować stację jako zainfekowaną, jeszcze zanim użytkownik zauważy cokolwiek podejrzanego na ekranie.

Makra, skrypty i inne mechanizmy uruchamiania kodu

Makra VBA w dokumentach Office – klasyk, który wciąż działa

Makra w dokumentach Office to nadal jeden z najpopularniejszych wehikułów dla złośliwego kodu. Cały trik polega na tym, że kod VBA może wykonywać:

• polecenia systemowe (np. przez Shell()),
• wywołania do WinAPI,
• operacje na plikach i rejestrze,
• połączenia sieciowe (np. przez obiekty COM, XMLHTTP itp.).

Typowy scenariusz to makro osadzone w sekcji Document_Open lub AutoOpen, uruchamiane automatycznie przy otwarciu pliku. Użytkownik widzi tylko natarczywy baner: „Ten dokument jest zabezpieczony. Kliknij Włącz zawartość, aby wyświetlić pełną treść”. Po kliknięciu – pas startowy dla kodu ofensywnego jest wolny.

Jak wygląda złośliwe makro „od środka”

Kiedy analityk zagląda do edytora VBA, rzadko widzi czytelny kod typu:

Sub AutoOpen()
    Call PobierzMalware
End Sub

Zamiast tego pojawia się:

• Obfuskacja – losowe nazwy zmiennych (aa1, zzz2), dziwne pętle, mnóstwo zbędnego kodu.
• Łączenie ciągów – komendy PowerShell pocięte na drobne fragmenty i składane w locie, żeby utrudnić wykrywanie sygnaturami.
• Ukryty kod w formularzach – logika nie w module, a np. w zdarzeniach przycisków lub w kodzie UserForm.

Ostatecznie i tak chodzi o jeden cel: zbudować i uruchomić komendę (zwykle PowerShell lub cmd.exe), która pobierze payload z Internetu lub wyciągnie go z zaszytego zasobu w samym dokumencie.

DDE, OLE i inne „funkcje użytkowe” w roli wektora ataku

Nie każde złośliwe Office’owe „magiczne sztuczki” to makra. W arsenale bywa też:

• DDE (Dynamic Data Exchange) – pole typu „odśwież dane z innego źródła”, które zamiast łączenia z arkuszem Excela może odpalić komendę powłoki.
• Osadzone obiekty OLE – plik EXE lub skrypt schowany w dokumencie jako obiekt; wystarczy dwuklik lub akceptacja komunikatu „Otworzyć dołączony obiekt?”.
• Linki do zewnętrznych szablonów – dokument DOCX może mieć wskazany szablon z sieci (np. serwerudziałtemplate.dotm). Po otwarciu Word łączy się z tym zasobem i może dociągnąć dalej zainfekowaną logikę.

DDE swego czasu robiło furorę w kampaniach, które „bez makr” potrafiły uruchamiać polecenia systemowe. Obecnie część z tych funkcji jest lepiej ograniczona, ale w środowiskach z legacy Office nadal zdarzają się przykre niespodzianki.

JavaScript, VBS, HTA – lekkie skrypty, ciężkie skutki

Pliki z rozszerzeniami .js, .vbs, .hta bywają spakowane w ZIP z miłą nazwą typu „Skan_umowy”. Po rozpakowaniu użytkownik widzi plik z ikonką przypominającą dokument HTML lub prostą aplikację. Dwuklik uruchamia:

• wscript.exe lub cscript.exe dla VBScript/JavaScript,
• mshta.exe dla aplikacji HTML (HTA).

Te hosty skryptowe mogą swobodnie:

• pobierać dodatkowe pliki przez HTTP/HTTPS,
• modyfikować rejestr,
• uruchamiać kolejne procesy (cmd, powershell, rundll32).

Dla atakującego to wygodny sposób na zbudowanie „stage 1” – lekkiego, łatwego do zmian skryptu, który dopiero po uruchomieniu dociąga właściwe narzędzia (np. implant C2).

PowerShell jako szwajcarski scyzoryk atakującego

PowerShell, projektowany jako potężny automat do zarządzania systemem, z perspektywy obrony bywa niestety idealnym „zdalnym sterownikiem”:

• umie pobierać dane z Internetu jednym poleceniem (Invoke-WebRequest, Invoke-RestMethod),
• obsługuje kod w formacie Base64, co ułatwia ukrycie treści polecenia,
• umożliwia odpalanie kodu w pamięci (bez pliku na dysku),
• ma łatwy dostęp do API Windows, WMI, Active Directory.

Złośliwe makro typowo wywołuje coś w stylu:

powershell.exe -NoProfile -ExecutionPolicy Bypass -WindowStyle Hidden -EncodedCommand <ciąg_Base64>

Parametry -NoProfile, -ExecutionPolicy Bypass i -WindowStyle Hidden są czerwoną flagą w logach – szczególnie gdy procesem rodzicem jest Word, Excel czy klient poczty.

PDF – mniej krzyku, ale wciąż realne ryzyko

Pliki PDF rzadziej wykorzystują makra, ale mają własny zestaw sztuczek:

• JavaScript w PDF – używany oryginalnie do walidacji formularzy, przechwytywany do exploitów.
• Akcje dokumentu – np. „po otwarciu dokumentu uruchom skrypt/otwórz URL”.
• Odesłania do zewnętrznych zasobów – obrazy czy czcionki ładowane z serwera atakującego.

W praktyce nowoczesne czytniki są dużo bardziej zahartowane niż stare, ale w środowiskach, gdzie wciąż krąży „historyczny” Acrobat Reader sprzed kilku wersji, PDF potrafi być równie groźny co dokument Office z makrem.

Łańcuch infekcji: od pierwszego procesu do trwałej obecności

Stage 0, Stage 1, Stage 2 – jak atakujący porcjuje swój kod

Żeby utrudnić wykrywanie i analizę, malware rzadko jest jedną wielką binarką. Częściej wygląda to tak:

• Stage 0 – dokument/załącznik (DOCX, PDF, LNK, VBS). Jego jedynym zadaniem jest odpalić kolejne stadium.
• Stage 1 – lekki skrypt lub mały EXE, pobierany z sieci lub wyciągany z zasobu. Zwykle obsługuje rekonesans systemu i pobiera właściwy „silnik”.
• Stage 2 – pełnoprawny implant/C2 lub narzędzie typu stealer, ransomware, backdoor.

Taki podział daje napastnikowi elastyczność: może zmieniać Stage 0 w kampanii phishingowej (nowe nazwy, nowe dokumenty), a Stage 2 – główny malware – pozostaje praktycznie ten sam.

Dropper vs downloader – dwa archetypy pierwszego etapu

Pierwsze złośliwe wykonywalne stadium zwykle mieści się w jednej z dwóch kategorii:

• Dropper – zawiera payload w sobie (np. zaszyfrowany w sekcji zasobów), po uruchomieniu wypakowuje go na dysk i startuje.
• Downloader – ma w kodzie wpisany adres serwera (URL/IP) i dopiero z niego pobiera właściwy plik.

Dropper jest mniej zależny od sieci (zadziała nawet w środowisku częściowo odciętym), ale trudniej go zaktualizować w locie. Downloader bywa „chudszy” i bardziej elastyczny: ten sam binarny plik może pobierać różne malware w zależności od kampanii czy regionu geograficznego ofiary.

Rekonesans: co malware sprawdza, zanim rozsiądzie się wygodnie

Zanim implant zapisze się na stałe, zwykle najpierw bada teren. Typowe elementy rozpoznania:

• Środowisko uruchomieniowe – wersja systemu, architektura (x86/x64), język interfejsu, lista zainstalowanego oprogramowania.
• Uprawnienia – czy aktualny użytkownik jest w grupie Administratorzy, czy ma uprawnienia domenowe.
• Środki ochrony – czy na stacji działa EDR, antywirus, agent DLP; obecność charakterystycznych procesów lub sterowników.
• Wirtualizacja/piaszczynka – malware może szukać śladów VM, narzędzi analitycznych, nienaturalnej konfiguracji (np. bardzo mało plików użytkownika).

Na tej podstawie implant może zdecydować, czy rozwinąć pełnię możliwości, czy zachowywać się „ciszej”, albo nawet całkiem się zakończyć, żeby nie zdradzić się w laboratorium analitycznym.

Mechanizmy utrwalenia (persistencja) w systemie Windows

Żeby atak nie zakończył się po jednym restarcie, malware musi znaleźć sposób na automatyczne uruchamianie się. Najczęściej wykorzystuje:

• Klucze Run/RunOnce w rejestrze: HKCUSoftwareMicrosoftWindowsCurrentVersionRun lub HKLM....
• Folder Autostart użytkownika (skrót LNK wskazujący na binarkę lub skrypt).
• Harmonogram zadań – tworzenie ukrytego zadania wywołującego plik co logon/boot.
• Usługi (services) – rejestracja nowej usługi lub przejęcie istniejącej.
• Wtyczki i dodatki – np. zainstalowanie dodatku do przeglądarki lub klienta poczty.

Bardziej zaawansowane zagrożenia mogą modyfikować sterowniki, biblioteki systemowe albo stosować techniki DLL hijacking, ale w większości incydentów spotykanych w SMB występują właśnie banalne wpisy Run+zadanie w harmonogramie – bo „wystarczająco dobre”.

Fileless i living off the land – gdy prawie nic nie ląduje na dysku

Coraz częściej atakujący rezygnuje z typowego EXE na dysku i przechodzi na tryb:

• fileless – kod ładowany bezpośrednio do pamięci (np. przez PowerShell, rundll32, reflective injection); na dysku zostają tylko śladowe skrypty lub w ogóle nic.
• living off the land (LotL) – wykorzystywanie już obecnych w systemie narzędzi (PowerShell, WMI, certutil.exe, mshta.exe, bitsadmin.exe), bez dostarczania nowych plików.

Dla detekcji oznacza to przestawienie się z monitorowania „podejrzanych plików” na profilowanie zachowania legalnych procesów. Jeśli certutil.exe nagle zaczyna pobierać plik z Internetu i zapisywać go w %TEMP%, to jest to sygnał ostrzegawczy, nawet jeżeli żaden nowy EXE nie pojawia się w katalogu „Pobrane”.

Komunikacja z serwerem C2 – jak zarażona stacja „gada” z napastnikiem

Próba pierwszego kontaktu: beaconing

Gdy implant uzna, że może działać, zwykle jako pierwsze robi to, co świeżo zainstalowana aplikacja chatowa – próbuje odezwać się do „serwera centrali”. Ten proces nazywa się beaconingiem:

• co określony interwał (np. co 30 sekund, co 5 minut, czasem losowo),
• malware wysyła mały pakiet danych do serwera C2 (Command and Control),
• w odpowiedzi może dostać instrukcję (komendę) lub nową konfigurację.

Jak wygląda ten ruch w sieci – HTTP(S), DNS, nietypowe porty

Z punktu widzenia sieci implant robi rzeczy bardzo podobne do zwykłych aplikacji – na tym polega jego siła. Typowe wzorce:

• HTTP/HTTPS – najczęstszy kanał, bo wygląda jak zwykłe przeglądanie Internetu. Ruch bywa:
  • schowany pod /api/status, /update/check czy innymi „nudnymi” ścieżkami,
  • opakowany w JSON lub pseudo-XML, żeby przypominać telemetrię czy logi.
• DNS – dane zaszyte w nazwach domen (np. hostid.random.token.example.com) lub odpowiedziach TXT. Z zewnątrz wygląda jak „trochę rozmowny” klient DNS.
• Nietypowe porty – 8080, 8443, 53, 443 na niestandardowych protokołach; czasem wręcz czysty TCP z prostym protokołem tekstowym.

Przyjmuje się, że „HTTPS jest święte”, więc wiele firm go nie rozpakowuje – to raj dla C2. W logach widać tylko, że jakaś stacja uparcie rozmawia z jednym adresem IP, a co tam płynie w środku, wie tylko implant i operator.

Maskowanie się w tłumie: domeny, certyfikaty, chmura

Samo nawiązanie połączenia to za mało, trzeba je jeszcze ukryć w szumie. Napastnicy:

• stawiają C2 na popularnych chmurach (Azure, AWS, Google, CDN-y),
• używają automatycznych certyfikatów (np. Let’s Encrypt) o neutralnie brzmiących nazwach,
• rejestrują domeny podobne do realnych usług: office-updates[.]net, cdn-sharepoint[.]com itd.

Stacja użytkownika widoczna w logach komunikuje się z adresem IP należącym do dużego dostawcy chmurowego – wygląda to równie „podejrzanie”, co zwykłe korzystanie z Teamsów. Z perspektywy SOC różnica bywa subtelna: trochę inne URI, regularne, „zbyt idealne” odstępy beaconów, brak typowych nagłówków przeglądarki.

Szyfrowanie i tunelowanie komend

C2 prawie nigdy nie wysyła poleceń „wprost”. Nawet jeśli implant używa HTTPS, to wewnątrz:

• komendy i odpowiedzi są dodatkowo szyfrowane (np. własnym AES z kluczem zaszytym w binarce),
• dane są kodowane (Base64, XOR, kompresja) zanim trafią do JSON-a czy formularza HTTP POST,
• odpowiedzi są „puste”, jeśli operator w danej chwili nic nie zlecił (implant tylko raportuje, że żyje).

W praktyce ruch wygląda jak małe, regularne zapytania typu „check-in” – trochę jak klient, który obsesyjnie sprawdza powiadomienia. Dopiero po stronie serwera pakiety są rozpakowywane i pokazywane operatorowi w formie znanego mu interfejsu: „uruchom cmd”, „ściągnij plik”, „zeskanuj podsieć”.

Fallback i redundancja – gdy pierwszy C2 padnie

Dobry implant nie ma jednego „numeru telefonu do centrali”. W konfiguracji często pojawia się:

• kilka domen C2,
• kilka różnych tras (np. HTTP, DNS, czasem mail),
• mechanizm opóźnionego uśpienia: jeżeli brak odpowiedzi dłużej niż X godzin, zmień serwer lub przejdź w tryb „hibernacji”.

Po stronie obrony wygląda to tak: blokujesz wykrytą domenę, ruch zamiera, incydent wydaje się opanowany – a po tygodniu ten sam host nagle zaczyna rozmawiać z innym, równie „legitnym” adresem w tej samej chmurze.

Interaktywna sesja: jak operator steruje stacją

Gdy beaconing działa poprawnie i implant „zaryzykuje” pełne połączenie, operator może:

• otworzyć interaktywną powłokę (shell) na komputerze ofiary,
• przeglądać system plików, zrzucać katalogi, wyszukiwać słowa kluczowe,
• uruchamiać w locie moduły: skaner haseł, keylogger, screenshotter, rekonesans AD.

Z punktu widzenia użytkownika najwyżej „coś przymuli”, czasem na moment zamigocze okno konsoli. Cała reszta dzieje się w tle: procesy startują bez okien, komunikacja z C2 idzie zaszyfrowanym kanałem, a jedyny czytelny ślad to nietypowe procesy potomne i ruch sieciowy w dziwnych godzinach.

Rozszerzanie zasięgu: lateral movement po udanym phishingu

Dlaczego jedno konto użytkownika to dopiero rozgrzewka

Przeciętne konto pracownika ma ograniczone prawa: dostęp do poczty, folderu współdzielonego, kilku aplikacji. Dla operatora to dobry punkt startu, ale nie cel. Prawdziwe „nagrody” to:

• kontrolery domeny i kontrola nad AD,
• serwery plików z kopiami umów, projektów, backupami,
• systemy finansowe, HR, CRM, repozytoria kodu.

Dlatego po pierwszym udanym phishingu zaczyna się klasyczne „wewnętrzne RC Exploration” – rozpoznanie i przemieszczanie się po sieci wewnętrznej.

Zbieranie poświadczeń: od tokenów po pliki konfiguracyjne

Żeby iść dalej, trzeba zebrać kolejne klucze do innych drzwi. Implant:

• sprawdza pamięć procesów (np. przeglądarki, menedżery haseł bez hasła głównego, aplikacje VPN),
• wydobywa hasła zapisane w rejestrze lub plikach konfiguracyjnych (np. stare narzędzia administracyjne, skrypty backupu),
• korzysta z wbudowanych funkcji Windows do pobierania ticketów Kerberos i tokenów dostępowych,
• uruchamia narzędzia typu credential dumper (Mimikatz i jego klony) – często w pamięci, bez zapisywania pliku.

Na jednym z realnych incydentów cała organizacja „poległa”, bo administrator kiedyś wrzucił na udział sieciowy skrypt backup.ps1 z wklejonym na sztywno hasłem do konta serwisowego domeny. Implant znalazł plik w kilka minut.

RDP, SMB, WMI – klasyczne ścieżki w bok

Gdy pojawią się nowe poświadczenia, pora przeskoczyć dalej. Najpopularniejsze wektory lateral movement:

• RDP – zdalny pulpit na inne stacje/serwery, często z pominięciem MFA w sieci wewnętrznej.
• SMB – dostęp do udziałów sieciowych, kopiowanie i uruchamianie plików na innych hostach.
• WMI i WinRM – zdalne wykonywanie poleceń, używane także przez legalne narzędzia administracyjne.

Mechanizm jest prosty: implant lub operator próbuje zalogować się na kolejne hosty z nowo uzyskanymi poświadczeniami. Jeśli któryś z nich przyjmie logowanie – mamy kolejny punkt zaczepienia, kolejne procesy, kolejne możliwości skanowania sieci z innej perspektywy.

Pivoting i „wyspy” w sieci

Sieci korporacyjne bywają podzielone na segmenty: VLAN-y, strefę serwerową, stacje użytkowników, sieć gościnną. Atakujący musi więc:

• znaleźć hosty, które mają dostęp do więcej niż jednego segmentu (np. serwery aplikacyjne, komputery administratorów),
• wykorzystać je jako „mosty” – zainstalować tam kolejne implanty i skanować / atakować z ich poziomu.

Ten proces nosi nazwę pivotingu. Z perspektywy logów ruch nie wychodzi już z pierwszego zainfekowanego laptopa, ale z serwera, który „z definicji” ma więcej uprawnień. Jeśli monitoring jest kiepski, łatwo uznać, że „serwer aplikacyjny robi swoje”, gdy tak naprawdę działa jako skocznia dla operatora.

Atak na Active Directory i eskalacja uprawnień

Gdy atakujący dotrze do środowiska domenowego, zaczynają się bardziej zaawansowane sztuczki:

• analiza struktury AD (użytkownicy, grupy, polityki GPO, delegacje uprawnień),
• szukanie kont uprzywilejowanych z hasłami wieloletnimi i wciąż aktywnymi,
• wykorzystywanie błędnych konfiguracji (np. możliwość edycji GPO przez zwykłych administratorów lokalnych).

Popularne techniki obejmują:

• Pass-the-Hash / Pass-the-Ticket – używanie wykradzionych hashy lub ticketów Kerberos bez poznania hasła w czystym tekście,
• Golden Ticket – wygenerowanie „superbiletu” Kerberos, który daje kontrolę nad domeną,
• DCsync / DCshadow – podszycie się pod kontroler domeny i zrzucenie hashy wszystkich kont.

Jeśli do tego dojdzie, sytuacja obronna staje się bardzo trudna: atakujący jest de facto „właścicielem” katalogu użytkowników i komputerów, może tworzyć nowe konta, nadawać sobie prawa, podmieniać skrypty logowania czy polityki bezpieczeństwa.

Rozsiewanie implantu i backdoorów w całej organizacji

Po zdobyciu wyższych uprawnień kolejny krok to rozmnożenie się. Kilka praktyk:

• rozkładanie implantów na wielu stacjach użytkowników (np. przez GPO, skrypty logowania, narzędzia zdalnej administracji),
• dodawanie ukrytych kont lokalnych lub domenowych z członkostwem w grupach administracyjnych,
• modyfikacja oprogramowania centralnego (np. narzędzia do zdalnego wsparcia IT) tak, żeby operator mógł „przyjść” w dowolnym momencie.

Z perspektywy obrony liczy się już nie pojedyncza zainfekowana stacja, tylko skala: incydent z poziomu „jeden klik w załącznik” eskaluje do sytuacji, w której połowę parku maszynowego trzeba uznać za potencjalnie przejętą.

Przygotowanie do monetizacji: ransomware, kradzież danych, szantaż

Lateral movement ma konkretny cel biznesowy po stronie przestępcy. Po zbudowaniu zasięgu i upewnieniu się, że:

• backupy są w zasięgu (lub da się je zniszczyć),
• dane wrażliwe są skatalogowane i skopiowane,
• środowisko jest wystarczająco dobrze zrozumiane,

atak przechodzi w fazę „kasy”:

• ransomware – szyfrowanie jak największej liczby serwerów i stacji, często jednocześnie,
• data exfiltration – wynoszenie gigabajtów plików (projekty, bazy danych, maile zarządu),
• podwójny/trójfazowy szantaż – żądanie okupu za odszyfrowanie, za niewypuszczenie danych do Internetu i za niewykonanie kolejnego ataku (np. DDoS).

Na tym etapie kliknięcie w załącznik sprzed kilku tygodni jest już tylko ciekawostką w linii czasu incydentu. Źródło kłopotów było banalne, ale łańcuch zdarzeń po drodze – bardzo daleki od „jednego pliku, który coś tam zaszyfrował”.

Źródła

• Internet Security Threat Report. Symantec (2019) – Statystyki phishingu, złośliwych załączników i ransomware
• 2023 Data Breach Investigations Report. Verizon (2023) – Rola phishingu i załączników w incydentach bezpieczeństwa
• Malicious Document Analysis: A Primer. SANS Institute (2018) – Analiza złośliwych dokumentów Office, makr i OLE
• NIST Special Publication 800-61 Revision 2: Computer Security Incident Handling Guide. NIST (2012) – Wytyczne reagowania na incydenty, w tym malware i phishing
• MITRE ATT&CK Enterprise Matrix. MITRE – Techniki T1566, T1204, T1203, T1059 dot. phishingu i złośliwych plików
• Microsoft 365 Defender: Malware and ransomware protection overview. Microsoft – Opis typowych wektorów infekcji, złośliwych załączników i zachowań
• Windows Internals, Part 1 (7th Edition). Microsoft Press (2017) – Procesy, usługi, rejestr – kontekst dla trwałości malware w Windows