Tydzień temu miałem pierwsze spotkanie z zarządem firmy, dla której zaczynam projekt poprawy bezpieczeństwa IT. Temat: priorytety security na 2026.
Przygotowałem się klasycznie: slajdy o krajobrazie zagrożeń, kilka case studies, liczby. Byłem gotowy tłumaczyć, że MFA nie jest "utrudnianiem życia użytkownikom", tylko elementarną higieną.
Nie zdążyłem nawet zacząć.
Zarząd sam powiedział:
"MFA to priorytet numer jeden. Traktujemy to jako krytyczne i jako quick win. Kiedy zaczynamy?"
Byłem w szoku. Pierwsza sytuacja w mojej karierze, gdy nie trzeba było "sprzedawać" MFA. Żadnych pytań o uciążliwość dla użytkowników. Żadnego "może zaczniemy od czegoś mniejszego". Po prostu: priorytet absolutny.
Co się zmieniło? Ludzie czytają newsy, a rzeczywistość jest brutalnie prosta.
Kampania Zestix: 50 firm, jeden hacker, zero MFA
W raporcie Hudson Rock z początku 2026 opisano kampanię, która powinna być case study w każdym szkoleniu z cybersecurity. Hacker działający pod pseudonimem "Zestix" włamał się do około 50 globalnych przedsiębiorstw.
Przykładowe ofiary:
- Iberia (Hiszpania) - największa linia lotnicza w kraju
- Sekisui House (Japonia) - globalny koncern budowlany
- Intecro Robotics (Turcja) - producent sprzętu aerospace i defense
- Maida Health (Brazylia) - provider usług healthcare
Dane wystawione na sprzedaż na dark webie:
- 11,5 GB wojskowego IP z Intecro Robotics
- 2,3 TB danych medycznych brazylijskiej policji wojskowej
- tysiące aktywnych spraw prawnych Mercedes-Benz USA
- dokumenty inżynieryjne, kontrakty, strategie prawne
Attack chain był banalnie prosty:
- Infostealer na urządzeniu pracownika wykrada hasła zapisane w przeglądarce
- Credentials trafiają do baz na dark webie - niektóre leżały tam latami
- Hacker znajduje loginy do ShareFile, Nextcloud, OwnCloud
- Loguje się normalnie: username + password
- Wchodzi - bo MFA nie było włączone
Cytat z raportu Hudson Rock, który powinien wisieć w każdej serwerowni:
"These companies were not hacked by a quantum computer cracking encryption; they were hacked because an employee infected their device with an infostealer, and the organization failed to turn on 2-Factor Authentication."
Bez exploitów. Bez zero-days. Bez zaawansowanego social engineeringu. Po prostu: hasło.
Dlaczego infostealery wygrywają
Skala problemu w liczbach
2025 był rokiem kradzieży credentials:
- 1,8 miliarda danych logowania wykradzionych przez infostealery (wzrost z 1,2 mld w 2024)
- 22% wszystkich naruszeń zaczyna się od skradzionych loginów
- 46% zainfekowanych urządzeń to BYOD lub prywatny sprzęt używany do pracy
- 4,5 mln USD - średni koszt naruszenia danych (IBM Cost of Data Breach Report 2025)
- 287 dni - średni czas wykrycia incydentu
Najpopularniejsze infostealery w 2026
RedLine Stealer Wykrada cookies, hasła, autofill data, portfele krypto. Celuje w przeglądarki (Chrome, Firefox, Edge), password managery, klientów FTP, tokeny Discord. Najczęściej dystrybuowany jako fałszywe cracki do oprogramowania lub dokumenty Office.
Lumma Stealer Browser fingerprinting, screenshot capture, zbieranie konfiguracji sprzętowej i sieciowej. Posiada mechanizmy anty-VM - utrudnia analizę w sandboxach.
Vidar Modularny i konfigurowalny - atakujący wybiera jakie dane zbierać. Szybka exfiltracja z niskim czasem przebywania w systemie. Często dystrybuowany przez malvertising.
Jak wygląda infekcja w praktyce
Dzień 0, godzina 0:00
Pracownik pobiera "Adobe_Photoshop_2025_Crack.exe" z warez site.
Plik instaluje backdoor i aktywuje RedLine Stealer w tle.
Dzień 0, godzina 0:10
Malware skanuje profile przeglądarek.
Znajduje zapisane hasła do:
- M365 (user@firma.pl)
- ShareFile (konto firmowe)
- AWS Console
- VPN credentials
Dzień 0, godzina 0:15
Dane pakowane i wysyłane na serwer C2.
Malware usuwa ślady i dezinstaluje się.
Pracownik nie wie, że cokolwiek się stało.
Dzień 14
Credentials pojawiają się na dark web marketplace.
Cena: $5-50 za konto, zależnie od wielkości firmy.
Dzień 60
Hacker kupuje credentials.
Próbuje zalogować się do ShareFile.
Sukces - bo brak MFA.
Dostęp do: projektów, kontraktów, danych finansowych.
Dzień 287 (średni czas wykrycia)
Anomalia wykryta - nietypowy wzorzec pobierania plików.
Incident response rozpoczyna się.
Szkody już zrobione.
Ekonomia dark webu
Ile kosztują firmowe dane logowania:
| Typ dostępu | Cena |
|---|---|
| Email firmowy - SMB (do 100 os.) | $5-15 |
| Email firmowy - mid-market (100-1000 os.) | $20-50 |
| Email firmowy - enterprise (1000+) | $50-500 |
| AWS/Azure Console | $100-1 000 |
| O365 Global Admin | $500-3 000 |
| ShareFile/Box admin | $50-200 |
| Pakiet C-level: email + cloud | $5 000+ |
| Sektor finansowy | $10 000+ |
| Healthcare (dane HIPAA) | $15 000+ |
ROI dla atakującego: kupuje credentials za $50, wyciąga dane warte miliony, sprzedaje za $10 000+.
Dlaczego MFA nadal nie jest standardem?
"To będzie uciążliwe dla użytkowników"
Reality check: pracownicy używają MFA codziennie - w bankowości online, social mediach, prywatnym emailu. W pracy nagle ma to być problem?
"Legacy aplikacje nie wspierają MFA"
Rozwiązania istnieją: Azure AD Application Proxy z pre-authentication, Okta Access Gateway, Cloudflare Zero Trust. A jeśli aplikacja naprawdę nie da rady - należy ustalić deadline jej wycofania.
"Nie mamy budżetu"
Koszt MFA: $3-6 na użytkownika miesięcznie. Klucze FIDO2 dla adminów: około $40 za urządzenie. Wdrożenie: 40-80 roboczogodzin.
Koszt naruszenia bez MFA: średnio $4,5 mln, plus reputacja, kary regulacyjne, utrata klientów, wzrost składki ubezpieczeniowej o 20-50%.
"Wdrożymy później"
To najgorszy argument. "Później" nie przychodzi - aż do incydentu.
Praktyczny guide wdrożenia: od zera do produkcji (6-8 tygodni)
Faza 1: Discovery i planowanie (tydzień 1-2)
Krok 1: Zinwentaryzuj wszystkie punkty dostępu
Co sprawdzić:
- M365 (Exchange, SharePoint, Teams, OneDrive)
- Azure / AWS / GCP Console
- Endpointy VPN
- File sharing (ShareFile, Box, Dropbox Business, Nextcloud)
- Panele administracyjne (WordPress, cPanel, narzędzia infrastruktury)
- SSH do produkcji
- Dostęp do baz danych (produkcja)
- CI/CD (Jenkins, GitLab, GitHub)
Krok 2: Risk matrix
| System | MFA aktualnie | Użytkownicy | Wrażliwość danych | Ryzyko | Priorytet |
|---|---|---|---|---|---|
| M365 Admin | Brak | 5 | Krytyczna | 10/10 | P0 |
| AWS Console | Brak | 12 | Krytyczna | 10/10 | P0 |
| VPN | Brak | 150 | Wysoka | 9/10 | P0 |
| ShareFile | Brak | 200 | Wysoka | 9/10 | P0 |
| M365 Użytkownicy | Częściowo | 200 | Wysoka | 8/10 | P1 |
| SSH Prod | Tylko klucze | 8 | Krytyczna | 8/10 | P1 |
P0 = tydzień 1-2, P1 = tydzień 3-4, P2 = tydzień 5-6.
Krok 3: Wybór metod MFA
Odporne na phishing (najlepsza opcja):
- Klucze sprzętowe FIDO2/WebAuthn
- Windows Hello for Business (TPM-backed)
Silne:
- Aplikacje authenticator (Microsoft Authenticator, Google Authenticator)
- Push (Duo, Okta)
Słabe - tylko awaryjnie:
- SMS
Rekomendacja:
- Konta admin: FIDO2 (obowiązkowe)
- Power users: authenticator (podstawowy) + FIDO2 (zapasowy)
- Zwykli użytkownicy: authenticator (podstawowy) + SMS (tylko zapasowy)
- Service accounts: managed identity lub certyfikaty
Faza 2: Projektowanie polityk (tydzień 2-3)
Polityki Conditional Access (Azure AD / Entra ID):
- CA: Wymagaj MFA dla wszystkich użytkowników
- Osobna polityka: phishing-resistant MFA dla adminów
- Blokada legacy authentication - najpierw tryb report-only, potem enforcement
Break-glass accounts - obowiązkowe
Minimum 2 konta awaryjne:
- Bardzo długie, losowe hasła (30+ znaków)
- Przechowywane offline (sejf fizyczny)
- Wyłączone z polityk Conditional Access
- Alert na każde użycie
- Kwartalny przegląd
Faza 3: Pilot (tydzień 3-4)
Grupa pilotażowa: 10-20 osób.
Kogo włączyć:
- Zespół IT (dogfooding - pierwsi testują)
- Early adopters
- Co najmniej jeden sceptyk
- 1-2 osoby z managementu
- Pracownicy zdalni (VPN)
Cel: wykrycie problemów przed pełnym rolloutem.
Faza 4: Pełny rollout (tydzień 5-8)
Podejście falami - dział po dziale.
Co robić w każdej fali:
- Codzienny monitoring adopcji
- Office hours dla pytań
- Komunikacja z jasnym deadline
- FAQ dostępne z wyprzedzeniem
- Twarda data enforcement - bez wyjątków
Faza 5: Hardening i operacje (ciągłe)
- Session controls: re-auth co 12h, brak persistent session na urządzeniach współdzielonych
- Number matching: odporność na MFA fatigue attacks
- Risk-based policies: dodatkowa weryfikacja przy logowaniu z nowej lokalizacji
- Alerty na powtarzające się błędy MFA i próby z podejrzanych IP
Najczęstsze błędy przy wdrożeniu MFA
- Admini na końcu - najważniejsze konta chronione w ostatniej kolejności
- SMS jako primary - słaba metoda, podatna na SIM swapping
- Wyjątki dla legacy bez deadline - stają się permanentne
- Brak break-glass accounts - lockout całego tenanta przy problemie
- Brak monitoringu po rollout - nie wiesz kto faktycznie używa MFA
Podsumowanie
Najbardziej nudne rzeczy robią największą robotę.
MFA jest nudne. Jest oczywiste. Istnieje od lat. I nadal 50 globalnych firm traci dane dlatego, że jeden hacker kupił hasła za $50 i mógł zalogować się bez żadnej dodatkowej weryfikacji.
Zarząd z początku tego artykułu rozumiał to bez slajdów. Coraz więcej zarządów rozumie. Pytanie: czy Twoja organizacja czeka na własny incydent, żeby to zrozumieć?
Jeśli chcesz sprawdzić gdzie Twoja organizacja stoi z NIS2 i bezpieczeństwem technicznym - zacznij od bezpłatnej diagnostyki NIS2.
Potrzebujesz kompleksowych wdrożenia NIS2 i DORA lub audytu bezpieczeństwa? Napisz do nas - działamy end-to-end.
Źródło: Dark Reading — Lack of MFA Common Thread in Vast Cloud Credential Heist