Archiwa: Security News - Strona 449 z 475 - Security Bez Tabu

Kategoria: Security News

Balancer odzyskuje środki po włamaniu na 128 mln USD: co wiemy o błędzie zaokrągleń i jak się chronić

Wprowadzenie do problemu / definicja luki

3 listopada 2025 r. protokół DeFi Balancer padł ofiarą skoordynowanego ataku na pulach Composable Stable w wersji V2. Atakujący wykorzystali błąd zaokrągleń w funkcji przeskalowania (tzw. upscale) dla transakcji EXACT_OUT oraz mechanikę batch swap (z rozliczeniami odroczonymi), by zmanipulować wyceny i wypłacić środki o łącznej wartości szacowanej początkowo na ok. 128 mln USD. Zespół Balancera uruchomił tryb odzyskiwania i podał, że część środków zaczęto już odzyskiwać we współpracy z partnerami i „białymi kapeluszami”.

W skrócie

  • Wejście wektor ataku: niespójności zaokrągleń w matematyce puli (upscale vs. downscale) połączone z batch swapami i traktowaniem tokenów BPT jak zwykłych aktywów.
  • Skala szkód: wstępnie ~128 mln USD na wielu łańcuchach; szybka reakcja społeczności i partnerów zmniejszyła część strat; proces odzyskiwania trwa.
  • Zakres wpływu: pule Composable Stable v5 poza oknem pauzy; inne typy pul (w tym V3) nie zostały dotknięte.
  • Root cause (wg Balancera): kierunek zaokrągleń w funkcji upscale dla EXACT_OUT naruszał oczekiwane własności invariantów puli.

Kontekst / historia / powiązania

Balancer to jeden z najdłużej działających protokołów AMM w ekosystemie DeFi. Usterki w warstwie „dokładności arytmetycznej” smart-kontraktów wielokrotnie bywały zapalnikiem strat (np. incydenty z błędami precyzji, manipulacją invariantów czy sandwichingiem). Atak z 3 listopada był wielochainowy (Ethereum, Base, Avalanche, Gnosis, Berachain, Polygon, Arbitrum, Optimism) i dotknął również forki Balancera. Części pul nie można było zatrzymać, bo działają „od lat” i były poza oknem pauzy.

Analiza techniczna / szczegóły luki

Badania niezależnych zespołów (BlockSec, Check Point Research) wskazują na kombinację trzech czynników:

  1. Niespójne zaokrąglanie – upscaling używał jednostronnego zaokrąglania w dół, podczas gdy downscaling mógł stosować inne zasady. Różnica ta, skumulowana w złożonych ścieżkach swapów, dawała mierzalną przewagę atakującemu.
  2. Batch swap + EXACT_OUT – wykorzystanie deferred settlement i „pożyczek w locie” (flash-like) w ramach jednej transakcji pozwalało zaniżać efektywną cenę BPT oraz innych aktywów, po czym realizować zysk.
  3. BPT jako zwykły token – traktowanie tokenów udziałowych (BPT) jak regularnych tokenów umożliwiło obchodzenie minimalnej podaży puli i sprowadzanie płynności do bardzo niskich poziomów, co zwiększało czułość na błąd.

Check Point podkreśla, że atak trwał <30 minut, obejmując równoległe ścieżki na sześciu łańcuchach, a łączna wartość wyprowadzonych aktywów sięgnęła ~128,64 mln USD.

Praktyczne konsekwencje / ryzyko

  • Ryzyko systemowe dla forków i integracji: forki Balancera oraz projekty budowane na Composable Stable Pools dziedziczą te same wektory ryzyka aż do aktualizacji kontraktów.
  • Ryzyko dla LP i traderów: w okresie po incydencie zagrożone są pule pozostające poza oknem pauzy; dalsze interakcje (zwł. z EXACT_OUT/batch swap) mogą zwiększać straty użytkowników.
  • Ryzyko reputacyjne / zgodności: duże wahania TVL i wstrzymania na łańcuchach (np. reakcje na Berachain) mogą wpływać na płynność, wyceny i zaufanie do protokołów AMM.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (LP, traderzy):

  • Unikaj interakcji z dotkniętymi pulami Composable Stable v5 do czasu oficjalnych zaleceń i migracji; wypłać płynność, jeśli to możliwe.
  • Sprawdź i ogranicz allowances dla kontraktów Balancer V2 oraz forków; rozważ użycie narzędzi do szybkiej revokacji uprawnień.
  • Monitoruj ogłoszenia Balancera (X, repozytoria, blog) i adresy atakującego, jeśli śledzisz przepływy środków.

Dla zespołów/projektów (operatorzy pul, integratorzy, audytorzy):

  • Zunifikuj semantykę zaokrągleń w całym łańcuchu obliczeń invariantów; preferuj biblioteki arytmetyki stałoprzecinkowej z dowodami własności. Wprowadź testy różnicowe (differential testing) i property-based tests pod kątem błędów precyzji.
  • Dodaj circuit breakery i „okna pauzy” o zasięgu obejmującym wszystkie krytyczne pule; rozważ automatyczne rate limiters i kill-switche dla batch swapów.
  • Ogranicz możliwość traktowania BPT jak zwykłych tokenów w kontekstach zagrażających minimalnej podaży puli; enforce’uj twarde progi płynności.
  • Zaplanuj migracje kontraktów i odpowiednie ścieżki odzyskiwania środków / redystrybucji w oparciu o transparentne transakcje on-chain i współpracę z giełdami (tzw. cex freeze).

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

W odróżnieniu od typowych ataków na mosty (bridge) czy błędów uprawnień, tu rdzeń problemu leżał w mikro-niespójności matematycznej i jej akumulacji w złożonych ścieżkach swapów. To bardziej przypomina wcześniejsze incydenty z precyzją/invariantami w AMM-ach niż klasyczne oracle manipulation. Analizy BlockSec i Check Point podkreślają, że same „bezpieczne” biblioteki matematyczne nie wystarczą, jeśli kontrakt nie zapewnia spójności zaokrągleń w całej ścieżce obliczeń.

Podsumowanie / kluczowe wnioski

  • Atak na Balancera obnażył, jak pozornie „mały” błąd zaokrągleń może w praktyce przełożyć się na dziesiątki milionów USD strat w minutach.
  • Odzyskiwanie środków trwa, a wstępne działania ograniczyły część szkód; finalne wartości strat i szczegóły dystrybucji Balancer zapowie w pełnym raporcie.
  • Dla branży DeFi to case study: konsekwentna semantyka zaokrągleń, testy właściwości invariantów, mocniejsze „bezpieczniki” operacyjne i szybkie procedury IR są niezbędne w projektach wielochainowych.

