Archiwa: Admin - Strona 2 z 33

20 Wskaźników I KPI Cyberbezpieczeństwa Do Śledzenia W 2026 r.

Co naprawdę mierzyć w cyberbezpieczeństwie?

W świecie cyberbezpieczeństwa liczby nie kłamią. Kluczowe Wskaźniki (KPI) pozwalają zmierzyć, jak skutecznie bronimy się przed atakami, zamiast zgadywać na podstawie przeczucia. W 2026 roku, przy coraz sprytniejszych atakach (np. wykorzystujących AI) i rosnącej presji regulacyjnej, mierzenie wyników staje się obowiązkowe. Jeśli nie da się czegoś zmierzyć, nie da się tym efektywnie zarządzać – ta stara zasada menedżerska dotyczy także bezpieczeństwa IT.

Czytaj dalej

Krytyczna luka w HPE Aruba AOS-CX pozwala na reset haseł administratora bez logowania

Wprowadzenie do problemu / definicja

Hewlett Packard Enterprise opublikował poprawki dla krytycznej podatności w systemie Aruba Networking AOS-CX, wykorzystywanym w przełącznikach sieciowych klasy kampusowej i data center. Problem dotyczy interfejsu zarządzania przez WWW i może prowadzić do obejścia mechanizmów uwierzytelniania, a następnie do resetu hasła administratora bez wcześniejszego logowania.

Z perspektywy bezpieczeństwa infrastruktury jest to szczególnie groźne, ponieważ płaszczyzna zarządzania urządzeniami sieciowymi należy do najbardziej wrażliwych obszarów środowiska IT. Jej przejęcie może otworzyć drogę do dalszych zmian konfiguracyjnych, manipulacji ruchem i osłabienia kontroli bezpieczeństwa.

W skrócie

Podatność otrzymała oznaczenie CVE-2026-23813 oraz ocenę CVSS 9.8, co klasyfikuje ją jako lukę krytyczną. Umożliwia ona zdalne, nieuwierzytelnione oddziaływanie na webowy interfejs zarządzania AOS-CX.

Dotyczy wielu rodzin przełączników Aruba CX.
Może prowadzić do resetu hasła administratora bez logowania.
Narażone są m.in. serie 4100i, 6000, 6100, 6200, 6300, 6400, 8320, 8325, 8360, 9300 oraz 10000.
Producent udostępnił poprawki i zalecił ograniczenie dostępu do interfejsów zarządzania.

Kontekst / historia

Urządzenia sieciowe od dawna są traktowane jako elementy infrastruktury o wysokim poziomie zaufania. W praktyce oznacza to, że skuteczna kompromitacja przełącznika lub routera może dać atakującemu znaczącą przewagę operacyjną, w tym możliwość wpływu na segmentację, ścieżki komunikacyjne oraz mechanizmy kontroli dostępu.

W ostatnich latach rośnie zainteresowanie cyberprzestępców i grup zaawansowanych podatnościami w warstwie sieciowej. Ataki na urządzenia infrastrukturalne są atrakcyjne, ponieważ pozwalają ominąć część zabezpieczeń wdrażanych na stacjach roboczych i serwerach. Omawiana luka wpisuje się w ten trend, ponieważ dotyczy bezpośrednio interfejsu administracyjnego.

Równolegle z CVE-2026-23813 producent zaadresował również inne problemy bezpieczeństwa, w tym podatności wysokiego ryzyka związane z możliwością wstrzyknięcia i wykonania złośliwych poleceń przez uwierzytelnionego zdalnego napastnika, a także lukę średniego ryzyka pozwalającą na przekierowanie użytkownika do dowolnego adresu.

Analiza techniczna

Z opublikowanych informacji wynika, że źródłem problemu jest webowy interfejs zarządzania systemu AOS-CX. Luka umożliwia wykonanie operacji prowadzącej do resetu hasła administratora bez przejścia przez proces uwierzytelnienia, co w praktyce oznacza obejście podstawowych mechanizmów kontroli dostępu.

Taki scenariusz jest wyjątkowo niebezpieczny, ponieważ atakujący nie musi wcześniej przejąć sesji, zdobyć danych logowania ani wykorzystywać dodatkowego wektora wejścia. Wystarczy osiągalność interfejsu zarządzania z niezaufanego segmentu sieci, aby ryzyko realnego przejęcia urządzenia istotnie wzrosło.

Po przejęciu kontroli nad przełącznikiem możliwe stają się między innymi zmiany konfiguracji, modyfikacja polityk dostępu, ingerencja w segmentację VLAN, wpływ na trasowanie oraz utrudnianie detekcji poprzez zmianę ustawień logowania i monitoringu. W środowiskach zautomatyzowanych zagrożenie może rozszerzyć się także na inne zintegrowane komponenty.

Poprawki zostały udostępnione w wersjach AOS-CX 10.17.1001, 10.16.1030, 10.13.1161 oraz 10.10.1180. Dodatkowo producent zalecił wyłączenie HTTP(S) na interfejsach SVI i portach routowanych tam, gdzie nie jest to konieczne, oraz ograniczenie dostępu do punktów końcowych HTTPS i REST wyłącznie dla zaufanych klientów administracyjnych.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest możliwość przejęcia uprzywilejowanego dostępu do przełącznika bez uwierzytelnienia. W środowisku produkcyjnym może to przełożyć się nie tylko na pojedynczy incydent administracyjny, ale również na zaburzenie działania całego segmentu infrastruktury.

zakłócenie komunikacji sieciowej,
osłabienie integralności kluczowych usług biznesowych,
zmianę konfiguracji bezpieczeństwa,
uzyskanie trwałego punktu obecności w infrastrukturze,
ułatwienie ruchu bocznego do kolejnych segmentów sieci.

Ryzyko jest szczególnie wysokie tam, gdzie interfejs zarządzania nie został odseparowany od zwykłego ruchu sieciowego, dostęp nie jest ograniczony listami ACL, a organizacja nie prowadzi pełnego monitoringu zmian konfiguracyjnych. Nawet bez publicznego potwierdzenia masowego wykorzystania tej luki jej krytyczność uzasadnia natychmiastową reakcję.

Rekomendacje

Organizacje korzystające z przełączników HPE Aruba CX powinny w pierwszej kolejności zinwentaryzować wszystkie podatne urządzenia i zweryfikować używane wersje AOS-CX. Następnie należy jak najszybciej wdrożyć poprawione wydania systemu.

