FalconFlank: twój EDR jako wektor ataku do podniesienia uprawnień

Co wiadomo na pewno

Autorem jest badacz występujący jako Chaotic Eclipse, Nightmare Eclipse, INFINITE NIGHTMARE i MSNightmare, ten sam, który przez ostatnie miesiące regularnie wypuszczał zero-daye na Windows. Pisaliśmy tu o jego MiniPlaśmie w maju i o LegacyHive w lipcu. Kod PoC leży publicznie na GitHubie.

Twarde fakty z repozytorium i z komunikacji producenta:

• PoC działa na w pełni zaktualizowanym Windows 11 25H2 oraz Windows Server 2025 z Falconem w polityce Phase 3 (Optimal Protection).
• Warunkiem jest włączona funkcja usuwania złośliwych makr z plików Microsoft Office.
• Kevin Beaumont potwierdził publicznie, że exploit działa, podobnie jak kilka innych z tej samej serii.
• CrowdStrike prowadzi analizę i zaleca wyłączenie polityki „Microsoft Office File Suspicious Macro Removal” dla Windows. Ochrona przed złośliwymi makrami zostaje po stronie ustawień Cloud Anti-malware for Microsoft Office Files. W portalu wsparcia jest osobny Tech Alert o nazwie FalconFlank.
• CVE nie przypisano, łatki nie ma.

Dlaczego funkcja ochronna staje się prymitywem ataku

Mechanizm remediacji z definicji musi działać z wysokimi uprawnieniami. Ma kasować, przenosić i modyfikować pliki w miejscach, do których zwykły użytkownik nie ma dostępu. To nie jest błąd projektowy, to warunek działania.

Problem zaczyna się wtedy, gdy proces działający jako SYSTEM zapisuje plik pod ścieżką, na którą wpływ ma użytkownik. Windows daje do tego gotowe narzędzie: punkty ponownej analizy, czyli junctions i symlinki. Atakujący przygotowuje strukturę katalogów w swoim profilu, podrzuca dokument, który wywoła remediację, i przekierowuje docelową ścieżkę zapisu tam, gdzie sam nie mógłby nic zapisać.

W przypadku FalconFlank celem jest plik:

C:\Windows\System32\WindowsPowerShell\v1.0\bcrypt.dll

Na czystym systemie ten plik nie istnieje. Prawdziwa biblioteka bcrypt.dll leży w System32. Windows przy ładowaniu bibliotek przeszukuje jednak najpierw katalog samej aplikacji, a powershell.exe mieszka właśnie w v1.0. Wystarczy więc, że jakikolwiek proces PowerShella wystartuje w kontekście SYSTEM (zadanie w harmonogramie, skrypt startowy, narzędzie zarządzania), a podłożona biblioteka wykona się z jego uprawnieniami.

Cała sztuczka polega na tym, że atakujący nie potrzebuje prawa zapisu do System32. Potrzebuje tylko procesu, który je ma, i możliwości pokazania mu palcem, gdzie ma pisać. Falcon dostarcza jedno i drugie.

To nie jest wpadka jednego producenta

W ostatnich tygodniach ten sam badacz opublikował serię exploitów zbudowanych na identycznym pomyśle:

• ShieldBreak (CVE-2026-69414) w Microsoft Defenderze, gdzie silnik czyszczący zapisuje kontrolowaną bibliotekę jako C:\Windows\System32\phoneinfo.dll, a wykonanie z uprawnieniami SYSTEM przychodzi przez wbudowane zadanie Windows Error Reporting. To obejście łatki na CVE-2026-50656.
• HardBreacher w Kaspersky Endpoint Security 14.0.0.504.
• PrettyPrague w Avaście, który zrzuca bazę SAM przez podatność w piaskownicy produktu. Gen Digital potwierdził problem i pracuje nad poprawką.

Wcześniej były RedSun (Cloud Files API plus TieringEngineService), LegacyHive, w którym zwykły użytkownik montuje ul rejestru administratora przez User Profile Service, oraz MiniPlasma, wskrzeszająca załataną w 2020 roku lukę w sterowniku cldflt.sys. Za każdym razem inny korytarz systemu, ten sam schemat: uprzywilejowany zapis plus ścieżka pod kontrolą atakującego.

