Archiwa: Malware - Strona 93 z 126

eScan: przejęty serwer aktualizacji posłużył do dystrybucji złośliwego „update” (supply chain) – co wiemy i jak reagować

Wprowadzenie do problemu / definicja luki

Incydenty typu supply chain (kompromitacja łańcucha dostaw) należą do najgroźniejszych, bo nadużywają mechanizmu, któremu organizacje ufają najbardziej: legalnych aktualizacji. W przypadku eScan (MicroWorld Technologies) potwierdzono, że nieautoryzowany plik trafił do ścieżki dystrybucji aktualizacji w obrębie jednego z regionalnych klastrów serwerów, a następnie został pobrany przez część klientów w ograniczonym oknie czasowym 20 stycznia 2026 r.

W skrócie

eScan potwierdził nieautoryzowany dostęp do konfiguracji regionalnego serwera aktualizacji i dystrybucję błędnego/złośliwego pliku w kanale update w dniu 20.01.2026 (wąskie okno czasowe, wybrany klaster).
Morphisec opisał kampanię jako wieloetapową infekcję opartą o podmieniony komponent aktualizacji (m.in. Reload.exe) oraz dalsze payloady (m.in. CONSCTLX.exe), z naciskiem na „anti-remediation” (blokowanie przyszłych aktualizacji).
Kluczowy problem operacyjny: na systemach dotkniętych incydentem automatyczna naprawa/aktualizacja może nie działać, bo malware celowo psuje mechanikę aktualizacji.

Kontekst / historia / powiązania

To nie pierwszy raz, gdy eScan pojawia się w kontekście nadużyć aktualizacji. W 2024 r. opisywano operację przypisywaną aktorom powiązanym z Koreą Płn., gdzie mechanizm aktualizacji eScan miał zostać wykorzystany do dostarczania backdoorów i minerów (kampania określana m.in. jako GuptiMiner) – tam scenariusz obejmował manipulację ruchem/aktualizacją (MitM) i podmianę paczki.
Różnica w 2026 r. jest zasadnicza: tym razem mówimy o dystrybucji przez legalną infrastrukturę aktualizacji (zaufany kanał vendorowy), co zwykle zwiększa „skuteczność” kampanii i utrudnia wczesne wykrycie.

Analiza techniczna / szczegóły luki

Z perspektywy TTP (tactics/techniques/procedures) w opisie Morphisec przewijają się trzy szczególnie niebezpieczne elementy:

1) Trojanizacja komponentu aktualizacji (Stage 1)
Atak miał zacząć się od podmiany 32-bitowego komponentu związanego z aktualizacją – wskazywany jest Reload.exe – który następnie realizował persistence, wykonywanie poleceń i przygotowanie gruntu pod kolejne etapy.

2) „Anti-remediation”: blokowanie przyszłych aktualizacji i naprawy
Złośliwy kod miał modyfikować m.in. plik HOSTS oraz elementy konfiguracji/rejestru eScan tak, aby utrudnić komunikację z serwerami aktualizacji i uniemożliwić pobieranie kolejnych definicji/patche’y. To klasyczny wzorzec: utrzymać foothold i „odciąć” ofiarę od leczenia.

3) Persistence przez Scheduled Tasks + artefakty w rejestrze (Stage 2/3)
Morphisec opisuje m.in. tworzenie zadań harmonogramu podszywających się pod defragmentację (np. nazwy w stylu Windows\Defrag\…Defrag, przykładowo „CorelDefrag”) oraz podejrzane klucze w HKLM\Software\{GUID} z danymi w formie tablicy bajtów (PowerShell payload).

