Z tego tekstu dowiesz się:

• Co to jest ClickFix i gdzie na niego trafisz
• Jak dochodzi do infekcji komputera ofiary
• Czym grozi instalacja złośliwego oprogramowania
• Jak ochronić się przed techniką ClickFix

Co to jest ClickFix

Popularność ClickFix wynika wynika z banalnej prostoty i skuteczności. Atakujący nie muszą przekonywać ofiary do klasycznej instalacji złośliwego oprogramowania. Wystarczy, że skłonią ją do wykonania polecenia, które pobierze lub uruchomi złośliwy skrypt. Obserwowane przez nas scenariusze działają pod pozorem „udowodnij, że nie jesteś robotem”. Problem polega, jak to często bywa, na skali. Atakujący szukają słabo zabezpieczonych stron w internecie, aby podłożyć ClickFix. Właściciele stron często nie są świadomi swojego pośredniego udziału w dystrybucji takiego ataku. Zwykły użytkownik internetu ze swojej perspektywy po prostu odwiedza kolejną witrynę.

Jak działa ClickFix krok po kroku

Zainfekowanie komputera odbywa się poprzez wklejenie komendy w oknie „Uruchom” w systemie Windows, aplikacji PowerShell lub terminalu na komputerze z macOS. Cały mechanizm sprowadza się do pozornie niewinnego działania kopiuj-sklej. Polecenie jest napisane w sposób niezrozumiały dla większości użytkowników, ale jasny dla systemu operacyjnego. Kluczowym elementem tej metody jest fakt, że to użytkownik wykonuje polecenie, którego sam nie rozumie. System traktuje jednak takie działanie jako świadome. W efekcie mechanizmy bezpieczeństwa często nie reagują, a złośliwe oprogramowanie może zostać uruchomione bez większych przeszkód.

Jak się chronić przed techniką ClickFix

Najważniejsza zasada jest prosta: nie uruchamiaj komend, których nie rozumiesz i których źródła nie jesteś w stanie wiarygodnie zweryfikować. Dotyczy to terminala, PowerShella i okna „Uruchom”. Jeśli instalacja programu wymaga wklejenia nietypowego polecenia ze strony internetowej, warto zachować szczególną ostrożność lub ją opuścić. System macOs ma wbudowane mechanizmy ochronne przed atakiem ClickFix, pisaliśmy o tym w kwietniu. Analogiczne mechanizmy stosuje również Windows. Należy pamiętać, że nie dają one 100% ochrony. Korzystając z komputera, nie używaj konta administratora do codziennej pracy. Ograniczy to skutki ataku.

 W praktyce warto pamiętać o kilku zasadach:

• pobieraj aplikacje wyłącznie z oficjalnych stron lub zaufanych sklepów,
• sprawdzaj dokładnie adres strony, zanim skopiujesz jakąkolwiek komendę,
• nie ufaj instrukcjom, które wywierają presję lub obiecują „szybką naprawę”,
• przerwij działanie, jeśli strona każe wkleić polecenie do terminala bez jasnego wyjaśnienia,
• aktualizuj system operacyjny,
• nie korzystaj z konta administratora do codziennej pracy.

Podsumowanie

ClickFix nie opiera się na technicznej złożoności, lecz na skutecznej manipulacji. Sam w sobie jest bardzo prosty. Zdarza się, że możemy być narażeni na to zagrożenie podczas próby pobrania plików z sieci lub nawet przy potwierdzaniu CAPTCHA, czyli mechanizmu potwierdzającego, że jesteśmy człowiekiem przy wejściu na witrynę. Ten przypadek opisywaliśmy niespełna rok temu w artykule „Zainfekuj się sam„. Zmieniają się scenariusze tej socjotechniki, jednak każdy z nich wymaga od użytkownika wprowadzenia komendy do komputera.

Najprostsza zasada bezpieczeństwa brzmi więc: nie kopiuj i nie wklejaj poleceń, których nie rozumiesz.

The post Uwaga na ClickFix – nie wklejaj cudzych poleceń appeared first on CERT Orange.

Rządowe Centrum Bezpieczeństwa odpowiada m.in. za ostrzeganie mieszkańców przed zagrożeniami takimi jak: atak terrorystyczny, zagrożenia wojenne, awarie i zdarzenia naturalne. Pierwsze, pilotażowe alerty zaczęto wysyłać pomiędzy czerwcem a grudniem 2018 roku.

Jak działa Alert RCB?

Aktualna ścieżka jest ustalona na podstawie Rozporządzenia Rady Ministrów z dnia 31 sierpnia 2020 r. Dowiemy się z niego również, że Alert RCB wysyłany jest także do zagranicznych numerów na terenie, który obejmuje jeśli mają włączony roaming. Wtedy treść SMS-a jest w języku angielskim.

Krok 1
RCB na podstawie monitorowania zagrożeń podejmuje decyzję o wysłaniu alertu i przygotowuje tekst SMS (maksymalnie 306 znaków). Kolejnym krokiem jest określenie obszaru geograficznego (z dokładnością do powiatu), gdzie ma być wysłany lub podejmowana jest decyzja o wysyłce na obszar całej Polski.

Krok 2
Treść komunikatu jest przesyłana do operatorów oraz potwierdzona kanałem telefonicznym. Odbywa się poprzez dedykowane protokoły aby skrócić całą ścieżkę. Następnie operatorzy telekomunikacyjni potwierdzają zlecenie wysyłki SMSa w swoich systemach.

Krok 3
Operatorzy wysyłają SMS z alertem. W tym samym czasie realizują też wysyłkę pozostałych wiadomości SMS pomiędzy użytkownikami sieci.

Krok 4
Telefon odbiera SMS. Operatorzy niezwłocznie po zakończeniu wysyłki przygotowują dla Rządowego Centrum Bezpieczeństwa raport, do ilu kart SIM udało się dostarczyć wiadomość.

Dlaczego alert może przyjść z opóźnieniem?

Opóźnienia to jeden z elementów, który podnoszony jest w dyskusjach.

Kluczowym problemem jest infrastruktura. Na podstawie Alertu RCB nagle rośnie liczba wiadomości SMS do wysłania.

Problemem tej metody jest wysłanie po jednej wiadomości SMS do każdego urządzenia korzystającego z karty SIM lub eSIM. Jest to chybione, ponieważ SMS może przyjść np. na router bezprzewodowy. Mało kto odczyta taką wiadomość, nawet jeśli to wcześniej zobaczy ją na telefonie, a wysyłka i tak musi być zrealizowana.

Czym jest Cell Broadcast i jak różni się od Alertu RCB?

Wiadomość jest nadawana do wszystkich urządzeń w zasięgu stacji bazowej jednocześnie. Bez względu na sieć, z jakiej korzystają użytkownicy. Eliminuje to wszystkie problemy związane z przepustowością wiadomości SMS. Sam komunikat może zawierać maksymalnie 1395 znaków. Oznacza to, że dostarczenie wiadomości jest natychmiastowe

Agencja rządowa (w naszym przypadku Rządowe Centrum Bezpieczeństwa) opracowuje i przesyła do operatorów:
– treść wiadomości
– obszar, na którym ma być nadany komunikat
– konfigurację (ile razy ma być wysłany komunikat)

Jak to wygląda w systemie Android?
Telefon odbiera komunikat i rozpoznaje go jako komunikat Cell Broadcast. Android uruchamia natywną aplikację Cell Broadcast Receiver app i wyświetla alert na następujących zasadach:
– przerywa każdą używaną w danej chwili aplikację
– emituje dźwięk przypisany tylko dla tej aplikacji oraz uruchamia wibracje
– nie ma możliwości natychmiastowego wygaszenia lub pominięcia komunikatu

Jak to wygląda w systemie iOS?
iPhone, analogicznie do Androida odbiera komunikat (tutaj różni się tylko protokół). System iOS natychmiast uruchamia alert na następujących zasadach w centrum powiadomień:
– wiadomość pojawia się na całym ekranie
– emituje dźwięk alarmowy, również jeśli telefon jest wyciszony lub w trybie skupienia
– uruchamia wibracje

Które europejskie kraje korzystają z Cell Broadcast?

Następujące państwa w Europie wdrożyły już tę technologię: Holandia, Litwa, Rumunia, Grecja, Hiszpania, Francja, Niemcy, Dania, Chorwacja, Norwegia, Austria, Bułgaria, Łotwa, Luksemburg, Włochy, Słowenia, Wielka Brytania.

Co blokuje wdrożenie Cell Broadcast w Polsce?

O ile Alert RCB jest zgodny z wymogami UE dotyczącymi systemów ostrzegania ludności cywilnej, o tyle wdrożenie Cell Broadcast wymagałoby wprowadzenia zmian w legislacji. Ustaliłoby to normy i konkretne wytyczne, aby cały proces był spójny. Obecnie MSWiA pracuje nad ustawą wdrażającą Cell Broadcast. Nie ma jednak w tej sprawie żadnych konkretnych informacji. Jako kraj członkowski UE nie jesteśmy jednak objęci żadnymi terminami wdrożenia tej technologii, lub karami za jej brak.

Statystyki treści Alertów RCB.

Na stronie Rządowego Centrum Bezpieczeństwa można znaleźć historię wszystkich wysłanych alertów. Przeanalizowałem alerty z ostatnich 12 miesięcy. Było ich dokładnie 66. Poniżej na wykresie podzieliłem je na zagrożenia, przed którymi ostrzegana była ludność cywilna. Przeważają alerty związane z pogodą.

Podsumowanie

Cell Broadcast jest skuteczniejszym rozwiązaniem od wysyłania SMS-ów. Android i iOS wspierają ją natywnie. W większości regionów użytkownik nie może wyłączyć tych powiadomień na swoim urządzeniu. Wystarczy być w zasięgu jakiejkolwiek stacji bazowej. Alternatywą może być push w aplikacji np. mObywatel. To jednak wymagałoby zainstalowania jej na większej liczbie urządzeń niż obecnie. Dodatkowo wracamy do problemu przepustowości. W sytuacji kryzysowej, gdzie ludzie zaczną wysyłać filmy i zdjęcia z danego obszaru pojawi się problem z przepustowością internetu. To zaś może ograniczyć dostarczenie powiadomień na danym obszarze.

The post Jak działa Alert RCB i dlaczego Polska wciąż nie korzysta z Cell Broadcast? appeared first on CERT Orange.

Zaawansowane zagrożenia

Half-click zamiast phishingu. Rosyjskie grupy APT wykorzystują podatności w webmailach

• Ataki typu half-click pozwalają ominąć klasyczny model phishingu, ponieważ do kompromitacji może wystarczyć samo otwarcie wiadomości w podatnym webmailu.
• TA458 i TA488, grupy powiązane z Rosją, wykorzystywały tę technikę przeciwko użytkownikom Roundcube, Zimbry i OWA.
• Cele kampanii obejmowały m.in. organizacje europejskie, w tym sektor telekomunikacyjny.

Half-click 

Przez lata powodzenie kampanii e-mailowych zależało przede wszystkim od skuteczności socjotechniki i nakłonienia użytkownika do kliknięcia linku czy pobrania załącznika. Sytuacja zaczęła się zmieniać wraz z wykorzystaniem podatności w platformach webmail, które pozwalają przeprowadzić atak bez konieczności dodatkowej interakcji użytkownika. 

Mechanizm określany jako half-click ogranicza wymaganą interakcję użytkownika do otwarcia wiadomości lub, zależnie od klienta, jej podglądu dzięki wykorzystaniu podatności, najczęściej typu cross-site scripting (XSS). Złośliwy HTML jest przetwarzany przez podatny webmail, a następnie uruchamia JavaScript w kontekście aktywnej sesji ofiary. Skrypt uzyskuje w ten sposób dostęp do funkcji i danych dostępnych dla zalogowanego użytkownika. Brak linku, załącznika czy wyraźnego wezwania do działania utrudnia zarówno rozpoznanie zagrożenia przez odbiorcę, jak i wykrycie go przez mechanizmy skupione głównie na klasycznym phishingu. 

Choć nazwa może kojarzyć się z exploitami zero-click, różnica jest istotna. W atakach zero-click ofiara nie wykonuje żadnej akcji – podatny system sam przetwarza złośliwą treść. W przypadku half-click użytkownik musi otworzyć wiadomość, ale na tym jego udział się kończy. Nie klika linków, nie pobiera załączników ani nie uruchamia makr. 

Od Roundcube, przez Zimbrę, do OWA 

Proofpoint opisał w ostatnim czasie trzy kampanie wykorzystujące technikę half-click. Mimo że używane były różne podatności i różne platformy, sposób działania pozostawał bardzo podobny z jednym celem: dostęp do skrzynki pocztowej.  

Pierwsza z grup, TA458, prowadziła operację RoundPress przeciwko kilku platformom webmailowym: Roundcube, Zimbrze  mDaemon, SOGo i Kerio Webmail. Wykorzystywany payload SpyPress służył przede wszystkim do kradzieży korespondencji, kontaktów i danych uwierzytelniających. W przypadku Roundcube operatorzy łączyli exploit XSS z podatnością CVE-2025-49113, uzyskując możliwość wykonania kodu na serwerze i wdrożenia mechanizmów trwałego dostępu. 

Natomiast TA488 wykorzystywała odrębną podatność w Zimbrze — CVE-2025-66376 — oraz payload ZimReaper. Po otwarciu wiadomości narzędzie pozyskiwało dane dostępne w sesji użytkownika, w tym hasła zapisane przez przeglądarkę, kody zapasowe 2FA, kontakty i wiadomości. Tworzyło również hasło aplikacyjne „ZimbraWeb”, zapewniające dalszy dostęp przez IMAP, POP3 lub SMTP.  

W kolejnej kampanii TA488 przeniosła ten model na Outlook Web Access, wykorzystując CVE-2026-42897 i implant OWAReaper. OWAReaper zapewniał utrzymanie dostępu zarówno w artefaktach przeglądarki, jak i przez zmianę uprawnień folderów skrzynki po stronie Exchange.  

TA458 jest oceniana jako prawdopodobnie powiązana z rosyjskim wywiadem wojskowym i działająca pod kierownictwem GRU. W przypadku TA488 pierwotna analiza wykazała podobieństwa do grupy Void Blizzard, znanej również jako Laundry Bear. Związek ten został następnie potwierdzony we współpracy z partnerami rządowymi Stanów Zjednoczonych a dostępne informacje wskazują, że TA488 działa jako prywatny wykonawca na rzecz rosyjskiego wywiadu. 

Cele ataków 

Choć znaczna część kampanii była wymierzona w organizacje związane z Ukrainą, administrację publiczną czy sektor obronny, lista ofiar była znacznie szersza. Obserwowano również działania skierowane przeciwko organizacjom z Europy. Wśród atakowanych podmiotów znalazły się przedsiębiorstwa z sektora telekomunikacyjnego, finansowego, lotniczego i hotelarskiego. Pokazuje to, że zainteresowanie rosyjskich grup nie ogranicza się wyłącznie do administracji państwowej, ale obejmuje również podmioty dysponujące wartościowymi informacjami lub odgrywające istotną rolę w funkcjonowaniu państwa i gospodarki. 

Temat ma znaczenie również z perspektywy polskich organizacji. Zimbra jest popularnym rozwiązaniem wśród części polskich przedsiębiorstw i instytucji, natomiast Outlook Web Access pozostaje powszechnym sposobem dostępu do poczty w środowiskach Microsoft Exchange. 

Patrząc szerzej

Wykorzystanie podatności w webmailach pokazuje, że poczta elektroniczna pozostaje jednym z najcenniejszych celów dla grup prowadzących operacje cyberwywiadowcze. Przejęcie skrzynki pocztowej zapewnia dostęp nie tylko do treści wiadomości, ale również do informacji o strukturze organizacji, relacjach z partnerami oraz bieżących projektach. Dla grup APT dane te mogą być punktem wyjścia do dalszych działań, w tym przygotowania ukierunkowanych wiadomości phishingowych oraz identyfikacji osób mających dostęp do istotnych zasobów. 

Więcej informacji:  
https://www.proofpoint.com/us/blog/threat-insight/cleaning-out-inboxes-ta488-comes-outlook-another-half-click-exploit 
https://www.proofpoint.com/us/blog/threat-insight/ta458-roundpress-exploits 
https://www.proofpoint.com/us/blog/threat-insight/ta488-targets-zimbra-mailservers-half-click-exploits 

