Nowy dropper MacSync „przechodzi” Gatekeeper w macOS dzięki podpisowi i notaryzacji - Security Bez Tabu

Nowy dropper MacSync „przechodzi” Gatekeeper w macOS dzięki podpisowi i notaryzacji

Wprowadzenie do problemu / definicja „luki”

Gatekeeper to mechanizm macOS, który ma dopuszczać do uruchomienia głównie aplikacje od zidentyfikowanych deweloperów, a w praktyce opiera się m.in. o podpis cyfrowy oraz notaryzację (skan Apple pod kątem znanego malware przed dystrybucją poza App Store). Jeśli aplikacja ma ważny podpis i „bilet” notaryzacji, wygląda dla systemu znacznie bardziej wiarygodnie — i właśnie ten model zaufania bywa nadużywany przez atakujących.

W opisywanym incydencie nie chodzi o klasyczny exploit Gatekeepera, tylko o dostarczenie droppera jako legalnie wyglądającej, podpisanej i notaryzowanej aplikacji Swift, co znacząco redukuje tarcie po stronie ofiary i zwiększa skuteczność kampanii.

W skrócie

  • Nowy wariant MacSync Stealer jest dostarczany w obrazie DMG podszywającym się pod instalator komunikatora („zk-call messenger”).
  • Dropper jest podpisany i notaryzowany, więc potrafi „przejść” weryfikacje Gatekeepera typowe dla pobranych aplikacji.
  • Jamf zgłosił nadużycie do Apple — certyfikat powiązany z Team ID został następnie cofnięty (revoked), ale to nie cofa faktu, że technika działa, dopóki podpis jest ważny.
  • Drugi etap jest pobierany z sieci jako zaciemniony skrypt (m.in. zapis do /tmp/runner), a dropper usuwa ślady, sprawdza łączność i stosuje ograniczanie częstotliwości uruchomień.

Kontekst / historia / powiązania

Jamf wskazuje, że to „cicha” zmiana jakościowa: wcześniejsze iteracje MacSync (i pokrewne kampanie) często opierały się o drag-to-Terminal lub ClickFix (wymuszenie na użytkowniku wklejenia/potwierdzenia komend w Terminalu). Teraz etap ten znika — użytkownik dostaje klasyczny „instalator”, który wygląda i zachowuje się jak aplikacja, a dropper odpala resztę w tle.

W tle jest też szerszy trend: coraz więcej macOS-owego malware próbuje „udawać legalne” poprzez podpisy i notaryzację, bo to realnie obniża skuteczność pierwszej linii obrony opartej o reputację i ostrzeżenia systemowe.

Analiza techniczna / szczegóły łańcucha infekcji

Poniżej najważniejsze elementy techniczne, które opisali badacze Jamf oraz media cytujące ich analizę:

1) Nośnik i socjotechnika

  • Dropper jest zapakowany w DMG nazwany jak instalator: zk-call-messenger-installer-3.9.2-lts.dmg, dystrybuowany z domeny przypominającej oficjalny serwis pobrań.
  • DMG bywa sztucznie „napompowany” (ok. 25,5 MB) przez dołączone pliki-wabiki (np. PDF-y), co może utrudniać proste reguły/heurystyki.

2) Podpis, notaryzacja i cofnięcie certyfikatu

  • Jamf potwierdził, że binarka Mach-O była code-signed i notarized, powiązana z Team ID GNJLS3UYZ4. Następnie Team ID/certyfikat został cofnięty po zgłoszeniu do Apple.

3) Logika droppera (Swift)

  • Aplikacja tworzy artefakty pomagające w „utrzymaniu stanu” i diagnostyce: log w ~/Library/Logs/UserSyncWorker.log oraz katalog ~/Library/Application Support/UserSyncWorker/ (pliki typu last_up, gate), co ułatwia jej kontrolę cyklu uruchomień.
  • Przed pobraniem payloadu wykonuje sprawdzenie łączności i potrafi zakończyć działanie, jeśli środowisko wygląda „nie tak” (np. brak internetu — typowe w sandboxach).
  • Stosuje rate-limiting (~3600 s), żeby nie uruchamiać łańcucha zbyt często i nie generować podejrzanego szumu.

