Krajobraz zagrożeń 12-18/02/2026

Obecny krajobraz zagrożeń jest definiowany przez systematyczną eksploatację zaufania – fundamentu, na którym opierają się zarówno procesy technologiczne, jak i relacje na linii obywatel – państwo. W bieżącym wydaniu obserwujemy jak to zaufanie staje się wektorem ataku w trzech opisywanych obszarach. Przyglądamy się transformacji popularnego środowiska deweloperskiego w dyskretne narzędzie do komunikacji z infrastrukturą cyberprzestępców, działając wewnątrz zaufanych procesów. Weryfikujemy również bezpieczeństwo podstaw naszej cyfrowej higieny, przywołując badania podważające deklarowaną niezawodność chmurowych menadżerów haseł i wskazując na ryzyka ukryte w modelach ochrony danych. Całość dopełnia analiza lokalnych kampanii phishingowych, które wykorzystują zaufanie do polskiej administracji skarbowej, podszywając się pod najważniejsze mechaniczny państwowe takie jak system KSeF czy rozliczenia e-PIT.

Cybercrime

Twój VS Code Cię zdradza?

Visual Studio Code to przykład narzędzia, które przekształciło się w niemal autonomiczne środowisko deweloperskie, często pozostające poza zasięgiem standardowych mechanizmów detekcyjnych SOC. Bezgraniczna swoboda, jaką VS Code daje programistom, wyprzedziła zdolności organizacji do nadzorowania tego, co dzieje się wewnątrz edytora, otwierając lukę, którą trudno załatać standardowymi narzędziami kontroli. Domyślne szerokie uprawnienia do systemu plików i terminali sprawiają, iż środowisko to staje się uprzywilejowanym i trudnym do wykrycia punktem wejścia do infrastruktury, zwłaszcza gdy zespoły SOC koncentrują się na typowych kanałach, takich jak poczta czy przeglądarki. Ryzyko to potęguje paradoks zaufania do oficjalnego Marketplace’u – miliony pobrań nie są równoznaczne z rzetelnym audytem bezpieczeństwa, a popularność wtyczki czyni ją atrakcyjnym celem dla ataków na łańcuch dostaw, zamieniając warsztat pracy inżyniera w nieautoryzowany terminal łączący stację roboczą z infrastrukturą organizacji.

Podatności w zaufanym ekosystemie

Zagrożenia zakorzenione w ekosystemie rozszerzeń wynikają przede wszystkim z faktu, iż operują one poza tradycyjnym sandboxem, wchodząc w interakcje z hostem na poziomie uprawnień zalogowanego użytkownika. Skala tego ryzyka jest ogromna, gdy spojrzymy na rozszerzenie Live Server, które posiada ponad 72 miliony instalacji. Podatność CVE-2025-65717 w rozszerzeniu Live Server umożliwia złośliwej stronie internetowej odpytywanie uruchomionego lokalnie serwera deweloperskiego. W scenariuszu, w którym użytkownik odwiedzi złośliwy adres URL przy aktywnym Live Server, atakujący może doprowadzić do nieautoryzowanego odczytu i eksfiltracji zasobów udostępnianych przez serwer — w tym kodu źródłowego, plików konfiguracyjnych, zmiennych środowiskowych (.env), kluczy API, a także innych lokalnych artefaktów i logów dostępnych w kontekście projektu.

Sytuację pogarsza fakt, iż proces usuwania tych podatności jest skrajnie nieefektywny. Mimo iż badacze raportowali te błędy już w czerwcu 2025 roku, najważniejsze problemy pozostają otwarte. Szczególnie alarmujący jest przypadek wtyczki Code Runner (37 mln instalacji) oraz Markdown Preview Enhanced (8,5 mln instalacji). Mimo, iż miliony deweloperów codziennie korzystają z narzędzi podatnych na zdalne wykonanie kodu, ich autorzy całkowicie zignorowali zgłoszenia, co wpisuje się w szerszy trend bierności, obserwowany również w przypadku Live Server. w tej chwili publicznie dostępne są kody eksploitów (PoC), które stanowią gotowe schematy ataków. Pokazują one wprost, jak dzięki zatrutego repozytorium lub manipulacji plikiem settings.json doprowadzić do wykonania kodu w kontekście zalogowanego użytkownika, co w środowiskach z podwyższonymi uprawnieniami może skutkować faktycznym przejęciem stacji roboczej.