C2 / infrastruktura
Wskazano też przykładowe adresy C2 i zasoby pobierania kolejnych payloadów (w publikacjach zwykle podawane w formie zanonimizowanej typu hxxps://… i [.]). W praktyce SOC powinien dodać je do blokad na brzegu sieci i w DNS/Proxy, a następnie skorelować z logami. (

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyka dla organizacji korzystających z eScan:

Utrata zaufania do kanału aktualizacji: nawet poprawnie zarządzany endpoint może zostać zainfekowany „legalnym” update’em.
Zablokowanie aktualizacji definicji AV/EDR: jeśli mechanizm aktualizacji zostanie uszkodzony, stacja robocza może pozostać w stanie „ślepoty” na nowe próbki i IOC.
Trwała obecność (persistence) i możliwość dalszej eskalacji: opisywane backdoory/downloader’y (np. CONSCTLX.exe) sugerują gotowość do dogrywania kolejnych modułów (kradzież danych, lateral movement, ransomware).
Ryzyko wtórnych kompromitacji: Morphisec rekomenduje także reset poświadczeń, jeśli zainfekowane hosty mogły uzyskać dostęp do kont/zasobów (typowy następny krok po supply chain).

Rekomendacje operacyjne / co zrobić teraz

Jeśli macie eScan w środowisku (enterprise lub consumer), sensowny playbook „tu i teraz”:

Ustal ekspozycję na okno 20.01.2026
- Przejrzyj logi aktualizacji eScan oraz ruch sieciowy z tego dnia, zwłaszcza jeśli endpointy korzystały z regionalnych serwerów/CDN.
Traktuj dotknięte hosty jak potencjalnie skompromitowane
- Izoluj z sieci systemy, na których wystąpiły symptomy: błędy aktualizacji, komunikaty o niedostępności update, zmiany w HOSTS, brak nowych definicji.
Polowanie na IOC (endpoint + AD + sieć)
- Szukaj: Reload.exe (nietypowe hashe/ścieżki), CONSCTLX.exe, zadań w Windows\Defrag\, podejrzanych kluczy HKLM\Software\{GUID} z danymi binarnymi, katalogów-znaczników (np. opisywany efirst w ProgramData).
Zablokuj infrastrukturę C2
- Dodaj domeny/IP z raportu do blokad (DNS sinkhole, proxy, firewall) i sprawdź historię połączeń.
Naprawa eScan może wymagać działania manualnego
- Morphisec podkreśla, że na zainfekowanych systemach automatyczne „doleczenie” może nie zadziałać, bo mechanizm aktualizacji został celowo uszkodzony — wymagany jest kontakt z vendorem i ręczne zastosowanie patcha/narzędzia naprawczego.
Forensics i higiena poświadczeń
- Zweryfikuj, czy doszło do uruchomienia Stage 3/backdoora; w razie potwierdzenia – pełne IR: timeline, triage pamięci, przegląd kont uprzywilejowanych, rotacja haseł/tokenów.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

2024 (GuptiMiner) vs 2026 (kompromitacja serwera/klastra aktualizacji):

2024: opisywano scenariusz, w którym atakujący podmieniają paczkę aktualizacji w trakcie dostarczania (MitM / słabe zabezpieczenia kanału).
2026: według potwierdzenia eScan i analizy Morphisec, złośliwy plik był dystrybuowany przez legalną infrastrukturę aktualizacji (co zwykle bardziej przypomina klasyczne supply chain w stylu „zaufany update staje się wektorem ataku”).

Wniosek praktyczny: nawet jeśli organizacja „nie klika w linki” i ma twarde polityki, update pipeline dostawcy pozostaje krytycznym punktem ryzyka, który warto obejmować monitoringiem (np. allowlisting hash/certyfikatów + anomalia w zachowaniu procesu aktualizacji).

Podsumowanie / kluczowe wnioski

Incydent eScan to klasyczny atak na łańcuch dostaw, gdzie legalny kanał aktualizacji posłużył do dystrybucji malware w dniu 20 stycznia 2026 r.
Kluczową cechą kampanii jest blokowanie mechanizmu naprawy/aktualizacji (HOSTS + konfiguracja/rejestr eScan), co podnosi koszt i czas reakcji.
Najrozsądniejsze podejście: szybko ustalić ekspozycję, izolować podejrzane hosty, wykonać threat hunting po IOC, zablokować C2 i wdrożyć manualną ścieżkę remediation rekomendowaną przez vendor/partnerów badawczych.

Źródła / bibliografia

BleepingComputer – potwierdzenie incydentu przez MicroWorld/eScan, symptomy, kontekst i odniesienia do analizy Morphisec. (BleepingComputer)
Morphisec Threat Labs – „Threat Bulletin: Critical eScan Supply Chain Compromise” (łańcuch infekcji, IOC, persistence, remediation). (Morphisec)
SC Media (SCWorld) – streszczenie incydentu i rekomendacje działań operacyjnych (threat hunting, blokady C2, ostrożność wobec certyfikatu). (SC Media)
SecurityWeek – tło historyczne: kampania 2024 wykorzystująca mechanizm aktualizacji eScan (GuptiMiner, MitM). (SecurityWeek)

Mustang Panda (HoneyMyte) rozwija CoolClient: nowe moduły kradzieży danych z przeglądarek i monitor schowka

Wprowadzenie do problemu / definicja luki

Chińsko-powiązana grupa szpiegowska znana jako Mustang Panda (w nomenklaturze części dostawców także HoneyMyte / Earth Preta / Bronze President) zaktualizowała swój backdoor CoolClient tak, aby skuteczniej wspierał kradzież danych uwierzytelniających i „życie z zasobów” (LOTL) w środowiskach ofiar. Najważniejsza zmiana: CoolClient nie jest już wyłącznie furtką do zdalnego dostępu, ale stał się platformą do wdrażania infostealerów (kradzież logowań z przeglądarek) oraz monitorowania schowka i aktywnego okna.

W skrócie

Nowy CoolClient potrafi monitorować schowek i śledzić tytuły aktywnych okien, a także podsłuchiwać poświadczenia do proxy HTTP.
W kampaniach zaobserwowano trzy rodziny stealerów: pod Chrome, Edge oraz wariant „uniwersalny” dla przeglądarek Chromium.
Eksfiltracja danych (np. cookies) może wykorzystywać legalne usługi (np. Google Drive) i tokeny/API wbudowane w operacje, co utrudnia detekcję po samym „dokąd wychodzi ruch”.
Cele kampanii to m.in. instytucje rządowe w kilku krajach Azji oraz poza nią (m.in. Myanmar, Mongolia, Malezja, Rosja, Pakistan).

Kontekst / historia / powiązania

CoolClient jest kojarzony z Mustang Panda co najmniej od 2022 r. i bywał wdrażany jako dodatkowa furtka obok innych znanych implantów tej klasy (np. PlugX, LuminousMoth).
Z perspektywy „rodziny” aktora warto pamiętać, że różni dostawcy opisywali go pod wieloma nazwami (np. Earth Preta), a kampanie często opierały się o spreparowane archiwa-przynęty i klasyczny spear-phishing.
W 2025 r. IBM X-Force wskazywał na szeroki arsenał i nakładające się klastry aktywności przypisywane temu ekosystemowi (m.in. ToneShell/Pubload oraz nowe techniki dystrybucji), co dobrze tłumaczy, dlaczego CoolClient jest dziś „rozbudowywany” zamiast zastępowany.

Analiza techniczna / szczegóły luki

1) Łańcuch uruchomienia i wieloetapowość (.DAT)

Z obserwacji badaczy wynika, że CoolClient korzysta z zaszyfrowanych plików .DAT i wieloetapowego wykonania. W opisie Kaspersky widoczny jest schemat, w którym implant:

odszyfrowuje kolejne artefakty (np. time.dat, loader.dat, main.dat),
uruchamia proces-pośrednik (write.exe) i wstrzykuje do niego kolejny etap,
buduje trwałość przez Run key, usługę systemową oraz zaplanowane zadanie.

2) Utrzymanie uprawnień i „passuac”

Warianty widziane w terenie wspierają obejście UAC i eskalację: przy sprzyjających warunkach uruchamiany jest tryb „passuac”, a następnie ustawiana jest trwałość przez zadanie harmonogramu.

3) Nowe funkcje: schowek, aktywne okno, sniffing proxy

Nowością w aktualnych wariantach jest:

monitor schowka (m.in. poprzez typowe API systemowe używane przez clipboard stealery),
telemetria aktywnego okna (np. tytuł okna),
HTTP proxy credential sniffer oparty o inspekcję pakietów i ekstrakcję nagłówków.

4) Ekosystem pluginów i zdalna powłoka

CoolClient utrzymuje architekturę z pluginami ładowanymi w pamięci, rozszerzoną m.in. o:

plugin zdalnej powłoki (ukryty cmd.exe, I/O przez potoki),
plugin zarządzania usługami (enumeracja, start/stop, modyfikacje),
rozbudowany plugin menedżera plików (mapowanie dysków sieciowych, kompresja ZIP, wyszukiwanie, uruchamianie plików).

