Phishing w hotelach: fałszywa skarga gościa

TL;DR

Microsoft opisał kampanię phishingową wymierzoną w branżę hotelarską i hospitality. Atakujący wysyłają wiadomości podszywające się pod gości, rezerwacje, skargi, zgłoszenia dotyczące pluskiew, opinie o pobycie albo pytania o stan pokoju. Pracownik recepcji lub rezerwacji ma pobrać archiwum ZIP ze zdjęciami i otworzyć plik, który wygląda jak obraz.

Problem polega na tym, że „zdjęcie” może być skrótem Windows LNK. Po uruchomieniu zaczyna się łańcuch infekcji z użyciem PowerShella, Node.js. Dla użytkownika to nadal wygląda jak zwykła obsługa reklamacji. Dla organizacji może to być początek przejęcia stacji roboczej, kont rezerwacyjnych, danych gości albo kolejnych prób oszustwa.

To inny scenariusz niż klasyczny phishing na prawdziwe rezerwacje hotelowe, w którym ofiarą jest podróżny. Tutaj pierwszym celem jest pracownik hotelu, recepcji, apartamentu, obsługi klienta albo zespołu rezerwacji.

Dlaczego recepcja jest dobrym celem dla phishingu

Recepcja nie działa jak typowe biuro, w którym większość wiadomości pochodzi od znanych nadawców. Codzienna praca polega na kontakcie z gośćmi, pośrednikami, platformami rezerwacyjnymi, kurierami, partnerami i dostawcami. Nieznany nadawca nie jest automatycznie czymś dziwnym.

Atakujący wykorzystują właśnie tę rutynę. Fałszywa skarga gościa brzmi wiarygodnie, bo hotel naprawdę musi reagować na reklamacje. Wiadomość o stanie pokoju, pluskwach, problemie zdrowotnym, zdjęciach szkód albo groźbie negatywnej opinii uruchamia presję operacyjną. Pracownik chce szybko wyjaśnić sprawę, zanim temat trafi do menedżera, platformy rezerwacyjnej lub publicznej opinii.

W takiej sytuacji zadziała nie tylko strach. Zadziała też odpowiedzialność za obsługę gościa. To ważny element phishingu: przynęta nie musi być technicznie wyrafinowana, jeśli pasuje do realnego obowiązku pracownika.

Jak działa scenariusz z fałszywą skargą gościa

W kampanii opisanej przez Microsoft atak zaczynał się od wiadomości kierowanych do organizacji z sektora hotelarskiego. Tematy wiadomości dotyczyły między innymi skarg gości, stanu pokoju, pluskiew, próśb o weryfikację, opinii po pobycie i zapytań rezerwacyjnych. Taki zestaw tematów jest dobrany pod ludzi, którzy naprawdę pracują z reklamacjami i zdjęciami od klientów.

W części obserwowanych wariantów atakujący nadużywali legalnych usług, w tym infrastruktury powiadomień Calendly i przekierowań Google. Microsoft określa ten mechanizm jako authentication laundering, czyli sytuację, w której wiadomość przechodzi część kontroli technicznych, bo jest wysyłana przez zaufaną usługę, ale sama intencja wiadomości pozostaje złośliwa.

Po kliknięciu użytkownik trafiał przez kilka przekierowań do pobrania archiwum ZIP. Nazwa pliku sugerowała zdjęcia. W środku znajdował się plik wyglądający jak obraz PNG, ale z rozszerzeniem LNK. LNK to skrót Windows. Może wyglądać niewinnie, ale może też uruchomić polecenia w systemie.

Po otwarciu takiego pliku uruchamiany był kolejny etap. Microsoft opisał użycie zaciemnionego PowerShella, pobieranie dodatkowych komponentów, uruchomienie złośliwego kodu przez Node.js. Node.js nie jest tu sam w sobie problemem. Problemem jest jego nadużycie jako środowiska do uruchomienia złośliwego komponentu.

Dlaczego poprawne SPF, DKIM i DMARC nie wystarczą

SPF, DKIM i DMARC są potrzebne, ale nie rozwiązują całego problemu. SPF sprawdza, czy dana infrastruktura może wysyłać pocztę dla domeny. DKIM potwierdza podpis wiadomości. DMARC określa politykę dla domeny i zgodność identyfikatorów. Te mechanizmy pomagają ograniczać podszywanie się pod domeny, ale nie oceniają zdrowego rozsądku treści.