Źródła / bibliografia

  1. SecurityWeek — „DeFi Protocol Balancer Starts Recovering Funds Stolen in $128 Million Heist”, 6 listopada 2025. (SecurityWeek)
  2. Balancer (oficjalne X) — „Preliminary Incident Report” (root cause: rounding w upscale dla EXACT_OUT). (X (formerly Twitter))
  3. BlockSec — „In-Depth Analysis: The Balancer V2 Exploit”, analiza techniczna niespójności zaokrągleń. (Blocksec Team)
  4. Check Point Research — „How an Attacker Drained $128M from Balancer”, metryki ataku i wielochainowy przebieg. (Check Point Research)
  5. The Block — „Balancer identifies rounding error as root cause of multi-chain DeFi exploit”, kontekst branżowy i uzupełniające szczegóły. (The Block)

Europejskie służby rozbijają globalny gang oszustów: miliony transakcji przez niemieckie firmy płatnicze

Wprowadzenie do problemu / definicja luki

Europejskie organy ścigania (koordynacja: Europol i Eurojust) przeprowadziły skoordynowaną akcję przeciwko trzem powiązanym sieciom przestępczym odpowiedzialnym za masowe oszustwa kartowe i pranie pieniędzy. Grupa miała wykorzystywać infrastrukturę czterech dużych niemieckich dostawców usług płatniczych (PSP) do rozliczania fałszywych subskrypcji na około 2 000 witrynach podszywających się pod serwisy VOD, randkowe i dla dorosłych. Straty szacowane są co najmniej na 300 mln euro, a dane 4,3 mln posiadaczy kart z 193 krajów miały zostać nadużyte. Zatrzymano 18 osób, a łącznie podejrzanych ma być 44. Akcję określono kryptonimem Operation Chargeback.

W skrócie

  • Skala: 19 mln obciążeń subskrypcyjnych, min. 300 mln € szkód; ofiary w 193 krajach.
  • Wektor nadużyć: przejęte/wykradzione dane kart + fałszywe serwisy subskrypcyjne; przetwarzanie przez skompromitowane PSP.
  • Infrastruktura finansowa: co najmniej 500 spółek-słupów (m.in. w UK i na Cyprze) do prania środków.
  • Zasięg operacji: przeszukania i działania m.in. w Niemczech, Włoszech, Kanadzie, Luksemburgu, Niderlandach, Singapurze, Hiszpanii, USA i na Cyprze.

Kontekst / historia / powiązania

Śledztwo prowadzone przez prokuratury i policję federalną Niemiec (BKA) przy wsparciu BaFin wpisuje się w szersze europejskie działania przeciw oszustwom płatniczym i praniu pieniędzy (EMPACT 2022–2025). Według komunikatów Eurojust i Europolu, rdzeń procederu działał w latach 2016–2021, po czym został zakłócony, a obecne zatrzymania to efekt kilkuletniej, wielowątkowej analizy danych i przepływów finansowych.

Analiza techniczna / szczegóły luki

Jak to działało:

  1. Pozyskanie danych kart: głównie z wycieków i phishingu; następnie automatyczne testy kart (card testing) i niskokwotowe obciążenia subskrypcyjne, by ominąć wykrywanie anomalii.
  2. Fałszywe serwisy: ok. 2 000 witryn oferujących „usługi” (streaming, randki, treści 18+) – realny content był drugorzędny lub nieistniał; kluczowy był ciągły billing.
  3. Wykorzystanie PSP: przestępcy – z pomocą obecnych lub byłych pracowników oraz pośredników – mieli uzyskiwać dostęp do kont handlowców (MIDs) i systemów rozliczeniowych 4 niemieckich PSP, co pozwalało na wypłaszczanie wskaźników chargeback i maskowanie fraudu w wolumenie legalnych transakcji.
  4. Pranie pieniędzy: sieć ~500 spółek i kont w wielu jurysdykcjach; środki dystrybuowano etapami, mieszając je z legalnymi wpływami, co utrudniało analizy KYC/AML.
  5. Skala nadużyć: 19 mln obciążeń na 19 mln kont kartowych; szkody potwierdzone ≥300 mln €, próby oszustw szacowane na >750 mln €.

Praktyczne konsekwencje / ryzyko

  • Dla PSP i acquirerów: ryzyko systemowe – kompromitacja procesów merchant onboarding, monitoringu transakcyjnego i zarządzania chargebackami. Potencjalne sankcje regulacyjne (BaFin) i koszty kompensat.
  • Dla banków-wydawców (issuerów): wyższe straty fraudowe, wzrost opłat scheme’owych za nadmierne chargebacki, presja na modele risk scoringu. (Wnioski na podstawie danych o skali i metodach operacyjnych.)
  • Dla użytkowników: nieautoryzowane subskrypcje, „szum” w historii transakcji o małych kwotach, utrata środków do czasu chargebacku.
  • Dla regulatorów: konieczność przeglądu nadzoru nad PSP oraz łańcuchem pośredników płatniczych i agregatorów.

Rekomendacje operacyjne / co zrobić teraz

Dla PSP/fintechów i acquirerów

  • Natychmiastowy audyt MIDs: re-KYC najwyższego ryzyka (branże „content”, subskrypcje, VOD, adult), w tym beneficial owners i powiązania krzyżowe między merchantami.
  • Kontrole techniczne:
    • Wymuś 3DS/SCA dla subskrypcji inicjowanych bez udziału karty (COF/mit) powyżej progów ryzyka.
    • Wykrywaj bursting małych transakcji i schematy „first charge small, then recurring”.
    • Modeluj nietypowe ścieżki refund/chargeback oraz wzorce „friendly fraud masking”.
  • Procesy compliance: wzmożone EDD dla resellerów i „psuedo-aggregatorów”; weryfikacja pracowników i partnerów z dostępem do systemów rozliczeniowych (insider risk).

Dla banków-issuerów

  • Zacieśnij profilowanie MCC + merchant descriptors; automatyczne alerty dla mikro-subskrypcji i transakcji transgranicznych z niskim AVS/CVV match.
  • Udoskonal customer education (wykrywanie „dark patterns” subskrypcji; wniosek o chargeback).