ograniczyć dostęp do interfejsów zarządzania wyłącznie do wydzielonych sieci administracyjnych,
wymusić filtrowanie ruchu do HTTPS i REST przy użyciu list ACL,
wyłączyć HTTP(S) na SVI i portach routowanych, jeśli nie są niezbędne,
przejrzeć logi pod kątem nietypowych operacji administracyjnych i zmian haseł,
zweryfikować integralność konfiguracji urządzeń po aktualizacji,
rozdzielić płaszczyznę zarządzania od ruchu użytkowników i usług produkcyjnych,
włączyć szczegółowe accounting, logging i monitoring działań administracyjnych,
przeprowadzić rotację poświadczeń uprzywilejowanych, jeśli istnieje podejrzenie ekspozycji.

Zespoły SOC i NOC powinny dodatkowo przygotować reguły wykrywania dla anomalii związanych z resetami kont administracyjnych, zmianami konfiguracji HTTPS i REST oraz nagłymi modyfikacjami polityk dostępu na przełącznikach.

Podsumowanie

CVE-2026-23813 to krytyczna podatność w HPE Aruba AOS-CX, która podkreśla znaczenie ochrony warstwy zarządzania urządzeniami sieciowymi. Możliwość zdalnego i nieuwierzytelnionego resetu hasła administratora tworzy scenariusz bezpośredniego przejęcia przełącznika, a w konsekwencji realne zagrożenie dla całej infrastruktury.

Kluczowe działania obejmują szybkie wdrożenie poprawek, ograniczenie ekspozycji interfejsów administracyjnych oraz wzmocnienie monitoringu i kontroli dostępu. Dla organizacji utrzymujących rozbudowane środowiska sieciowe jest to incydent, który powinien zostać potraktowany jako wysoki priorytet operacyjny.

Źródła

SecurityWeek — Critical HPE AOS-CX Vulnerability Allows Admin Password Resets

CrackArmor: dziewięć luk w AppArmor umożliwia eskalację do roota i osłabia izolację kontenerów

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa ujawnili zestaw dziewięciu podatności nazwanych zbiorczo CrackArmor, które dotyczą mechanizmu AppArmor w jądrze Linuksa. Problem obejmuje błędy klasy confused deputy, w których mniej uprzywilejowany użytkownik lub proces może skłonić komponent bezpieczeństwa do wykonania operacji wykraczających poza zakładany model uprawnień.

W praktyce oznacza to możliwość obejścia części ograniczeń narzucanych przez AppArmor, uzyskania lokalnej eskalacji uprawnień do roota oraz osłabienia zabezpieczeń opartych na izolacji kontenerów. To szczególnie istotne dla organizacji wykorzystujących AppArmor jako jedną z podstawowych warstw ochrony hostów i środowisk kontenerowych.

W skrócie

CrackArmor obejmuje dziewięć podatności w AppArmor zgłoszonych przez Qualys Threat Research Unit.
Problem ma dotyczyć jąder Linux od wersji 4.11 na dystrybucjach integrujących AppArmor.
Luki mogą umożliwiać manipulowanie profilami bezpieczeństwa przez pseudo-pliki i obchodzenie restrykcji user namespace.
Skutki obejmują lokalną eskalację uprawnień, ataki denial of service, osłabienie hardeningu usług oraz zwiększenie ryzyka naruszenia izolacji kontenerów.

Kontekst / historia

AppArmor to mechanizm Mandatory Access Control oparty na Linux Security Modules, od lat stosowany w celu ograniczania działań procesów przez precyzyjnie zdefiniowane profile bezpieczeństwa. Jest szeroko wykorzystywany w popularnych dystrybucjach, w tym w Ubuntu, Debianie i SUSE, gdzie pełni rolę dodatkowej warstwy kontroli dostępu.

W ostatnich latach AppArmor zyskał także znaczenie jako narzędzie ograniczające użycie nieuprzywilejowanych user namespaces. To ważne, ponieważ funkcja ta była wielokrotnie wykorzystywana jako element łańcuchów prowadzących do eskalacji uprawnień. Właśnie na styku polityk AppArmor, pseudo-plików jądra i obsługi przestrzeni nazw ujawniły się słabości określone jako CrackArmor.

Analiza techniczna

Z technicznego punktu widzenia CrackArmor opisuje klasę błędów logicznych typu confused deputy w sposobie egzekwowania polityk AppArmor. Tego typu wada pojawia się wtedy, gdy uprzywilejowany komponent wykonuje operację w imieniu mniej uprzywilejowanego podmiotu, ale nie weryfikuje poprawnie kontekstu bezpieczeństwa.

W efekcie atakujący może użyć legalnego mechanizmu ochronnego do osiągnięcia rezultatu, którego normalnie nie mógłby uzyskać bezpośrednio. Według ujawnionych analiz nieuprzywilejowany użytkownik może manipulować profilami bezpieczeństwa za pośrednictwem pseudo-plików, co w określonych scenariuszach pozwala zmienić sposób działania ochrony lub całkowicie osłabić jej skuteczność.

Istotny jest również wpływ na user namespaces. Jeżeli system polega na AppArmor jako głównym mechanizmie ograniczającym tworzenie nieuprzywilejowanych przestrzeni nazw użytkownika, obejście tych restrykcji może przywrócić atakującemu dostęp do funkcji jądra często wykorzystywanych w dalszej eksploatacji. To zwiększa powierzchnię ataku i ułatwia budowę bardziej złożonych łańcuchów naruszenia.

Badacze wskazali ponadto na ryzyko ataków typu denial of service, scenariusze prowadzące do wyczerpania stosu oraz odczyty poza buforem, które mogą dostarczać informacji przydatnych do obejścia KASLR. Oznacza to, że CrackArmor nie jest wyłącznie problemem integralności polityk bezpieczeństwa, ale potencjalnym punktem wspierającym dalszą eksploatację jądra.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem jest lokalna eskalacja uprawnień do roota. W środowiskach wielodostępnych, na hostach deweloperskich, serwerach CI/CD, bastionach oraz platformach kontenerowych oznacza to realne ryzyko pełnego przejęcia systemu. Po uzyskaniu roota atakujący może modyfikować konfigurację, instalować backdoory, wyłączać monitoring i utrzymywać trwały dostęp.