5) Infostealery: Chrome/Edge/Chromium i eksfiltracja „przez legalne chmury”

W operacjach udokumentowano wdrażanie stealerów kradnących loginy z przeglądarek (różne warianty pod Chrome, Edge i Chromium-based).
Co istotne operacyjnie: w części przypadków eksfiltracja (np. pliki cookies) była wykonywana narzędziowo (np. przez curl) do legalnych usług typu Google Drive, z użyciem tokenów/kluczy wbudowanych w działania aktora, co utrudnia prostą blokadę na podstawie „złośliwej domeny”.

6) Dystrybucja: legalne oprogramowanie i DLL sideloading

BleepingComputer (na bazie ustaleń Kaspersky) wskazuje, że w obserwowanych atakach malware bywał wdrażany przez legalne komponenty związane z Sangfor, a wcześniej operatorzy uruchamiali CoolClient przez DLL side-loading z wykorzystaniem podpisanych binariów (np. popularne aplikacje użytkowe).

Uwaga „na radar”: badacze sygnalizują także użycie nieopisanego wcześniej rootkita w powiązaniu z tym zestawem narzędzi, ale szczegóły mają zostać opublikowane w osobnym raporcie.

Praktyczne konsekwencje / ryzyko

Kompromitacja tożsamości: kradzież haseł/cookies/sesji z przeglądarek to ryzyko przejęcia dostępu do poczty, SSO, paneli administracyjnych i narzędzi chmurowych.
Trudniejsza detekcja na poziomie sieci: eksfiltracja przez popularne legalne usługi (np. Google Drive) może „zniknąć w szumie” i wyglądać jak typowy ruch biznesowy.
Wysokie ryzyko post-exploitation: pluginy (shell, zarządzanie usługami, operacje na plikach) i techniki eskalacji/UAC sprzyjają długiej obecności w sieci i lateral movement.

Rekomendacje operacyjne / co zrobić teraz

Ochrona poświadczeń i sesji

Włącz/egzekwuj MFA odporne na phishing (FIDO2/WebAuthn) dla kont uprzywilejowanych i dostępu do krytycznych SaaS.
Rotuj hasła i unieważnij sesje tam, gdzie wykryto anomalie przeglądarkowe (cookies/tokens).

Detekcja na endpointach (EDR)

Poluj na nietypowe uruchomienia i wstrzyknięcia z udziałem procesów typu write.exe oraz aktywności wokół zaszyfrowanych .dat i nietypowych usług/zadań harmonogramu.
Monitoruj wywołania związane ze schowkiem oraz pobieranie danych logowania z profili przeglądarek (szczególnie w kontekście narzędzi typu curl).

Kontrola ruchu do usług chmurowych

Nie blokuj „w ciemno” Google Drive, ale wdrażaj CASB / DLP / polityki uploadu dla stacji i kont uprzywilejowanych (kto, co i skąd wysyła pliki).
W proxy/secure web gateway ustaw alerty na masowe uploady i podejrzane nagłówki autoryzacji w nietypowych kontekstach (np. curl na stacjach użytkowników).

Higiena oprogramowania i odporność na sideloading

Ogranicz uruchamianie nieautoryzowanych binariów (AppLocker/WDAC), zwłaszcza z katalogów użytkownika i ścieżek tymczasowych.
Waliduj łańcuch dostaw: jeśli w środowisku jest oprogramowanie wykorzystywane do „legitymizacji” uruchomienia, przejrzyj modele dystrybucji i podpisy/hashe.

Różnice / porównania z innymi przypadkami

W wielu kampaniach APT backdoor służy głównie do zdalnego sterowania i pobierania kolejnych modułów. Tu widać przesunięcie akcentu: CoolClient staje się platformą do kradzieży tożsamości (infostealery, schowek, proxy sniffing) oraz do eksfiltracji „pod przykrywką” legalnych usług.
Na tle wcześniejszych opisów Earth Preta/Mustang Panda (phishing, archiwa-przynęty, szeroki arsenał) to spójna ewolucja: mniej hałaśliwe domeny C2 w warstwie eksfiltracji, większy nacisk na dostęp przez konta i sesje.

Podsumowanie / kluczowe wnioski

CoolClient w najnowszych kampaniach Mustang Panda/HoneyMyte to już nie tylko „backdoor”, ale modułowa platforma post-exploitation z funkcjami typowymi dla wyspecjalizowanych złodziei danych (schowek, przeglądarki, proxy) i z mechanizmami utrzymania dostępu (usługi, taski, obejście UAC). Priorytet obrony powinien przesunąć się na ochronę tożsamości (MFA/FIDO2), telemetry EDR wokół przeglądarek i narzędzi transferu, oraz kontrolę uploadów do legalnych chmur.

Źródła / bibliografia

BleepingComputer – opis kampanii i podsumowanie zmian w CoolClient (27 stycznia 2026). (BleepingComputer)
Kaspersky Securelist (GReAT) – analiza techniczna CoolClient i stealerów (27 stycznia 2026). (Securelist)
Trend Micro – tło dot. Earth Preta/Mustang Panda i taktyk kampanii (2023). (www.trendmicro.com)
IBM X-Force – kontekst dot. Hive0154/Mustang Panda, arsenału i technik dystrybucji (2025). (IBM)

Ponad 6 tys. serwerów SmarterMail narażonych na automatyczne przejęcia kont admina (CVE-2026-23760)

Wprowadzenie do problemu / definicja luki

SmarterMail (serwer pocztowy i platforma współpracy od SmarterTools) znalazł się na celowniku masowych, zautomatyzowanych ataków po ujawnieniu krytycznej luki CVE-2026-23760. Błąd pozwala bez uwierzytelnienia przejąć konto administratora poprzez nieprawidłowo zaprojektowane API resetu hasła, a następnie – dzięki wbudowanym funkcjom administracyjnym – doprowadzić do zdalnego wykonania poleceń na hoście (RCE).

Równolegle organizacje typu Shadowserver raportowały tysiące instancji wystawionych do internetu, które wyglądały na podatne, a analitycy obserwowali już ataki „in the wild”.

W skrócie