Dla użytkowników

  • Sprawdzaj historie płatności pod kątem drobnych, cyklicznych obciążeń z niejasnymi nazwami.
  • Włącz powiadomienia o transakcjach i rozważ wirtualne karty do subskrypcji.

(Każda z powyższych rekomendacji wynika z metod opisanych w materiałach Europolu/Eurojust i doniesieniach prasowych o Operation Chargeback.)

Różnice / porównania z innymi przypadkami

W ostatnich miesiącach europejskie organy ścigania uderzały także w duże sieci crypto-scamów, gdzie kluczowa była tokenizacja i pranie na łańcuchu (np. świeże działania koordynowane przez Eurojust, oddzielne od sprawy Chargeback). W Operation Chargeback rdzeniem był jednak klasyczny kanał kartowy i komercyjne PSP, a nie inwestycyjne oszustwa krypto. To inny wektor ataku, ale wspólna pozostaje profesjonalizacja prania przez siatkę spółek-słupów i multi-jurysdykcyjność.

Podsumowanie / kluczowe wnioski

  • Atak na łańcuch płatniczy może być równie skuteczny jak malware: przejęcie procesów PSP i merchantów pozwala „legalizować” masowe mikropłatności.
  • Insiderzy i pośrednicy to krytyczny wektor – kontrole dostępu i due diligence partnerów są tak samo ważne jak modele AML.
  • Subskrypcje o niskiej wartości wymagają dedykowanych reguł ryzyka; standardowe progi wykrywania często je przepuszczają.
  • Współpraca międzynarodowa (Europol/Eurojust) i presja regulacyjna są skuteczne, ale ryzyko re-konfiguracji siatek pozostaje wysokie.

Źródła / bibliografia

  • Europol: „Operation Chargeback: 4.3 million cardholders affected, EUR 300 million in damages”. (04.11.2025). (Europol)
  • Eurojust: „Eurojust coordinates major operation against EUR 300 million global credit card fraud”. (05.11.2025). (Eurojust)
  • Reuters: „Germany arrests 18 in international crackdown on suspected online fraud”. (05.11.2025). (Reuters)
  • Financial Times: „Eighteen arrested in connection with alleged global online fraud network”. (05.11.2025). (Financial Times)
  • The Record: „Europe police bust global fraud ring that used German payment firms to launder millions”. (05.11.2025). (The Record from Recorded Future)

Nikkei: wyciek danych po przejęciu kont Slack. 17 000+ osób potencjalnie dotkniętych

Wprowadzenie do problemu / definicja incydentu

Japoński koncern medialny Nikkei poinformował, że napastnicy uzyskali nieautoryzowany dostęp do firmowego Slacka i wykradli dane dotyczące ponad 17 000 osób (pracowników i partnerów). Do włamania doszło po zainfekowaniu prywatnego komputera pracownika złośliwym oprogramowaniem, które wykra­dło poświadczenia do Slacka. Firma podkreśla, że nie potwierdzono wycieku danych źródeł i materiałów dziennikarskich. Incydent wykryto we wrześniu 2025 r., a publiczną informację opublikowano 4–5 listopada 2025 r.

W skrócie

  • Skala: 17 000+ rekordów (dokładniej: 17 368).
  • Zakres danych: imiona i nazwiska, adresy e-mail oraz historia czatów w Slacku.
  • Wektor wejścia: malware na prywatnym PC pracownika → kradzież poświadczeń → logowanie do kont Slack.
  • Oś czasu: kompromitacja i wykrycie we wrześniu 2025 r.; ujawnienie na początku listopada 2025 r.
  • Zgłoszenia do regulatora: incydent dobrowolnie zgłoszono japońskiej Komisji Ochrony Informacji Osobowych (PPC).

Kontekst / historia / powiązania

Nikkei to właściciel m.in. dziennika The Nikkei i byłego właściciela Financial Times. Spółka doświadczała już incydentów bezpieczeństwa – w 2022 r. informowano o ataku ransomware z wpływem na dane klientów. Obecny przypadek dotyczy jednak SaaS-owego środowiska współpracy (Slack) i kradzieży poświadczeń, a nie szyfrowania zasobów.

Analiza techniczna / szczegóły luki

Z komunikatów prasowych i relacji mediów wynika następujący łańcuch zdarzeń:

  1. Infekcja endpointa – prywatny komputer pracownika został zainfekowany stealerem (rodzina infostealerów), który przechwytuje ciasteczka sesyjne i/lub tokeny OAuth oraz zapisane hasła.
  2. Eksfiltracja poświadczeń – malware wykradło dane uwierzytelniające do Slacka. Tego typu kampanie są powszechne: monitoring rynku kradzionych danych wskazuje na setki tysięcy przejętych zestawów poświadczeń Slacka.
  3. Dostęp do kont Slack – z użyciem skradzionych tokenów/hasła napastnik zalogował się do kont pracowników i pobrał historię czatów, a także dane profilowe (imię, nazwisko, e-mail).
  4. Detekcja i reakcja – we wrześniu 2025 r. zidentyfikowano incydent; wdrożono reset haseł i inne działania naprawcze.

Dlaczego Slack? Narzędzia kolaboracyjne przechowują duże ilości wrażliwych informacji (klucze API, linki do dokumentów, decyzje biznesowe). W wielu firmach Slack jest integrowany z SSO, ale słabym punktem pozostają prywatne urządzenia bez EDR/MDR, które mogą wyciec tokeny sesyjne mimo MFA. (Wniosek na podstawie opisu incydentu i praktyk branżowych).

