Tag: Encryption

Wprowadzenie do problemu / definicja

Google Chrome od 2024 roku wykorzystuje mechanizm App-Bound Encryption, którego celem jest lepsza ochrona ciasteczek sesyjnych, zapisanych haseł oraz innych wrażliwych danych przeglądarki przed kradzieżą przez malware typu infostealer. Najnowsze analizy wskazują jednak, że zabezpieczenie to zostało ponownie ominięte. Tym razem atak nie koncentruje się na łamaniu szyfrowania jako takiego, lecz na przechwyceniu klucza w momencie, gdy przeglądarka odszyfrowuje dane i ujawnia je tymczasowo w pamięci procesu.

W skrócie

Nowo opisana technika umożliwia obejście ochrony App-Bound Encryption w Google Chrome i potencjalnie również w innych przeglądarkach opartych na Chromium. Mechanizm został powiązany z malware VoidStealer i wykorzystuje legalną funkcję debugowania do zatrzymania procesu dokładnie w chwili odszyfrowywania danych. W praktyce pozwala to przechwycić materiał kryptograficzny z pamięci RAM i otwiera drogę do kradzieży cookies, tokenów oraz zapisanych poświadczeń.

• atak uderza w etap użycia danych, a nie w ich zaszyfrowany magazyn,
• wykorzystywane są legalne mechanizmy diagnostyczne systemu,
• największym ryzykiem pozostaje przejęcie aktywnych sesji użytkownika,
• problem może dotyczyć szerzej całego ekosystemu Chromium.

Kontekst / historia

App-Bound Encryption zostało wdrożone przez Google w lipcu 2024 roku jako odpowiedź na rosnącą skuteczność infostealerów działających w środowisku Windows. Wcześniejsze podejście, oparte głównie na systemowym DPAPI, nie zapewniało wystarczającej ochrony przed złośliwym oprogramowaniem działającym w kontekście legalnie zalogowanego użytkownika. W efekcie malware mogło pozyskiwać dane przeglądarki bez konieczności przełamywania zabezpieczeń na poziomie jądra systemu.

Nowy model ochrony miał sprawić, że tylko sama aplikacja Chrome będzie mogła odszyfrować chronione dane. Rozwiązanie znacząco podniosło poprzeczkę dla operatorów masowych kampanii kradzieży danych, ale nie wyeliminowało problemu całkowicie. Już wcześniej badacze i praktycy bezpieczeństwa opisywali obejścia wykorzystujące techniki bezplikowe, process hollowing, niskopoziomowe wywołania systemowe oraz manipulację pamięcią procesu. Obecna metoda potwierdza, że przeglądarka nadal pozostaje atrakcyjnym celem dla cyberprzestępców.

Analiza techniczna

Najistotniejszym elementem nowego podejścia jest atak na moment użycia tajemnicy, a nie na sam zaszyfrowany zasób. Napastnik nie próbuje zatem bezpośrednio złamać algorytmu szyfrowania ani wydobyć danych z dysku w ich postaci zaszyfrowanej. Zamiast tego czeka na krótki moment, w którym przeglądarka musi odszyfrować ciasteczko, token lub zapisane poświadczenie, aby wykorzystać je w procesie uwierzytelniania.

W tym oknie czasowym klucz główny lub dane pośrednie niezbędne do odszyfrowania pojawiają się w pamięci procesu w postaci jawnej. Według opisu analizowanego przypadku malware dołącza do procesu przeglądarki jako debugger, korzystając z legalnego mechanizmu diagnostycznego. Następnie identyfikuje właściwy punkt wykonania, zatrzymuje proces i odczytuje materiał kryptograficzny bezpośrednio z pamięci operacyjnej.

Z perspektywy obrońców to istotna zmiana, ponieważ obejście nie wymaga klasycznego ataku na magazyn danych przeglądarki. Zabezpieczenie skutecznie chroni dane w spoczynku, lecz nie eliminuje ryzyka podczas ich użycia w pamięci RAM. Innymi słowy, jeśli aplikacja musi odszyfrować sekret, pojawia się możliwość jego przechwycenia przez odpowiednio przygotowane złośliwe oprogramowanie.