Drugim ważnym obszarem ryzyka jest izolacja kontenerów. Jeśli AppArmor stanowi element modelu separacji obciążeń, obejście jego polityk osłabia zasady least privilege i defense in depth. Nie musi to od razu oznaczać pełnego escape z każdego kontenera, ale znacząco obniża próg trudności dla atakującego.

Istotne pozostaje także ryzyko dla dostępności usług. Możliwość wymuszenia polityk blokujących lub wywołania błędów prowadzących do DoS może przełożyć się na awarie aplikacji, restarty procesów i przerwy w działaniu usług krytycznych. Szczególnie narażone są systemy, w których AppArmor jest aktywny domyślnie, a lokalny dostęp może uzyskać użytkownik nieuprzywilejowany albo proces podatny na zdalne wykonanie kodu.

Rekomendacje

Najważniejszym krokiem jest wdrożenie poprawek jądra dostarczonych przez producenta dystrybucji. W przypadku CrackArmor obejścia tymczasowe nie zapewniają równoważnego poziomu ochrony, dlatego priorytetem powinno być pełne aktualizowanie kernela i pakietów związanych z AppArmor.

Zidentyfikować hosty, na których AppArmor jest aktywny i egzekwuje profile dla usług lub kontenerów.
Sprawdzić, czy środowisko korzysta z ograniczeń user namespace opartych na AppArmor.
Przeanalizować ekspozycję systemów współdzielonych, platform developerskich i hostów kontenerowych.
Monitorować logi AppArmor, auditd oraz dzienniki jądra pod kątem nietypowych operacji związanych z profilami.
Ograniczyć lokalny dostęp użytkowników oraz możliwość uruchamiania kodu do czasu pełnego załatania systemów.
Zweryfikować dodatkowe warstwy ochrony, takie jak seccomp, capabilities oraz zabezpieczenia runtime kontenerów.

Z perspektywy hardeningu warto przyjąć, że AppArmor nie powinien być jedyną linią obrony. Skuteczna strategia bezpieczeństwa hostów i kontenerów wymaga podejścia wielowarstwowego, w którym obejście pojedynczego mechanizmu nie prowadzi automatycznie do pełnego kompromisu systemu.

Podsumowanie

CrackArmor to ważne przypomnienie, że nawet mechanizmy ochronne działające na poziomie jądra mogą stać się elementem łańcucha eksploatacji. Dziewięć ujawnionych luk w AppArmor pokazuje, jak groźne bywają błędy logiki w komponentach odpowiedzialnych za egzekwowanie polityk bezpieczeństwa.

Skutki obejmują lokalną eskalację do roota, osłabienie izolacji kontenerów, możliwość ataków DoS oraz ułatwienie dalszej eksploatacji jądra. Organizacje korzystające z AppArmor powinny potraktować ten zestaw podatności priorytetowo, zwłaszcza na hostach wielodostępnych i platformach kontenerowych.

Źródła

The Hacker News — https://thehackernews.com/2026/03/nine-crackarmor-flaws-in-linux-apparmor.html
AppArmor — Project Documentation — https://apparmor.net/
The Linux Kernel Documentation — AppArmor — https://docs.kernel.org/admin-guide/LSM/apparmor.html
Ubuntu Security Features — AppArmor unprivileged user namespace restrictions — https://wiki.ubuntu.com/Security/Features
Ubuntu Community Hub — Understanding AppArmor User Namespace Restriction — https://discourse.ubuntu.com/t/understanding-apparmor-user-namespace-restriction/58007

UNC6426 wykorzystuje atak na łańcuch dostaw nx npm do przejęcia uprawnień administratora AWS w 72 godziny

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą dziś do najpoważniejszych zagrożeń dla organizacji rozwijających aplikacje w modelu chmurowym. Incydent przypisywany grupie UNC6426 pokazuje, że kompromitacja pojedynczego pakietu w ekosystemie npm może stać się początkiem pełnego przejęcia środowiska deweloperskiego, repozytoriów kodu oraz infrastruktury AWS.

W opisywanym scenariuszu punktem wejścia była wcześniejsza kompromitacja pakietu nx. Złośliwy komponent doprowadził do kradzieży poświadczeń dewelopera, a następnie umożliwił atakującym eskalację dostępu przez GitHub i CI/CD aż do roli administratora w chmurze.

W skrócie

Atak rozpoczął się od zainfekowanego pakietu nx w rejestrze npm, który uruchamiał złośliwy kod na stacji roboczej dewelopera. Napastnicy przechwycili token GitHub, przeprowadzili rekonesans w repozytoriach i pipeline’ach, a następnie pozyskali sekrety wykorzystywane w procesach automatyzacji.

Kolejnym etapem było nadużycie federacji GitHub-AWS opartej o OIDC. Dzięki zbyt szerokim uprawnieniom roli powiązanej z CloudFormation atakujący utworzyli nową rolę IAM z polityką AdministratorAccess, uzyskując pełną kontrolę nad środowiskiem AWS w czasie krótszym niż 72 godziny.

wejście przez kompromitację pakietu npm,
kradzież tokena GitHub i sekretów CI/CD,
wykorzystanie OIDC do uzyskania tymczasowych poświadczeń AWS,
eskalacja do pełnych uprawnień administratora,
eksfiltracja danych i działania destrukcyjne w środowisku produkcyjnym.

Kontekst / historia

Tłem incydentu była kompromitacja pakietu nx npm z sierpnia 2025 roku. Ustalenia wskazują, że napastnicy mieli wykorzystać podatny workflow typu pull_request_target, co pozwoliło im uzyskać podwyższone uprawnienia w procesie CI/CD i doprowadzić do publikacji złośliwych wersji pakietu.

Zainfekowane wydania zawierały skrypt postinstall, który po instalacji rozpoczynał zbieranie danych środowiskowych oraz poświadczeń. To istotny przykład tego, jak naruszenie lokalnego narzędzia developerskiego może bardzo szybko przełożyć się na kompromitację systemów budowania, repozytoriów oraz zasobów chmurowych.

Incydent łączy w sobie trzy krytyczne obszary ryzyka: bezpieczeństwo łańcucha dostaw oprogramowania, ochronę tożsamości oraz błędną konfigurację uprawnień w środowisku cloud-native. W praktyce oznacza to, że nawet pozornie ograniczony incydent na endpointcie dewelopera może stać się początkiem pełnoskalowego naruszenia organizacji.