VS Code jako narzędzie Command & Control

Tak szerokie pole ataku zostaje dopełnione przez funkcjonalność, która w rękach atakującego zmienia VS Code w klasyczny przykład narzędzia klasy LOLBin (Living Off the Land Binary). Mowa o funkcji Remote Tunnels, która pozwala na zestawienie szyfrowanego połączenia C2 przy użyciu podpisanych, zaufanych plików wykonywalnych Microsoftu. Atakujący, po uzyskaniu wstępnego dostępu do maszyny, nie musi instalować jawnie złośliwego systemu – wystarczy, iż wykorzysta istniejącą instalację lub uruchomi przenośną wersję edytora dzięki prostej komendy code tunnel. Taka aktywność z natury umyka standardowym sygnaturom systemów AV i EDR, ponieważ proces jest uznawany za legalny, certyfikowany składnik środowiska programistycznego.

Kluczowym elementem tej strategii jest mechanizm uwierzytelniania, który pozwala cyberprzestępcy na wykorzystanie własnego, osobistego konta GitHub lub Microsoft Entra ID do uruchomienia tunelu sieciowego. W praktyce oznacza to ominięcie korporacyjnych polityk dostępowych i mechanizmów warunkowego dostępu (Conditional Access), ponieważ uwierzytelnienie odbywa się przy użyciu zewnętrznej tożsamości kontrolowanej przez atakującego. Skuteczność tej metody potwierdzają kampanie grup APT realizowane w ostatnich latach. W 2023 roku grupa Mustang Panda wykorzystała VS Code w operacjach szpiegowskich wymierzonych w instytucje rządowe w Azji Południowo-Wschodniej. Atakujący dostarczali na stacje robocze ofiar pliki ZIP zawierające przenośną wersję code.exe oraz złośliwe biblioteki DLL wykorzystywane do techniki DLL side-loading. Po uruchomieniu tunelu dzięki własnych tokenów GitHub, atakujący uzyskiwali stały, szyfrowany kanał dostępu. Ruch generowany przez tunel jest szyfrowany i kierowany do zaufanych domen Microsoftu, co znacząco utrudnia jego odróżnienie od rutynowej aktywności deweloperskiej i sprzyja długotrwałemu utrzymaniu obecności w sieci bez wzbudzania oczywistych alertów.

Jeszcze bardziej precyzyjny schemat działania zidentyfikowano w ramach Operation Digital Eye (przełom czerwca i lipca 2024 r.), kampanii przypisywanej chińskim grupom APT, której celem była kompromitacja krytycznej infrastruktury cyfrowej w Europie Południowej m.in. we Włoszech. Atak wymierzony był w dużych dostawców usług IT typu B2B, którzy zarządzają danymi i infrastrukturą dla klientów z wielu branż. Po wstępnej infekcji serwerów bazodanowych dzięki narzędzia sqlmap i wdrożeniu backdoorów takich jak ShadowPad, VS Code był użyty jako pomocniczy kanał komunikacji. Wykorzystanie legalnej domeny visualstudio.com umożliwiło atakującym rekonesans, lateral movement oraz omijanie polityk firewalli, czyniąc z IDE narzędzie do infiltracji łańcucha dostaw i pozyskiwania poświadczeń.

AI i ShadowIT

Brak centralnego nadzoru nad rozszerzeniami w VS Code jest klasycznym przykładem Shadow IT w środowisku deweloperskim. Ryzyko to rośnie wraz z popularyzacją asystentów AI, takich jak Claude czy Cline, integrowanych bezpośrednio z edytorem. Narzędzia te działają w kontekście uprawnień użytkownika i – w zależności od konfiguracji – mogą sugerować instalację dodatkowych wtyczek, generować komendy powłoki lub uzyskiwać szeroki dostęp do plików projektu. Choć nie instalują komponentów w pełni autonomicznie, półautomatyczne mechanizmy akceptacji oraz rutynowe zatwierdzanie rekomendacji przez użytkowników istotnie obniżają próg bezpieczeństwa operacyjnego.