Technika ta wpisuje się w szerszy trend nadużywania legalnych funkcji systemowych i narzędzi deweloperskich do działań ofensywnych. Debugowanie, introspekcja pamięci oraz sterowanie wykonaniem procesu mają uzasadnione zastosowania administracyjne i programistyczne, ale w rękach operatorów malware stają się skutecznym wektorem obejścia zabezpieczeń endpointu.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem skutecznego obejścia App-Bound Encryption jest możliwość przejęcia aktywnych sesji użytkownika. Kradzież cookies sesyjnych lub tokenów może umożliwić obejście uwierzytelniania wieloskładnikowego w usługach, w których sesja została już wcześniej ustanowiona. Dla organizacji oznacza to ryzyko nieautoryzowanego dostępu do poczty, środowisk SaaS, paneli administracyjnych, platform developerskich oraz danych finansowych.

Ryzyko nie ogranicza się wyłącznie do Chrome. Ponieważ problem dotyczy modelu działania App-Bound Encryption i szerzej ekosystemu Chromium, zagrożone mogą być również inne przeglądarki bazujące na tym samym silniku. To szczególnie ważne w środowiskach korporacyjnych, gdzie różne zespoły korzystają z odmiennych aplikacji, ale opartych na wspólnej architekturze.

Dodatkowym wyzwaniem pozostaje wykrywalność. Jeśli malware wykorzystuje legalne API debuggera i działa bardzo krótko, tylko w wybranym momencie odszyfrowania, jego aktywność może być trudniejsza do odróżnienia od nietypowych, ale legalnych działań administracyjnych lub deweloperskich. W praktyce oznacza to, że tradycyjne mechanizmy ochrony sygnaturowej mogą okazać się niewystarczające bez telemetrii behawioralnej oraz monitorowania pamięci procesu.

Rekomendacje

Organizacje powinny traktować przeglądarkę jako krytyczny zasób bezpieczeństwa, a nie tylko narzędzie użytkownika końcowego. W praktyce oznacza to konieczność wdrożenia wielowarstwowych kontroli ochronnych wokół procesów przeglądarek i przechowywanych przez nie sekretów.

W pierwszej kolejności warto ograniczyć możliwość uruchamiania nieautoryzowanych procesów i narzędzi mogących uzyskiwać dostęp do pamięci innych aplikacji. Kluczowe znaczenie mają polityki application control, wdrożenie EDR lub XDR oraz monitorowanie prób attachowania debuggera do procesów przeglądarek. Z perspektywy detekcji należy zwracać uwagę na anomalie związane z odczytem pamięci, wstrzymywaniem procesów oraz nietypowym użyciem narzędzi developerskich na stacjach roboczych użytkowników biznesowych.

Drugim filarem powinno być ograniczanie wartości danych przechowywanych w przeglądarce. Dotyczy to zwłaszcza zapisywania haseł, danych płatniczych i długotrwałych sesji administracyjnych. Tam, gdzie to możliwe, warto stosować krótszy czas życia sesji, dodatkowe warunki dostępu, ciągłą weryfikację ryzyka oraz powiązanie sesji z urządzeniem lub kontekstem sieciowym.

W środowiskach o podwyższonych wymaganiach bezpieczeństwa rekomendowane jest rozważenie izolacji przeglądarek, hardeningu stacji roboczych uprzywilejowanych oraz separacji kont administracyjnych od codziennej pracy użytkownika. Należy również aktualizować przeglądarki i systemy operacyjne bez zwłoki, ponieważ producenci mogą wprowadzać kolejne mechanizmy utrudniające podobne ataki.

• monitorowanie prób debugowania procesów przeglądarek,
• wykrywanie nieoczekiwanego dostępu do pamięci Chrome i innych przeglądarek Chromium,
• analiza podejrzanych procesów potomnych uruchamianych z kontekstu przeglądarki,
• detekcja oznak kradzieży tokenów, cookies i danych uwierzytelniających,
• śledzenie anomalii sesyjnych w usługach chmurowych po stronie tożsamości.

Podsumowanie

Nowe obejście App-Bound Encryption pokazuje, że ochrona danych przeglądarki na poziomie szyfrowania nie rozwiązuje całego problemu, jeśli atakujący potrafi przechwycić sekret w chwili jego użycia. Przeglądarki pozostają atrakcyjnym celem dla operatorów infostealerów, ponieważ są centralnym repozytorium danych sesyjnych i uwierzytelniających. Dla zespołów bezpieczeństwa oznacza to konieczność rozszerzenia ochrony z samego magazynu danych na cały cykl życia sekretu: od zapisu, przez odszyfrowanie, po użycie w pamięci procesu.

Źródła

