Stuxnet wrócił na GitHub, a Shai-Hulud omija skaner npm

Kod źródłowy Stuxnet opublikowany na GitHubie po inżynierii odwrotnej

Nieznany badacz bezpieczeństwa opublikował w serwisie GitHub odwrotnie zrekonstruowaną wersję kodu źródłowego Stuxnet. Repozytorium zawiera instrukcje budowania, a uruchomienie wymaga maszyny wirtualnej z systemem Windows XP lub Windows 7 bez połączenia z siecią; pełne efekty ładunku można zaobserwować tylko z odpowiednim oprogramowaniem Siemens, a najlepiej także sprzętem. Stuxnet atakował sterowniki przemysłowe Siemensa używane w irańskim zakładzie wzbogacania uranu w Natanz. Jego ładunek manipulował przetwornikami częstotliwości w wirówkach, aby po cichu uszkodzić wirniki, jednocześnie raportując personelowi normalną pracę. Uważa się go za pierwszego cyfrowego robaka, który spowodował bezpośrednie szkody fizyczne.

Researcher reverse-engineers infamous Stuxnet malware source code, publishes it on Github for all — attack targeted Iranian nuclear facilities and was the first software of its type to cause physical damage →

Robak Shai-Hulud ponownie omija skanowanie malware w npm

Robak npm o nazwie Shai-Hulud powrócił kilka miesięcy po tym, jak uznano go za nieaktywny. W maju przejęte konto opiekuna wypchnęło 639 złośliwych wersji pakietów @antv do npm w ciągu zaledwie godziny, zanim atak zatrzymano. Od tego czasu npm wprowadził skanowanie malware w momencie publikacji, które wstrzymuje każdy pakiet na pięć do piętnastu minut, zanim stanie się instalowalny. Badacze z Aikido Security wykryli jednak „wormy boy”, który przeszedł przez kolejkę weryfikacji. Charlie Eriksen z Aikido Security powiedział, że ładunek miał ten sam hash co fala @AntV i ten sam payload. Cztery pakiety zostały przesłane w ciągu godziny po 111-dniowej przerwie, omijając skanowanie npm. To [email protected], [email protected], [email protected] oraz [email protected]. Eriksen stwierdził, że luka między tym, co deklaruje skanowanie rejestru, a tym, co faktycznie wychwyciło przy identycznym hashu, jest prawdziwą historią, dodając, że dopasowanie sygnatur znanych złośliwych artefaktów to najłatwiejsza poprzeczka w branży i najbardziej niepokojące jest to, że została pominięta.

Is Shai-Hulud back? Researchers spot ‘wormy boy’ slipping past npm malware scanning features →

Luka w zabezpieczeniu Microsoftu przed podszywaniem się w mailach

Microsoft udostępnił w kwietniu 2025 roku ustawienie o nazwie Reject Direct Send, które blokuje zewnętrzne wiadomości podszywające się pod wewnętrzne. Ustawienie dotyczy funkcji Direct Send w Microsoft 365, która pozwala drukarkom, skanerom i innym urządzeniom dostarczać pocztę do systemu firmy bez logowania. Atakujący wykorzystywali Direct Send, aby zewnętrzne maile wyglądały na wewnętrzne, dlatego Microsoft stworzył to ustawienie. Firma ReliaQuest opublikowała w czwartek badanie pokazujące, że atakujący wysyłający wiadomość do firmy z włączonym Reject Direct Send mogą dostarczyć ją do skrzynki odbiorcy, pozostawiając pusty adres zwrotny — pole, którego odbiorca nigdy nie widzi. W przeciwnym razie identyczna wiadomość zostaje odrzucona. Technika nie wymaga skradzionego hasła, przejętego konta, obejścia uwierzytelniania wieloskładnikowego ani kompromitacji sieci, więc zabezpieczenia oparte na ochronie logowania jej nie adresują. Jednym z głównych ryzyk jest przejęcie poczty biznesowej, czyli oszustwo, w którym pracownik zostaje nakłoniony do przelania pieniędzy lub przekazania danych logowania, często zaczynające się od maila wyglądającego na wiadomość od działu IT lub członka zarządu. W niektórych przypadkach opisanych przez ReliaQuest podszywające się wiadomości trafiały do folderu spam, ale większość dotarła do skrzynki odbiorcy. Jedną z dróg do skrzynki były listy wyjątków — nadpisania konfigurowane przez administratorów, aby poczta od zatwierdzonego nadawcy omijała filtr spamu. W jednym przypadku wiadomość nie przeszła żadnego testu uwierzytelniania nadawcy, a filtrowanie Microsoftu sklasyfikowało ją jako phishing, mimo to trafiła do skrzynki odbiorcy, ponieważ lista zatwierdzonych nadawców zawierała członka zarządu, pod którego wiadomość się podszywała. ReliaQuest określił to odkrycie jako ograniczenie zakresu Reject Direct Send, a nie wadę oprogramowania Microsoftu. Microsoft przyznał to ograniczenie, ogłaszając ustawienie w kwietniu 2025 roku, wyjaśniając, że ocenia adres zwrotny koperty, a nie adres nadawcy widoczny dla czytelnika. Zapytany w FAQ, czy klienci potrzebują Reject Direct Send, aby czuć się chronieni, Microsoft odpowiedział „Nie”, mówiąc, że ustawienie „dołącza do wielu warstw ochrony w Microsoft 365”. Dokumentacja produktu Microsoftu mówi, że większość klientów w ogóle nie potrzebuje Direct Send, zaleca go tylko dla starszego sprzętu i podaje, że firma pracuje nad opcją domyślnego wyłączenia Direct Send. Microsoft nie odpowiedział natychmiast na prośbę o komentarz. ReliaQuest sprzedaje oprogramowanie wykrywające, a część jego zaleceń wskazuje na własne produkty. Jedna z obron zatrzymała każdą próbę ReliaQuest: ograniczony łącznik przychodzący, filtr akceptujący pocztę tylko z zatwierdzonych maszyn, blokował podszywające się maile niezależnie od zawartości koperty. Instytucje, które już ograniczają, które maszyny mogą dostarczać pocztę, nie są narażone. Dla pozostałych ReliaQuest zaleca przegląd wszystkich skonfigurowanych nadpisań spamu, odnotowanie wpisów dotyczących członka zarządu lub menedżera i usunięcie tych, których firma nie potrafi uzasadnić, co zmniejsza liczbę osób, pod które atakujący może się skutecznie podszyć. ReliaQuest spodziewa się, że atakujący będą nadal używać tej techniki i skupią wysiłek na wydostawaniu wiadomości z folderu spam.