Metodyka

Nowe nazwy, stary problem. Google zmienia sposób nazywania grup APT

• Google zmienia sposób nazywania grup APT, zastępując dotychczasowe konwencje Mandiant i TAG jednym systemem Google Threat Intelligence. 
• APT28 staje się LAKE RELIC, APT29 – ICE RELIC, a APT41 – SPIRE CASTLE – nowe nazwy mają być łatwiejsze do zapamiętania i jednocześnie wskazywać na atrybucję aktora.
• Nowa konwencja porządkuje taksonomię Google, ale nie rozwiązuje problemu wielu nazw w CTI – dla analityków oznacza na razie kolejny system aliasów, który trzeba mapować do już istniejących.

Nazewnictwo grup APT od lat przypomina język, w którym na określenie tej samej rzeczy funkcjonuje kilka, a czasami kilkanaście różnych słów. Microsoft ma Midnight Blizzard, CrowdStrike – Cozy Bear, a Mandiant przez lata posługiwał się oznaczeniem APT29. Dla osób zajmujących się Cyber Threat Intelligence nie jest to niczym nowym. Mapowanie aliasów stało się po prostu częścią codziennej pracy analitycznej. Teraz do tego słownika trzeba będzie dopisać kolejne pojęcia.

24 lipca Google Threat Intelligence Group (GTIG) ogłosił wprowadzenie nowego, ujednoliconego systemu nazewnictwa aktorów zagrożeń. Zmiana jest konsekwencją połączenia dwóch rozwijanych wcześniej niezależnie modeli: systemu Mandiant oraz Google Threat Analysis Group (TAG). W ramach GTIG mają one zostać zastąpione wspólną taksonomią wykorzystywaną zarówno wewnętrznie, jak i w publicznych raportach Google. 

Koniec z APT? Nadchodzą CASTLE, RELIC i NEPTUNE 

Nowy system opiera się na dwuczłonowych kryptonimach. Pierwszy człon ma identyfikować konkretnego aktora i, tam gdzie jest to możliwe, nawiązywać do nazwy znanej już z wcześniejszych publikacji. Jeśli takiego określenia nie ma, termin jest generowany losowo, a następnie weryfikowany przez analityków GTIG. 

Znacznie ciekawszy jest drugi człon nazwy. Pełni on funkcję klasyfikacyjną i wskazuje na pochodzenie lub charakter aktywności danego klastra. Google przypisał poszczególnym kategoriom charakterystyczne słowa: 

• CASTLE – aktorzy powiązani z Chińską Republiką Ludową,
• ION – Iran,
• NEPTUNE – Korea Północna,
• RELIC – Rosja,
•  COMET – grupy cyberprzestępcze.

W efekcie dobrze znane oznaczenia zaczynają otrzymywać zupełnie nowe odpowiedniki. APT28 staje się LAKE RELIC, APT29 – ICE RELIC, Sandworm/APT44 – SANDWORM RELIC, APT41 – SPIRE CASTLE, natomiast FIN7 otrzymuje nazwę WILD COMET. 

Pomysł ma pewną intuicyjną zaletę. Widząc po raz pierwszy nazwę RIVER CASTLE, analityk nie musi jeszcze wiedzieć, że wcześniej była to APT15, aby z samej konstrukcji nazwy odczytać, że według GTIG jest to aktor powiązany z Chinami. Podobnie końcówka RELIC natychmiast wskazuje na rosyjską atrybucję, a COMET na charakter cyberprzestępczy. 

Według Google właśnie taki kontekst ma być jedną z najważniejszych zalet nowego rozwiązania. Sekwencyjne oznaczenia w rodzaju APT1 wymagają zapamiętywania znaczenia kolejnych numerów, podczas gdy nowy system ma być bardziej intuicyjny i łatwiejszy do wykorzystania przez obrońców. 

Co istotne, nie wszystkie dotychczasowe elementy systemu Mandiant znikną. Google zapowiedział dalsze stosowanie oznaczenia UNC (Uncategorized) wobec klastrów znajdujących się na wczesnym etapie analizy. Dotychczasowe nazwy mają również pozostać indeksowane i wyszukiwalne w Google Threat Intelligence, razem z aliasami innych dostawców oraz mapowaniem do MITRE ATT&CK. Proces migracji będzie stopniowy – na początku objął kilkadziesiąt najbardziej aktywnych grup. 

Na poziomie technicznym trudno więc mówić o prostym wyrzuceniu starego słownika. Google próbuje raczej zbudować nad nim nową warstwę. 

Jeden aktor, wiele nazw  

Z perspektywy społeczności Cyber Threat Intelligence problemem nigdy nie był wyłącznie fakt, że nazwy takie jak APT28 czy UNC4057 są trudniejsze do zapamiętania niż LAKE RELIC czy COLD RELIC. Problemem jest przede wszystkim fragmentacja systemów nazewnictwa. 

Każdy z dużych dostawców Threat Intelligence posiada własną telemetrię, źródła informacji, kryteria grupowania aktywności i poziomy pewności atrybucji. W rezultacie ten sam przeciwnik może występować w raportach różnych organizacji pod wieloma nazwami. Nie oznacza to przy tym, że wszystkie te nazwy są prostymi synonimami. 

To bardzo ważne rozróżnienie. Dwa zespoły badawcze mogą obserwować częściowo pokrywające się klastry infrastruktury, malware i TTP, ale dysponować różnym poziomem widoczności. Jeden może uważać je za działalność jednej grupy, drugi zachować dwa oddzielne klastry do momentu uzyskania mocniejszych dowodów. 

Google sam zwraca uwagę na ten problem, przyznając, że bezpośrednie porównywanie aktorów śledzonych przez różne organizacje jest trudne, ponieważ żadna z nich nie posiada identycznej widoczności krajobrazu zagrożeń. I właśnie dlatego niezależne systemy nazewnictwa mają metodologiczny sens.  

Alias w CTI nie zawsze oznacza więc równoważność.

Problemem nie jest istnienie wielu konwencji 

Atrybucja w CTI nie przypomina katalogu, w którym istnieje jeden obiektywnie zdefiniowany aktor i jedna poprawna nazwa. Jest to proces analityczny. Nowe dane mogą prowadzić do łączenia wcześniej oddzielnych klastrów, ich rozdzielania albo zmiany poziomu pewności co do ich powiązania z określonym państwem, organizacją czy znaną wcześniej grupą. 

Dlatego trudno postulować stworzenie jednego globalnego słownika grup APT. Paradoksalnie mogłoby to prowadzić do utraty części informacji analitycznej. Jeżeli dwie organizacje obserwują nieco inny zakres działalności przeciwnika, używanie odrębnych nazw może być bardziej poprawne niż przedwczesne uznanie obu zbiorów aktywności za jedną grupę. 

Mandiant przez ponad dekadę zbudował jeden z najbardziej rozpoznawalnych modeli atrybucji w branży. Oznaczenia APT, FIN czy później UNC weszły do języka społeczności CTI. Znajdziemy je w tysiącach raportów, platformach Threat Intelligence, regułach detekcyjnych, repozytoriach IOC, prezentacjach, artykułach naukowych i wewnętrznych bazach wiedzy organizacji. 

Zmiana konwencji nie powoduje, że ten historyczny słownik nagle znika. APT28 nadal będzie APT28 w tysiącach wcześniejszych analiz. Jednocześnie będzie LAKE RELIC w nowych materiałach Google i będzie funkcjonował pod kolejnymi nazwami u innych dostawców. Z punktu widzenia całego ekosystemu nie następuje więc redukcja liczby nazw. 

 Uproszczenie czy rebranding? 

Z perspektywy Google decyzja jest zrozumiała. Połączenie Mandiant i TAG w ramach Google Threat Intelligence Group oznaczało konieczność scalenia dwóch niezależnych systemów śledzenia przeciwników. Stworzenie wspólnej taksonomii jest naturalnym elementem takiej integracji. 

Nowy system ma również zalety. Nazwy są bardziej charakterystyczne, zawierają dodatkowy kontekst i mogą być łatwiejsze do zapamiętania niż kolejne numery APT. Trudniej jednak zgodzić się z tezą, że sama zmiana konwencji przynosi większą klarowność całemu ekosystemowi CTI. Dla społeczności analityków oznacza ona przynajmniej początkowo coś odwrotnego: konieczność nauczenia się kolejnego słownika i mapowania go do nazw funkcjonujących od wielu lat. 

Dlatego warto oddzielić dwie kwestie: uproszczenie wewnętrznego modelu Google Threat Intelligence od uproszczenia sposobu, w jaki cała społeczność CTI komunikuje wiedzę o przeciwnikach. Pierwsze prawdopodobnie właśnie następuje. Drugie pozostaje nierozwiązanym problemem.

Patrząc szerzej

Dyskusja o nowych nazwach Google pokazuje szerszy problem: być może w CTI zbyt mocno przywiązaliśmy się do samej nazwy aktora.  W CTI nazwa grupy jest tylko etykietą – o wiele ważniejsza pozostaje analiza TTP (Tactics, Techniques, and Procedures), infrastruktury oraz kontekstu operacyjnego. 

Wartość nowej konwencji nie będzie zależała od tego, czy LAKE RELIC łatwiej zapamiętać niż APT28. Znacznie ważniejsze będzie to, czy system pomoże analitykom korelować informacje, rozumieć zakres poszczególnych klastrów i właściwie interpretować poziom pewności atrybucji. 

Bo największym problemem nazewnictwa w CTI nigdy nie był brak dobrych nazw. Problemem jest to, że mamy ich zbyt wiele – i nie zawsze oznaczają dokładnie to samo

Więcej informacji:  
https://cloud.google.com/blog/topics/threat-intelligence/updated-cyber-threat-actor-naming-system 

Podatności

CosmosEscape – ucieczka z bazy

• Analitycy firmy Wiz opisali podatność w Azure Cosmos DB pozwalającą na ominięcie izolacji pomiędzy tenantami na platformie SaaS. Badacze uzyskali dostęp do Master Key umożliwiającego dostęp do każdego konta w usłudze.
• Nie były konieczne specjalne uprawnienia ani błędy w konfiguracji po stronie klienta. Dostęp odbywał się za pośrednictwem Gremlin API, ale jego skutki wykraczały daleko poza tę usługę. 
• Microsoft docenił pracę badaczy i odpowiedzialne podejście do publikacji informacji o podatności. Mimo wszystko warto podkreślić odpowiedzialność dostawców usług SaaS za bezpieczeństwo oferowanych platform i znikome możliwości ograniczania ryzyka ze strony klientów.

Podatność CosmosEscape, opisana przez badaczy Wiz, ujawniła krytyczny problem w architekturze Azure Cosmos DB, pozwalający na przełamanie izolacji pomiędzy tenantami w usłudze. Badacze wykazali możliwość uzyskania pełnej kontroli nad dowolnym kontem Cosmos DB bez posiadania uprawnień i niezależnie od konfiguracji bezpieczeństwa zastosowanej przez właściciela zasobu. Scenariusz ataku prowadził do pozyskania kluczy administracyjnych umożliwiających odczyt, modyfikację i usuwanie danych przechowywanych w bazach innych organizacji. Z punktu widzenia bezpieczeństwa platform multi-tenant to jedna z najpoważniejszych podatności, ponieważ narusza podstawowe założenie separacji danych pomiędzy klientami korzystającymi z tej samej infrastruktury. 

Punktem wejścia był interfejs Gremlin API, przeznaczony do obsługi grafowych modeli danych. Analiza przeprowadzona przez Wiz wykazała, że sposób przetwarzania zapytań umożliwiał wykorzystanie mechanizmów refleksji środowiska .NET. Odpowiednio przygotowane zapytanie pozwalało wywoływać klasy i metody, które nie powinny być dostępne z poziomu Gremlina. W rezultacie możliwe było wykonanie kodu poza sandboxem i uzyskanie dostępu do DB Gateway, usługi wykonującej zapytania w imieniu klientów. To ewidentny przykład naruszenia granicy pomiędzy kodem użytkownika a infrastrukturą platformy. 

Po uzyskaniu możliwości wykonania kodu badacze skoncentrowali się na analizie środowiska uruchomieniowego. W pamięci procesu znajdowały się informacje wykorzystywane przez wewnętrzne mechanizmy uwierzytelniania Azure Cosmos DB, w tym master key odpowiedzialny za generowanie kluczy dostępowych. Pozyskanie tego sekretu umożliwiało wygenerowanie prawidłowych kluczy Primary Key dla dowolnego konta usługi. Ponieważ klucze te zapewniają pełne uprawnienia administracyjne, dalszy dostęp do danych odbywał się przy użyciu standardowych interfejsów API i nie wymagał już wykorzystywania samej podatności. 

Szczególnie istotnym aspektem CosmosEscape był zasięg konsekwencji wykorzystania podatności. Chociaż wektor wejściowy wykorzystywał Gremlin API, skutki kompromitacji nie ograniczały się do użytkowników korzystających z grafowych baz danych. Po uzyskaniu możliwości generowania kluczy administracyjnych atakujący mógł uzyskać dostęp do kont wykorzystujących pozostałe interfejsy oferowane przez Azure Cosmos DB, w tym SQL API, MongoDB API, Cassandra API oraz Table API. Oznaczało to, że podatność dotyczyła centralnych mechanizmów zarządzania usługą, a nie pojedynczego modułu odpowiedzialnego za obsługę konkretnego modelu danych. 

W opublikowanej analizie Wiz zwrócił uwagę, że cały proces nie wymagał wykorzystania podatności po stronie klienta ani błędnej konfiguracji środowiska. Atak był możliwy wobec domyślnie skonfigurowanych instancji usługi, ponieważ wykorzystywał wyłącznie błędy znajdujące się w infrastrukturze zarządzanej przez Microsoft. Z tego względu standardowe mechanizmy ochrony, takie jak filtrowanie ruchu sieciowego, prywatne endpointy, segmentacja sieci czy poprawnie skonfigurowane uprawnienia użytkowników, nie eliminowały ryzyka.  

Po zgłoszeniu podatności Microsoft uniemożliwił wykorzystanie opisanego wektora ataku oraz przeprowadził zmiany w komponentach odpowiedzialnych za przetwarzanie zapytań i zarządzanie kluczami dostępowymi. Według informacji przekazanych przez firmę analiza logów telemetrycznych nie wykazała oznak wykorzystania podatności przez osoby nieuprawnione (poza badaczami z Wiz) przed jej usunięciem. Sam proces reakcji pokazuje jednak, jak dużą rolę odgrywa odpowiedzialne ujawnianie podatności oraz ścisła współpraca pomiędzy analitykami bezpieczeństwa a dostawcami usług chmurowych. 

Patrząc szerzej

CosmosEscape jest przykładem trudności związanych z oceną bezpieczeństwa usług SaaS. Klient ma możliwość monitorowania własnych zasobów i konfiguracji, jednak nie dysponuje narzędziami pozwalającymi zweryfikować sposób implementacji mechanizmów izolacji tenantów, zarządzania kluczami czy ochrony środowiska. W konsekwencji podatności występujące w tej warstwie pozostają niewidoczne aż do momentu ich wykrycia przez dostawcę lub niezależnych badaczy.   

Przy korzystaniu z usług SaaS i PaaS poziom bezpieczeństwa zależy nie tylko od poprawnej konfiguracji po stronie klienta, ale również od jakości zabezpieczeń i procesów po stronie operatora platformy. Z perspektywy klient ocena bezpieczeństwa opiera się więc w pełni na zaufaniu do dostawcy i oferowanych przez niego rozwiązań. Warto wziąć to pod uwagę w przypadku analizy ryzyka i weryfikacji możliwości jego mitygacji. 

Więcej informacji:
https://www.wiz.io/blog/cosmosescape-taking-over-every-database-in-azure-cosmos-db  

The post Krajobraz Zagrożeń – 03.08.2026 appeared first on CERT Orange.

SMS-y, które trafiły do analizy CERT Orange Polska, przychodzą z nadpisu:

• MOPS

Skrót to m.in. akronim oznaczający Miejski Ośrodek Pomocy Społecznej, co ma dodatkowo uwiarygodnić przekaz.

Treść wiadomości to m.in. (pisownia oryginalna):