Analiza techniczna

Złośliwy pakiet miał osadzać skrypt postinstall uruchamiający narzędzie do kradzieży poświadczeń określane jako QUIETVAULT. Mechanizm ten zbierał zmienne środowiskowe, informacje o systemie oraz cenne tokeny, w tym GitHub Personal Access Tokens. Dodatkowo wykorzystywał lokalnie dostępne narzędzia oparte na modelach językowych do przeszukiwania systemu pod kątem wrażliwych danych.

W analizowanym przypadku wykonanie złośliwego komponentu miało nastąpić w trakcie korzystania z edytora kodu używającego wtyczki Nx Console. Aktualizacja lub aktywacja komponentu doprowadziła do przejęcia tokena dewelopera, co otworzyło drogę do dalszych działań w środowisku GitHub.

Po uzyskaniu tokena PAT grupa UNC6426 przeprowadziła działania rozpoznawcze i wykorzystała narzędzie open source Nord Stream do wydobycia sekretów z pipeline’ów CI/CD. W ten sposób pozyskano poświadczenia konta serwisowego GitHub, a następnie użyto mechanizmu pobierania tymczasowych tokenów AWS STS dla roli powiązanej z GitHub Actions i CloudFormation.

Kluczową słabością okazały się nadmierne uprawnienia roli federowanej z GitHub. Po przejęciu dostępu do roli Actions-CloudFormation atakujący wdrożyli nowy stos CloudFormation z możliwością tworzenia zasobów IAM. Następnie utworzyli nową rolę i przypisali do niej politykę AdministratorAccess, uzyskując pełne uprawnienia administracyjne w AWS.

Po eskalacji rozpoczęła się faza post-exploitation. Obejmowała ona odczyt i eksfiltrację danych z koszyków S3, działania wymierzone w instancje EC2 i bazy RDS, odszyfrowywanie kluczy aplikacyjnych oraz ingerencję w repozytoria GitHub, które zostały przemianowane i ustawione jako publiczne.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją tego typu ataku jest błyskawiczne przejście od kompromitacji pojedynczego urządzenia deweloperskiego do pełnego naruszenia środowiska chmurowego. Skutki mogą obejmować utratę poufności danych, zniszczenie zasobów produkcyjnych, przejęcie repozytoriów oraz ujawnienie sekretów aplikacyjnych.

Incydent pokazuje również, że skrypty postinstall w pakietach npm nadal stanowią realny problem bezpieczeństwa. W połączeniu z szerokimi tokenami PAT, źle zabezpieczonymi sekretami CI/CD i nadmiarowymi uprawnieniami IAM tworzą one bardzo skuteczną ścieżkę eskalacji.

Rosnące znaczenie ma także ryzyko związane z narzędziami AI używanymi lokalnie przez programistów. Jeżeli takie komponenty mają dostęp do plików, tokenów i aktywnych sesji, ich kompromitacja może zwiększyć zasięg ataku i utrudnić wykrycie nieautoryzowanych działań.

Rekomendacje

Organizacje powinny ograniczać wykonywanie skryptów postinstall wszędzie tam, gdzie jest to możliwe. Jeśli całkowite wyłączenie nie wchodzi w grę, warto wdrożyć sandboxing procesów instalacyjnych, kontrolę integralności zależności oraz monitorowanie anomalii podczas instalacji pakietów.

Niezbędne jest również ścisłe stosowanie zasady najmniejszych uprawnień wobec kont serwisowych, ról federowanych przez OIDC i zasobów CloudFormation. Role używane przez GitHub Actions nie powinny mieć możliwości tworzenia nowych ról IAM ani dołączania polityk administracyjnych bez dodatkowych zabezpieczeń i wyraźnego uzasadnienia biznesowego.

W obszarze zarządzania tożsamością należy stosować krótkotrwałe i precyzyjnie ograniczone tokeny GitHub PAT, regularnie rotować sekrety oraz monitorować ich wykorzystanie. Szczególną uwagę powinny zwracać nietypowe użycia STS, tworzenie nowych ról IAM, dołączanie polityki AdministratorAccess oraz nagłe operacje na S3, EC2 i RDS.

blokowanie lub ograniczanie skryptów postinstall,
ochrona workflow GitHub Actions przed nadużyciem pull_request_target,
segmentacja uprawnień między środowiskiem developerskim i produkcyjnym,
monitorowanie IAM, STS, CloudFormation, S3, EC2 i RDS,
wdrożenie procedur szybkiego unieważniania tokenów i izolacji stacji deweloperskich,
analiza działań narzędzi AI operujących na endpointach programistów.

Podsumowanie

Przypadek UNC6426 stanowi modelowy przykład wieloetapowego ataku łączącego kompromitację łańcucha dostaw npm, kradzież tożsamości deweloperskiej, nadużycie sekretów CI/CD oraz eskalację uprawnień w AWS. Najważniejszy wniosek jest jednoznaczny: pozornie lokalny incydent związany z pakietem developerskim może w bardzo krótkim czasie doprowadzić do przejęcia całej infrastruktury chmurowej.

Dla zespołów bezpieczeństwa oznacza to konieczność jednoczesnej ochrony zależności software’owych, tokenów dostępowych, pipeline’ów automatyzacji i federacji między GitHub a AWS. Bez ograniczania uprawnień oraz ciągłego monitorowania ścieżek zaufania podobne incydenty będą coraz trudniejsze do powstrzymania.

Źródła

The Hacker News — UNC6426 Exploits nx npm Supply-Chain Attack to Gain AWS Admin Access in 72 Hours — https://thehackernews.com/2026/03/unc6426-exploits-nx-npm-supply-chain.html
Google Cloud — Cloud Threat Horizons Report, H1 2026 — https://cloud.google.com/
Praetorian — pull_request_target workflow security research — https://www.praetorian.com/
Endor Labs — Pwn Request / GitHub Actions workflow abuse analysis — https://www.endorlabs.com/
Socket — Analysis of AI-assisted software supply chain abuse — https://socket.dev/

Globalny incydent w Stryker: zakłócenie środowiska Microsoft i podejrzenie ataku typu wiper

Wprowadzenie do problemu / definicja