Jeżeli atakujący nadużywa legalnej usługi do wysłania powiadomienia lub przekierowania, część kontroli może wyglądać poprawnie. Wiadomość może przejść przez bramkę pocztową, bo formalnie pochodzi z infrastruktury, która ma prawo wysyłać dany typ powiadomień. To nie znaczy, że link prowadzi do bezpiecznego miejsca.

Dla zespołów IT i security oznacza to konieczność patrzenia szerzej niż na wynik uwierzytelnienia poczty. Liczy się cały ciąg zdarzeń: kto otrzymał wiadomość, czy kliknął link, co pobrała przeglądarka, jaki plik został uruchomiony, jakie procesy pojawiły się po otwarciu archiwum i czy endpoint zaczął komunikować się z nietypowymi domenami.

Polski kontekst: hotele, apartamenty i obsługa klienta

Ten scenariusz nie musi ograniczać się do dużych hoteli w Azji lub Europie Zachodniej. W Polsce podobne przynęty mogą trafić do recepcji hotelu, obiektu apartamentowego, pensjonatu, biura podróży, firmy obsługującej najem krótkoterminowy, działu administracji albo centrum obsługi klienta.

Wiadomość może dotyczyć brudnego pokoju, szkody w apartamencie, reklamacji za pobyt, zgubionego dokumentu, rzekomej kontroli sanitarnej, zdjęć uszkodzenia, faktury, zwrotu płatności albo groźby negatywnej opinii. Każdy z tych tematów brzmi jak normalna sprawa operacyjna.

Ryzyko rośnie, gdy pracownik korzysta z jednego komputera do poczty, paneli rezerwacyjnych, płatności, dokumentów gości i komunikacji z platformami. Przejęcie takiego urządzenia może dać atakującym dostęp nie tylko do lokalnych plików. Może też otworzyć drogę do kont w systemach rezerwacyjnych, poczty, paneli administracyjnych i danych klientów.

Warto też połączyć ten temat z szerszą mapą ryzyk dla branż, w których pracownicy obsługują klientów i płatności. Hotele są czytelnym przykładem, ale mechanizm działa wszędzie tam, gdzie wiadomość od nieznanej osoby jest częścią codziennej pracy.

Co powinien zrobić pracownik przed otwarciem pliku

Pracownik nie musi analizować złośliwego kodu. Musi rozpoznać moment, w którym rutynowa obsługa sprawy przechodzi w ryzyko.

Jeżeli wiadomość od gościa wymaga pobrania archiwum ZIP, otwarcia nietypowego pliku, przejścia przez kilka przekierowań albo uruchomienia czegoś, co nie jest zwykłym dokumentem, proces powinien się zatrzymać. Szczególnie podejrzane są sytuacje, w których plik udaje zdjęcie, ale pochodzi z archiwum, ma nietypową ikonę, wymaga rozpakowania albo nie pokazuje rozszerzenia.

Bezpieczniejsza reakcja to potwierdzenie sprawy innym kanałem. Recepcja może odpisać z prośbą o przesłanie zdjęć w bezpieczniejszej formie, użyć oficjalnego kanału platformy rezerwacyjnej albo przekazać wiadomość do osoby odpowiedzialnej za IT lub bezpieczeństwo. Jeśli organizacja ma przycisk zgłaszania phishingu, taka wiadomość powinna trafić do analizy, a nie do kosza.

To dobry scenariusz do ćwiczenia w ramach programu security awareness, bo sprawdza coś więcej niż kliknięcie. Sprawdza, czy pracownik umie przerwać proces, gdy wiadomość wygląda biznesowo, ale wymaga ryzykownego działania.

Co zrobić, jeśli to już się stało

Jeśli pracownik pobrał archiwum, ale go nie otworzył, nie powinien go rozpakowywać ponownie ani przesyłać dalej przypadkowymi kanałami. Plik trzeba zachować do analizy zgodnie z procedurą i zgłosić zdarzenie do IT, security albo administratora.

Jeżeli plik został otwarty, urządzenie należy potraktować jako potencjalnie naruszone. Brak komunikatu błędu, brak widocznej instalacji i normalnie działający komputer nie są dowodem bezpieczeństwa. W opisanym wzorcu infekcja może działać w tle, zmieniać wartości rejestru w systemie i kontaktować się z infrastrukturą sterującą.

Pierwsze działania powinny obejmować:

