NIS2 w skrócie – po co powstała i co zmienia dla organizacji
Dyrektywa NIS2 (Network and Information Systems 2) to unijne prawo dotyczące cyberbezpieczeństwa, będące następcą pierwszej dyrektywy NIS z 2016 roku (tzw. NIS1). Stanowi ona znaczący krok naprzód w wysiłkach UE na rzecz wzmocnienia cyberbezpieczeństwa w kluczowych sektorach gospodarki.
Kompletny przewodnik po dyrektywie NIS2 dla organizacji w Polsce i UE
Dyrektywa NIS2 to największa od lat zmiana w sposobie, w jaki organizacje w Europie muszą zarządzać bezpieczeństwem informacji, ryzykiem i incydentami. Jej celem nie jest biurokracja — lecz wprowadzenie realnych, mierzalnych standardów cyberbezpieczeństwa, które obejmą zarówno duże firmy, jak i kluczowych dostawców technologii, usług krytycznych i infrastruktury cyfrowej.
Grupa ransomware Everest ogłosiła, że to ona stoi za włamaniem do Collins Aerospace (spółka RTX), którego skutki odczuwalne były w całej Europie — od paraliżu odpraw po wielogodzinne opóźnienia. Nowa deklaracja na stronie wycieków grupy pojawiła się 17–18 października 2025 r., kilka tygodni po tym, jak Collins potwierdził incydent ransomware dotyczący oprogramowania do boardingu pasażerów. Wcześniej służby i media nie wskazywały jednoznacznie sprawców ataku.
W skrócie
Co się stało: Collins Aerospace padł ofiarą ataku ransomware, który zakłócił odprawy i nadawanie bagażu na lotniskach m.in. w Londynie (Heathrow), Brukseli, Dublinie i Berlinie. ENISA potwierdziła charakter ataku jako ransomware.
Nowy element: Grupa Everest publicznie przypisała sobie odpowiedzialność i zapowiedziała publikację wykradzionych danych.
Stan formalny: RTX w zgłoszeniu inwestorskim podał, że chodziło o oprogramowanie do boardingu pasażerów; spółka nie spodziewa się istotnego wpływu finansowego. Równolegle w Wielkiej Brytanii zatrzymano (warunkowo zwolniono) mężczyznę w związku ze sprawą, lecz śledztwo trwa.
Kontekst / historia / powiązania
Atak z września 2025 r. wymusił ręczną obsługę pasażerów na wielu lotniskach i spowodował odwołania lotów. W tamtym czasie nie było potwierdzonej identyfikacji grupy. Dopiero teraz Everest przypisuje sobie odpowiedzialność, ujawniając wpis na stronie wycieków i zapowiadając „transze” danych. Media branżowe i regionalne odnotowały ten zwrot, podkreślając związek ze wcześniejszym chaosem na lotniskach.
Analiza techniczna / szczegóły luki
Wektor uderzenia: RTX wskazał na „passenger boarding software” – klasę systemów krytycznych dla procesu odprawy i wejścia na pokład (CUTE/CUPPS), wdrażanych u wielu przewoźników i operatorów. Uderzenie w taką warstwę oprogramowania ma efekt kaskadowy (łańcuch dostaw).
Taktyki sprawców (TTPs) – wnioskowanie na podstawie znanych kampanii ransomware i deklaracji Everest: kradzież danych (double extortion), szyfrowanie zasobów produkcyjnych, groźba publikacji danych w razie braku okupu. Informacje z wpisów monitorujących leak-site Everest wskazują na publikację wpisu dotyczącego Collins/RTX w dniach 17–18 października.
Skala i propagacja zakłóceń: zakłócenia objęły wiele hubów (Heathrow, Bruksela, Berlin, Dublin), co potwierdza wrażliwość sektora lotniczego na jednopunktowe awarie po stronie dostawcy.
Praktyczne konsekwencje / ryzyko
Ryzyko operacyjne: przestoje w odprawach, ręczne procesy, korki w terminalach, utrata slotów, domino w siatce połączeń.
Ryzyko prawne i reputacyjne: potencjalny wyciek danych pasażerów lub partnerów, presja regulacyjna (NIS2, RODO), roszczenia kontraktowe. (Deklaracje publikacji danych przez Everest zwiększają ryzyko wtórnych nadużyć).
Ryzyko finansowe: choć RTX raportował brak „materialnego” wpływu, koszty incydentu po stronie linii i lotnisk (opóźnienia, personel, rekompensaty) mogą być znaczące – zwykle nieujmowane w raporcie dostawcy.
Rekomendacje operacyjne / co zrobić teraz
Dla operatorów lotnisk i linii lotniczych:
Modelowanie ryzyka łańcucha dostaw (CUPPS/CUTE/MUSE i integracje) – klasyfikacja komponentów „single point of failure”, audyty i plany awaryjne z realnym RTO/RPO.
Segmentacja i „blast radius” – oddzielenie sieci operacyjnych (airside/landsid e), kontrola lateral movement, tiered admin, „break-glass” konta offline.
Kontrole tożsamości – phishing-resistant MFA dla kont uprzywilejowanych, rotacja kluczy API integrujących DCS/Departure Control.
Telemetria i EDR/XDR – pełne logowanie na serwerach aplikacyjnych i brokerach integracyjnych (SITA/Amadeus itp.), korelacja zdarzeń z IOC/TTP grup ransomware.
Kopie zapasowe i runbooki manualne – offline immutable backups + ćwiczenia tabletop z przejściem na manual check-in/boarding.
Bezpieczny rozwój i hardening (CISA/ENISA good practices dla oprogramowania krytycznego), izolacja tenantów, kontrola aktualizacji.
Detekcja exfiltracji – DLP na warstwie aplikacyjnej, egress filtering, honeytokens w danych PII.
Plan odpowiedzialnej komunikacji – spójne advisory dla klientów (IOC, TTP, reguły detekcji, kroki naprawcze).
(Praktyki powyżej wynikają z dobrych praktyk dla incydentów ransomware w infrastrukturze krytycznej oraz z charakteru tego ataku potwierdzonego przez RTX/ENISA).
Różnice / porównania z innymi przypadkami
Wobec typowych ataków na linie lotnicze: tu głównym celem był dostawca oprogramowania, a nie pojedynczy przewoźnik. To tłumaczy szeroki, wielolotniskowy efekt.
Na tle „głośnych” kampanii (np. Scattered Spider): motywacja Everest wpisuje się w trend łączenia okupu z „prestiżem” w środowisku przestępczym – co podkreślali eksperci po wrześniowym chaosie.
Podsumowanie / kluczowe wnioski
Deklaracja Everest domyka najważniejszy znak zapytania: kto uderzył w Collins Aerospace. Formalnego potwierdzenia organów na razie brak, ale wpisy na leak-site i relacje branżowe są spójne czasowo.
Rdzeniem incydentu był atak ransomware na oprogramowanie do boardingu, co obnażyło kruchość łańcucha dostaw lotniczych.
Organizacje lotnicze powinny potraktować zdarzenie jako case study i wzmocnić segmentację, planowanie ciągłości działania oraz egzekwowanie wymagań bezpieczeństwa wobec dostawców.
Źródła / bibliografia
Cybersecurity Dive: „RTX confirms hack of passenger boarding software involved ransomware” (26 września 2025). (Cybersecurity Dive)
Reuters: „Airport chaos highlights rise in high-profile ransomware attacks…” (22 września 2025). (Reuters)
Reuters: „UK police arrest man over hack that affected European airports” (24 września 2025). (Reuters)
CyberNews: „Collins Aerospace attack claimed by Everest…” (18 października 2025). (Cybernews)
Security Affairs: „Everest Gang takes credit for Collins Aerospace breach” (18 października 2025). (Security Affairs)
Newsletter – Zero Spamu
Dołącz by otrzymać aktualizacje bloga, akademii oraz ukryte materiały, zniżki i dodatkową wartość.
Dzięki!
Dzięki za dołączenie do newslettera Security Bez Tabu.
Wkrótce otrzymasz aktualizacje z bloga, materiały zza kulis i zniżki na szkolenia.
Jeśli nie widzisz wiadomości – sprawdź folder Spam lub Oferty.
Ekstorcjonistyczna grupa Scattered LAPSUS$ Hunters opublikowała w sieci zestawy danych skradzionych z instancji Salesforce należących do wielu firm. Wyciek nastąpił po nieudanym wymuszeniu okupu – Salesforce publicznie zadeklarował, że nie zapłaci i nie będzie negocjować. Co istotne, sam rdzeń platformy Salesforce nie został naruszony; ataki uderzyły w klientów i ich integracje/aplikacje oraz ludzi (socjotechnika). Na liście ofiar wymieniono m.in. Albertsons, Engie Resources, Fujifilm, GAP, Qantas i Vietnam Airlines. Qantas informował wcześniej o potencjalnie ~5–6 mln dotkniętych klientów, a w przypadku Vietnam Airlines usługę Have I Been Pwned odnotowała ~7,3 mln kont.
Co? Wyciek części danych i groźby ujawnienia kolejnych – łącznie przestępcy chwalili się setkami milionów do ~1 mld rekordów z dziesiątek firm korzystających z Salesforce.
Jak? Dwie równoległe ścieżki:
Vishing/Help Desk → skłonienie pracowników do instalacji spreparowanego Salesforce Data Loader / uzyskania dostępu do kont.
Przejęte tokeny OAuth aplikacji Salesloft Drift → masowy eksport danych z obiektów Salesforce.
Stanowisko Salesforce: brak dowodów na kompromitację platformy; firma nie zapłaci okupu.
Działania organów ścigania: zaburzenie infrastruktury wymuszeniowej grupy przez FBI; mimo to część danych wyciekła.
Kontekst / historia / powiązania
Początek października przyniósł uruchomienie przez grupę własnego serwisu wyciekowego i eskalację gróźb wobec ~39 wskazanych firm-klientów Salesforce. Jednocześnie pojawiły się potwierdzone publikacje danych (m.in. Qantas, Vietnam Airlines). Wcześniejsze ostrzeżenia pochodziły od Google Threat Intelligence/Mandiant oraz FBI, które niezależnie opisały dwie aktywne komórki (UNC6040 i UNC6395) polujące na instancje Salesforce różnymi metodami.
Analiza techniczna / szczegóły luki
Ścieżka A – socjotechnika i Data Loader (UNC6040):
Atakujący używali vishingu (podszywanie się pod IT Service Desk), aby nakłonić pracowników do instalacji zmodyfikowanego Salesforce Data Loader lub udostępnienia danych logowania/MFA.
Po uzyskaniu dostępu następował eksport masowy rekordów (PII, dane programów lojalnościowych, profile użytkowników).
Ścieżka B – tokeny OAuth i integracje (UNC6395):
Kompromitacja tokenów OAuth aplikacji Salesloft Drift; w odpowiedzi 20 sierpnia unieważniono tokeny Drift i wyłączono aplikację w AppExchange.
Napastnicy wykonywali SOQL z kont zaufanych aplikacji, zliczając i pobierając obiekty Account, Opportunity, User, Case, oraz wyszukiwali w danych sekrety (np. AKIA, hasła, tokeny Snowflake).
GTIG/Mandiant opublikowali IOC (m.in. UA „Salesforce-Multi-Org-Fetcher/1.0”, zakres IP – również węzły Tor) i szczegółowe zapytania SOQL pomocne w detekcji.
Dlaczego ofiary są podatne?
Nadmierne uprawnienia Connected Apps („full access”), zbyt liberalne IP Relaxation, brak restrykcji API na profilach, niewłaściwy lifecycle tokenów i zbyt długie sesje.
Ryzyko wtórne (pivot): wyciek tajnych kluczy/API znalezionych w rekordach Salesforce → dalsze włamania do AWS/Snowflake i systemów SaaS.
Chaos informacyjny: część deklaracji grupy jest przesadzona lub niespójna (np. „nie możemy więcej wyciekać”), co utrudnia ocenę pełnej skali, ale potwierdzone wycieki już mogą skutkować incydentami fraudowymi.
Rekomendacje operacyjne / co zrobić teraz
1) Reagowanie i łagodzenie skutków (Salesforce/SecOps)
Przegląd logów: Event Monitoring (zwł. Connected App OAuth Usage, Login, API, UniqueQuery), anomalia w UA i adresach z IOC (Tor/Cloud).
Rotacja sekretów: natychmiast unieważnij i odtwórz tokeny OAuth, API keys, hasła powiązane z integracjami; usuń nadmiarowe refresh tokens.
Ogranicz Connected Apps: minimalne scopes, IP restrictions, wyłącz „API Enabled” poza uprzywilejowanymi Permission Sets; ustaw krótsze sesje i wymuś MFA.
Wyszukiwanie sekretów w danych: przeszukaj obiekty (Case, Attachment, Task, Chatter) pod kątem AKIA, password, Snowflake, URL-i logowania; zastosuj narzędzia typu TruffleHog.
2) Twardnienie procesów i ludzi
Help Desk Playbook: blokada realizacji żądań przez telefon/voice bez out-of-band potwierdzenia i weryfikacji tożsamości; zakaz dyktowania kodów MFA/SSO.
Dystrybucja oprogramowania: instalatory Salesforce Data Loader wyłącznie z oficjalnych źródeł, podpisy cyfrowe, listy dozwolonych hashy, EDR.
3) Komunikacja z klientami i monitoring nadużyć
Powiadomienie osób, których dotyczy sprawa; brand-monitoring pod kątem phish-kampanii podszywających się pod firmę/lojalności.
Dodatkowe kontrole ryzyka transakcji i weryfikacje zmian danych (adresy, telefony) w systemach lojalnościowych.
4) Współpraca z dostawcami i organami
Wykonaj zalecenia Salesforce/Salesloft; zgłoś ślady kompromitacji do FBI/CERT (flash TLP:CLEAR nt. UNC6040/UNC6395).
Różnice / porównania z innymi przypadkami
Nie jest to „klasyczny” ransomware: brak szyfrowania, czysta ekstorsja danych + presja medialna.
Atak na ekosystem SaaS: kruche punkty to integracje i tożsamość, a nie zero-day w samym Salesforce – odmiennie np. od incydentów z lukami w platformach on-prem.
Podsumowanie / kluczowe wnioski
Wyciek ujawnia strukturalną słabość: zaufane aplikacje i tokeny OAuth są „złotym kluczem” do danych CRM.
Wzmocnienie Connected Apps, monitoring SOQL, rotacja sekretów i dyscyplina operacyjna są dziś ważniejsze niż kiedykolwiek.
Organy ścigania potrafią zakłócić infrastrukturę wymuszeniową, ale skutki wycieku (phishing, oszustwa, przejęcia kont) pozostają i wymagają długofalowej obrony.
Źródła / bibliografia
SecurityWeek – przegląd publikacji danych (Albertsons, Engie, Fujifilm, GAP, Qantas, Vietnam Airlines) i kontekst 39 ofiar. (SecurityWeek)
Reuters – potwierdzenia dot. skali („~1 mld rekordów”), technik vishing oraz stanowiska Salesforce. (Reuters)
Google Cloud Threat Intelligence/Mandiant – techniczne szczegóły kampanii UNC6395 (Drift OAuth), SOQL, IOC, zalecenia. (Google Cloud)
Cybersecurity Dive – deklaracja Salesforce o odmowie płatności, rozdzielenie dwóch kampanii (Data Loader vs. Drift). (cybersecuritydive.com)
BankInfoSecurity/GovInfoSecurity – przebieg publikacji po zakłóceniu przez FBI, liczby dla Qantas/Vietnam Airlines. (BankInfoSecurity)
Newsletter – Zero Spamu
Dołącz by otrzymać aktualizacje bloga, akademii oraz ukryte materiały, zniżki i dodatkową wartość.
Dzięki!
Dzięki za dołączenie do newslettera Security Bez Tabu.
Wkrótce otrzymasz aktualizacje z bloga, materiały zza kulis i zniżki na szkolenia.
Jeśli nie widzisz wiadomości – sprawdź folder Spam lub Oferty.
Moralność potrafi usprawiedliwić krzywdę. Etyka stawia granice. To prowokacyjne stwierdzenie każe zastanowić się, czy zawsze to, co uznajemy za moralne, jest naprawdę słuszne. W życiu codziennym, a szczególnie w świecie cyberbezpieczeństwa, granica między tym co można, tym co wolno a tym co warto bywa rozmyta. Specjaliści ds. bezpieczeństwa dysponują ogromnymi możliwościami – potrafią w kilka chwil uzyskać dostęp do poufnych danych lub wyłączyć kluczowe systemy. Dlatego pytanie „czy to zrobić?” nie może kończyć się na „czy potrafię” ani nawet na „czy mam pozwolenie”. Musimy pójść o krok dalej i zapytać: czy warto to zrobić – czy to jest słuszne i odpowiedzialne?.
Prompty AI to nic innego jak instrukcje lub pytania, które zadajemy modelom sztucznej inteligencji (np. ChatGPT), aby uzyskać od nich użyteczną odpowiedź. Odpowiednio sformułowane prompty potrafią znacznie usprawnić pracę specjalistów ds. bezpieczeństwa informacji – od analizy zagrożeń, przez automatyzację żmudnych zadań, po cele edukacyjne. Nic dziwnego, że w ostatnim czasie ChatGPT stał się gorącym tematem w IT – znajduje coraz szersze zastosowanie, także w cybersecurity.
Call for Papers (w skrócie CfP) to otwarte wezwanie do nadsyłania propozycji wystąpień na konferencję lub inne wydarzenie branżowe. Organizatorzy ogłaszają CfP, aby zachęcić specjalistów do podzielenia się wiedzą – zarówno najnowszymi badaniami, jak i praktycznym doświadczeniem. W ramach CfP każdy chętny może przesłać streszczenie swojego potencjalnego wystąpienia, a komisja programowa wybiera z nadesłanych zgłoszeń te, które trafią do agendy wydarzenia.