W przypadku kompromitacji rozszerzenia, przejęcia tokenów API lub prompt injection, atakujący może uzyskać dostęp do wszystkich zasobów dostępnych w kontekście zalogowanego użytkownika. Nie oznacza to automatycznej eskalacji uprawnień systemowych, jednak przy administracyjnych uprawnieniach lokalnych lub aktywnych tokenach chmurowych skutki mogą być porównywalne z przejęciem uprzywilejowanej stacji roboczej. Dodatkowo możliwość konfiguracji zdalnego tunelu jako trwałej usługi systemowej stwarza stały kanał komunikacji endpoint-to-cloud, który trudno wykryć, a który może posłużyć do lateral movement, pozyskiwania poświadczeń i pivotu do zasobów chmurowych oraz systemów CI/CD organizacji

Od zaufania do aktywnego nadzoru

Zapewnienie bezpieczeństwa nowoczesnego środowiska programistycznego wymaga proaktywnych działań – przejście od modelu domyślnego zaufania do monitorowania procesów wewnątrz IDE. Dla zespołów bezpieczeństwa rekomendujemy kompleksowe podejście obejmujące zarówno kontrolę nad funkcją tunelowania, jak i monitoring środowiska deweloperskiego. W środowiskach, które nie wymagają użycia Dev Tunnels, warto całkowicie wyłączyć tę funkcjonalność, a tam, gdzie jest konieczna, ograniczyć możliwość logowania wyłącznie do autoryzowanych instancji (tenantów), jednocześnie monitorując próby uruchomienia nieautoryzowanych tuneli. Zalecane jest filtrowanie połączeń wychodzących z procesów VS Code, takich jak code.exe i devtunnel.exe, oraz alertowanie w systemach SIEM i EDR w przypadku zestawienia tunelu do nieznanych domen lub adresów IP. Warto rozważyć monitorowanie nietypowych zmian w plikach konfiguracyjnych IDE, takich jak settings.json, oraz w katalogach rozszerzeń, a także flagowanie uruchamiania procesów z nietypowymi argumentami, np. –accept-server-license-terms. Dodatkowo, warto wdrożyć centralną politykę dopuszczającą instalację jedynie zweryfikowanych wtyczek.

Więcej informacji:
https://www.ox.security/blog/cve-2025-65717-live-server-vscode-vulnerability/
https://www.ox.security/blog/cve-2025-65716-markdown-preview-enhanced-vscode-vulnerability/
https://www.ox.security/blog/cve-2025-65715-code-runner-vscode-rce/
https://newtonpaul.com/blog/vscode-remote-tunnels-abuse-and-detections/
https://unit42.paloaltonetworks.com/stately-taurus-abuses-vscode-southeast-asian-espionage/
https://www.sentinelone.com/labs/operation-digital-eye-chinese-apt-compromises-critical-digital-infrastructure-via-visual-studio-code-tunnels/

Podatności

Menadżery haseł nie są „magicznie bezpieczne”

Współczesne menadżery haseł od lat są przedstawiane jako fundament higieny cyberbezpieczeństwa – narzędzia, które rozwiązują problem słabych, powtarzalnych haseł i umożliwiają stosowanie unikalnych, silnych danych uwierzytelniających w każdej usłudze. Jednak najnowsze badania naukowe oraz rzeczywiste incydenty bezpieczeństwa pokazują, iż krajobraz zagrożeń związany z ich używaniem jest znacznie bardziej złożony, niż sugerowałaby to marketingowa narracja o pełnej poufności.

Punktem wyjścia do tej refleksji są badania opublikowane przez naukowców z ETH Zurich, opisane w artykule „Password managers less secure than promised” z 2026 roku. „Zero Knowledge Encryption” to termin powszechnie używany przez dostawców chmurowych menedżerów haseł. Choć nie ma on ścisłego znaczenia technicznego, pojęcie to ma sugerować, iż serwer – który przechowuje zaszyfrowane bazy danych haseł użytkowników – nie jest w stanie uzyskać żadnych informacji o ich zawartości. Deklaracje bezpieczeństwa składane przez dostawców implikują, iż założenie to powinno pozostawać prawdziwe choćby w sytuacji, gdy serwer zachowuje się w pełni złośliwie. Taki model zagrożeń jest w praktyce uzasadniony wysoką wrażliwością danych przechowywanych w sejfach haseł.

