Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania należą do najpoważniejszych zagrożeń we współczesnym cyberbezpieczeństwie. Ich skuteczność wynika z wykorzystania zaufania, jakim użytkownicy i organizacje obdarzają legalnych producentów, ich infrastrukturę oraz mechanizmy aktualizacji.
W przypadku AOMEI Backupper napastnicy mieli wykorzystać infrastrukturę producenta do krótkotrwałego dostarczania złośliwych komponentów zamiast prawidłowych plików odpowiedzialnych za aktualizacje i powiadomienia. Taki scenariusz jest szczególnie niebezpieczny, ponieważ z perspektywy ofiary cały proces wygląda jak standardowa, autoryzowana komunikacja z dostawcą.
W skrócie
Badacze opisali kampanię supply chain wymierzoną w użytkowników AOMEI Backupper na systemach Windows. Operacja polegała na czasowej modyfikacji plików konfiguracyjnych, które kierowały klientów do złośliwego archiwum ZIP zawierającego kolejne etapy infekcji.
- celem byli użytkownicy AOMEI Backupper,
- atak wykorzystywał przejęty kanał aktualizacji i mechanizm powiadomień,
- w kampanii użyto downloadera CROSSROAD oraz backdoora SHINYROAD,
- działania przypisano grupie śledzonej jako UNC7017,
- złośliwe zmiany utrzymywano tylko przez kilka minut, co utrudniało wykrycie.
Kontekst / historia
Incydent obejmował okres od kwietnia do lipca 2026 roku i dotyczył infrastruktury aktualizacyjnej powiązanej z AOMEI Backupper. Jednym z pierwszych sygnałów alarmowych było wykrycie nietypowego uruchomienia legalnego narzędzia zdalnej administracji Radmin w kontekście działania aplikacji AOMEI.
Analiza zdarzeń wskazała, że kompromitacja nie miała charakteru ciągłego. Zamiast utrzymywać złośliwe pliki stale na serwerze, napastnicy okresowo podmieniali konfiguracje tylko na bardzo krótki czas, a następnie przywracali ich prawidłowe wersje. Takie podejście znacząco ograniczało szanse wykrycia podczas rutynowych kontroli i utrudniało odtworzenie pełnego przebiegu incydentu.
Udokumentowane okna ekspozycji trwały od kilku do kilkunastu minut. Taktika „uderz i zniknij” pokazuje rosnącą dojrzałość operacji supply chain, w których kluczowe staje się nie tylko dostarczenie malware, ale też maksymalne ograniczenie śladów pozostawionych w infrastrukturze ofiary i dostawcy.
Analiza techniczna
Techniczna strona ataku opierała się na manipulacji plikami konfiguracyjnymi używanymi przez aplikację. Jeden z nich określał lokalizację pakietów do pobrania, a drugi odpowiadał za treść i logikę działania mechanizmu powiadomień. Po podmianie tych elementów klient pobierał spreparowane archiwum ZIP zamiast legalnych zasobów.
Kluczową słabością okazał się brak silnego uwierzytelniania kryptograficznego konfiguracji po stronie klienta. Dodatkowo wartość kontrolna używana do weryfikacji pobieranego pliku była przekazywana w tym samym, nieuwierzytelnionym kanale. W praktyce dawało to atakującym możliwość jednoczesnego wskazania złośliwego źródła oraz podania zgodnej sumy kontrolnej, co pozwalało obejść podstawową kontrolę integralności.
Łańcuch infekcji obejmował komponent CROSSROAD, działający jako downloader i moduł wstępnego rozpoznania środowiska. Po uruchomieniu analizował system, pobierał kolejne elementy oraz tworzył mechanizmy trwałości, między innymi z użyciem zaplanowanych zadań. Następnie instalowany był SHINYROAD, czyli backdoor zapewniający zdalną komunikację z infrastrukturą C2 i możliwość dalszego dostarczania poleceń.
W jednej z fal kampanii zaobserwowano również próbę wymuszenia uwierzytelnienia NTLM przy użyciu odwołań do zasobu WebDAV kontrolowanego przez napastnika. Tego typu technika może prowadzić do przechwycenia hashy uwierzytelniających Windows, a następnie do ich wykorzystania w kolejnych etapach ataku, na przykład podczas ruchu bocznego lub prób łamania offline.
Istotnym elementem operacji było także użycie legalnych narzędzi, takich jak Radmin. Łączenie zaufanych binariów z własnymi komponentami napastnika utrudnia wykrywanie, zwłaszcza w środowiskach, które w dużym stopniu polegają na ocenie reputacji plików i standardowych regułach antywirusowych.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją takiego incydentu jest utrata zaufania do mechanizmu aktualizacji oraz rozszerzenie powierzchni ataku na wszystkich użytkowników, którzy w krytycznym momencie komunikowali się z naruszoną infrastrukturą. Nawet krótki czas ekspozycji nie wyklucza istotnej liczby ofiar, ponieważ do infekcji mogło dojść podczas zwykłego sprawdzania aktualizacji lub pobierania komunikatów przez aplikację.
- zdalne wykonanie kodu na stacjach roboczych i serwerach,
- ustanowienie trwałego dostępu przez backdoora,
- ukrywanie aktywności przy użyciu legalnych narzędzi administracyjnych,
- ryzyko przejęcia danych uwierzytelniających NTLM,
- dalsza eskalacja do fazy post-exploitation i ruchu bocznego.
Z perspektywy organizacji ważne jest również to, że usunięcie problemu po stronie dostawcy nie oznacza automatycznego oczyszczenia już zainfekowanych systemów. Każde środowisko korzystające z AOMEI Backupper powinno traktować ten incydent jako potencjalne naruszenie własnych endpointów, wymagające aktywnego dochodzenia.
Rekomendacje
Organizacje korzystające z AOMEI Backupper powinny przeprowadzić ukierunkowane działania huntingowe i śledcze na systemach, które w okresie od kwietnia do lipca 2026 roku miały aktywny kontakt z infrastrukturą producenta. Kluczowe jest połączenie analizy hostów, telemetrii EDR oraz logów sieciowych.
- zweryfikować harmonogram zadań pod kątem nietypowych wpisów związanych z AOMEI, Radmin lub procesami uruchamianymi z katalogów tymczasowych,
- sprawdzić obecność nieautoryzowanych plików EXE i DLL w katalogach aplikacji oraz profilach użytkowników,
- przeanalizować logi EDR, DNS i proxy pod kątem połączeń do podejrzanej infrastruktury,
- skontrolować, czy Radmin nie został zainstalowany bez wiedzy zespołu IT,
- przeprowadzić hunting pod kątem beaconingu, anomalii PowerShell i nietypowych procesów potomnych,
- zresetować poświadczenia, jeśli istnieje ryzyko przejęcia hashy NTLM,
- odizolować hosty z oznakami kompromitacji i wykonać pełną analizę śledczą.
Długofalowo warto wdrożyć dodatkowe zabezpieczenia, takie jak allowlisting aplikacji, monitorowanie mechanizmów aktualizacji oprogramowania firm trzecich, niezależną walidację integralności pobieranych pakietów oraz segmentację sieci. Producenci oprogramowania powinni natomiast podpisywać kryptograficznie konfiguracje sterujące aktualizacjami i nie opierać weryfikacji integralności na danych dostarczanych tym samym kanałem, który może zostać naruszony.
Podsumowanie
Incydent związany z AOMEI Backupper pokazuje, jak skuteczne mogą być nowoczesne ataki na łańcuch dostaw prowadzone w modelu krótkotrwałej, precyzyjnej kompromitacji. Zamiast długiego utrzymywania złośliwych plików na serwerach, napastnicy zastosowali krótkie okna operacyjne, które znacząco utrudniły wykrycie i analizę.
Dla zespołów bezpieczeństwa najważniejszy wniosek jest jednoznaczny: zaufanie do legalnego dostawcy nie może zastępować własnej telemetrii, kontroli integralności oraz monitorowania zachowania zaufanych aplikacji. Mechanizmy aktualizacji powinny być traktowane jako krytyczny element powierzchni ataku, wymagający takiej samej uwagi jak systemy uprzywilejowane czy usługi dostępne z sieci.
Źródła
- BleepingComputer — https://www.bleepingcomputer.com/news/security/hackers-hijack-aomei-update-servers-to-secretly-spread-malware/
- Google Cloud Blog — Investigating Ephemeral Supply Chain Tampering — https://cloud.google.com/blog/topics/threat-intelligence/investigating-ephemeral-supply-chain-tampering
- ManageEngine Threat Analysis Lab — AOMEI Backupper supply-chain compromise: Investigation and analysis — https://www.manageengine.com/threat-analysis-lab/aomei-backupper-supply-chain-compromise.html