• Informujemy, ze Twoj wniosek mieszkaniowy wymaga uzupelnienia danych. Zaktualizuj informacje, aby kontynuowac procedure. [LINK]
• Administracja Miejska: Aktualizacja danych do wniosku mieszkaniowego jest wymagana. Uzupelnij formularz, aby zakonczyc proces. [LINK]

W analizowanych przypadkach link w SMS-ie prowadził pod adres skracacza hxxps://did[.]li/[5-znakowy ciąg], docelowo zaś pod adres hxxps://mieszkanie-dla-ciebie.buzz/pl.

Warto jednak pamiętać, że oszuści mogą używać innego nadpisu; może się też zdarzyć, iż wiadomości będą wysyłane ze zwykłego numeru. Możliwe jest też użycie innego serwisu do skracania linków oraz – po zablokowaniu adresu docelowego – innej strony. Ma to z resztą miejsce, ponieważ jest to kolejna odsłona tej kampanii.

Wyłudzają nie tylko dane karty – również PESEL i nr dowodu

Zazwyczaj w tego typu kampaniach celem oszustów jest wyłudzenie danych karty płatniczej ofiary. To cel także tej kampanii, czego dowodzi fakt mającego na nas czekać dofinansowania. Oszuści chcą Cię przekonać do podania w tym celu szczegółowych danych karty płatniczej (w tym daty ważności i kodu CVC/CVV), jednak CERT Orange Polska po raz kolejny przypomina, że:

Dane karty płatniczej podajemy w celu zakupu, a nie otrzymania pieniędzy!

Sytuacje odwrotne są tak rzadkie, że bezpiecznie jest po prostu założyć, że jeśli ktoś twierdzi, że dane Twojej karty są mu potrzebne, by zapłacić Ci pieniądze – kłamie.

O ile jednak podanie danych karty spowoduje, że oszust wyczyści nam konto, dużo bardziej niebezpieczna sytuacja ma miejsce na wcześniejszym etapie. Pod pozorem uzupełnienia danych niezbędnych do „weryfikacji uprawnienia do wsparcia w ramach rządowych programów mieszkaniowych” formularz prosi o podanie nie tylko adresu e-mail, numeru telefonu komórkowego (jeśli je podasz – szykuj się na kolejne phishingi), ale również:

• numeru dowodu osobistego
• PESEL

Te dwie ostatnie dane wpadające w ręce oszustów to największe potencjalne ryzyko w tym schemacie! Dysponując nimi przestępcy mogą przejąć Twoją tożsamość i podszyć się pod Ciebie w szeregu sytuacji, m.in.:

• wyłudzić kredyt/pożyczkę/chwilówkę
• założyć konto bankowe
• zaciągnąć zobowiązania w firmie telekomunikacyjnej
• zarejestrować działalność gospodarczą
• zawrzeć umowę cywilno-prawną
• wypożyczyć samochód (i spowodować w nim szkody)
• wyłudzić inne świadczenia

I jeszcze sporo innych złośliwych działań.

Jak nie dać się oszukać? Co zrobić, po wpisaniu danych?

Przede wszystkim – jeśli jeszcze tego nie zrobiłeś/aś – zastrzeż swój PESEL np. w aplikacji mObywatel. Przy okazji pamiętaj o odnowieniu certyfikatów. Więcej na ten temat znajdziesz tutaj. To uniemożliwi wykorzystanie Twojego numeru PESEL przez osoby niepowołane.

Jak nie dać się oszukać?

• do SMS-ów z linkami podchodź z bardzo ograniczonym zaufaniem
• upewnij się, czy strona, którą odwiedzasz, jest na pewno witryną (w opisywanym przypadku) administracji publicznej; pamiętaj, że adresy takich stron zawsze kończą się na gov.pl

Dodatkowo, by uniknąć konsekwencji nieuwagi:

• ustaw niskie limity kwotowe dla karty, której używasz do płatności w sieci – wtedy nawet jeśli jej dane trafią do oszusta, obciąży kartę do poziomu limitu
• jeśli nie przeprowadzasz żadnej transakcji a na Twój telefon przyjdzie SMS z kodem do potwierdzenia transakcji lub aplikacja banku wygeneruje kod push z monitem – natychmiast skontaktuj się z bankiem!

Ty lub ktoś z Twoich bliskich dał się oszukać? Taką transakcję kartową zgłoś reklamacją poprzez chargeback, szczegóły opisujemy w tym artykule.

Jeśli trafi do ciebie taki lub podobny SMS, prześlij go na nr 508 700 900. W ten sposób chronisz nie tylko siebie ale również innych internautów.

The post Fałszywe SMS-y o wniosku mieszkaniowym. Kolejny etap kampanii wyłudzającej dane osobowe i kart płatniczych. appeared first on CERT Orange.

mObywatel to aplikacja mobilna oferująca dostęp do elektronicznych dokumentów (m.in. dowodu osobistego, legitymacji studenckiej, czy prawa jazdy) służąca również jako mechanizm logowania do urzędów on-line oraz cyfrowych usług. Wg. najnowszych danych Ministerstwa Cyfryzacji korzysta z niej nawet 12 mln Polaków. Teraz – najpóźniej do 5 sierpnia – muszą zaktualizować certyfikaty dokumentów.

Na czym polega aktualizacja? To odnowienie certyfikatów dokumentów czyli przedłużenie ich daty ważności. Wystarczy zalogować się do aplikacji przed 5 sierpnia, a certyfikaty zaktualizują się same. Jeśli korzystasz z niej regularnie – prawdopodobnie już tak się stało. Jeśli od dawna nie używasz aplikacji, zaloguj się do niej samodzielnie. Zrób to bezpośrednio w telefonie. Unikaj korzystania z linków otrzymanych w SMS-ach lub e-mailach.

Dlaczego musisz być ostrożnym właśnie teraz?

Cyberprzestępcy chętnie wykorzystują głośne i masowe tematy do przygotowywania kampanii phishingowych. Aktualizacja certyfikatów w mObywatelu spełnia oba te warunki: dotyczy wielu osób i ma konkretny termin. W efekcie ryzyko pojawienia się przygotowanej pod to kampanii phishingowej jest bardzo wysokie. Sieciowi przestępcy dowiedli tego m.in. w terminie rozliczania podatku PIT podszywając się pod e-Urząd Skarbowy, czy w czasie, gdy rozpoczęły się wakacje – pod Booking.com.

Przypominamy raz jeszcze: jeśli korzystasz z mObywatela regularnie, certyfikaty Twojego dowodu osobistego lub legitymacji szkolnej (w aplikacji mObywatel Junior) z dużym prawdopodobieństwem już zaktualizowały się automatycznie. Co stanie się jeśli nie logowałaś/eś się przez długi okres do mObywatela i nie zrobisz tego przed 5 sierpnia? Wtedy trzeba się nimi ponownie zalogować, szczegóły znajdziesz na poświęconej aktualizacji certyfikatów stronie rządowej.

Jak może wyglądać próba oszustwa „na mObywatel”?

Typowy schemat tego typu kampanii to próba wykradzenia danych logowania do banku. Dlatego może się zdarzyć, że na docelowej stronie opcje logowania przy użyciu Profilu Zaufanego, e-Dowodu, czy aplikacji mObywatel pozostaną wyszarzone z powodu rzekomych problemów, czy awarii.

Fałszywa wiadomość może:

• informować o konieczności pilnej aktualizacji certyfikatu,
• zawierać link prowadzący do strony przypominającej serwis rządowy,
• sugerować problem z dokumentem lub dostępem do usług,
• nakłaniać do zalogowania się poza oficjalną aplikacją,
• przekierowywać do fałszywego formularza logowania.

Zwróć uwagę na takie sygnały ostrzegawcze jak:

• SMS lub e-mail informujący o pilnej aktualizacji w mObywatelu,
• presja czasu i wezwanie do natychmiastowego działania,
• link prowadzący do adresu tylko przypominającego oficjalną stronę,
• strona utrzymana w kolorystyce serwisów rządowych, ale prosząca o dodatkowe dane,
• komunikaty o rzekomej awarii lub niedostępności oficjalnych metod logowania,
• prośba o podanie danych logowania po kliknięciu w link z wiadomości.

Warto pamiętać, że nazwa nadawcy SMS-a może być myląca. Sama obecność słowa przypominającego „mObywatel” lub „gov” nie przesądza o autentyczności wiadomości.

Co robić, jeśli otrzymasz podejrzaną wiadomość?

• nie klikaj linku,
• nie podawaj danych logowania,
• otwórz aplikację mObywatel samodzielnie i sprawdź komunikaty bezpośrednio w niej,
• jeśli masz wątpliwości, sprawdź informacje na oficjalnych kanałach administracji publicznej.

Najważniejsza zasada jest prosta: aktualizację i inne działania związane z aplikacją mObywatel wykonuj tylko w samej aplikacji, nigdy po kliknięciu w link z SMS-a lub e-maila.

A jeśli trafi do Ciebie taka wiadomość – prześlij ją dalej ze swojego telefonu do CERT Orange Polska na nr 508 700 900. W ten sposób ochronisz również innych użytkowników!

The post Oszuści mogą podszywać się pod mObywatel. Sprawdź, jak rozpoznać fałszywy SMS i chronić swoje dane. appeared first on CERT Orange.

Moje doświadczenia jako analityka Incident Response, oparte na kilkunastu analizach forensics realizowanych po rzeczywistych incydentach bezpieczeństwa, doprowadziły mnie do dość prostego wniosku: wielu z tych ataków można było uniknąć, a przynajmniej znacząco utrudnić ich przeprowadzenie i ograniczyć skutki.

W analizowanych przypadkach bardzo często niejedna krytyczna podatność czy pojedynczy błąd prowadziły do pełnej kompromitacji środowiska. Znacznie częściej był to ciąg pozornie niezależnych problemów: brak MFA, nieaktualne systemy, zbyt szerokie uprawnienia, płaska sieć, współdzielone konta administratorów, niewystarczający monitoring czy brak możliwości szybkiej izolacji zaatakowanych systemów.

Każdy z tych elementów osobno nie musi prowadzić do poważnego incydentu. Połączone tworzą jednak ścieżkę, którą atakujący może wykorzystać do przejścia od początkowego dostępu do przejęcia kolejnych systemów, eskalacji uprawnień, eksfiltracji danych i ostatecznie wdrożenia ransomware.

Nie ma jednego pomysłu na ochronę

Oczywiście każdy incydent jest inny. Różne są możliwości, motywacje i poziom determinacji atakujących. Nie istnieje zestaw zabezpieczeń, który zagwarantuje, że organizacja nigdy nie zostanie skutecznie zaatakowana.

Jednocześnie większość obserwowanych przeze mnie ataków nie była zbiorem przypadkowych działań. Atakujący korzystają ze sprawdzonych narzędzi, technik i schematów postępowania. Uzyskują początkowy dostęp, prowadzą rekonesans środowiska, zdobywają kolejne uprawnienia, przemieszczają się pomiędzy systemami, przejmują konta uprzywilejowane, wyłączają mechanizmy bezpieczeństwa, kopiują dane, a następnie uruchamiają ransomware.

To dobra wiadomość dla obrońców. Jeżeli znamy typowe etapy ataku, możemy budować zabezpieczenia w taki sposób, aby na każdym z nich atakujący napotykał kolejną przeszkodę.

Nie chodzi przy tym o znalezienie jednego produktu czy technologii, która „zatrzyma ransomware”. Skuteczna ochrona powinna składać się z wielu wzajemnie uzupełniających się warstw – od wiedzy o posiadanych zasobach i właściwej architektury sieci przez zarządzanie tożsamością i ochronę systemów końcowych, aż po monitoring, detekcję, reagowanie na incydenty i możliwość odtworzenia środowiska.

Poniższe rekomendacje są zbiorem praktycznych działań, które mogą pomóc organizacji zmniejszyć prawdopodobieństwo skutecznego ataku ransomware, utrudnić działania napastnika oraz ograniczyć skalę incydentu, jeśli do kompromitacji mimo wszystko dojdzie.

Nie jest to lista gwarantująca pełną odporność na ransomware. Jest to raczej próba odpowiedzi na bardzo praktyczne pytanie:

Co możemy zrobić dzisiaj, aby jutro atakujący miał znacznie trudniejsze zadanie?

Warstwa 1. Architektura i ograniczenie powierzchni ataku

Pierwszą linią obrony jest wiedza o własnym środowisku oraz właściwie zaprojektowana infrastruktura. Nie powinniśmy zakładać wyłącznie, że uda nam się uniemożliwić uzyskanie początkowego dostępu. Znacznie bezpieczniejszym założeniem jest przyjęcie, że pojedynczy system może zostać przejęty, a następnie zaprojektowanie środowiska tak, aby jego kompromitacja nie oznaczała automatycznie kompromitacji całej organizacji.

1. Zacznij od wiedzy o własnych zasobach

Trudno chronić infrastrukturę, o której istnieniu nie wiemy. Organizacja powinna posiadać aktualną ewidencję wykorzystywanych systemów, urządzeń, aplikacji i usług, wraz z informacją o ich właścicielach, funkcji biznesowej, wersjach oprogramowania oraz ekspozycji na Internet.

Szczególnej kontroli powinny podlegać zasoby dostępne publicznie. Zapomniany serwer, nieużywana aplikacja, stary koncentrator VPN czy urządzenie pozostawione z nieaktualnym oprogramowaniem mogą stać się najprostszą drogą do infrastruktury organizacji.

Asset Management stanowi fundament wielu kolejnych procesów bezpieczeństwa. Bez wiedzy o posiadanych zasobach trudno skutecznie zarządzać podatnościami, aktualizacjami, wdrożeniem EDR czy centralnym logowaniem.

2. Segmentacja i mikrosegmentacja sieci

Należy wdrożyć architekturę sieciową uwzględniającą segmentację. Tam, gdzie jest to uzasadnione – również mikrosegmentację.

Stacje robocze użytkowników, serwery, systemy administracyjne, infrastruktura kopii zapasowych oraz systemy krytyczne powinny funkcjonować w odpowiednio wydzielonych strefach bezpieczeństwa. Komunikacja pomiędzy nimi powinna być ograniczona zgodnie z zasadą najmniejszych uprawnień. Jeżeli stacja użytkownika nie musi komunikować się bezpośrednio z określonym serwerem lub inną stacją roboczą, taki ruch powinien być domyślnie zablokowany.

Segmentacja znacząco utrudnia prowadzenie rekonesansu i ruchu lateralnego oraz ogranicza możliwość rozprzestrzenienia ransomware na całe środowisko.

3. Kontrola i inspekcja ruchu pomiędzy strefami

Ruch pomiędzy kluczowymi segmentami sieci powinien być kontrolowany przez odpowiednio skonfigurowane firewalle. Tam, gdzie jest to uzasadnione – również monitorowany przez rozwiązania klasy Intrusion Detection/Prevention System (IDS/IPS). Systemy te mogą wspierać identyfikację prób rekonesansu, skanowania usług, ataków brute-force, wykorzystania znanych podatności czy transmisji potencjalnie złośliwych plików.

IPS nie powinien być traktowany wyłącznie jako zabezpieczenie styku z internetem. W odpowiednio zaprojektowanej architekturze może również stanowić element kontroli i monitorowania komunikacji pomiędzy wybranymi strefami wewnętrznymi.

4. Web Proxy i kontrola dostępu do Internetu

Ruch HTTP i HTTPS generowany przez stacje robocze powinien podlegać kontroli z wykorzystaniem rozwiązania Web Proxy, Secure Web Gateway lub równoważnego mechanizmu bezpieczeństwa. System powinien umożliwiać blokowanie zasobów o złej reputacji oraz – zależnie od polityki organizacji – nowo utworzonych, nieskategoryzowanych lub nieznanych domen.

Jeszcze bardziej restrykcyjne zasady powinny dotyczyć serwerów. Serwer, który nie wymaga bezpośredniego dostępu do internetu, nie powinien go posiadać. W pozostałych przypadkach należy ograniczyć komunikację do usług i kierunków niezbędnych do realizacji jego funkcji. Takie podejście może znacząco utrudnić zarówno pobieranie kolejnych komponentów malware, jak i komunikację z infrastrukturą Command&Control.

5. DNS reputacyjny