Eksperci przeanalizowali architekturę popularnych chmurowych menedżerów haseł, wykazując, iż deklarowany model bezpieczeństwa w praktyce może być podatny na nadużycia. Badanie zostało zaprojektowane w oparciu o jawnie wrogi model zagrożeń (malicious server threat model), który znacząco wykracza poza standardowe założenia przyjmowane przez dostawców menedżerów haseł. Zamiast zakładać, iż serwer jest bezpieczny, badacze przyjęli, iż jest w pełni skompromitowany lub działa intencjonalnie złośliwie, a mimo to system deklarujący Zero Knowledge Encryption powinien chronić poufność i integralność danych użytkownika.

Naukowcy przeprowadzili symulacje na własnej infrastrukturze udającej zhakowane serwery Bitwarden, LastPass i Dashlane. Na serwerach, które emulowały zachowanie skompromitowanej infrastruktury dostawcy, uzyskano praktyczne potwierdzenie podatności. Serwery te generowały spreparowane odpowiedzi API, manipulowały strukturami danych sejfu, kluczami oraz metadanymi w sposób zgodny z protokołem, ale sprzeczny z jego intencją bezpieczeństwa. Ataki były projektowane tak, aby wykorzystywały wyłącznie rutynowe czynności wykonywane przez użytkowników, takie jak logowanie, otwieranie sejfu, synchronizacja danych, dołączanie do organizacji czy korzystanie z funkcji współdzielenia haseł.

Wyniki badań jednoznacznie wykazały, iż deklarowana odporność na złośliwy serwer nie jest spełniona w żadnym z analizowanych produktów. Łącznie zidentyfikowano kilkadziesiąt podatności umożliwiających naruszenie poufności i integralności sejfów, w tym ataki prowadzące do odzyskania haseł w postaci jawnej oraz do pełnej kompromitacji sejfów organizacyjnych.

Pierwszym fundamentalnym problemem jest nadmierne zaufanie do kontekstu kryptograficznego dostarczanego przez serwer. Klient w wielu scenariuszach przyjmuje od backendu informacje dotyczące struktury sejfu, relacji między obiektami, identyfikatorów kluczy czy metadanych organizacyjnych i nie posiada wystarczających mechanizmów weryfikacji ich autentyczności oraz integralności. O ile same dane są szyfrowane, o tyle ich „oprawa logiczna” pozostaje pod kontrolą serwera. Złośliwy backend może więc manipulować kontekstem w sposób zgodny z protokołem, ale prowadzący do ujawnienia haseł lub naruszenia integralności sejfu.

Drugą przyczyną jest błędne założenie projektowe, iż serwer nie jest aktywnie wrogi. W efekcie wiele mechanizmów – zwłaszcza synchronizacja, odzyskiwanie konta, współdzielenie haseł czy obsługa organizacji – zostało zaprojektowanych tak, aby upraszczać operacje backendowe kosztem silnej weryfikacji po stronie klienta. To prowadzi do sytuacji, w której kryptografia chroni zawartość pojedynczych obiektów, ale nie zabezpiecza całej logiki systemu przed manipulacją.

Ostatnim wskazanym kluczowym źródłem podatności jest złożoność funkcjonalna nowoczesnych menedżerów haseł. Funkcje takie jak współdzielenie wpisów, rotacja kluczy, dostęp organizacyjny, delegowanie uprawnień czy odzyskiwanie dostępu wprowadzają dodatkowe warstwy szyfrowania i zależności. Każda z tych warstw zwiększa powierzchnię ataku i tworzy nowe punkty, w których serwer może wpływać na stan klienta. W wielu przypadkach to właśnie mechanizmy „enterprise” okazały się najbardziej podatne, ponieważ wymagały bardziej skomplikowanego zarządzania kluczami i metadanymi.