Researchers find a hole in Microsoft’s anti-spoofing fix →

Indie zapobiegły oszustwom na 5043 crore rupii dzięki wskaźnikowi FRI

Indyjski wskaźnik ryzyka oszustw finansowych (FRI) pomógł instytucjom finansowym zapobiec podejrzanym transakcjom cyberoszustw o wartości 5043,73 crore rupii do sierpnia 2026 roku. System uruchomiony 22 maja 2025 roku przez Departament Telekomunikacji zapobiegł około 660 crore rupii w pierwszych sześciu miesiącach, a ponad 2000 crore rupii w zaledwie cztery miesiące od kwietnia 2026 roku, gdy adopcja przez banki i platformy płatnicze wzrosła. FRI powstał w ramach Platformy Wywiadu Cyfrowego (DIP) Departamentu Telekomunikacji. Ocenia prawdopodobieństwo, że numer telefonu jest powiązany z oszustwem finansowym, i klasyfikuje go jako ryzyko średnie, wysokie lub bardzo wysokie, czerpiąc z raportów na platformie Sanchar Saathi, Krajowego Portalu Zgłaszania Cyberprzestępczości Indyjskiego Centrum Koordynacji Cyberprzestępczości, informacji od operatorów telekomunikacyjnych, banków i instytucji finansowych oraz innych parametrów telekomunikacyjnych. Banki, instytucje finansowe, aplikacje UPI i inne podmioty mogą włączyć tę inteligencję do swoich systemów kontroli oszustw, co pozwala ostrzegać klientów, wprowadzać dodatkową weryfikację, opóźniać transakcję lub w przypadkach wystarczająco wysokiego ryzyka ją odrzucić. Gdy FRI wprowadzano, Departament Telekomunikacji podał, że PhonePe używał klasyfikacji bardzo wysokiego ryzyka do odrzucania transakcji i wysyłania alertów, a wiodące platformy UPI, w tym PhonePe, Paytm i Google Pay, zaczęły integrować inteligencję DIP ze swoimi systemami. Ponad 1600 organizacji jest obecnie podłączonych do DIP, w porównaniu z ponad 1200 raportowanymi w lutym 2026 roku. Departament Telekomunikacji twierdzi, że przeprowadził ponad 25 sesji szkoleniowych obejmujących 1500 banków, instytucji finansowych i regulatorów. Zgodnie z zasadami podziału kompetencji cyberprzestępczość należy do domeny Ministerstwa Spraw Wewnętrznych, a policja i porządek publiczny to sprawy stanowe; rola Departamentu Telekomunikacji polega na dostarczaniu inteligencji telekomunikacyjnej, a nie na ściganiu przestępstw. DIP umożliwia dwukierunkową wymianę informacji z interesariuszami, w tym z I4C Ministerstwa Spraw Wewnętrznych. Na dzień 31 stycznia 2026 roku Obywatelski System Zgłaszania i Zarządzania Oszustwami Finansowymi pomógł zaoszczędzić ponad 8690 crore rupii w ponad 24,65 lakh skarg, a Rejestr Podejrzanych I4C udostępnił informacje o 27,37 lakh kont mułów pierwszego poziomu, a uczestniczące instytucje odrzuciły transakcje o wartości 9518,91 crore rupii. Reserve Bank of India, proponując Platformę Wywiadu Płatności Cyfrowych, argumentował, że utrzymanie zaufania do płatności cyfrowych wymaga inteligencji na poziomie sieci i wymiany danych w czasie rzeczywistym między systemami płatności. Departament Telekomunikacji stwierdza: „Każda rupia zatrzymana u źródła to oszustwo, które nigdy się nie wydarzyło”. Pozostają otwarte pytania o niezależną ocenę silnika ryzyka, w tym ile transakcji sklasyfikowanych jako bardzo wysokie ryzyko ostatecznie okazuje się oszustwem, ile legalnych numerów jest błędnie oznaczanych, jaka część alertów kończy się porzuceniem transakcji przez prawdziwych klientów i jak szybko błędnie sklasyfikowany numer może zostać zweryfikowany i przywrócony. Fałszywie pozytywny wynik osadzony w infrastrukturze finansowej czasu rzeczywistego może uniemożliwić obywatelowi lub firmie otrzymanie pieniędzy, a jeśli wiele banków i platform płatniczych polega na tej samej klasyfikacji ryzyka, błędny sygnał może rozprzestrzenić się w ekosystemie finansowym. Tworzy to potrzebę ram zarządzania klasyfikacją, przeglądem i rozpatrywaniem skarg, z audytowalnymi regułami określającymi, kiedy alert generuje ostrzeżenie, kiedy wymagane jest dodatkowe uwierzytelnienie, a kiedy transakcja może zostać zablokowana, wraz z zarządzaniem danymi obejmującym ograniczenie celu, retencję danych, kontrolę dostępu, mechanizmy korekty i odpowiedzialność za niedokładne informacje. Dane RBI konsekwentnie pokazują, że transakcje kartowe i internetowe dominują w zgłaszanych oszustwach bankowych pod względem liczby.

