TrueConf jako kanał dostawy malware: Head Mare podmieniło zaufane instalatory

Grupa Head Mare przejęła samodzielnie hostowane serwery wideokonferencyjne TrueConf i zastąpiła legalny instalator klienta wersją zawierającą backdoor. Użytkownik pobierał plik z serwera własnej organizacji, czyli ze źródła, któremu naturalnie ufał bardziej niż linkowi zewnętrznemu. Właśnie to zmieniło włamanie do jednego systemu brzegowego w atak na łańcuch dostaw wielu stacji roboczych.

Kampania dotknęła obserwowane organizacje z sektora transportu, nauki i edukacji. Nie ma podstaw, by uznawać wszystkie instalacje TrueConf za naruszone. Każdy operator samodzielnego serwera powinien jednak zweryfikować wersję, integralność dystrybuowanych plików i historię pobrań, zamiast ograniczać się do zainstalowania łatki.

Dwie drogi prowadziły do tego samego backdoora

Pierwsza część kampanii, aktywna co najmniej od grudnia 2025 roku i wykryta w lutym 2026, używała zaproszeń do wideorozmowy. Ofiara po kliknięciu linku otrzymywała propozycję instalacji klienta. Obok spodziewanego oprogramowania uruchamiał się wcześniej nieznany backdoor PhantomPxPigeon.

W drugiej części napastnicy nie musieli tworzyć domeny podobnej do marki. Przejęli prawdziwe, lokalnie zarządzane serwery TrueConf i podmienili dostępny na nich pakiet kliencki. Raport Kaspersky ICS CERT potwierdza podmianę plików i brak ważnego podpisu cyfrowego w wykrytych złośliwych dystrybucjach.

Dokładna ścieżka wejścia na te konkretne serwery nie została potwierdzona. Badacze uznali za prawdopodobne wykorzystanie BDU:2025-10116 — podatności, dla której producent wydał poprawkę w sierpniu 2025 roku. To ważne rozróżnienie: podmiana instalatorów jest obserwowanym faktem, lecz przypisanie initial access do tej jednej luki pozostaje hipotezą.

Dlaczego podpis jest silniejszy niż zaufanie do adresu URL

TLS odpowiada za połączenie z serwerem, ale nie potwierdza, że administrator serwera udostępnia oryginalny plik producenta. Suma kontrolna opublikowana na tym samym przejętym serwerze również nie tworzy niezależnego dowodu. Podpis kodu wiąże natomiast binarium z kluczem wydawcy i może zostać zweryfikowany przez system przed uruchomieniem.

Wykryte złośliwe pakiety nie miały ważnego podpisu. Organizacja, która blokuje niepodpisane instalatory i wdraża oprogramowanie z centralnego repozytorium po niezależnej weryfikacji, mogła przerwać ten łańcuch nawet po kompromitacji serwera konferencyjnego.

Reakcja na możliwą podmianę

1. Zaktualizuj TrueConf Server do bieżącego wspieranego wydania. Producent wskazał, że linie 5.5.1, 5.4.6 i 5.3.7 zawierały pierwotne poprawki, ale należy użyć najnowszego dostępnego maintenance release.
2. Odizoluj podejrzany serwer przed analizą i zachowaj obrazy dysków, logi reverse proxy, logi uwierzytelnienia oraz katalog z dystrybucjami.
3. Pobierz listę hashy wszystkich instalatorów udostępnianych w badanym okresie. Zweryfikuj ich podpisy poza przejętym hostem, korzystając z zaufanego źródła producenta.
4. Ustal, które endpointy pobrały lub uruchomiły dany hash. Koreluj telemetrykę przeglądarki, proxy, EDR i systemu dystrybucji oprogramowania.
5. Na potencjalnie zainfekowanych stacjach szukaj procesów potomnych instalatora, nietypowych zadań harmonogramu, nowych usług i ruchu wychodzącego po czasie instalacji.
6. Zrotuj sekrety dostępne na serwerze TrueConf oraz poświadczenia użyte przez administratorów z potencjalnie zainfekowanych urządzeń.
7. Odbuduj kanał dystrybucji z czystego obrazu. Samo przywrócenie poprawnego instalatora nie usuwa utrzymanego dostępu napastnika do serwera.
8. Wprowadź allowlisting podpisanego kodu i niezależny manifest hashy przechowywany w systemie, którego administrator TrueConf nie może zmienić.

Fakty i analiza Breachroad

Kaspersky potwierdził obecność PhantomPxPigeon, przejęte serwery, podmienione pakiety i brak ważnych podpisów. Wykorzystanie BDU:2025-10116 pozostaje prawdopodobnym, ale niepotwierdzonym wektorem. Zalecenie niezależnego manifestu oraz korelacji każdego pobrania z hashem jest analizą Breachroad — ma zapewnić dowód także wtedy, gdy źródłowy serwer nie jest wiarygodny.

Szkolenia z reagowania na incydenty uczą zespoły odróżniać podatność wejściową od pełnego zasięgu kompromitacji. Audyt infrastruktury może sprawdzić serwery brzegowe, repozytoria instalatorów, podpisy i możliwość odtworzenia ścieżki dystrybucji.