Praktyczne konsekwencje / ryzyko

  • Spear-phishing i BEC – wyciek adresów e-mail + kontekstu rozmów ułatwia podszywanie się pod pracowników/partnerów.
  • Inżynieria społeczna – znajomość struktur projektów i nazw kanałów zwiększa skuteczność ataków na kolejne zasoby (Confluence, Git, CRM).
  • Ekspozycja metadanych – historia czatu często zawiera linki do dokumentów i tokeny zaproszeń – nawet jeśli same pliki są w innych systemach.
  • Ryzyko wtórnych naruszeń u partnerów, których dane kontaktowe były w Slacku.

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji korzystających ze Slacka i podobnych narzędzi:

  1. Wymuś SSO + MFA oraz Device Trust (dostęp tylko z zarządzanych, zgodnych urządzeń).
  2. EDR/MDR na wszystkich urządzeniach z dostępem do Slacka (także BYOD) + polityka zakazu używania prywatnych komputerów bez MDM.
  3. Token hygiene: cykliczne unieważnianie tokenów, krótkie TTL sesji, rotacja haseł aplikacyjnych, blokada legacy tokens.
  4. Least privilege w Slacku: ogranicz liczbę adminów, wyłącz gości zewnętrznych tam, gdzie to możliwe, audytuj OAuth apps i integracje.
  5. Retencja i DLP: skróć retencję wiadomości i plików, włącz DLP dla treści (wykrywanie kluczy API, numerów kart, danych osobowych).
  6. Threat hunting: przegląd audit logs (logowania, eksporty, API calls), IOC dla znanych stealerów; monitoruj nietypowe pobrania historii kanałów.
  7. Szkolenia i playbook: trening przeciw spear-phishingowi opartemu o realne wątki Slack, gotowy playbook „token/session theft”.
  8. Komunikacja z partnerami: powiadom łańcuch dostaw, jeśli ich dane kontaktowe mogły wyciec; wprowadź out-of-band kanał weryfikacji płatności/zleceń.

Różnice / porównania z innymi przypadkami

  • Model ataku: zamiast klasycznego ransomware na zasoby on-prem, mamy atak na warstwę tożsamości i sesji SaaS. To zmienia priorytety: kluczowe stają się kontrola urządzeń i higiena tokenów, nie tylko backupy.
  • Dobrowolne zgłoszenie do regulatora (PPC) mimo braku formalnego obowiązku dla danych „reporterskich” – to rzadziej spotykana, bardziej transparentna praktyka.

Podsumowanie / kluczowe wnioski

  • Jedno zainfekowane prywatne urządzenie może otworzyć drzwi do firmowego komunikatora i ujawnić tysiące rekordów oraz historie czatów.
  • MFA nie wystarczy, jeśli napastnik kradnie tokeny sesyjne – konieczna jest kontrola urządzeń, EDR i skracanie żywotności sesji.
  • Organizacje powinny traktować Slack/Teams jak systemy o wysokiej wrażliwości, z DLP, retencją i monitoringiem na poziomie poczty/CRM.

Źródła / bibliografia

  • SecurityWeek: oficjalne szczegóły incydentu, skala i wektor wejścia (infostealer → Slack) oraz wzmianka o wcześniejszym ransomware (2022). (SecurityWeek)
  • The Record / Recorded Future News: potwierdzenie zakresu i scenariusza ataku. (The Record from Recorded Future)
  • Dark Reading: cytat z komunikatu (prywatny PC, wirus, wrzesień) i oś czasu reakcji. (Dark Reading)
  • CNET Japan: dokładna liczba „17 368”, potwierdzenie retencji i dobrowolnego zgłoszenia do PPC. (japan.cnet.com)
  • Impress Watch (INTERNET Watch): lokalne potwierdzenie zakresu danych i dat. (INTERNET Watch)

SonicWall potwierdza: za wrześniowym włamaniem do chmury stoją „aktorzy sponsorowani przez państwo” — co to oznacza dla firm

Wprowadzenie do problemu / definicja luki

SonicWall potwierdził, że wrześniowy incydent dotyczył nieautoryzowanego pobrania kopii zapasowych konfiguracji firewalli z określonego środowiska chmurowego, wykorzystując wywołanie API, a sprawcami byli aktorzy sponsorowani przez państwo. Firma podkreśla, że zdarzenie nie ma związku z globalnymi kampaniami ransomware (m.in. Akira) wymierzonymi w urządzenia brzegowe. Ustalenia pochodzą z zakończonego dochodzenia prowadzonego z udziałem Mandiant.

W skrócie

  • Zakres: dostęp do plików kopii konfiguracji (EXP) firewalli przechowywanych w chmurze MySonicWall; produktowe firmware i inne systemy SonicWall nie zostały naruszone.
  • Atrybucja: potwierdzono udział aktorów państwowych; wektor to zaufane wywołanie API w konkretnym środowisku chmurowym.
  • Kogo dotyczy: SonicWall w finalnym komunikacie wskazał, że wszyscy klienci korzystający z funkcji cloud backup powinni traktować się jako potencjalnie dotknięci incydentem (uprzednio mówiono o <5%).
  • Ryzyko: choć hasła/sekrety w plikach są indywidualnie szyfrowane (AES-256 dla Gen7, 3DES dla Gen6), same konfiguracje ujawniają topologię, reguły i punkty dostępu — co ułatwia ataki ukierunkowane.
  • Działania naprawcze: SonicWall udostępnił Online Analysis Tool i Credentials Reset Tool oraz szczegółowy playbook remediacji; CISA wydała alert z zaleceniami dla operatorów.

Kontekst / historia / powiązania

  • 17 września 2025 r. SonicWall poinformował o podejrzanej aktywności wokół kopii zapasowych w chmurze MySonicWall. 22 września CISA opublikowała alert z rekomendacjami. W kolejnych tygodniach komunikaty ewoluowały: od „<5%” do „wszyscy użytkownicy cloud backup”. 4 listopada SonicWall zakończył dochodzenie, przypisując atak aktorowi sponsorowanemu przez państwo. 6 listopada temat opisały media branżowe.

Analiza techniczna / szczegóły luki

Co zawiera plik .EXP?

  • Pełny zrzut konfiguracji urządzenia (reguły, interfejsy, polityki, konta usługowe, profile VPN/LDAP/RADIUS/SNMP, itp.).
  • Sekrety (hasła/klucze) w tej konfiguracji są dodatkowo szyfrowane per-pole (AES-256 dla Gen7; 3DES dla Gen6).
  • W workflou chmurowym: plik jest przesyłany po HTTPS do Cloud Backup API, następnie dodatkowo szyfrowany i kompresowany przed składowaniem; przy pobieraniu API usuwa szyfrowanie „całościowe”, pozostawiając oryginalny plik (z zaszyfrowanymi sekretami).

