Atak na łańcuch dostaw AOMEI Backupper: krótkotrwała kompromitacja aktualizacji doprowadziła do dystrybucji backdoora - Security Bez Tabu

Atak na łańcuch dostaw AOMEI Backupper: krótkotrwała kompromitacja aktualizacji doprowadziła do dystrybucji backdoora

Cybersecurity news

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą do najbardziej niebezpiecznych incydentów cyberbezpieczeństwa, ponieważ wykorzystują zaufanie użytkowników do legalnych mechanizmów aktualizacji. W przypadku AOMEI Backupper problem nie wynikał z klasycznej luki w samej aplikacji, lecz z możliwości manipulacji plikami dostarczanymi przez infrastrukturę aktualizacji producenta.

W praktyce oznaczało to, że część systemów Windows mogła pobrać złośliwy komponent podszywający się pod legalny pakiet aktualizacyjny. Taki scenariusz jest szczególnie groźny, ponieważ złośliwy ruch i uruchamiane procesy mogą wyglądać jak standardowa aktywność zaufanego oprogramowania.

W skrócie

Opisana kampania polegała na krótkotrwałej podmianie plików aktualizacyjnych obsługiwanych przez AOMEI Backupper. Manipulacje trwały zwykle od kilku do kilkunastu minut, przez co infekowane były tylko te hosty, które w danym momencie sprawdzały dostępność aktualizacji.

  • atak dotyczył łańcucha dostaw, a nie klasycznej podatności klienta,
  • złośliwy pakiet instalował backdoora zapewniającego zdalny dostęp,
  • w jednym z incydentów możliwy był także wyciek odpowiedzi NetNTLMv2,
  • krótkie okna czasowe znacząco utrudniały wykrycie i analizę zdarzenia.

Kontekst / historia

Z ujawnionych informacji wynika, że aktywność obserwowano między majem a lipcem 2026 roku. Badacze wskazali co najmniej trzy istotne okna manipulacji: 28 maja, 16 lipca oraz 20 lipca 2026 roku. Każde z nich trwało około pięciu do dziesięciu minut.

Model działania był wyraźnie oportunistyczny. Zamiast długotrwałej kompromitacji wszystkich klientów, napastnicy okresowo zmieniali zawartość zwracaną przez serwery aktualizacji. Taka taktyka ograniczała ryzyko wykrycia przez mechanizmy reputacyjne, rutynowe kontrole i standardowe ścieżki monitoringu po stronie dostawcy oraz klientów.

Według dostępnych ustaleń ofiary pochodziły z różnych sektorów, między innymi z branży IT, telekomunikacji i szkolnictwa wyższego. Sugeruje to międzynarodowy charakter kampanii oraz dobór celów zależny od momentu kontaktu z infrastrukturą aktualizacji.

Analiza techniczna

Kluczowym problemem bezpieczeństwa były pliki konfiguracyjne odpowiedzialne za wskazanie pakietu do pobrania oraz sterowanie funkcją powiadomień. Oprogramowanie nie weryfikowało ich w sposób kryptograficzny, a suma kontrolna pakietu znajdowała się w tym samym niezaufanym źródle, które definiowało, co należy pobrać. Taki model oznaczał brak silnego łańcucha zaufania.

W rezultacie napastnik mający możliwość zmiany tych plików po stronie serwera mógł jednocześnie wskazać inny pakiet i dostarczyć odpowiadającą mu wartość kontrolną. Aplikacja akceptowała więc złośliwy plik jako poprawny, mimo że weryfikacja opierała się na danych pochodzących z tego samego, podatnego na manipulację źródła.

Po pobraniu pakietu uruchamiany był komponent typu downloader, którego zadaniem było rozpakowanie dalszych elementów, utworzenie zadania harmonogramu i zapewnienie trwałości. W analizowanych przypadkach wykorzystano legalnie podpisane narzędzie zdalnej administracji, obok którego umieszczano bibliotekę DLL kontrolowaną przez atakującego. Taka technika umożliwiała sideloading DLL, czyli załadowanie złośliwego modułu przez zaufany proces.

Implant zapewniał funkcjonalność zdalnej powłoki oraz możliwość pobierania i uruchamiania kolejnych ładunków. Badacze odnotowali również użycie dodatkowego frameworka C2 maskowanego jako legalne oprogramowanie. Oznacza to, że incydent mógł prowadzić nie tylko do jednorazowego uruchomienia malware, ale do pełnej, interaktywnej kontroli nad hostem.