Kolejną warstwę ochrony powinien stanowić system DNS wykorzystujący informacje reputacyjne. Pozwala on blokować komunikację ze znanymi domenami phishingowymi, serwerami Command&Control, infrastrukturą dystrybucji malware oraz innymi zasobami powiązanymi ze złośliwą aktywnością. Mechanizm ten działa na bardzo wczesnym etapie komunikacji i może uniemożliwić połączenie ze złośliwą infrastrukturą jeszcze przed nawiązaniem właściwej sesji sieciowej.

Warstwa 2. Tożsamość, konta i kontrola dostępu

W wielu incydentach ransomware kluczowym momentem nie jest samo uruchomienie malware, lecz przejęcie konta posiadającego wystarczające uprawnienia do dalszego przemieszczania się po środowisku. Uzyskanie poświadczeń administratora może całkowicie zmienić skalę incydentu. Dlatego ochrona tożsamości powinna być jednym z najważniejszych elementów strategii anty-ransomware.

6. MFA i ochrona dostępu zdalnego

Uwierzytelnianie wieloskładnikowe powinno być obowiązkowe przynajmniej dla dostępu VPN, poczty, usług chmurowych, systemów administracyjnych oraz wszystkich kont uprzywilejowanych. Tam, gdzie jest to możliwe, warto preferować mechanizmy MFA odporne na phishing zamiast opierać ochronę wyłącznie na kodach SMS czy prostych powiadomieniach push.

W przypadku infrastruktury VPN można dodatkowo rozważyć ograniczenie możliwości nawiązywania połączeń z lokalizacji geograficznych, z których organizacja nie prowadzi działalności – jeżeli takie ograniczenie wynika z analizy ryzyka.

Należy również przeanalizować zasadność wykorzystywania split tunnelingu. W środowiskach wymagających pełnej kontroli ruchu jego wyłączenie pozwala kierować komunikację użytkownika przez firmowe mechanizmy bezpieczeństwa.

7. Oddziel konta administracyjne od codziennej pracy

Konta administracyjne nie powinny być wykorzystywane do codziennej pracy, przeglądania internetu czy obsługi poczty elektronicznej. Administrator powinien posiadać oddzielne konto użytkownika oraz oddzielne konto administracyjne, wykorzystywane wyłącznie podczas wykonywania czynności wymagających podwyższonych uprawnień.

W bardziej dojrzałych środowiskach warto dodatkowo wdrożyć model separacji poziomów administracyjnych oraz dedykowane, odpowiednio zabezpieczone stacje wykorzystywane do zarządzania infrastrukturą, np. PAW (Privileged Access Workstation). Celem jest ograniczenie sytuacji, w której kompromitacja zwykłej stacji administratora automatycznie daje napastnikowi dostęp do poświadczeń pozwalających zarządzać kluczowymi systemami.

8. Windows LAPS

W środowiskach Windows należy wdrożyć Windows LAPS umożliwiający centralne zarządzanie hasłami lokalnych kont administratorów. Każdy system powinien posiadać inne, odpowiednio złożone i automatycznie rotowane hasło administratora lokalnego.

Wykorzystywanie tego samego hasła lokalnego administratora na wielu komputerach tworzy bardzo dogodne warunki do ruchu lateralnego. Przejęcie poświadczeń na jednym systemie może w takim przypadku umożliwić uzyskanie dostępu do kolejnych urządzeń. LAPS znacząco ogranicza to ryzyko.

9. Zarządzanie tożsamością i recertyfikacja dostępów

Organizacja powinna posiadać centralną ewidencję kont i nadanych uprawnień. Dostępy powinny podlegać regularnej recertyfikacji, a nieaktywne konta, niepotrzebne uprawnienia oraz dostępy osób, które zmieniły stanowisko lub zakończyły współpracę z organizacją, powinny być niezwłocznie usuwane.

Należy konsekwentnie stosować zasadę najmniejszych uprawnień. Użytkownik, administrator, konto techniczne czy aplikacja powinny posiadać wyłącznie takie uprawnienia, jakie są niezbędne do realizacji ich funkcji. Szczególnej kontroli powinny podlegać konta uprzywilejowane oraz konta techniczne.

Warstwa 3. Ochrona stacji roboczych i serwerów

Kolejnym poziomem ochrony są same systemy końcowe. Nawet jeżeli napastnik przedostanie się do sieci, jego działania na stacji roboczej lub serwerze powinny pozostawiać ślady i zostać możliwie szybko wykryte.

10. Endpoint Detection and Response

Rozwiązanie klasy EDR powinno zostać wdrożone na wszystkich obsługiwanych stacjach roboczych i serwerach, na których jest to technicznie możliwe. Reguły detekcyjne powinny uwzględniać techniki wykorzystywane podczas ataków ransomware, takie jak próby wyłączania mechanizmów bezpieczeństwa, usuwanie kopii Volume Shadow Copy, manipulowanie usługami, wykorzystanie PowerShell, WMI czy PsExec, pozyskiwanie poświadczeń oraz nietypowe masowe operacje na plikach.

EDR powinien również umożliwiać szybką zdalną izolację hosta od sieci.

W praktyce możliwość odizolowania zainfekowanej stacji lub serwera w ciągu kilku minut od wykrycia podejrzanej aktywności może mieć kluczowe znaczenie dla ograniczenia skali incydentu.

11. Sysmon jako dodatkowe źródło telemetrii

W środowiskach Windows warto rozważyć wdrożenie Sysmon jako dodatkowego źródła telemetrii bezpieczeństwa. Odpowiednio skonfigurowany Sysmon pozwala rejestrować m.in. tworzenie procesów, połączenia sieciowe, operacje na plikach i rejestrze oraz inne zdarzenia przydatne podczas wykrywania i analizy ataków.

Sysmon sam w sobie nie jest jednak mechanizmem ochronnym. Jego wartość pojawia się dopiero wtedy, gdy generowane dane są centralnie zbierane i analizowane. Dlatego logi Sysmon powinny być przesyłane do SIEM i wykorzystywane przez odpowiednio przygotowane reguły detekcyjne.

12. Hardening systemów

Konfiguracja systemów operacyjnych powinna ograniczać możliwość wykorzystania funkcji, które nie są wymagane biznesowo. Należy ograniczać zbędne usługi, protokoły i mechanizmy administracyjne, kontrolować możliwość uruchamiania skryptów oraz wykorzystywać mechanizmy bezpieczeństwa oferowane przez system operacyjny.

W przypadku środowisk Windows szczególnej analizie powinny podlegać m.in. NTLM, SMB, PowerShell, RDP oraz mechanizmy przechowywania i ochrony poświadczeń. Zasada jest prosta: jeżeli dana funkcja nie jest potrzebna – powinna zostać wyłączona lub ograniczona.

Warstwa 4. Podatności i systemy wystawione do internetu

Jednym ze sposobów uzyskania początkowego dostępu pozostaje wykorzystanie podatności w publicznie dostępnych systemach. Szczególnie atrakcyjnym celem są urządzenia brzegowe: koncentratory VPN, firewalle, systemy zdalnego dostępu oraz publicznie dostępne aplikacje.

13. Zarządzanie podatnościami

Organizacja powinna posiadać ciągły proces zarządzania podatnościami obejmujący identyfikację zasobów, skanowanie podatności, ocenę ryzyka, priorytetyzację oraz kontrolę procesu ich usuwania.

Samo wykonanie skanu nie jest zarządzaniem podatnościami. Kluczowe jest doprowadzenie procesu do momentu usunięcia podatności, zastosowania mechanizmu ograniczającego ryzyko albo świadomej i udokumentowanej akceptacji związanego z nią ryzyka.

Priorytetyzacja nie powinna wynikać wyłącznie z wartości CVSS. Należy również uwzględniać ekspozycję systemu, jego znaczenie dla organizacji oraz informacje o rzeczywistym wykorzystywaniu danej podatności przez atakujących.

14. Aktualizacje i zarządzanie wersjami oprogramowania

Wszystkie systemy operacyjne, aplikacje oraz urządzenia infrastruktury powinny być aktualizowane zgodnie z zaleceniami producentów. Najwyższy priorytet powinny otrzymywać podatności aktywnie wykorzystywane przez atakujących oraz systemy dostępne bezpośrednio z internetu.

Standardowy cykl aktualizacji może być niewystarczający w sytuacji, gdy pojawia się krytyczna podatność aktywnie wykorzystywana w atakach. Organizacja powinna posiadać możliwość uruchomienia przyspieszonego, awaryjnego procesu aktualizacji dla takich przypadków.

Należy również posiadać ewidencję wykorzystywanych wersji oprogramowania, aby szybko określić, które systemy wymagają interwencji.

15. Web Application Firewall

Publicznie dostępne aplikacje internetowe powinny być chronione za pomocą rozwiązania klasy Web Application Firewall (WAF). WAF stanowi dodatkową warstwę zabezpieczeń umożliwiającą identyfikację i blokowanie części prób wykorzystania podatności aplikacyjnych. Nie zastępuje on jednak procesu zarządzania podatnościami, aktualizacji ani bezpiecznego procesu tworzenia oprogramowania. Powinien być traktowany jako kolejna warstwa ochrony, a nie rozwiązanie problemu podatnej aplikacji.

Warstwa 5. Monitoring i detekcja

Atak ransomware bardzo rzadko rozpoczyna się od szyfrowania danych. Wcześniej napastnik może przez wiele godzin lub dni prowadzić rekonesans, pozyskiwać poświadczenia, eskalować uprawnienia, przemieszczać się po środowisku i przygotowywać infrastrukturę do przeprowadzenia właściwego ataku.

To właśnie na tym etapie istnieje największa szansa na jego wykrycie, zanim dojdzie do zaszyfrowania systemów.

16. Centralny SIEM

Organizacja powinna posiadać centralny system gromadzenia i analizy zdarzeń bezpieczeństwa klasy SIEM. Do systemu powinny trafiać logi m.in. z systemów operacyjnych, usług katalogowych, urządzeń sieciowych, VPN, firewalli, WAF, IDS/IPS, EDR, systemów antywirusowych oraz kluczowych aplikacji. Nie chodzi jednak wyłącznie o zgromadzenie możliwie dużej liczby logów.

SIEM powinien posiadać zestaw reguł korelacyjnych i detekcyjnych pozwalających identyfikować zarówno pojedyncze podejrzane zdarzenia, jak i sekwencje działań mogących wskazywać na trwający atak. Reguły powinny być regularnie rozwijane i dostosowywane do zmian infrastruktury oraz aktualnego krajobrazu zagrożeń.

17. SOC i ciągły monitoring

Alert musi trafić do kogoś, kto potrafi go właściwie zinterpretować. Zdarzenia generowane przez SIEM, EDR i pozostałe systemy bezpieczeństwa powinny być analizowane przez zespół odpowiedzialny za monitoring bezpieczeństwa – wewnętrzny SOC lub zewnętrzną usługę realizującą taką funkcję.

Kluczowe jest zapewnienie odpowiedniego czasu reakcji. Alert bezpieczeństwa, którego nikt nie analizuje przez kilkanaście godzin, może mieć niewielką wartość podczas szybko rozwijającego się incydentu ransomware. Wraz z procesem monitorowania należy przygotować scenariusze postępowania określające, co analityk powinien zrobić po wykryciu konkretnych rodzajów aktywności oraz kiedy zdarzenie wymaga natychmiastowej eskalacji.

18. Cyber Threat Intelligence

Proces monitorowania powinien być wspierany przez analizę aktualnego krajobrazu zagrożeń.

Cyber Threat Intelligence pozwala identyfikować nowe techniki, narzędzia i sposoby działania grup ransomware, a następnie przekładać tę wiedzę na konkretne działania obronne. Nie powinno sprowadzać się wyłącznie do kolekcjonowania adresów IP, domen czy hashy plików. Największą wartość daje wiedza o sposobie działania przeciwnika – jego taktykach, technikach i procedurach – którą można przełożyć na nowe reguły SIEM i EDR, mechanizmy blokowania, scenariusze threat huntingu oraz zmiany konfiguracji infrastruktury.

Warstwa 6. Reagowanie i odporność organizacji

Nawet najlepsze zabezpieczenia nie gwarantują, że organizacja nigdy nie zostanie zaatakowana. Dlatego strategia anty-ransomware musi odpowiadać również na pytanie:

Co zrobimy, jeśli atakujący jednak dostanie się do naszej infrastruktury?

19. Przygotuj plan Incident Response

Organizacja powinna posiadać przygotowany i regularnie testowany plan reagowania na incydent ransomware. Procedura powinna określać role i odpowiedzialności, sposób eskalacji incydentu, zasady komunikacji oraz działania techniczne wykonywane podczas jego obsługi.

Zespół reagowania powinien mieć możliwość szybkiej izolacji pojedynczych urządzeń, blokowania kont użytkowników, odcinania serwerów, a w sytuacji krytycznej również izolowania całych segmentów sieci. Decyzje takie nie powinny być po raz pierwszy uzgadniane w momencie trwającego ataku.

Warto wcześniej określić, kto posiada uprawnienia do podjęcia decyzji o izolacji systemu lub części infrastruktury i w jakich sytuacjach może to zrobić.

20. Backup i możliwość odtworzenia środowiska

Kopie zapasowe są jedną z najważniejszych ostatnich linii obrony przed ransomware.

Można stosować strategię 3-2-1-1-0: co najmniej trzy kopie danych, na dwóch różnych typach nośników, jedna kopia poza podstawową lokalizacją, jedna kopia offline lub immutable oraz brak błędów podczas testów odtwarzania.

Szczególnie istotne jest odseparowanie infrastruktury backupowej od podstawowego środowiska oraz ograniczenie możliwości jej administracji z wykorzystaniem tych samych kont, które zarządzają pozostałą infrastrukturą. Atakujący również wiedzą, że backup może uniemożliwić skuteczny szantaż. Dlatego infrastruktura kopii zapasowych często staje się jednym z celów ataku.

Samo posiadanie backupu nie wystarcza. Organizacja musi regularnie sprawdzać, czy rzeczywiście jest w stanie odtworzyć z niego kluczowe systemy oraz ile czasu taki proces zajmuje. Backup, którego nigdy nie próbowano odtworzyć, jest jedynie założeniem, że posiadamy backup (żartobliwie nazywany Backupem Schroedingera).

21. Ćwicz, zanim wydarzy się prawdziwy incydent

Procedury reagowania powinny być regularnie testowane. Warto prowadzić ćwiczenia TableTop, Purple Team oraz symulacje incydentów ransomware obejmujące zarówno zespoły techniczne, jak i osoby odpowiedzialne za zarządzanie organizacją, komunikację, kwestie prawne oraz ciągłość działania.

Ćwiczenia powinny odpowiadać na bardzo praktyczne pytania:

• Kto podejmuje decyzję o odłączeniu części infrastruktury?
• Jak skontaktujemy się ze sobą, jeśli poczta przestanie działać?
• Kto odpowiada za kontakt z klientami?
• Jak szybko potrafimy ustalić skalę kompromitacji?
• Czy wiemy, które systemy muszą zostać odtworzone jako pierwsze?
• Czy potrafimy odtworzyć je z backupu?

Pierwszym momentem, w którym organizacja sprawdza swój plan reagowania na ransomware, nie powinien być rzeczywisty atak.

Zamiast jednej bariery przeciwko ransomware – wiele warstw

Nie istnieje pojedynczy produkt, który rozwiązuje problem ransomware. EDR nie zastąpi segmentacji. Segmentacja nie zastąpi MFA. MFA nie usunie podatności. SIEM nie pomoże, jeśli nikt nie analizuje generowanych przez niego alertów. Backup nie zatrzyma ataku, ale może zdecydować o tym, czy po incydencie organizacja będzie w stanie odtworzyć swoje środowisko.

Dlatego skuteczna ochrona przed ransomware powinna opierać się na koncepcji Defense in Depth – wielu niezależnych, wzajemnie uzupełniających się warstw zabezpieczeń. Można spojrzeć na nie jak na kolejne przeszkody ustawione na drodze atakującego: poznaj swoje zasoby → ogranicz powierzchnię ataku → chroń tożsamość → utrudnij ruch lateralny → chroń endpointy → monitoruj → wykrywaj → reaguj → odtwarzaj.