Dlaczego to wciąż groźne, mimo szyfrowania sekretów?

  • Konfiguracja zdradza strukturę sieci i usług, listę adresów/IP/FQDN, schemat NAT/reguł i włączone interfejsy zewnętrzne — to „mapa drogowa” dla atakującego.
  • Jeśli w konfiguracji znajdowały się sekrety starszego typu (Gen6/3DES), zbyt krótkie hasła, współdzielone poświadczenia, dane TOTP/OTP seed lub hashe, ryzyko ich odtworzenia/obejścia wzrasta.
  • Zidentyfikowane przez SonicWall „Active – High Priority” urządzenia (z usługami wystawionymi do Internetu) powinny być traktowane jako pilne.

Praktyczne konsekwencje / ryzyko

  • Ukierunkowane logowania do SSL VPN/administracji z użyciem prawidłowych danych (po rotacji haseł również do kont serwisowych), próby rekonfiguracji lub ominięcia reguł.
  • Pivoting do segmentów LAN na bazie znajomości tras/statycznych tuneli VPN.
  • Ataki na łańcuch tożsamości (RADIUS/LDAP/AD) i urządzenia towarzyszące (np. SIEM, NMS), których dane konfiguracyjne mogły znaleźć się w kopii.
  • Wiarygodny spear-phishing/SMB hijack dzięki wiedzy o nazwach hostów, regułach i podsieciach.
    Te scenariusze są spójne z ostrzeżeniami amerykańskich instytucji (CISA) dotyczącymi skutków ekspozycji plików preferencji firewalli.

Rekomendacje operacyjne / co zrobić teraz

  1. Weryfikacja ekspozycji: zaloguj się do MySonicWall → Product Management → Issue List i sprawdź status urządzeń (Active – High Priority / Lower Priority / Inactive).
  2. Użyj narzędzi SonicWall:
    • Online Analysis Tool – wskaże usługi wymagające remediacji,
    • Credentials Reset Tool – zautomatyzuje rotację lokalnych haseł i TOTP.
  3. Rotacja sekretów (pełna, nie wybiórcza):
    • konta administratorów firewalli,
    • konta i klucze RADIUS/LDAP/SNMP, profile VPN (site-to-site/remote), konta API,
    • wszelkie shared secrets, a także certyfikaty jeśli były powiązane z hasłem w konfiguracji.
  4. Higiena dostępu zdalnego: wymuś MFA (z nowymi seedami), blokuj po IP/geo, ogranicz portale admin do bastionów/VPN, włącz alerty na nietypowe logowania; skorzystaj z zaleceń CISA.
  5. Hardening i monitoring:
    • porównaj konfiguracje przed/po, szukaj nieautoryzowanych zmian,
    • koreluj logi z EDR/SIEM, poluj na artefakty lateral movement,
    • aktualizuj do Gen7 i najnowszego firmware’u, usuń nieużywane konta/usługi.
  6. Komunikacja i dowody: utrwal artefakty IR, przygotuj notyfikacje do partnerów łańcucha dostaw i — gdy wymagane — do regulatorów.

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

  • To nie jest „klasyczny” ransomware na urządzenie brzegowe. SonicWall i media branżowe podkreślają rozdzielenie tego incydentu od kampanii Akira wymierzonych w SSL VPN/edge. Tutaj osią ataku była warstwa chmurowa (cloud backup API), a nie exploit na samym firewallu.
  • Atrybucja ma znaczenie: przypisanie do „state-sponsored” sugeruje długoterminową eksfiltrację wiedzy o środowiskach i potencjalne, ciche nadużycia — w odróżnieniu od hałaśliwych szyfrowań danych typowych dla grup finansowych.

Podsumowanie / kluczowe wnioski

  • Incydent dotknął wszystkich korzystających z cloud backup i został przypisany aktorom państwowym.
  • Choć sekrety w plikach są szyfrowane, ujawniona konfiguracja znacząco ułatwia przygotowanie skutecznych ataków.
  • Nie zwlekaj: przeprowadź pełną rotację sekretów, przejrzyj ekspozycję usług i skorzystaj z narzędzi SonicWall oraz zaleceń CISA.

Źródła / bibliografia

  1. SonicWall Blog — Cloud Backup Security Incident Investigation Complete and Strengthened Cyber Resilience (4 listopada 2025 r.). (SonicWall)
  2. SonicWall Support Notice — MySonicWall Cloud Backup File Incident (aktualizacja 28 października 2025 r.). (SonicWall)
  3. CISA Alert — SonicWall Releases Advisory for Customers after Security Incident (22 września 2025 r.). (CISA)
  4. BleepingComputer — SonicWall says state-sponsored hackers behind September security breach (5 listopada 2025 r.). (BleepingComputer)
  5. The Hacker News — SonicWall Confirms State-Sponsored Hackers Behind September Cloud Backup Breach (6 listopada 2025 r.). (The Hacker News)

Detaliści coraz częściej odmawiają okupu. Co pokazuje raport Sophos „State of Ransomware in Retail 2025”?

Wprowadzenie do problemu / definicja luki

Sektor retail pozostaje jednym z najczęściej atakowanych przez grupy ransomware. Najnowsze dane Sophos wskazują jednak na wyraźną zmianę: mniej ataków kończy się skutecznym szyfrowaniem danych, koszty odtworzenia spadają, a firmy odbudowują się szybciej. Jednocześnie rośnie presja finansowa – medianowe żądania okupu wzrosły do 2 mln USD, podczas gdy medianowe płatności utrzymują się w okolicach 1 mln USD.

W skrócie

  • Mniej szyfrowań, więcej wymuszeń: odsetek skutecznych szyfrowań spadł do 48%, rośnie udział „extortion-only” (kradzież i groźba publikacji bez szyfrowania).
  • Żądania rosną szybciej niż płatności: mediana żądania 2 mln USD, mediana płatności 1 mln USD.
  • Skąd się biorą incydenty? W 46% przypadków źródłem był „nieznany ubytek bezpieczeństwa” (unknown gap); 58% detalistów, którzy doświadczyli szyfrowania, zapłaciło okup.
  • Koszty i czas odtwarzania: średni koszt odtworzenia (bez okupu) spadł do ok. 1,6 mln USD; połowa firm wraca do normalnego działania w tydzień.

Kontekst / historia / powiązania

Sophos publikuje branżowe „State of Ransomware” od lat, a tegoroczna edycja dla retail (badanie 361 liderów IT/bezpieczeństwa w 16 krajach) rozszerza zakres o czynniki organizacyjne i wpływ na zespoły IT. To uzupełnia wnioski z raportu ogólnosektorowego 2025 (m.in. średni koszt odtworzenia 1,5 mln USD).