1. Dark Reading — Yet Another Way to Bypass Google Chrome’s Encryption Protection — https://www.darkreading.com/endpoint-security/yet-another-way-bypass-google-chromes-encryption-protection
2. Google Security Blog — Improving the security of Chrome cookies on Windows — https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on-windows.html
3. CyberArk — C4 Bomb: Blowing Up Chrome’s AppBound Cookie Encryption — https://www.cyberark.com/resources/threat-research-blog/c4-bomb-blowing-up-chromes-appbound-cookie-encryption/
4. Alex Hagenah — chromelevator — https://github.com/xaitax/Chrome-App-Bound-Encryption-Decryption
5. Kaspersky — The current state of browser stealers — https://www.kaspersky.com/blog/browser-stolen-data-2024/52423/

Wprowadzenie do problemu / definicja

Mechanizm App-Bound Encryption (ABE) został wprowadzony przez Google po to, aby utrudnić złośliwemu oprogramowaniu kradzież wrażliwych danych przechowywanych przez przeglądarkę Chrome, takich jak ciasteczka sesyjne, zapisane hasła czy tokeny uwierzytelniające. Kluczowa idea tego rozwiązania polega na powiązaniu procesu odszyfrowania danych z samą aplikacją przeglądarki, a nie wyłącznie z kontem użytkownika zalogowanego do systemu Windows.

Najnowsze obserwacje pokazują jednak, że cyberprzestępcy potrafią ominąć tę ochronę bez klasycznego łamania kryptografii. Zamiast atakować sam algorytm, wykorzystują moment, w którym przeglądarka musi odsłonić chronione dane lub materiał kryptograficzny w pamięci operacyjnej, aby normalnie z nich skorzystać.

W skrócie

Nowa technika została powiązana z rodziną malware VoidStealer i dotyczy Chrome oraz innych przeglądarek opartych na Chromium. Obejście polega na przechwyceniu klucza szyfrującego lub jego użytecznej reprezentacji z pamięci procesu w chwili, gdy przeglądarka odszyfrowuje dane chronione przez ABE.

• Atak nie wymaga klasycznej eskalacji uprawnień do poziomu systemowego.
• Wykorzystywany jest legalny mechanizm debugowania procesów.
• Celem są cookies, hasła, tokeny i inne artefakty sesyjne.
• Ryzyko dotyczy zarówno użytkowników indywidualnych, jak i środowisk firmowych.

Kontekst / historia

W systemie Windows przez lata ochrona danych przeglądarki opierała się głównie na mechanizmach takich jak DPAPI. Rozwiązanie to dobrze zabezpieczało dane zapisane na dysku, ale miało ograniczoną skuteczność wobec malware działającego w kontekście legalnie zalogowanego użytkownika. W praktyce infostealery mogły często odczytywać cenne dane bez potrzeby przełamywania zaawansowanych barier kryptograficznych.

Google wdrożył ABE jako próbę ograniczenia tego problemu. Założenie było proste: nawet jeśli napastnik działa na koncie użytkownika, nie powinien łatwo odszyfrować danych przeglądarki poza zaufanym procesem Chrome. Z czasem okazało się jednak, że atakujący i badacze bezpieczeństwa znajdują kolejne sposoby na obchodzenie tego modelu ochrony.

Wcześniejsze analizy opisywały metody oparte na uruchamianiu bezplikowym, process hollowing, bezpośrednich wywołaniach systemowych czy podszywaniu się pod legalną aktywność przeglądarki. Najnowsze obejście pokazuje kolejny etap ewolucji tych technik: skupienie się na bardzo krótkim oknie czasowym, w którym sekret musi zostać ujawniony w pamięci procesu.

Analiza techniczna

Istota problemu wynika z ograniczeń praktycznej ochrony sekretów „w użyciu”. Dane mogą być poprawnie zabezpieczone na dysku, lecz w chwili, gdy aplikacja musi z nich skorzystać, muszą zostać odszyfrowane do postaci użytecznej. To właśnie ten moment staje się celem ataku.

W opisywanym scenariuszu malware przyłącza się do procesu przeglądarki jako debugger. Nie jest to egzotyczna funkcja systemowa, lecz legalny i powszechnie stosowany mechanizm wykorzystywany przez programistów oraz analityków. Dzięki temu atak może wyglądać mniej podejrzanie niż klasyczne techniki iniekcji kodu lub agresywnej eskalacji uprawnień.