Istotnym czynnikiem są również anty-wzorce kryptograficzne i zaszłości historyczne. Część rozwiązań wywodzi się z architektur projektowanych w latach dziewięćdziesiątych i wczesnych dwutysięcznych, kiedy nie zakładano w systemach możliwości kompromitacji serwera. W efekcie zastosowano konstrukcje, które są matematycznie poprawne, ale nie zapewniają odporności na aktywną manipulację kontekstem przez backend.

Badania wykazały fundamentalne ryzyko systemowe: menedżer haseł centralizuje najbardziej wrażliwe dane użytkownika – dostęp do bankowości, poczty, systemów korporacyjnych, kluczy API, danych tożsamościowych – w jednym repozytorium. W przypadku kompromitacji tego repozytorium skutki są kaskadowe.

Realnym potwierdzeniem tego scenariusza był incydent związany z LastPass w 2022 roku. Atakujący uzyskali dostęp do środowiska developerskiego, a następnie, wykorzystując skradzione dane uwierzytelniające oraz tokeny, dotarli do zasobów w chmurze – w tym do kopii zapasowych zawierających zaszyfrowane sejfy użytkowników oraz metadane. Choć same hasła były szyfrowane, wyciek objął m.in. adresy e-mail, URL-e serwisów, dane kontaktowe i inne informacje pomocnicze. Incydent ten udowodnił, iż choćby jeżeli kryptografia nie zostanie bezpośrednio złamana, przejęcie warstwy serwerowej lub łańcucha dostaw aplikacji dostawcy generuje poważne ryzyko operacyjne i reputacyjne, a w dłuższej perspektywie może umożliwić ataki offline na słabo zabezpieczone sejfy (np. przy użyciu słabego hasła głównego).

Warto podkreślić, iż model chmurowy nie jest jedynym obszarem ryzyka. Popularne rozwiązania desktopowe, takie jak KeePass, również doświadczyły problemów bezpieczeństwa. W kontekście podatności CVE-2023-24055 wskazywano możliwość eksportu konfiguracji w sposób, który przy spełnieniu określonych warunków mógł prowadzić do ujawnienia bazy haseł w postaci jawnej. Choć twórcy argumentowali, iż atak wymaga już uprzedniego przejęcia uprawnień administracyjnych systemu, incydent ten unaocznił inną klasę ryzyka: jeżeli komputer zostaje przejęty (np. przez malware), menedżer haseł staje się atrakcyjnym celem dla adwersarza.

Dodatkową warstwą zagrożeń są ataki aplikacyjne i przeglądarkowe. Wiele menedżerów haseł integruje się z przeglądarką poprzez rozszerzenia i funkcję autowypełniania. Mechanizmy te, choć zwiększają wygodę użytkownika, jednocześnie tworzą nowe powierzchnie ataku – od manipulacji DOM, przez clickjacking, aż po wymuszanie wypełnienia formularzy w kontekście kontrolowanym przez atakującego. W określonych scenariuszach może to prowadzić do wycieku danych uwierzytelniających bez konieczności uzyskiwania dostępu do samej bazy haseł.

W krajobrazie zagrożeń nie można także pomijać czynnika ludzkiego. Siła menedżera haseł w dużej mierze zależy od jakości hasła głównego, zastosowania uwierzytelniania wieloskładnikowego oraz poprawnej konfiguracji. W przypadku słabego hasła głównego, wyciek zaszyfrowanej bazy – jak pokazały doświadczenia po incydencie LastPass – może umożliwić skuteczne ataki brute-force offline. Użytkownicy często przeceniają bezpieczeństwo narzędzia, zakładając, iż sam fakt korzystania z menedżera haseł eliminuje ryzyko, podczas gdy w praktyce bezpieczeństwo jest funkcją całego łańcucha: infrastruktury dostawcy, implementacji kryptografii, bezpieczeństwa komputera oraz świadomości użytkownika.