Atakujący może ominąć jedną z tych warstw. Być może ominie również drugą. Każda kolejna zwiększa jednak koszt i czas potrzebny do przeprowadzenia ataku oraz prawdopodobieństwo jego wykrycia.

Warto również pamiętać, że sukces obrony nie zawsze musi oznaczać całkowite uniemożliwienie włamania. Jeżeli napastnik wykorzysta podatność i przejmie pojedynczy serwer, ale segmentacja uniemożliwi mu dalszy ruch, EDR wykryje jego działania, SOC zareaguje na alert, a zespół Incident Response odizoluje system, zanim atakujący uzyska dostęp do kluczowej infrastruktury – mechanizmy bezpieczeństwa spełniły swoją funkcję.

I właśnie to powinno być jednym z podstawowych celów dobrze zaprojektowanej architektury bezpieczeństwa: nie zakładać, że atak nigdy się nie wydarzy, lecz zbudować środowisko, w którym jego skuteczne przeprowadzenie będzie możliwie trudne, jego działania możliwie szybko wykryte, a skutki incydentu ograniczone.

The post Jak zbudować skuteczną ochronę przed ransomware appeared first on CERT Orange.

Cybercrime

Od fałszywych repozytoriów do przejętych projektów. Ewolucja ataków na programistów

• Zidentyfikowano ponad 800 fałszywych repozytoriów GitHub podszywających się pod narzędzia AI i serwery MCP, których celem było dostarczenie złośliwego oprogramowania.
• Kampanie wymierzone w programistów ewoluują – od infekowania pojedynczych użytkowników do prób kompromitacji całych projektów open source i łańcuchów dostaw oprogramowania.
• Opisane działania wpisują się w szerszy trend wykorzystywania środowisk deweloperskich jako punktu wejścia do organizacji.

Popularność narzędzi opartych o sztuczną inteligencję sprawiła, że w serwisach takich jak GitHub niemal codziennie pojawiają się nowe biblioteki, rozszerzenia i gotowe projekty. Cyberprzestępcy coraz częściej wykorzystują ten trend, publikując repozytoria, które wyglądają wiarygodnie, lecz w rzeczywistości służą do dystrybucji złośliwego oprogramowania. 

Przykładem jest kampania FakeGit. Na GitHubie zidentyfikowano ponad 800 repozytoriów podszywających się pod narzędzia związane z AI oraz serwerami MCP. Projekty zawierały rozbudowaną dokumentację, instrukcje uruchomienia oraz powiązania z innymi repozytoriami, sprawiając wrażenie aktywnie rozwijanych inicjatyw open source. 

Po uruchomieniu przygotowanego przez atakujących kodu rozpoczynał się wieloetapowy proces prowadzący do pobrania kolejnych komponentów malware. W zależności od wariantu jego celem była kradzież danych uwierzytelniających, informacji zapisanych w przeglądarce czy portfeli kryptowalutowych. Kampania pokazuje, że GitHub coraz częściej jest wykorzystywany nie tylko jako platforma do hostowania kodu, ale również jako element infrastruktury wykorzystywanej przez cyberprzestępców do uwiarygodniania swoich działań. 

FakeGit nie jest jednak odosobnionym przypadkiem. Kilka tygodni wcześniej opisano próbę infekcji wykorzystującą zupełnie inny scenariusz, ale prowadzącą do podobnego celu – przejęcia środowiska pracy programisty. 

W opublikowanej analizie opisano przebieg fikcyjnego procesu rekrutacyjnego, podczas którego otrzymano zadanie programistyczne w postaci repozytorium Git. Kod aplikacji wyglądał wiarygodnie, a jego uruchomienie nie prowadziło do wykonania złośliwego oprogramowania. Zagrożenie zostało ukryte w mniej oczywistym miejscu – Git hookach. W analizowanym przypadku złośliwy kod uruchamiał się podczas przełączania gałęzi, pobierał kolejne komponenty z infrastruktury atakujących i rozpoczynał dalszy etap infekcji. 

Nie jest to jedyna technika wykorzystująca środowisko deweloperskie do uruchomienia złośliwego kodu. W ostatnich miesiącach obserwowano również nadużywanie konfiguracji tasks.json w Visual Studio Code. Po otwarciu projektu i zaakceptowaniu zaufania do repozytorium środowisko mogło automatycznie wykonać przygotowane wcześniej zadania, które pobierały i uruchamiały kolejne elementy infekcji. Zarówno Git hooki, jak i konfiguracje VS Code pokazują, że cyberprzestępcy chętnie wykorzystują mechanizmy stanowiące naturalny element codziennej pracy programistów. 

Opisane przypadki stanowią element szerszej aktywności określanej przez badaczy jako Contagious Interview, prowadzonej od kilku lat przeciwko programistom i organizacjom rozwijającym oprogramowanie. Choć część publikacji wiąże ją z podmiotami powiązanymi z Koreą Północną, badacze podkreślają, że atrybucja poszczególnych incydentów nie zawsze jest jednoznaczna, a sama kampania najprawdopodobniej obejmuje kilka współpracujących ze sobą klastrów wykorzystujących podobne narzędzia i techniki. 

Początkowo działania skupiały się głównie na fałszywych ofertach pracy oraz zadaniach rekrutacyjnych, których celem było nakłonienie programisty do uruchomienia przygotowanego wcześniej projektu. Z czasem zestaw wykorzystywanych technik znacząco się rozszerzył. Obok fikcyjnych procesów rekrutacyjnych zaczęły pojawiać się złośliwe pakiety publikowane w popularnych repozytoriach, projekty podszywające się pod narzędzia AI, nadużycia konfiguracji Visual Studio Code czy wykorzystanie Git hooków. Niezależnie od zastosowanej techniki cel pozostaje ten sam – uzyskanie dostępu do środowiska deweloperskiego ofiary. 

Po uzyskaniu dostępu do jego środowiska pracy próbują wykorzystać posiadane przez niego uprawnienia do modyfikowania legalnych projektów rozwijanych przez organizację. Zaobserwowano również rozwój technik utrudniających wykrycie takich zmian. W niektórych przypadkach złośliwy kod JavaScript ukrywany był w plikach konfiguracyjnych z wykorzystaniem dużej liczby białych znaków, dzięki czemu właściwy fragment znajdował się poza widocznym obszarem podczas przeglądania kodu lub analizy zmian. Równocześnie modyfikowano metadane commitów, aby utrudnić zauważenie nieautoryzowanych zmian. 

Interesującym elementem kampanii jest również sposób dostarczania kolejnych etapów malware. Zamiast przechowywać je na klasycznej infrastrukturze C2, obserwowano wykorzystanie publicznych sieci blockchain, takich jak TRON, Aptos czy BNB Smart Chain, jako tzw. dead dropów. Repozytorium zawiera jedynie mechanizm pobierający kolejne instrukcje z zapisanych tam danych. Pozwala to stosunkowo łatwo zmieniać dostarczany payload bez konieczności modyfikowania samego repozytorium oraz utrudnia działania polegające na blokowaniu infrastruktury wykorzystywanej przez atakujących. 

Patrząc szerzej

FakeGit to kolejny przykład zmiany, jaką obserwujemy w atakach wymierzonych w programistów i organizacje rozwijające oprogramowanie. Jeszcze kilka lat temu dominowały przede wszystkim złośliwe pakiety publikowane w popularnych repozytoriach. Obecnie atakujący wykorzystują znacznie szerszy zestaw technik – od fałszywych procesów rekrutacyjnych i repozytoriów podszywających się pod popularne narzędzia, przez nadużywanie funkcji środowisk programistycznych, aż po próby przejęcia legalnych projektów open source. Niezależnie od wykorzystywanej metody celem pozostaje uzyskanie dostępu do środowiska deweloperskiego, które może stać się punktem wyjścia do dalszych ataków na łańcuch dostaw oprogramowania. 

Skala tego zjawiska stale rośnie. Badacze regularnie identyfikują kolejne setki lub tysiące złośliwych repozytoriów i pakietów, jednak nowe pojawiają się szybciej, niż udaje się je usuwać. Dla zespołów bezpieczeństwa oznacza to konieczność monitorowania nie tylko podatności czy złośliwych pakietów, ale również sposobu, w jaki organizacja korzysta z narzędzi i platform wspierających proces tworzenia oprogramowania. 

Więcej informacji:  
https://citizendot.github.io/articles/fake-job-interview-git-hook-malware/ 
https://www.island.io/blog/agentbaiting-how-800-fake-ai-skills-and-mcp-servers-delivered-malware. 

Oszustwa i podszycia

Kali365, Device Code Phishing i ekosystem PhaaS

• Kali365 to phishkit dystrybuowany w modelu Phishing-as-a-Service wykorzystywany w wielu kampaniach, zarówno masowych, jak i celowanych. 
• Jako przynęty zwykle stosowane są takie scenariusze jak udostępnienie pliku i marki w tym Docusign czy Microsoft i produkty Sharepoint, OneDrive i Teams.
• Kali365 oferuje zarówno phishing z wykorzystaniem techniki Adversary-in-the-Middle, jak i ciekawszej – Device Code Phishing.
• PhaaS to istotny element krajobrazu zagrożeń, który warto obserwować ze względu na mnogość rozwiązań i dynamiczne zmiany wynikające także z działań służb.

Kali365 to aktualnie jeden z częściej wykorzystywanych phishkitów na rynku cyberprzestępczym oferowany w modelu Phishing-as-a-Service. Oznacza to, że należy rozróżnić twórców usługi PhaaS od afiliantów realizujących kampanię z jej wykorzystaniem. Ten model działania wiąże się z odrębnością grup osób przygotowujących funkcje i wdrażających rozwiązania, od osób przeprowadzających ataki i jednocześnie czerpiących korzyści z pozyskanych danych.  

Popularność phiskitu przekłada się na mnożące się publikacje opisujące kulisy działania, jak i widywane kampanie z jego wykorzystaniem. Analitycy Infoblox w swoim artykule skupiają się na jednym atakującym, który korzysta z różnych phishkitów, między innymi Evilginx, FlowerStorm i Kali365. Wyłudzane były poświadczenia do usług Microsoft 365, ale także innych wartościowych kont. Analitycy wyróżniają kampanie, które dotykają szczególnie istotnych ofiar, jak Unia Europejska, czy Organizację Narodów Zjednoczonych, ale ataki mają wyraźnie charakter globalny. Z kolei analitycy Any.Run opisują przede wszystkim kampanie widziane w Stanach Zjednoczonych, ale z naszych obserwacji wynika, że podobne ataki regularnie są realizowane także w Polsce.  

W obu przypadkach analizy przedstawiają głównie scenariusze związane z udostępnieniem plików oraz zapytaniami ofertowymi, a atakujący podszywają się pod OneDrive, SharePoint oraz DocuSign. Warto jednak zwrócić uwagę na metody wykorzystywane przez atakujących do ominięcia coraz powszechniejszego dwuskładnikowego uwierzytelniania. Kali365 oferuje zarówno przechwytywanie sesji w modelu Adversary-in-the-Middle, jak i nowszym – Device Code Phishing.  Ten drugi, oparty na nadużyciu modelu Device Code Flow służącego do logowania na urządzeniach z ograniczonym interfejsem użytkownika, jest szczególnie warty uwagi. 

Ta metoda, czasem nazywana Ghost Phishing, opiera się na mniej znanej użytkownikom metodzie logowania. Na stronie pod kontrolą atakującego wyświetlany jest kod, którego wpisanie w oknie logowania ma pozwolić uzyskać dostęp do dokumentu „przynęty”. Po interakcji ze stroną otwierane jest dodatkowe okno przeglądarki ze stroną z uruchomionym prawdziwym flow logowania Microsoft, z poprawną domeną login.microsoftonline.com. Po wpisaniu kodu i zalogowaniu się prawdziwymi poświadczeniami atakujący uzyskuje dostęp na podstawie OAuth oraz refresh tokeny do konta ofiary. Skutkuje to dostępem odpornym na zmiany hasła i wieloskładnikowe uwierzytelnianie. Z perspektywy ofiary nieznającej przebiegu autoryzacji w ramach Device Code Flow może być trudno dostrzec znaki ostrzegawcze. Warto wspomnieć, że jedną z kluczowych metod zapobiegania atakom z wykorzystaniem tej metody jest całkowite wyłączenie obsługi Device Code Flow tam, gdzie nie jest to funkcja niezbędna. 

Rys. Przykładowa strona phishingowa z kodem oraz prawdziwy flow uwierzytelniania Microsoft otwierania w drugim oknie. Źródło: Any.Run

Nie wiadomo jaka przyszłość czeka Kali365, ale warto wspomnieć, że popularność w świecie cyberprzestępczym ma często swoją cenę. 20 lipca niemiecki Bundeskriminalamt poinformował o operacji przeprowadzonej we współpracy z partnerami międzynarodowymi wymierzonej w usługę Kratos PhaaS uznawaną za jedną z największych tego typu platform. W ramach działań zatrzymano w Indonezji administratora odpowiedzialnego za rozwój platformy oraz wyłączono ponad 200 serwerów stanowiących jej zaplecze techniczne. Według śledczych z narzędzi Kratos korzystało ponad 1800 cyberprzestępców prowadzących około 15 tysięcy kampanii phishingowych miesięcznie. Zwykle efektem tego typu operacji jest zakłócenie działań przestępczych afiliantów i tymczasowe zmniejszenie ich aktywności, ale należy spodziewać się szybkiego powrotu do normy w zakresie ataków phishingowych. 

Patrząc szerzej

Phishkity są stałym elementem krajobrazu zagrożeń, ale warto zwrócić uwagę na ich udział w propagacji nowych metod phishingu. Opracowanie metody omijania wieloskładnikowego uwierzytelniania lub zabezpieczeń nie skutkuje jego wykorzystaniem tylko przez jedną grupę, a przez wszystkich afiliantów korzystających z usług danego dostawcy PhaaS. Nawet bardziej zaawansowane techniki stają się osiągalne dla początkujących atakujących. 

Z perspektywy obrońców warto zwracać uwagę na phishkity, ponieważ ich wspólne cechy oraz powtarzalne metody dają szansę na wykrywanie i skuteczne blokowanie takich kampanii. Jak pokazuje przykład Kratos PhaaS. w dalszej perspektywie możliwe jest także uniemożliwienie działalności „usługodawcom”, co utrudnia ataki afiliantom zmuszonym do poszukiwania alternatywnego dostawcy. 

Więcej informacji:  
https://www.infoblox.com/blog/threat-intelligence/the-procurement-trap-inside-an-aitm-campaign-targeting-global-institutions/ 
https://www.bka.de/SharedDocs/Kurzmeldungen/DE/Kurzmeldungen/260720_Schlag_gegen_Phishing_Gruppierung_Kratos.html 
https://any.run/cybersecurity-blog/kali365-phishing-targeting-us/ 

Future

Autonomiczni agenci AI w praktyce – nowe wyzwania dla DFIR i Cyber Threat Intelligence

• Hugging Face opublikował szczegółową analizę jednego z pierwszych publicznie opisanych incydentów, w którym agent AI uczestniczył w prowadzeniu rzeczywistej operacji ofensywnej.
• Incydent nie był klasycznym atakiem przeprowadzonym przez zewnętrznego threat actora. Doszło do niego podczas ewaluacji możliwości cybernetycznych modeli OpenAI, które próbując rozwiązać zadanie testowe, samodzielnie odkryły i połączyły podatności pozwalające wydostać się poza zakładane środowisko oraz uzyskać dostęp do infrastruktury Hugging Face. 
• Równie istotny okazał się proces analizy powłamaniowej, w którym do rekonstrukcji incydentu wykorzystano modele AI oraz narzędzia agentowe, pokazując rosnącą rolę sztucznej inteligencji zarówno podczas wykonywania działań ofensywnych, jak i późniejszej analizy powłamaniowej.

Opublikowany przez Hugging Face raport dotyczący incydentu bezpieczeństwa z lipca 2026 roku jest znacznie ważniejszy niż kolejna historia o naruszeniu bezpieczeństwa. To jeden z pierwszych tak szczegółowo opisanych przypadków pokazujących, że autonomiczne systemy AI zaczynają odgrywać realną rolę podczas prowadzenia złożonych operacji cybernetycznych. Dodatkowe informacje opublikowane przez OpenAI pokazują jednak, że charakter tego incydentu był jeszcze bardziej nietypowy, niż początkowo mogło się wydawać. 