Szczególnie niebezpieczny był incydent z 20 lipca 2026 roku. Oprócz podmiany pakietu zmieniono wtedy także mechanizm powiadomień tak, aby ładował niewidoczny zasób przez WebDAV. Taki scenariusz mógł doprowadzić do wysłania odpowiedzi NetNTLMv2 do infrastruktury kontrolowanej przez napastnika, nawet bez skutecznego uruchomienia właściwego złośliwego kodu.

Konsekwencje / ryzyko

Najpoważniejszym aspektem tej kampanii jest wykorzystanie zaufanego kanału aktualizacji. Dla zespołów bezpieczeństwa oznacza to wyższy poziom trudności detekcji, ponieważ aktywność może przypominać normalne działanie aplikacji biznesowej i legalnych komponentów systemowych.

  • zdalne wykonanie kodu na hostach z zainstalowanym AOMEI Backupper,
  • utrwalenie obecności za pomocą zadań harmonogramu i legalnych binariów,
  • możliwość dostarczania dodatkowych narzędzi post-exploitation,
  • ryzyko wycieku poświadczeń NetNTLMv2,
  • potencjalne rozszerzenie dostępu w środowiskach domenowych.

Istotnym problemem operacyjnym jest także fakt, że napastnicy przywracali część artefaktów do stanu przypominającego legalny. Ponieważ serwery przez większość czasu zwracały poprawną zawartość, analiza wykonana po incydencie mogła błędnie sugerować brak kompromitacji. To klasyczny przykład trudności związanych z krótkotrwałym, punktowym naruszeniem łańcucha dostaw.

Rekomendacje

Organizacje korzystające z AOMEI Backupper powinny przeprowadzić retrospektywne polowanie na zagrożenia obejmujące co najmniej okres od kwietnia do lipca 2026 roku. Samo zabezpieczenie infrastruktury po stronie dostawcy nie oznacza, że wcześniej zainfekowane systemy zostały oczyszczone.

  • zweryfikować hosty pod kątem nietypowych zadań harmonogramu, szczególnie powiązanych z komponentami zdalnej administracji,
  • przeszukać systemy plików pod kątem niepodpisanych plików wykonywalnych uruchamianych z katalogów AOMEI,
  • sprawdzić obecność podejrzanych bibliotek DLL mogących wskazywać na sideloading,
  • przeanalizować logi pod kątem ruchu do infrastruktury C2 oraz nietypowego WebDAV i SMB wychodzącego do Internetu,
  • czasowo ograniczyć lub zablokować wychodzący ruch SMB na port 445 do adresów zewnętrznych,
  • zachować lokalne artefakty i cache aktualizacji do celów śledczych,
  • wdrożyć reguły detekcyjne YARA, Sigma oraz dostępne wskaźniki IOC,
  • ocenić, czy inne narzędzia tego samego dostawcy nie wykorzystują podobnego modelu zaufania.

Z perspektywy strategicznej organizacje powinny wymagać od dostawców podpisanych metadanych aktualizacji, rozdzielenia źródła konfiguracji od źródła walidacji integralności oraz wdrożenia kryptograficznie odpornej weryfikacji pakietów. Bez tego kanał aktualizacji pozostaje podatny na manipulację po stronie serwera.

Podsumowanie

Incydent związany z AOMEI Backupper pokazuje, że nowoczesny atak na łańcuch dostaw nie musi opierać się na luce w aplikacji końcowej. Wystarczy słabo zaprojektowany model zaufania w procesie aktualizacji, aby zaufany mechanizm stał się nośnikiem backdoora.

Krótkie okna podmiany, wykorzystanie legalnych komponentów oraz możliwość wycieku poświadczeń bez jawnego uruchamiania malware sprawiają, że sprawa ma duże znaczenie dla zespołów SOC, DFIR i administratorów. Każde środowisko korzystające z tego oprogramowania w analizowanym okresie powinno zostać objęte kontrolą pod kątem trwałej kompromitacji.

Źródła

  1. https://thehackernews.com/2026/10/attackers-tampered-with-aomei.html
  2. https://cloud.google.com/blog/topics/threat-intelligence/aomei-backupper-supply-chain-compromise
  3. https://www.manageengine.com/log-management/cyber-security/aomei-backupper-supply-chain-attack.html
  4. https://www.ubackup.com/changelog.html