Analiza techniczna / szczegóły luki

Wektory wejścia. Najczęściej wykorzystywane były:

  • Luki w oprogramowaniu/infrastrukturze (pierwsze miejsce),
  • Składniki tożsamości (skradzione/wyłudzone dane logowania),
  • Phishing.
    Dodatkowo wielu respondentów wskazało braki organizacyjne: „nieznana luka” w środowisku, ograniczone kompetencje zespołu lub niedobór narzędzi ochronnych. Te obserwacje sugerują, że detaliści mają problem nie tylko z podatnościami, ale i z widocznością oraz procesami.

Zmiana taktyk atakujących. Maleje rola czystego szyfrowania, a zyskuje podwójna/pojedyncza ekstorsja (exfiltracja i groźba publikacji), zgodnie z trendami opisanymi szerzej przez instytucje rządowe.

Ekonomia okupu. U detalistów istotnie wzrosły żądania (mediana 2 mln USD), ale płatności nie nadążają (ok. 1 mln USD). Firmy częściej negocjują lub odmawiają, co potwierdzają relacje prasowe oraz wpisy Sophos.

Praktyczne konsekwencje / ryzyko

  • Ryzyko operacyjne: nawet bez płacenia okupu koszty przestojów, nadgodzin i napraw są wysokie (ok. 1,6 mln USD średnio w retail).
  • Ryzyko reputacyjne i regulacyjne: wycieki danych klientów (PII, dane płatnicze) przy modelu „extortion-only” implikują obowiązki notyfikacyjne i ryzyko kar. (Wniosek na podstawie trendów CISA dot. exfiltracji jako narzędzia nacisku).
  • Obciążenie zespołów: wzrost presji na IT/SEC, rotacje kadry kierowniczej, absencje i wypalenie po incydencie.

Rekomendacje operacyjne / co zrobić teraz

  1. Zamknij „unknown gaps”: uruchom ciągłe attack surface management (ASM), skan podatności i priorytetyzację patchy pod kątem exploitowalności (KEV, znane łańcuchy RCE). (Wniosek zgodny z przyczynami incydentów w retail).
  2. Tożsamość > perymetr: phishing-resistant MFA (FIDO2), polityki dostępu warunkowego, segmentacja ról i JIT/JEA dla kont uprzywilejowanych. (Zgodne z trendem nadużycia poświadczeń).
  3. Kontrola danych i DLP: szyfrowanie w spoczynku i w ruchu, monitoring exfiltracji (brokerzy CASB, egress filtering, honey-tokens). (Adekwatne do wzrostu extortion-only).
  4. Detekcja i reakcja: EDR/XDR z playbookami na lateral movement; testy odzyskiwania; izolacja stacji POS; sieci gościnne odseparowane od zaplecza. (W duchu szybszego RTO raportowanego w retail).
  5. Backupy odporne na sabotaż: 3-2-1, kopie offline/immutability, regularne testy odtwarzania i plany decyzyjne dot. okupu.
  6. Higiena podatności aplikacji web/edge: WAF, SSRF/RCE guardrails, skany SCA/DAST, szybkie łatanie urządzeń peryferyjnych (VPN/SD-WAN/Wi-Fi). (Zgodne z „exploited vulnerabilities lead the way”).
  7. Ćwiczenia „table-top” z zarządem: ścieżki decyzji przy negocjacjach, wymagania ubezpieczyciela, komunikacja do klientów/regulatorów. (Z uwagi na presję zarządczą i stres zespołów).

Różnice / porównania z innymi przypadkami

W porównaniu z ogólnosektorowym raportem Sophos 2025 (średni koszt odtworzenia ~1,5 mln USD), retail wypada podobnie kosztowo, ale wyróżnia się większą presją okupu (2 mln vs. 1 mln medianowo żądane w retail) oraz częstszym odwołaniem do „unknown gaps” jako pierwotnej przyczyny. To sugeruje specyfikę rozproszonego środowiska (POS, zaplecze, e-commerce, łańcuch dostaw).

Podsumowanie / kluczowe wnioski

  • Detaliści odbudowują się szybciej i płacą proporcjonalnie mniej względem rosnących żądań, ale to nie znaczy, że ryzyko maleje – zmienia się taktyka napastników (exfiltracja i wymuszenia).
  • Widoczność i podstawy inżynieryjne (ASM, patching, MFA, segmentacja) to najskuteczniejsza odpowiedź na „unknown gaps”.
  • „Czy płacić?” – nawet jeśli część firm płaci (58%), dane pokazują, że negocjacje i odmowa coraz częściej działają, o ile istnieją dobre kopie i procedury.

Źródła / bibliografia

  1. Help Net Security – „Retailers are learning to say no to ransom demands” (06.11.2025). (Help Net Security)
  2. Sophos – State of Ransomware in Retail 2025 (strona raportu). (SOPHOS)
  3. Sophos News – „The State of Ransomware in Retail 2025” (19.08.2025). (Sophos News)
  4. Sophos – Press release: „More than Half (58%) of Retailers Pay the Ransom” (04.11.2025). (SOPHOS)
  5. CISA – #StopRansomware Guide (aktualne wytyczne nt. podwójnej/potrójnej ekstorsji). (CISA)

Fedora 42 łata krytyczne luki w X.Org X11 Server (xserver 21.1.20): CVE-2025-62229, CVE-2025-62230, CVE-2025-62231

Wprowadzenie do problemu / definicja luki

6 listopada 2025 r. Fedora udostępniła aktualizację xorg-x11-server do wersji 21.1.20 dla Fedora 42, która eliminuje trzy nowe luki w X.Org/Xwayland: CVE-2025-62229, CVE-2025-62230 i CVE-2025-62231. Pakiet został zbudowany w ramach zgłoszenia FEDORA-2025-43c76ece40 i jest dostępny przez system aktualizacji Bodhi/DNF. Aktualizacja podbija wersję serwera X i zawiera poprawki bezpieczeństwa dostarczone upstream przez X.Org.

W skrócie

  • Dotknięte komponenty: X.Org X server (Xorg) oraz Xwayland.
  • Wersja naprawcza (Fedora 42): 21.1.20-1.fc42.
  • Vektory ataku: głównie lokalne – złośliwy lub skompromitowany klient X11 może spowodować use-after-free lub nadpisanie pamięci w serwerze X.
  • Skutki: awarie (DoS) lub potencjalnie wykonanie kodu w kontekście serwera X.
  • Działaj teraz: zaktualizuj pakiety i zrestartuj sesję graficzną/menedżer logowania.