Incydent nie był klasycznym atakiem przeprowadzonym przez zewnętrznego napastnika wykorzystującego AI. Doszło do niego podczas wewnętrznej ewaluacji możliwości cybernetycznych modeli OpenAI, w tym GPT-5.6 Sol oraz bardziej zaawansowanego modelu przedpremierowego. Modele działały z obniżonym poziomem mechanizmów odmowy dla działań cybernetycznych, ponieważ celem eksperymentu było sprawdzenie ich maksymalnych możliwości podczas realizacji złożonych, wieloetapowych zadań ofensywnych. 

To właśnie sposób realizacji tego celu stanowi jeden z najciekawszych elementów całego incydentu. Modele nie otrzymały bezpośredniego polecenia zaatakowania infrastruktury Hugging Face. Próbując rozwiązać zadania benchmarku ExploitGym, zaczęły szukać sposobu uzyskania dostępu do Internetu poza izolowanym środowiskiem ewaluacyjnym. W tym celu zidentyfikowały podatność zero-day w wykorzystywanym przez OpenAI proxy rejestru pakietów, a następnie przeprowadziły eskalację uprawnień oraz ruch boczny pomiędzy systemami, aż dotarły do węzła posiadającego dostęp do Internetu. Po jego uzyskaniu modele wywnioskowały, że infrastruktura Hugging Face może zawierać informacje pozwalające znaleźć rozwiązania testów. W kolejnych etapach połączyły kilka wektorów ataku, w tym skradzione dane uwierzytelniające oraz podatność zero-day, uzyskując ścieżkę prowadzącą do zdalnego wykonania kodu w infrastrukturze Hugging Face. 

Z perspektywy analitycznej jeszcze ciekawsze od samego wektora wejścia jest tempo oraz skala działania obserwowane podczas incydentu. Analiza Hugging Face objęła około 17 tys. działań wykonanych w trakcie operacji, pokazując skalę aktywności, której ręczna rekonstrukcja byłaby niezwykle czasochłonna. Autonomiczny agent AI może wykonywać tysiące operacji w bardzo krótkim czasie, dynamicznie zmieniać sposób działania, korzystać z wielu narzędzi jednocześnie oraz podejmować kolejne decyzje na podstawie wyników poprzednich etapów. Taka charakterystyka znacząco utrudnia klasyczną analizę incydentów prowadzoną wyłącznie przez człowieka. OpenAI zwraca przy tym uwagę na rosnącą zdolność najnowszych modeli do prowadzenia złożonych operacji cybernetycznych w długim horyzoncie czasowym. Incydent pokazuje, że możliwości obserwowane wcześniej podczas benchmarków i cyberpoligonów zaczynają przekładać się na działania w rzeczywistych środowiskach.

Równie interesująca okazała się analiza powłamaniowa. Hugging Face wykorzystał własne narzędzia oparte na sztucznej inteligencji do odtworzenia przebiegu incydentu oraz analizy ogromnej liczby zdarzeń. Organizacja zwróciła również uwagę na ograniczenia komercyjnych modeli udostępnianych poprzez API, których mechanizmy bezpieczeństwa utrudniały analizę części artefaktów związanych z incydentem. W efekcie wykorzystano lokalnie uruchomione modele typu open-weight, które umożliwiły przeprowadzenie pełnej analizy bez ograniczeń wynikających z polityk bezpieczeństwa usług zewnętrznych. 

Incydent jest jednak interesujący nie tylko ze względu na wykorzystanie autonomicznych modeli podczas działań ofensywnych. Raport Hugging Face pokazuje również kilka zmian, które mogą mieć istotne znaczenie dla przyszłości analiz prowadzonych przez zespoły Cyber Threat Intelligence oraz Incident Response. 

Jednym z najciekawszych wniosków płynących z analizy incydentu jest zmiana roli klasycznych wskaźników kompromitacji (IOC). W tradycyjnych kampaniach malware analiza koncentruje się na adresach IP, domenach, skrótach plików, nazwach procesów czy sygnaturach wykorzystywanych narzędzi. W przypadku autonomicznych agentów AI wiele z tych artefaktów może mieć jednak znacznie krótszy cykl życia. Agent może dynamicznie generować nowe polecenia, wybierać inne narzędzia, zmieniać sposób realizacji zadania lub wykorzystywać alternatywne ścieżki działania w zależności od sytuacji. Większego znaczenia nabiera analiza sposobu działania agenta. Dla zespołów Cyber Threat Intelligence oznacza to konieczność skupienia się nie tylko na odpowiedzi na pytanie, co zostało wykorzystane, ale przede wszystkim w jaki sposób agent podejmował decyzje, z jakich narzędzi korzystał, jak wyglądała sekwencja wykonywanych działań oraz jakie zależności występowały pomiędzy kolejnymi etapami operacji. Raport Hugging Face pokazuje, że w środowiskach wykorzystujących agentów AI analiza zachowania systemu, procesu podejmowania decyzji oraz wykorzystywanych narzędzi może stać się równie istotna jak klasyczna analiza wskaźników kompromitacji. 

Incydent zwraca również uwagę na inny, często pomijany aspekt bezpieczeństwa systemów agentowych. Zagrożeniem przestaje być wyłącznie sam model językowy, a coraz większego znaczenia nabiera zestaw narzędzi, do których agent posiada dostęp. W praktyce są to terminale systemowe, interfejsy API, repozytoria kodu, usługi chmurowe czy serwery wykorzystujące Model Context Protocol (MCP). To właśnie możliwość wywoływania zewnętrznych narzędzi sprawia, że agent przestaje być jedynie systemem generującym odpowiedzi, a staje się aktywnym uczestnikiem operacji, mogącym wykonywać rzeczywiste działania w środowisku. 

Innymi słowy, kompromitacja lub nadużycie warstwy wykonawczej może mieć znacznie większe konsekwencje niż podatność samego modelu językowego. Z perspektywy bezpieczeństwa oznacza to konieczność rozszerzenia modelu zagrożeń. Analizie powinny podlegać nie tylko prompty i odpowiedzi modelu, ale również zakres uprawnień przypisanych agentowi, dostępne narzędzia, sposób autoryzacji ich wywołań oraz możliwość ich nadużycia. W praktyce powierzchnia ataku rozszerza się poza sam model AI i obejmuje również jego warstwę wykonawczą (tool calling) – mechanizmy umożliwiające agentowi wykonywanie rzeczywistych działań w środowisku. To właśnie ta warstwa może w kolejnych latach stać się jednym z najważniejszych obszarów badań nad bezpieczeństwem systemów agentowych. 

Patrząc szerzej

Incydent pokazuje nowy problem, który może stać się jednym z kluczowych wyzwań bezpieczeństwa systemów agentowych: kontrola zakresu działania agenta nie może opierać się wyłącznie na kontroli jego instrukcji. Model nie musi otrzymać polecenia wykonania konkretnego ataku, aby w trakcie realizacji innego celu odkryć, że kompromitacja kolejnego systemu jest skutecznym sposobem osiągnięcia zadania. W takim środowisku szczególnego znaczenia nabierają mechanizmy ograniczające nie tylko to, co agent może wygenerować, ale przede wszystkim to, co może rzeczywiście wykonać. 

Z tego punktu widzenia klasyczny sandbox, filtrowanie promptów czy mechanizmy odmowy modelu są tylko częścią architektury bezpieczeństwa. Równie istotne stają się segmentacja środowiska, kontrola dostępu do sieci, zarządzanie tożsamością agenta, ograniczenie dostępnych narzędzi, monitoring wykonywanych operacji oraz możliwość automatycznego przerwania działania po wykryciu nietypowej sekwencji aktywności. Incydent OpenAI i Hugging Face pokazuje, że w przypadku agentów zdolnych do prowadzenia operacji w długim horyzoncie czasowym bezpieczeństwo musi być projektowane nie tylko wokół modelu, lecz wokół całego środowiska, w którym model może działać. 

W naszej ocenie równie istotna jak rozwój samych modeli AI będzie ewolucja metod ich analizy. Zespoły bezpieczeństwa będą musiały coraz częściej badać nie tylko kod, logi czy wskaźniki kompromitacji, ale również sposób działania agentów, wykorzystywane przez nie narzędzia oraz proces podejmowania decyzji. To obszar, który w najbliższych latach może stać się jednym z najważniejszych kierunków rozwoju analiz DFIR oraz Cyber Threat Intelligence

Więcej informacji:
https://huggingface.co/blog/security-incident-july-2026 
https://openai.com/pl-PL/index/hugging-face-model-evaluation-security-incident/ 

The post Krajobraz Zagrożeń – 27.07.2026 appeared first on CERT Orange.

Główne zmiany dotyczą obostrzeń dla dzieci poniżej 13. roku życia oraz spójności ustawień i limitów w ramach całego ekosystemu Apple. W miejsce zarządzania urządzeniami, z których korzystają dzieci zostanie wprowadzone zarządzanie profilem użytkownika (czyli w tym przypadku dziecka). Wśród nowości znajdziemy nadawanie i odbieranie dostępu do konkretnych aplikacji czy wymuszenie zgody rodzica w przypadku chęci zainstalowania nowej aplikacji. Co wydaje się być kontrowersyjne, to mechanizm akceptowania nowych stron WWW, odwiedzanych przez dzieci, a nawet konieczność akceptacji dodania nowego kontaktu.

Jakie zmiany wprowadza Apple w kontroli rodzicielskiej

W ekosystemie Apple aplikacja Screen Time była do tej pory rodzinnym centrum dowodzenia. W ramach usługi Chmura rodzinna, można było w niej dodać urządzenia i ustawiać limity korzystania dla każdego z nich.

Nasze podejście do pomagania rodzinom w tworzeniu bezpieczniejszych doświadczeń cyfrowych opiera się na przekonaniu, że każde dziecko jest inne. Dlatego budujemy proste i intuicyjne narzędzia, oparte na wiedzy ekspertów, by rodzice mogli dostosować cyfrową ścieżkę swojego dziecka

mówi Sumbul Desai, wiceprezes Apple odpowiedzialna za dział Health and Fitness. Dr Sumbul Desai jest medialną twarzą marki, w obszarze zdrowia ale nie znalazła się tam przypadkiem. Poza rolą w zarządzie marki jest też lekarką i profesorem medycyny na uniwersytecie Stanforda. Jej rolą w Apple jest m.in. nadzór nad klinikami i przychodniami prowadzonymi przez markę. Badania prowadzone przy ich wykorzystaniu wpływają bezpośrednio na rozwój takich produktów jak aplikacja Zdrowie, czy Apple Watch.

Wróćmy jednak do aplikacji Screen Time. Już w chwili pierwszego uruchomienia i konfiguracji nowego urządzenia, możemy sklasyfikować jego właściciela jako „konto dziecięce”, co poprowadzi nas przez dedykowaną ścieżkę. Jeśli jest to kolejne urządzenie – automatycznie przyjmuje ono wszystkie parametry skonfigurowane wcześniej dla profilu dziecka. Oznacza to odejście od zarządzania urządzeniami i przejście na konkretne profile. Ustawione parametry są od teraz współdzielone pomiędzy urządzeniami danego użytkownika.

W pierwszym kroku konfiguracji wprowadzana jest dokładna data urodzenia. W zależności od regionu świata będzie się różnić minimalny wiek, od którego można założyć takie konto. Wprowadzono również 5 kategorii wiekowych.

App Store z nowymi kategoriami wiekowymi

Tutaj mamy już więcej zmian. App Store na bazie kategorii wiekowych (4+, 9+, 13+, 16+, 18+) podpowiada aplikacje i gry w ramach Game Center. Ze zmianami pojawi się zupełnie nowa kategoria Kids, wewnątrz której można ograniczyć dostęp w ramach całego App Store. Oznacza to, że dziecko nie zobaczy aplikacji spoza tej kategorii.

Kolejną nowością jest Permission Kit. To mechanizm, który wymaga zgody rodzica (tutaj: administratora) przed instalacją każdej nowej aplikacji. Trochę jak w pracy, prawda?

Daje to możliwość zarządzania konkretnymi aplikacjami – tym, które mają, a które nie mają prawa zostać zainstalowane na urządzeniu. Konfiguracja po stronie rodzica jest oczywiście swobodna, może więc ulegać zmianom, jeśli ktoś posprząta w pokoju, przyniesie dobrą ocenę albo przeprowadzi staruszkę przez ulicę. Ten mechanizm Apple nazywa Ask to Buy i od tej pory obejmuje on również mikropłatności (tzw. in-app purchases, czyli zakupy wewnątrz aplikacji). Dla niewtajemniczonych: są to na przykład artefakty w grach, które ułatwiają rozgrywkę.

Ask to Browse, scenariusz rodem z Black Mirror?

Z punktu widzenia Apple jest to rozwinięcie opisanego wcześniej mechanizmu Ask to Buy. Na czym dokładnie polega? Jeśli w przeglądarce Safari nasze dziecko zechce odwiedzić nową, nieodwiedzaną wcześniej domenę, musi zaczekać na akceptację rodzica (prośba o zgodę trafia do rodzica jako powiadomienie w aplikacji Wiadomości). Mamy więc swego rodzaju domową whitelistę, niczym w firewallu.

Przyjmijmy przykład odrabiania lekcji i niedostępności rodziców. Czas realizacji zadania znacznie się wtedy wydłuży, być może nawet zmieni dalszy harmonogram dnia. Dziecko nieświadomie może w ten sposób zostać zmuszone do poszukiwania informacji wyłącznie w obrębie już odwiedzonych i zatwierdzonych stron. Efektem może być zawężenie bańki informacyjnej, w której funkcjonuje dziecko.

Funkcja jest domyślnie włączona dla wszystkich dzieci poniżej 13. roku życia ze skonfigurowaną usługą Chmura rodzinna. To oznacza, że obejmie znaczną część kont. Nie można mieć pewności, w jaki sposób rodzice będą ją dostosowywać do codziennych realiów. Jednocześnie rośnie liczba „przyjmowanych” powiadomień i czas spędzony przed ekranem, a chyba to właśnie w założeniu Apple chciało redukować. Po to powstała aplikacja Screen Time i powiadomienia związane z czasem spędzonym przed ekranem.

Wcześniejszej akceptacji rodzica będzie wymagać również każdy nowy kontakt, jaki dziecko chce dodać do swojego telefonu. De facto oznacza to, że rodzic będzie musiał akceptować każdego nowego znajomego swojej pociechy. Apple w swojej dokumentacji wprost opisuje, że dzięki tej funkcji nie trzeba ręcznie przeglądać zawartości telefonu dziecka.

Communication Safety: ochrona przed treściami

Do tej pory mechanizm nazywany przez Apple Sensitive Content Analysis miał za zadanie wykrywać nagość w lokalnych plikach takich jak zdjęcia, filmy albo załączniki do wiadomości iMessage. Funkcja istniała już od iOS 15.2. Metoda rozpoznawania treści opiera się na sieci neuronowej i jest zoptymalizowana pod procesory od A11 i M1 wzwyż. Oznacza to, że cały proces klasyfikacji obrazu odbywa się lokalnie na urządzeniu użytkownika. Dopiero manualne zgłoszenie takiej treści powoduje, że trafia ona do Apple i umożliwia jej przekazanie organom ścigania.

Communication Safety to kolejny element przygotowany pod kątem ochrony kont małoletnich, zawierający warunki i obostrzenia, o których piszę w tym tekście. Rozszerzenie umożliwia analizę wiadomości oraz połączeń FaceTime w czasie rzeczywistym. Do wykrywania nagości dochodzi rozpoznawanie „przemocy i drastycznych treści”, przy czym Apple nie ujawnia, jak dokładnie są one klasyfikowane. Obraz objęty restrykcjami zostanie rozmyty i nie wyświetlony dziecku. Jeśli oglądaliście Black Mirror na Netfliksie, być może od razu przyjdzie wam na myśl odcinek Arkangel z czwartego odcinka debiutanckiego sezonu antologii Charliego Brookera.

Jaki efekt daje Communication Safety w oparciu o framework Sensitive Content Analysis?