₹5043 crore saved: How India is building a real-time defence against digital fraud →

Rosyjscy hakerzy mieli użyć fałszywej CAPTCHA przeciw ukraińskiemu rządowi

Atak cybernetyczny wymierzony w ukraińską organizację rządową został powiązany z Moskwą według raportu Cisco. Badacze bezpieczeństwa Cisco zauważyli nietypową aktywność w systemach komputerowych organizacji w kwietniu i ocenili „z umiarkowaną pewnością”, że atak przeprowadził rosyjski aktor zagrożenia. Badacze znaleźli w systemie malware o nazwie Amatera, zdolne do kradzieży poufnych informacji. Zostało ono również użyte do zainstalowania oprogramowania dającego atakującemu dostęp do komputera, w tym możliwość przeglądania plików, przesyłania danych i uruchamiania poleceń. Oprogramowanie było skonfigurowane do łączenia się z serwerem o adresie IP zlokalizowanym w Rosji. Nie udało się zweryfikować, czy jakiekolwiek informacje zostały faktycznie skradzione z ukraińskiej organizacji, czy hakerzy aktywnie wykorzystali ten dostęp ani jak komputer został początkowo zainfekowany. Badacze Cisco ocenili, że atak był częścią szerszej operacji mającej na celu kradzież kryptowalut i danych uwierzytelniających. „Nie było jasne, co zapoczątkowało łańcuch wykonania” — czytamy w raporcie. W ukraińskim systemie badacze zobaczyli złośliwy plik ukryty pod nazwą „verification.google”, ale nie mogli prześledzić, co spowodowało jego uruchomienie. Szukając podobnych ataków, znaleźli inną infekcję z tym samym malware Amatera, powiązaną ze zhakowanymi stronami wyświetlającymi fałszywe wersje weryfikacji CAPTCHA Google. Zamiast prosić użytkowników o zaznaczenie pola lub rozpoznanie obrazków, fałszywa weryfikacja kazała im otworzyć okno na komputerze i wkleić tekst, który uruchamiał malware. W tej infekcji Amatera posłużyło również do zainstalowania programu przeznaczonego do kradzieży kryptowalut, który mógł monitorować kopiowane przez ofiary adresy portfeli kryptowalutowych i zastępować je adresami kontrolowanymi przez atakujących, potencjalnie przekierowując płatności. Cisco stwierdziło, że podobieństwa między infekcjami sugerują, iż atak na Ukrainę mógł zacząć się w ten sam sposób, ale badacze nie mogli potwierdzić, że obie infekcje zaczęły się identycznie ani że przeprowadziła je ta sama grupa.

Russian hackers may have used fake CAPTCHA to hack Ukrainian government computers →