Kontekst / historia / powiązania

X.Org pozostaje krytycznym elementem stosu graficznego na Linuksie – nawet w dystrybucjach domyślnie używających Waylanda, ponieważ Xwayland utrzymuje kompatybilność z aplikacjami X11. W 2025 r. X.Org kilkukrotnie poprawiał błędy klasy memory safety, a dystrybucje (w tym Fedora) backportują te poprawki do stabilnych wydań. Najnowszy update dla F42 scala poprawki z upstream i udostępnia je poprzez Bodhi.

Analiza techniczna / szczegóły luki

CVE-2025-62229 — use-after-free w obsłudze powiadomień X11 Present
Błąd w logice tworzenia powiadomień Present może pozostawić „dangling pointery” i prowadzić do use-after-free, skutkując korupcją pamięci lub crashem serwera X/Xwayland. Atakujący może wywołać błąd, generując odpowiednio spreparowane powiadomienia Present.

CVE-2025-62230 — use-after-free w czyszczeniu zasobów XKB
Niewłaściwa obsługa sprzątania zasobów klienta w rozszerzeniu XKB prowadzi do wcześniejszego zwolnienia struktur bez poprawnego odłączenia powiązanych obiektów. Skutkiem jest use-after-free, który może ujawnić się przy rozłączaniu się klienta.

CVE-2025-62231 — przepełnienie (overflow) w XkbSetCompatMap
Brak właściwych kontroli zakresów podczas przetwarzania danych wejściowych do funkcji XkbSetCompatMap() może spowodować nadpisanie pamięci lub awarię. Problem dotyczy rozszerzenia XKB i może być wyzwalany specjalnie spreparowanymi danymi od klienta.

Wersja naprawcza i pakietowanie (Fedora 42)
Fedora podniosła pakiet xorg-x11-server do 21.1.20-1.fc42 w ramach aktualizacji FEDORA-2025-43c76ece40, opisanej jako „Update to xserver 21.1.20, CVE fix for: CVE-2025-62229, CVE-2025-62230, CVE-2025-62231”.

Praktyczne konsekwencje / ryzyko

  • Priorytet: średni–wysoki w środowiskach z wieloma użytkownikami na tym samym hoście, z X11 forwarding lub z nieufnymi klientami (np. CI, VDI, laby).
  • Model ataku: lokalny (z poziomu klienta X), ale skutki mogą obejmować DoS i potencjalny RCE w procesie serwera X/Xwayland.
  • Zakres: dotyczy zarówno klasycznego Xorg, jak i Xwaylanda – praktycznie wszystkich stacji roboczych korzystających z aplikacji X11 na Fedorze 42.

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj system (Fedora 42): sudo dnf upgrade --advisory FEDORA-2025-43c76ece40 # lub pełna aktualizacja sudo dnf upgrade --refresh Następnie zrestartuj sesję graficzną (wylogowanie/logowanie) lub przeładuj menedżer logowania (gdm/sddm/lightdm), aby nowe biblioteki/serwer zostały wczytane.
  2. Zweryfikuj wersję: rpm -q xorg-x11-server # oczekiwane: xorg-x11-server-21.1.20-1.fc42
  3. Zmniejsz powierzchnię ataku (best practices):
    • Wyłącz/ogranicz X11 forwarding w SSH lub używaj trybu ForwardX11Trusted=no tylko w razie potrzeby.
    • Preferuj Waylanda tam, gdzie to możliwe; jeśli aplikacje X11 są niezbędne, uruchamiaj je przez Xwayland (izolacja per-proces).
    • Monitoruj logi (journalctl -b | grep -i Xorg\|Xwayland) po aktualizacji, czy nie pojawiają się crashe/ostrzeżenia.
    • Egzekwuj aktualizacje także na systemach headless z pakietami Xvfb/Xwayland.

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

W 2025 r. X.Org łatał też inne błędy pamięci w komponentach XKB/kompozytora (m.in. use-after-free i przepełnienia bufora) – omawiane tu CVE wpisują się w ten trend: błędy walidacji długości/żywotności obiektów w rozszerzeniach X11 skutkujące korupcją pamięci. Aktualizacja 21.1.20 w Fedorze 42 konsoliduje poprawki konkretnie dla CVE-2025-62229/-62230/-62231.

Podsumowanie / kluczowe wnioski

  • Fedora 42 wydała szybką aktualizację do xserver 21.1.20, eliminując trzy świeże luki w X.Org/Xwayland.
  • Ataki są głównie lokalne, ale mogą skutkować poważnymi konsekwencjami (DoS/RCE).
  • Zaktualizuj pakiety i zrestartuj środowisko graficzne – to najprostszy i najskuteczniejszy krok ograniczający ryzyko.

Źródła / bibliografia

  • Fedora Bodhi — FEDORA-2025-43c76ece40: opis aktualizacji do 21.1.20 i listy CVE. (bodhi.fedoraproject.org)
  • Debian Security Tracker — CVE-2025-62229: opis use-after-free w Present. (security-tracker.debian.org)
  • Debian Security Tracker — CVE-2025-62231: opis overflow w XkbSetCompatMap. (security-tracker.debian.org)
  • cve.org — CVE-2025-62230: opis use-after-free w czyszczeniu zasobów XKB. (cve.org)
  • LinuxSecurity Advisory (link od użytkownika) — streszczenie wydania dla Fedora 42. (Linux Security)

Daylight pozyskuje 33 mln dol. na „agentowe” MDR. Co to oznacza dla SOC-ów?

Wprowadzenie do problemu / definicja luki

Skalowanie operacji bezpieczeństwa (SOC) rozbija się dziś o dwa twarde limity: czas reakcji i liczbę ludzi. Klasyczne MDR-y (Managed Detection and Response) odciążają zespoły, ale nadal cierpią na przeciążenie alertami i „eskalowanie zamiast rozwiązywania”. Startup Daylight proponuje alternatywę: połączenie agentowych systemów AI z nadzorem doświadczonych analityków, aby dostarczać rezultaty (containment, remediacje) zamiast samych powiadomień. Firma właśnie ogłosiła rundę 33 mln USD (Series A), która ma przyspieszyć rozwój platformy oraz modułów dla Identity Threat Response i Cloud Workload Protection.