Atak typu wiper to destrukcyjna operacja cybernetyczna, której celem nie jest klasyczne zaszyfrowanie danych dla okupu, lecz ich trwałe usunięcie, uszkodzenie lub doprowadzenie do utraty integralności systemów. Tego rodzaju incydenty są szczególnie niebezpieczne dla organizacji działających globalnie, opartych na scentralizowanym zarządzaniu tożsamością, urządzeniami i usługami chmurowymi.

W przypadku firmy Stryker mowa o szeroko zakrojonym zakłóceniu środowiska Microsoft, które przełożyło się na problemy z dostępem do systemów i aplikacji biznesowych. Równolegle pojawiły się doniesienia o możliwym destrukcyjnym charakterze zdarzenia oraz o roszczeniach napastników dotyczących eksfiltracji danych.

W skrócie

Stryker potwierdził 11 marca 2026 roku cyberatak, który spowodował globalne zakłócenie środowiska Microsoft. Firma przekazała, że incydent został opanowany, ale nadal wpływa on na dostępność części systemów i aplikacji biznesowych.

Jednocześnie grupa Handala przypisała sobie odpowiedzialność za atak i twierdziła, że przeprowadziła działania destrukcyjne oraz wyprowadziła dane. Publiczny obraz incydentu pozostaje niejednoznaczny, ponieważ oficjalna komunikacja spółki nie wskazuje na wykrycie ransomware ani klasycznego malware, podczas gdy doniesienia z rynku sugerują możliwość nadużycia centralnych mechanizmów administracyjnych.

Kontekst / historia

Stryker należy do grona największych globalnych dostawców technologii medycznych. Skala działalności tej organizacji oznacza, że nawet częściowa utrata dostępności usług IT może natychmiast wpłynąć na procesy operacyjne, obsługę klientów, logistykę i współpracę z partnerami.

Znaczenie ma także tło geopolityczne. W ostatnich latach wielokrotnie obserwowano kampanie przypisywane podmiotom określanym jako proirańskie lub powiązane z irańskim ekosystemem operacji cybernetycznych. W analizach branżowych Handala bywa opisywana jako persona łącząca eksfiltrację danych, presję psychologiczną, działania informacyjne i komponent destrukcyjny.

W takich przypadkach celem nie jest wyłącznie kradzież informacji. Napastnicy dążą również do maksymalizacji chaosu operacyjnego, osłabienia zaufania do ofiary oraz zwiększenia presji reputacyjnej. To sprawia, że nawet przy ograniczonej liczbie technicznych szczegółów incydent w Stryker należy traktować jako poważny sygnał ostrzegawczy dla całego sektora medtech.

Analiza techniczna

Najbardziej interesującym elementem tego zdarzenia są informacje o globalnym zakłóceniu środowiska Microsoft oraz doniesienia o zdalnym wymazywaniu urządzeń zarządzanych centralnie. Jeśli taki scenariusz rzeczywiście miał miejsce, mogło dojść do wykorzystania legalnych funkcji administracyjnych organizacji przeciwko niej samej, co wpisuje się w model living off the land.

Taki wariant ataku jest szczególnie groźny, ponieważ nie wymaga rozmieszczenia klasycznego malware na każdym systemie końcowym. Wystarczy przejęcie uprzywilejowanych kont, tokenów dostępowych lub kontroli nad usługami odpowiedzialnymi za zarządzanie tożsamością i urządzeniami.

Możliwe hipotezy techniczne obejmują:

przejęcie kont administracyjnych w środowisku chmurowym i wykonanie destrukcyjnych operacji z poziomu natywnych konsol zarządzających,
kompromitację usług katalogowych, polityk urządzeń i mechanizmów kontroli dostępu,
nadużycie funkcji resetu, wipe, reprovisioningu lub wycofywania urządzeń z zarządzania,
wykorzystanie zaufanych kanałów administracyjnych do działań, które z perspektywy użytkownika końcowego wyglądają jak klasyczny wiper.

Takie podejście ma kilka istotnych zalet z punktu widzenia napastnika. Może ograniczać widoczność ataku w narzędziach opartych na sygnaturach, pozwala korzystać z legalnych interfejsów API i utrudnia szybkie odróżnienie złośliwej aktywności od działań administracyjnych.

Dodatkowo nie można wykluczyć komponentu eksfiltracyjnego. Coraz częściej grupy prowadzące operacje destrukcyjne najpierw kradną dane, a dopiero później przechodzą do zakłócenia działania środowiska. Dzięki temu mogą połączyć skutki operacyjne z presją reputacyjną i potencjalnym szantażem informacyjnym.

Konsekwencje / ryzyko

Dla organizacji z sektora medycznego i technologii medycznych skutki podobnego incydentu mogą być znacznie szersze niż typowe straty po awarii IT. Ryzyko obejmuje zarówno utratę ciągłości operacyjnej, jak i długofalowe konsekwencje biznesowe oraz regulacyjne.

zakłócenie procesów biznesowych i logistycznych,
ograniczony dostęp do aplikacji operacyjnych, komunikacyjnych i administracyjnych,
opóźnienia w realizacji zamówień oraz wsparciu serwisowym,
potencjalną utratę danych korporacyjnych i informacji wrażliwych,
szkody reputacyjne wobec klientów, partnerów i inwestorów,
ryzyko konsekwencji prawnych oraz regulacyjnych.

Szczególnie niebezpieczna jest silna zależność od jednego ekosystemu tożsamości i produktywności. Jeśli incydent obejmuje centralne usługi katalogowe, pocztę, kontrolę dostępu i MDM, organizacja może jednocześnie utracić zdolność do komunikacji, koordynacji reakcji oraz bezpiecznego odtwarzania środowiska użytkowników końcowych.

Ten przypadek pokazuje również, że brak potwierdzonego malware nie musi oznaczać niższej skali zagrożenia. Przeciwnie, może sugerować bardziej zaawansowane nadużycie legalnych narzędzi administracyjnych, przejętych sesji uprzywilejowanych albo uprawnień aplikacyjnych w chmurze.

Rekomendacje

Incydent w Stryker powinien skłonić organizacje do przeglądu bezpieczeństwa tożsamości, zarządzania urządzeniami oraz odporności operacyjnej. Kluczowe działania obronne obejmują:

wzmocnienie kontroli uprzywilejowanego dostępu, w tym ograniczenie liczby kont administracyjnych oraz wdrożenie MFA odpornego na phishing,
zastosowanie modelu just-in-time i just-enough-admin dla operacji o podwyższonym ryzyku,
audyt ról, delegacji oraz polityk wipe, reset i reprovisioning w platformach MDM i usługach tożsamości,
alertowanie na masowe operacje wykonywane wobec urządzeń, użytkowników i aplikacji,
utrzymywanie offline’owych i niemutowalnych kopii zapasowych oraz regularne testy odtwarzania,
przygotowanie alternatywnych kanałów komunikacji kryzysowej poza głównym środowiskiem korporacyjnym,
korelację logów z usług tożsamości, MDM, EDR, poczty i systemów dostępowych,
monitorowanie nietypowych działań administracyjnych wykonywanych poza standardowymi oknami operacyjnymi,
wdrożenie mechanizmów DLP i kontroli ruchu wychodzącego w celu ograniczenia skutków eksfiltracji danych,
prowadzenie ćwiczeń tabletop i purple teaming dla scenariuszy przejęcia środowiska Microsoft 365 lub platform MDM.

W praktyce kluczowe jest odejście od myślenia, że bezpieczeństwo endpointów samo w sobie wystarczy. Dzisiejsze operacje destrukcyjne coraz częściej uderzają w warstwę tożsamości, automatyzację administracyjną i zaufane usługi chmurowe.

Podsumowanie

Incydent w Stryker pokazuje, że współczesne ataki destrukcyjne nie muszą opierać się wyłącznie na klasycznym malware. Równie skuteczne może być przejęcie centralnych mechanizmów zarządzania i wykorzystanie legalnych funkcji administracyjnych do sparaliżowania działalności organizacji.

Dla firm działających globalnie najważniejsza lekcja jest jasna: ochrona kont uprzywilejowanych, platform MDM i usług tożsamości musi być traktowana jako element krytyczny. W środowisku, w którym ataki coraz częściej łączą eksfiltrację danych, zakłócenie operacyjne i presję informacyjną, odporność organizacji musi obejmować znacznie więcej niż obronę przed ransomware.

Źródła

BleepingComputer — https://www.bleepingcomputer.com/news/security/medtech-giant-stryker-offline-after-iran-linked-wiper-malware-attack/
Stryker — A Message To Our Customers — https://www.stryker.com/us/en/about/news/2026/a-message-to-our-customers-03-2026.html
Unit 42 — Threat Brief: March 2026 Escalation of Cyber Risk Related to Iran — https://unit42.paloaltonetworks.com/iranian-cyberattacks-2026/

Krytyczna luka w HPE Aruba AOS-CX pozwala na reset hasła administratora

Wprowadzenie do problemu / definicja

Hewlett Packard Enterprise usunęło wiele podatności bezpieczeństwa w systemie Aruba Networking AOS-CX, wykorzystywanym w przełącznikach serii CX dla środowisk kampusowych i centrów danych. Najpoważniejsza z nich, oznaczona jako CVE-2026-23813, dotyczy webowego interfejsu zarządzania i może umożliwić nieuwierzytelnionemu atakującemu obejście mechanizmów kontroli dostępu oraz zdalny reset hasła konta administracyjnego.

To szczególnie groźny scenariusz, ponieważ płaszczyzna zarządzania urządzeniami sieciowymi stanowi jeden z najbardziej wrażliwych elementów infrastruktury enterprise. Przejęcie dostępu administracyjnego do przełącznika może otworzyć drogę do dalszej kompromitacji sieci, zmian konfiguracji i zakłócenia pracy usług.

W skrócie

Najważniejsza luka została oznaczona jako CVE-2026-23813.
Podatność dotyczy webowego interfejsu zarządzania HPE Aruba AOS-CX.
Atak może umożliwić obejście uwierzytelnienia i reset hasła administratora.
Producent udostępnił poprawki oraz zalecenia ograniczające ekspozycję.
W chwili publikacji nie wskazano publicznego exploitu ani potwierdzonego aktywnego wykorzystania.

Kontekst / historia

AOS-CX to system operacyjny odpowiedzialny za funkcje administracyjne, konfigurację, telemetrię i integrację operacyjną przełączników Aruba CX. Z perspektywy bezpieczeństwa oznacza to, że każda luka w interfejsie zarządzającym może mieć bezpośredni wpływ na integralność i dostępność całego środowiska sieciowego.

Informacja o CVE-2026-23813 wpisuje się w szerszy trend rosnącej liczby zagrożeń wymierzonych w urządzenia infrastrukturalne i ich płaszczyzny zarządzania. Dla zespołów bezpieczeństwa to kolejny sygnał, że przełączniki, routery i kontrolery powinny być objęte takim samym poziomem nadzoru jak serwery, stacje robocze i aplikacje.

Analiza techniczna

Z opisu producenta wynika, że problem dotyczy klasy authentication bypass w webowym interfejsie administracyjnym AOS-CX. Tego rodzaju błąd oznacza możliwość ominięcia standardowego procesu autoryzacji bez użycia prawidłowych poświadczeń. W praktyce przyczyną mogą być błędy w logice sesji, walidacji żądań, egzekwowaniu kontroli dostępu lub obsłudze mechanizmów resetu danych administracyjnych.

Najbardziej niebezpieczny aspekt tej luki polega na możliwości zresetowania hasła administratora. W efekcie atakujący może uzyskać kontrolę nad urządzeniem na poziomie zarządczym i wykonywać działania o wysokim wpływie operacyjnym.

modyfikować konfigurację urządzenia,
zmieniać polityki dostępu i segmentacji,
manipulować trasami i interfejsami,
osłabiać mechanizmy bezpieczeństwa,
przygotowywać środowisko do dalszego ruchu bocznego.

Producent wskazał, że atak nie wymaga uprzywilejowanego konta i może cechować się niską złożonością. Nawet jeśli w momencie publikacji nie było informacji o publicznym kodzie exploit ani aktywnej eksploatacji, samo opublikowanie biuletynu i aktualizacji zwiększa ryzyko szybkiego opracowania skutecznych metod ataku na podstawie analizy różnic między wersjami oprogramowania.

Konsekwencje / ryzyko

Ryzyko biznesowe i operacyjne związane z CVE-2026-23813 jest wysokie, ponieważ podatność dotyczy krytycznego elementu infrastruktury. Przejęcie konta administratora na przełączniku może przełożyć się na szeroki zakres negatywnych skutków dla organizacji.