Następnie złośliwe oprogramowanie identyfikuje właściwy moment wykonania, w którym Chrome odszyfrowuje dane chronione przez ABE. Gdy materiał kryptograficzny pojawia się w pamięci w formie możliwej do dalszego wykorzystania, proces zostaje zatrzymany, a pamięć przechwycona. W efekcie napastnik nie łamie samego mechanizmu szyfrowania, lecz wykorzystuje fakt, że przeglądarka musi czasowo „odsłonić” sekret, aby działać zgodnie ze swoim przeznaczeniem.

To rozróżnienie ma duże znaczenie. Nie mamy tu do czynienia z klasycznym złamaniem kryptografii, ale z nadużyciem momentu operacyjnego, w którym bezpieczeństwo ustępuje funkcjonalności. Tego typu ataki coraz częściej pojawiają się tam, gdzie systemy dobrze chronią dane „w spoczynku”, lecz mają ograniczone możliwości obrony przed przechwyceniem sekretów z pamięci procesu.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją takiego obejścia jest możliwość kradzieży aktywnych artefaktów uwierzytelniających. W praktyce oznacza to, że napastnik może przejąć sesję użytkownika bez znajomości hasła, a w części przypadków również ominąć część zabezpieczeń wieloskładnikowych, jeśli uwierzytelnienie zostało już wcześniej zakończone sukcesem.

Problem ma szczególne znaczenie dla organizacji korzystających intensywnie z usług SaaS, paneli administracyjnych, poczty firmowej, narzędzi DevOps i środowisk chmurowych. W takich warunkach przeglądarka staje się centralnym punktem dostępu do kluczowych zasobów. Przechwycenie cookies lub tokenów może więc prowadzić nie tylko do kompromitacji jednego konta, ale także do dalszego ruchu lateralnego i eskalacji incydentu.

Dodatkowym wyzwaniem po stronie obrońców jest fakt, że atak nadużywa legalnego mechanizmu debugowania. Sama obecność działań związanych z debuggerem nie musi oznaczać aktywności złośliwej. Znaczenia nabiera więc analiza kontekstu: które procesy inicjują attach do przeglądarki, na jakich stacjach roboczych, o jakiej porze i czy zachowanie to odpowiada normalnemu profilowi pracy użytkownika.

Rekomendacje

Organizacje powinny traktować przeglądarki internetowe jako zasób wysokiego ryzyka, porównywalny z klientami poczty, narzędziami zdalnego dostępu czy aplikacjami obsługującymi poświadczenia. Sama ochrona danych zapisanych w przeglądarce nie jest wystarczająca, jeśli przeciwnik potrafi przechwycić je w pamięci podczas użycia.

• Wdrożyć monitoring EDR/XDR pod kątem nietypowego debugowania procesów Chrome i innych przeglądarek Chromium.
• Ograniczyć możliwość uruchamiania niezatwierdzonego oprogramowania poprzez allowlisting i kontrolę skryptów.
• Minimalizować przechowywanie haseł bezpośrednio w przeglądarce.
• Stosować dedykowane menedżery haseł klasy enterprise.
• Skracać czas życia sesji i tokenów tam, gdzie jest to możliwe.
• Tworzyć reguły detekcji skupione na kradzieży cookies i tokenów, a nie wyłącznie na dumpingu poświadczeń systemowych.
• Po wykryciu infekcji szybko unieważniać sesje, resetować poświadczenia i rotować tokeny dostępu.

W praktyce warto również ograniczać lokalne uprawnienia administracyjne, blokować zbędne narzędzia developerskie na stacjach roboczych użytkowników biznesowych oraz monitorować dostęp do pamięci procesów obsługujących dane uwierzytelniające. Ochrona przeglądarki powinna stać się integralnym elementem strategii bezpieczeństwa tożsamości i dostępu.

Podsumowanie

Nowa technika obejścia App-Bound Encryption pokazuje, że nawet dobrze zaprojektowane zabezpieczenia przeglądarki mają naturalną słabość w momencie operacyjnego użycia sekretów. VoidStealer nie tyle łamie samą kryptografię, ile wykorzystuje chwilę, w której Chrome musi ujawnić materiał kryptograficzny lub dane sesyjne w pamięci.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że obrona nie może kończyć się na szyfrowaniu danych zapisanych na dysku. Kluczowe stają się monitoring procesu przeglądarki, wykrywanie nadużyć debugowania, ograniczanie wartości przechowywanych sesji oraz szybka reakcja na oznaki działania infostealerów.