CVE-2026-23760: obejście uwierzytelnienia w API resetu hasła; dotyczy wersji przed build 9511.
Wektor: POST /api/v1/auth/force-reset-password akceptuje żądania anonimowe i w krytycznej ścieżce dla sysadmina nie weryfikuje starego hasła / tokenu resetu.
Skutek: przejęcie konta admina → szybka eskalacja do RCE/SYSTEM przez funkcje administracyjne (np. wykonywanie komend).
Eksploatacja była obserwowana masowo i automatycznie (sekwencje żądań API, tworzenie „System Events”, sprzątanie śladów).
Skala: raportowano >6 000 publicznie dostępnych serwerów potencjalnie narażonych.

Kontekst / historia / powiązania

CVE-2026-23760 wypłynęło krótko po innej krytycznej luce w SmarterMail (CVE-2025-52691), co podbiło zainteresowanie atakujących (i presję na zespoły IT). BleepingComputer opisał sytuację jako serię zdarzeń: zgłoszenie, szybka poprawka, a następnie szybka adaptacja eksploitu i skanowanie internetu w poszukiwaniu podatnych serwerów.

Istotny kontekst operacyjny: w przypadku serwerów pocztowych ekspozycja na internet jest często „z definicji” (webmail, panel admina, API), więc okno czasowe między patchem a masową eksploatacją bywa wyjątkowo krótkie. SecurityWeek cytował watchTowr, że poprawka została szybko przeanalizowana (reverse engineering) i zaczęła być wykorzystywana na szeroką skalę.

Analiza techniczna / szczegóły luki

1) Root cause: reset hasła admina bez dowodu tożsamości

watchTowr opisał problem jako błąd w logice resetu hasła: endpoint force-reset-password jest dostępny anonimowo (co samo w sobie bywa normalne dla resetów), ale ścieżka dla kont sysadmin pozwala podać Username i NewPassword bez weryfikacji OldPassword lub tokenu resetu.

W praktyce: jeśli atakujący zna (lub zgadnie) nazwę konta administratora (często „admin”), może zresetować hasło i zalogować się jako administrator.

2) Od przejęcia konta do RCE – dwie obserwowane ścieżki

Ścieżka A (watchTowr): po przejęciu sysadmina możliwe jest doprowadzenie do wykonania poleceń systemowych przez wbudowane funkcje administracyjne (watchTowr opisał drogę przez ustawienia i mechanizm, który finalnie uruchamia komendę na hoście).
Ścieżka B (Huntress): w atakach „in the wild” widziano użycie funkcji System Events – napastnik po zdobyciu tokena dostępu tworzył złośliwy event-hook, wyzwalał go (np. dodaniem domeny), a potem wykonywał działania porządkowe (kasowanie domeny i hooka).

3) Sygnały masowej automatyzacji

Huntress pokazał typową sekwencję żądań API obserwowaną u wielu ofiar w krótkich odstępach czasu (co wygląda na automatyczne skrypty), zaczynając od wymuszenia resetu hasła, potem autoryzacji i konfiguracji mechanizmów do wykonania komend.

Praktyczne konsekwencje / ryzyko

Przejęty serwer SmarterMail to zwykle „klucz do królestwa” poczty:

dostęp do skrzynek, korespondencji i danych wrażliwych,
możliwość podszywania się (phishing/BEC), reguły przekierowań, utrwalanie dostępu,
infrastruktura do dalszych ataków (malware, pivot w sieci, kradzież poświadczeń),
ryzyko incydentu zgodności (RODO), reputacji i ciągłości działania.

NVD wprost wskazuje, że uprawnienia sysadmina w SmarterMail mogą przekładać się na administracyjne uprawnienia na hoście (SYSTEM/root) dzięki wbudowanym funkcjom zarządzania – co z perspektywy IR oznacza traktowanie takiego zdarzenia jak pełne przejęcie serwera.

Rekomendacje operacyjne / co zrobić teraz

1) Patch i weryfikacja wersji

Zaktualizuj do build 9511 lub nowszego (wszystko „przed 9511” jest wprost wskazywane jako podatne).

2) Jeśli nie możesz zaktualizować natychmiast (awaryjnie)