utrata integralności konfiguracji sieci,
nieautoryzowane zmiany polityk i tras ruchu,
zakłócenie dostępności usług,
osłabienie widoczności i zdolności detekcyjnych,
umożliwienie dalszych ataków wewnętrznych,
potencjalne przekierowywanie lub przechwytywanie ruchu.

Największe zagrożenie występuje tam, gdzie interfejsy administracyjne są dostępne z rozległych segmentów sieci, stref użytkowników, niedostatecznie chronionych sieci zarządzających lub nawet z zewnątrz. W takich warunkach podatność może stać się punktem wejścia do kompromitacji newralgicznej warstwy infrastrukturalnej.

Rekomendacje

Organizacje korzystające z HPE Aruba AOS-CX powinny potraktować tę lukę priorytetowo i wdrożyć działania ograniczające ryzyko bez zbędnej zwłoki.

Zidentyfikować wszystkie urządzenia działające na podatnych wersjach AOS-CX.
Niezwłocznie zastosować oficjalne poprawki producenta.
Ograniczyć dostęp do interfejsów zarządzania wyłącznie do wydzielonej sieci administracyjnej.
Wyłączyć HTTP i HTTPS tam, gdzie zarządzanie webowe nie jest niezbędne.
Wdrożyć ścisłe filtrowanie ruchu do interfejsów REST i HTTPS z użyciem ACL oraz segmentacji.
Zwiększyć poziom logowania i monitorowania operacji administracyjnych.
Analizować logi pod kątem prób nieautoryzowanego dostępu, zmian haseł i modyfikacji konfiguracji.
Zweryfikować gotowość do rotacji poświadczeń administracyjnych i odtworzenia zaufanej konfiguracji.
Przeprowadzić szerszy przegląd ekspozycji interfejsów zarządzania w całej infrastrukturze.

Z perspektywy defensywnej warto również rozważyć korzystanie z bastionów administracyjnych, pełne rejestrowanie działań uprzywilejowanych oraz dodatkową kontrolę zmian konfiguracyjnych w ramach procesów operacyjnych.

Podsumowanie

Podatność CVE-2026-23813 w HPE Aruba AOS-CX pokazuje, jak poważne konsekwencje mogą mieć błędy w interfejsach zarządzania urządzeń sieciowych. Możliwość obejścia uwierzytelnienia i resetu hasła administratora stwarza realne ryzyko przejęcia kontroli nad kluczowymi elementami infrastruktury.

Nawet przy braku publicznie dostępnego exploitu organizacje nie powinny odkładać działań naprawczych. Priorytetem pozostaje szybkie wdrożenie poprawek, ograniczenie dostępu do płaszczyzny zarządzania oraz wzmożone monitorowanie aktywności administracyjnej.

Źródła

BleepingComputer – HPE warns of critical AOS-CX flaw allowing admin password resets — https://www.bleepingcomputer.com/news/security/hpe-warns-of-critical-aos-cx-flaw-allowing-admin-password-resets/
HPE Support Center – Security bulletin for Aruba Networking AOS-CX vulnerabilities — https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04823en_us&docLocale=en_US

Termite ransomware i „Velvet Tempest”: jak ClickFix + CastleRAT łączą się z włamaniami i przygotowaniem pod ransomware

Wprowadzenie do problemu / definicja luki

ClickFix to technika socjotechniczna, która udaje „naprawę” problemu (np. CAPTCHA, błąd przeglądarki, weryfikacja człowieka) i instruuje użytkownika, by wkleił polecenie do Windows Run (Win+R) lub uruchomił je w PowerShell/cmd. To nie jest luka w oprogramowaniu, tylko skuteczny wektor initial access oparty o zachowanie użytkownika i „życie z ziemi” (LOLBAS). W 2026 r. ClickFix jest coraz częściej łączony z łańcuchami loader → RAT/stealer → ruch boczny → ransomware, bo daje atakującym szybkie wejście i dobre maskowanie.

W skrócie

Z obserwacji opisanej 7 marca 2026 r. wynika, że operatorzy śledzeni jako Velvet Tempest (DEV-0504) użyli kampanii malvertising prowadzącej do miksu ClickFix + CAPTCHA, aby skłonić ofiary do wklejenia zaciemnionego polecenia w oknie „Uruchom”. Następnie uruchomiony został kaskadowy łańcuch cmd.exe i narzędzi systemowych (w tym finger.exe) do pobrania pierwszych loaderów; jeden z elementów był archiwum podszywającym się pod PDF. W kolejnych etapach widoczna była automatyzacja przez PowerShell, kompilacja komponentów .NET przez csc.exe w katalogach tymczasowych oraz elementy oparte o Pythona dla utrzymania się w systemie (np. w C:\ProgramData). Finalnie miało to doprowadzić do uruchomienia loadera i pobrania CastleRAT.

Kluczowy niuans: w obserwowanym incydencie nie doszło do uruchomienia samego ransomware Termite, ale część infrastruktury/hostingu narzędzi była powiązana z wcześniejszymi intruzjami przypisywanymi do „Termite” (co sugeruje współdzielenie zasobów lub playbooków w ekosystemie afiliantów).

Kontekst / historia / powiązania

BleepingComputer wskazuje, że Velvet Tempest (DEV-0504) to doświadczony aktor, kojarzony z działalnością afilianta w wielu „epokach” ransomware. W praktyce takie grupy często zmieniają brand, przechodzą między programami RaaS i reużywają TTP, a równolegle korzystają z usług wyspecjalizowanych operatorów (np. MaaS/loader).

Istotne jest też tło „Castle*”: analizy branżowe opisują CastleLoader/CastleRAT jako elementy modularnego systemu dystrybucji malware, wykorzystywanego w kampaniach wieloetapowych (loader pobiera kolejne komponenty, a RAT daje trwałą kontrolę i rozpoznanie środowiska).

Analiza techniczna / szczegóły łańcucha

Poniżej typowy obraz techniczny tej klasy ataków (zbieżny z opisem incydentu i szerszymi analizami ClickFix/Castle):

Etap 0 — dystrybucja (malvertising / kompromitowane strony):

reklamy lub przejęte witryny kierują na stronę „weryfikacji”, która prezentuje instrukcję wklejenia komendy do Win+R.