Źródła

1. https://www.darkreading.com/endpoint-security/yet-another-way-bypass-google-chromes-encryption-protection
2. https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on-windows.html
3. https://www.kaspersky.com/blog/chrome-app-bound-encryption-how-it-works/52614/
4. https://www.cyberark.com/resources/threat-research-blog/c4-bomb-blowing-up-chromes-appbound-cookie-encryption/
5. https://github.com/xaitax/Chrome-App-Bound-Encryption-Decryption

Wprowadzenie do problemu / definicja

Storm to nowy infostealer zaprojektowany do kradzieży danych uwierzytelniających, ciasteczek sesyjnych, tokenów, danych autouzupełniania oraz informacji z portfeli kryptowalutowych. Najbardziej niepokojącą cechą tego zagrożenia jest przeniesienie procesu odszyfrowywania przechwyconych artefaktów z urządzenia ofiary do infrastruktury operatora, co znacząco utrudnia wykrycie aktywności przez klasyczne mechanizmy ochronne.

W praktyce oznacza to zmianę podejścia: zamiast odczytywać i odszyfrowywać dane lokalnie, malware eksportuje zaszyfrowane pliki oraz bazy z przeglądarek, a następnie przetwarza je już po stronie serwera kontrolowanego przez atakującego. Taki model ogranicza liczbę lokalnych śladów kompromitacji i zwiększa skuteczność kradzieży aktywnych sesji.

W skrócie

Storm pojawił się jako nowoczesny infostealer oferowany w modelu subskrypcyjnym. Jego operatorzy stawiają nie tylko na kradzież haseł, ale przede wszystkim na przejmowanie już uwierzytelnionych sesji użytkowników.

• kradnie hasła, cookies, tokeny i dane autouzupełniania,
• zbiera informacje z komunikatorów i portfeli kryptowalutowych,
• przesyła zaszyfrowane artefakty do odszyfrowania po stronie serwera,
• umożliwia automatyczne odtwarzanie sesji z użyciem tokenów i proxy,
• ogranicza widoczność działań złośliwego kodu na stacji roboczej.

Kontekst / historia

Rynek infostealerów od lat przechodzi ewolucję. Początkowo złośliwe oprogramowanie skupiało się głównie na prostym wykradaniu zapisanych haseł. Z czasem atakujący zaczęli jednak koncentrować się na przejmowaniu aktywnych sesji, ponieważ to one pozwalają ominąć część mechanizmów ochronnych, w tym wybrane wdrożenia MFA.

Znaczenie tego trendu wzrosło wraz z rozwojem zabezpieczeń w przeglądarkach. Wprowadzenie nowych mechanizmów ochrony danych, takich jak App-Bound Encryption w Chrome na Windows, zwiększyło trudność lokalnego odszyfrowywania artefaktów. W odpowiedzi twórcy malware zaczęli przenosić krytyczne operacje poza urządzenie ofiary. Storm wpisuje się dokładnie w ten kierunek rozwoju, łącząc kradzież danych z automatyzacją odzyskiwania sesji.

Analiza techniczna

Storm działa przede wszystkim w środowisku Windows i ma przechwytywać dane z przeglądarek opartych na Chromium oraz wybranych przeglądarek z rodziny Gecko. Zamiast wykonywać pełne odszyfrowanie lokalnie, malware eksportuje zaszyfrowane dane do infrastruktury atakującego. To podejście redukuje liczbę lokalnych wskaźników kompromitacji związanych z dostępem do magazynów przeglądarki.

Według opisywanych materiałów zagrożenie może pozyskiwać szeroki zakres danych użytkownika:

• zapisane hasła,
• ciasteczka sesyjne,
• dane autouzupełniania,
• tokeny kont, w tym tokeny usług internetowych,
• dane kart płatniczych,
• historię przeglądania,
• dane z komunikatorów, takich jak Telegram, Signal i Discord,
• informacje z rozszerzeń i aplikacji portfeli kryptowalutowych,
• dokumenty z katalogów użytkownika,
• informacje systemowe oraz zrzuty ekranu.

Istotnym elementem ekosystemu jest panel operatorski. Nie służy on wyłącznie do odbioru logów, ale także do automatyzacji przejmowania sesji. Atakujący mogą wykorzystywać przechwycone tokeny i cookies wraz z proxy dopasowanym geograficznie do lokalizacji ofiary, co zwiększa szansę na skuteczne odtworzenie sesji bez wzbudzania dodatkowych alertów bezpieczeństwa.