4) Pobranie i uruchomienie 2. etapu

  • Drugi etap jest pobierany po HTTPS (Jamf wskazuje konkretny endpoint) i zapisywany jako /tmp/runner wraz z nagłówkami do walidacji (/tmp/runner.headers).
  • Zanim payload ruszy, dropper usuwa atrybut com.apple.quarantine oraz ustawia prawa wykonywania (np. 750). To jest istotne, bo Gatekeeper w dużej mierze „budzi się” właśnie przez mechanizm kwarantanny dla plików pobranych z internetu.
  • Co ciekawe: dropper wykonuje też własną weryfikację polityki Apple przez spctl -a -v (czyli w praktyce sam sprawdza, czy wygląda „legalnie” dla Gatekeepera). Po uruchomieniu czyści część śladów (kasuje /tmp/runner, zapisuje znacznik czasu kolejnego uruchomienia).

Praktyczne konsekwencje / ryzyko

MacSync to infostealer, więc ryzyko dotyczy przede wszystkim:

  • przejęcia danych uwierzytelniających (przeglądarki, dane sesyjne),
  • danych z pęku kluczy i zasobów użytkownika,
  • danych wrażliwych w firmie (SSO, tokeny, dostęp do SaaS),
  • strat finansowych (np. dostęp do portfeli krypto / kont) — zależnie od tego, jakie moduły są aktywne w danej kampanii.

W firmach największy problem to to, że „instalator” nie wygląda jak klasyczna infekcja terminalowa, więc szybciej przechodzi przez nawyki użytkowników i bywa trudniejszy do wychwycenia w helpdesku („zainstalowałem komunikator”).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów IT/SOC (priorytet: szybkie ograniczenie ryzyka)

  • Zablokuj sieciowo wskazane IoC: domeny/endpointy wykorzystywane do pobierania skryptu i dalszej komunikacji (Jamf publikuje IoC, w tym m.in. URL do pobrania /tmp/runner oraz domenę używaną w łańcuchu).
  • Poluj na artefakty hostowe:
    • ~/Library/Logs/UserSyncWorker.log
    • ~/Library/Application Support/UserSyncWorker/ (np. last_up, gate)
    • tworzenie/uruchamianie /tmp/runner oraz usuwanie com.apple.quarantine dla plików w /tmp
    • nietypowe wywołania spctl -a -v w kontekście droppera (telemetria EDR).
  • Egzekwuj polityki: preferuj dystrybucję aplikacji przez MDM, ogranicz instalacje z nieznanych źródeł, rozważ dodatkowe reguły dla uruchomień z zamontowanych obrazów DMG w środowiskach o wysokim ryzyku.

Dla użytkowników

  • Pobieraj aplikacje wyłącznie z oficjalnych kanałów; sam fakt notaryzacji nie gwarantuje bezpieczeństwa (to skan na znane próbki — atakujący próbują „wejść w okno czasowe” przed wykryciem i cofnięciem certyfikatu).
  • Jeśli instalator każe wykonywać nietypowe kroki (np. „kliknij prawym i Open”, prosi o dodatkowe uprawnienia bez sensu) — przerwij i zgłoś do IT.

Różnice / porównania z innymi przypadkami

Warto rozróżnić dwa scenariusze:

  1. Bypass Gatekeepera jako słabość mechanizmu (np. problemy z propagacją atrybutu kwarantanny w pewnych narzędziach) — to klasyczny „mechanizm można ominąć”.
  2. Nadużycie modelu zaufania (podpis + notaryzacja) oraz działania post-download (np. czyszczenie com.apple.quarantine) — tu Gatekeeper nie jest „złamany” exploitem, tylko atakujący grają w jego reguły i minimalizują sygnały ostrzegawcze.

Opisany MacSync wpisuje się głównie w punkt 2.

Podsumowanie / kluczowe wnioski

  • MacSync podnosi poprzeczkę: od „terminalowej socjotechniki” przechodzi do podpisanych i notaryzowanych dropperów w Swift.
  • Cofnięcie certyfikatu pomaga, ale nie rozwiązuje problemu trendu — ta technika będzie kopiowana przez kolejne rodziny malware.
  • Dla obrony kluczowe są: telemetria endpointów, polowanie na artefakty (UserSyncWorker, /tmp/runner), oraz szybkie blokady sieciowe IoC.

Źródła / bibliografia

  • Jamf Threat Labs – analiza nowego droppera MacSync (Swift, podpis/notaryzacja, IoC). (Jamf)
  • BleepingComputer – omówienie kampanii i informacja o cofnięciu certyfikatu po zgłoszeniu. (BleepingComputer)
  • SecurityWeek – streszczenie i kontekst trendu „signed + notarized” w macOS malware. (SecurityWeek)
  • Apple Security (dokumentacja) – Gatekeeper/Notaryzacja jako warstwy ochrony przed malware. (Apple Support)
  • Palo Alto Networks Unit 42 – jak działa Gatekeeper i rola atrybutu kwarantanny (perspektywa „bypassów”). (Unit 42)