Mimo nieco smutnych wniosków płynących z przedstawionych badań i dotychczasowych incydentów, menadżery haseł nie przestają być rozwiązaniem rekomendowanym z perspektywy higieny bezpieczeństwa – w większości przypadków są to rozwiązania bezpieczniejsze. Jednak z perspektywy analizy zagrożeń należy brać pod uwagę ich kompromitację i poważne implikacje z niej wynikające. Model bezpieczeństwa – zwłaszcza w wersji chmurowej – opiera się na zaufaniu do infrastruktury i integralności dostawcy. Badania akademickie oraz realne incydenty pokazują, iż obietnica „zero knowledge” nie jest absolutna, a bezpieczeństwo menadżera haseł jest tak silne, jak najsłabszy element jego architektury i środowiska, w którym funkcjonuje.

Więcej informacji:
https://eprint.iacr.org/2026/058
https://ethz.ch/en/news-and-events/eth-news/news/2026/02/password-managers-less-secure-than-promised.html
https://blog.szurek.tv/post/cve-2023-24055/
https://github.com/alt3kx/CVE-2023-24055_PoC
https://support.lastpass.com/s/document-item?language=en_US&bundleId=lastpass&topicId=LastPass%2Fincident-1-details.html&_LANG=enus
https://krebsonsecurity.com/2025/03/feds-link-150m-cyberheist-to-2022-lastpass-hacks/

Oszustwa i podszycia

Zwrot podatku i powiadomienie z KSeF? Tym razem to phishing i keylogger.

W ostatnim czasie obserwujemy zintensyfikowane próby phishingu z wykorzystaniem grafik i treści podszywających się pod polskie serwisy rządowe. Wiadomości są dostarczane do odbiorców za pośrednictwem e-mail oraz SMS. Mimo różnych formatów i różnych celów, ataki pojawiają się w podobnym czasie i wiążą się zarówno z corocznym rozpoczęciem rozliczania e-PIT oraz wdrożeniem KSeF. Oba te wątki wywołują dużo emocji, które atakujący chcą wykorzystać, do tego uderzając w przemyślanych terminach.

KSeF — mail z załącznikiem

Jednym z pierwszych zaobserwowanych przykładów jest wiadomość e-mail mająca przypominać powiadomienie od Krajowej Administracji Skarbowej. Informacja ma dotyczyć wdrożenia KSeF i zachęcić do otwarcia załącznika „Powiadomienie z dnia. 04.02.2026.iso”.

Rys. Mail o tytule „Powiadomienie” z plikiem ISO jako załącznikiem. Źródło: https://x.com/ahraciborski/status/2020084518799991209

Niepokojący powinien wydać się typ pliku, ponieważ to nie dokument, ale obraz ISO. Jego uruchomienie spowoduje wykonanie zawartego w nim pliku EXE, który rozpocznie łańcuch infekcji. Pierwszym etapem jest GuLoader służący do pobrania ostatecznego payloadu — VIP Keyloggera. To złośliwe oprogramowanie kradnie pliki oraz dane z przeglądarek i schowka , rejestruje naciśnięcia klawiszy klawiatury, a także robi zrzuty ekranu.

KAS — mail z linkiem phishingowym

CERT Polska ostrzegł o wiadomościach e-mail o tytule „Zawiadomienie o wszczęciu kontroli podatkowej” podszywających się pod KAS. W mailu zawarto odnośnik do strony phishingowej, na której znajduje się wierna kopia panelu logowania do profilu zaufanego. Możliwe jest „logowanie” dzięki nazwy użytkownika i hasła lub dzięki bankowości elektronicznej. Niezależnie od wybranej formy, atakujący może pozyskać cenne dane uwierzytelniające pozwalające na podjęcie nieautoryzowanych działań w imieniu ofiary lub kradzież pieniędzy z konta. W obu przypadkach konieczne byłoby przejście dodatkowego etapu, w którym oszust spróbowałby wyłudzić także drugi składnik logowania, na przykład kod z SMS.

e-PIT — SMS z linkiem phishingowym