Model infrastrukturalny również zasługuje na uwagę. Operatorzy Storm mają umożliwiać podłączanie własnych serwerów VPS do centralnej platformy, dzięki czemu ruch i wykradzione dane mogą być przekierowywane przez infrastrukturę pozostającą pod ich kontrolą. To utrudnia szybką neutralizację całego ekosystemu i pozwala rozproszyć operacje między wieloma węzłami.

Konsekwencje / ryzyko

Największym ryzykiem związanym ze Storm nie jest sama kradzież hasła, lecz przejęcie aktywnej, już uwierzytelnionej sesji. W takim scenariuszu atakujący może uzyskać dostęp do poczty, systemów SaaS, zasobów chmurowych, paneli administracyjnych czy kont finansowych bez konieczności ponownego logowania.

Dla organizacji oznacza to realne zagrożenie biznesowe i operacyjne:

• przejęcie kont uprzywilejowanych,
• kradzież danych z systemów chmurowych,
• lateral movement w środowisku firmowym,
• eksfiltrację dokumentów i danych wrażliwych,
• nadużycia finansowe oraz przejęcia kont kryptowalutowych,
• wykorzystanie skradzionych informacji do dalszych kampanii phishingowych,
• sprzedaż logów dostępowych na forach cyberprzestępczych.

Dodatkowym czynnikiem ryzyka jest model malware-as-a-service. Dzięki subskrypcji próg wejścia dla mniej zaawansowanych grup przestępczych znacząco spada, a gotowe funkcje budowy, zarządzania i odzyskiwania sesji zwiększają skalę potencjalnych kampanii.

Rekomendacje

Organizacje powinny przyjąć, że sama ochrona haseł nie wystarcza. Kluczowe staje się monitorowanie sesji, anomalii behawioralnych i nietypowego użycia tokenów dostępowych. Obrona przed nowoczesnymi infostealerami musi obejmować zarówno stacje robocze, jak i warstwę tożsamości.

• wdrożyć monitorowanie sesji i wykrywanie nietypowego użycia tokenów,
• analizować logowania pod kątem lokalizacji, reputacji adresów IP i wzorców dostępu,
• skracać czas życia sesji oraz częściej rotować tokeny,
• wymuszać ponowną autoryzację dla operacji wysokiego ryzyka,
• segmentować dostęp do aplikacji SaaS i zasobów chmurowych,
• blokować uruchamianie nieautoryzowanych plików wykonywalnych,
• stosować EDR ukierunkowany na wykrywanie kradzieży artefaktów przeglądarki i nietypowej komunikacji,
• utwardzać konfigurację przeglądarek, rozszerzeń i portfeli kryptowalutowych,
• izolować stacje robocze administratorów i użytkowników uprzywilejowanych,
• regularnie szkolić użytkowników z phishingu i metod dostarczania malware.

W przypadku incydentu sama zmiana hasła może nie wystarczyć. Konieczne może być unieważnienie wszystkich aktywnych sesji, reset tokenów odświeżania, przegląd zaufanych urządzeń oraz analiza, czy atakujący nie uzyskał trwałego dostępu do środowiska.

Podsumowanie

Storm pokazuje, że nowoczesne infostealery rozwijają się w kierunku cichszego działania, mniejszej liczby lokalnych artefaktów i większej automatyzacji przejmowania aktywnych sesji. Przeniesienie odszyfrowywania danych na serwer operatora znacząco utrudnia wykrycie ataku i zwiększa skuteczność działań przeciwko użytkownikom indywidualnym oraz organizacjom.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona tożsamości, sesji i zachowań użytkowników staje się równie ważna jak tradycyjna ochrona poświadczeń. Storm nie jest jedynie kolejnym stealerem — to przykład dojrzewania cyberprzestępczych usług ukierunkowanych na realne przejęcie dostępu.

Źródła

1. BleepingComputer — https://www.bleepingcomputer.com/news/security/the-silent-storm-new-infostealer-hijacks-sessions-decrypts-server-side/
2. Google Security Blog — https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on-windows.html
3. Varonis — Cookie-Bite — https://www.varonis.com/blog/cookie-bite
4. Varonis — SessionShark — https://www.varonis.com/blog/sessionshark
5. MITRE ATT&CK — Steal Web Session Cookie — https://attack.mitre.org/techniques/T1539/