W skrócie

  • 33 mln USD Series A prowadzone przez Craft Ventures; udział m.in. Bain Capital Ventures i Maple VC. Całkowite finansowanie: 40 mln USD.
  • Daylight określa swój model jako MASS – Managed Agentic Security Services: autonomiczne agentowe AI + nadzór analityków 24/7.
  • Cel rundy: ekspansja w USA, rozwój platformy operacji bezpieczeństwa i uruchomienie modułów dla tożsamości oraz chmury.
  • Firma deklaruje wdrożenia „w mniej niż godzinę”, „do 90% mniej false positives” i klientów w USA/EU (m.in. The Motley Fool, Cresta, McKinsey Investment Office). (Deklaracje producenta)
  • Założyciele: Hagai Shapira (CEO) i Eldad Rudich (CTO) – weterani Unit 8200.

Kontekst / historia / powiązania

Runda ogłoszona 4–5 listopada 2025 r. następuje trzy miesiące po seedzie 7 mln USD i wpisuje się w trend przyspieszonego finansowania narzędzi AI-native SecOps. W tle mamy eksplozję ataków napędzanych AI, rosnące środowiska hybrydowe i chroniczny deficyt talentów w SOC. Daylight pozycjonuje MASS jako ewolucję MDR: agenci AI wykonują monitoring, triage, dochodzenia kontekstowe i wstępne remediacje, a analitycy podejmują decyzje o wyższym ciężarze.

Analiza techniczna / szczegóły podejścia

Architektura MASS (wysnuta z opisów publicznych):

  • Warstwa agentowa (AI-core): zestaw wyspecjalizowanych agentów wykonujących korelację sygnałów, priorytetyzację, „case building” oraz autonomiczne działania (np. izolacja hosta, blokada konta, polityka w EDR/IdP), z możliwością pracy cloud/on-prem/hybryda.
  • Nadzór ekspercki (human-in-the-loop): analitycy „kalibru PhD” potwierdzają hipotezy, rozszerzają zakres dochodzenia, zatwierdzają remediacje wysokiego ryzyka i utrzymują „guardrails” dla agentów.
  • Integracje i czas wartości: producent podkreśla szybkie wdrożenie (<1h) i pracę „w istniejącej infrastrukturze” – to sugeruje gotowe konektory do EDR/XDR, SIEM, IdP, chmur. (Deklaracje producenta)
  • Nowe moduły: Identity Threat Response i Cloud Workload Protection mają rozszerzyć autonomię poza klasyczne endpointy.

Różnica semantyczna: Daylight używa pojęcia MASS aby odróżnić się od „AI-assisted MDR”. Klucz to agentowość (samodzielne działanie agentów w granicach polityk) zamiast samego „copilota” do analizy zdarzeń.

Praktyczne konsekwencje / ryzyko

Plusy dla SOC:

  • Skrócenie MTTD/MTTR dzięki automatycznym dochodzeniom i remediacjom niskiego ryzyka.
  • Redukcja alert fatigue i kosztów eskalacji; potencjalnie mniej ról L1/L2, więcej „SRE-like SecOps”.

Ryzyka i „ciemne pola”:

  • Zaufanie do agentów: konieczne twarde guardrails, audyt działań i „two-person rule” dla akcji destrukcyjnych (np. masowe disable kont).
  • Bias danych i halucynacje: agentowe systemy oparte na LLM muszą mieć deterministyczne playbooki i walidację efektów.
  • Vendor lock-in & integracje: rzeczywista głębokość integracji z EDR/XDR/IdP/SaaS będzie decydować o skuteczności poza presales demo.
  • Regulacje/zgodność: ścieżki audytu, eDiscovery i zgodność z politykami tożsamości (zwłaszcza w UE).
    (Ocena własna na podstawie publicznych opisów architektury.)

Rekomendacje operacyjne / co zrobić teraz

  1. Pilot 60–90 dni: wybrane segmenty (np. wybrane OU w IdP, część floty EDR, wycinek chmury). Zdefiniuj KPI: MTTD/MTTR, % zautomatyzowanych remediacji, precyzja triage.
  2. RACI dla agentów: policy gates dla akcji o wysokim wpływie (disable użytkownika, kwarantanna zasobu chmurowego).
  3. Playbooki „deterministyczne”: ustandaryzowane runbooki SOAR jako „rails” dla agentów; logowanie decyzji i wyników.
  4. Ocena integracji: sprawdź konektory do twoich krytycznych systemów (IdP, EDR/XDR, chmury, SaaS).
  5. Model zagrożeń AI: włącz AI threat modeling (np. ryzyka „model misuse”, nadmierna autonomiczność, eskalacja uprawnień).
  6. Due diligence dostawcy: SLA na czas reakcji analityków, transparentność działań agentów, mechanizmy „kill-switch”.

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

  • Klasyczny MDR/XDR: zwykle „detect → alert → escalate”, ograniczona automatyzacja i często ręczne dochodzenia. Daylight twierdzi, że przechodzi do „detect → investigate → resolve” z agentami AI, a człowiek nadzoruje tylko trudne przypadki.
  • „AI-assisted SOC copilot”: narzędzia pomagające analitykom pisać zapytania lub streszczać alerty. MASS aspiruje do autonomii operacyjnej w ramach polityk (containment/remediacje), co zbliża je do „autonomic SOC”.

Podsumowanie / kluczowe wnioski

  • Runda 33 mln USD (Series A) potwierdza popyt na agentowe podejście do SecOps. MASS ma ambicję dostarczać wynik, nie tylko alert.
  • Sukces wdrożeń będzie zależeć od jakości integracji, dojrzałości guardrails i przejrzystości działań agentów.
  • Dla CISO to realna ścieżka do skrócenia MTTR bez liniowego zwiększania etatów – ale wymaga świadomego pilotowania, kontroli zmian i audytu.

Źródła / bibliografia

  1. SecurityWeek: Daylight Raises $33 Million for AI-Powered MDR Platform (05.11.2025). (SecurityWeek)
  2. Blog Daylight (Hagai Shapira): Lighting the Next Chapter… (04.11.2025). (daylight.ai)
  3. SiliconANGLE: Daylight Security raises $33M… (04.11.2025). (SiliconANGLE)
  4. CTech / Calcalistech: Cyber startup Daylight raises $33 million… (04.11.2025). (ctech)
  5. Daylight – About / Leadership. (daylight.ai)