Beaumont skomentował to bez owijania: problem z jakością bezpieczeństwa samych produktów bezpieczeństwa jest szerszy niż jeden producent. Trudno się nie zgodzić. Zwykle uczymy klientów, że kontrola bezpieczeństwa to redukcja ryzyka. Ta seria przypomina, że kontrola bezpieczeństwa jest też oprogramowaniem, więc ma swoje błędy, a instaluje się na 100 procent stacji w firmie.

Co to znaczy dla twojego ryzyka

Zasięg. EDR stoi na każdym endpoincie i prawie zawsze w jednej, ujednoliconej polityce. Podatność w agencie nie dotyczy jednego serwera, tylko całej floty naraz, z identyczną konfiguracją.

Miejsce w łańcuchu ataku. FalconFlank sam w sobie nie robi włamania, ale zajmuje dokładnie ten stopień, którego brakuje między phishingiem a poważnymi kłopotami. Zdobycie SYSTEM na stacji to dostęp do poświadczeń w pamięci, wyłączenie mechanizmów ochronnych, ruch boczny i dalej domena. Ransomware potrzebuje właśnie tego kroku.

Wykrywalność. Autor sam napisał, że CrowdStrike ma zapewne sygnatury na opublikowany PoC i że wystarczy zmienić technikę ładowania biblioteki, żeby je ominąć. Detekcja konkretnego pliku nie jest więc mitygacją podatności, tylko mitygacją jednej implementacji.

I rzecz najbardziej niewygodna dla CISO: zalecana mitygacja polega na wyłączeniu funkcji ochronnej. Płacisz ochroną przed jednym zagrożeniem za zamknięcie drugiego. To decyzja o ryzyku, a nie zadanie operacyjne, i powinna zostać gdzieś zapisana z datą i nazwiskiem.

Co zrobić w tym tygodniu

• Wyłącz politykę „Microsoft Office File Suspicious Macro Removal” dla Windows w konsoli Falcona, zgodnie z zaleceniem producenta, i sprawdź, czy ustawienia Cloud Anti-malware for Microsoft Office Files są aktywne.
• Otwórz Tech Alert FalconFlank w portalu wsparcia CrowdStrike i przypisz komuś śledzenie go do momentu wydania łatki. Zalecenia producentów przy nieopatchowanych błędach zmieniają się z dnia na dzień.
• Monitoruj pojawienie się pliku pod ścieżką z sekcji technicznej. Na czystym systemie go nie ma, więc każde jego wystąpienie jest samo w sobie alertem.
• Zbuduj regułę polowania na sekwencję: zdarzenie remediacji Falcona, a zaraz po nim zapis nowej biblioteki DLL w katalogu systemowym albo proces potomny z uprawnieniami SYSTEM.
• Kontroluj zmiany w wykluczeniach Falcona. Dodanie wykluczenia to jeden z dwóch sposobów, którymi autor PoC sugeruje uruchomienie exploita.
• Ogranicz problem u źródła. Zablokuj makra w plikach z internetu polityką Office (Block macros from running in Office files from the Internet). Jeśli remediacja nie ma czego czyścić, nie ma czym manipulować.
• Sprawdź, czy inne agenty bezpieczeństwa w środowisku nie są objęte tą samą falą. Kaspersky i Avast już na liście.

Szybki test obecności podłożonej biblioteki:

$p = "$env:SystemRoot\System32\WindowsPowerShell\v1.0\bcrypt.dll"
if (Test-Path $p) {
    Write-Warning "Plik nie powinien istnieć w tej lokalizacji."
    Get-Item $p | Select-Object FullName, CreationTime, LastWriteTime, Length
    Get-AuthenticodeSignature $p | Select-Object Status, SignerCertificate
} else {
    "OK: brak pliku w katalogu PowerShella."
}

Wynik OK znaczy tyle, że ta konkretna ścieżka jest czysta w tej chwili. Nie znaczy, że podatność cię nie dotyczy.