W zeszłym tygodniu informowaliśmy o kampanii SMS-ów informujących o możliwym do otrzymania zwrocie podatku. W wiadomościach występujących w różnych wariantach znajdował się link do strony w domenie bezpieczny-zwrot-podatku[.]com, na której znajdował się panel phishingowy. Ta strona nie była jednak wierną kopią paneli logowania lub formularzy znanych ze stron rządowych, a połączeniem kilku elementów graficznych związanych ze stronami w domenie gov.pl. Pierwszym etapem do uzyskania rzekomego zwrotu podatku miało być przekazanie danych osobowych i adresowych. Drugim, mającym na celu wyłudzenie danych dostępowych do bankowości elektronicznej, było „uwierzytelnienie bankowe” przenoszące użytkownika na stronę imitującą logowanie do wybranego banku. Szczegóły tego oszustwa przedstawialiśmy w naszym artykule.

Zwrot środków — mail z linkiem phishingowym

Zwrot pieniędzy został wykorzystany także w innym mailu z odnośnikiem do strony phishingowej w treści. W tym scenariuszu początkowo wyłudzany był numer dowodu osobistego lub paszportu i kod pocztowy, by na kolejnym ekranie ofiara zobaczyła podsumowanie informacji o nienależnie pobranych środkach, dla których przysługuje zwrot.

Rys. Strona informująca o kwocie nadpłaty wynikającej z błędu systemu.

Następnie wyłudzane są dane karty płatniczej pod pretekstem zwrotu na nią środków. Ofiara z nadzieją na uzyskanie ponad 1,5 tysiąca zł może przekazać dane, a choćby autoryzować transakcje, które pojawią się później przy skorzystaniu przez atakujących z tej karty.

Incydent ZUS — strona phishingowa z kodem QR

Monitorując potencjalnie złośliwe domeny napotkaliśmy eincydent[.]org oraz e-incydent[.]org, które wyraźnie mają imitować polskie systemy do zgłaszania incydentów. Treść stron wskazywała na podszywanie się pod zgłaszanie incydentów w systemie ZUS.

Rys. Strona phishingowa z nagłówkiem „Zgłoszenie incydentu ZUS”.

Po wybraniu jednej z opcji uwierzytelnienia — jedyną aktywną w czasie analizy było logowanie dzięki mObywatela — zostaniemy przeniesieni na stronę z kodem QR do zeskanowania dzięki tej właśnie aplikacji. Nie udało nam się prześledzić całego scenariusza, by potwierdzić co dzieje się po zeskanowaniu kodu. Niewykluczone, iż jest to forma kradzieży cudzej tożsamości i wykorzystania jej w którymś z procesów wymagających Na ten moment nie znamy metody dostarczenia odnośnika do potencjalnej ofiary, ale obserwując podobne scenariusze podejrzewamy wiadomości e-mail.

Zarówno nowe, jak i te dobrze znane procesy stają się celem atakujących, którzy wykorzystują te scenariusze do wyłudzania informacji lub infekowania złośliwym oprogramowaniem. W pierwszym z przypadków działa niedostateczna znajomość przebiegu autoryzacji lub procesowania zaistniałych błędów, z czego korzystają oszuści tworząc własne, wiarygodne scenariusze. Z kolei oparcie się na dobrze znanych działaniach wymaga dokładnego odtworzenia procesu przez atakujących, by oprzeć się na przyzwyczajeniach użytkowników. Przechodząc przez pozornie znane etapy autoryzacji lub potwierdzeń można zapomnieć o niezbędnym elemencie przy każdym logowaniu do istotnych kont — uważności. Przy każdym logowaniu do istotnych usług, w tym bankowości internetowej i portali rządowych, należy uważnie przyjrzeć się adresowi URL odwiedzanej strony. Ze szczególną ostrożnością powinno się podchodzić także do załączników w wiadomościach e-mail. Przy każdej wiadomości wzbudzającej emocje, wywołującej poczucie presji czasu i zachęcającej do pobrania pliku lub wejścia w link, warto skierować się na oficjalne strony instytucji. Przypominamy adresy oficjalnych stron

• Krajowej Administracji Skarbowej: https://www.gov.pl/web/kas,
• obsługi e-PIT: https://www.podatki.gov.pl/
• oraz KSeF: https://ksef.podatki.gov.pl/

Więcej informacji:
https://x.com/CERT_Polska/status/2021283029461667966
https://cert.orange.pl/ostrzezenia/e-pit-lada-moment-uwazaj-na-oszustwa