• Zanim dziecko zobaczy lub wyśle tak skategoryzowaną treść, otrzyma ostrzeżenie.
• Usługa włącza się automatycznie dla każdego konta poniżej 18. roku życia, gdzie dotychczas dolnym pułapem był wiek 13 lat.
• Apple udostępni pakiet dla deweloperów umożliwiający integrację tej technologii w zewnętrznych aplikacjach, jakie będą w przyszłości dostępne w App Store.

Time Allowances: wspólne ograniczenia na wszystkich urządzeniach

Kluczową zmianą jest limit korzystania z poszczególnych aplikacji oraz możliwość podzielenia ich na różne kategorie. Nowością są jednak harmonogramy aplikacji dostępnych w danych porach dnia lub tygodnia. Wszystko w ramach połączenia ustawień i limitów na wszystkich urządzeniach przypisanych do jednego profilu. To oznacza, że jeśli do tej pory mieliśmy dopuszczalne 2 godziny gier na iPadzie i 2 godziny gier na iPhonie, w praktyce oznaczało to limit 4 godzin rozrywki dziennie. Takie hakowanie systemu nie będzie już możliwe, w wyniku zmiany podejścia do zarządzania.

Przeprojektowany Screen Time

Nowy dashboard pokazuje łączny czas korzystania z konkretnych aplikacji na wszystkich urządzeniach dziecka, w przeciwieństwie do dotychczasowej listy urządzeń. To oznacza kontrolę i możliwość wyłączenia dostępu do danej aplikacji lub całej kategorii w jednej chwili. Generalnie widać, że cała zmiana polega na odejściu od nadzoru urządzeń i przejściu na monitorowanie konkretnych aktywności. Pozornie nie wydaje się kluczowa ale dla kogoś, kto korzystał z tych funkcji, będzie to zapewne uproszczenie konfiguracji.

Aby ułatwić korzystanie, część funkcjonalności trzeba było wprowadzić odgórnie. Apple chwali się współpracą z organizacjami i naukowcami badającymi wpływ technologii na dobrostan dzieci. Prawdopodobnie na podstawie ich wytycznych wprowadza predefiniowane ustawienia i rozwija swoje produkty. Tych funkcjonalności jest oczywiście więcej, a ja skupiłem się na najciekawszych zmianach. Pełne opisy funkcji z zakresu kontroli rodzicielskiej znajdują się na przeznaczonej dla rodziców stronie.

Narzędzia dla deweloperów

Firmy trzecie mogą wykorzystywać w swoich aplikacjach funkcjonalności rozwijane przez Apple. Udostępnione pakiety deweloperskie zawierają przyciski, powiadomienia, opisy techniczne i dostępy do API dla zarejestrowanych w Apple kont deweloperskich. Oto lista narzędzi udostępnionych deweloperom:

• Sensitive Content Analysis – wykrywanie nagości i przemocy przed pokazaniem treści oraz w połączeniach wideo w czasie rzeczywistym. Wraz z Communication Safety nie wymaga trenowania własnego modelu.
• Permission Kit – wymaganie zgody na dodanie nowego kontaktu również wewnątrz aplikacji firm trzecich (np. komunikatora takiego jak WhatsApp), wraz z Significant Change API, czyli możliwością wymagania ponownej zgody rodzica w określonych przypadkach (np. przy dużej zmianie regulaminu).
• Declared Age Range API – rodzic decyduje, czy udostępnić deweloperowi przedział wiekowy dziecka i metodę weryfikacji wieku (w krajach, gdzie jest to wymagane, np. w Australii).
• Framework Screen Time – twórcy aplikacji mogą budować własne blokady i mechanizmy zarządzania dostępami, które będą wyświetlane w aplikacji Screen Time.
• App Store Server Notifications – powiadomienie dla dewelopera o cofnięciu przez rodzica zgody na dostęp.

Pamiętajmy, że Apple dostarcza narzędzia, ale nie egzekwuje ich wdrożenia poza własnym ekosystemem. To oznacza, że firmy trzecie mogą, ale nie muszą ich wdrażać. Można z ciekawością spoglądać w kierunku takich producentów jak np. TikTok albo Discord.

Wymienione funkcjonalności zostały ogłoszone w czerwcu 2026 roku i mają zostać finalnie wdrożone jesienią.

Wnioski

Wymaganie akceptacji każdej nowej strony WWW przez rodzica oznacza nadzorowanie podstawowego elementu cyfrowego życia dziecka, jakim jest przeglądanie internetu. W sytuacji, gdy od lat – co robi m.in. Fundacja Orange – mówimy o edukacji w zakresie cyberhigieny opartej nie tylko na ustalonych zasadach ekranowych, ale też rozmowie z dzieckiem i wzajemnym zaufaniu. W tym przypadku to wszystko jest spłycone do powiadomienia, które można zaakceptować lub nie.

Rekomendowane przez producenta konfiguracje będą z czasem ulegać zmianom i rozszerzeniom. Nieświadomy bądź mniej zaangażowany użytkownik (w tym przypadku rodzic) będzie ulegał odgórnie narzuconym ustawieniom. Czy system da się obejść? Oczywiście. Większość dzieci używa jako podstawowych komunikatorów Instagrama, TikToka czy Discorda. Te aplikacje pozostają poza bezpośrednim zasięgiem Apple. Objęcie ich kontrolą wymagałoby wdrożenia Permission Kit przez samych twórców. Alternatywnym rozwiązaniem byłoby odebranie dziecku dostępu do codziennych metod komunikacji a następnie zmuszenia do korzystania z iMessage. W praktyce oznaczałoby to odcięcie od komunikacji ze znajomymi.

Nowe funkcje ułatwiają konfigurację. Jednak to na rodzicach spoczywa największa odpowiedzialność za edukację i rozwój swoich dzieci, a ci nie zawsze postępują rozsądnie. Pisałem na ten temat chociażby przy okazji zakończenia roku szkolnego: https://cert.orange.pl/aktualnosci/dlaczego-publikacja-zdjec-dzieci-ze-swiadectwem-to-zly-pomysl/

Źródła:

• https://www.apple.com/newsroom/2026/06/apple-previews-new-child-safety-features/
• https://developer.apple.com/kids
• https://appleinsider.com/articles/21/10/05/insiders-say-apple-health-leaders-mislead-executives-punish-staff
• https://developer.apple.com/documentation/PermissionKit
• https://developer.apple.com/documentation/sensitivecontentanalysis
• https://support.apple.com/en-us/105071
• https://developer.apple.com/documentation/sensitivecontentanalysis/detecting-nudity-in-media-and-providing-intervention-options
• https://www.apple.com/child-safety/

The post Apple wzmacnia kontrolę rodzicielską w iOS. Co zmieniają nowe funkcje dla dzieci i rodziców? appeared first on CERT Orange.

Od wejścia w życie Ustawy o zwalczaniu nadużyć w komunikacji elektronicznej, jednym z naszych codziennych zadań jest blokowanie oszukańczych SMS-ów. Prawo obliguje nas do blokowania wiadomości zgodnych z wzorcami otrzymywanymi od NASK, ale daje również dużo większe możliwości walki ze smishingiem.

Mechanizmem – z przyczyn oczywistych – nie będziemy się dzielić, ale schematem działania oszustów: jak najbardziej. Tym bardziej, że adresatami tego typu wiadomości są klienci wszystkich dostawców usług telefonii komórkowej, nie tylko Orange Polska.

Fałszywi kurierzy, podszycia pod serwisy rządowe – popularne, ale wcale nie najczęstsze

Na czym polegają najczęściej opisywane kampanie phishingu SMS?

• Nie mogliśmy dostarczyć Twojej paczki.
• Netflix Ci wygasł.
• Odbierz nadpłatę podatku (i inne warianty oparte o fałszywe strony rządowe).
• Mamo, telefon wpadł mi do sedesu.

O tych przypadkach smishingu piszemy na naszych łamach regularnie. Ten ostatni schemat funkcjonuje już od przeszło trzech lat (!), będąc zarówno najpopularniejszym jak i najtrudniejszym do zablokowania. Podszywając się pod dziecko ofiary, przestępcy używają bowiem domeny wa.me. Gdy klikniemy podany link na telefonie i posiadamy aplikację WhatsApp – zostaniemy przekierowani bezpośrednio do niej, z wpisanym numerem oszusta. To legalny mechanizm przekierowania, po prostu nadużywany przez przestępców.

Jak rozpoznać takie oszukańcze schematy?

• SMS z podszyciem pod dziecko przychodzi ze zwykłego numeru telefonu i zawiera link do strony https://wa.me/[NUMER_TELEFONU]
• W przypadku najpopularniejszego serwisu streamingowego nadawcą może być „Netflix” (ten nadpis nie jest odgórnie blokowany) lub jego wariacje z literówkami (np. Netfiix, Neltfix, itp.). Jeśli trafi do Ciebie tego typu wiadomość – wystarczy sprawdzić adres strony do której Cię kieruje.
• Oszustwa na kurierów/serwisy aukcyjne. Tu kluczem jest przekaz o „niedostarczeniu paczki” bądź „konieczności potwierdzenia sprzedaży”.
• W przypadku serwisów rządowych oszuści lawirują, by trafić w nadpis, który jeszcze nie jest odgórnie blokowany, zazwyczaj jednak zawiera ciąg „gov”, czy słowa – zależnie od tematu oszustwa – „podatki”, czy „mandat”. Tu kluczem jest sprawdzenie strony docelowej. Jeśli nie kończy się na gov.pl – mamy do czynienia z oszustwem.

Jak dużo tego typu SMS-ów trafia do naszych mechanizmów bezpieczeństwa? Wiadomości „Mamo/tato” stanowią od 5 do 10-12% treści która co tydzień trafia do systemów CERT Orange Polska. Pozostałe to zazwyczaj poniżej 1%. Co zatem stanowią pozostałe?

Kasyno, w którym (nie) czekają na Ciebie pieniądze

Pozostałe wiadomości to – jak wskazywał tytuł – agresywne reklamy kasyn. Zarówno tych zabronionych polskim prawem, jak i tych otwarcie oszukańczych. O tych drugich pisaliśmy już pół roku temu. W opisywanym schemacie w skrócie:

• dostajemy SMS-a o mającej czekać na nas nagrodzie
• klikając w link, trafiamy na stronę, gdzie możemy zakręcić kołem
• za pierwszym razem „wygrywamy” kilkaset złotych, za drugim – trafiamy już Jackpot
• po kliknięciu „odbierz nagrodę” trafiamy na… kanał na komunikatorze Telegram
• klikając w link na kanale trafiamy na kolejną stronę
• tam musimy się zarejestrować i… dokonać wpłaty, by odebrać wygraną (która okazuje się być opcją pomnożenia naszej wpłaty o 100%)
• gdy wybieramy BLIK – taki sposób pozwala zobaczyć kto jest docelowym odbiorcą – okazuje się, że nasze pieniądze trafiają do… serwisu, sprzedającego karty podarunkowe

Skąd przychodzą takie wiadomości? Za ostatni miesiąc najpopularniejsze nadpisy (tj. wyświetlana w telefonie nazwa nadawcy) to:

• Boomerang
• Westace
• Pistolo
• PLVIP
• Sofia

Warto jednak być wyczulonym również na dziwnie brzmiące wiadomości przychodzące z nadpisów będących żeńskimi imionami anglojęzycznymi. W tym przypadku oszuści wysyłają z każdego nadpisu po kilka SMS-ów, jednak samych imion jest zaskakująco dużo.

Najczęściej wykorzystywane w SMS-ach strony docelowe to:

• tr.boomerang-casino.com
• tr.westace.com
• 3kx.in
• playid.onelink.me
• tr.pistolo.com
• ibxal.link
• myslotoro.com

Charakterystyczne subdomeny tr. i cl. zawsze prowadzą do witryn powiązanych z kasynami. Dodatkowo jeśli link prowadzi Was do domeny zawierającej słowa „casino”, „spin”, „win”, czy „slot” – macie 100 procent pewności, że traficie na stronę związaną z grami losowymi.

Jak wyglądają takie wiadomości SMS

W jaki sposób oszuści chcą nas skusić do wpłaty na swoje kasyno? Oto przykłady wiadomości z ostatniego tygodnia (zachowujemy oryginalną pisownię):

• Czesc, Mariusz! Mowi Alex z obslugi klienta. Chce cie przeprosic. Dolaczylem Twoja premie w wysokosci 2000 €. Pobierz tutaj –> [adres]
• Wspinaj się wyżej po Drabinie Bonusowej i zgarnij 315% do 4 500 PLN całkowitych nagród. Zagraj w [nazwa kasyna]. [adres]
• Time to play! Your 90% bonus up to 675 PLN + 50 FS available for you at [nazwa kasyna]. [adres]
• Bonus VIP: Osiagnij szczyt w [nazwa kasyna]! Premia 255% do  5 400 PLN nalezy do Ciebie. Wspinaj sie![adres]
• Wplata na Twoje konto zostala zatwierdzona. Odblokowano 1800 darmowych spinow. Czekaja tutaj: [adres]
• Przeslalismy 7000 zl na Twoj numer telefonu (+48[numer])! Odbierz swoje pieniadze – to naprawde latwe: [adres]
• Gratulacje, [imię i nazwisko] z [miasto], jestes mistrzem! Odbierz gotowke w zaledwie 2 minuty: [adres]
• Dzis wieczorem czeka na nas 10 darmowych spinow bez depozytu: [adres]

Skąd mam wiedzieć, czy to kasyno jest legalne?

Krótką listę legalnych w Polsce podmiotów hazardowych funkcjonujących w internecie znajdziecie na poświęconej temu tematowi stronie. Jeśli jesteście klientami Orange Polska, w przypadku SMS-ów, które do Was trafiają (jeśli przemkną przez nasze systemy) możliwości co do kasyn są dwie:

• przedsięwzięcie z założenia oszukańcze (jak opisywane wyżej)
• kasyno nielegalne w rozumieniu polskiego prawa (dodatkowo zazwyczaj funkcjonujące poza prawodawstem UE, co może wykluczać dochodzenie praw klienta)

Fakt, iż zarówno oszuści jak i kasyna działające poza polskim prawem wciąż używają SMS-ów do agresywnej reklamy dowodzi, iż tego typu aktywności przynoszą im korzyści. Co je różni? Z punktu widzenia polskiego internauty nic. W obu przypadkach pieniądze stracicie na pewno. W pierwszym po prostu z założenia zostaną one ukradzione, w drugim zaś – przegrane. Nie czeka na Was żadna premia, hasło „jesteście mistrzami” nie ma nic wspólnego z prawdą, nie odbierzecie gotówki, a darmowe spiny może i dostaniecie, ale i tak docelowo niczego nie przyniosą.

Zwracajcie uwagę na takie SMS-y, ostrzeżcie o nich bliskich. A jeśli trafią do Was: nie klikajcie, nie generujcie ruchu na stronach do których prowadzą. Sprawcie, by wysyłającym po prostu przestało się to opłacać. Na koniec zawsze i tak wygrywa kasyno.

The post Nielegalne kasyna i nie tylko – jak rozpoznać SMS-y od oszustów? appeared first on CERT Orange.

Hej, przypadkowo zgłosiłem Twoje konto. Steam prowadzi właśnie jego weryfikację. Musisz jak najszybciej napisać do administratora, zanim dostaniesz bana.

Brzmi znajomo? 

Jeżeli korzystasz ze Steama, istnieje spora szansa, że podobna wiadomość trafiła kiedyś również do Ciebie. Być może wysłała ją osoba z listy znajomych. Być może ktoś zupełnie obcy. Czasami rozmowa zaczyna się od pytania o ulubioną klasę w Team Fortress 2. Innym razem od propozycji udziału w turnieju Counter-Strike’a lub atrakcyjnej wymiany skinów. Schematów jest wiele, ale cel pozostaje niezmienny – przejąć Twoje konto lub ukraść wartościowe przedmioty. 

Konto Steam jest warte więcej, niż myślisz 

Jeszcze kilka lat temu przejęcie konta do gry oznaczało głównie utratę postępów. Dzisiaj sytuacja wygląda zupełnie inaczej. W wielu popularnych tytułach przedmioty posiadają realną wartość rynkową. Szczególnie dobrze widać to w przypadku Counter-Strike’a (CS), gdzie niektóre skiny osiągają ceny porównywalne z wartością samochodu. To właśnie dlatego gracze CS-a należą do najczęściej atakowanych grup użytkowników. 

