Dlaczego współczesne cyberataki coraz częściej omijają klasyczne zabezpieczenia?
Dlaczego współczesne cyberataki coraz częściej omijają klasyczne zabezpieczenia?
Jeszcze kilka lat temu obraz cyberataku był stosunkowo prosty.
Napastnik znajdował lukę.
Wykorzystywał exploit.
Instalował malware.
Przejmował serwer.
Dzisiaj coraz częściej wygląda to zupełnie inaczej.
Napastnik nie musi nawet „łamać” zabezpieczeń.
Może je przejść prawidłowo.
Może zalogować się poprawnym kontem, wykorzystać prawidłową sesję albo zaatakować element infrastruktury, który sam jest uznawany za zaufany.
To właśnie dlatego współczesne bezpieczeństwo coraz mniej przypomina walkę z pojedynczym exploitem, a bardziej kontrolowanie całego łańcucha zaufania.
Hasło i MFA nie kończą już procesu bezpieczeństwa
Klasyczny model wyglądał tak:
Login
↓
Password
↓
MFA
↓
Access
Problem?
Jeżeli napastnik zdobędzie hasło i przekona użytkownika do zatwierdzenia MFA, system może uznać logowanie za prawidłowe.
Dobrym przykładem jest atak ShinyHunters na firmę cybersecurity ReliaQuest. Jak opisywał Bugstoday, napastnicy wykorzystali socjotechnikę, rozmowę telefoniczną, fałszywą stronę SSO oraz MFA fatigue, aby doprowadzić do prawidłowego uwierzytelnienia.
ShinyHunters Hit a Cybersecurity Company. A Phone Call Was Enough
To bardzo dobry przykład tego, dlaczego samo:
„Mamy MFA”
nie powinno być traktowane jako odpowiedź na pytanie o bezpieczeństwo kont.
Authentication nie oznacza jeszcze zaufania
Współczesna architektura bezpieczeństwa powinna rozdzielać kilka etapów.
Authentication
↓
Device Trust
↓
Risk Assessment
↓
Authorization
↓
Application
↓
Data
Użytkownik może więc zostać prawidłowo uwierzytelniony, ale nadal nie otrzymać dostępu do określonego systemu.
To fundamentalna różnica.
Jeżeli napastnik przejmie konto:
user@example.com
nie powinien automatycznie otrzymać:
VPN
+
Cloud
+
Source Code
+
Admin Panel
+
Internal Applications
Każdy kolejny poziom powinien mieć własne zabezpieczenia.
Najgroźniejsze są systemy stojące na granicy sieci
Niektóre urządzenia i serwery mają szczególne znaczenie.
To nie są zwykłe komputery.
To bramy.
VPN.
Gatewaye.
Load balancery.
Serwery dostępu.
Systemy uwierzytelniania.
Jeżeli taki system zostanie przejęty, napastnik nie musi atakować każdego komputera osobno.
Może wejść przez infrastrukturę stojącą na granicy organizacji.
Dobrym przykładem jest ostatnia kampania przeciwko Citrix NetScaler.
W przypadku CVE-2026-8452 sytuacja jest szczególnie nieprzyjemna, ponieważ podatność jest aktywnie wykorzystywana, a obserwowano już instalowanie web shelli na zaatakowanych urządzeniach.
Bugstoday opisał ten przypadek w materiale Citrix NetScaler Is Under Attack. Hackers Are Already Dropping Web Shells.
Schemat jest prosty:
Internet
↓
NetScaler
↓
Initial Foothold
↓
Web Shell
↓
Reconnaissance
↓
Internal Network
I właśnie dlatego urządzenia brzegowe powinny być traktowane jak systemy o najwyższym znaczeniu.
Security appliance też może stać się narzędziem ataku
Jest jeszcze bardziej przewrotna sytuacja.
Co jeśli zaatakuje się oprogramowanie, którego zadaniem jest ochrona komputerów?
W przypadku WatchGuard Agent pojawiły się dwie krytyczne podatności umożliwiające wykonanie kodu bez uwierzytelnienia. Jedna dotyczy mechanizmu UDP discovery i command service, a druga path traversal.
Obie mogą prowadzić do wykonania kodu na systemie Windows.
Bugstoday zwrócił na ten problem uwagę w artykule WatchGuard Agent Has Two Critical RCE Bugs. No Login Required.
Problem jest tutaj wyjątkowo ciekawy.
Security software nie jest zwykłą aplikacją.
Często posiada wysokie uprawnienia.
Jeżeli napastnik przejmie taki komponent, może otrzymać bardzo potężny mechanizm wykonawczy.
Czyli:
Security Software
↓
Vulnerability
↓
Code Execution
↓
Elevated Privileges
↓
Endpoint Compromise
To pokazuje, że nie można automatycznie zakładać:
„Mamy zainstalowane oprogramowanie security, więc jesteśmy bezpieczniejsi.”
Każdy dodatkowy komponent zwiększa również powierzchnię ataku.
Najgorszy scenariusz: podatność + infrastruktura krytyczna dla organizacji
Wysokie ryzyko pojawia się wtedy, gdy podatny system znajduje się w centrum infrastruktury.
Przykład?
SharePoint.
Nie jest to tylko serwer przechowujący dokumenty.
W środowisku firmowym może być powiązany z:
- kontami użytkowników,
- dokumentami,
- procesami biznesowymi,
- integracjami,
- usługami wewnętrznymi,
- administracją.
Bugstoday opisał CVE-2026-55040 jako krytyczny authentication bypass z publicznym PoC i aktywną eksploatacją. Jeszcze ważniejsze jest to, że podatność może zostać połączona z inną luką w łańcuch prowadzący do RCE.
Temat został przedstawiony w artykule Microsoft SharePoint Auth Bypass Gets a Public PoC — And the RCE Chain Is Worse.
To pokazuje bardzo ważny trend.
Pojedyncza podatność nie musi być katastrofalna.
Może nią zostać po połączeniu z kolejnym elementem.
Cyberatak coraz częściej jest łańcuchem
Współczesny atak można przedstawić tak:
Initial Access
↓
Authentication Bypass
↓
Session / Token
↓
Privilege Escalation
↓
Persistence
↓
Lateral Movement
↓
Data Access
↓
Exfiltration
Napastnik nie potrzebuje więc jednej „superluki”.
Potrzebuje kilku elementów, które razem tworzą działający łańcuch.
Dlatego podatność z CVSS 9.0 nie zawsze jest bardziej niebezpieczna niż luka z niższą oceną.
Liczy się również:
gdzie znajduje się podatny system i z czym jest połączony.
Największym problemem jest zaufanie
W każdym z tych przypadków występuje podobny motyw.
System ufa:
- użytkownikowi,
- urządzeniu,
- tokenowi,
- aplikacji,
- agentowi,
- serwerowi,
- połączeniu,
- procesowi.
Napastnik próbuje przejąć właśnie ten element.
Dlatego można przedstawić współczesny cyberatak jako próbę odpowiedzi na jedno pytanie:
Co sprawić, aby system uznał mnie za kogoś lub coś zaufanego?
W przypadku ShinyHunters była to tożsamość użytkownika.
W przypadku SharePoint — token.
W przypadku NetScaler — podatna usługa wystawiona do Internetu.
W przypadku WatchGuard Agent — uprzywilejowany komponent bezpieczeństwa.
Technika jest różna.
Cel pozostaje podobny.
Zero Trust nie jest już teorią
W takim środowisku model:
Inside = Trusted
Outside = Untrusted
jest niewystarczający.
Organizacja powinna zakładać:
Every Request
↓
Verify
↓
Evaluate Context
↓
Authorize
↓
Monitor
Nie wystarczy sprawdzić użytkownika raz.
Trzeba również kontrolować:
- urządzenie,
- aplikację,
- lokalizację,
- zachowanie,
- poziom ryzyka,
- rodzaj wykonywanej operacji.
Szczególnie ważne jest to w przypadku operacji administracyjnych.
Patchowanie również musi się zmienić
Klasyczny model:
CVE Published
↓
Wait for Maintenance Window
↓
Patch
coraz częściej jest zbyt wolny.
Jeżeli mamy:
Public PoC
+
Active Exploitation
+
Internet Exposure
sytuacja zmienia się natychmiast.
Jeżeli podatność jest już wykorzystywana, czas reakcji powinien być liczony w godzinach, a nie tygodniach.
Dlatego priorytet patchowania powinien uwzględniać nie tylko CVSS.
Lepszy model:
CVSS
+
Exploitability
+
Public PoC
+
Active Exploitation
+
Internet Exposure
+
Asset Criticality
=
Real Risk
Nie każda podatność wymaga tego samego czasu reakcji
Administrator powinien inaczej traktować:
Internal Test Server
i:
Internet-Facing VPN Gateway
Nawet jeżeli oba mają podobny wynik CVSS.
Jeszcze inaczej:
Identity Provider
oraz:
Developer Laptop
Warto więc tworzyć priorytety.
P1 — natychmiast
- aktywnie wykorzystywana luka,
- publiczny exploit,
- system wystawiony do Internetu,
- urządzenie VPN,
- system tożsamości,
- infrastruktura krytyczna.
P2 — bardzo szybko
- publiczny PoC,
- krytyczna podatność,
- system dostępny z sieci wewnętrznej,
- ważna aplikacja biznesowa.
P3 — standardowy cykl
- brak exploita,
- brak aktywnej eksploatacji,
- ograniczona powierzchnia ataku.
Największy błąd: patrzenie tylko na CVE
CVE mówi nam o podatności.
Nie mówi wszystkiego o incydencie.
Dwa systemy mogą mieć:
CVSS 9.8
ale zupełnie inne znaczenie biznesowe.
System A:
Isolated Lab
System B:
Internet-Facing Authentication Gateway
Ta sama liczba.
Zupełnie inne ryzyko.
Dlatego zarządzanie podatnościami powinno być połączone z:
asset inventory + exposure management + threat intelligence + incident response.
Co powinna robić organizacja?
Minimalny model powinien obejmować kilka warstw.
1. Inventory
Musisz wiedzieć, co masz.
Servers
Endpoints
VPN
Cloud
Applications
Security Agents
Identity Systems
2. Exposure
Musisz wiedzieć, co jest dostępne z Internetu.
3. Vulnerability Management
Musisz wiedzieć, które komponenty są podatne.
4. Threat Intelligence
Musisz wiedzieć, czy dana luka jest faktycznie wykorzystywana.
5. Identity Security
Musisz kontrolować konta, MFA, sesje i urządzenia.
6. Detection
Musisz wykrywać anomalie.
7. Response
Musisz mieć procedurę na moment, w którym zabezpieczenie zostanie przełamane.
Najważniejsza zmiana myślenia
Współczesny cyberatak coraz rzadziej wygląda jak:
Hacker
↓
Exploit
↓
Server
Bardziej przypomina:
Human
↓
Identity
↓
Device
↓
Application
↓
Session
↓
Infrastructure
↓
Data
Napastnik wybiera najsłabszy element.
Jeżeli nie może wykorzystać użytkownika, spróbuje aplikacji.
Jeżeli aplikacja jest dobrze zabezpieczona, może zaatakować urządzenie.
Jeżeli urządzenie jest chronione, może poszukać podatnego gatewaya.
Jeżeli gateway jest poprawiony, może szukać błędu w systemie tożsamości.
To gra o najsłabsze ogniwo.
Wnioski
Trzy świeże historie opisane przez Bugstoday pokazują trzy zupełnie różne drogi do tego samego celu.
ShinyHunters wykorzystali człowieka i zaufanie.
SharePoint pokazuje, jak authentication bypass może stać się początkiem znacznie większego łańcucha.
NetScaler pokazuje, jak podatna infrastruktura brzegowa może dać napastnikowi bezpośredni punkt wejścia.
A WatchGuard Agent przypomina, że nawet oprogramowanie stworzone do ochrony systemu może stać się elementem ataku.
Wspólny mianownik?
Zaufanie.
Napastnik nie zawsze musi złamać zabezpieczenie.
Czasami wystarczy doprowadzić do sytuacji, w której zabezpieczenie samo powie:
„Ten użytkownik jest prawidłowy.”
„Ten token jest poprawny.”
„Ten proces jest zaufany.”
„Ten ruch pochodzi z właściwego miejsca.”
I właśnie dlatego współczesne cyberbezpieczeństwo powinno zakładać, że każdy element może kiedyś zostać przejęty.
Nie chodzi o to, aby stworzyć system, którego nigdy nie da się zaatakować.
Chodzi o to, aby po przełamaniu jednej warstwy napastnik nadal miał przed sobą kolejne.
Identity
↓
MFA
↓
Device Trust
↓
Conditional Access
↓
Least Privilege
↓
Network Segmentation
↓
EDR
↓
Monitoring
↓
Incident Response
Jeżeli jedna warstwa zawiedzie, następna powinna nadal działać.
To jest różnica między systemem, który wygląda na bezpieczny, a systemem zaprojektowanym na moment, w którym ktoś naprawdę zacznie go atakować.
Jak zabezpieczyć dane i aplikacje w środowiskach chmurowych (AWS, Azure, Google Cloud) Chmurowe rozwiązania obliczeniowe stały się podstawą nowoczesnych firm, Czytaj dalej
Zaawansowane bezpieczeństwo na Androidzie: VPN, antywirusy i ochrona danych Android jest najczęściej używanym systemem mobilnym, co czyni go atrakcyjnym celem Czytaj dalej