Etap 1 — ClickFix (uruchomienie polecenia przez użytkownika):

ofiara uruchamia zaciemnioną komendę; w obserwacji pojawiają się zagnieżdżone łańcuchy cmd.exe oraz użycie finger.exe do pobrania pierwszych loaderów (LOLBAS, „życie z ziemi”).

Etap 2 — staging i wykonywanie kolejnych komponentów:

PowerShell pobiera dalsze payloady i uruchamia komendy,
widoczna jest kompilacja .NET przez csc.exe w katalogach tymczasowych,
pojawiają się komponenty Pythona wspierające persistence (np. w C:\ProgramData).

Etap 3 — loader → RAT:

BleepingComputer opisuje, że łańcuch finalnie „staged” loader i pobrał CastleRAT, kojarzony z rodziną CastleLoader dystrybuującą różne RAT-y i stealery.
Niezależne analizy CastleLoader pokazują, że ten typ loadera bywa budowany tak, by dekodować i uruchamiać payload w pamięci, ograniczając artefakty na dysku, oraz pobierać kolejne etapy z infrastruktury atakujących.

Dlaczego to jest groźne dla ransomware?
Bo po stabilnym osadzeniu RAT-a atakujący mają czas na rozpoznanie AD, kradzież poświadczeń, enumerację hostów i przygotowanie warunków do masowego wdrożenia szyfratora (czasem dopiero po dniach/tygodniach).

Praktyczne konsekwencje / ryzyko

W opisywanej obserwacji po uzyskaniu dostępu widoczne były działania „hands-on keyboard”, w tym rozpoznanie Active Directory, discovery hostów oraz profilowanie środowiska, a także próby pozyskiwania poświadczeń (np. z przeglądarki). To klasyczny schemat pre-ransomware: najpierw kontrola i mapowanie, potem eskalacja i dopiero na końcu decyzja o szyfrowaniu/eksfiltracji.

Dla biznesu przekłada się to na:

ryzyko przejęcia kont uprzywilejowanych i kompromitacji domeny,
kradzież danych i długotrwałą obecność (persistence),
możliwość uruchomienia ransomware w późniejszym terminie (również przez innego operatora, jeśli dostęp zostanie „sprzedany” lub współdzielony).

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz” (priorytety SOC/IR):

Zablokuj ClickFix jako zachowanie, nie jako pojedynczy IOC

reguły EDR/SIEM na nietypowe uruchomienia: Win+R → cmd/powershell z długimi, zaciemnionymi parametrami,
monitoring „łańcuchów” procesów: explorer.exe → rundll32/cmd/powershell/mshta/regsvr32 (zależnie od wariantu kampanii).

Hunting na LOLBAS i staging

korelacje na finger.exe w kontekście pobierania danych (rzadkie w normalnych środowiskach),
wykrywanie kompilacji przez csc.exe w %TEMP%/katalogach użytkownika,
alerty na podejrzane artefakty i trwałość w C:\ProgramData (zadania, usługi, autorun).

Zabezpieczenia tożsamości

natychmiastowa rotacja haseł dla kont podejrzanych + wymuszenie MFA (szczególnie kont admin/serwisowych),
przegląd logowań i tokenów sesyjnych (nietypowe lokalizacje/urządzenia),
ograniczenie uprawnień lokalnych adminów i segmentacja dostępu do AD.

Containment na endpointach

izolacja hostów z anomaliami w drzewie procesów (ClickFix/loader/RAT),
pełna triage pamięci i artefaktów (bo część etapów może być in-memory).

Prewencja użytkownika

krótkie szkolenie „just-in-time”: „CAPTCHA nigdy nie wymaga Win+R i wklejania komend”,
blokady politykami (AppLocker/WDAC) na nieautoryzowane interpretery i nietypowe ścieżki uruchomień.

Różnice / porównania z innymi przypadkami

To, co wyróżnia ClickFix, to przeniesienie „momentu kompromitacji” na użytkownika: nie trzeba eksploitu, bo ofiara sama uruchamia payload. Unit 42 opisuje ClickFix jako rosnący trend i pokazuje, że kampanie potrafią dynamicznie zmieniać implementację (różne rodziny malware, różne łańcuchy), a mimo to rdzeń jest stały: obfuscated PowerShell/command + kolejne etapy.

Z kolei analizy łańcuchów ClickFix w innych kampaniach (np. kończących się stealerami) pokazują podobną logikę: shellcode/loader → wstrzyknięcie do legalnych procesów → eksfiltracja. To ważne, bo organizacje często bagatelizują „tylko stealer”, a w praktyce stealer bywa etapem budowy dostępu pod większą operację.

Podsumowanie / kluczowe wnioski

ClickFix to skuteczny, „tani” wektor initial access, który omija potrzebę exploitów i utrudnia obronę, bo opiera się na zachowaniu użytkownika.
W opisywanym przypadku widoczny jest klasyczny playbook: malvertising → ClickFix → LOLBAS/PowerShell/.NET → CastleRAT, a następnie działania ręczne w sieci (AD discovery itp.).
Nawet jeśli w danej obserwacji ransomware nie zostanie uruchomione, taki dostęp należy traktować jako incydent o wysokim priorytecie, bo to typowy etap „przygotowania pola” pod szyfrowanie i/lub eksfiltrację.
Obrona wymaga podejścia behawioralnego: wykrywania łańcuchów procesów, nietypowych LOLBAS (np. finger.exe), kompilacji csc.exe, persistence w ProgramData oraz twardej higieny tożsamości.

Źródła / bibliografia

BleepingComputer — „Termite ransomware breaches linked to ClickFix CastleRAT attacks” (7 marca 2026) (BleepingComputer)
Darktrace — „CastleLoader & CastleRAT: Behind TAG150’s Modular Malware Delivery System” (26 listopada 2025) (Darktrace)
Palo Alto Networks Unit 42 — „Fix the Click: Preventing the ClickFix Attack Vector” (aktualizacja 10 lipca 2025) (Unit 42)
LevelBlue / SpiderLabs — „How ClickFix Opens the Door to Stealthy StealC Information Stealer” (12 lutego 2026) (levelblue.com)
Blackpoint Cyber — „Snakes in the Castle: Inside a Python-Driven CastleLoader Delivery” (9 grudnia 2025) (Blackpoint)