Podobnie wygląda sytuacja w Team Fortress 2 (TF2), gdzie od wielu lat funkcjonuje rozbudowany rynek wymiany przedmiotów. Tam również wartościowe przedmioty stały się celem licznych kampanii phishingowych i oszustw. 

Dla cyberprzestępcy przejęte konto może oznaczać kilka różnych możliwości zarobku: 

• sprzedaż całego konta,  
• sprzedaż skinów i przedmiotów,  
• wykorzystanie konta do dalszych oszustw,  
• rozsyłanie wiadomości do znajomych ofiary,  
• prowadzenie kolejnych kampanii phishingowych.  

I właśnie ten ostatni element jest szczególnie interesujący. Wyobraźmy sobie, że otrzymujesz wiadomość od osoby, z którą grasz od kilku lat. Widzisz znajomy avatar, nazwę użytkownika i historię wcześniejszych rozmów. Naturalnie zakładasz, że rozmawiasz z tą samą osobą. 

Tymczasem konto mogło zostać przejęte kilka godzin wcześniej. 

„Przypadkowo zgłosiłem Twoje konto” – klasyk wśród oszustw 

To prawdopodobnie najpopularniejszy scenariusz wykorzystywany przeciwko użytkownikom Steama. Mimo że jest znany od lat, nadal pojawia się w nowych odsłonach i wciąż znajduje kolejne ofiary. 

Schemat zazwyczaj wygląda bardzo podobnie. Użytkownik otrzymuje zaproszenie do znajomych lub wiadomość od osoby, która twierdzi, że przez pomyłkę zgłosiła jego konto do Steam Support. Nadawca przeprasza za swoją pomyłkę i zapewnia, że sytuację można szybko wyjaśnić. W tym celu prosi o kontakt z rzekomym administratorem Steama, przesyłając jego profil lub kontakt na Discordzie. 

Po nawiązaniu kontaktu z rzekomym administratorem rozmowa przybiera bardziej formalny charakter. Oszust może poprosić o nazwę użytkownika, adres e-mail przypisany do konta, kod przesłany przez Steam Guard lub hasło. 

Istnieje także odmiana skierowana do osób handlujących przedmiotami. W tej wersji użytkownik dowiaduje się, że jego konto zostało zgłoszone z powodu posiadania rzekomo zduplikowanych przedmiotów. Aby uniknąć blokady, ma przekazać swoje skiny specjalnemu botowi, który przeprowadzi ich „weryfikację”. Oczywiście po zaakceptowaniu wymiany przedmioty trafiają do cyberprzestępcy i już nie wracają. 

Okiem analityka CTI 

Ten scenariusz jest niezwykle skuteczny, ponieważ wykorzystuje dwa silne mechanizmy psychologiczne. Pierwszym jest autorytet a drugim strach przed utratą konta, zwłaszcza jeśli użytkownik posiada na nim gry lub przedmioty kolekcjonerskie. 

Warto pamiętać, że Steam nie posiada administratorów kontaktujących się z użytkownikami przez czat, Discord czy Telegram. Oficjalne wsparcie techniczne prowadzone jest wyłącznie przez system Steam Support. Pracownicy Steam nigdy nie poproszą również o hasło ani kody uwierzytelniające. 

„Too good to be true” 

Niektóre kampanie rozpoczynają się jeszcze prościej. 

Do użytkownika wysyłane jest zaproszenie od atrakcyjnie wyglądającego profilu. Rozmowa początkowo nie wzbudza żadnych podejrzeń. Dopiero po kilku wiadomościach pojawia się propozycja przejścia na inną platformę komunikacyjną – najczęściej Telegram lub Discord. 

Dlaczego? 

Po pierwsze, cyberprzestępcy zyskują większą swobodę działania. W takiej sytuacji łatwiej też jest przesyłać linki prowadzące do fałszywych stron logowania. Po trzecie zaś – ofiara zaczyna odnosić wrażenie, że prowadzi prywatną rozmowę poza oficjalną platformą. 

Sam fakt otrzymania zaproszenia do rozmowy poza Steamem nie oznacza jeszcze próby oszustwa. Warto jednak zachować szczególną ostrożność, jeśli rozmówca bardzo szybko zaczyna namawiać do kliknięcia przesłanego linku, logowania się do zewnętrznego serwisu lub pobrania pliku. 

Brakuje nam jednego gracza 

Gracze CS-a i TF2 od lat należą do najczęściej atakowanych społeczności na Steamie. W obu przypadkach nie bez znaczenia pozostaje aktywny rynek przedmiotów oraz duża liczba osób angażujących się w rozgrywki rankingowe i turniejowe. 

Jednym z najpopularniejszych scenariuszy jest tzw. scam turniejowy. Rozmowa często rozpoczyna się od pytania: 

„Jaką klasą grasz w Team Fortress 2?” 

albo 

„Grasz jeszcze w CS-a?” 

Po krótkiej wymianie wiadomości rozmówca informuje, że jego drużynie brakuje jednego zawodnika do turnieju z atrakcyjną pulą nagród. W innych wariantach prosi jedynie o oddanie głosu na swoją drużynę lub wsparcie znajomych w trwających rozgrywkach. Historia może być uwiarygadniana dodatkowymi szczegółami np. tłumaczenie, że jeden z zawodników zachorował i drużyna pilnie szuka zastępstwa. Im bardziej wiarygodna historia, tym większa szansa, że ofiara kliknie przesłany link. 

Po wejściu na stronę użytkownik trafia na profesjonalnie wyglądający serwis turniejowy. Znajduje tam przycisk logowania przez Steam, który w rzeczywistości prowadzi do fałszywej strony przechwytującej dane uwierzytelniające. Czasami w teorii jest opcja założenia nowego konta. Po rozpoczęciu procesu rejestracji użytkownik może zostać poinformowany, że konieczne jest potwierdzenie numeru telefonu za pomocą wiadomości SMS. Taki dodatkowy krok ma uwiarygodnić cały proces i sprawić wrażenie, że serwis stosuje standardowe mechanizmy bezpieczeństwa wykorzystywane podczas organizacji turniejów. 

W rzeczywistości zamiast oczekiwanego etapu weryfikacji SMS wyświetlane jest okno logowania do Steam. Może ono wyglądać bardzo wiarygodnie, dlatego użytkownik odnosi wrażenie, że loguje się do oficjalnej usługi.

Okiem analityka CTI 

To dobry przykład kampanii, która nie wymaga zaawansowanych technik. Strona internetowa może wyglądać bardzo profesjonalnie, ale jej jedynym zadaniem jest wyłudzenie danych logowania. W praktyce cyberprzestępcy inwestują znacznie więcej czasu w rozmowy niż na przygotowanie strony phishingowej. 

Zaufanie do znanych platform 

FACEIT – serwis, który umożliwia udział w rozgrywkach rankingowych, turniejach oraz meczach organizowanych poza oficjalnym matchmakingiem gry i od lat cieszy się dużą popularnością wśród bardziej zaawansowanych graczy CS-a. 

Jednym z obserwowanych obecnie scenariuszy jest tworzenie stron internetowych podszywających się pod proces weryfikacji konta lub rejestracji do turnieju. Ich adresy często zawierają słowo faceit, uzupełnione o dodatkowe wyrazy lub losowe ciągi znaków. Na pierwszy rzut oka mogą wyglądać wiarygodnie, zwłaszcza jeśli użytkownik nie zwróci uwagi na pełną nazwę domeny. 

Po wejściu na stronę użytkownik jest proszony o weryfikację tożsamości przez zalogowanie się do Steam. Cały proces wygląda profesjonalnie i sprawia wrażenie elementu standardowej procedury bezpieczeństwa. W rzeczywistości celem jest przechwycenie danych logowania do konta Steam. 

Okiem analityka CTI 

Obecnie interfejs bywa niemal identyczny z oryginałem. Znacznie ważniejsze staje się sprawdzenie pełnego adresu strony oraz zastanowienie się, czy logowanie do Steam rzeczywiście jest potrzebne do wykonania danej czynności. 

Darmowa karta podarunkowa? 

Użytkownik otrzymuje informację o możliwości odebrania darmowej karty podarunkowej lub wyjątkowej promocji. Zachętą może być atrakcyjna grafika, ograniczony czas trwania oferty lub informacja o specjalnej akcji przygotowanej z okazji wydarzenia w świecie gier. 

Coraz częściej wykorzystywane są również kody QR, które mają ułatwić przejście do strony z ofertą. To rozwiązanie jest wygodne, ale jednocześnie utrudnia ocenę, dokąd rzeczywiście prowadzi odnośnik. 

Po zeskanowaniu kodu użytkownik trafia na stronę, która tylko z pozoru przypomina serwis społeczności Steam. Dopiero dokładniejsze sprawdzenie adresu pokazuje, że nie znajduje się ona w domenie Steam Community.

W zależności od scenariusza użytkownik może zostać poproszony o zalogowanie się do Steam, podanie kodu aktywacyjnego lub pobranie dodatkowego pliku niezbędnego do odebrania nagrody. 

Pobierany plik jednak nie zawiera żadnej karty podarunkowej. Zamiast tego instalowane jest złośliwe oprogramowanie, którego zadaniem jest kradzież danych zapisanych na komputerze użytkownika. 

Okiem analityka CTI 

Choć przynęta może być różna – darmowa karta podarunkowa, weryfikacja FACEIT czy udział w turnieju – bardzo często końcowy etap wygląda podobnie. Użytkownik jest nakłaniany do pobrania pliku lub zalogowania się na fałszywej stronie. Pozornie różne kampanie często prowadzą do tego samego celu – przejęcia konta, przedmiotów lub zainstalowania złośliwego oprogramowania. 

Nie każde zagrożenie zaczyna się od wiadomości 

Większość opisanych wcześniej scenariuszy opiera się na socjotechnice. Cyberprzestępca nawiązuje kontakt z ofiarą, buduje wiarygodną historię i próbuje skłonić ją do zalogowania się na fałszywej stronie. 

Nie oznacza to jednak, że jest to jedyny sposób ataku. 

Zdarzają się sytuacje, w których użytkownik sam pobiera plik lub uruchamia aplikację, nie mając świadomości, że zawiera ona złośliwy kod. Dobrym przykładem jest opisywana w Krajobrazie Zagrożeń kampania wykorzystująca Wallpaper Engine. 

Wallpaper Engine to popularna aplikacja dostępna na Steamie, pozwalająca użytkownikom tworzyć i pobierać animowane tapety pulpitu. Jej ogromną zaletą jest aktywna społeczność oraz możliwość udostępniania własnych projektów poprzez Steam Workshop. To właśnie ten mechanizm został wykorzystany przez cyberprzestępców. 

W analizowanej kampanii złośliwy kod został ukryty w pliku projektu udostępnionym jako tapeta. Użytkownik, który pobrał i uruchomił przygotowaną przez napastników zawartość, mógł nieświadomie uruchomić również złośliwe oprogramowanie. 

Choć tego typu przypadki należą do rzadkości, pokazują one ważną rzecz – zagrożenie nie zawsze musi pochodzić z wiadomości prywatnej lub fałszywej strony internetowej. 

Innym przykładem była kampania wykorzystująca grę BlockBlasters, która przez pewien czas była dostępna na Steamie. Gra posiadała kartę produktu, materiały promocyjne i była dostępna do pobrania jak każda inna pozycja na platformie. 

Problem pojawiał się dopiero po jej uruchomieniu. Końcowym etapem ataku było zainstalowanie na komputerze użytkownika infostealera – rodzaju złośliwego oprogramowania wyspecjalizowanego w kradzieży danych. 

Dla ofiary oznacza to, że skutki infekcji mogą wykraczać daleko poza utratę samego konta Steam. Przejęte mogą zostać również konta pocztowe, media społecznościowe czy inne usługi, do których użytkownik logował się z tego samego komputera. 

Okiem analityka CTI 

Wallpaper Engine to dobry przykład tzw. łańcucha zaufania.

Użytkownik ufa platformie Steam -> Platforma udostępnia popularną aplikację -> Aplikacja umożliwia publikowanie treści tworzonych przez społeczność. -> Cyberprzestępca próbuje wykorzystać zaufanie wstawiając szkodliwe treści.

Nie oznacza to, że sama aplikacja jest złośliwa. Wręcz przeciwnie – problemem staje się możliwość dostarczenia szkodliwej zawartości przez osoby trzecie.

Praktyczne rekomendacje ochrony konta Steam 

• Włącz Steam Guard

  Steam Guard to mechanizm uwierzytelniania wieloskładnikowego (MFA). Dzięki niemu samo poznanie hasła przez cyberprzestępcę nie wystarczy do zalogowania się na konto.

  Jeżeli jeszcze z niego nie korzystasz, warto włączyć go jak najszybciej. Pamiętaj jednak, że nawet Steam Guard nie ochroni Cię, jeśli sam zatwierdzisz logowanie lub przekażesz kod oszustowi.

• Nigdy nie podawaj haseł ani kodów uwierzytelniających

  Pracownicy Steam Support nigdy nie poproszą Cię o:

  • hasło do konta,
  • kod przesłany e-mailem,
  • kod ze Steam Guard,
  • przekazanie dostępu do konta.

  Jeżeli ktoś przedstawia się jako administrator Steama i oczekuje takich informacji, możesz mieć pewność, że masz do czynienia z próbą oszustwa.

• Ostrożność wobec nieoczekiwanych wiadomości

  Otrzymanie wiadomości od nieznanej osoby nie musi oznaczać próby oszustwa. Powinno jednak wzbudzić czujność, zwłaszcza gdy rozmówca:

  • twierdzi, że przypadkowo zgłosił Twoje konto,
  • namawia do przejścia na Telegram lub Discord,
  • prosi o oddanie głosu na drużynę,
  • zaprasza do turnieju,
  • proponuje wyjątkowo korzystną wymianę,
  • wywiera presję czasu.

  To właśnie presja i emocje są jednymi z najczęściej wykorzystywanych narzędzi socjotechniki.

• Weryfikacja linków

  Sprawdź pełny adres strony internetowej. Cyberprzestępcy często wykorzystują domeny bardzo podobne do oryginalnych, licząc na to, że użytkownik nie zauważy różnicy.

• Zanim się zalogujesz, zatrzymaj się na chwilę

  Warto zadać sobie jedno pytanie:

  „Dlaczego ta strona w ogóle prosi mnie o zalogowanie do Steam?”

• Uważaj na pliki pobierane spoza zaufanych źródeł

  Nie wszystkie zagrożenia kończą się na phishingu. Jeżeli strona zachęca Cię do pobrania dodatkowego programu, pliku wykonywalnego lub archiwum ZIP w celu odebrania nagrody, uruchomienia turnieju czy aktywacji karty podarunkowej, potraktuj to jako sygnał ostrzegawczy.

• Chroń konto e-mail

  Warto pamiętać, że konto Steam jest silnie powiązane z adresem e-mail.

  Jeżeli cyberprzestępca przejmie skrzynkę pocztową, zyskanie dostępu do wielu usług może stać się znacznie łatwiejsze dla oszusta. Dlatego konto e-mail również powinno być zabezpieczone silnym, unikalnym hasłem oraz uwierzytelnianiem wieloskładnikowym.

• Nie bój się przerwać rozmowy

  Cyberprzestępcy bardzo często próbują wywołać poczucie pilności.

  • „Masz tylko kilka minut.”
  • „Za chwilę konto zostanie zablokowane.”
  • „Musimy szybko zweryfikować Twoje przedmioty.”

  Przerwij rozmowę. Zweryfikuj informacje w oficjalnych kanałach. Skontaktuj się ze znajomym innym sposobem, jeśli wiadomość pochodzi z jego konta. Kilka minut poświęconych na sprawdzenie sytuacji może uchronić Cię przed utratą konta lub cennych przedmiotów.

To pierwszy artykuł z serii poświęconej bezpieczeństwu graczy. W kolejnych częściach przyjrzymy się innym platformom, usługom i metodom wykorzystywanym przez cyberprzestępców, pokazując, jak rozpoznawać zagrożenia i skutecznie się przed nimi chronić. 

The post Odblokowano osiągnięcie: przejęte konto Steam  appeared first on CERT Orange.