ogranicz dostęp do panelu/web API (VPN/allowlista IP, przynajmniej dla interfejsu administracyjnego),
rozważ tymczasowe reguły reverse proxy/WAF ograniczające dostęp do ścieżek API resetu hasła (uwaga: to obejście, nie „fix”),
włącz monitoring anomalii na endpointach /api/v1/auth/* i akcjach administracyjnych.

3) „Assume breach” – szybkie polowanie i IR

Szukaj w logach (proxy / aplikacyjnych) nietypowych żądań:

POST /api/v1/auth/force-reset-password oraz dalszych sekwencji API,
tworzenia/edycji System Events / event-hooków i operacji dodania/usunięcia domen (pattern z Huntress).

IOCs/sygnały (wg Huntress):

powtarzające się, szybkie sekwencje żądań API,
user-agent python-requests/2.32.4 widziany w atakach,
artefakt plikowy wskazywany w analizie Huntress (plik z wynikami rozpoznania).

4) Higiena po incydencie

reset haseł kont uprzywilejowanych (i rotacja kluczy/sekretów, jeśli serwer miał dostęp do innych systemów),
przegląd reguł przekazywania poczty, integracji i webhooków,
sprawdzenie trwałości (scheduled tasks, usługi, web-shelle, nieznane binaria),
segmentacja i minimalizacja ekspozycji usług zarządzających.

Różnice / porównania z innymi przypadkami

Warto odróżnić dwie głośne luki SmarterMail z przełomu stycznia:

CVE-2026-23760 – „czyste” przejęcie admina przez reset hasła bez weryfikacji (API), a potem RCE jako konsekwencja uprawnień admina i funkcji administracyjnych.
CVE-2025-52691 – wcześniejsza, krytyczna podatność pre-auth (opisywana jako droga do RCE na niezałatanych serwerach), wspominana w kontekście tej fali ataków.

Operacyjnie: w CVE-2026-23760 kluczowe jest, że atakujący może „wejść drzwiami frontowymi” jako admin (zmieniając hasło), co utrudnia detekcję, jeśli organizacja monitoruje wyłącznie klasyczne wskaźniki exploitów RCE.

Podsumowanie / kluczowe wnioski

CVE-2026-23760 to krytyczny błąd projektowy w API resetu hasła, który umożliwia przejęcie konta sysadmina i w praktyce prowadzi do pełnego kompromisu serwera.
Skala ekspozycji jest duża (tysiące instancji wystawionych do internetu), a eksploatacja była obserwowana jako zautomatyzowana.
Najważniejsze działania: aktualizacja do build 9511+, ograniczenie ekspozycji panelu/API oraz szybkie threat hunting pod kątem sekwencji API i nadużyć System Events.

Źródła / bibliografia

BleepingComputer – o skali ekspozycji i trwających atakach (BleepingComputer)
NVD (NIST) – opis CVE-2026-23760, wersje podatne, charakter wpływu (NVD)
watchTowr Labs – analiza techniczna root cause i PoC dla force-reset-password (watchTowr Labs)
Huntress – obserwacje ataków „in the wild”, sekwencje API i IOCs (Huntress)
SecurityWeek – kontekst masowej eksploatacji i mechaniki nadużyć (SecurityWeek)

Microsoft łata aktywnie wykorzystywany 0-day w Office (CVE-2026-21509) – obejście zabezpieczeń OLE/COM i pilne działania dla adminów

Wprowadzenie do problemu / definicja luki

Pod koniec stycznia 2026 Microsoft wydał awaryjne, pozacykliczne poprawki (out-of-band) dla podatności 0-day w Microsoft Office, która – co najważniejsze – była już aktywnie wykorzystywana w atakach. Luka otrzymała identyfikator CVE-2026-21509 i jest klasyfikowana jako Security Feature Bypass: nie chodzi więc o „klasyczne RCE”, ale o ominięcie mechanizmów ochronnych w Office związanych z kontrolkami COM/OLE.

W skrócie

CVE: CVE-2026-21509
Typ: obejście zabezpieczeń (Security Feature Bypass), powiązane z decyzjami bezpieczeństwa opartymi o niezaufane dane (CWE-807)
Wektor CVSS (CNA/Microsoft): 7.8 HIGH, AV:L / UI:R (wymagane działania użytkownika)
Warunek ataku: dostarczenie spreparowanego pliku Office i nakłonienie ofiary do otwarcia; Preview Pane nie jest wektorem ataku
Zakres: wiele wersji Office (m.in. 2016/2019/LTSC/365); dla części wydań ochrona ma być realizowana „po stronie usługi” i wymaga restartu aplikacji
KEV: podatność trafiła do kontekstu Known Exploited Vulnerabilities (KEV); w danych NVD widać m.in. Date Added: 2026-01-26 oraz Due Date: 2026-02-16

Kontekst / historia / powiązania

Ataki na łańcuch „dokument → elementy OLE/COM → uruchomienie niebezpiecznej logiki” to stały motyw kampanii phishingowych i malware’owych. W tym przypadku Microsoft jasno wskazuje, że aktualizacja dotyczy obejścia „OLE mitigations”, czyli mechanizmów ograniczających ryzyko podatnych kontrolek COM/OLE. To ważna wskazówka: nawet jeśli sam błąd nie jest „pełnym RCE”, to może otwierać drogę do kolejnych etapów ataku (np. uruchomienia komponentów, które powinny zostać zablokowane przez polityki/mitigacje).

Analiza techniczna / szczegóły luki

Co wiemy na pewno (z advisory i opisów technicznych)

Opis z NVD (na podstawie danych od CNA/Microsoft): „Reliance on untrusted inputs in a security decision in Microsoft Office…” – czyli mechanizm decyzyjny bezpieczeństwa może zostać oszukany przez niezaufane wejście.
Microsoft i media branżowe łączą problem bezpośrednio z OLE/COM i mechanizmami ochrony („OLE mitigations”).

Warunki exploitacji

Atak lokalny (AV:L) i wymagana interakcja użytkownika (UI:R): typowy scenariusz to phishing / spearphishing z załącznikiem Office lub plikiem pobieranym z internetu, który użytkownik otwiera.
Microsoft podkreśla, że Preview Pane nie jest wektorem, ale otwarcie pliku przez użytkownika już tak.

Mitigacja „kill bit” (COM Compatibility)

W materiałach opisano obejście zmniejszające ryzyko (szczególnie gdy łatka nie jest jeszcze dostępna dla danej edycji): w rejestrze Windows, w gałęzi COM Compatibility, tworzy się klucz dla konkretnego CLSID i ustawia wartość Compatibility Flags = 0x400. To podejście przypomina klasyczne „kill bity” blokujące problematyczne komponenty COM/ActiveX.

Praktyczne konsekwencje / ryzyko

Realne ryzyko operacyjne: aktywne wykorzystanie „in-the-wild” oznacza, że kampanie już trwają, a PoC nie jest konieczny, by zobaczyć skutki w organizacji.
Bypass zabezpieczeń to często początek łańcucha: ominięcie mitigacji OLE/COM może zwiększyć skuteczność ataków dokumentowych i obniżyć próg wejścia dla kolejnych technik (np. uruchomienia komponentu, który miał być zablokowany).
Presja czasowa dla organizacji: NVD wskazuje, że CVE jest powiązane z KEV i ma datę „due date” 16 lutego 2026 (co praktycznie wymusza szybkie domknięcie tematu w patch management).

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „od najpilniejszych” – tak, żeby dało się je wdrożyć nawet w dużym środowisku:

1) Zweryfikuj, które edycje Office są w użyciu

Zidentyfikuj: Office 2016, Office 2019, LTSC 2021/2024, Microsoft 365 Apps – podatność dotyczy wielu linii produktowych.

2) Wymuś aktualizacje / restart aplikacji Office

Dla części wersji (Office 2021 i nowsze / M365) Microsoft wskazuje ochronę przez service-side change, ale z warunkiem: użytkownicy muszą zrestartować aplikacje Office, aby mechanizm zaczął działać. W praktyce: komunikat do użytkowników + wymuszenie restartu (np. po logoffie, przez narzędzia EDR/ITSM).

3) Jeśli łatka nie jest dostępna dla Twojej edycji – zastosuj mitigację rejestrową

Jeżeli masz środowiska, gdzie update jeszcze nie dotarł (w materiałach wskazywano opóźnienia dla 2016/2019), rozważ tymczasową mitigację w rejestrze w gałęziach COM Compatibility z ustawieniem Compatibility Flags = 0x400 dla wskazanego CLSID. Najbezpieczniej wdrożyć to jako kontrolowany GPO/Intune remediation (z backupem i rollbackiem).

4) Utwardź warstwę „dokumenty z internetu”

Utrzymuj / egzekwuj Protected View oraz polityki ograniczające uruchamianie zawartości aktywnej z plików pobranych z internetu (MOTW). Microsoft wprost wskazuje, że ustawienia ochronne typu Protected View dają dodatkową warstwę obrony.

5) Hunting i detekcja

Potraktuj incydent jak „kampanię dokumentową”: poluj na nietypowe załączniki Office, wzrost otwarć plików z maili zewnętrznych, anomalie procesów potomnych Office (WinWord/Excel/PowerPoint) i zdarzenia związane z COM/OLE.
Microsoft wspomina o dostępnych detekcjach w Defenderze (warto upewnić się, że sygnatury/telemetria są aktualne).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

0-day „bypass” vs „RCE”: CVE-2026-21509 nie jest opisywany jako klasyczne zdalne wykonanie kodu bez udziału użytkownika – tu kluczowe są interakcja użytkownika i ominięcie mechanizmu ochrony. To często mniej „medialne”, ale w praktyce równie groźne, bo zwiększa skuteczność dobrze znanych technik (phishing + dokument).
Mitigacja typu kill bit: użycie COM Compatibility i flag kompatybilności mocno przypomina historyczne podejście do blokowania podatnych komponentów ActiveX/COM – to sygnał, że problem może dotyczyć „konkretnego obiektu/klasy” w ekosystemie OLE/COM.

Podsumowanie / kluczowe wnioski

CVE-2026-21509 to aktywnie wykorzystywany 0-day w Microsoft Office, sklasyfikowany jako obejście zabezpieczeń OLE/COM.
Priorytetem jest szybka redukcja ekspozycji: aktualizacje, wymuszenie restartu Office tam, gdzie ochrona jest „service-side”, oraz mitigacje rejestrowe w środowiskach, które czekają na patch.
Traktuj temat jak incydent „high urgency”: NVD wskazuje powiązanie z KEV i termin działań do 16 lutego 2026.

Źródła / bibliografia

BleepingComputer – opis OOB patch, zakres wersji, mitigacje rejestrowe, komentarz Microsoft (BleepingComputer)
NVD (NIST) – CVSS 3.1 (CNA), opis, CWE-807, informacja o KEV (date added / due date) (nvd.nist.gov)
The Hacker News – podsumowanie techniczne, restart aplikacji, wersje/aktualizacje, kroki mitigacji (The Hacker News)
SecurityWeek – kontekst „in-the-wild”, brak szczegółów o kampanii, ogólna ocena ryzyka (SecurityWeek)
The Register – dodatkowe tło i ujęcie operacyjne dla OOB patch (The Register)

Nowe ataki ClickFix nadużywają skryptów Windows App-V, by dostarczać malware (Amatera Stealer)

Wprowadzenie do problemu / definicja luki

ClickFix to nie „luka” w sensie CVE, tylko powtarzalny wzorzec socjotechniczny: ofiara jest przekonywana, by sama uruchomiła polecenie w Windows (najczęściej przez Win+R) pod pretekstem „weryfikacji” albo „naprawy problemu”. W najnowszej odsłonie atakujący dołożyli sprytny twist: zamiast odpalać PowerShell bezpośrednio, proxy’ują wykonanie przez legalny, podpisany komponent Microsoftu związany z App-V.

W skrócie

Kampania startuje od fałszywego CAPTCHA i instrukcji: wklej/uruchom komendę w oknie „Uruchamianie” (Win+R).
Komenda nadużywa SyncAppvPublishingServer.vbs (App-V) odpalonego przez wscript.exe, aby „przykryć” uruchomienie PowerShell i zmienić typowy łańcuch procesów.
Łańcuch ma bramki anty-sandbox: sprawdzanie zachowania użytkownika, kolejności uruchomienia i stanu schowka; w środowiskach analitycznych potrafi „wisieć” w nieskończoność.
Konfiguracja jest pobierana z publicznego Google Calendar (.ics) (dead-drop), a jeden z etapów ukrywa payload w PNG (steganografia) i ładuje go w pamięci.
Finalnie celem jest Amatera Stealer (rodzina infostealer sprzedawana jako MaaS, rozwijana i „utwardzana” pod kątem evasion).

Kontekst / historia / powiązania

Microsoft wskazuje, że ClickFix rośnie od 2024 r. i bywa łączony z phishingiem, malvertisingiem oraz kompromitacją stron — a kluczową przewagą napastnika jest wymuszenie interakcji człowieka, która potrafi ominąć część automatycznych detekcji.

W tej kampanii istotne jest „życie z ziemi” (LotL/LOLBins): MITRE opisuje nadużycie SyncAppvPublishingServer.vbs jako sub-technikę System Script Proxy Execution, gdzie legalny skrypt może proxy’ować wykonanie poleceń PowerShell zamiast bezpośredniego powershell.exe.

Analiza techniczna / szczegóły luki

Poniżej najważniejsze elementy łańcucha (z perspektywy IR/DFIR i detekcji):

1) Wejście: fake CAPTCHA → Win+R
Użytkownik widzi stronę „human verification” i dostaje instrukcję uruchomienia komendy. To klasyczny ClickFix, ale dalej robi się nietypowo.

2) Proxy wykonania: wscript.exe + SyncAppvPublishingServer.vbs
Zamiast explorer.exe → powershell.exe, pojawia się uruchomienie przez wscript.exe i skrypt App-V (SyncAppvPublishingServer.vbs). To zmienia „process ancestry” i może obniżać skuteczność reguł nastawionych na typowe wzorce PowerShell.

3) „Execution gates” i anty-analiza
Blackpoint opisuje bramkowanie oparte m.in. o:

walidację kolejności kroków i zachowania użytkownika,
kontrolę schowka (marker potwierdzający manualne wklejenie),
ciche „zawieszenie” (np. nieskończone oczekiwanie), by marnować zasoby sandboxów.

4) LotL infrastruktury: konfiguracja w Google Calendar (.ics)
Zamiast twardo kodować parametry C2/loadera, kampania pobiera je z publicznego pliku kalendarza (ICS) — prostej tekstówki, którą łatwo aktualizować bez ruszania pierwszych etapów.

5) Fileless/stage’in memory + steganografia w PNG
W kolejnych etapach payload jest odszyfrowywany/rozpakowywany w pamięci, a jedna z metod dostarczania to ukrycie zaszyfrowanego ładunku w obrazie PNG (steganografia).

6) Payload: Amatera Stealer
Amatera jest opisywana przez Proofpoint jako rebranding ACR Stealera, oferowany w modelu MaaS i rozwijany pod kątem unikania detekcji; w praktyce to „warstwa monetyzacji” wielu web-inject / ClickFix-like łańcuchów.

Praktyczne konsekwencje / ryzyko

Celowanie w środowiska firmowe: App-V częściej występuje w środowiskach Enterprise/Education; tam też „naturalnie” działa SyncAppvPublishingServer.vbs, więc aktywność łatwiej ukryć w szumie.
Kradzież danych uwierzytelniających i sesji: infostealery typowo polują na przeglądarki, hasła, tokeny, portfele krypto i dane aplikacji — co szybko przekłada się na przejęcia kont i dalszą propagację. (Charakterystyka Amatera jako aktywnie rozwijanego stealera/MaaS.)
Niższa skuteczność „klasycznych” reguł PowerShell: jeżeli polityki/detekcje są budowane głównie wokół powershell.exe, proxy przez wscript.exe + podpisany skrypt może wyślizgiwać się spod części alertów.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h):

Edukacja i komunikat do użytkowników: „Nigdy nie wklejaj poleceń do Win+R/Terminala z przypadkowych stron (CAPTCHA, ‘fix’, ‘verify’)”. Microsoft wprost wskazuje ten element jako rdzeń ClickFix i punkt, w którym szkolenie realnie obniża ryzyko.
Detekcja: wscript.exe → SyncAppvPublishingServer.vbs z osadzonym PowerShell
- MITRE sugeruje monitorowanie uruchomień tego skryptu przez wscript.exe i anomalii w linii poleceń, gdzie skrypt służy jako proxy dla PowerShell.
Ograniczenie powierzchni: blokada skryptu, jeśli App-V nie jest wymagany
- MITRE w mitigacjach mówi wprost: jeśli podpisane skrypty proxy-execution nie są potrzebne, warto je blokować polityką kontroli aplikacji. (WDAC/AppLocker / allow-listing).

Wzmocnienia średnioterminowe (1–4 tyg.):

Hardening stacji: ograniczenie możliwości uruchamiania narzędzi i interpreterów skryptowych tam, gdzie nie są niezbędne (w tym kontrola VBScript/WSH w środowisku).
Telemetria PowerShell: gdzie to możliwe, włącz/utrzymaj logowanie (Script Block Logging/AMSI) i koreluj z nietypowym proces ancestry (PowerShell bez powershell.exe na wierzchu).
Polityki uprawnień: minimalizacja lokalnych adminów oraz kontrola makr/skryptów i stref (szczególnie gdy wektor wejścia to web).
Polowanie po IoC/TTP: nietypowe pobieranie .ics z publicznych usług, sekwencje loaderów „in-memory”, pobieranie PNG w kontekście skryptów i późniejsze deszyfrowanie/uruchomienie.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Klasyczny ClickFix często sprowadza się do „wklej i uruchom PowerShell”. Microsoft opisuje, że wariantów jest wiele, ale rdzeń pozostaje ten sam: użytkownik wykonuje polecenie, bo wygląda na element weryfikacji/naprawy.

To, co wyróżnia opisywaną kampanię, to proxy execution przez App-V (LOLBin) oraz wieloetapowa, konsekwentna optymalizacja pod anty-analizę: bramkowanie schowkiem i kolejnością, dead-drop w Google Calendar i steganografia w PNG, wszystko z naciskiem na „ciche” wykonanie w pamięci.

Podsumowanie / kluczowe wnioski

ClickFix dalej działa, bo wykorzystuje nawyk „szybkiego naprawiania” problemu — a ta kampania pokazuje, że napastnicy potrafią go połączyć z podpisanymi komponentami Windows i przemyślanym łańcuchem evasion.
SyncAppvPublishingServer.vbs nie jest egzotyką w ATT&CK — to rozpisana technika proxy-execution; jeśli masz App-V, musisz liczyć się z nadużyciem tego elementu.
Największy „ROI” na start: uświadomienie użytkowników + detekcje na wscript/App-V + kontrola aplikacji (blokuj, jeśli niepotrzebne).

Źródła / bibliografia

BleepingComputer – „New ClickFix attacks abuse Windows App-V scripts to push malware” (26 stycznia 2026) (BleepingComputer)
Blackpoint Cyber – „Novel Fake CAPTCHA Chain Delivering Amatera Stealer” (Blackpoint)
MITRE ATT&CK – T1216.002 System Script Proxy Execution: SyncAppvPublishingServer (attack.mitre.org)
Microsoft Security Blog – „Think before you Click(Fix): Analyzing the ClickFix social engineering technique” (21 sierpnia 2025) (Microsoft)
Proofpoint – „Amatera Stealer: Rebranded ACR Stealer With Improved Evasion, Sophistication” (16 czerwca 2025) (Proofpoint)

„Stanley” – nowy toolkit malware do phishingu przez spoofing stron z prawdziwym URL w pasku adresu

Wprowadzenie do problemu / definicja luki

„Stanley” to sprzedawany w modelu malware-as-a-service (MaaS) zestaw narzędzi, który umożliwia ataki phishingowe w sposób wyjątkowo podstępny: ofiara widzi w pasku adresu legalny adres strony, ale treść, z którą wchodzi w interakcję, jest podmieniona na phishingową. To uderza w najczęstszy nawyk bezpieczeństwa („sprawdź URL”), bo ten sygnał przestaje być wiarygodny.

W skrócie

Toolkit „Stanley” był reklamowany na rosyjskojęzycznym forum, z ceną ok. 2–6 tys. USD; wariant premium ma m.in. panel zarządzania i „gwarancję” publikacji w Chrome Web Store.
Przykładowa wtyczka („Notely”) łączy legalne funkcje z nadużyciami uprawnień przeglądarki, aby przechwytywać wizyty na stronach i nakładać pełnoekranowy phishing.
Mechanizm opiera się m.in. o osadzanie treści w iframe i (według badaczy) obchodzenie zabezpieczeń typu X-Frame-Options / CSP.

Kontekst / historia / powiązania

Varonis opisuje „Stanley” jako kolejny etap ewolucji ataków „browser-native”: zamiast klasycznych fałszywych domen czy przekierowań – mamy manipulację sesją i treścią w przeglądarce z użyciem rozszerzenia. W tle jest też problem modelu „review-once, update-anytime” w sklepach z dodatkami: rozszerzenie może wyglądać na nieszkodliwe w momencie weryfikacji, a później zmienić zachowanie.

Analiza techniczna / szczegóły luki

1) Dystrybucja i „opakowanie” wtyczki

W opisywanym przypadku przynętą jest rozszerzenie „Notely” (notatnik/zakładki) z realną funkcjonalnością, ale jednocześnie proszące o uprawnienia pozwalające „widzieć i kontrolować” odwiedzane strony.
„Stanley” ma oferować różne ścieżki instalacji (w tym Web Store), a panel operatora ułatwia zarządzanie infekcjami i regułami przechwyceń.

2) Panel zarządzania i reguły „URL hijacking”

Operator dostaje webowy panel z listą hostów (identyfikowanych m.in. po IP) oraz możliwością ustawiania par źródłowy URL → docelowy URL (phishing). Istotne jest to, że reguły można aktywować/dezaktywować per ofiara, co umożliwia „atak na żądanie”.

3) Podmiana treści przy zachowaniu legalnego adresu

Z opisu wynika, że rozszerzenie przechwytuje wejście na legalną domenę i nakłada na stronę pełnoekranowy iframe z treścią atakującego – a pasek adresu dalej pokazuje prawdziwą domenę (np. giełdy krypto). To znacząco zwiększa skuteczność kradzieży danych logowania.

4) Obchodzenie zabezpieczeń anty-framing

Varonis wiąże działanie z usuwaniem/obchodzeniem nagłówków X-Frame-Options i polityk CSP (mechanizmy, które mają ograniczać osadzanie strony w ramkach i zmniejszać ryzyko clickjackingu). Jeśli atakujący potrafi doprowadzić do skutecznego framingu, może wiarygodnie „przykleić” phishing do legalnej sesji użytkownika.

5) Komunikacja z C2 i odporność operacyjna

Wtyczka ma mechanizm cyklicznego odpytywania serwera C2 oraz zapasową rotację domen, żeby utrzymać kontrolę nawet po blokadach. Varonis opisał też konkretne wskaźniki (domeny/panel) i fakt zgłoszenia sprawy do Chrome Web Store.

Praktyczne konsekwencje / ryzyko

Użytkownicy: kradzież haseł, tokenów sesyjnych, danych MFA (np. jednorazowych kodów) – bo atak odbywa się „na żywo”, w kontekście prawdziwego URL.
Firmy: wzrost skuteczności przejęć kont (ATO) na usługach SaaS/IdP, ryzyko BEC i eskalacji w łańcuchu dostępu (SSO), a także trudniejsza analiza incydentu, bo sygnały „phishing URL” mogą nie zadziałać.
Zespół SOC: klasyczne szkolenia „sprawdź domenę” stają się niewystarczające – trzeba monitorować rozszerzenia, ruch przeglądarki i anomalie sesji.

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji (IT/SecOps):

Wymuś allowlistę rozszerzeń (Chrome Enterprise / Edge for Business): blokuj instalację niezatwierdzonych dodatków, ogranicz uprawnienia „read and change data on all websites”.
Zablokuj znane IoC z raportu (domeny/panel/ID rozszerzenia) na warstwie DNS/Proxy/EDR i monitoruj komunikację przeglądarki do nietypowych domen C2.
Detekcja zdarzeń związanych z rozszerzeniami: nowe instalacje, nagłe aktualizacje, nietypowe połączenia wychodzące procesu przeglądarki, próby wstrzykiwania treści/ramkowania.
Wzmocnij tożsamość: FIDO2/WebAuthn (tam, gdzie możliwe), Conditional Access, krótkie sesje, ograniczanie tokenów i kontrola ryzyka logowań (zachowanie/urządzenia).
Szybka reakcja IR: w razie podejrzenia – izolacja profilu przeglądarki/użytkownika, reset sesji, wymuszenie wylogowań globalnych, rotacja haseł, przegląd uprawnień aplikacji OAuth.

Dla użytkowników:

Instaluj dodatki tylko, gdy są realnie potrzebne; czytaj zakres uprawnień (szczególnie dostęp do wszystkich stron).
Jeśli „coś wygląda jak logowanie”, ale pojawiło się nietypowo (np. po powiadomieniu z przeglądarki) – przerwij, otwórz stronę od nowa, sprawdź aktywne rozszerzenia.

Różnice / porównania z innymi przypadkami

Klasyczny phishing zwykle opiera się o podobną domenę/URL lub przekierowanie. „Stanley” celuje w sytuację, gdzie domena jest prawdziwa, a fałszywa jest warstwa interfejsu.
To bardziej „man-in-the-browser” niż „fałszywa strona”: rozszerzenie działa z uprawnieniami przeglądarki i może modyfikować zachowanie sesji. W ATT&CK pasuje to do technik związanych z Browser Extensions (T1176) i Browser Session Hijacking (T1185).

Podsumowanie / kluczowe wnioski

„Stanley” pokazuje, że phishing coraz częściej „przeprowadza się” w przeglądarce, a nie tylko „przed przeglądarką”. Gdy pasek adresu przestaje być sygnałem ostrzegawczym, kluczowe stają się: kontrola i monitoring rozszerzeń, egzekwowanie polityk przeglądarkowych oraz twardsze mechanizmy tożsamości (FIDO2/Conditional Access).

Źródła / bibliografia

SecurityWeek – opis kampanii i cech toolkitu „Stanley”. (SecurityWeek)
Varonis Threat Labs – analiza techniczna, kontekst, IoC i mechanika działania. (varonis.com)
MDN Web Docs – clickjacking oraz rola X-Frame-Options / CSP w ograniczaniu osadzania w iframe. (developer.mozilla.org)
MITRE ATT&CK – T1176 (Software Extensions) i T1185 (Browser Session Hijacking). (attack.mitre.org)

7 Typowych Pułapek W Procesie Zarządzania Incydentami I Jak Ich Unikać

Dlaczego to ma znaczenie

Gdy dochodzi do cyberincydentu, czas działa na niekorzyść obrony. To, jak zespół zareaguje w pierwszych godzinach, decyduje o tym, czy incydent będzie tylko drobnym potknięciem, czy pełnowymiarową katastrofą. Dobre przygotowanie potrafi zamienić potencjalny paraliż firmy w kontrolowane zdarzenie o minimalnym wpływie. Z kolei brak planu i chaotyczne działania “na gorąco” często tylko pogarszają sytuację.

Czytaj dalej