1. przerwanie pracy na urządzeniu,
2. zgłoszenie incydentu do właściwego zespołu,
3. odłączenie komputera od sieci zgodnie z procedurą organizacji,
4. zachowanie wiadomości, plików i czasu zdarzenia,
5. sprawdzenie, czy użytkownik logował się potem do poczty, paneli rezerwacyjnych lub systemów płatności,
6. zmianę haseł i unieważnienie sesji z innego, zaufanego urządzenia, jeśli istnieje ryzyko przejęcia konta.

W hotelu lub firmie obsługującej rezerwacje trzeba dodatkowo sprawdzić konta platform rezerwacyjnych, reguły pocztowe, aktywne sesje, historię wiadomości do gości i nietypowe zmiany danych płatniczych. Szwajcarskie ostrzeżenia z wcześniejszych kampanii pokazywały, że malware na komputerze hotelu może prowadzić do przejęcia dostępów do platform i późniejszego phishingu wysyłanego już do prawdziwych gości.

Co powinien monitorować IT, security i SOC

SOC, czyli zespół monitorowania bezpieczeństwa, nie powinien traktować tego jako pojedynczej wiadomości. Ważna jest sekwencja: e-mail, kliknięcie, pobranie, rozpakowanie, uruchomienie pliku, procesy potomne, komunikacja sieciowa.

W praktyce warto monitorować pobrania archiwów ZIP o nazwach sugerujących zdjęcia, uruchomienia plików LNK z katalogów użytkownika, start PowerShella po otwarciu pliku z archiwum, procesy Node.js z nietypowych lokalizacji, nowe wpisy autostartu, zmiany wyjątków w ochronie endpointa oraz połączenia do nowych lub nietypowych domen.

Nie chodzi o ślepe kopiowanie listy wskaźników z jednego raportu. Domeny i nazwy plików mogą się zmienić. Bardziej trwały jest wzorzec zachowania: wiadomość do recepcji, plik udający zdjęcie, uruchomienie skryptu, nietypowe procesy i próba utrzymania dostępu.

W organizacjach korzystających z Microsoft 365, Google Workspace lub innych usług SaaS trzeba równolegle sprawdzić logowania, sesje, reguły pocztowe, przekierowania, aplikacje z dostępem do konta i nietypowe operacje na plikach. Atak zaczyna się od endpointa, ale jego skutki mogą pojawić się w usługach chmurowych.

Jak ćwiczyć taki scenariusz

Ten typ ataku dobrze nadaje się do kontrolowanych ćwiczeń, ale scenariusz powinien być przygotowany odpowiedzialnie. Celem nie jest zawstydzenie recepcji ani udowodnienie, że ktoś kliknie. Celem jest sprawdzenie, czy organizacja rozpoznaje moment ryzyka i czy ma działający proces zgłoszenia.

W testach phishingowych dla firm taki wariant można zbudować jako wiadomość o reklamacji, zdjęciach szkody albo prośbie o pilne wyjaśnienie. Bez prawdziwego malware, bez realnego podszywania się pod markę i bez wykorzystywania danych gości. Mierzone powinny być nie tylko kliknięcia, ale też zgłoszenia, czas reakcji, decyzja o nieotwieraniu archiwum i przekazanie sprawy do właściwego kanału.

Po ćwiczeniu warto omówić trzy pytania: co sprawiło, że wiadomość wyglądała wiarygodnie, gdzie był moment zatrzymania i co powinno się wydarzyć po zgłoszeniu. Taka rozmowa daje więcej niż ogólna zasada „nie otwieraj podejrzanych załączników”, bo odnosi się do realnej pracy zespołu.

Wniosek dla firm obsługujących klientów

Fałszywa skarga gościa działa, bo nie wygląda jak egzotyczny cyberatak. Wygląda jak zadanie z kolejki recepcji, rezerwacji albo obsługi klienta. Właśnie dlatego kontrola nie może opierać się tylko na filtrze poczty i dobrych intencjach pracownika.

Najbezpieczniejsza zasada jest konkretna: jeśli wiadomość od klienta przenosi rozmowę do archiwum, skrótu, nietypowego pliku lub wieloetapowego pobierania, trzeba zatrzymać proces i zgłosić sprawę, zanim system zrobi coś za użytkownika. Jeśli chcesz przećwiczyć podobny scenariusz w swojej organizacji, możesz zacząć od rozmowy przez kontakt z PHISHLY.